Re: [netconf] ietf crypto types - permanently hidden

[Juergen Schoenwaelder <[e-mail]>]

On Wed, May 01, 2019 at 09:19:38AM -0700, Andy Bierman wrote:
> 
> This seems to be a good test for whether NMDA is useful as designed.
> It seems obvious that something has to be stored in <running> and
> then transformed as it is applied to <intended>.
>

The issue here seems to be that you create a resource that you would
like to be partially accessible as config and partially not accessible
at all or only as applied config in operational state. The question is
how to model that, i.e., the binding between config part and the
internal state part. Do we have any other similar resources or is this
really a very special case?

We discussed the 'create user account' case where often users ids are
allocated as a side effect of creating an account but the allocated
ids then becomes regular config, i.e., the config can be copied and
restored as one would expect. This is not really the same case that we
have with locally created keys.

An alternative might be to consider a locally generated key entirely
operational state (applied config): You invoke an RPC to create a key
and you give it a name and then it exists as named operational state
(applied config) until you delete that named operational state. If you
want to configure a transport that refers to such a key, you do this
via a name binding, pretty much in the way we apply interface
configuration to an interface with a matching name. Perhaps this is a
model that could work.

Perhaps Martin has even better ideas.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>