Hi, Jan In the second case you've described below, " servers accept references to pieces of hardware that are currently missing, and just mark them as operationally down." Is this missing hardware related configuration also not present in <running>? Would a server treat this configuration as invalid if not? NMDA does allow a user to configure an interface which is not physically inserted, but my understanding is that the interface configuration needs to first be present in <running> in order to be leaf-refed by other configuration (if the require-instance is true).
Any misunderstanding? Best Regards, Qiufang -----Original Message----- From: Jürgen Schönwälder <[email protected]> Sent: Monday, March 27, 2023 2:13 PM To: Jan Lindblad <[email protected]> Cc: Rob Wilton (rwilton) <[email protected]>; [email protected]; Kent Watsen <[email protected]>; [email protected] Subject: Re: [netmod] system configuration/datastore and the keystore/truststore drafts On Mon, Mar 27, 2023 at 04:04:34AM +0200, Jan Lindblad wrote: > Rob, Jürgen, Kent, WG, > > I am strongly opposed to giving up the idea that running must always be > valid. This is one of the landmark properties that has made NETCONF the most > useful management interface for network automation ever. For anyone not up > to that, we already have SNMP and there is also a wide assortment of > REST-based APIs out there. > > I'm slightly appalled :-) that dropping this tenet is even discussed. In > particular, I find it strange that such a small stone in one shoe would make > us consider abandoning the whole trip. During the development of NMDA, it became clear that implementations often validate intended and not running when ask them to validate running. It is all a question of how much do we execpt/allow to happen on the transition running to intended. Some say 'nothing', some say 'a little bit of expansion', some say ... Yes, its a slippery slope, but we started it with NMDA, not with the system datastore or crypto types. > I'm no crypto expert and know little about how TPM modules work, but I was > under the impression that part of the beauty with TPMs was that you would > *not* copy keys around in the rest of the system. Instead you'd just refer to > the keys in the TPM. This is similar to how you'd typically refer to hardware > in slots. > > So if we treat TPM keys like they were hardware, we are back to our usual > discussion about how to treat validity of running with respect to hardware. > Either servers reject references in running to pieces of hardware that > happens to be missing at this point in time (which may make it hard to > install backups taken earlier, if the hardware setup has changed since), or > servers accept references to pieces of hardware that are currently missing, > and just mark them as operationally down. No need to change any RFCs to go > with either of these approaches, I believe, and certainly not break > fundamentals. > > Does this make sense, or is there a crypto angle here that I am missing? Yes, ideally no copying would be needed since there is just a lazy reference by name. I do not recall the details why this is not the way the crypto models work. /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
