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. ---------------------------------------------------------------------- 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? _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
