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

[Andy Bierman <[e-mail]>]

On Wed, Aug 21, 2024 at 1:05 AM maqiufang (A) <[e-mail]> wrote:

> 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.
>
>
>


No, I do not agree that system config "comes and goes" and therefore no
system config can be in <running>.
Metadata can be used to identify system data vs. client data.

The example in the appendix shows a device that would boot without any
interfaces in <running>.
They would only be in <system>.  If this is the case, then all non-NMDA
clients and all current NMDA clients
need to be rewritten to know about the <system> config.   IMO breaking all
existing clients would be a bad idea.



> 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.
>


I am confused, because I was told the reason <system> is needed is so
leafref and XPath in <running>
can reference the system config (i.e. nodes in <running> require nodes from
<system> to be part of the data tree.)
This violates the XPath context rules in RFC 7950.
This prevents offline validation of <running>
This violates the MUST requirement in RFC 7950 that <running> MUST be valid.



> 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.
>
>
>

Obviously, an old client is unaware of the new <system> datastore and will
never provide the 'resolve-system' leaf.
I do not understand how config can be changed, e.g. an address is assigned
to an interface,
if the parent interface is not in <running>.




>
>
> Andy
>
> Best Regards,
>
> Qiufang
>


Andy