Hi Med, here are my comments:
YANG modules should be as tightly coupled as possible to the corresponding IANA registries. In an ideal world, YANG would simply have a statement for using a registry directly. This is, however, not possible in the current state of affairs. In particular, a separate module mirroring an IANA registry is almost always needed. Identities versus typedefs/enumerations: I think the text in sec. 4.11.1 of RFC 8407 applies to IANA registries as well. I would only add that identities are preferable if *distributed* extensibility is needed, i.e. if different parties are expected to define public and long-living entries on their own. Identities could also be extremely useful if the registry entries are organized hierarchically, possibly including multiple inheritance. One caveat regarding identities: for reasons that are unclear to me, YANG requires identity names (unlike enums) to be identifiers. That's why it is not possible to use identities without workarounds e.g. for Media Types, where it would IMO make a lot of sense. Last paragraph in sec. 3: "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 by IANA for generating the module (e.g., an XSLT 1.0 stylesheet in Appendix A of [RFC9108])." The first option turned out to be no-go in the DNSOP WG during the preparation of RFC 9108. The main objection was that, despite all warnings, implementors would blindly use the initial revision published in an RFC even after some entries become deprecated and might be potentially dangerous. It was thus proposed to e.g. keep the initial module revision only in the I-D stage and ask RFC Editor to delete it before publishing it as an RFC. Eventually, the XSLT stylesheet as a template for the initial module revision was acceptable to everyone and worked very well with IANA, too. Another advantage of the XSLT-based solution is that it allows for generating an always up-to-date revision of the YANG module from the online XML representation of the IANA registry. As a proof of concept, I prepared XSLT stylesheets for a dozen or so registries [1]. Although it works quite well, I do admit that it would be a drudgery to cover the full scope of existing IANA registries. Lada [1] https://github.com/llhotka/iana-yang <[email protected]> writes: > Hi all, > > We had in alto wg a discussion about consistent use of IANA-maintained > modules. This document provides some guidelines that I hope will ensure some > consistency about how we are interacting with IANA registries. The goal is > avoid transforming YANG modules (if not maintained by IANA) as another source > of information, which are likely to be out of sync. > > Some more details/context are provided in the I-D. > > Comments and suggestions are appreciated. > > Cheers, > Med > > -----Message d'origine----- > De : [email protected] <[email protected]> > Envoyé : jeudi 24 mars 2022 10:41 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]> > Objet : New Version Notification for > draft-boucadair-netmod-iana-registries-00.txt > > > A new version of I-D, draft-boucadair-netmod-iana-registries-00.txt > has been successfully submitted by Mohamed Boucadair and posted to the IETF > repository. > > Name: draft-boucadair-netmod-iana-registries > Revision: 00 > Title: Recommendations for Creating IANA-Maintained YANG > Modules > Document date: 2022-03-24 > Group: Individual Submission > Pages: 5 > URL: > https://www.ietf.org/archive/id/draft-boucadair-netmod-iana-registries-00.txt > Status: > https://datatracker.ietf.org/doc/draft-boucadair-netmod-iana-registries/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-boucadair-netmod-iana-registries > > > Abstract: > This document provides a set of guidelines for YANG module authors > related to the design of IANA-maintained modules. These guidelines > are meant to leverage existing IANA registries and use YANG as just > another format to present the content of these registries. > > This document updates RFC 8407. > > > > > > The IETF Secretariat > > > > _________________________________________________________________________________________________________________________ > > 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] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
