I am jumping into the middle of a discussion, but I do agree that some of the questions raised by Ketan merit a debate.
> On Jun 2, 2025, at 11:03 PM, Ketan Talaulikar via Datatracker > <[email protected]> wrote: > > 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. As far as I understand, an experimental draft can define a protocol normatively using key words from RFC 2119. Similarly, a YANG module should be allowed to be normatively defined in a experimental draft. What I am not clear on is the follow-on question. Are you asking if a YANG module in an experimental draft can augment a YANG module in a PS? My take is that, it should be allowed. > > 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. Our experience with these guidelines is that they seem to undergo changes faster than a -bis document can be published. So while this -bis document captures a snapshot, it will almost be obsolete by the time this document is published. Having a (stable) link to the wiki allows us to keep the guidelines updated based on WG consensus. > > 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." ? The title of the document is “Guidelines for Authors and Reviewers of Documents Containing YANG models”. > > 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? I agree, even though it was cited normatively in RFC8407. > > 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? In hindsight, I would have recommended saying that the “deprecated” status should be maintained for one release, before marking it as “obsolete” regardless of a time period. > > 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? In addition to what Med has cited, the same guideline applies to experimental and informational documents. Thanks. > > 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] Mahesh Jethanandani [email protected] _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
