Hi, I read the -02 draft. It does not conflict with RFC 8407. I don't think sec 3, para 3 is really needed, but the guideline to document the reasoning behind using enum vs. identity is more relevant for IANA modules than other modules.
Andy On Fri, Mar 25, 2022 at 8:05 AM <mohamed.boucad...@orange.com> wrote: > Re-, > > Thanks, Lada. > > I updated the draft accordingly + reflected the interpretation shared by > Jürgen. > > URL: > https://www.ietf.org/archive/id/draft-boucadair-netmod-iana-registries-02.txt > Status: > https://datatracker.ietf.org/doc/draft-boucadair-netmod-iana-registries/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-boucadair-netmod-iana-registries > Diff: > https://www.ietf.org/rfcdiff?url2=draft-boucadair-netmod-iana-registries-02 > > Cheers, > Med > > > -----Message d'origine----- > > De : Ladislav Lhotka <ladislav.lho...@nic.cz> > > Envoyé : vendredi 25 mars 2022 15:04 > > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; > > netmod@ietf.org > > Objet : RE: [netmod] TR: New Version Notification for draft-boucadair- > > netmod-iana-registries-00.txt > > > > <mohamed.boucad...@orange.com> writes: > > > > > Hi Lada, > > > > > > Thank you for the comments. > > > > > > Pleases see inline. > > > > > > Cheers, > > > Med > > > > > >> -----Message d'origine----- > > >> De : Ladislav Lhotka <ladislav.lho...@nic.cz> Envoyé : vendredi 25 > > >> mars 2022 11:26 À : BOUCADAIR Mohamed INNOV/NET > > >> <mohamed.boucad...@orange.com>; netmod@ietf.org 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? > > > > Possibly, this is something that enumerations cannot model. > > > > > >> > > >> 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. > > > > Yes, I suspect that different WGs may have different opinions on this. > > > > > > > >> 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. > > > > Thanks, Lada > > > > > > > >> <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 > > >> > > > > _________________________________________________________________________________________________________________________ > > 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 >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
