Ketan Talaulikar has entered the following ballot position for draft-ietf-netmod-rfc8407bis-25: 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-rfc8407bis/ ---------------------------------------------------------------------- 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? 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please find below some comments provided inline in the idnits output of v25 of this document. 14 Abstract 16 This memo provides guidelines for authors and reviewers of <nit> s/memo/document 232 1.1. Changes Since RFC 8407 <minor> Since this is an exhaustive list of changes, can it be moved to the appendix section? First time (new) readers don't need to be bothered by this in the body of the RFC? 688 Unless the modules comply with [RFC8791] or define YANG extensions 689 (e.g., [RFC7952]), the security section MUST be modeled after the 690 latest approved template (available at 691 <https://wiki.ietf.org/group/ops/yang-security-guidelines>). <major> I am not sure if a wiki pointer is appropriate here. If it is a BCP level thing (beyond what is in 3.7.1 below) then please cover inline and remove the URL. 847 3.8. IANA Considerations Section 849 In order to comply with IESG policy as set forth in 850 <https://www.ietf.org/id-info/checklist.html>, every I-D that is 851 submitted to the IESG for publication MUST contain an IANA 852 Considerations section. The requirements for this section vary <major> The text gives an impression of referencing an IETF webpage (that is not updated via IETF consensus process) for a normative (MUST) directive. More problematic is that it is not scoped to YANG documents alone. Given that the URL is already present in the template, would there be an issue if the text were to simply say "Every I-D specifying a YANG module that is submitted to the IESG for publication MUST contain an IANA Considerations section." ? 884 3.8.2. Documents That Extend an Existing Namespace 886 It is possible to extend an existing namespace using a YANG submodule 887 that belongs to an existing module already administered by IANA. In 888 this case, the document containing the main module MUST be updated to 889 use the latest revision of the submodule. <major> What is exactly meant by "the document containing the main module MUST be updated"? That "document" has already been published as an RFC and that module is now being maintained by IANA on its website. Is this something that IANA needs to take care of by itself (I guess this is the case)? Or is it something that each new document doing such updates need to ask IANA to do this? Please clarify. 954 3.10. Validation Tools 956 All modules need to be validated before submission in an I-D. The 957 'pyang' YANG compiler is freely available from GitHub: 959 <https://github.com/mbj4668/pyang> <minor> Should these GitHub links not be moved into the informative reference section? 1053 4.1. Module Naming Conventions 1055 Normative modules contained in Standards Track documents MUST be 1056 named according to the guidelines in the IANA Considerations section 1057 of [RFC6020]. <major> The referenced RFC talks about "IETF stream documents" and not Standards Track documents alone. Could you please review all occurrences of reference to standards track document to review for correctness? They should also cover experimental and informational? 1605 4.7. YANG Definition Lifecycle Management 1607 The YANG status statement MUST be present within a definition if its 1608 value is "deprecated" or "obsolete". The status SHOULD NOT be 1609 changed from "current" directly to "obsolete". An object SHOULD be 1610 available for at least one year with a "deprecated" status before it 1611 is changed to "obsolete". <major> This at least one year limit - does it include time as an I-D or it is so that it can be changed by another RFC that gets published one year after the publication of the previous one. Can you please clarify? 1656 The "organization" statement MUST be present. If the module is 1657 contained in a document intended for IETF Standards Track status, 1658 then the organization SHOULD be the IETF working group (WG) chartered 1659 to write the document. For other standards organizations, a similar 1660 approach is also suggested. <major> This is another instance which talks only about standards track - what about the others? Also, not all standards track need to come via WG - some may be AD sponsored? Why not allow "IETF" alone for AD sponsored? 1824 Note that a different URN prefix string SHOULD be used for modules 1825 that are not Standards Track. The string SHOULD be selected 1826 according to the guidelines in [RFC7950]. <major> Which specific section of RFC7950 is being referenced here? And what is the guideline for experimental and informational track documents with YANG modules? 3154 The initial version of this YANG module is part of RFC IIII; see 3155 the RFC itself for full legal notices. <minor> This RFC IIII is used here and other places in the context of the IANA related aspects. The use is described in the following paragraph but can you also please cover in Section 2? 3196 4.30.3. Guidance for Writing the IANA Considerations for RFCs Defining 3197 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 ? 3257 * A note that unassigned or reserved values must not be present in 3258 the IANA-maintained module. <major> Is that a MUST NOT? There is a mix of lower and upper case normative language. Some consistency would be good. 3623 7.1. Normative References 3625 [ID-Guidelines] 3626 IETF, "Guidelines to Authors of Internet-Drafts", n.d., 3627 <https://authors.ietf.org/en/content-guidelines-overview>. <major> Is it normal for this to be a normative reference to an IETF webpage that is not updated via IETF consensus? Why not move it to informative references? <EoRv25> _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
