From: mohamed.boucad...@orange.com <mohamed.boucad...@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-boun...@ietf.org> De la part de tom petch > EnvoyΓ© : jeudi 15 septembre 2022 11:25 > Γ : Henk Birkholz <henk.birkh...@sit.fraunhofer.de>; opsawg > <opsawg@ietf.org> > Objet : Re: [OPSAWG] π WG Last Call for draft-ietf-opsawg-mud- > tls-07 > > From: OPSAWG <opsawg-boun...@ietf.org> on behalf of Henk Birkholz > <henk.birkh...@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
