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]).

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.
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-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.
> 

-- 
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/>

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to