Re: [netmod] IANA registries and YANG

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 <lhotka@nic.cz> wrote:
> 
> Ladislav Lhotka <lhotka@nic.cz> 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