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

From: <[email-masked]>
Date: Thu, 24 Mar 2022 09:47:16 +0000

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 : [email-masked] <[email-masked]> 
Envoyé : jeudi 24 mars 2022 10:41
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
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.

---

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

Hi,

the document says that it updates RFC 8407. 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. I like the
recommendation given in other places of being explicit about what
"updates" means.

OLD

NEW

   This document updates RFC 8407 by providing additional guidelines
   for IANA maintained modules. It does not change anything written
   in RFC 8407.

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.

/js

PS: I liked the word 'inexorability' but I am not sure that making me
    smile was the intention of the authors. ;-)

On Thu, Mar 24, 2022 at 09:47:16AM +0000, [email-masked] wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> 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/>

---

From: <[email-masked]>
Date: Thu, 24 Mar 2022 10:44:42 +0000

Hi Jürgen, 

Thank you for the feedback. 

Please see inline. 

Cheers,
Med

> De : Jürgen Schönwälder <[email-masked]>
> Envoyé : jeudi 24 mars 2022 11:27
> Cc : [email-masked]
> 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
> 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

[Med] Agree. 

>    for IANA maintained modules. It does not change anything written

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

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

>     smile was the intention of the authors. ;-)

[Med] :-)

> > 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.
> >
> > De : [email-masked] <[email-masked]> Envoyé :
> > jeudi 24 mars 2022 10:41 À : BOUCADAIR Mohamed INNOV/NET
> > <[email-masked]> Objet : New Version Notification for
> > draft-boucadair-netmod-iana-registries-00.txt
> >
> >
> > ______________________________________________________________________
> > ___________________________________________________
> >
> > 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: Thu, 24 Mar 2022 11:56:07 +0100

>    "identityref" data type SHOULD be used instead of an enumeration or

But why do you think this statement of RFC 8407 needs any changes or
different interpretations? 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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 25 Mar 2022 11:26:17 +0100

Hi Med,

here are my comments:

YANG modules should be as tightly coupled as possible to the corresponding IANA registries. In an ideal world, YANG would simply have a statement for using a registry directly. This is, however, not possible in the current state of affairs.

In particular, a separate module mirroring an IANA registry is almost always needed.

Identities versus typedefs/enumerations: I think the text in sec. 4.11.1 of RFC 8407 applies to IANA registries as well. I would only add that identities are preferable if *distributed* extensibility is needed, i.e. if different parties are expected to define public and long-living entries on their own.

Identities could also be extremely useful if the registry entries are organized hierarchically, possibly including multiple inheritance. 

One caveat regarding identities: for reasons that are unclear to me, YANG requires identity names (unlike enums) to be identifiers. That's why it is not possible to use identities without workarounds e.g. for Media Types, where it would IMO make a lot of sense.

Last paragraph in sec. 3:

   "Designers of IANA-maintained modules MAY supply the full Initial
   version of the module in a specification document that registers the
   module or only a script to be used by IANA for generating the module
   (e.g., an XSLT 1.0 stylesheet in Appendix A of [RFC9108])."

The first option turned out to be no-go in the DNSOP WG during the preparation of RFC 9108. The main objection was that, despite all warnings, implementors would blindly use the initial revision published in an RFC even after some entries become deprecated and might be potentially dangerous. It was thus proposed to e.g. keep the initial module revision only in the I-D stage and ask RFC Editor to delete it before publishing it as an RFC. Eventually, the XSLT stylesheet as a template for the initial module revision was acceptable to everyone and worked very well with IANA, too.

Another advantage of the XSLT-based solution is that it allows for generating an always up-to-date revision of the YANG module from the online XML representation of the IANA registry. As a proof of concept, I prepared XSLT stylesheets for a dozen or so registries [1]. Although it works quite well, I do admit that it would be a drudgery to cover the full scope of existing IANA registries.

Lada

[1] https://github.com/llhotka/iana-yang

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

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

Thanks Lada,

this is useful input I think.

Another thing that we experienced in some corners of the IETF is that
IANA registries are often tied to specific protocols and it is
sometimes tempting to reuse a registry for a sligthly different
purpose. This can cause problems down the road when for example
definitions stop to make sense for the protocol the registry was
created for (i.e., they should move to deprecated or obsolete) but
other uses of the registry would still need the definition.

