> Perhaps Kent can help us by summarizing why he believes copying is
> needed, i.e., why lazy references by name do not work for credentials
> stored in TPMs.
The truststore and keystore use-case entails the following concepts from
the system-config draft:
- Inactive Until Referenced
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-01#name-inactive-until-referenced
- Configuring Descendant Nodes of a System-defined Node (keystore draft only)
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-01#name-configuring-descendant-node
There is no inherent desire to copy these system-defined nodes into
<running> (nor in their entirety). The *published* version of those two
drafts only say to do so now because 1) that text was written before
system-config's originating I-D existed, 2) to ensure, e.g., "mandatory
true" nodes in <running> would exist, and 3) because that text hasn't
been updated since the system-config draft was adopted.
Rob raised a very good point in his recent AD-review that these
sections should not say that system-defined nodes have to be
copied into <running>, so as to leave the door open for lazy
referenced to the <system> defined nodes.
Additionally, these sections define behaviors & mechanics about the
immutability nature of the data, when really such should be defined
only in the system-config and immutable-flag drafts. That said, I
don't want to introduce a normative reference to those drafts that
would result in a MISREF.
Kent
> Concerning the larger discussion about validation of running vs
> validation of intended: During NMDA developed, it became clear that
> some not quite relevant NETCONF implementations do actually validate
> intended when you asked them to validate running. And what happens
> between running and intended is not covered by any standards as of
> today. Is this bad? In a way yes and no. It is bad because some
> vcendors may read this as an invitation to do things that really mess
> up a client's expectations but it is perhaps also good since the
> distinction acknowledges reality.
>
> The discussion around system config is old (much older than the I-D)
> and this is a grey area and I assume that every bigger server has some
> places somewhere where it "cheats" a bit to deal with the problem.
> There is the option to just leave it like that, i.e., to trust that
> vendors will understand to not go over board with magic system config
> "cheats" or to work out solutions that may introduce another datastore
> or solutions to tag config in running that is not really under the
> control of a client (immutable flags play in here and perhaps the WG
> needs to discuss whether really both a system datastore and immutable
> flags are needed - at the end immutable config is coming from
> somewhere).
>
> The only lazy binding mechanism we have is to refer to resources by
> name. If the name resolution does not work out, the relevant config is
> not applied. This kind of works if data models are designed for it but
> this adds complexity to the modeling process.
>
> /js
>
> --
> Jürgen Schönwälder Constructor University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <https://constructor.university/>
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
