Re: [netconf] IANA templates for algorithms

Kent Watsen <kent+ietf@watsen.net> writes:

> From our session at IETF 106, there was a suggestion to follow the “template” pattern forged by draft-ietf-dnsop-iana-class-type-yang, which provides an XSLT script that generates a YANG module by processing as input the XML for the separately maintained "DNS Parameters” registry, specifically https://www.iana.org/assignments/dns-parameters/dns-parameters.xml.  The IANA workflow is:
>
>     1) whenever updating the DNS Parameters registry...
>             - for whatever RFC may be requesting it
>
>     2) also update the YANG module...
>             - by re-running the XSLT script again over the updated XML file

Strictly speaking, the XSLT stylesheet is still intended only for producing the initial revision of the module.

Re-running the stylesheet on a later revision of the registry would essentially work, only the revision history would be lost. I don't see any easy workaround to this.

It is up to IANA (we can help them) to decide whether the YANG module will be updated as before, e.g. by manually adding new enums, identities etc., or whether they use the stylesheet and then manually edit the revision history.

Maybe it would be useful to write an informational RFC suggesting a workflow for these cases.

Lada

>
> The prerequisite for this process is that there exists separate registries to pull data from, i.e., the input to the XSLT script.  The closest comparable registries that we could pull from seem to be:
>
>  - for TLS: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
>  - for SSH: https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml
>
> Neither of these registries help us, at least not directly.  Yes, they provide enumerations for on-the-wire protocol values, but they fail to provide an enumeration for, e.g., a 2048-bit RSA key.
>
> Keying off Rob’s comment from the 106 meeting for the IANA process to engage expert reviewers, it seems that a process akin to the following is needed:
>
>     1) whenever some number of existing target registries are updated
>           - for now, just the SSH/TLS registries listed above
>
>     2) engage an "expert reviewer" to see if any of the new entries
>         regard an undefined algorithm and, if so, a TBD process is
>         used to add the new algorithms to the appropriate YANG
>         module (e.g., iana-symmetric-algorithms), which would be
>         automatically published by IANA.
>
> Drilling into step (2) some, the process might actually be:
>
>   2a) update some new TBD registry (e.g., “base algorithms”).
>         This would need to be done by a crypto expert (not the
>         NETCONF WG or YANG Doctors.  Good candidates might
>         the Security ADs or, perhaps better, the WG that published
>         the source RFC.
>
>   2b) run a script over the updated new TBD “base algorithms” 
>          registry to produce the desired updated YANG module(s).  
>          Presumably IANA could do this in the same way as will
>          Be done for the DNS Parameters registry.
>
> Obviously (2a) relies heavily on buy-in from the Security Area experts.  The buy-in needs to be both that this is an important registry to define and support the publication of an RFC that creates and defines rules for maintaining said registry.   Our “crypto-types” draft could be this RFC, if they’re okay with that.
>
> Rich, as someone more connected to the Security Area, what do you think about this plan and any ideas on how to proceed to get the needed buy-in?
>
>
> Kent // contributor
>
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67