Hi Jason,
On 2020-05-13, 11:50 AM, "Sterne, Jason (Nokia - CA/Ottawa)" <[email protected]> wrote: Hi guys, As someone who is heavily involved in the development of an extensive YANG model comprised of submodules, I'm not a fan of mandating that include by revision is mandatory for submodules. It may indeed be a good idea (so perhaps SHOULD is fine) but I can see it causing problems on the implementation side. The primary development of a data model may be distributed out to submodules and the main module may only be a top level container for the submodules (and rarely touched). This would suddenly create an ordering dependency in the release process that requires the main module file to systematically be updated after all development of the submodules is halted. Then the results of the submodules has to be used to then go update the module. Solvable - yes, but folks who work on large scale projects will know that suddenly requiring that type of development process change isn't as easy as it may sound on paper. <RR> I can see why you wouldn't want to modify all your include by-revision statements. But you would still need to update the module revision-label based on changes done in the included submodules. Regards, Reshad. It is possible to manage the "packaging" of submodules and modules out of band or other mechanisms. OpenConfig, for example, uses submodules but does not currently include by version. I'm not proposing this is ideal. But I think we should leave it as acceptable. Rgds, Jason > -----Original Message----- > From: Reshad Rahman (rrahman) <[email protected]> > Sent: Tuesday, May 12, 2020 9:46 AM > To: Sterne, Jason (Nokia - CA/Ottawa) <[email protected]>; Martin > Björklund <[email protected]> > Cc: [email protected] > Subject: Re: [netmod] Revision labels for submodules > > Hi Jason, > > On 2020-05-09, 12:52 PM, "Sterne, Jason (Nokia - CA/Ottawa)" > <[email protected]> wrote: > > Hi Martin, > > Your approach sounds good to me. I was forgetting about the "editorial" > level of change (e.g. the 3rd part of SemVer). So I agree that moving a leaf > would be an editorial change in both submodules. > > But what if a module is not doing include by revision? It may indeed make > sense to include by revision but it isn't mandated. For sake of argument here > what if the module itself didn't change at all in this case? > It is now mandated in section 3 of draft-ietf-netmod-yang-module- > versioning-00. > > > It *feels* like the right thing to do here is to consider the module overall > to have an editorial change. > > The revision statement of sub-modules has a scope of the file (the sub- > module). It isn't clear to me whether the revision of a *module* has a scope > that includes all sub-modules or if it is just a scope of the module file. But we > could clarify that as part of this work. > Because of include by revision, the module would have to change to include > a different revision of a sub-module. > > Regards, > Reshad. > > Jason > > > -----Original Message----- > > From: Martin Björklund <[email protected]> > > Sent: Saturday, May 9, 2020 11:54 AM > > To: [email protected] > > Cc: [email protected]; Sterne, Jason (Nokia - CA/Ottawa) > > <[email protected]> > > Subject: Re: [netmod] Revision labels for submodules > > > > "Reshad Rahman (rrahman)" <[email protected]> wrote: > > > Hi, > > > > > > On 2020-05-08, 5:12 PM, "Martin Björklund" <[email protected]> > wrote: > > > > > > Hi, > > > > > > "Reshad Rahman (rrahman)" <[email protected]> wrote: > > > > Hi, > > > > > > > > This came up during this week's meeting. We briefly discussed > whether > > > > there's a need to version sub-modules or can we restrict versioning > to > > > > modules only. We would like to hear from the WG on this, > especially > > > > those with experience managing sub-modules. > > > > > > Yes I think this is needed. At tail-f, there are several modules with > > > many submodules. These modules always use include by revision, > and > > > always the main module is always uddated when any submodule is > > > updated. It doens't make much sense IMO to not use include by > > > revision. > > > > > > > For completeness, below is an update from Jason in github: > > > > My initial reaction is that we should not preclude the use of > revision > > > > label with a submodule. Submodules have their own version > today. The > > > > trick is to define (or explicitly say it is out of scope) whether a > > > > module version must change if any underlying submodule versions > > > > change. That gets difficult if you consider simply moving a leaf > from > > > > one sub-module to another (without changing anything else about > it - > > > > its context, etc). > > > > > > Why would this be difficult? The revision date is updated on any > > > editorial change (see 7.1.9 of RFC 7950). So if a leaf gets moved > > > from submodule A to submodule B, then their revisions are udpated, > and > > > hence the module's include-by revision is udpated, and hence the > > > module's revision ois updated. > > > > > > I think what Jason meant is that by moving a leaf between > submodules, > > > it's possible the module's schema didn't change. > > > So yes revision date is updated, but you can't blindly update the > > > revision-label. > > > > Why not? > > > > > > /martin > > > > > > > > > > Regards, > > > Reshad. > > > > > > /martin > > > > > > > > > > > > > > > > > Regards, > > > > Reshad. > > > > > > > > On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad Rahman > > (rrahman)" > > > > <[email protected] on behalf of > > > > [email protected]> wrote: > > > > > > > > Hi, > > > > > > > > https://github.com/netmod-wg/yang-ver-dt/issues/49 > > > > > > > > o 3.3 > > > > > > > > Submodules MUST NOT use revision label schemes that > could > > > > be > > > > confused > > > > with the including module's revision label scheme. > > > > > > > > Hmm, how do I ensure that this MUST NOT is handled > > > > correctly? > > > > What > > > > exactly does "could be confused with" mean? > > > > > > > > Good point. What was meant by that the label space for > modules and > > > > sub-modules are orthogonal. e.g. the sub-module and module > both > > have > > > > the same label, it shouldn't be inferred that the 2 are related. > > > > We'll change/clarify the text. > > > > > > > > Regards, > > > > Reshad. > > > > > > > > On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman > > (rrahman)" > > > > <[email protected] on behalf of > > > > [email protected]> wrote: > > > > > > > > Hi Martin, > > > > > > > > We've opened issues to track your review comments (see > > > > below). Will > > > > kick off separate therads for each issue. > > > > > > > > https://github.com/netmod-wg/yang-ver- > > dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev- > handling > > > > > > > > Regards, > > > > Reshad. > > > > > > > > On 2020-03-10, 3:31 PM, "netmod on behalf of Martin > Björklund" > > > > <[email protected] on behalf of [email protected]> > wrote: > > > > > > > > Hi, > > > > > > > > Here are my review comments of > > > > draft-verdt-netmod-yang-module-versioning-01. > > > > > > > > > > > > > > > > o 3.1.1 > > > > > > > > o In statements that have any data definition statements > > > > as > > > > substatements, those data definition substatements > MAY > > > > be > > > > reordered, as long as they do not change the ordering > > > > or > > > > any "rpc" > > > > "input" substatements. > > > > > > > > I think this needs to capture that no descendant > statements > > > > to > > > > "input" can be reordered. Same for "output" (note, > "input" > > > > and > > > > "output" in both "rpc" and "action"). > > > > > > > > > > > > o 3.3 > > > > > > > > All revision labels that match the pattern for the > > > > "version" > > > > typedef in the ietf-yang-semver YANG module MUST be > > > > interpreted as > > > > YANG semantic version numbers. > > > > > > > > I don't think this is a good idea. Seems like a layer > > > > violation. > > > > What if my project use another dialect of semver, that > > > > wouldn't > > > > be > > > > possible with this rule. I think this needs to be removed. > > > > > > > > > > > > o 3.3 > > > > > > > > Submodules MUST NOT use revision label schemes that > could > > > > be > > > > confused > > > > with the including module's revision label scheme. > > > > > > > > Hmm, how do I ensure that this MUST NOT is handled > > > > correctly? > > > > What > > > > exactly does "could be confused with" mean? > > > > > > > > > > > > o 3.3 > > > > > > > > In the filename of a YANG module, where it takes the > > > > form: > > > > module- > > > > or-submodule-name ['@' revision-label] ( '.yang' / > > > > '.yin' ) > > > > > > > > Should this section update 5.2 of RFC 7950? I know that > > > > 5.2 > > > > just > > > > says "SHOULD". But existing tools implement this SHOULD, > > > > and > > > > they > > > > need to be updated to handle this new convention. > > > > > > > > But I wonder if this a good idea. It means that a tool > > > > that > > > > looks > > > > for a module with a certain revision date cannot simply > > > > check > > > > the > > > > filenames, but need to parse all available modules (wijust > > > > to > > > > find the > > > > > > > > > > > > > > > > o 3.4 > > > > > > > > leaf imperial-temperature { > > > > type int64; > > > > units "degrees Fahrenheit"; > > > > status deprecated { > > > > rev:status-description > > > > "Imperial measurements are being phased out in > > > > favor > > > > of their metric equivalents. Use > > > > metric-temperature > > > > instead."; > > > > } > > > > description > > > > "Temperature in degrees Fahrenheit."; > > > > } > > > > > > > > I don't think rev:status-description is necessary / worth > > > > it. > > > > This > > > > can easily be written with the normal description > statement > > > > instead: > > > > > > > > leaf imperial-temperature { > > > > type int64; > > > > units "degrees Fahrenheit"; > > > > status deprecated; > > > > description > > > > "Imperial measurements are being phased out in > > > > favor > > > > of their metric equivalents. Use > > > > metric-temperature > > > > instead. > > > > > > > > Temperature in degrees Fahrenheit."; > > > > } > > > > > > > > > > > > o 3.5 > > > > > > > > The example modules should be legal YANG modules. Use > e.g. > > > > "urn:example:module" as namespace. > > > > > > > > Also, the modules are missing the last "}", which confuses > > > > the > > > > "rfcstrip" tool. > > > > > > > > > > > > o 4.1.1 > > > > > > > > Alternatively, the first example could have used the > > > > revision > > > > label > > > > "1.0.0" instead, which selects the same set of > > > > revisions/versions. > > > > > > > > import example-module { > > > > rev:revision-or-derived 1.0.0; > > > > } > > > > > > > > Shouldn't this be s/1.0.0/2.0.0/g ? > > > > > > > > > > > > o 5 > > > > > > > > I think the module name "ietf-yl-revisions" should be > > > > changed to > > > > "ietf-yang-library-revisions". "yl" is not a well-known > > > > acronym. > > > > > > > > > > > > o 5.2.2 > > > > > > > > Wouldn't it be better if the leaf > > > > "deprecated-nodes-implemented" > > > > and > > > > "obsolete-nodes-absent" were of type "boolean" rather > than > > > > type > > > > "empty"? > > > > > > > > > > > > o 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". > > > > > > > > It is ok to use rev:nbc-changes if needed, though. > > > > > > > > > > > > o 7.1.1 > > > > > > > > There is a missing " in: > > > > > > > > 4. For status "obsolete", it is RECOMMENDED to keep the > > > > "status- > > > > description" information, from when the node had > > > > status > > > > "deprecated, which is still relevant. > > > > HERE -----------^ > > > > > > > > > > > > o 8 > > > > > > > > s/CODE ENDS>/<CODE ENDS>/ > > > > > > > > > > > > o Both YANG modules > > > > > > > > All extensions should specify the grammar; i.e., in which > > > > statements > > > > they can be present and which substatements they can > have. > > > > > > > > > > > > > > > > /martin > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > > > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
