On Sat, May 13, 2023 at 12:15 PM Jason Sterne (Nokia) < jason.ste...@nokia.com> wrote:
> Hi Andy, > > > > YANG modules are occasionally doing NBC changes today (in the IETF, in > other standard bodies and in vendor modules). If an old tool/client doesn’t > recognize the new rev:non-backwards-compatible extension it isn’t any worse > off than today. But this extension allows YANG 1.1 modules to clearly > communicate to tools/programmers/etc that an NBC has occurred. > > > I do not buy the argument that it is OK to change the YANG 1.1 standard this way because there are some examples of 7950 violations. Some NBC changes are much more impactful than others and are all being lumped together. All extensions are optional to implement in YANG 1.1. A YANG 1.1 tool already deployed (all of them) does not know about these extensions, even if it tried not to ignore extensions. The only correct way to remove MUST/MUST NOT from the "YANG contract" is to introduce a new YANG language version (1.2), and make a new contract. The versioning, update rules, import/include handling, and lifecycle features are too important for interoperability to be left optional, and too important to be extensions instead of real statements. Ironically, the WG seems to understand the importance of proper management for NBC changes in YANG content, but not the YANG language itself. Andy About your last paragraph: The intent of the draft is not to encourage NBC > changes. In section 3.1 it says the following: > > Note that NBC changes often create problems for clients, thus it is > recommended to avoid making them.¶ > > Section 7.1 says the following: > > NBC changes to YANG modules may cause problems to clients, who are > consumers of YANG models, and hence YANG module authors SHOULD minimize NBC > changes and keep changes BC whenever possible. > > > > When NBC changes are introduced, consideration should be given to the > impact on clients and YANG module authors SHOULD try to mitigate that > impact. > > > > But NBC changes are happening in the industry so at least this lets > authors indicate it. > > > > I agree that doing a phased change is best. That’s what we recommend in > section 7.1.1 (deprecate first, etc) and B.2. > > > > The module versioning draft also updates that the change from current or > deprecated to obsolete is NBC. Going “obsolete” is an impact to a client. > > > > Jason > > > > > > *From:* netmod <netmod-boun...@ietf.org> *On Behalf Of *Andy Bierman > *Sent:* Tuesday, May 9, 2023 2:06 PM > *To:* NetMod WG <netmod@ietf.org> > *Subject:* [netmod] Comments on > draft-ietf-netmod-yang-module-versioning-09 > > > > > > *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. > > > > Hi, > > > > Most of the document focuses on the administrative details that will > > be required to update a YANG module. (Lots of them). > > > > My concern is with YANG 1.1 Co-existence and deployment of this new RFC. > (Sec 3.1) > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09#section-3.1 > > > > A client (or another tool) that is compliant with RFC 7950 is > > not required to be aware of the new YANG extensions, or expect > > NBC changes in new module revisions. It is not a good idea to > > allow NBC changes in a YANG 1.1 module. IMO the new rules > > need to apply to a new YANG language version. It is not reasonable > > to expect YANG 1.1 tools to work even if MUST requirements are removed. > > > > Since YANG 1.1 Co-existence is not possible, vendors will decide > > for themselves how much NBC they want in their implementations. > > Breaking a YANG 1.1 client tool is still a problem they will have to deal > with. > > > > This new RFC could encourage instability and poor engineering practices in > YANG APIs. > > IMO best practice is still to introduce a new identifier and phase out > > the old identifier with status=deprecated, then obsolete. > > This is how opensource usually works (for good reason). > > > > > > Andy > > > > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
