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 <netmod-boun...@ietf.org> On Behalf Of Martin Björklund > Sent: Tuesday, March 10, 2020 3:28 PM > To: lber...@labn.net > Cc: netmod-cha...@ietf.org; netmod@ietf.org > 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 <lber...@labn.net> 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 > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
