Hello Andy, Found this older email. The draft discourages, but allows NBC changes , including in standard modules (and that is needed, IETF has already made NBC changes). Other SDOs ORAN, 3GPP and others have much faster release cycles, so they have more chance to deprecate or obsolete YANG nodes thereby doing NBC changes. Vendors, with even faster cycles, will have even more cases where they deprecate, obsolete, remove data nodes.
Yes, NBC changes are bad, but sometimes needed. The draft encourages to keep changes BC, but allows NBC. This is a significant departure from RFC 7950, just as you say, but the idea in RFC7950 that NBC changes can be fully avoided was unrealistic to begin with. Regards Balazs From: netmod <[email protected]> On Behalf Of Andy Bierman Sent: Tuesday, 14 June, 2022 20:35 To: NetMod WG <[email protected]> Subject: [netmod] draft-ietf-netmod-yang-module-versioning-05: NBC Changes Hi, The draft-05 version has expired and is no longer on the NETMOD WG WEB page. Sec 3.1 includes this text: Where pragmatic, updates to YANG modules SHOULD be backwards- compatible, following the definition in Section 3.1.1<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning#section-3.1.1>. This is a significant departure from RFC 7950. There are normal "lifecycle" changes that can occur to YANG-based APIs that are currently classified as NBC changes in 7950, sec 11. They are often related to the release train. Maybe this concept is common enough to standardize. For example, we often introduce a leaf with a default of 'disabled' because we mandate that ALL new features or behavior changes MUST require the client to opt-in. But after a year or two, we may change that default to 'enabled' in a new release train. Then if the feature is deprecated at the end of the lifecycle, the default may get changed back to 'disabled' in a new release train. BC compatibility is ALWAYS maintained within a release train. Given that RFCs take so long to publish, it seems unlikely that we would ever be in a position to make a "real" NBC change in the middle of a release train, such that all of the client code already deployed will break immediately when the upgrade is done. We can NEVER just remove the old version. It is hard to imagine a situation where breaking real deployments is a better option than introducing a new identifier, so old clients and new clients can coexist. Andy
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
