<[email protected]> writes: > 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?
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]> 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. > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
