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

[Ladislav Lhotka]

Hi Med,

thanks for letting me know, it's nice to see that my somewhat crazy 
method still finds some uses.


Cheers, Lada

Dne 15. 03. 23 v 10:52 mohamed.boucad...@orange.com napsal(a):

Hi Lada,

FWIW, we exercised the use of the script when preparing 
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-extensions/. The source 
files can be seen at:
https://github.com/boucadair/enhanced-acl-netmod/tree/main/yang.

The use of the script is ACked in both the IANA module and also Section .

Cheers,
Med


-Message d'origine-
De : Ladislav Lhotka 
Envoyé : vendredi 25 mars 2022 15:04
À : BOUCADAIR Mohamed INNOV/NET ;
netmod@ietf.org
Objet : RE: [netmod] TR: New Version Notification for draft-
boucadair-netmod-iana-registries-00.txt

 writes:


...


  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



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


Thanks, Lada




_

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.



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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[mohamed.boucadair]

Hi Lada,

FWIW, we exercised the use of the script when preparing 
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-extensions/. The source 
files can be seen at: 
https://github.com/boucadair/enhanced-acl-netmod/tree/main/yang. 

The use of the script is ACked in both the IANA module and also Section . 

Cheers,
Med

> -Message d'origine-
> De : Ladislav Lhotka 
> Envoyé : vendredi 25 mars 2022 15:04
> À : BOUCADAIR Mohamed INNOV/NET ;
> netmod@ietf.org
> Objet : RE: [netmod] TR: New Version Notification for draft-
> boucadair-netmod-iana-registries-00.txt
> 
>  writes:
> 
...
> >
> >  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
> >>
> >
> > [Med] Will add a pointer to this repo. Thanks.
> 
> Thanks, Lada
> 


_

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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[mohamed.boucadair]

Dear Chairs, all, 

The new version include some text to address the issue raised by Italo 
recently. 

I think that it is time to consider adoption of this draft. Thanks. 

Cheers,
Med

-Message d'origine-
De : internet-dra...@ietf.org  
Envoyé : vendredi 13 janvier 2023 09:03
À : BOUCADAIR Mohamed INNOV/NET 
Objet : New Version Notification for 
draft-boucadair-netmod-iana-registries-06.txt


A new version of I-D, draft-boucadair-netmod-iana-registries-06.txt
has been successfully submitted by Mohamed Boucadair and posted to the IETF 
repository.

Name:   draft-boucadair-netmod-iana-registries
Revision:   06
Title:  Recommendations for Creating IANA-Maintained YANG Modules
Document date:  2023-01-13
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-boucadair-netmod-iana-registries-06.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://author-tools.ietf.org/iddiff?url2=draft-boucadair-netmod-iana-registries-06

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
   another format to present the content of these registries when
   appropriate.

   This document updates RFC 8407 by providing additional guidelines for
   IANA-maintained modules.  Also, this document updates RFC 8126 by
   providing additional guidelines for writing the IANA considerations
   for RFCs that specify IANA-maintained modules.  This document does
   not change anything written in RFC 8407 and RFC 8126.


  


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.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[mohamed.boucadair]

Hi all, 

This version includes a new section that discusses what should be included in 
the IANA Considerations Section. This version is also updating RFC 8126. 

I have a pending comment from Lou to consider adding some text when to *not* 
use an IANA-maintained module. Suggestions to address this comment are more 
than welcome.

Cheers,
Med

-Message d'origine-
De : internet-dra...@ietf.org  
Envoyé : jeudi 8 septembre 2022 13:51
À : BOUCADAIR Mohamed INNOV/NET 
Objet : New Version Notification for 
draft-boucadair-netmod-iana-registries-04.txt


A new version of I-D, draft-boucadair-netmod-iana-registries-04.txt
has been successfully submitted by Mohamed Boucadair and posted to the IETF 
repository.

Name:   draft-boucadair-netmod-iana-registries
Revision:   04
Title:  Recommendations for Creating IANA-Maintained YANG Modules
Document date:  2022-09-08
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-boucadair-netmod-iana-registries-04.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-04

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
   another format to present the content of these registries when
   appropriate.

   This document updates RFC 8407 by providing additional guidelines for
   IANA-maintained modules.  Also, this document updates RFC 8126 by
   providing additional guidelines for writing the IANA considerations
   for RFCs that specify IANA-maintained modules.  This document does
   not change anything written in RFC 8407 and RFC 8126.


  


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.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[mohamed.boucadair]

Hi Chairs, all,

Would it be possible to consider a call for adoption for this draft or you 
think that more discussion is needed?

Cheers,
Med

De : netmod  De la part de mohamed.boucad...@orange.com
Envoyé : mercredi 30 mars 2022 10:04
À : netmod@ietf.org
Objet : Re: [netmod] TR: New Version Notification for 
draft-boucadair-netmod-iana-registries-00.txt

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

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

Cheers,
Med

De : netmod mailto:netmod-boun...@ietf.org>> De la 
part de mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
Envoyé : mardi 29 mars 2022 07:44
À : Andy Bierman mailto:a...@yumaworks.com>>
Cc : netmod@ietf.org<mailto:netmod@ietf.org>
Objet : Re: [netmod] TR: New Version Notification for 
draft-boucadair-netmod-iana-registries-00.txt

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 mailto:a...@yumaworks.com>>
Envoyé : lundi 28 mars 2022 20:05
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Cc : Ladislav Lhotka mailto:ladislav.lho...@nic.cz>>; 
Jürgen Schönwälder 
mailto:j.schoenwael...@jacobs-university.de>>;
 netmod@ietf.org<mailto:netmod@ietf.org>
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



_



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.

_

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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[mohamed.boucadair]

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

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

Cheers,
Med

De : netmod  De la part de mohamed.boucad...@orange.com
Envoyé : mardi 29 mars 2022 07:44
À : Andy Bierman 
Cc : netmod@ietf.org
Objet : Re: [netmod] TR: New Version Notification for 
draft-boucadair-netmod-iana-registries-00.txt

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 mailto:a...@yumaworks.com>>
Envoyé : lundi 28 mars 2022 20:05
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Cc : Ladislav Lhotka mailto:ladislav.lho...@nic.cz>>; 
Jürgen Schönwälder 
mailto:j.schoenwael...@jacobs-university.de>>;
 netmod@ietf.org<mailto:netmod@ietf.org>
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



_

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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[mohamed.boucadair]

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 
Envoyé : lundi 28 mars 2022 20:05
À : BOUCADAIR Mohamed INNOV/NET 
Cc : Ladislav Lhotka ; Jürgen Schönwälder 
; netmod@ietf.org
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 
mailto:mohamed.boucad...@orange.com>> wrote:
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

