Hi Jürgen, Thank you for the feedback.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Jürgen Schönwälder <j.schoenwael...@jacobs-university.de> > Envoyé : jeudi 24 mars 2022 11:27 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> > Cc : netmod@ietf.org > Objet : Re: [netmod] TR: New Version Notification for draft-boucadair- > netmod-iana-registries-00.txt > > Hi, > > the document says that it updates RFC 8407. [Med] yes, it is more "extends" than "amends" (as per https://datatracker.ietf.org/doc/html/draft-kuehlewind-update-tag) except for one point I'm not sure yet about. See next please. I assume that the intended > semantic here is that this document augments what is being said in RFC > 8407 but it does not change anything said in RFC 8407. [Med] It relaxes a reco from 8407: This recommendation takes precedence over the behavior in Section 4.11.1 of [RFC8407] for IANA-maintained modules because the extensibility concern is not applicable for such modules. I like the > recommendation given in other places of being explicit about what > "updates" means. [Med] Agree. > > OLD > > This document updates RFC 8407. > > NEW > > This document updates RFC 8407 by providing additional guidelines > for IANA maintained modules. It does not change anything written > in RFC 8407. > [Med] Thanks. Went now for: This document updates RFC 8407 by providing additional guidelines for IANA-maintained modules. I may add or not the last sentence depending whether we consider that we are amending Section 4.11.1 of [RFC8407]. That is covered in your point below: > It seems that later on you are actually changing what RFC 8407 says > although I am not sure I understand the reasoning. RFC 8407 recommends > to use enums if there is a single naming authority allocating values and > thus ensuring uniqness of values. I am not sure in which sense the DOTS > decision to use enums is not inline with what RFC 8407 says. DOTS may > have decided to go with enums for space reasons and then this decision > implies that values have to be centrally allocated. Note that there are > IANA registries that allow distributed allocation of values and for > thoses cases the RFC 8407 recommendation to use identities still applies > I think. [Med] I was referring to this part: If extensibility of enumerated values is required, then the "identityref" data type SHOULD be used instead of an enumeration or other built-in type. > > /js > > PS: I liked the word 'inexorability' but I am not sure that making me > smile was the intention of the authors. ;-) [Med] :-) > > On Thu, Mar 24, 2022 at 09:47:16AM +0000, mohamed.boucad...@orange.com > wrote: > > 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 > > -- > 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/> _________________________________________________________________________________________________________________________ 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
