Roman Danyliw has entered the following ballot position for draft-ietf-netmod-rfc8407bis-25: No Objection
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-rfc8407bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Christer Holmberg for the GENART review. ** Section 3 All guidelines for I-D authors [ID-Guidelines] MUST be followed. Appreciating that this text was carried over from RFC8407: -- Why are requirement set for all I-Ds being repeated here? This would be true for any document, on a YANG topic or not. -- Versioning: which exact version of each page is mandatory to implement? Is it every future version? -- Why is some other clarifying guidance about minting RFCs not include – e.g., https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ or guidance to adhere to the internet architecture. IMO, it is not appropriate to reference an educational wiki with a normative MUST. I also don’t see value in repeating what is required of every I-D. There are a few other places noted below where guidance about writing an I-D which isn’t specific to YANG is repeated. ** Section 3 The following sections MUST be present in an I-D containing a YANG module: * Narrative sections * Definition sections * Security Considerations section * IANA Considerations section * References section Same comment as above. Why are document elements already required by other guidance for ALL I-Ds listed here (e.g., Security Considerations, IANA considerations)? Why are some required things omitted (e.g., an abstract per https://www.rfc-editor.org/rfc/rfc7322.html#section-4.3)? I would recommend focusing on what is YANG specific. ** Section 3.4. If the document contains major Network Management Datastore Architecture (NMDA) exceptions or include a temporary non-NMDA module [RFC8342], then the Introduction section should mention this fact with the reasoning that motivated that design. Refer to Section 4.23 for more NMDA-related guidance. Specifically, Section 4.23.2 includes a recommendation for designers to describe and justify any NMDA exceptions in detail as part of the module itself. What constitutes a “major” NMDA exception? What’s the threshold between “major” (which requires documentation in the abstract) and minor (which would not)? ** Section 3.8 In order to comply with IESG policy as set forth in <https://www.ietf.org/id-info/checklist.html>, every I-D that is submitted to the IESG for publication MUST contain an IANA Considerations section. The requirements for this section vary depending on what actions are required of the IANA. If there are no IANA considerations applicable to the document, then the IANA Considerations section will state that "This document has no IANA actions". Refer to the guidelines in [RFC8126] for more details. Why is this paragraph needed. This is true for EVERY I-D, Yang related or not. ** Section 3.8 Each normative YANG module MUST be registered in both … What is a “normative YANG module”? Is that one specified in the document? Recommend being clearer. ** Section 4.30.2 Designers of IANA-maintained modules MAY supply the full initial version of the module in a specification document that registers the module or only a script to be used (including by IANA) for generating the module (e.g., an XSLT stylesheet as in Appendix A of [RFC9108] or a Python script as in [RFC9645]). … Note: [Style] provides XSLT 1.0 stylesheets and other tools for translating IANA registries to YANG modules. The tools can be used to generate up-to-date revisions of an IANA-maintained module based upon the XML representation of an IANA registry. -- What is the relationship between the guidance that code may be supplied in an I-D on transforming a registry and this Note? -- Is this a note for IANA? Future I-D authors? ** Section 4.30.3 In addition to the IANA considerations in Section 3.8, the IANA Considerations Section of an RFC that includes an IANA-maintained module MUST provide the required instructions for IANA to automatically perform the maintenance of that IANA module. What is being directed by the phrase “automatically perform[ed]”? How is this different that other IANA guidance? _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
