Hi Lada, Thank you for the comments.
Pleases see inline. Cheers, Med > -----Message d'origine----- > De : Ladislav Lhotka <[email protected]> > Envoyé : vendredi 25 mars 2022 11:26 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; > [email protected] > Objet : Re: [netmod] TR: New Version Notification for draft-boucadair- > netmod-iana-registries-00.txt > > 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. [Med] The current text in 8407 seems to just reason about fixed values AND single maintainers. What I'm hearing from both you and Jurgen is that this is not an update. I won't make a fixation on that and will proceed with updating the text to reflect the interpretation you shared. Thank you. > > Identities could also be extremely useful if the registry entries are > organized hierarchically, possibly including multiple inheritance. [Med] Do you think we should include some text in the draft to call out this aspect? > > 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. > [Med] Thanks for the feedback. The proposed guideline is to let the designers be aware of both approaches, decide based on their specific context, and then include a justification for their choice. > 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. [Med] Agree. I will add a note about this. 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 > [Med] Will add a pointer to this repo. Thanks. > <[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 _________________________________________________________________________________________________________________________ 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
