[netmod] Re: comments on system-config-08 draft

["maqiufang (A)" <[e-mail]>]

Hi, Andy,

Thanks for the comments, please see reply inline…

From: Andy Bierman [mailto:[e-mail]]
Sent: Wednesday, August 21, 2024 12:34 AM
To: NetMod WG <[e-mail]>
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