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]> 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 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]> > *Envoyé :* mercredi 4 juin 2025 10:00 > *À :* BOUCADAIR Mohamed INNOV/NET <[email protected]> > *Cc :* Mahesh Jethanandani <[email protected]>; NETMOD Group < > [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 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]> 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]> > > Envoyé : mercredi 4 juin 2025 07:10 > > À : Ketan Talaulikar <[email protected]> > > Cc : The IESG <[email protected]>; draft-ietf-netmod- > > [email protected]; NETMOD WG Chairs <[email protected]>; > > NETMOD Group <[email protected]>; Kent Watsen <[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]> 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] To unsubscribe send an email to [email protected]
