Subject: [netmod] IANA registries

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 10 Oct 2019 13:49:22 +0200

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 10 Oct 2019 14:07:57 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> 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:
> 
> 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.
> 

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
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 10 Oct 2019 14:34:10 +0200

> and instruct IANA to fill it in with the contents of the registry at

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

---

From: Kent Watsen <[email-masked]>
Date: Thu, 17 Oct 2019 22:02:36 +0000

All,

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

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Oct 2019 15:46:12 +0200

Kent Watsen <[email-masked]> writes:

> 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

---

From: Kent Watsen <[email-masked]>
Date: Mon, 21 Oct 2019 14:54:03 +0000

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. 

>> supplement to the registry?

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

Kent

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Oct 2019 17:22:44 +0200

On Mon, 2019-10-21 at 14:54 +0000, Kent Watsen wrote:
> 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.

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

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