> -Message d'origine-
> De : Ladislav Lhotka mailto:ladislav.lho...@nic.cz>>
> Envoyé : vendredi 25 mars 2022 15:04
> À : BOUCADAIR Mohamed INNOV/NET 
> mailto:mohamed.boucad...@orange.com>>;
> netmod@ietf.org<mailto:netmod@ietf.org>
> Objet : RE: [netmod] TR: New Version Notification for draft-boucadair-
> netmod-iana-registries-00.txt
>
> mailto:mohamed.boucad...@orange.com>> writes:
>
> > Hi Lada,
> >
> > Thank you for the comments.
> >
> > Pleases see inline.
> >
> > Cheers,
> > Med
> >
> >> -Message d'origine-
> >> De : Ladislav Lhotka 
> >> mailto:ladislav.lho...@nic.cz>> Envoyé : vendredi 
> >> 25
> >> mars 2022 11:26 À : BOUCADAIR Mohamed INNOV/NET
> >> mailto:mohamed.boucad...@orange.com>>; 
> >> netmod@ietf.org<mailto:netmod@ietf.org> Objet : Re: [netmod]
> >> TR: New Version Notification for draft-boucadair-
> >> netmod-iana-registries-00.txt
> >>
> >> 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.
> >
> > [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?
>
> Possibly, this is something that enumerations cannot model.
> >
> >>
> >> 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 d

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

[Andy Bierman]

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

> 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
>
> > -Message d'origine-
> > De : Ladislav Lhotka 
> > Envoyé : vendredi 25 mars 2022 15:04
> > À : BOUCADAIR Mohamed INNOV/NET ;
> > netmod@ietf.org
> > Objet : RE: [netmod] TR: New Version Notification for draft-boucadair-
> > netmod-iana-registries-00.txt
> >
> >  writes:
> >
> > > Hi Lada,
> > >
> > > Thank you for the comments.
> > >
> > > Pleases see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > >> -Message d'origine-
> > >> De : Ladislav Lhotka  Envoyé : vendredi 25
> > >> mars 2022 11:26 À : BOUCADAIR Mohamed INNOV/NET
> > >> ; netmod@ietf.org Objet : Re: [netmod]
> > >> TR: New Version Notification for draft-boucadair-
> > >> netmod-iana-registries-00.txt
> > >>
> > >> 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.
> > >
> > > [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?
> >
> > Possibly, this is something that enumerations cannot model.
> > >
> > >>
> > >> 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 XS

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

[mohamed.boucadair]

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

> -Message d'origine-
> De : tom petch 
> Envoyé : lundi 28 mars 2022 12:38
> À : BOUCADAIR Mohamed INNOV/NET ;
> netmod@ietf.org; Jürgen Schönwälder  university.de>
> Objet : Re: [netmod] TR: New Version Notification for draft-boucadair-
> netmod-iana-registries-00.txt
> 
> From: netmod  on behalf of Jürgen Schönwälder
> 
> Sent: 25 March 2022 10:37
> 
> 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.
> 
> 
> 
> 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
> 

_

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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[tom petch]

From: netmod  on behalf of Jürgen Schönwälder 

Sent: 25 March 2022 10:37

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.



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

On Fri, Mar 25, 2022 at 11:26:17AM +0100, Ladislav Lhotka wrote:
> 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
>
>  writes:
>
> > 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 : internet-dra...@ietf.org 
> > Envoyé : jeudi 24 mars 2022 10:41
> > À : BOUCADAIR 

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

[mohamed.boucadair]

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

> -Message d'origine-
> De : Ladislav Lhotka 
> Envoyé : vendredi 25 mars 2022 15:04
> À : BOUCADAIR Mohamed INNOV/NET ;
> netmod@ietf.org
> Objet : RE: [netmod] TR: New Version Notification for draft-boucadair-
> netmod-iana-registries-00.txt
> 
>  writes:
> 
> > Hi Lada,
> >
> > Thank you for the comments.
> >
> > Pleases see inline.
> >
> > Cheers,
> > Med
> >
> >> -Message d'origine-
> >> De : Ladislav Lhotka  Envoyé : vendredi 25
> >> mars 2022 11:26 À : BOUCADAIR Mohamed INNOV/NET
> >> ; netmod@ietf.org Objet : Re: [netmod]
> >> TR: New Version Notification for draft-boucadair-
> >> netmod-iana-registries-00.txt
> >>
> >> 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.
> >
> > [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?
> 
> Possibly, this is something that enumerations cannot model.
> >
> >>
> >> 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.
> >>
> >
> > [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.
> 
> >
> >> 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] A

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

[Ladislav Lhotka]

 writes:

> Hi Lada, 
>
> Thank you for the comments. 
>
> Pleases see inline. 
>
> Cheers,
> Med
>
>> -Message d'origine-
>> De : Ladislav Lhotka 
>> Envoyé : vendredi 25 mars 2022 11:26
>> À : BOUCADAIR Mohamed INNOV/NET ;
>> netmod@ietf.org
>> Objet : Re: [netmod] TR: New Version Notification for draft-boucadair-
>> netmod-iana-registries-00.txt
>> 
>> 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.
>
> [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?

Possibly, this is something that enumerations cannot model.
>
>> 
>> 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.
>> 
>
> [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.

>
>> 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
>> 
>> [1] https://github.com/llhotka/iana-yang
>> 
>
> [Med] Will add a pointer to this repo. Thanks.

Thanks, Lada

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

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

[mohamed.boucadair]

Hi Lada, 

Thank you for the comments. 

Pleases see inline. 

Cheers,
Med

> -Message d'origine-
> De : Ladislav Lhotka 
> Envoyé : vendredi 25 mars 2022 11:26
> À : BOUCADAIR Mohamed INNOV/NET ;
> netmod@ietf.org
> Objet : Re: [netmod] TR: New Version Notification for draft-boucadair-
> netmod-iana-registries-00.txt
> 
> 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.

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

[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
> 
> [1] https://github.com/llhotka/iana-yang
> 

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

>  writes:
> 
> > 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 : internet-dra...@ietf.org  Envoyé :
> > jeudi 24 mars 2022 10:41 À : BOUCADAIR Mohamed INNOV/NET
> >  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
>

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

[Jürgen Schönwälder]

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

On Fri, Mar 25, 2022 at 11:26:17AM +0100, Ladislav Lhotka wrote:
> 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
> 
>  writes:
> 
> > 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 : internet-dra...@ietf.org  
> > Envoyé : jeudi 24 mars 2022 10:41
> > À : BOUCADAIR Mohamed INNOV/NET 
> > 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
>

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

[Ladislav Lhotka]

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

 writes:

> 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 : internet-dra...@ietf.org  
> Envoyé : jeudi 24 mars 2022 10:41
> À : BOUCADAIR Mohamed INNOV/NET 
> 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

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

[Jürgen Schönwälder]

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

On Fri, Mar 25, 2022 at 08:40:30AM +, mohamed.boucad...@orange.com wrote:
> Re-,
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Jürgen Schönwälder 
> > Envoyé : vendredi 25 mars 2022 09:01
> > À : BOUCADAIR Mohamed INNOV/NET 
> > Cc : Qin Wu ; netmod@ietf.org
> > Objet : Re: [netmod] TR: New Version Notification for draft-boucadair-
> > netmod-iana-registries-00.txt
> > 
> > On Fri, Mar 25, 2022 at 07:49:42AM +, mohamed.boucad...@orange.com
> > wrote:
> > 
> > > > 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.
> > >
> > 
> > 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. 
>  
> > 
> > /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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[mohamed.boucadair]

Re-,

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Jürgen Schönwälder 
> Envoyé : vendredi 25 mars 2022 09:01
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : Qin Wu ; netmod@ietf.org
> Objet : Re: [netmod] TR: New Version Notification for draft-boucadair-
> netmod-iana-registries-00.txt
> 
> On Fri, Mar 25, 2022 at 07:49:42AM +, mohamed.boucad...@orange.com
> wrote:
> 
> > > 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.
> >
> 
> 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. 
 
> 
> /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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Jürgen Schönwälder]

On Fri, Mar 25, 2022 at 07:49:42AM +, mohamed.boucad...@orange.com wrote:

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

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

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[mohamed.boucadair]

Hi Jürgen, 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Jürgen Schönwälder 
> Envoyé : vendredi 25 mars 2022 08:15
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : Qin Wu ; netmod@ietf.org
> 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 +, mohamed.boucad...@orange.com
> 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 
> > > Envoyé : jeudi 24 mars 2022 12:52
> > > À : Qin Wu 
> > > Cc : BOUCADAIR Mohamed INNOV/NET ;
> > > netmod@ietf.org Objet : Re: [netmod] TR: New Version Notification
> > > for draft-boucadair- netmod-iana-registries-00.txt
> > >
> > > On Thu, Mar 24, 2022 at 11:23:39AM +, Qin Wu wrote:
> > > > >-邮件原件-
> > > > >发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Jürgen
> > > Sch?nw?lder
> > > > >发送时间: 2022年3月24日 18:56
> > > > >收件人: mohamed.boucad...@orange.com
> > > > >抄送: netmod@ietf.org
> > > > >主题: Re: [netmod] TR: New Version Notification for
> > > > >draft-boucadair-netmod-iana-registries-00.txt
> > > >
> > > > >On Thu, Mar 24, 2022 at 10:44:42AM +,
> > > mohamed.boucad...@orange.com 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
> > > > >&

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

[Jürgen Schönwälder]

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 +, mohamed.boucad...@orange.com 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 
> > Envoyé : jeudi 24 mars 2022 12:52
> > À : Qin Wu 
> > Cc : BOUCADAIR Mohamed INNOV/NET ;
> > netmod@ietf.org
> > Objet : Re: [netmod] TR: New Version Notification for draft-boucadair-
> > netmod-iana-registries-00.txt
> > 
> > On Thu, Mar 24, 2022 at 11:23:39AM +, Qin Wu wrote:
> > > >-邮件原件-
> > > >发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Jürgen
> > Sch?nw?lder
> > > >发送时间: 2022年3月24日 18:56
> > > >收件人: mohamed.boucad...@orange.com
> > > >抄送: netmod@ietf.org
> > > >主题: Re: [netmod] TR: New Version Notification for
> > > >draft-boucadair-netmod-iana-registries-00.txt
> > >
> > > >On Thu, Mar 24, 2022 at 10:44:42AM +,
> > mohamed.boucad...@orange.com 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
> > modul

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

[mohamed.boucadair]

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 
> Envoyé : jeudi 24 mars 2022 12:52
> À : Qin Wu 
> Cc : BOUCADAIR Mohamed INNOV/NET ;
> netmod@ietf.org
> Objet : Re: [netmod] TR: New Version Notification for draft-boucadair-
> netmod-iana-registries-00.txt
> 
> On Thu, Mar 24, 2022 at 11:23:39AM +, Qin Wu wrote:
> > >-邮件原件-
> > >发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Jürgen
> Sch?nw?lder
> > >发送时间: 2022年3月24日 18:56
> > >收件人: mohamed.boucad...@orange.com
> > >抄送: netmod@ietf.org
> > >主题: Re: [netmod] TR: New Version Notification for
> > >draft-boucadair-netmod-iana-registries-00.txt
> >
> > >On Thu, Mar 24, 2022 at 10:44:42AM +,
> mohamed.boucad...@orange.com 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Jürgen Schönwälder]

On Thu, Mar 24, 2022 at 11:23:39AM +, Qin Wu wrote:
> >-邮件原件-
> >发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Jürgen Sch?nw?lder
> >发送时间: 2022年3月24日 18:56
> >收件人: mohamed.boucad...@orange.com
> >抄送: netmod@ietf.org
> >主题: Re: [netmod] TR: New Version Notification for 
> >draft-boucadair-netmod-iana-registries-00.txt
> 
> >On Thu, Mar 24, 2022 at 10:44:42AM +, mohamed.boucad...@orange.com 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.
>

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[mohamed.boucadair]

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 
> Envoyé : jeudi 24 mars 2022 12:24
> À : Jürgen Schönwälder ; BOUCADAIR
> Mohamed INNOV/NET 
> Cc : netmod@ietf.org
> Objet : RE: [netmod] TR: New Version Notification for draft-boucadair-
> netmod-iana-registries-00.txt
> 
> >-邮件原件-
> >发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Jürgen Sch?nw?lder
> >发送时间: 2022年3月24日 18:56
> >收件人: mohamed.boucad...@orange.com
> >抄送: netmod@ietf.org
> >主题: Re: [netmod] TR: New Version Notification for
> >draft-boucadair-netmod-iana-registries-00.txt
> 
> >On Thu, Mar 24, 2022 at 10:44:42AM +, mohamed.boucad...@orange.com
> 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.
> 


_

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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Qin Wu]

>-邮件原件-
>发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Jürgen Sch?nw?lder
>发送时间: 2022年3月24日 18:56
>收件人: mohamed.boucad...@orange.com
>抄送: netmod@ietf.org
>主题: Re: [netmod] TR: New Version Notification for 
>draft-boucadair-netmod-iana-registries-00.txt

>On Thu, Mar 24, 2022 at 10:44:42AM +, mohamed.boucad...@orange.com 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Jürgen Schönwälder]

On Thu, Mar 24, 2022 at 10:44:42AM +, mohamed.boucad...@orange.com 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? 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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[mohamed.boucadair]

Hi Jürgen, 

Thank you for the feedback. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Jürgen Schönwälder 
> Envoyé : jeudi 24 mars 2022 11:27
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : netmod@ietf.org
> 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
> semantic here is that this document augments what is being said in RFC
> 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
> "updates" means.

[Med] Agree. 

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

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

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


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

[Med] :-)


> 
> On Thu, Mar 24, 2022 at 09:47:16AM +, mohamed.boucad...@orange.com
> wrote:
> > 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 : internet-dra...@ietf.org  Envoyé :
> > jeudi 24 mars 2022 10:41 À : BOUCADAIR Mohamed INNOV/NET
> >  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.
> >
> >
> &

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

[Jürgen Schönwälder]

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

   This document updates RFC 8407.

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 +, mohamed.boucad...@orange.com wrote:
> 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 : internet-dra...@ietf.org  
> Envoyé : jeudi 24 mars 2022 10:41
> À : BOUCADAIR Mohamed INNOV/NET 
> 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.
> 
> ___
> netmod mailing list
> netmod@ietf.org
> 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/>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[mohamed.boucadair]

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 : internet-dra...@ietf.org  
Envoyé : jeudi 24 mars 2022 10:41
À : BOUCADAIR Mohamed INNOV/NET 
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.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries

[Ladislav Lhotka]

On 29. 11. 21 14:32, Robert Varga wrote:

On 26/11/2021 09:30, Ladislav Lhotka wrote:
And what do yo do with Early Allocation, which can last more than a 
year?
Sorry, I am not familiar with early allocations, what could be the 
problem here?


The problem is that early allocations are temporary and automatically 
expire in 12 months (relinquishing the code point) unless refreshed by 
the requester -- see https://www.rfc-editor.org/rfc/rfc7120#section-3.3 
for details.


I see. So if the temporarily allocated code point disappears from the 
registry, it won't be present in the YANG module either, if it is 
generated later. If YANG was able to read the registry directly, it 
would be the same.


Cheers, Lada



Regards,
Robert

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries

[Robert Varga]

On 26/11/2021 09:30, Ladislav Lhotka wrote:

And what do yo do with Early Allocation, which can last more than a year?

Sorry, I am not familiar with early allocations, what could be the problem here?


The problem is that early allocations are temporary and automatically 
expire in 12 months (relinquishing the code point) unless refreshed by 
the requester -- see https://www.rfc-editor.org/rfc/rfc7120#section-3.3 
for details.


Regards,
Robert


OpenPGP_signature
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries

[Carsten Bormann]

Hi Lada,



> On 2021-11-26, at 09:48, Ladislav Lhotka  wrote:
> 
> Carsten Bormann  writes:
> 
>> On 2021-11-24, at 09:13, Ladislav Lhotka  wrote:
>>> 
>>> Please let me know what you think about this.
>> 
>> I think it is amazing.
>> 
>> So for each registry, you have
>> 
>> — manually extracted an information model and kept that in your head,
> 
> Well, my old head doesn't serve me that well anymore, I was just looking into 
> the registry web page and XML. 

Indeed, so you had to apply human intelligence to produce information that is 
not available for the registry.

>> — written code that translates the information you could extract from the 
>> XML form of the registry into a YANG data model (note that this data model 
>> is not defining the registry, but it is the translated content of the 
>> registry)
> 
> Right, and IANA needn't be involved at all.

In the long run, we will need to make sure we actually capture the information 
model for registries (at the time the registries are created and updated, when 
the experts are in the house).

>> This is certainly highly useful.
>> It also requires to essentially start from scratch for each new registry.
> 
> Registry schemas are quite diverse, so a universal translation procedure 
> isn't possible.

(That’s why I said we need to capture the information model.
There is not a single one that applies to every registry.)

> Also, some decisions may be necessary on the YANG side - for example, whether 
> the registry records are to be represented as enums or identities.

Right, that is essentially the the IM ➔ DM mapping, and that needs to be done 
for each kind of DM (unless the IM already contains enough hints to carry this 
out by default).

> In most cases, writing a registry-specific translation isn't difficult and 
> amounts to copying Makefile and XSLT stylesheet templates, editing parameters 
> in the Makefile and writing a few XSLT lines.

I’m not questioning this, I just note that this is a mostly manual process that 
will be hard to maintain in the long run.

>> Shouldn’t registries come with a machine readable information model?
> 
> Actually, RELAX NG schemas are available, for example
> 
> https://www.iana.org/assignments/dns-parameters/dns-parameters.rng

These are data models for the registry page, not the underlying information 
models.

> They are useful for clarifying what to expect in the registry but don't help 
> much with automating the translation. 

(Because the IM info is missing.)

>> Shouldn’t it then be “easy” to build a generic tool that creates a YANG 
>> model out of the data in the registry?
> 
> Ideally, YANG might be able to directly "import" registries, but this is 
> quite difficult to achieve because registries are not very uniform.

… and you’d need the IM info (and any DM mapping hints).

.oOo.

I don’t want to hold up this effort by trying to do this properly, but I note 
that YANG is not the only target DM that registries would need to translate 
info.
(And you’ll note that I’m thinking like an SDF author here…)

Grüße, Carsten

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries

[Ladislav Lhotka]

Carsten Bormann  writes:

> On 2021-11-24, at 09:13, Ladislav Lhotka  wrote:
>> 
>> Please let me know what you think about this.
>
> I think it is amazing.
>
> So for each registry, you have
>
> — manually extracted an information model and kept that in your head,

Well, my old head doesn't serve me that well anymore, I was just looking into 
the registry web page and XML. 

> — written code that translates the information you could extract from the XML 
> form of the registry into a YANG data model (note that this data model is not 
> defining the registry, but it is the translated content of the registry)

Right, and IANA needn't be involved at all.

>
> This is certainly highly useful.
> It also requires to essentially start from scratch for each new registry.

Registry schemas are quite diverse, so a universal translation procedure isn't 
possible. Also, some decisions may be necessary on the YANG side - for example, 
whether the registry records are to be represented as enums or identities.

In most cases, writing a registry-specific translation isn't difficult and 
amounts to copying Makefile and XSLT stylesheet templates, editing parameters 
in the Makefile and writing a few XSLT lines.

> Shouldn’t registries come with a machine readable information model?

Actually, RELAX NG schemas are available, for example

https://www.iana.org/assignments/dns-parameters/dns-parameters.rng

They are useful for clarifying what to expect in the registry but don't help 
much with automating the translation. 

> Shouldn’t it then be “easy” to build a generic tool that creates a YANG model 
> out of the data in the registry?

Ideally, YANG might be able to directly "import" registries, but this is quite 
difficult to achieve because registries are not very uniform.

Thanks, Lada


>
> Grüße, Carsten
>

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries

[Ladislav Lhotka]

tom petch  writes:

> From: netmod  on behalf of Ladislav Lhotka 
> 
> Sent: 24 November 2021 08:13
>
> Hi,
>
> I tried to generalize the approach of RFC 9108 and develop XSLT stylesheets 
> for generating YANG modules directly from IANA registries. The results are in 
> this GitHub project:
>
> https://github.com/llhotka/iana-yang
>
> So far I have processed 22 registries - most of them are related to DNS, but 
> I also tried to include a few from other areas. After cloning the project, 
> all YANG modules can be generated by running "make" in the top-level 
> directory.
>
> Adding a new registry is usually quite simple, although some hide nasty 
> surprises such as duplicate entries. Also, in most cases it is quite clear 
> how to do the translation, but sometimes input from domain experts might be 
> needed.
>
> I can see two immediate advantages of this approach:
>
> * There is a single source of truth - the registry itself; IANA needn't
>   maintain the YANG module separately.
>
> * The initial revision of a registry-based YANG module needn't be published in
>   an RFC that is not intended to be updated. There are concerns that people
>   may extract such a module from the RFC long after it becomes obsolete.
>
> Please let me know what you think about this.
>
> 
> An IANA registry can contain any number of columns meaning an infinite 
> variety of things - TLS comes to mind.   A YANG module is more limited.  
> Having both in an RFC shows how to map the registry into YANG.

Such a module isn't meant as a replacement of the registry, developers will 
most likely need to consult both. Contents of extra columns may either appear 
in the description (as in iana-dnssec-algorithms), or may be omitted (as in 
iana-structured-syntax-suffix).

And yes, as I wrote domain experts' input may be needed, perhaps in the form of 
an RFC. However, it is not ideal to include a complete YANG module (initial 
revision) based on a random snapshot of the registry in such an RFC. In DNSOP 
WG this turned out to be a no-go, and after discussing a few alternatives we 
came up with an XSLT stylesheet as kind of a recipe from which IANA made the 
initial revision.

I understand that XSLT isn't everyone's favourite language, but I don't know 
about a better choice for this purpose. Perhaps the RFC could just explain the 
rules for the translation in the text (with examples).

>
> And what do yo do with Early Allocation, which can last more than a year?

Sorry, I am not familiar with early allocations, what could be the problem here?

Lada

>
> Tom Petch
>
> Thanks, Lada
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries

[Carsten Bormann]

On 2021-11-24, at 09:13, Ladislav Lhotka  wrote:
> 
> Please let me know what you think about this.

I think it is amazing.

So for each registry, you have

— manually extracted an information model and kept that in your head,
— written code that translates the information you could extract from the XML 
form of the registry into a YANG data model (note that this data model is not 
defining the registry, but it is the translated content of the registry)

This is certainly highly useful.
It also requires to essentially start from scratch for each new registry.
Shouldn’t registries come with a machine readable information model?
Shouldn’t it then be “easy” to build a generic tool that creates a YANG model 
out of the data in the registry?

Grüße, Carsten

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries

[tom petch]

From: netmod  on behalf of Ladislav Lhotka 

Sent: 24 November 2021 08:13

Hi,

I tried to generalize the approach of RFC 9108 and develop XSLT stylesheets for 
generating YANG modules directly from IANA registries. The results are in this 
GitHub project:

https://github.com/llhotka/iana-yang

So far I have processed 22 registries - most of them are related to DNS, but I 
also tried to include a few from other areas. After cloning the project, all 
YANG modules can be generated by running "make" in the top-level directory.

Adding a new registry is usually quite simple, although some hide nasty 
surprises such as duplicate entries. Also, in most cases it is quite clear how 
to do the translation, but sometimes input from domain experts might be needed.

I can see two immediate advantages of this approach:

* There is a single source of truth - the registry itself; IANA needn't
  maintain the YANG module separately.

* The initial revision of a registry-based YANG module needn't be published in
  an RFC that is not intended to be updated. There are concerns that people
  may extract such a module from the RFC long after it becomes obsolete.

Please let me know what you think about this.


An IANA registry can contain any number of columns meaning an infinite variety 
of things - TLS comes to mind.   A YANG module is more limited.  Having both in 
an RFC shows how to map the registry into YANG.

And what do yo do with Early Allocation, which can last more than a year?

Tom Petch

Thanks, Lada

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] IANA registries

