Hi Andy, Thank you for sharing the feedback.
For the paragraph you quoted, I removed the normative language from the first sentence. The other parts of that paragraph are useful as they call an important aspect that is only supported with identities + the guideline to document the reasoning. Will keep that text. Thank you. Cheers, Med De : Andy Bierman <[email protected]> Envoyé : lundi 28 mars 2022 20:05 À : BOUCADAIR Mohamed INNOV/NET <[email protected]> Cc : Ladislav Lhotka <[email protected]>; Jürgen Schönwälder <[email protected]>; [email protected] Objet : Re: [netmod] TR: New Version Notification for draft-boucadair-netmod-iana-registries-00.txt 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> > Envoyé : vendredi 25 mars 2022 15:04 > À : BOUCADAIR Mohamed INNOV/NET > <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]> > Objet : RE: [netmod] TR: New Version Notification for draft-boucadair- > netmod-iana-registries-00.txt > > <[email protected]<mailto:[email protected]>> writes: > > > Hi Lada, > > > > Thank you for the comments. > > > > Pleases see inline. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Ladislav Lhotka > >> <[email protected]<mailto:[email protected]>> Envoyé : vendredi > >> 25 > >> mars 2022 11:26 À : BOUCADAIR Mohamed INNOV/NET > >> <[email protected]<mailto:[email protected]>>; > >> [email protected]<mailto:[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? > > 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 > > > > >> <[email protected]<mailto:[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 > >> > _________________________________________________________________________________________________________________________ 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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod _________________________________________________________________________________________________________________________ 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
