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 <[email protected]> wrote: > From: [email protected] <[email protected]> > 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 <[email protected]> De la part de tom petch > > EnvoyΓ© : jeudi 15 septembre 2022 11:25 > > Γ : Henk Birkholz <[email protected]>; opsawg > > <[email protected]> > > Objet : Re: [OPSAWG] π WG Last Call for draft-ietf-opsawg-mud- > > tls-07 > > > > From: OPSAWG <[email protected]> on behalf of Henk Birkholz > > <[email protected]> > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > > OPSAWG mailing list > > [email protected] > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg >
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
