Hi Jeff, We avoided getting into subtleties about “severity” of an NBC change (hard enough to just get agreement on basic rules). But I do think it is useful to come up with changes and approaches that have lower impact on users/clients even if they are still marked as NBC.
For the new versioning marking, it would basically be the following. In the “revision” statement of the new module: 1. Add "rev:non-backwards-compatible" as per draft-ietf-netmod-yang-module-versioning-08 - Updated YANG Module Revision Handling<https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/> 2. Increment the major version of the YANG Semver (i.e. go from 1.0.0 to 2.0.0) as per draft-ietf-netmod-yang-semver-11 - YANG Semantic Versioning<https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver/11/> That may seem harsh, but we leaned towards being strict on flagging any NBC change in order to avoid false-negatives (i.e. false-positives aren’t as bad). Users can then diff the module versions, see that only the unknown-bits stuff has changed, and then decide if they need to update their client, etc. Jason From: Jeffrey Haas <[email protected]> Sent: Thursday, April 13, 2023 4:44 PM To: Jason Sterne (Nokia) <[email protected]> Cc: [email protected] Subject: Re: 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. Jason, On Apr 13, 2023, at 4:29 PM, Jason Sterne (Nokia) <[email protected]<mailto:[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