[Ladislav Lhotka]

Hi,

I tried to generalize the approach of RFC 9108 and develop XSLT stylesheets for 
generating YANG modules directly from IANA registries. The results are in this 
GitHub project:

https://github.com/llhotka/iana-yang

So far I have processed 22 registries - most of them are related to DNS, but I 
also tried to include a few from other areas. After cloning the project, all 
YANG modules can be generated by running "make" in the top-level directory.

Adding a new registry is usually quite simple, although some hide nasty 
surprises such as duplicate entries. Also, in most cases it is quite clear how 
to do the translation, but sometimes input from domain experts might be needed.

I can see two immediate advantages of this approach:

* There is a single source of truth - the registry itself; IANA needn't
  maintain the YANG module separately.

* The initial revision of a registry-based YANG module needn't be published in
  an RFC that is not intended to be updated. There are concerns that people
  may extract such a module from the RFC long after it becomes obsolete.

Please let me know what you think about this.

Thanks, Lada

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries and YANG

[Kent Watsen]

Maybe this approach can be for the algorithms in the "iana-*algs.yang" modules 
defined in the crypto-types draft.   The '*' expands to symmetric, asymmetric, 
and hash.   The problem is that I'm unsure if there is exists 1-1 registries.  
But, to the extent there are registries, this approach seems easiest for IANA.

