Per,
Thank you. Unless we hear a new objection our plan is to proceed with
the draft as is.
Lou
On 3/16/2025 8:15 PM, Per Andersson wrote:
On Sat, Mar 15, 2025 at 7:52 AM Lou Berger <lber...@labn.net> 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 <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
