On Mon, Oct 17, 2022 at 10:52 AM Balázs Lengyel <[email protected]> wrote:
> 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. > > > The term 'Where pragmatic' could be removed from the text. It implies that only people who do not want to be pragmatic need to follow the SHOULD. I do not object to the versioning work. We might even implement some of it when the RFCs get published. > Regards Balazs > Andy > > > *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
