Hi Roman, Thanks for your review! Answers inline.
On Wed, Jun 3, 2026 at 8:19 PM Roman Danyliw via Datatracker <[email protected]> wrote: > > Roman Danyliw has entered the following ballot position for > draft-ietf-netmod-yang-module-filename-13: Discuss > > 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/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > ** Section 2. What does “update” mean? How should implementers take this > guidance? > > 2. YANG Module File Names > This section updates Section 5.2 of [RFC7950], Section 5.2 of > [RFC6020], and Section 3.2 of [RFC9907]. > > -- On RFC7950 and RFC6020, it appears like the text in this Section 2 should > replace all of Section 5.2. Is that accurate, if so, please be explicit. > Otherwise, it isn't clear how both blocks of text should be concurrently > evaluated by an implementer. > > -- On RFC7950 and RFC6020, assuming this section is a replacement, how should > this guidance be internalized. Both of these RFCs are defining the “YANG > language” applicable if it is used in the IETF context or not. What does it > mean to recommend to someone who isn’t in the IETF ecosystem to “If a revision > has an associated YANG semantic version (ysv:version) then a YANG file SHOULD > be created that uses the YANG semantic version in the file name. > Additionally, > YANG files with or without the revision-date MAY be created”? The text seemed > to be saying “make two files”. This guidance only seems meaningful in the > IANA > version control approach being defined here. > > -- On RFC9907, how should the text in this Section 2 be merged with Section > 3.2 > (for RFC9907)? It looks like the text is different and the subsequent section > of this document (Section 2.1) is a more natural swap. > > ** Section 2.1. What does “update” mean? > > 2.1. Code Components > This section updates Section 3.2 of [RFC9907]. > > Please be explicit to say (I believe) this section replaces Section 3.2 of > RFC9907. Revision 14 has been published to address the issues you raised. It is now explicitly defined what is updated and not. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you to Joel Halpern for the GENART review. > > ** Section 2. > In short, the YANG semantic version file name scheme is RECOMMENDED, > as its use will convey compatibility status at a glance without the > need to read the module. If a system or tooling can't handle the > YANG module file name convention, it is acceptable to not support or > use the convention defined in this document. > > If I am the developer of a YANG module who do I know that "a system or tooling > can't handle this new file name convention" whereby allowing me to ignore the > recommendation? I would say that you should query the system or tool documentation. However, the authority is be the actual implementation, so you would need to verify that given your input the tool produces the expected output. The method to verify this is no different from any other software, program, or tool and is outside the scope of this document. -- Per _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
