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
