tom petch <ie...@btconnect.com> writes:

> From: netmod <netmod-boun...@ietf.org> on behalf of Ladislav Lhotka 
> <ladislav.lho...@nic.cz>
> 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.
>
> <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.

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

Reply via email to