Jason,
> On Apr 12, 2023, at 5:26 PM, Jason Sterne (Nokia) <[email protected]> > wrote: > > It just occurred to me that to avoid the NBC change we could also consider > just calling this new typedef “raw-bits” and always outputting all the bits > in the second leaf (whether they are known or not)? I suspect this was > already considered though… It was and part of the discussion. As I mentioned to Andy, consistent advice for modeling the raw stuff might be helpful. However, for bit fields I find the likely options to be annoying and probably not good ease of use for the end-user. More below > > From: netmod <[email protected]> On Behalf Of Jason Sterne (Nokia) > 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. That's the current proposal, yes. > > Strictly speaking, that should probably be considered an NBC change although > it is a bit of a grey zone - the NBC rules for state are fuzzy (theoretically > they are defined by RFC7950 but it is clear those rules were focused on > config, and the same goes for all our new versioning work). But I could > imagine an implementation that was previously seeing bit-0 returned and > suddenly stops seeing that bit-0 returned (which could cause different > interpretation/behavior). So in some ways the semantics of the unknown-flags > leaf has changed. It may be better to just flag this as an NBC change so a > user would be drawn to look at it, and make a decision that they do or don’t > have to update their handling/use of it? I'm not following the versioning discussions enough to know the full semantics you're implying. That said, you hit the relevant point next: > > The known flags leaf would only go through backwards compatible changes > though (since we’d always be additive in adding bits) – assuming bit > positions don’t change in the protocol. Exactly. Unknown became known. The need to "see" the unknown has gone away. Thinking on this slightly more, I think I see where our thinking diverges somewhat. From one perspective (illustrated by your point above), bit-1 has "gone away". This is a change. My perspective is that the semantics of the node in question is there to model "unknown". The change is thus "expected" when things are assigned. Where things are potentially problematic for end users from a state perspective is that if you're testing on the unknown bit, its change is HIGHLY problematic. My use case is for debugging rather than daily operations. In circumstances where you wanted to always know the contents of the bit vector in a constant fashion, a "raw" output is preferable. However, this reverts to the headache discussed in other sub-threads. I wish to point you and others concerned on these points to the BGP YANG modeling for Extended Communities, which will have these problems in a different flavor: Known communities will render via the typedefs, unknown will render using the prefix 'raw'. (See typedef bgp-ext-community-type.) This headache is already a consideration in every BGP implementation that deals with extended communities in changing meaning. To address that point and needs for stable representation, see leaf-list "ext-community-raw". Netmod's deep scrutiny on this topic is heartily invited. :-) I expect a lot of heartburn over what current implementations do with this stuff. > > It would probably help to show an example of what a YANG module looks like > for step 1 and then step 2 (an unknown becomes known), and also what is > returned in NETCONF in step 1 and step 2. You partially have that in section > 3.2 although the YANG model isn’t shown and it might be good to explicitly > mention that <unknown-flags> isn’t returned (note it may also be valid to > return <unknown-flags></unknown-flags>). Figure 4 in draft version -02 shows how the type gets modified to add the new bit. The model doesn't change between step 1/ step 2 beyond this. If you'd find it helpful, I could add to the text covering Figure 8 "after assignment, bit-1 is no longer returned in unknown-flags". Is that what you're looking for? -- Jeff
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