Kent // contributor



> On Dec 18, 2019, at 2:29 AM, Ladislav Lhotka  wrote:
> 
> Ladislav Lhotka  writes:
> 
>> Hi,
>> 
>> I would like to discuss the issue of developing YANG modules that mirror 
>> IANA registries. The main objection, raised in DNSOP WG in relation to 
>> draft-lhotka-dnsop-iana-class-type-yang-02, was that the RFC containing the 
>> initial revision of the module doesn't get updated along with the IANA 
>> registry (IANA is expected to keep the module in sync without updating the 
>> RFC). As a result implementors can use the obsolete snapshot from the RFC.
>> 
>> I am aware of three solution proposals:
>> 
>> 1. use some kind of template instead of a YANG module
> 
> Followup: template turned out to be the right buzzword! Instead of the 
> initial revision of a YANG module, it is possible to include an XSLT 
> stylesheet and instruct IANA to use it for generating the initial revision of 
> the module directly from the XML version of the registry. I used this 
> approach in
> 
> https://tools.ietf.org/html/draft-ietf-dnsop-iana-class-type-yang-00
> 
> Could this be a recommended way for converting other IANA registries?
> 
> Lada
> 
>> 
>> 2. include only two or three entries of the registry as examples so
>>   that it is clear that it is not the complete list
>> 
>> 3. keep the module in the document during the whole I-D stage but
>>   instruct the RFC Editor to remove it just before it becomes RFC.
>> 
>> I am personally in favour of #3. According to Randy Presuhn, who proposed 
>> it, this procedure was used during the preparation of BCP 47. It would 
>> require some extra coordination with with IANA but, apart from that, it 
>> should IMO work well and avoid the problem mentioned above.
>> 
>> Thanks, Lada
>> 
>> -- 
>> Ladislav Lhotka 
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Ladislav Lhotka 
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries and YANG