This is not really an YANG specific issue but more a general issue
whenever people try to reuse existing registries. If there are many
uses of a given registry, you may end up with many (sometimes
overlapping) definitions out of which only a subset make really sense
for a given use case. In other words, generalizing the use of an
existing registry beyonds its original scope can cause serious
problems down the road. Again, this is not really YANG specific, but
it has shown up with YANGified registries.

/js

---

From: <[email-masked]>
Date: Fri, 25 Mar 2022 10:45:26 +0000

Hi Lada, 

Thank you for the comments. 

Pleases see inline. 

Cheers,
Med

> De : Ladislav Lhotka <[email-masked]>
> Envoyé : vendredi 25 mars 2022 11:26
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>;
> [email-masked]
> YANG modules should be as tightly coupled as possible to the
> corresponding IANA registries. In an ideal world, YANG would simply have
> a statement for using a registry directly. This is, however, not
> possible in the current state of affairs.
> 
> Identities versus typedefs/enumerations: I think the text in sec. 4.11.1
> of RFC 8407 applies to IANA registries as well. I would only add that
> identities are preferable if *distributed* extensibility is needed, i.e.
> if different parties are expected to define public and long-living
> entries on their own.

[Med] The current text in 8407 seems to just reason about fixed values AND single maintainers. What I'm hearing from both you and Jurgen is that this is not an update. I won't make a fixation on that and will proceed with updating the text to reflect the interpretation you shared. Thank you.  

> 
> Identities could also be extremely useful if the registry entries are
> organized hierarchically, possibly including multiple inheritance.

[Med] Do you think we should include some text in the draft to call out this aspect?

> 
> One caveat regarding identities: for reasons that are unclear to me,
> YANG requires identity names (unlike enums) to be identifiers. That's
> why it is not possible to use identities without workarounds e.g. for
> Media Types, where it would IMO make a lot of sense.
> 
> The first option turned out to be no-go in the DNSOP WG during the
> preparation of RFC 9108. The main objection was that, despite all
> warnings, implementors would blindly use the initial revision published
> in an RFC even after some entries become deprecated and might be
> potentially dangerous. It was thus proposed to e.g. keep the initial
> module revision only in the I-D stage and ask RFC Editor to delete it
> before publishing it as an RFC. Eventually, the XSLT stylesheet as a
> template for the initial module revision was acceptable to everyone and
> worked very well with IANA, too.
> 

[Med] Thanks for the feedback. The proposed guideline is to let the designers be aware of both approaches, decide based on their specific context, and then include a justification for their choice.

> Another advantage of the XSLT-based solution is that it allows for
> generating an always up-to-date revision of the YANG module from the
> online XML representation of the IANA registry.

[Med] Agree. I will add a note about this. 

 As a proof of concept, I
> prepared XSLT stylesheets for a dozen or so registries [1]. Although it
> works quite well, I do admit that it would be a drudgery to cover the
> full scope of existing IANA registries.
> 
> Lada
> 

[Med] Will add a pointer to this repo. Thanks.

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 25 Mar 2022 15:03:55 +0100

<[email-masked]> writes:

> [Med] The current text in 8407 seems to just reason about fixed
> values AND single maintainers. What I'm hearing from both you and
> Jurgen is that this is not an update. I won't make a fixation on
> that and will proceed with updating the text to reflect the
> interpretation you shared. Thank you.
>
>> 

Possibly, this is something that enumerations cannot model.
> [Med] Thanks for the feedback. The proposed guideline is to let the designers be aware of both approaches, decide based on their specific context, and then include a justification for their choice.

Yes, I suspect that different WGs may have different opinions on this.

> [Med] Will add a pointer to this repo. Thanks.

Thanks, Lada

---

From: <[email-masked]>
Date: Fri, 25 Mar 2022 15:03:59 +0000

Re-,

Thanks, Lada. 

I updated the draft accordingly + reflected the interpretation shared by Jürgen.

