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 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]> 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 <[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] <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]> 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 [email protected]
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
