Hi! Thanks for your thorough review Jürgen!
On Fri, Nov 1, 2024 at 4:07 PM Jürgen Schönwälder <[email protected]> wrote: > > * YANG module file name conventions > <draft-ietf-netmod-yang-module-filename-00> > > - I suggest to remove text making claims that something is "easy" > etc. unless there is a real definition for "easy". Having a > semantic version number in a file name does nothing by itself, it > just adds more clutter to the locations where modules are stored. > The semantic version number only is useful if people implement a > revised version of YANG that supports semantic versioning. Is this aiming at the paragraph mentioning that it is easy to update tooling? It only discusses the effort to update the actual tool and states that the effort required for the industry to adopt YANG SemVer might be significant. It can be clarified to state that the tooling that have been investigated all needed only small (or trivial) efforts to support the module filename change. > - Why "instead of the revision date"? I think the revision date > should always be there - at least as long a we talk about YANG > 1.1. Existing deployed tools do use those names. You may _in > addition_ have other names. In RFC 7950 revision date is optional. This draft states that you can either support [email protected] or acme-router-module#2.0.3.yang and, finally, just acme-router-module.yang Where both revision date and revision label are optional but mutually exclusive. Do you suggest that both the revision date and the revision label should be in the filename? > - I am not sure the statement "YANG semantic version is recommended > in order to simplify for module consumers" is true if at the same > time you recommend to break RFC 7950 compliant implementations by > not requiring the YANG 1.1 module file names anymore. I think these are orthogonal things. It simplifies in the way that it is quick to glance over a module name and see if there is an indication that it has changed according to semantic versioning rules. However, it might make things more difficult because tooling update is necessary to handle support for the updated file name of course. > - Typically, only one file name SHOULD exist for the same module (or > submodule) revision. [...] Two file names [...] MAY exist for the > same module (or submodule) revision. > > I disagree with this statement. You can add additional names, > there is no point in changing and breaking RFC 7950 rules. > Implementations can arrange files in different directories if that > is a concern. Storage is cheap, breaking existing code is not. Do you mean that the SHOULD can be softened? The WG asked to present guidance for this issue, the guidelines should probably not be too weak. > - I do not really understand why this is a separate document and not > a part of draft-ietf-netmod-yang-semver (after rewriting it to > stop break YANG 1.1). It was taken out by the yang versioning design team but the WG requested it to be addressed. The yang versioning design team thought that an experimental draft was the way forward, but the WG chairs suggested it should be a standards track document. It can absolutely be put back in draft-ietf-netmod-yang-semver. -- Per _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
