Re: [netconf] ietf crypto types - permanently hidden

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Kent,

Inline with [RW]

From: netconf <[e-mail]> On Behalf Of Kent Watsen
Sent: 04 April 2019 17:23
To: Martin Bjorklund <[e-mail]>
Cc: [e-mail]
Subject: Re: [netconf] ietf crypto types - permanently hidden




and the creation of a private key that becomes (protected)
configuration is similar to the creation of a user account, where an
unused uid is allocated that becomes configuration.

AFAIK there is no standard model defined that actually do this.

Mostly true, though one might claim that <edit-config> is an example
of an RPC that modifies configuration.

[RW]
But in this case, the updated configuration is provided by the client, not the server.  I.e. it is clear which entity owns the configuration, and is the "source of truth".


The closest thing we have is the "type" of an interface:

          When an interface entry is created, a server MAY
          initialize the type leaf with a valid value, e.g., if it
          is possible to derive the type from the name of the
          interface.

If private keys are handled like this, then I can accept it.

This is not what is being asked for here.



But we
should NOT introduce special actions/rpcs that manipulate the
configuration.

Why not?  Not that it's a valid justification, but vendors do it already.
What would it take to make it be not "special"?   Would adding a
standard (yang-next?) "modifies-configuration" leaf to the action/rpc
definition suffice?

FWIW, I do agree with Balazs, and argued as much a couple years
ago, that the current approach is not best practice.  That said, I'm
more interested in the general-purpose use of rpcs/actions this way.

We have always said no, but the reasoning is unclear.  What are the
specific objections and is there anyway to alleviate them?

[RW]
I think that is bad practice for a server to inject configuration into <running>.  It makes it ambiguous as to which entity really owns the configuration.   I think that what is in <running> should be owned by the client, not the server.  I'm not saying that nobody does this, but I don't believe that it is the cleanest solution.

I'm OK with a server injecting configuration between <running> and <intended>, and using NACM to prevent that value from being read back from <intended>.

I'm OK with the server just reporting the default system allocated value in <operational>, again protected by NACM if appropriate.

Thanks,
Rob



Kent // contributor