[Ladislav Lhotka]

Ladislav Lhotka  writes:

> Hi,
>
> I would like to discuss the issue of developing YANG modules that mirror IANA 
> registries. The main objection, raised in DNSOP WG in relation to 
> draft-lhotka-dnsop-iana-class-type-yang-02, was that the RFC containing the 
> initial revision of the module doesn't get updated along with the IANA 
> registry (IANA is expected to keep the module in sync without updating the 
> RFC). As a result implementors can use the obsolete snapshot from the RFC.
>
> I am aware of three solution proposals:
>
> 1. use some kind of template instead of a YANG module

Followup: template turned out to be the right buzzword! Instead of the initial 
revision of a YANG module, it is possible to include an XSLT stylesheet and 
instruct IANA to use it for generating the initial revision of the module 
directly from the XML version of the registry. I used this approach in

https://tools.ietf.org/html/draft-ietf-dnsop-iana-class-type-yang-00

Could this be a recommended way for converting other IANA registries?

Lada

>
> 2. include only two or three entries of the registry as examples so
>that it is clear that it is not the complete list
>
> 3. keep the module in the document during the whole I-D stage but
>instruct the RFC Editor to remove it just before it becomes RFC.
>
> I am personally in favour of #3. According to Randy Presuhn, who proposed it, 
> this procedure was used during the preparation of BCP 47. It would require 
> some extra coordination with with IANA but, apart from that, it should IMO 
> work well and avoid the problem mentioned above.
>
> Thanks, Lada
>
> -- 
> Ladislav Lhotka 
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries and YANG

