On Sat, Mar 15, 2025 at 7:52 AM Lou Berger <[email protected]> wrote: > > 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?)
Yes, only the last one. The plan was to leave it as is. No further comments was made after asking for clarification. It was deemed that there is no conflict between: * stating that generally only one file SHOULD exist, but several MAY exist * RFC 7950 stating how a filename form SHOULD be * having multiple filenames If the WG disagrees this SHOULD can be softened or even removed. Perhaps that is the course of action to take in order for this draft to progress? -- Per > Thanks, > Lou > > ---------- > On February 26, 2025 7:35:23 AM Per Andersson <[email protected]> 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 <[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]
