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