[Ladislav Lhotka]

On Tue, 2019-11-19 at 11:48 +, tom petch wrote:
> - Original Message -
> From: "Ladislav Lhotka" 
> To: "Martin Bjorklund" 
> Cc: 
> Sent: Tuesday, November 19, 2019 10:29 AM
> 
> > On Tue, 2019-11-19 at 11:17 +0100, Martin Bjorklund wrote:
> > > Ladislav Lhotka  wrote:
> > > > Hi,
> > > > 
> > > > I would like to discuss the issue of developing YANG modules that
> > > > mirror IANA registries. The main objection, raised in DNSOP WG in
> > > > relation to draft-lhotka-dnsop-iana-class-type-yang-02, was that
> the
> > > > RFC containing the initial revision of the module doesn't get
> updated
> > > > along with the IANA registry (IANA is expected to keep the module
> in
> > > > sync without updating the RFC). As a result implementors can use
> the
> > > > obsolete snapshot from the RFC.
> > > > 
> > > > I am aware of three solution proposals:
> > > > 
> > > > 1. use some kind of template instead of a YANG module
> > > > 
> > > > 2. include only two or three entries of the registry as examples
> so
> > > >that it is clear that it is not the complete list
> > > > 
> > > > 3. keep the module in the document during the whole I-D stage but
> > > >instruct the RFC Editor to remove it just before it becomes
> RFC.
> > > Do you mean that the RFC editor removes it and the RFC just points
> to
> > > the IANA registry?  And then the RFC editor hands it over to IANA so
> > > that they can use it as an initial version to be published?
> > 
> > Yes. The final RFC would then only describe and explain the design of
> the
> > module, which is useful in itself (because there are several possible
> options
> > for translating a registry to YANG).
> > 
> > > As long as the instructions to the RFC editor are clear, I think
> this
> > > can work.
> > 
> > We have to work out the details and discuss it with IANA, but it
> shouldn't IMO
> > be too difficult. And the draft in DNSOP can be used as a guinea pig.
> 
> I think that this is a bad idea; we have been handing over modules to
> IANA to maintain since 1999 and I have not seen much in the way of
> troubles in the intervening decades.

I guess everyone in this mailing list will agree that this issue is largely a
red herring, but it seems that our draft in DNSOP cannot move forward without
solving it. For those with masochistic inclination, here is a typical ML thread:

https://mailarchive.ietf.org/arch/msg/dnsop/0AjdiR8htN_vjglimt1b7z10V_E

DNSOP chairs don't want to take a stance and hope that the IESG will resolve
this issue somehow - but this is of course not going to happen.

> 
> I want the RFC to contain the initial version of the module - otherwise,
> we have no record of the initial version.

Why do you need the initial version? After all, it is just a random snapshot of
the registry that is used to explain to IANA how the module is supposed to be
updated.

> 
> What we should do is make it clear that it is the initial version and
> will not be maintained e.g. in the description and revision clauses
> 
> 'The initial version of this module was published in RFC; the
> current version can be found at
> https://  ...iana  ...
> "

I suggested something like this repeatedly, without any significant success.

What else can we do?

Lada

> 
> Tom Petch
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > Lada
> > 
> > > 
> > > 
> > > /martin
> > > 
> > > 
> > > > I am personally in favour of #3. According to Randy Presuhn, who
> > > > proposed it, this procedure was used during the preparation of BCP
> > > > 47. It would require some extra coordination with with IANA but,
> apart
> > > > from that, it should IMO work well and avoid the problem mentioned
> > > > above.
> > > > 
> > > > Thanks, Lada
> > > > 
> > > > --
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > 
> > > > ___
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > 
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries and YANG

