Re: [netconf] updates to client/server drafts

[Martin Bjorklund <[e-mail]>]

Juergen Schoenwaelder <[e-mail]> wrote:
> On Tue, Jun 11, 2019 at 08:53:57PM +0000, Kent Watsen wrote:
> > 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?
> 
> I am strictly against hiding actions by encoding 'verbs' in an ad-hoc
> data format. I rather not support creation of keys on the device.

Remember we had this cases:

1.  upload of keys
2a. generation of keys on the box that will go into hardware protected
    storage (and never be accessible)
2b. generation of keys on the box that will be stored on disk
    (and never be accessible over the mgmt interface)
3.  generation of keys on the box that become (protected) configuration


I think the previous version of the draft (with YANG actions) handles
1 and 2 (a and b with trivial updates).

It is only (3) that we don't have a solution for that everybody
accepts.

So perhaps we should solve 1 and 2a and 2b, and publish that, and
leave 3 for the future?


/martin