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 <lho...@nic.cz> wrote: > > Ladislav Lhotka <lho...@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
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
