Jason,
> On Apr 13, 2023, at 5:00 PM, Jason Sterne (Nokia) <[email protected]> > wrote: > > 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: > 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/> > 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. I think I'm still unclear on how this would manifest for my proposal. The "known" field isn't having a NBC change, so I think we can ignore that. The "unknown" field has a stable type. More importantly, and perhaps a larger question for the NBC work, what needs to be flagged is that a specific bit has been impacted at a specific version bump of the document. How is that to be signaled on such a type? Consider instead the non-general case, and one that's in the bgp-model: leaf unknown-flags { type bits { bit unknown-2 { position 2; description "Bit 2 was received but is currently RESERVED."; } bit unknown-3 { position 3; description "Bit 3 was received but is currently RESERVED."; } } This represents the modeling from my unknown draft for the remaining two bits of the nybble that aren't assigned after the second bit was assigned. If a future version of BGP's Graceful Restart feature assigned bit 2, and unknown-flags wasn't modeled using my proposed typedef, I can see the following actions being done: Add new type to the known leaf. (A backward compatible change.) Delete "unknown-2". This is NBC, but clearly documents the change. Briefly scrolling through the module-versioning draft, it doesn't appear that there's ways to flag what nodes contribute to the NBC issues. In any case, where the contents are visibly impacted, it's clear you can flag this. I suspect you're missing a way to flag the case as documented in my current draft. -- Jeff
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
