On Fri, Dec 17, 2021 at 7:11 AM Kent Watsen <[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> > > > 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
