From: netmod <netmod-boun...@ietf.org> on behalf of Jürgen Schönwälder <j.schoenwael...@jacobs-university.de> Sent: 25 March 2022 10:37
Thanks Lada, this is useful input I think. Another thing that we experienced in some corners of the IETF is that IANA registries are often tied to specific protocols and it is sometimes tempting to reuse a registry for a sligthly different purpose. This can cause problems down the road when for example definitions stop to make sense for the protocol the registry was created for (i.e., they should move to deprecated or obsolete) but other uses of the registry would still need the definition. This is not really an YANG specific issue but more a general issue whenever people try to reuse existing registries. If there are many uses of a given registry, you may end up with many (sometimes overlapping) definitions out of which only a subset make really sense for a given use case. In other words, generalizing the use of an existing registry beyonds its original scope can cause serious problems down the road. Again, this is not really YANG specific, but it has shown up with YANGified registries. <tp> I just fell over a twist to this. There is an IANA-maintained module of address family as enumerations. bgp-model reinvents part of this as YANG identity and at least one other WG has imported the bgp-model version into its work. I have queried this on the IDR list but can imagine the response I will get, along the lines of the issues in this thread:-( Tom Petch /js On Fri, Mar 25, 2022 at 11:26:17AM +0100, Ladislav Lhotka wrote: > 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 > > <mohamed.boucad...@orange.com> 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 : internet-dra...@ietf.org <internet-dra...@ietf.org> > > Envoyé : jeudi 24 mars 2022 10:41 > > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> > > 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 > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