URL:            https://www.ietf.org/archive/id/draft-boucadair-netmod-iana-registries-02.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-02

Cheers,
Med

> Envoyé : vendredi 25 mars 2022 15:04
> Objet : RE: [netmod] TR: New Version Notification for draft-boucadair-
> >> De : Ladislav Lhotka <[email-masked]> Envoyé : vendredi 25
> >> mars 2022 11:26 À : BOUCADAIR Mohamed INNOV/NET
> >> <[email-masked]>; [email-masked] Objet : Re: [netmod]
> >> TR: New Version Notification for draft-boucadair-
> >> corresponding IANA registries. In an ideal world, YANG would simply
> >> have a statement for using a registry directly. This is, however, not
> >> Identities versus typedefs/enumerations: I think the text in sec.
> >> 4.11.1 of RFC 8407 applies to IANA registries as well. I would only
> >> add that identities are preferable if *distributed* extensibility is
> needed, i.e.
> > [Med] The current text in 8407 seems to just reason about fixed values
> > AND single maintainers. What I'm hearing from both you and Jurgen is
> > that this is not an update. I won't make a fixation on that and will
> > proceed with updating the text to reflect the interpretation you
> > shared. Thank you.
> >
> >>
> >> warnings, implementors would blindly use the initial revision
> >> published in an RFC even after some entries become deprecated and
> >> might be potentially dangerous. It was thus proposed to e.g. keep the
> >> initial module revision only in the I-D stage and ask RFC Editor to
> >> delete it before publishing it as an RFC. Eventually, the XSLT
> >> stylesheet as a template for the initial module revision was
> >> acceptable to everyone and worked very well with IANA, too.
> >>
> >
> > [Med] Thanks for the feedback. The proposed guideline is to let the
> designers be aware of both approaches, decide based on their specific
> context, and then include a justification for their choice.
> 
> >> prepared XSLT stylesheets for a dozen or so registries [1]. Although
> >> it works quite well, I do admit that it would be a drudgery to cover
> >> the full scope of existing IANA registries.
> >>
> >> Lada
> >>
> >> 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.
> >> >

---

From: tom petch <[email-masked]>
Date: Mon, 28 Mar 2022 10:37:55 +0000

From: netmod <[email-masked]> on behalf of Jürgen Schönwälder <[email-masked]>
Sent: 25 March 2022 10:37

Thanks Lada,

<tp>

I just fell over a twist to this.  There is an IANA-maintained module of address family as enumerations.  bgp-model reinvents part of this as YANG identity and at least one other WG has imported the bgp-model version into its work.

