Re: [netconf] updates to client/server drafts

[Kent Watsen <[e-mail]>]

Hi Juergen,

Thanks for broaching the topic, I'm hoping we can suss out such things before the drafts enter Last Call in 2-3 weeks.


>> 1) in crypto-types, replaced the 'action' statements with 'crypt-hash' like equivalents.  If folks don't like the "verbs", then we can simply remove them, having no solution for asking the device to generate a key or install a hidden key.
>> 
> 
> I am not sure this approach. This just hides the discussion in a
> special purpose construction:
> 
>               Without the optional '-and-hidden' postfix, the generated
>               key pair is stored in the configuration data store as if
>               the values had been configured by the client.


True, this special purpose construction sidesteps us needing to resolve the larger "can actions effect configuration" discussion.  But perhaps that is okay given that the need to have actions effecting configuration is exceedingly rare?   It's clear that you're not thrilled by this approach, but it's unclear if the reason you're not thrilled is because of the approach or because it's sidestepping the larger discussion.    Also, what do you propose we do about it?  Choices:

a) nix the "verbs", leaving the solution for asking the device to generate a key and install a hidden key to a future update.
b) resurrect the 'action' based discussion.
c) cautiously move forward with the "verbs" approach.
d) something else?




> A more general note: I assume that humans configuring systems are
> mostly familiar with common file formats for X.509 certificates like
> .pem files or similar. It seems these formats can't be used with the
> YANG module and that tools are needed to extract the pieces of data
> and to ship them to the server. Perhaps usability would be higher if
> the module would support upload/download of X.509 related material in
> commonly used formats.

This comment seems to apply to the entire client/server suite of drafts.  I believe that your statement regards the somewhat heavy use of CMS structures for conveyed certificate chains, rather than the non-standard though nearly ubiquitous concatenation of PEM-encoded certificates.

I believe that bi-directional `openssl` based one-liners exist for converting between CMS and concatenated-PEMs.  Would it help if the crypto-types draft included an Appendix section to supply the `openssl` commands for just the 'trust-anchor-cert-cms' and 'end-entity-cert-cms' typedefs?  [FWIW, constructing said CMS structures in Python is trivial.]


Kent // contributor