Re: [netconf] ietf crypto types - permanently hidden

[Kent Watsen <[e-mail]>]

>> 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.


> 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?


Kent // contributor