[netmod] Re: YANG in EXP/INFO Documents (was RE: Ketan Talaulikar's Discuss on draft-ietf-netmod-rfc8407bis-25: (with DISCUSS and COMMENT)

[Benoit Claise <[e-mail]>]

Perfect Med.

That works.

Regards, Benoit


On 6/4/2025 5:10 PM, [e-mail] wrote:
>
> Re-,
>
> Thanks, Benoît. Very useful.
>
> =
>
> I believe the above text does the job. Why do we need to specify more 
> than the above?
> If we do, we would be inventing rules here, like "exp-ietf" :-(
> It's best too provide guidance only on Standards Tracks, while 
> everybody else can follow them if they want
> =
>
> I made the following in -26:
>
> OLD:
>
> These guidelines are intended to be used by authors and reviewers to
>
> improve the readability and interoperability of published YANG data
>
> models.
>
> NEW:
>
> These guidelines are intended to be used by authors and reviewers to
>
> improve the readability and interoperability of published YANG data
>
> models.  These guidelines can be used independent of the IETF
>
> publication stream or even by other organizations.
>
> Cheers,
>
> Med
>
> *De :*Benoit Claise <[e-mail]>
> *Envoyé :* mercredi 4 juin 2025 17:41
> *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> *Cc :* NETMOD Group <[e-mail]>; Ketan Talaulikar 
> <[e-mail]>
> *Objet :* Re: [netmod] Re: YANG in EXP/INFO Documents (was RE: Ketan 
> Talaulikar's Discuss on draft-ietf-netmod-rfc8407bis-25: (with DISCUSS 
> and COMMENT)
>
>
>
> Hi Med,
>
> On 6/4/2025 1:44 PM, [e-mail] wrote:
>
>     Hi Benoît,
>
>     Thanks for sharing your thoughts.
>
>     I would prefer to avoid the splitting-hair type of discussion :-),
>     but the situation is that the 8407 has many statements based on
>     the standards track vs. else. For example,
>
>     ==
>
>     *4 <https://datatracker.ietf.org/doc/html/rfc8407#section-4>**.
>     YANG Usage Guidelines*
>
>     Modules in IETF Standards Track specifications MUST comply with all
>
>     syntactic and semantic requirements of YANG 1.1 [RFC7950
>     <https://datatracker.ietf.org/doc/html/rfc7950>].
>
>     …
>
>     The following example URNs would be valid namespace statement values
>
>     for Standards Track modules:
>
>     urn:ietf:params:xml:ns:yang:ietf-netconf-partial-lock
>
>     urn:ietf:params:xml:ns:yang:ietf-netconf-state
>
>     urn:ietf:params:xml:ns:yang:ietf-netconf
>
>     Note that a different URN prefix string SHOULD be used for modules
>
>     that are not Standards Track.
>
>     …
>
>     ==
>
> I believe the above text does the job. Why do we need to specify more 
> than the above?
> If we do, we would be inventing rules here, like "exp-ietf" :-(
> It's best too provide guidance only on Standards Tracks, while 
> everybody else can follow them if they want
>
>     This discussion is not part of the scope we set for this bis, but
>     Ketan raised fair questions.
>
>     I’m still interested to hear cases where you think that a
>     “normative YANG” module makes sense in an Info spec.
>
> Actually, I don't want to have to be thinking about all the different 
> corner cases and come up with rules here ;-)
> I can guess that there will a good situation in the future for which 
> we don't want to write down the rules in stone now.
> I just made up examples:
> - what if I want a YANG module for NetFlow version 9 (RFC 3954) or 
> Sflow (RFC 3176), should this RFC be Informational?
> - what about the syslog YANG module, RFC 9742 based on RFC 3164? We 
> could say that it must "Informational" because the normative reference 
> RFC 3164 is informational... euh wait RFC 3164 is not even in the 
> references???
>
> It doesn't matter in the end, that's my point.
> What does matter to me is that we do NOT call the Sflow one 
> "inf-sflow" and that we don't have too rigid rules.
>
> I hope this helps.
>
> Regards, Benoit
>
>     Thanks.
>
>     Cheers,
>
>     Med
>
>     *De :*Benoit Claise <[e-mail]>
>     <mailto:[e-mail]>
>     *Envoyé :* mercredi 4 juin 2025 14:17
>     *À :* Ketan Talaulikar <[e-mail]>
>     <mailto:[e-mail]>; BOUCADAIR Mohamed INNOV/NET
>     <[e-mail]> <mailto:[e-mail]>
>     *Cc :* NETMOD Group <[e-mail]> <mailto:[e-mail]>
>     *Objet :* Re: [netmod] Re: YANG in EXP/INFO Documents (was RE:
>     Ketan Talaulikar's Discuss on draft-ietf-netmod-rfc8407bis-25:
>     (with DISCUSS and COMMENT)
>
>
>
>     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 <[e-mail]>
>         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.
>             Both will be synced if we conclude to go that path. /*
>
>             Cheers,
>
>             Med
>
>             *De :*Ketan Talaulikar <[e-mail]>
>             *Envoyé :* mercredi 4 juin 2025 10:00
>             *À :* BOUCADAIR Mohamed INNOV/NET
>             <[e-mail]>
>             *Cc :* Mahesh Jethanandani <[e-mail]>;
>             NETMOD Group <[e-mail]>
>             *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
>             <[e-mail]> 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 <[e-mail]>
>                 > Envoyé : mercredi 4 juin 2025 07:10
>                 > À : Ketan Talaulikar <[e-mail]>
>                 > Cc : The IESG <[e-mail]>; draft-ietf-netmod-
>                 > [e-mail]; NETMOD WG Chairs
>                 <[e-mail]>;
>                 > NETMOD Group <[e-mail]>; Kent Watsen
>                 <[e-mail] <mailto:[e-mail]>>
>                 > 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
>                 > <[e-mail]> 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 [e-mail]
>
>         To unsubscribe send an email [e-mail]
>
>     ____________________________________________________________________________________________________________
>
>     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.