Hi all, FWIW, a new version that reflects the comments heard so far is available online:
URL: https://www.ietf.org/archive/id/draft-boucadair-netmod-iana-registries-01.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-01 Cheers, Med > -----Message d'origine----- > De : Jürgen Schönwälder <[email protected]> > Envoyé : jeudi 24 mars 2022 12:52 > À : Qin Wu <[email protected]> > Cc : BOUCADAIR Mohamed INNOV/NET <[email protected]>; > [email protected] > Objet : Re: [netmod] TR: New Version Notification for draft-boucadair- > netmod-iana-registries-00.txt > > On Thu, Mar 24, 2022 at 11:23:39AM +0000, Qin Wu wrote: > > >-----邮件原件----- > > >发件人: netmod [mailto:[email protected]] 代表 Jürgen > Sch?nw?lder > > >发送时间: 2022年3月24日 18:56 > > >收件人: [email protected] > > >抄送: [email protected] > > >主题: Re: [netmod] TR: New Version Notification for > > >draft-boucadair-netmod-iana-registries-00.txt > > > > >On Thu, Mar 24, 2022 at 10:44:42AM +0000, > [email protected] wrote: > > >> > 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. > > >> > > > > >But why do you think this statement of RFC 8407 needs any changes or > different interpretations? > > > > [Qin Wu] If my understanding is correct, Authors of document > > containing YANG data model face dilemma choices now, i.e.,whether > > 1.change enum into identities which avoid updating the module defining > the enum in the future 2. Or stick to use enum and separate all enum > types into IANA-Maintained YANG Modules, which also avoid updating the > module, in addition, another benefit is to make sure the same registry > maintenance for the module that get updated. > > For the second choice, here is one related discussion raised by Lada > > https://mailarchive.ietf.org/arch/msg/netmod/AILS-FptdNxMWFgSHiSjbwGc6 > > tM/ > > both seems to work. > > > > I am writing about IANA maintained modules, not about why one should use > IANA maintained modules. > > /js > > -- > 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
