Hi Christopher, Thanks for your review!
The -12 revision should address your comments. Answers inline. On Tue, Jun 2, 2026 at 5:39 AM Christopher Inacio via Datatracker <[email protected]> wrote: > > Christopher Inacio has entered the following ballot position for > draft-ietf-netmod-yang-module-filename-11: No Record > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-filename/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the short and concise draft. > > Thanks to Barry L., and Joel H. for their reviews. (Both caught the ABNF > notation issues about semver / date.) > > I would like to echo Éric's comments about if this draft intends to recommend > making two copies of the same YANG module? > > >If the YANG module (or submodule) has an associated YANG semantic version > (ysv:version), then a file name that use the YANG semantic version MUST be > created. In addition, a file with the revision date in the file name MAY be > created as well. > > That is what that paragraph says unless I'm really mistaken. This is now relaxed to a SHOULD with guidance on why and when it is acceptable to not use the YANG module file name convention. However, the IANA Considerations require that two files, one with YANG semantic version and one with revision-date, are be created; and that they are identical byte-for-byte. It was discussed to use symlinks but in discussions with IANA the WG consensus was to create two identical copies. (There were technical and operational reasons for avoiding using symlinks.) > I don't know what to make of Section 2.1. The SemVer will indicate some > amount > of compatibility, but then everything else is caveat emptor? How would this > file naming standard help when there are multiple competing versions? It will indicate that the versions might be different but share the same base. Without the YANG module file name convention there exist no way to mark a YANG module (file). They would just be name the same thing but have different revision dates. E.g.: [email protected] [email protected] With the file name convention in RFC 7950 they could be just: [email protected] [email protected] I.e. without any indication on what draft they belong to. > The working group absolutely wants IANA to create 2 entries for each YANG > module that has a SemVer version attached AND wants IANA to ensure that the > contents of the modules are identical? Yes. Existing registry contents should not be removed, but new files can be added with ysv:version. Since all tooling, systems, and deployments might not handle the YANG module file name convention, the existing file name convention must be made available. > What does identical mean in this case? > Byte-by-byte equivalence? It does, this is now clarified. -- Per _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
