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.) 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? 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please find below some comments provided inline in the idnits output of v26 of this document. 234 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? 696 3.7. Security Considerations Section 698 Each specification that defines one or more modules MUST contain a 699 section that discusses security considerations relevant to those 700 modules. 702 Unless the modules comply with [RFC8791] or define YANG extensions 703 (e.g., [RFC7952]), the security section MUST be modeled after the 704 latest approved template (available at 705 <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. It does not seem appropriate to me to have a normative MUST reference to a webpage that is not updated via IETF consensus. 959 3.10. Validation Tools 961 All modules need to be validated before submission in an I-D. The 962 'pyang' YANG compiler is freely available from GitHub: 964 <https://github.com/mbj4668/pyang> <minor> Should these GitHub links not be moved into the informative reference section? 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" 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". 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. 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. 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" 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 ? <EoRv26> _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
