Re-, Please see inline.
Cheers, Med (as editor) De : Ketan Talaulikar <[email protected]> Envoyé : mardi 3 juin 2025 13:34 À : BOUCADAIR Mohamed INNOV/NET <[email protected]> Cc : The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Objet : Re: Ketan Talaulikar's Discuss on draft-ietf-netmod-rfc8407bis-25: (with DISCUSS and COMMENT) Hi Med, Thanks for your quick response and sharing the diff from your github edit buffer. I understand that some of the points that I've raised are inherited from RFC 8407. This is a pretty significant and important document. Therefore, there are some things that need discussion/update even if they were coming from RFC 8407 to align with times. [Med] I’m flexible but we need to be careful to not diverge much from the scope set for the bis this time: https://datatracker.ietf.org/meeting/117/materials/slides-117-netmod-7-guidelines-for-authors-and-reviewers-of-documents-containing-yang-data-models-00 (slide 7) ;-) We need an iterative approach and clear scope for each round. Please check inline below for clarifications. Ones without response can be considered as addressed/closed and can be trimmed out in further replies. On Tue, Jun 3, 2025 at 2:27 PM <[email protected]<mailto:[email protected]>> wrote: Hi Ketan, Thanks for the review. The changes made so far 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/KTcomments/draft-ietf-netmod-rfc8407bis.txt. See more context inline. Cheers, Med (as editro) > -----Message d'origine----- > De : Ketan Talaulikar via Datatracker > <[email protected]<mailto:[email protected]>> > Envoyé : mardi 3 juin 2025 08:04 > À : The IESG <[email protected]<mailto:[email protected]>> > Cc : > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; > [email protected]<mailto:kent%[email protected]>; > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]> > Objet : Ketan Talaulikar's Discuss on draft-ietf-netmod-rfc8407bis- > 25: (with DISCUSS and COMMENT) > > 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.) > > > ------------------------------------------------------------------- > 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? [Med] YANG modules defined in the IETF so far are defined in PS documents, even when covering protocols that are in Info/Exp. An example is RFC9105. You may refer to https://mailarchive.ietf.org/arch/msg/opsawg/7E9g02ZwMt5z9PT1vgSai4kW42U/ or the discussion at the time in the IESG. KT> That email thread does not really cover my point. The email thread gives the position of an AD at that point of time. Four years down the line, we again have a couple of ADs discussing a somewhat similar point. What is needed is that the IETF consensus is captured in a BCP document. I believe this is the right BCP document to cover it. The key point is that a YANG module (independent of the underlying objects it manipulates) is about making two peers (client/server) interoperable. KT> I am not going to debate that point (yet). However, I will note that there have been recommendations made over the years to include YANG modules in the same document as the protocol features. So, the question then becomes: 1) If the document is considered experimental (or informational) in view of the protocol specifications/extensions in it, then should it (a) not include a YANG and that should be in separate standards track document, or (b) no YANG work should be done for anything experimental or informational, or (c) the document needs to be standard track because it has a YANG (as in the proverbial "tail wagging the dog"? - to not be taken literally). 2) Independent of (1), the authors and WG seem to have not all considered even the possibility of YANG being documented in IETF stream as Experimental or Informational while artifacts from other older RFCs (but not the predecessors of this BCP) generally refer to IETF Stream documents and not standard tracks. I would like to discuss and understand why so. Further, whatever is the reason should be captured in this document as it is after all the BCP for writing/reviewing YANG documents. [Med] My personal take on this is that there is no causality effect between the track of a base spec and its companion YANG module, especially when used for management purposes. I provided the example of 9105 on purpose to illustrate this (base=INFO, YANG=PS). I’m not aware of any YANG module that is published as Info or EXP to date. That’s said, there might be cases where publishing in the Info or Exp may make sense in the future but I don’t know those. It is difficult to create guidance for an hypothetical case. The preamble of Section 4 is clear about the intent usage of the spec. The following usage in Section 3 (inherited from 8407): CURRENT: There are three usage scenarios for YANG that can appear in an I-D or RFC: o normative module or submodule o example module or submodule o example YANG fragment not part of any module or submodule KT> I do not see how this even relates to the standard/experimental/informational tracks. Can you please explain? [Med] An example module is module which is provided for illustration purpose and is not registered within IANA, etc. Also, perhaps I do not fully understand what an "example module" is used for from reading this document - is it something different from or beyond say https://www.rfc-editor.org/rfc/rfc9127.html#appendix-A.1 ? [Med] That’s an example module. I ask this question since you bring up "example module" when I bring up experimental/informational documents. 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 [Med] OK, even if this was inherited from 8407 ;-) > > 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? [Med] This is a matter of taste, but more importantly follow the practice used in rfc8407 vs 6087. > > 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 > <major> I am not sure if a wiki pointer is appropriate here. [Med] This practice is implemented and followed since many years now (including RFC editor, etc.). We need a stable reference to maintain the template out of the RFC itself. A reason why the template is maintained here and not completely offloaded is that we received a request from the IETF trust that we addressed (this text is used outside the IETF). KT> First, I am happy that the template (as of the date of publishing this document) is going to be in the RFC itself (Appendix would have been better for my taste for all such templates - but I leave it to the authors/WG/AD). The problem is the normative MUST to reference something that is not going to be updated via the IETF Consensus process - my concern would be addressed by dropping that normative MUST. The document can even say that the template may be improved with community inputs and the latest version can be found at an URL that is placed as an informational reference. [Med] Not sure there is something broken in this process that is exercised since at least 2010. We need to trust the responsible ADs to do it right when major changes are to be made (consult with netmod, iesg, etc.). 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.ietf.org<http://www.ietf.org/>%2Fid- > info%2Fchecklist.html&data=05%7C02%7Cmohamed.boucadair%40orange.com<http://40orange.com/> > %7C9b04b9803c344846ae4908dda2646796%7C90c7a20af34b40bfbc48b9253b6f5 > d20%7C0%7C0%7C638845274308491793%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI > ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qLf%2Fz4Eu%2BzB2Lm7ZIQrn3DcE7ldb > eA5dZGnMvCj65RI%3D&reserved=0>, 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." > ? [Med] Even if this was in 8407/6087, removed that text. KT> Thanks. But please note that I had not asked for its removal and instead provided an alternative text. Tomorrow, even if something similar comes in 8126bis, it would have been helpful to retain the text mandating IANA considerations in this document as well since it is going to be referenced by YANG authors/reviewers. > > 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. [Med] This section is under "3.8. IANA Considerations Section" which covers considerations in a document that extends the existing namespace. KT> I am sorry, but it does not clarify. Could you please explain the intent here? Perhaps with an example? [Med] I meant this section about the content of IANA cons section of a specification that extends an existing namespace. > > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > github.com<http://github.com/>%2Fmbj4668%2Fpyang&data=05%7C02%7Cmohamed.boucadair%40ora > nge.com<http://nge.com/>%7C9b04b9803c344846ae4908dda2646796%7C90c7a20af34b40bfbc48b9 > 253b6f5d20%7C0%7C0%7C638845274308504790%7CUnknown%7CTWFpbGZsb3d8eyJ > FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW > FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IM3BY3o8Q2%2BUVR0WGUo0HXt > JhqWmnRYzrQQn1v0HCEs%3D&reserved=0> > > <minor> Should these GitHub links not be moved into the informative > reference > section? [Med] Preserved the use from 8407. > > 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? [Med] This part is untouched from 8407. The key part of the text you quoted is "normative modules". Other types (e.g., example modules) are not concerned to follow the full guidance. KT> I think you are missing my point. The following is the text from RFC6020: The module name prefix 'ietf-' is reserved for IETF stream documents [RFC4844<https://www.rfc-editor.org/rfc/rfc4844>], while the module name prefix 'irtf-' is reserved for IRTF stream documents. Modules published in other RFC streams MUST have a similar suitable prefix. Why is this document then narrowing it down only to Standards Track documents? Note, you are focussing on "normative modules", but I am discussing the document track which is AFAIK independent. > > 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? [Med] Idem as previous one, this is inherited from 8407. As clarified in that same section, the reasoning is vs. published module, which is defined as follows: o published: A stable release of a module or submodule. For example, the "Request for Comments" described in Section 2.1 of [RFC2026] is considered a stable publication. KT> That does not provide any clarity. The text should state clearly the procedure to deprecate and obsolete. This is something that perhaps gets exercise more often than what would be ideal, so it is important to cover it. [Med] Added « publication date » per a suggestion from Éric. > > 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? [Med] This is not excluded. This is covered as exception to the SHOULD. Added "Exceptions may be example modules, IANA-maintained modules, or modules contained in AD-sponsored documents." KT> My original question is not answered. And the newly proposed text raises further questions. The IANA maintained modules are also originated via IETF standards track document - so why should they be an exception? [Med] because IANA controls the registries! A YANG module is not more than another for to represent the content of a registry. The AD-sponsored documents can also be IETF standards track - here the only exception is that they don't have IETF WGs. What still remains uncovered is experimental and informational ... [Med] I don’t follow you here. The exception is in reference to ” SHOULD be the IETF working group”. There is no WG for AD-sponsored docs. > > 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? [Med] Updated to reference Section 5.3, where we have: XML namespaces for private modules are assigned by the organization owning the module without a central registry. Namespace URIs MUST be chosen so they cannot collide with standard or other enterprise namespaces -- for example, by using the enterprise or organization name in the namespace. KT> Thanks. But there is no guidance at that location for the namespace for experimental/information. There is a further redirection to https://www.rfc-editor.org/rfc/rfc6020#section-14 but that says "ietf-" is available for all of IETF stream and now this document is restricting it to standard track alone? The module name prefix 'ietf-' is reserved for IETF stream documents [RFC4844<https://www.rfc-editor.org/rfc/rfc4844>], while the module name prefix 'irtf-' is reserved for IRTF stream documents. Modules published in other RFC streams MUST have a similar suitable prefix. > > 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? [Med] Happily. Done. > > 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) [Med] There won't be any ;-) This is the beauty of IANA-maintained modules. KT> Exactly! But you should not be surprised that this may not be as commonly known. Therefore, adding a sentence in this document saying "there isn't anything to do" would help at least some folks like to point to during reviews. > 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. [Med] The note will be included in IANA consideration section. The current wording is consistent with the guidance fro that section at: https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/#inappropriate-uses-of-key-words KT> You are correct. I misread that part. Thanks, Ketan > > 3623 7.1. Normative References > > 3625 [ID-Guidelines] > 3626 IETF, "Guidelines to Authors of Internet- > Drafts", n.d., > 3627 > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > authors.ietf.org<http://authors.ietf.org/>%2Fen%2Fcontent-guidelines- > overview&data=05%7C02%7Cmohamed.boucadair%40orange.com<http://40orange.com/>%7C9b04b9803c > 344846ae4908dda2646796%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7 > C638845274308518244%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU > sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > 3D%7C0%7C%7C%7C&sdata=FQf7Fjalpe9gC57J1hzJvUkDGELGP9Mk2g4tioa%2BkPM > %3D&reserved=0>. > > <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? [Med] This is inherited from 8407. I think that we can move it around as we softened now the generic I-D guidance. > > <EoRv25> > > ____________________________________________________________________________________________________________ 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. ____________________________________________________________________________________________________________ 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]