I have queried this on the IDR list but can imagine the response I will get, along the lines of the issues in this thread:-(

Tom Petch

/js

---

From: <[email-masked]>
Date: Mon, 28 Mar 2022 12:55:23 +0000

Hi Tom, 

This part from 8407 is worth to be considered:

   If an appropriate derived type exists in any standard module, such as
   [RFC6991], then it SHOULD be used instead of defining a new derived
   type.

Unless I'm mistaken, the idr I-D defines a new identity afi-safi which is not **directly** defined in RFC8294. However, I do think their design is suboptimal as we can reuse the existing typedefs from RFC8294, but calling individually the afi and safi.

Note that RFC4760 says the following:

====
      Address Family Identifier (AFI):
         ....

         Presently defined values for the Address Family Identifier
         field are specified in the IANA's Address Family Numbers
         registry [IANA-AF].

and 

   As specified in this document, the MP_REACH_NLRI and MP_UNREACH_NLRI
   attributes contain the Subsequence Address Family Identifier (SAFI)
   field.  The SAFI name space is defined in this document.  The IANA
   registered and maintains values for the SAFI namespace as follows:
===

Freezing afi-safis in an IETF-maintained module is indeed an example of designs that draft-boucadair-netmod-iana-registries is trying to avoid.  

Cheers,
Med

> De : tom petch <[email-masked]>
> Envoyé : lundi 28 mars 2022 12:38
> [email-masked]; Jürgen Schönwälder <j.schoenwaelder@jacobs-
> university.de>
> IANA registries are often tied to specific protocols and it is sometimes
> tempting to reuse a registry for a sligthly different purpose. This can
> cause problems down the road when for example definitions stop to make
> sense for the protocol the registry was created for (i.e., they should
> move to deprecated or obsolete) but other uses of the registry would
> still need the definition.
> 
> whenever people try to reuse existing registries. If there are many uses
> of a given registry, you may end up with many (sometimes
> existing registry beyonds its original scope can cause serious problems
> down the road. Again, this is not really YANG specific, but it has shown
> up with YANGified registries.
> 
> <tp>
> 
> I just fell over a twist to this.  There is an IANA-maintained module of
> address family as enumerations.  bgp-model reinvents part of this as
> YANG identity and at least one other WG has imported the bgp-model
> version into its work.
> 
> I have queried this on the IDR list but can imagine the response I will
> get, along the lines of the issues in this thread:-(
> 
> Tom Petch
> 
> /js
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Mar 2022 11:05:19 -0700

Hi,

I read the -02 draft.
It does not conflict with RFC 8407.
I don't think sec 3, para 3 is really needed, but the guideline to document
the
reasoning behind using enum vs. identity is more relevant for IANA modules
than other modules.

Andy

On Fri, Mar 25, 2022 at 8:05 AM <[email-masked]> wrote:

> URL:
> https://www.ietf.org/archive/id/draft-boucadair-netmod-iana-registries-02.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-02
>
> Cheers,
> Med
>
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: <[email-masked]>
Date: Tue, 29 Mar 2022 05:44:18 +0000

Hi Andy,

Thank you for sharing the feedback.

For the paragraph you quoted, I removed the normative language from the first sentence.

The other parts of that paragraph are useful as they call an important aspect that is only supported with identities + the guideline to document the reasoning. Will keep that text. Thank you.

Cheers,
Med

De : Andy Bierman <[email-masked]>
Envoyé : lundi 28 mars 2022 20:05
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : Ladislav Lhotka <[email-masked]>; Jürgen Schönwälder <[email-masked]>; [email-masked]
Objet : Re: [netmod] TR: New Version Notification for draft-boucadair-netmod-iana-registries-00.txt

Hi,

I read the -02 draft.
It does not conflict with RFC 8407.
I don't think sec 3, para 3 is really needed, but the guideline to document the
reasoning behind using enum vs. identity is more relevant for IANA modules than other modules.

Andy

On Fri, Mar 25, 2022 at 8:05 AM <[email-masked]<mailto:[email-masked]>> wrote:
Re-,

Thanks, Lada.

Cheers,
Med

> De : Ladislav Lhotka <[email-masked]<mailto:[email-masked]>>
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]>> writes:
>
> > Hi Lada,
> >
> >> De : Ladislav Lhotka <[email-masked]<mailto:[email-masked]>> Envoyé : vendredi 25
> >> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> Objet : Re: [netmod]
> >> <[email-masked]<mailto:[email-masked]>> writes:
> >>
> >> > Hi all,
> >> >

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

---

From: <[email-masked]>
Date: Wed, 30 Mar 2022 08:04:22 +0000

Hi all,

FWIW, a new version with the change of a normative language is available at:

URL:            https://www.ietf.org/archive/id/draft-boucadair-netmod-iana-registries-03.txt

Diff:           https://www.ietf.org/rfcdiff?url2=draft-boucadair-netmod-iana-registries-03

Cheers,
Med

De : netmod <[email-masked]> De la part de [email-masked]
Envoyé : mardi 29 mars 2022 07:44
À : Andy Bierman <[email-masked]>
Cc : [email-masked]
Objet : Re: [netmod] TR: New Version Notification for draft-boucadair-netmod-iana-registries-00.txt

Hi Andy,

Cheers,
Med

De : Andy Bierman <[email-masked]<mailto:[email-masked]>>
Envoyé : lundi 28 mars 2022 20:05
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]<mailto:[email-masked]>>
Cc : Ladislav Lhotka <[email-masked]<mailto:[email-masked]>>; Jürgen Schönwälder <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Objet : Re: [netmod] TR: New Version Notification for draft-boucadair-netmod-iana-registries-00.txt

Hi,

I read the -02 draft.

Andy