Per, When you say "most of the comments" - what is your plan for addressing comments not yet addressed? (Which is just the last one, right?)
Thanks, Lou ---------- On February 26, 2025 7:35:23 AM Per Andersson <per.i...@ionio.se> wrote: 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 <per.i...@ionio.se> wrote: Hi! Thanks for your thorough review Jürgen! On Fri, Nov 1, 2024 at 4:07 PM Jürgen Schönwälder <jschoenwaelder@constructor.university> 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 -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
