Hi, Andy, Thanks for the comments, please see reply inline…
From: Andy Bierman [mailto:[email protected]] Sent: Wednesday, August 21, 2024 12:34 AM To: NetMod WG <[email protected]> Subject: [netmod] comments on system-config-08 draft Hi, I do not think this draft is ready. 1) Behavior changes to conventional datastores There seem to be NBC changes being made to the behavior of the conventional non-NMDA datastores, particularly <running>. I disagree that it is a problem that <running> contains some system configuration mixed in with the client configuration. The only problem is that the data is not editable by clients. The "immutable" flag draft provides clients with enough information to avoid 'access-denied' errors when editing system config. Changing the behavior of <running> seems to break old non-NMDA clients that expect the combined config. There are various implementations about system configuration, and some do put system configuration into <running>, but the vision has always been to give the client full control over <running>, right? System configuration comes and goes, which is beyond the control of operators, while I think <running> should be controlled with more predictability. 2) NBC Changes to XPath Changing the XPath evaluation procedures is an NBC change. In this case, also quite complicated to implement XPath across multiple datastores. System config could be visible in <running> using the immutable flag. Leafrefs and XPath are allowed to point at config=true in the same data tree. This does not require any changes to XPath processing. Referencing a special read-only datastore is no different than simply allowing the XPath to reference config=false. It is the same NBC change. I am confused by this comment, as no one has ever proposed to change the XPath evaluation procedures. If the intention is to make <running> alone valid, the proposed approach is to either copy the referenced system nodes into <running> or use the “resolve-system” parameter to allow the server do the copy thing. If <running> alone doesn’t have to be valid and only <intended> is subject to validation, then simply merge <running> with <system> to be referentially complete for <intended>. Neither case has proposed a direct cross-datastore reference. 3) resolve-system I am confused why a client would not resolve the system, since the <running> datastore needs these nodes so the client nodes can exist. Of course the client can resolve the reference and explicitly copy the missing parts from <system> into <running> (see sec 5.2), “resolve-system” is just an alternative for the clients that don’t wish a manual copy. It is optional to implement and clients *may* use. Andy Best Regards, Qiufang
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
