Hi Jürgen, Kent, If we can take that interpretation (and I agree I think that was the spirit of how I thought that NMDA works, particularly for templating and inactive configuration).
However, my concern comes from the MUST in this paragraph of RFC 8342 (and RFC 7950 also states that <running> must always be valid): 5.1.3. The Running Configuration Datastore (<running>) The running configuration datastore (<running>) is a configuration datastore that holds the current configuration of the device. It MAY include configuration that requires further transformation before it can be applied, e.g., inactive configuration, or template-mechanism- oriented configuration that needs further expansion. However, <running> MUST always be a valid configuration data tree, as defined in Section 8.1 of [RFC7950]. And the current version of the system datastore draft (https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/), 5.1. Conceptual Model of Datastores, has text like: All above three types of system configurations will appear in <system>. Clients MAY reference nodes defined in <system>, override values of configurations defined in <system>, and configure descendant nodes of system-defined nodes, by copying or writing intended configurations into the target configuration datastore (e.g., <running>). Servers MUST enforce that configuration references in <running> are resolved within the <running> datastore and ensure that <running> contains any referenced system configuration. Clients MUST either explicitly copy system-defined nodes into <running> or use the "resolve-system" parameter. The server MUST enforce that the referenced system nodes configured into <running> by the client is consistent with <system>. Note that <system> aware clients know how to discover what nodes exist in <system>. How clients unaware of the <system> datastore can find appropriate configurations is beyond the scope of this document. But, if the WG agrees that for NMDA, the actual validation happens on <intended> and not <running> then I understand that to mean that <running> on its own may not be valid, and it is only "implicitly valid" after doing the processing between <running> and <intended> and <intended> must always be valid. Further, I think that this means that there isn't any requirement (from a validation correctness point of view) to require system configuration to be copied into <running>. Of course, there may be other reasons why a client may want system configuration to be copied into <running>, e.g., so that it can be returned in a get request of <running>. If the WG agrees that this is the right direction then I think that it would be helpful for the system configuration datastore to perhaps update (or clarify) section 5.1.3 of RFC 8342, and perhaps provide an updated diagram with how the system datastore fits into the picture. I think that there would be further updates required to the system configuration datastore draft to clarify the expected behaviour, and we should also think carefully about the text and perhaps examples in the truststore/keystore drafts (since they currently state that the keys/certificates must be copied into <running>, and I think that we are saying with NMDA that this is not required). Thanks, Rob > -----Original Message----- > From: Jürgen Schönwälder <[email protected]> > Sent: 26 March 2023 13:24 > To: Rob Wilton (rwilton) <[email protected]> > Cc: [email protected] > Subject: Re: [netmod] system configuration/datastore and the > keystore/truststore drafts > > Rob, > > my reading of Figure 2 of RFC 8342 is that validation happens on > intended and not on running. I assume the system config is folded in > between running and intended. This seems to be inline with the > approach taken by the system config draft. This, of course, leaves is > open what actually happens if keys are removed and cause a subsequent > validation error. Ideally, such a transaction key removal transaction > should fail, but whether this will be enforced if the transaction > takes place outside the configuration management system may be a bit > wishful thinking. > > /js > > On Sun, Mar 26, 2023 at 04:28:46PM +0000, Rob Wilton (rwilton) wrote: > > Hi, > > > > I'm in the process of AD reviewing Kent's keystore and truststore drafts in > NETCONF. > > > > In both of these drafts, there is a desire to be able to use keys or > certificates that are managed on the device, potentially as part of a TPM, > and yet be able to reference those keys/certificates from the device > configuration. There is also some reference to how this configuration may > work with the system datastore. > > > > https://www.ietf.org/archive/id/draft-ietf-netconf-keystore-27.html#name- > support-for-built-in-keys gives an example. > > > > Looking at the current version of the system datastore, > https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/01/, my > understanding is that this draft reinforces the requirement that <running> is > always valid. Hence any data nodes in the <system> datastore, that are > referenced from the configuration in the <running> datastore, MUST also be > copied into <running>, so that it validates. Unreferenced descendant > configuration (that won't stop <running> from validating) can be left in > system, which is then merged with <running>, and validated as part of > <intended>. > > > > This is the approach that the keystore/truststore explains. However, there > is separately the issue that the build in keys and certificates may be updated > via an out of band process, such that the current keys/certificates are stored > on the device, and a stale copy of the keys/certificates ends up in the > running configuration. The keystore/truststore draft mitigates this by > stating > that if the key/certificate config differs between <running> and <system>, > then the values in <running> are ignored and the values in <system> take > priority. However, my understanding is that this behaviour is the reverse of > what we normally expect when merging configuration in the <running> and > <system> datastores, where configuration in <running> overrides > configuration in <system>. Ultimately, I think that this means that we would > need special handling for key/truststore configuration rather than just > following the normal behaviour. > > > > Hence, I wonder whether we are making this more complex than > necessary. Rather than requiring that <running> is always independently > valid from <intended>, then would it not be simpler to allow <running> to > have invalid configuration but always require that whenever <running> is > changed then <intended> is updated and must always be valid. This would > allow <running> to reference configuration in <system> without requiring it > to be copied into <running>. > > > > I still think that we should allow the configuration to be copied into > <running> for clients that also want <running> to be validate independently > from <intended>, but otherwise, the requirement of copying keys are > certificates into running doesn't seem ideal. > > > > Any thoughts? > > > > Regards, > > Rob > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > -- > 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
