Jason,
> On Apr 13, 2023, at 4:29 PM, Jason Sterne (Nokia) <[email protected]> > wrote: > [>>JTS:] Yeah – I see that perspective. But a client using the old > API/contract gets new/different behavior for the unknown-flags leaf from a > new server. Hence NBC – unless we decide in the end to somehow make this > specific case/typedef an exception but I’m not sure about that yet. The > typedef and behavior you are describing there may still be useful as-is even > if we decide to still officially consider the change to unknown-flags > behavior as NBC (i.e. in new the version of the module that changes a bit > from unknown to known). Understood. True to form, I seldom seem to come to netmod with easy problems. :-) Not having read the current versioning material, this would seem to be a case where you could consider this NBC, but likely not-problematic. I'm not sure if you have "severity" as a concept in the discussions thus far. If there's current verbiage about documenting NBC considerations, feel free to point me to the appropriate documents. As a general purpose mechanism, the draft could simply describe that any time an update to the known leaf type is done that the unknown leaf type is flagged for NBC for the newly assigned bits. > > 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. > [>>JTS:] Can you point me to a repository or RFC where I can see this? I’m > not familiar with where this YANG work is being done. Sorry for not including the URL. This document went to WGLC for IDR a few days ago. We'll be asking (yet yet yet again) for YANG doctor review. https://www.ietf.org/archive/id/draft-ietf-idr-bgp-model-16.html You'll find the typedef issue for extended communities in there, and also the field for unknown bits in the operational state that is the genesis for this conversation. > 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. [>>JTS:] > Sure – maybe just mention explicitly that the model for unknown-flags stays > unchanged. > > 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?[>>JTS:] Yes – that would probably help. I'll try to roll in these changes soon. Thanks. -- Jeff
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
