Hi, Andy, all From: Andy Bierman [mailto:[email protected]] Sent: Saturday, December 18, 2021 2:06 AM To: Kent Watsen <[email protected]> Cc: maqiufang (A) <[email protected]>; [email protected] Subject: Re: [netmod] Must offline-validation of <running> alone be valid?
On Fri, Dec 17, 2021 at 7:11 AM Kent Watsen <[email protected]<mailto:kent%[email protected]>> wrote: Andy, et. al., I cannot find any RFC text that says <running> has only nodes created by a client. Really? Interesting. Still, I know it’s a mantra we’ve held closely for many year, right? No. Quite the opposite. <snip> [Qiufang Ma] Kent and Jason said that the “shared objects” is the primary <system> configuration use cases. I do agree. In Huawei’s implementation, The server also generates hundreds of system data objects(service templates, predefined policies, etc). Physical resource related configuration is really only a small part of that. And as you mentioned, there is no RFC text says <running> have only nodes created by a client. Actually, in our implementation, we do allow system configuration to be populated into <running> automatically when it is generated, because copy/paste for reference is painful. That is, all the system configuration is really a part of <running>. But our customers do complain that when retrieving <running> they usually find a large number of configuration data objects not defined by themselves, most of which are irrelevant to their own configurations and they have no idea where they are come from. I also tried to bring this idea to the IETF(https://datatracker.ietf.org/doc/html/draft-ma-netconf-with-system-02#section-3.1) and would like to collect some more feedback, it seems that the WG thinks we want the client to fully own the running datastore, the server should never auto-populates <running> unless asked by the clients. Best Regards, Qiufang Ma There was a brouhaha back when I proposed the "keystore” draft have an “action” called “generate-private-key” that would insert the generated key into <running>. Claims were made by prominent members of this list that it’s bad form for anything but a client to edit <running>. As a result, extensive effort was spent defining a mechanism enabling the generated key to be returned in the RPC-reply in an encrypted form (such that only the server that generated the key could decrypt it), all so the client could immediately return it to the server via a config push in order to preserve the sanctity of client read-backs. If current claims were true then, why didn’t someone just say it’s okay since the server is acting like a client under the hood? Maybe not a lot of non-security people were following the thread. IMO a better design would have been to introduce a "secure-NV-storage" concept. The keys are never exposed. Only labels are exposed and the client can store a reference to the key in <running>. Maybe Juergen proposed this idea. YANG-based management assumes that the conceptual API for a YANG device can be described by all the [module, revision, features, deviations] tuples (YANG library). There was an original assumption that <running> could contain all the information to describe this "real API". The original design was too simplistic so NMDA introduced <intended> and <operational> datastores. Now <running> no longer represents the "real API". It now contains some or all of the information required to produce the real API, which is now deemed to be <intended>. Not one of the mechanisms to transform <running> into <intended> is standardized. Now <running> + ??? is a combination of the real API and the "proprietary setup API". It has never been true that <running> is always valid. In hindsight, that MUST is really a SHOULD, post-NMDA. Inactive nodes cannot be counted against constraints (e.g. must, min/max-elements, unique). Constraints on config templates do not address the needed constraints on the expanded data. IMO it is too late "fix" <running> by placing any restrictions on the contents or who can edit it. NMDA (wisely) did not do it. A "system edit" is difficult to describe, especially in a controller-driven bootstrap framework. The immuable issue is just hidden access control, so tag data nodes with new metadata to expose that. K. Andy
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
