This is my reading as well. Despite being published 5 years ago, the pushback comes because there’s no *programmatic* way to prevent client breakage. There is a need to have a mechanism, like the “critical” flag (1), to signal when new behavior is required.
(1) https://github.com/netmod-wg/yang-next/issues/70 K. > On Mar 26, 2023, at 1:24 PM, Jürgen Schönwälder > <[email protected]> wrote: > > 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
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
