Hi Juergen, Andy, With an author/contributor hat on ...
It is unclear to me, from an RFC document perspective, what is being proposed here, and appreciate that each of you may have different thoughts as to what is being proposed. E.g., are you proposing: (1) That the yang module versioning draft should update RFC 7950 to define a yang version "1.2" or "2.0" label, but still keeps the new extensions defined in a separate module? (2) The same as (1) but also changing the statements to be part of the formal YANG language (but still in separate documents that update RFC 7950)? (3) To do an RFC 7950-bis for YANG 1.2/2.0, that strictly only includes the module versioning work? E.g., leaving the semantic version numbers as a separate draft. (4) To look at YANG 1.2/2.0 in a wider scope, and consider this work alongside the other 100 proposed issues/enhancements (https://github.com/netmod-wg/yang-next/issues), for the next version of YANG. (5) something else ... My overriding concern here is that there is a pretty clear industry support for accepting that non-backwards-compatible changes do sometimes occur and whilst it is entirely appropriate for them to be minimized, it is still helpful to have a way to accurately indicate when they do occur. Depending on what the actual work is, I think that doing (1) or (2) might take another 4-8 months, doing (3) might take 8-12 months, and doing (4) could be another 5 years, and it is worth noting that the first draft bringing Semver to IETF was by Benoit 6 years ago. I.e., we have already been working on this for a long time. After the previous module-versioning last-call we attempted to refine the draft further to make the functionality more optional, specifically, changing the semantics of "recommended-min" for imports to make it suggestive guidance rather than changing the actual import behaviour. So, my reading is that the core changes to the YANG specification by this document are really those definition in section 3, and I think that these can be mitigated via a CLI option to tools that are performing comparisons of YANG modules. Pragmatically, I would like to see the WG publish these as separate RFCs, in the format that they are now, to get this work completed, so that we can move on. Once the versioning work is complete, then I think that it would be helpful for the WG to consider doing a rev of RFC 7950, that should include this versioning work (including defining formal YANG keywords rather than extension keywords) and also evaluate whether some of the other proposals/enhancements tracked on github should be considered, along with trying to clean up the documents, e.g., moving the NETCONF protocol specific parts out of the base YANG spec, moving the XML encoding into its own separate document. Regards, Rob > -----Original Message----- > From: netmod <[email protected]> On Behalf Of Jürgen Schönwälder > Sent: 13 May 2023 23:14 > To: Andy Bierman <[email protected]> > Cc: NetMod WG <[email protected]> > Subject: Re: [netmod] Comments on draft-ietf-netmod-yang-module- > versioning-09 > > On Sat, May 13, 2023 at 01:13:06PM -0700, Andy Bierman wrote: > > > > 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. > > +1 > > > Ironically, the WG seems to understand the importance of proper > management > > for NBC changes in YANG content, but not the YANG language itself. > > yup > > /js > > -- > Jürgen Schönwälder Constructor University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://constructor.university/> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
