In the current proposal/draft, when bit-1 changes to "known", then suddenly the server stops sending bit-1 in the unknown-bits.
That behavior changes whether the author remembers (or decides) to update the description of the unknown-flags or not. I've suggested that the description of the unknown-flags leaf is updated in this case. If the author forgets (or decides not) to update the description, I'm not sure we'd want to suddenly say that's backwards compatible. The author should (or perhaps MUST) mark the revision as non-backwards-compatible IMO. Jason > -----Original Message----- > From: Martin Björklund <mbj+i...@4668.se> > Sent: Monday, April 17, 2023 2:08 AM > To: Jason Sterne (Nokia) <jason.ste...@nokia.com> > Cc: jh...@pfrc.org; netmod@ietf.org > Subject: Re: [netmod] Unknown bits - backwards compatibility > > > CAUTION: This is an external email. Please be very careful when clicking > links or > opening attachments. See the URL nok.it/ext for additional information. > > > > Hi, > > > "Jason Sterne (Nokia)" <jason.ste...@nokia.com> wrote: > > Hi Martin, > > > > If a "description" of a leaf (without a default statement) changes from > > this: > > > > "the absence of this leaf causes the protocol to stay > > administratively down" > > > > to this: > > > > "the absence of this leaf causes the protocol to go administratively > > up" > > > > (with no other changes in the YANG) then IMO it *is* an NBC > > change. The behavior described in a "description" field is > > considered part of the model/API (I've seen many references & > > examples of this over the years in NETMOD/NETCONF discussions). > > Absolutely. > > But that's not what we disuss in this case. In this case we have > a leaf that shows "unknown bits", and neither the type nor the leaf > (including descriptions) change during the upgrade. > > > > /martin > > > > > > > Maybe it becomes more subtle if that behavior change isn't documented in the > "description" statement (I'd argue it is still NBC if the server changes that > behavior and they should be publishing a new revision of the YANG model/API), > but I was proposing that it should in this case. > > > > Jason > > > > > -----Original Message----- > > > From: Martin Björklund <mbj+i...@4668.se> > > > Sent: Friday, April 14, 2023 4:39 AM > > > To: Jason Sterne (Nokia) <jason.ste...@nokia.com> > > > Cc: jh...@pfrc.org; netmod@ietf.org > > > Subject: Re: [netmod] Unknown bits - backwards compatibility > > > > > > > > > CAUTION: This is an external email. Please be very careful when clicking > > > links > or > > > opening attachments. See the URL nok.it/ext for additional information. > > > > > > > > > > > > Hi, > > > > > > I am quite confused after reading this thread, so I had to go back to > > > this first message: > > > > > > "Jason Sterne (Nokia)" <jason.ste...@nokia.com> wrote: > > > > Hi Jeff, > > > > > > > > One topic that came up during the IETF 116 NETMOD meeting was > > > > backwards compatibility. > > > > > > > > >From what I understand, a leaf (e.g. unknown-flags) that uses the > > > > >unknown-bits typedef would never change its definition in YANG. It > > > > >would always be defined as unknown-bits with all 64 bit definitions > > > > >even as more and more bits become "known". *But* the system would > > > > >suddenly stop reporting bit-0, then bit-1 in that unknown-flags leaf > > > > >as those bits become known. > > > > > > > > Strictly speaking, that should probably be considered an NBC change > > > > > > Nothing has changed in the data model, so there is no way to mark the > > > _data model_ as NBC. > > > > > > The server follows the data model, and reports which bits it doesn't > > > understand. With software updates, this may change over time. This > > > is simply the semantics of this state leaf. > > > > > > > > > /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
