[As a contributor] I mostly agree with Martin’s comments, mostly in that I don’t think the “semver" label has been fully justified relative to the disruption I perceive it may cause. I’d prefer the documents regarding semver be adopted as Experimental until more is known.
Kent > On Mar 13, 2020, at 12:53 PM, Sterne, Jason (Nokia - CA/Ottawa) > <[email protected]> wrote: > > Hi Martin, > > Thanks for taking a look at the drafts and for your support of the DT's work. > Please see inline. > > Regards, > Jason > >> -----Original Message----- >> From: netmod <[email protected]> On Behalf Of Martin Björklund >> Sent: Tuesday, March 10, 2020 3:28 PM >> To: [email protected] >> Cc: [email protected]; [email protected] >> Subject: Re: [netmod] Adoption of versioning design team docs >> >> [second attempt, sorry for duplicates] >> >> Hi, >> >> By document: >> >> draft-verdt-netmod-yang-module-versioning-01 >> >> This is a great contribution to the YANG ecosystem. It is very well >> written, and I would like to see this document proceed quickly. The >> solutions it proposed are really needed. I have one objection >> though; in 7.1 the text says: >> >> All IETF YANG modules MUST include revision-label statements for all >> newly published YANG modules, and all newly published revisions of >> existing YANG modules. The revision-label MUST take the form of a >> YANG semantic version number [I-D.verdt-netmod-yang-semver]. >> >> I strongly disagree with this new rule. IETF modules use a linear >> history, so there are no reasons to use "modified semver". > > [>>JTS: ] This point will obviously require further discussion, so we have > raised an issue in our GitHub DT tracker for it: > https://github.com/netmod-wg/yang-ver-dt/issues/45 > > Would you be okay to defer discussion on this until after the adoption call, > so that we can focus discussion on the two drafts that you oppose adopting? > >> >> I support the adoption of this document. >> >> (I will send a review of this document in a separate mail) >> >> >> draft-verdt-netmod-yang-semver-01 >> >> This draft proposes a way to express how a given revision is >> backwards compatible in a very short format. With the new extension >> statements in draft-verdt-netmod-yang-module-versioning, this >> information is already present in the revision history of a module. >> (One possible exception is editorial changes, but that can easily be >> fixed by adding an "editorial" extension to "ietf-yang-revisions"). >> >> I don't think this document should be adopted. > > [>>JTS: ] History suggests that YANG modules, even those produced by IETF > will not always be flawless. Most IETF documents may end up having a linear > history (in which case semver and the modified semver look the same). But > some may not. > > Vendors, however, definitely need to be able to support/fix issues in shipped > releases without forcing clients to move to the latest code. That means some > ability to describe changes in branched modules is required. Branching is > optional (and NBC changes in previous versions is not recommended) but when > it does need to happen, we should at least have a standardized and well > described mechanism available. > > Semver provides a lot more intuitive high level information about the scope > of changes in a module vs a vanilla revision date. It presents a human > friendly approximation/summary for a complex lineage system when needed. > > Having a common modified yang semver scheme for standard and vendor models > would be very useful for consumers of YANG models. > > Ultimately a diff of modules is needed to know every change, but it does give > a quick 1 line indication of the impact of changing between two module > versions, and can handle branched model development. > >> >> >> draft-rwilton-netmod-yang-packages-03 >> >> I support the adoption of this document. >> >> >> draft-wilton-netmod-yang-ver-selection-02 >> >> I think the solutions proposed in this draft are overly complex and >> some of them are probably impossible to implement correctly in real >> world use cases. >> >> I don't think this document should be adopted. > > > [>>JTS: ] It would be good to discuss the scenarios that version selection > may not work for. > > We do believe there are some cases where version selection is very helpful. > > One example is when an NBC change needs to occur (e.g. bug fix, or extending > functionality) that causes a leaf to change type but there is a strong desire > to keep the same name (e.g. something basic like "interface" or "address"). > We can't use a "status deprecated" approach to support the old functionality > in this case. > > Another example is the ability for a client to specify (and a server to > advertise & limit) which data models (3rd party vs proprietary) it wants to > use for interactions with the server. > > This is an important part of a complete solution to versioning and backwards > compatibility, and after discussions of various alternatives we think this is > the most viable approach. > > Note that this draft is optional for clients and servers to support. It > provides a scheme when it is desired/needed but servers aren't required to > support this if it is too complex for them or not useful in their > applications. There is also a fair bit of flexibility in the draft for > different server capabilities. > >> >> >> draft-verdt-netmod-yang-schema-comparison-00 >> >> I support the adoption of this document. >> >> >> >> /martin >> >> >> Lou Berger <[email protected]> wrote: >>> Hi, >>> We'd like to start a two week adoption call for the set of documents >>> described below by Rob. To be specific, this includes >>> 1) draft-verdt-netmod-yang-solutions-03 >>> 2) draft-verdt-netmod-yang-module-versioning-01 >>> 3) draft-verdt-netmod-yang-semver-01 >>> 4) draft-rwilton-netmod-yang-packages-03 >>> 5) draft-wilton-netmod-yang-ver-selection-02 >>> 6) draft-verdt-netmod-yang-schema-comparison-00 >>> >>> The adoption call ends in two weeks, on March 16. >>> >>> Please voice your support or objections on list. While we prefer to >>> adopt as a set, objections on specific documents are acceptable. >>> >>> Netmod Chairs >>> >>> On 2/29/2020 2:21 AM, Rob Wilton (rwilton) wrote: >>> >>>> Netmod chairs, >>>> >>>> The version selection draft draft-wilton-netmod-yang-ver-selection-02 >>>> is now posted. With that, the YANG versioning design team would like >>>> to please request you make an WG adoption call for these documents. >>>> >>>> The updated full list is: >>>> >>>> 1) draft-verdt-netmod-yang-solutions-03 >>>> - Solution overview, updated since 106 to cover updates to version >>>> - selection and schema comparison drafts. >>>> >>>> 2) draft-verdt-netmod-yang-module-versioning-01 >>>> - Base module versioning solution, unchanged from the version presented >>>> - at 106. >>>> >>>> 3) draft-verdt-netmod-yang-semver-01 >>>> - YANG Semantic version numbers, unchanged from the version >> presented at >>>> - 106. >>>> >>>> 4) draft-rwilton-netmod-yang-packages-03 >>>> - YANG packages draft, updated since 106 >>>> 5) draft-wilton-netmod-yang-ver-selection-02 >>>> - Version selection, updated since 106, as per notes below >>>> >>>> 6) draft-verdt-netmod-yang-schema-comparison-00 >>>> - Schema comparison tooling, unchanged from the version presented at >>>> - 106. >>>> >>>> The main changes to the version selection draft are: >>>> - We have tried to simplify the model, but at the same time give servers >>>> - more flexibility about how they implement version selection and what >>>> - it can be used for. E.g. if the server wants to allow a client to >>>> - choose between different schema versions, but require that all clients >>>> - use the same schema version, that is now possible >>>> - The draft explicitly disallows schema-selection happening mid-session >>>> - The solution allows the server to require clients to configure >>>> - schema-sets before they are used >>>> - The solution provides more information about which schema-sets are >>>> - compatible with each other >>>> >>>> Regards, >>>> Rob >>>> >>>> >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
