Re: [OPSAWG] 🔔 WG Last Call for draft-ietf-opsawg-mud-tls-07

Thanks Tom and Med for the feedback. We will add a note that users should
visit the IANA URL with the Yang module. The new guidelines for the
IANA-maintained modules need to be discussed in the netmod WG (updating
RFC8216), till then, we will have to follow the existing guidelines as
other specifications.

Cheers,
-Tiru

On Fri, 16 Sept 2022 at 16:15, tom petch <ietfc@btconnect.com> wrote:

> From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
> Sent: 15 September 2022 12:35
>
> Hi Tom,
>
> This is a fair comment.
>
> There is currently no recommendation on whether the initial full
> IANA-maintained modules should (not) be included or whether "an
> IANA-maintained module should
> always be published on its own". Publishing the module in a separate
> document has the same issues as those that are called out in the last two
> sentences of the excerpt below from
> https://datatracker.ietf.org/doc/html/draft-boucadair-netmod-iana-registries-04;
> I don't think it is worth to be considered by the authors here:
>
> <tp>
> Well, I have a recommendation.  I think that the initial version of an
> IANA-maintained module should appear in an RFC on its own.  That RFC can
> then be classified as Historic after a brief pause.
>
> The initial version should be there so that we can see how we got to
> whereever we later get to.  Authors can, and do, add a note to the effect
> that users should visit the IANA website, and give a URL,  Such a note
> should always be present IMO.
>
> Tom Petch
>
>    Designers of IANA-maintained modules MAY supply the full initial
>    version of the module in a specification document that registers the
>    module or only a script to be used (including by IANA) for generating
>    the module (e.g., an XSLT stylesheet as in Appendix A of [RFC9108]).
>    When a script is used, the Internet-Draft that defines an IANA-
>    maintained module SHOULD include an appendix with the initial full
>    version of the module.  Including such an appendix in pre-RFC
>    versions is meant to assess the correctness of the outcome of the
>    supplied script.  The authors MUST include a note to the RFC Editor
>    requesting that the appendix be removed before publication as RFC.
>    Initial versions of IANA-maintained modules that are published in
>    RFCs may be misused despite the appropriate language to refer to the
>    IANA registry to retrieve the up-to-date module.  This is problematic
>    for interoperability, e.g., when values are deprecated or are
>    associated with a new meaning.
>
> As an alternative to the script mentioned above, I wonder whether the
> authors can simply include a note to the RFC Editor asking to remove the
> module from the RFC and replace it with a link to the IANA page with the
> module.
>
> That's said, I'm having troubles with the content of the IANA-maintained
> module itself because it does not reflect the content of the authoritative
> registries it refers to. Also, I'm not sure the current IANA instructions
> are unambiguous so that IANA can maintain the module.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : OPSAWG <opsawg-bounces@ietf.org> De la part de tom petch
> > Envoyé : jeudi 15 septembre 2022 11:25
> > À : Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; opsawg
> > <opsawg@ietf.org>
> > Objet : Re: [OPSAWG] 🔔 WG Last Call for draft-ietf-opsawg-mud-
> > tls-07
> >
> > From: OPSAWG <opsawg-bounces@ietf.org> on behalf of Henk Birkholz
> > <henk.birkholz@sit.fraunhofer.de>
> > Sent: 14 September 2022 15:07
> >
> > Dear OPSAWG members,
> >
> > this email starts a two week period for a Working Group Last Call
> > of
> >
> > > https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-
> > 07.html
> >
> > ending on Thursday, September 28th.
> >
> > The authors believe the Internet-Draft is ready for a WGLC and the
> > chairs agree. The draft has been discussed visibly at IETF 114 and
> > review feedback has been incorporated in -07.
> >
> > Please send your comments to the list and your assessment of
> > whether or not it is ready to proceed to publication before
> > September 28th.
> >
> > <tp>
> > Not Ready.
> >
> > This I-D contains a YANG module for IANA to maintain along with
> > YANG modules and other data which are not.  I think that this
> > approach is always wrong.  The two sets of material have different
> > life cycles.  The IANA-maintained module is effectively obsolete
> > as soon as the RFC is published since the contents are then
> > maintained by IANA; anyone seeing the module in the RFC will be
> > looking at obsolete - sooner or later - material.  Users should
> > always be looking at the IANA website.  There is no way to tell
> > users this in the published status of an RFC.
> >
> > The remaining material in the I-D is likely to be updated over
> > time and then the authors have a choice of two bad approaches.
> > They can cut out the IANA-maintained module in which case the new
> > document sort of obsoletes the old one but not quite and a lot
> > more editing is needed; or they can republish the IANA-maintained
> > module which by then will have been obsolete for some time and
> > almost certainly wrong.  Hence an IANA-maintained module should
> > always be published on its own.
> >
> > Tom Petch
> >
> > For the OPSAWG co-chairs,
> >
> > Henk
> >
> > _______________________________________________
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
> > _______________________________________________
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>