I am glad to see that the WG has quickly converged that the guidelines provided by rfc8407bis and RFC 8407 before that apply not just to documents that are on the Standards Track but also to experimental, informational, or BCP. I am also happy to see that Med has added a statement at the top to clarify it to that effect.
But as Ketan has pointed out in his comments, there are remnants of statements that sometimes contradict this new overall statement or just cause confusion. It would be best to just clean them so we are not back discussing this question. Here are some specific comments Ketan has provided: 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 <https://datatracker.ietf.org/doc/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 <https://datatracker.ietf.org/doc/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" Thanks. > On Jun 4, 2025, at 5:40 AM, Benoit Claise > <[email protected]> wrote: > > Hi Ketan, > > > On 6/4/2025 1:30 PM, Ketan Talaulikar wrote: >> Hi Benoit, >> >> Just to make sure that I understand your viewpoint here. Are you saying? >> >> 1) OK for the YANG modules developed by the IETF to be in any of the IETF >> Stream documents? (for the moment not going beyond IETF into other streams) > Yes. >> 2) OK for augments (which are YANG modules themselves) to YANG modules to be >> in any of the IETF Stream documents. > Yes. > > My rational: YANG @ IETF face bigger challenges (see the NEMOPS workshop, for > example) than trying to set stricter rules for its development > > KISS, Keep It Simple Simple ;-) > > Regards, Benoit >> >> Thanks, >> Ketan >> >> >> On Wed, Jun 4, 2025 at 5:47 PM Benoit Claise <[email protected] >> <mailto:[email protected]>> wrote: >> Dear all, >> >> This discussion about YANG module in EXP/INFO seems to me as a >> splitting-hair type of discussion. >> Starting from the very first question: "At a high-level, I would like to >> discuss and understand whether YANG model documents can be experimental or >> informational." >> My answer: No, a YANG module just happens to be in a PS/EXP/INFO document. >> Note: to find this related document, see www.yangcatalog.org >> <http://www.yangcatalog.org/> >> >> Let's not try to convey the subtle IETF differences between PS/EXP/INFO into >> the YANG modules themselves. >> And having "exp-ietf" is simply a bad idea. What if the experiment is >> successful, are we going to re-publish as "ietf"? It doesn't make sense from >> an API point of view. >> >> From there, the augmentation questions "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?" are >> irrelevant. >> >> Regards, Benoit >> >> On 6/4/2025 11:15 AM, Ketan Talaulikar wrote: >>> Hi Med, >>> >>> My individual preference (i.e., w/o my AD hat), would be to leave them >>> separate. That content seems more appropriate for a standards track >>> document and not this BCP. >>> >>> Thanks, >>> Ketan >>> >>> >>> On Wed, Jun 4, 2025 at 1:42 PM <[email protected] >>> <mailto:[email protected]>> wrote: >>> Re-, >>> >>> >>> Regarding a prefix of "exp-ietf" for experimental. That would be changing >>> what is in https://datatracker.ietf.org/doc/html/rfc6020#section-14 >>> <https://datatracker.ietf.org/doc/html/rfc6020#section-14> which allows for >>> "ieft-" for all of the IETF stream tracks. I would suggest starting that as >>> a separate conversation outside of this current document. >>> >>> [Med] FYI, we used to have updates to IANA cons in 6020 as part of the >>> 8407bis. These matters are covered now in >>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6020-iana-update-01 >>> >>> <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6020-iana-update-01>. >>> Both will be synced if we conclude to go that path. >>> >>> >>> Cheers, >>> >>> Med >>> >>> >>> De : Ketan Talaulikar <[email protected] >>> <mailto:[email protected]>> >>> Envoyé : mercredi 4 juin 2025 10:00 >>> À : BOUCADAIR Mohamed INNOV/NET <[email protected] >>> <mailto:[email protected]>> >>> Cc : Mahesh Jethanandani <[email protected] >>> <mailto:[email protected]>>; NETMOD Group <[email protected] >>> <mailto:[email protected]>> >>> Objet : Re: YANG in EXP/INFO Documents (was RE: [netmod] Ketan Talaulikar's >>> Discuss on draft-ietf-netmod-rfc8407bis-25: (with DISCUSS and COMMENT) >>> >>> >>> Hi Med and netmod WG, >>> >>> >>> I see a YANG module as adjunct to the feature that it enables operations >>> and management for. My view comes mostly from the routing and routing >>> protocols space. I realize that at various other levels of abstractions and >>> types of models, the views would be different. >>> >>> >>> Coming back to the application of YANG models for routing, I believe it >>> should follow the status of the feature. I am assuming that the IETF >>> strongly wants to encourage development of YANG modules to happen adjunct >>> (and preferably in the same document?) as the rest of the protocol spec. >>> >>> >>> I view this debate about standards/experimental/information more as a >>> distraction from the main purpose of this document >>> (draft-ietf-netmod-rfc8407bis) - which is guidelines for writing/reviewing >>> YANG modules (in the IETF?). >>> >>> >>> There will continue to be debates about the correct track of both the >>> protocol specs and their corresponding YANG modules. There is a great deal >>> of subjectivity and decisions are made by the WGs, ADs, IESG on a case by >>> case basis. Let it be so. I also want to try and impress that Experimental >>> specs are all not some weird stuff being produced (though opinions vary >>> widely from case to case basis). There are enough experiments (and even >>> things in informational documents) that have gone on to gain mainstream >>> industry relevance. >>> >>> >>> How about this document steers clear of that debate and instead focuses on >>> the modules themselves? How about we just say for all of the IETF stream >>> documents? That will address my concerns. >>> >>> >>> Regarding a prefix of "exp-ietf" for experimental. That would be changing >>> what is in https://datatracker.ietf.org/doc/html/rfc6020#section-14 >>> <https://datatracker.ietf.org/doc/html/rfc6020#section-14> which allows for >>> "ieft-" for all of the IETF stream tracks. I would suggest starting that as >>> a separate conversation outside of this current document. >>> >>> >>> Thanks, >>> >>> Ketan >>> >>> >>> >>> On Wed, Jun 4, 2025 at 1:04 PM <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi all, >>> (restricting the discussion to netmod, for now). >>> >>> I don't think that it makes sense to publish a normative YANG module in an >>> Informational RFC. Whether we care about interoperability or not. If we >>> care, and a normative YANG module is provided, publishing as Informational >>> should not be an option. >>> >>> I'm also not comfortable claiming that we can publish a "normative" YANG as >>> experimental (whatsoever that means), at least without cautions. Beyond >>> YANG, publishing as Exp has a meaning and implications (including >>> process-wise). For example, RFC2026 says: >>> >>> The "Experimental" designation typically denotes a specification that >>> is part of some research or development effort. Such a specification >>> is published for the general information of the Internet technical >>> community and as an archival record of the work, subject only to >>> ^^^^^^^^^^^^^^^^ >>> editorial considerations and to verification that there has been >>> ^^^^^^^^^^^^^^^^^^^^^^^^ >>> adequate coordination with the standards process (see below). An >>> Experimental specification may be the output of an organized Internet >>> research effort (e.g., a Research Group of the IRTF), an IETF Working >>> Group, or it may be an individual contribution. >>> >>> Of course, the guidance in 8407bis can be followed by authors for such >>> document, if they wish so. However, I don't think we need to have strong >>> expectations on that. For example, >>> * an experiment may have its own cycles and should not be subject, for >>> example, to the lifecycle constraints we impose for >>> deprecating/obsoleting/etc. >>> * a module in an exp spec may not need to be registered within IANA as an >>> experiment is in a limited domain and does not involve multiple >>> implementations. >>> * an experiment may be precisely about testing things that are not >>> compliant with guidance >>> >>> Another dimension is that publishing as Exp require adequate justification >>> why we can't publish as PS. For the specific case of YANG, the status of >>> the underlying technology should not be the only criteria here as we are >>> dealing with the interop between two peers independent of the objects they >>> manipulates. At least from where I sit, a >>> normative module can be defined as PS even if the underlying technology was >>> Info (e.g., RFC9105). >>> >>> Things may get complicated with the augmentations and leaking outside the >>> IETF. I think I would prefer making this change: >>> >>> OLD: >>> All normative YANG modules published by the >>> IETF MUST begin with the prefix "ietf-". >>> >>> NEW: >>> All normative YANG modules published in Standards Track documents by the >>> IETF MUST begin with the prefix "ietf-". YANG modules published in >>> Experimental >>> documents by the IETF MUST begin with the prefix "exp-ietf". >>> >>> (I prefer exp-ietf to ietf-exp) >>> >>> Please share your thoughts and suggestions. >>> >>> Cheers, >>> Med (as contributor) >>> >>> > -----Message d'origine----- >>> > De : Mahesh Jethanandani <[email protected] >>> > <mailto:[email protected]>> >>> > Envoyé : mercredi 4 juin 2025 07:10 >>> > À : Ketan Talaulikar <[email protected] >>> > <mailto:[email protected]>> >>> > Cc : The IESG <[email protected] <mailto:[email protected]>>; draft-ietf-netmod- >>> > [email protected] <mailto:[email protected]>; NETMOD WG Chairs >>> > <[email protected] <mailto:[email protected]>>; >>> > NETMOD Group <[email protected] <mailto:[email protected]>>; Kent Watsen >>> > <[email protected] <mailto:kent%[email protected]>> >>> > Objet : Re: [netmod] Ketan Talaulikar's Discuss on draft-ietf- >>> > netmod-rfc8407bis-25: (with DISCUSS and COMMENT) >>> > >>> > >>> > 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] <mailto:[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.) >>> > > >>> > > >>> > > ----------------------------------------------------------------- >>> > > 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. >>> > > >>> >>> ____________________________________________________________________________________________________________ >>> 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] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] >>> <mailto:[email protected]> >> > > _______________________________________________ > 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]
