Re: [netconf] Create IANA-defined modules?

["Per Andersson (perander)" <[e-mail]>]

From: Kent Watsen <[e-mail]> on Monday, June 14, 2021 18:22:
>
> Since the discussion has been mostly about *how* to create the IANA-defined module (not *if* we should, e.g., dropping the work for some future effort to pickup), I take it that folks believe having the ability for configure supported-algorithms is needed now.  As no one offered to help (:sigh:, and people wonder why this work takes so long), I wrote the attached script that creates the attached module directly from the data obtained from the IANA-maintained "TLS Cipher Suites" sub-registry of the "Transport Layer Security (TLS) Parameters” registry here: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml.  The resulting module is also attached.
> 
> Tom, you will be happy to know that the all the identity names begin with “tls”  :)    Also, there are no “feature” statements, since there is nothing in the source registry that can be used to generate “if-feature” statements.  Out of the 347 algorithms listed in the registry,  310 algorithms are marked “status deprecated” (driven by the “recommended” column having value ’N’), and 7 algorithms are marked “status obsolete” (driven by the "SC-tls-des-idea-ciphers-to-historic” reference).

I was on the brink to volunteer, sorry that I didn't raise my voice in time.
Good work, nonetheless.


> Regarding if to use a  “config false” tree or an RPC, Per makes an interesting point about “must" and “when” expressions, though I do wonder how that would play out in practice, as said expressions would (presumably) be defined under “config true” nodes and hence couldn't reference the “config false” values?  Maybe Per could say some more about the use-case in mind.

I saw a use case where some subset of the configuration tree
(e.g. a list of devices or restconf/netconf tls servers) could have
a schema when expression depending on the server's supported
algorithms.

However, I did not think it through that they were config nodes that
were going to access non-config nodes.


> No one responded regarding if we should use identities or enumerations.  The attached sample module uses identities, but it would be an easy thing to change the script to generated enumerations - thoughts?
>
> Again: if “identity” statements are used, and the module is *implemented*, it would NOT mean the server supports all (or even any) of the algorithms. This would only be known if the algorithm appears in the “supported algorithms” "config false” list.  Does anyone feel this is a misuse of YANG?  IMO, YANG identities needing to be implemented is not very useful in practice, and so I don’t view that as a negative in the slightest.

AFAICS identities and enumerations support the same set of
sub-statements .

Using identities it would be possible to derive them from
other identities, and by doing so encode some more
information (e.g. is it a symmetric or asymmetric key etc).
This could hold some value.

>From reading RFC 7950, it looks to me like identities are
much like atoms or named constants; their existance in
an implemented module does not imply or guarantee any
working (code/server) implementation. (Correct me if I'm
wrong here.)

I think identities should be used.


--
Per