[Ladislav Lhotka]

On Tue, 2019-11-19 at 11:17 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > Hi,
> > 
> > I would like to discuss the issue of developing YANG modules that
> > mirror IANA registries. The main objection, raised in DNSOP WG in
> > relation to draft-lhotka-dnsop-iana-class-type-yang-02, was that the
> > RFC containing the initial revision of the module doesn't get updated
> > along with the IANA registry (IANA is expected to keep the module in
> > sync without updating the RFC). As a result implementors can use the
> > obsolete snapshot from the RFC.
> > 
> > I am aware of three solution proposals:
> > 
> > 1. use some kind of template instead of a YANG module
> > 
> > 2. include only two or three entries of the registry as examples so
> >that it is clear that it is not the complete list
> > 
> > 3. keep the module in the document during the whole I-D stage but
> >instruct the RFC Editor to remove it just before it becomes RFC.
> 
> Do you mean that the RFC editor removes it and the RFC just points to
> the IANA registry?  And then the RFC editor hands it over to IANA so
> that they can use it as an initial version to be published?

Yes. The final RFC would then only describe and explain the design of the
module, which is useful in itself (because there are several possible options
for translating a registry to YANG).

> 
> As long as the instructions to the RFC editor are clear, I think this
> can work.

We have to work out the details and discuss it with IANA, but it shouldn't IMO
be too difficult. And the draft in DNSOP can be used as a guinea pig.

Lada

> 
> 
> 
> /martin
> 
> 
> > 
> > I am personally in favour of #3. According to Randy Presuhn, who
> > proposed it, this procedure was used during the preparation of BCP
> > 47. It would require some extra coordination with with IANA but, apart
> > from that, it should IMO work well and avoid the problem mentioned
> > above.
> > 
> > Thanks, Lada
> > 
> > -- 
> > Ladislav Lhotka 
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries and YANG

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Hi,
> 
> I would like to discuss the issue of developing YANG modules that
> mirror IANA registries. The main objection, raised in DNSOP WG in
> relation to draft-lhotka-dnsop-iana-class-type-yang-02, was that the
> RFC containing the initial revision of the module doesn't get updated
> along with the IANA registry (IANA is expected to keep the module in
> sync without updating the RFC). As a result implementors can use the
> obsolete snapshot from the RFC.
> 
> I am aware of three solution proposals:
> 
> 1. use some kind of template instead of a YANG module
> 
> 2. include only two or three entries of the registry as examples so
>that it is clear that it is not the complete list
> 
> 3. keep the module in the document during the whole I-D stage but
>instruct the RFC Editor to remove it just before it becomes RFC.

Do you mean that the RFC editor removes it and the RFC just points to
the IANA registry?  And then the RFC editor hands it over to IANA so
that they can use it as an initial version to be published?

As long as the instructions to the RFC editor are clear, I think this
can work.



/martin


> 
> I am personally in favour of #3. According to Randy Presuhn, who
> proposed it, this procedure was used during the preparation of BCP
> 47. It would require some extra coordination with with IANA but, apart
> from that, it should IMO work well and avoid the problem mentioned
> above.
> 
> Thanks, Lada
> 
> -- 
> Ladislav Lhotka 
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] IANA registries and YANG

[Ladislav Lhotka]

Hi,

I would like to discuss the issue of developing YANG modules that mirror IANA 
registries. The main objection, raised in DNSOP WG in relation to 
draft-lhotka-dnsop-iana-class-type-yang-02, was that the RFC containing the 
initial revision of the module doesn't get updated along with the IANA registry 
(IANA is expected to keep the module in sync without updating the RFC). As a 
result implementors can use the obsolete snapshot from the RFC.

I am aware of three solution proposals:

1. use some kind of template instead of a YANG module

2. include only two or three entries of the registry as examples so
   that it is clear that it is not the complete list

3. keep the module in the document during the whole I-D stage but
   instruct the RFC Editor to remove it just before it becomes RFC.

I am personally in favour of #3. According to Randy Presuhn, who proposed it, 
this procedure was used during the preparation of BCP 47. It would require some 
extra coordination with with IANA but, apart from that, it should IMO work well 
and avoid the problem mentioned above.

Thanks, Lada

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries

[Ladislav Lhotka]

On Mon, 2019-10-21 at 14:54 +, Kent Watsen wrote:
> Hi Lada, 
> 
> > Another option, also suggested in DNSOP WG, was to enable YANG to refer
> > directly to the IANA registry.
> 
> For crypto types, I don’t know if this it possible, as there may be many
> registries involved. 
> 
> Regardless, what is it that is doing the referring?  an identityref?  there
> needs to be a module update, not just a ref, right?  or do you mean that the
> type is “string” and the values are documented to be from said IANA
> registries?

This is of course a good question. I think an implicit enumeration could be a
good fit for many registries.

> 
> 
> > The problem with this is that we have no formalism for writing such
> > templates.
> 
> True. 
> 
> > > How about preparing an initial revision of the module, without writing any
> > > RFC, and hand it over to IANA to be published as a
> > > supplement to the registry?
> 
> I don’t understand.  Can you give a sketch of what you have in mind?

Just prepare the module and run it through some defined approval procedure. The
module will become official as soon as IANA publishes it on the "YANG
Parameters" page [1]. After that, IANA will update the module each time the
registry changes - the instructions for updates may be a part of the module
description. But there will be no RFC connected to the module.

Lada

[1] https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries

[Kent Watsen]

Hi Lada, 

> Another option, also suggested in DNSOP WG, was to enable YANG to refer 
> directly to the IANA registry.

For crypto types, I don’t know if this it possible, as there may be many 
registries involved. 

Regardless, what is it that is doing the referring?  an identityref?  there 
needs to be a module update, not just a ref, right?  or do you mean that the 
type is “string” and the values are documented to be from said IANA registries?


> The problem with this is that we have no formalism for writing such templates.

True. 

>> How about preparing an initial revision of the module, without writing any 
>> RFC, and hand it over to IANA to be published as a
>> supplement to the registry?

I don’t understand.  Can you give a sketch of what you have in mind?



Kent 


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries

[Ladislav Lhotka]

Kent Watsen  writes:

