Hi Jürgen, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Jürgen Schönwälder <[email protected]> > Envoyé : vendredi 25 mars 2022 08:15 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]> > Cc : Qin Wu <[email protected]>; [email protected] > Objet : Re: [netmod] TR: New Version Notification for draft-boucadair- > netmod-iana-registries-00.txt > > Dear Med, > > I still do not understand the meaning of this text: > > For IANA-maintained modules, this recommendation takes precedence > over the behavior specified in Section 4.11.1 of [RFC8407] because > the extensibility concern is not applicable for such modules. > > I fail to see why the extensibility aspects discussed in Section > 4.11.1 of [RFC8407] are not applicable to IANA modules. Also note that > Section 4.11.1 of [RFC8407] is about the choice between an enumeration > and identities. Your text says: > > An IANA-maintained module may use identities (e.g., [RFC8675]) or > typedefs (e.g., [RFC9108]). [Med] aah, I see your concern. Sorry. The text should be more clear and say the following: An IANA-maintained module may use identities (e.g., [RFC8675]) or typedefs with enumeration type (e.g., [RFC9108]). or just An IANA-maintained module may use identities (e.g., [RFC8675]) or enumerations (e.g., [RFC9108]). > > Note that enumerations and intentityrefs are both base types. To me, it > does not make sense to compare identities against typedefs (a general > mechanism to give a derived type a name). The quoted DOTS example is > also about "enumerations" vs "identities" and not about "identities" vs > "typedefs". > > Anyway, my main point is that I do not see that the extensibility > implications of enumerations and identities change just because a module > is owned by IANA. Allocating a new enum requires an update of the module > defining the enum, i.e., allocation is centralized. [Med] The point is that adding a new enum is possible. The extensibility concern with enums we used to have for non IANA-maintained modules does not apply. I agree that identities are more flexible. That’s why the suggested text requires a justification text to motivate the design choice. > Identities do not require that a central module is updated to allocate a > new value, i.e., vendors can independently allocate values. This > fundamental difference does not change just because a module is owned by > IANA. > > /js > > On Fri, Mar 25, 2022 at 06:36:09AM +0000, [email protected] > wrote: > > 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-FptdNxMWFgSHiSjb > > > > wGc6 > > > > 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. > > > > -- > 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
