Subject: [netmod] IANA registries

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 24 Nov 2021 09:13:42 +0100

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

---

From: tom petch <[email-masked]>
Date: Thu, 25 Nov 2021 17:02:26 +0000

From: netmod <[email-masked]> on behalf of Ladislav Lhotka <[email-masked]>
Sent: 24 November 2021 08:13

Hi,

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

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Nov 2021 18:35:34 +0100

> 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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 26 Nov 2021 09:30:00 +0100

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

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 26 Nov 2021 09:48:08 +0100

> — 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 tran…

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

> 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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 26 Nov 2021 09:58:14 +0100

Hi Lada,

> On 2021-11-26, at 09:48, Ladislav Lhotka <[email-masked]> wrote:
> 

Indeed, so you had to apply human intelligence to produce information that is not available for 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).

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

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

> 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

---

From: Robert Varga <[email-masked]>
Date: Mon, 29 Nov 2021 14:32:00 +0100

> 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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 29 Nov 2021 14:48:26 +0100

> the requester -- see https://www.rfc-editor.org/rfc/rfc7120#section-3.3 

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