> All,
>
>>> That's a bit odd.  But perhaps it can be solved by actually not
>>> filling in all values in this module, but rather make it a template
>>> and instruct IANA to fill it in with the contents of the registry at
>>> the time of publication.
>> 
>> OK, so the module template in the RFC couldn't be used at all - this might
>> indeed help.
>
> This is an interesting proposal indeed, and one that may help with the 
> crypto-types "algorithm" discussion as well.
>
> Having IANA be able to automatically publish revisions for select
> module is something that has been discussed in the past, partially
> in NETCONF wrt crypto-types, to eliminate the need for expensive RFC
> cycles, for updates that needed as a reaction to other RFCs being
> published, which should also have the effect of shortening the time
> it takes for those updates to be made.

Another option, also suggested in DNSOP WG, was to enable YANG to refer 
directly to the IANA registry.

>
> AFAIK, no such relationship with IANA exists currently anywhere
> within the IETF.  To move this idea forward, the chairs need to
> discuss with the AD.  It might aid that discussion if there were an
> example template module...anyone want to a stab at one?

The problem with this is that we have no formalism for writing such templates.

>
> Should there be an I-D that lays out the framework for the agreement
> with IANA, or would each draft (e.g., crypto-types) lay it out just
> for itself?  Actually, this sounds like what might come out of the
> discussion with the AD, but thoughts now are welcome to.

How about preparing an initial revision of the module, without writing any RFC, 
and hand it over to IANA to be published as a supplement to the registry?

Lada

>
> Kent // as co-chair

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries

[Kent Watsen]

All,

>> That's a bit odd.  But perhaps it can be solved by actually not
>> filling in all values in this module, but rather make it a template
>> and instruct IANA to fill it in with the contents of the registry at
>> the time of publication.
> 
> OK, so the module template in the RFC couldn't be used at all - this might
> indeed help.

This is an interesting proposal indeed, and one that may help with the 
crypto-types "algorithm" discussion as well.

Having IANA be able to automatically publish revisions for select module is 
something that has been discussed in the past, partially in NETCONF wrt 
crypto-types, to eliminate the need for expensive RFC cycles, for updates that 
needed as a reaction to other RFCs being published, which should also have the 
effect of shortening the time it takes for those updates to be made.

AFAIK, no such relationship with IANA exists currently anywhere within the 
IETF.  To move this idea forward, the chairs need to discuss with the AD.  It 
might aid that discussion if there were an example template module...anyone 
want to a stab at one?   

Should there be an I-D that lays out the framework for the agreement with IANA, 
or would each draft (e.g., crypto-types) lay it out just for itself?  Actually, 
this sounds like what might come out of the discussion with the AD, but 
thoughts now are welcome to.

Kent // as co-chair___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries

[Ladislav Lhotka]

On Thu, 2019-10-10 at 14:07 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > Hi,
> > 
> > some of you have probably seen the discussions around
> > 
> > https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-02
> > 
> > We proposed to adopt it as a work item in the DNSOP WG, but despite
> > some support this is probably not going to happen. The substantial
> > objections are:
> > 
> > 1. It is not good to publish a YANG snapshot of an IANA registry as an RFC
> > because future implementors will use the module from that RFC and implement
> > registry entries that may have been deprecated in the mean time. 
> > 
> > 2. The meaning of "deprecated" and "obsolete" defined by IANA (RFC
> > 8126) differs from the definition in RFC 7950.
> > 
> > I already raised #2 in this mailing list, and I think it should be
> > addressed in the next version of YANG.
> > 
> > Regarding #1, I tried to explain that the RFC is only intended to contain an
> > initial revision of the corresponding YANG module, but it didn't help. One
> > suggestion was to avoid representing the registries as enumerations or sets
> of
> > identities, and use only integers.
> 
> That's a bit odd.  But perhaps it can be solved by actually not
> filling in all values in this module, but rather make it a template
> and instruct IANA to fill it in with the contents of the registry at
> the time of publication.

OK, so the module template in the RFC couldn't be used at all - this might
indeed help.

My idea was to tag the RFC as historic as soon as IANA takes over the module
maintenance.

I think part of the problem is that the new revisions are available from a
rather obscure place - the YANG Parameters registry page:

https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml

Lada

> 
> 
> 
> /martin
> 
> 
> > I wonder if we can come up with a reasonable solution. Without
> > having the important registries as YANG modules, it is difficult to
> > work on other modules - for DNS, in this case, but it could apply to
> > other areas, too.
> > 
> > Thanks, Lada
> > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Hi,
> 
> some of you have probably seen the discussions around
> 
> https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-02
> 
> We proposed to adopt it as a work item in the DNSOP WG, but despite
> some support this is probably not going to happen. The substantial
> objections are:
> 
> 1. It is not good to publish a YANG snapshot of an IANA registry as an RFC
> because future implementors will use the module from that RFC and implement
> registry entries that may have been deprecated in the mean time. 
> 
> 2. The meaning of "deprecated" and "obsolete" defined by IANA (RFC
> 8126) differs from the definition in RFC 7950.
> 
> I already raised #2 in this mailing list, and I think it should be
> addressed in the next version of YANG.
> 
> Regarding #1, I tried to explain that the RFC is only intended to contain an
> initial revision of the corresponding YANG module, but it didn't help. One
> suggestion was to avoid representing the registries as enumerations or sets of
> identities, and use only integers.

That's a bit odd.  But perhaps it can be solved by actually not
filling in all values in this module, but rather make it a template
and instruct IANA to fill it in with the contents of the registry at
the time of publication.



/martin


> I wonder if we can come up with a reasonable solution. Without
> having the important registries as YANG modules, it is difficult to
> work on other modules - for DNS, in this case, but it could apply to
> other areas, too.
> 
> Thanks, Lada
> 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] IANA registries

[Ladislav Lhotka]

Hi,

some of you have probably seen the discussions around

https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-02

We proposed to adopt it as a work item in the DNSOP WG, but despite some support
this is probably not going to happen. The substantial objections are:

1. It is not good to publish a YANG snapshot of an IANA registry as an RFC
because future implementors will use the module from that RFC and implement
registry entries that may have been deprecated in the mean time. 

2. The meaning of "deprecated" and "obsolete" defined by IANA (RFC 8126) differs
from the definition in RFC 7950.

I already raised #2 in this mailing list, and I think it should be addressed in
the next version of YANG.

Regarding #1, I tried to explain that the RFC is only intended to contain an
initial revision of the corresponding YANG module, but it didn't help. One
suggestion was to avoid representing the registries as enumerations or sets of
identities, and use only integers.

I wonder if we can come up with a reasonable solution. Without having the
important registries as YANG modules, it is difficult to work on other modules -
for DNS, in this case, but it could apply to other areas, too.

Thanks, Lada

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod