Dear WG, Just published -01 to address most of the comments. See details below.
On Mon, Nov 4, 2024 at 9:00 AM Per Andersson <[email protected]> wrote: > > 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. Changed the wording to reflect what has been done and evaluations of those efforts. > > - 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. Replaced "instead of" with "in addition to". > > - 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. Updated wording to reflect what is simplified and by what means. > > - 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. No updates have been made here. -- Per _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
