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 <[email protected]>
*Envoyé :* mercredi 4 juin 2025 17:41
*À :* BOUCADAIR Mohamed INNOV/NET <[email protected]>
*Cc :* NETMOD Group <[email protected]>; Ketan Talaulikar
<[email protected]>
*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, [email protected] 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 <[email protected]>
<mailto:[email protected]>
*Envoyé :* mercredi 4 juin 2025 14:17
*À :* Ketan Talaulikar <[email protected]>
<mailto:[email protected]>; BOUCADAIR Mohamed INNOV/NET
<[email protected]> <mailto:[email protected]>
*Cc :* NETMOD Group <[email protected]> <mailto:[email protected]>
*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 <[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]
____________________________________________________________________________________________________________
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.
