Hi Ketan, Thanks for the updated ballot.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Ketan Talaulikar via Datatracker <[email protected]> > Envoyé : mercredi 4 juin 2025 20:04 > À : The IESG <[email protected]> > Cc : [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected] > Objet : Ketan Talaulikar's Discuss on draft-ietf-netmod-rfc8407bis- > 26: (with DISCUSS and COMMENT) > > > Ketan Talaulikar has entered the following ballot position for > draft-ietf-netmod-rfc8407bis-26: 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.) > > > ------------------------------------------------------------------- > DISCUSS: > ------------------------------------------------------------------- > > Thanks to the authors and the WG for your work on this important > document. > > I have one high-level point that I would like to discuss with the > authors and > the WG since is it not clear - this is regarding experimental and > information > track YANG module documents in IETF stream. > > At a high-level, I would like to discuss and understand whether > YANG model > documents can be experimental or informational. I think the answer > is YES? But > this is not clear. A follow-on question: what is the guidance for > YANG models > specified in standards track document being augmented by modules in > experimental or informational track document? Is there any > restrictions? I > think the answer is NO? But again, this is not clear. > > Please also see in the comments sections for some concerns that are > related to > this topic - those are provided inline for better context. > > UPDATE for v26: Thanks for the new text to help address my > concerns. There are > still some remnants in the text related to this point that I am > listing in the > comments below with specific suggestions. [Med] I think that your initial discuss is addressed both in -26 and "materially" :-) with the WG in the thread initiated specifically for this: https://mailarchive.ietf.org/arch/msg/netmod/bWv1aqW2TXyrsn3PI641xg0Nx0U/. The position I'm hearing from the WG is well summarized by Benoît: "It's best to provide guidance only on Standards Tracks, while everybody else can follow them if they want". The NEW text captures this spirit: These guidelines are intended to be used by authors and reviewers to improve the readability and interoperability of published YANG data models. These guidelines can be used independent of the IETF publication stream or even by other organizations. > > ------------------------------------------------------------------- > COMMENT: > ------------------------------------------------------------------- > > Please find below some comments provided inline in the idnits > output of v26 of > this document. ... [Med] Trimmed points I already clarified and for which we won't make changes. > > 1042 4. YANG Usage Guidelines > > 1044 Modules in IETF Standards Track specifications MUST > comply with all > 1045 syntactic and semantic requirements of YANG 1.1 > [RFC7950]. See the > > <major> This is related to my DISCUSS. Suggest replace "IETF > Standards Track > specifications" with "IETF Stream documents" [Med] This CURRENT wording still reflect the position I'm hearing from the WG. This does not prevent others to follow this guidance. > > 1060 4.1. Module Naming Conventions > > 1062 Normative modules contained in Standards Track documents > MUST be > 1063 named according to the guidelines in the IANA > Considerations section > 1064 of [RFC6020]. > > <major> The referenced RFC talks about "IETF stream documents" and > not > Standards Track documents alone. This is related to my DISCUSS. > Suggest > to replace "contained in Standards Track documents" with "contained > in > IETF stream documents" or even better with "contained in > documents". > [Med] This CURRENT wording still reflect the position I'm hearing from the WG. This does not prevent others to follow this guidance. > 1160 For convenience, prefix values of example modules SHOULD > be prefixed > 1161 with "ex" or similar patterns. In doing so, readers of > example > 1162 modules or tree diagrams that mix both example and > standard modules > 1163 can easily identify example parts > > <major> This is kind of something that I caught when looking for > "standard". In > this case, I believe it should have been ... s/standard/normative ? > If you > look for "standard module" (case insensitive search) there are more > such > occurrences to be found. I believe they should also be changed > similarly. [Med] "standard module" use was inherited from RFC6020/RFC7950. For example, RFC6020 says the following: The names of all standard modules and submodules MUST be unique. Developers of enterprise modules are RECOMMENDED to choose names for their modules that will have a low probability of colliding with standard or other enterprise modules, e.g., by using the enterprise or organization name as a prefix for the module name. > > 1662 The "organization" statement MUST be present. If the > module is > 1663 contained in a document intended for IETF Standards > Track status, > 1664 then the organization SHOULD be the IETF working group > (WG) chartered > 1665 to write the document. Exceptions may be example > modules, IANA- > 1666 maintained modules, or modules contained in AD-sponsored > documents. > 1667 For other standards organizations, a similar approach is > also > 1668 suggested. > > 1670 The "contact" statement MUST be present. If the module > is contained > 1671 in a document intended for Standards Track status, then > the WG web > 1672 and mailing information SHOULD be present, and the main > document > 1673 author or editor contact information SHOULD be present. > If > 1674 additional authors or editors exist, their contact > information MAY be > 1675 present. There is no need to include the contact > information for WG > 1676 Chairs. > > <major> This is another instance which talks only about standards > track. This > is related to my DISCUSS. > > SUGGEST: > The "organization" statement MUST be present. If the module is > contained in an > IETF Stream document, then the organization SHOULD be the IETF > working group > (WG) chartered to write the document. Exceptions may be example > modules, > IANA-maintained modules, or modules contained in AD-sponsored > documents. For > other standards organizations, a similar approach is also > suggested. > > The "contact" statement MUST be present. If the module is contained > in an IETF > Stream document, then the WG web and mailing information SHOULD be > present, and > the main document author or editor contact information SHOULD be > present. If > additional authors or editors exist, their contact information MAY > be present. > There is no need to include the contact information for WG Chairs. > Exceptions > may be example modules, IANA-maintained modules, or modules > contained in > AD-sponsored documents. For other standards organizations, a > similar approach > is also suggested. [Med] This CURRENT wording still reflect the position I'm hearing from the WG. This does not prevent others to follow this guidance. > > 1823 The following example URNs would be valid namespace > statement values > 1824 for Standards Track modules: > > 1826 urn:ietf:params:xml:ns:yang:ietf-netconf-partial- > lock > > 1828 urn:ietf:params:xml:ns:yang:ietf-netconf-state > > 1830 urn:ietf:params:xml:ns:yang:ietf-netconf > > 1832 Note that a different URN prefix string SHOULD be used > for modules > 1833 that are not Standards Track. The string SHOULD be > selected > 1834 according to the guidelines in Section 5.3 of [RFC7950]. > > 1836 The following URIs exemplify what might be used by > modules that are > 1837 not Standards Track. > > <major> This is again limiting to standards track document and > related to > my DISCUSS. Suggest replacing "Standards Track" with "IETF Stream > document" [Med] This CURRENT wording still reflect the position I'm hearing from the WG. This does not prevent others to follow this guidance. > > 3205 4.30.3. Guidance for Writing the IANA Considerations for > RFCs Defining > 3206 IANA-Maintained Modules > > <major> What is missing is guidance for future documents (i.e. not > RFC IIII) > that allocate code points from a registry that is associated with > an > IANA-maintained YANG module. I guess the instruction for such a > document is to > not give any specific instruction related to such a module (e.g., > don't try to > repeat the updated module in appendix or such?) - all of this > should be taken > care of by IANA automatically based on instructions provided in RFC > IIII ? > [Med] We do already say in that section: * A request to IANA to add a note to the page displaying the information about the IANA-maintained module that new values must not be directly added to the module. These values should be added to an authoritative IANA registry. -26 have now the following: IANA-maintained module: A YANG module that is maintained by IANA and has an IANA registry associated with it (e.g., "iana-tunnel-type" [RFC8675] or "iana-pseudowire-types" [RFC9291]). Once an IANA-maintained module is initialized, new values are not directly added to the module. These values are instead added to the companion registry. How these values are added to the registry itself will follow the policy set for that registry. Not sure what further change is needed. Thank you. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
