Hi Roman, Thanks for the review. The changes can be tracked at: https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/roman-review/draft-ietf-netmod-rfc8407bis.txt
Please see more context inline. Cheers, Med (as editor) > -----Message d'origine----- > De : Roman Danyliw via Datatracker <[email protected]> > Envoyé : lundi 2 juin 2025 22:47 > À : The IESG <[email protected]> > Cc : [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected] > Objet : Roman Danyliw's No Objection on draft-ietf-netmod- > rfc8407bis-25: (with COMMENT) > > > 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.) > > > ------------------------------------------------------------------- > 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: [Med] ... and even since draft-ietf-netmod-yang-usage-00 (which become rfc6087#section-3) :-) > > -- Why are requirement set for all I-Ds being repeated here? This > would be > true for any document, on a YANG topic or not. [Med] when linking the text you quoted with the previous one: YANG modules under review are likely to be contained in Internet- Drafts (I-Ds). This is about reminding authors/reviewers that how to write an I-D is not repeated here but go and look at [ID-Guidelines] for these matters. Only YANG specific matters will be included. Reworded to better reflect this. > > -- Versioning: which exact version of each page is mandatory to > implement? Is > it every future version? [Med] not sure to get your comment. > > -- Why is some other clarifying guidance about minting RFCs not > include - e.g.,..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. [Med] These are listed because some are exclusive to YANG while other include YANG-specific guidance. Reworded accordindgly. > > 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 > 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)? [Med] Some examples are provided in 4.23.3/1 (e.g., temporary non-NMDA version). Any deviation has to be called out in the main document per the following: Designers SHOULD describe and justify any NMDA exceptions in detail, such as the use of separate subtrees and/or separate leafs. The "description" statements for both the configuration and the operational state SHOULD be used for this purpose. However, there is no value to list every exception in the introduction but only insist on the main ones. The old guidance in 8407 was to say in the abstract that a module is compliant with NMDA, but given the following: YANG modules SHOULD be designed with the assumption that they will be used on servers supporting the operational state datastore. We changed the guidance to better focus on highlighting exceptions. > > ** Section 3.8 > In order to comply with IESG policy as set forth in > > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.ietf.org%2Fid- > info%2Fchecklist.html&data=05%7C02%7Cmohamed.boucadair%40orange.com > %7Cad2ef6a990294b98729308dda21694b3%7C90c7a20af34b40bfbc48b9253b6f5 > d20%7C0%7C0%7C638844940054939585%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI > ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=407mIWhf4RFz1MWZuOUXI2CztJp44guO > 4kCSoscP1Fo%3D&reserved=0>, 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. > [Med] I think we can delete that para. > ** 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. [Med] We do already have the following categories introduced in Section 3: CURRENT: There are three usage scenarios for YANG that can appear in an I-D or RFC: * normative module or submodule * example module or submodule * example YANG fragment not part of any module or submodule > > ** 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? [Med] This is aside note for authors for available tools that can be leveraged. > > -- Is this a note for IANA? Future I-D authors? [Med] This is for 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? > [Med] The challenge here is to avoid soliciting registrants as they may not even know about the existence of a YANG-maintained module. Mirroring a change to the registry in an IANA-maintained module may not be straightforward. The text right after dives on these instructions, including examples: - If the name in the IANA registry does not comply with the naming conventions listed in Section 4.3.1, the procedure MUST detail how IANA can generate legal identifiers from such a name. Specifically, if the name begins with a number, it is RECOMMENDED to spell out the number when used as an identifier. IANA should be provided with instructions to perform such task. For example, authors of a module with such identifiers have to indicate whether: ____________________________________________________________________________________________________________ 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]
