Subject: Re: [netmod] TR: New Version Notification for draft-boucadair-netmod-iana-registries-00.txt

From: Qin Wu <[email-masked]>
Date: Thu, 24 Mar 2022 11:23:39 +0000

>-----邮件原件-----
>发件人: netmod [mailto:[email-masked]] 代表 Jürgen Sch?nw?lder
>发送时间: 2022年3月24日 18:56
>收件人: [email-masked]
>抄送: [email-masked]
>主题: 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-masked] 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-FptdNxMWFgSHiSjbwGc6tM/
both seems to work.

>An enum implies that allocations can only be done by updating the module defining the enum. If a WG goes for an enum because of efficiency concerns, then the WG accepts that new allocations require an update of the module defining the enum.  If you
>want multiple parties to allocate values, then the price is the overhead of using identities.

>The good old middle ground are numbers spaces where some of the space is allocated for distributed allocations (and sometimes these allocations than include things like enterprise IDs to reduce the likelyhood for collisions) but then the YANG equivalent 
>for this is not just a plain enum.

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

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

---

From: <[email-masked]>
Date: Thu, 24 Mar 2022 11:46:58 +0000

Re-,

Agree with Qin. This is one of the usual comments from yangdoctors. 

The proposed clarification in draft-boucadair-netmod-iana-registries makes explicit that, for IANA-maintained modules, designers should make a decision based solely on their specific context. 

Cheers,
Med

> -----Message d'origine-----
> De : Qin Wu <[email-masked]>
> Envoyé : jeudi 24 mars 2022 12:24
> À : Jürgen Schönwälder <[email-masked]>; BOUCADAIR
> Mohamed INNOV/NET <[email-masked]>
> Cc : [email-masked]
> Objet : RE: [netmod] TR: New Version Notification for draft-boucadair-
> netmod-iana-registries-00.txt
> 
> >-----邮件原件-----
> >主题: Re: [netmod] TR: New Version Notification for
> >draft-boucadair-netmod-iana-registries-00.txt
> 
> [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.

_________________________________________________________________________________________________________________________

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.

---

From: Jürgen Schönwälder <[email-masked]>
Date: Thu, 24 Mar 2022 12:52:01 +0100

> https://mailarchive.ietf.org/arch/msg/netmod/AILS-FptdNxMWFgSHiSjbwGc6tM/

I am writing about IANA maintained modules, not about why one should
use IANA maintained modules.

/js

---

From: <[email-masked]>
Date: Fri, 25 Mar 2022 06:36:09 +0000

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

> De : Jürgen Schönwälder <[email-masked]>
> Envoyé : jeudi 24 mars 2022 12:52
> À : Qin Wu <[email-masked]>
> Cc : BOUCADAIR Mohamed INNOV/NET <[email-masked]>;
> [email-masked]
> Objet : Re: [netmod] TR: New Version Notification for draft-boucadair-
> > >> > It seems that later on you are actually changing what RFC 8407
> > >> > says although I am not sure I understand the reasoning. RFC 8407
> > >> > 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.
> > >>
> > [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.
> I am writing about IANA maintained modules, not about why one should use
> IANA maintained modules.
> 
> /js
> 
> --

---

From: Jürgen Schönwälder <[email-masked]>
Date: Fri, 25 Mar 2022 08:15:11 +0100

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

---

From: <[email-masked]>
Date: Fri, 25 Mar 2022 07:49:42 +0000

Hi Jürgen, 

Please see inline. 

Cheers,
Med

> Envoyé : vendredi 25 mars 2022 08:15
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> Cc : Qin Wu <[email-masked]>; [email-masked]

[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".
> 
> 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
> 
> > > [email-masked] Objet : Re: [netmod] TR: New Version Notification
> > > for draft-boucadair- netmod-iana-registries-00.txt
> > >
> > > > >> > 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
> > > > >>    "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?
> > > >
> > > 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.
> > > > https://mailarchive.ietf.org/arch/msg/netmod/AILS-FptdNxMWFgSHiSjb
> > > > wGc6
> > > > tM/
> > > > both seems to work.
> > > >
> > >
> > ______________________________________________________________________
> > ___________________________________________________
> >
> > 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.

---

From: Jürgen Schönwälder <[email-masked]>
Date: Fri, 25 Mar 2022 09:01:28 +0100

> [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…

Adding an enum is always possible, regardless who "owns" the
module. Yes, it is process wise easier to add an enum to an IANA
maintained module than an IETF maintained module. But this has nothing
to do with the text in the RFC you believe needs an update.

/js

---

From: <[email-masked]>
Date: Fri, 25 Mar 2022 08:40:30 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : vendredi 25 mars 2022 09:01
> > [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.
> >
> 
> Adding an enum is always possible, regardless who "owns" the module.
> Yes, it is process wise easier to add an enum to an IANA maintained
> module than an IETF maintained module.

[Med] Glad to see that we agree on this. This is even important here as we are trying to keep IANA as the authoritative source for modules that echo an existing registry + generalize the use of yang as another "Available Format" for the registries. 

 But this has nothing to do with
> the text in the RFC you believe needs an update.

[Med] I trust what you are saying but I'm still not sure everyone has this interpretation. 

We may get rid of the update if we also think this falls under this text:  

   If the set of values is fixed and the data type contents are
                                 ^^^ 
   controlled by a single naming authority, then an enumeration data
   type SHOULD be used.

but "and" is problematic. "or" would better fit what we are discussing here.

---

From: Jürgen Schönwälder <[email-masked]>
Date: Fri, 25 Mar 2022 10:10:54 +0100

I guess I still fail to understand what the issue is. I do not
understand what needs changes and why or why "ownership" by IANA would
change any guidelines.

/js