Re: [netconf] Comments on crypto types presentation

[Kent Watsen <[e-mail]>]

Hi Juergen (and Joe and Jason),

> Just for clarification: If we do #3 now, we can still do #2 later?

Yes, as far as we know, the “algorithm" id can be added later.
 
Assuming existing versioning rules (Sec 11 in RFC 7950), the “algorithm” node would have to be added then as "mandatory false", which might be okay.  Of course, the YANG-versioning work (in NETMOD WG) should be published by then so, in the worst case (i.e., it needs to be mandatory true), the YANG module could legally introduce the non-backwards-compatible change.


> If the answer is 'yes', then option #3 is attractive as we gain time
> and hopefully implementation experience and we can add protocol
> specific key generation RPCs in a second step.

Indeed, time-to-market vs completeness.  However everyone should be aware that the deferral would likely be  "a few years", if not more.

I’m personally okay with that, and perhaps even prefer it, since it more quickly gets the monkey off my back.  

Devil’s advocate position: not supporting keygen would be a disservice to the industry as whole, and there’s something to be said for striking while the iron is hot.


PS: regarding enum vs identityref.  Option 1 could also use identityref…and, in fact, it did before.  The reason Option 1 changed to using an enum was so that a set “value” could be associated with each algorithm.  That said, the need to set a value was never clearly explained and, IMO, doesn’t exist.  My only point is, don’t let enum-vs-identity be the key differentiator in thinking about Option 1-vs-2.   

Kent // contributor


> Otherwise, option #2
> seems more attractive to me. In a TPM world, it seems key generation
> on the device is somewhat essential to have.
> 
> /js
> 
> On Mon, Apr 06, 2020 at 02:39:08PM +0000, Joe Clarke (jclarke) wrote:
>> Since we are running short on time at the VI, I want to register some comments on the list.
>> 
>> * I ultimately like option #3 to progress the base client-server work and see if the key gen feature is desired down the road (enough to pick it back up).
>> 
>> * Second, I prefer option #2 for the reasons discussed as well as because of the comment Jason raised that I think the identityref approach makes sense.
>> 
>> Joe