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

[Andy Bierman <[e-mail]>]

On Wed, Aug 21, 2024 at 9:28 AM Kent Watsen <[e-mail]> wrote:

> Hi Andy,
>
> 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.
>
>
> This is why there was so much effort before to copy system-defines nodes
> (the so called “shared objects”) into <running>, i.e., so legacy clients
> wouldn’t break.  This is my #1 case in the other thread.
>
> The other approach is to version the protocols with a mandate that clients
> grok <system> and no longer “running alone must be valid”.
>
> No one is talking about changing the existing NC/1.1 and RC/1.0 contracts.
>
>

So you are planning new protocol versions with NBC changes as well?


> 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 is not true.  XPaths are only resolved in the datastore that is the
> context.  E.g., if validating <running>, running is the context.  If
> validating <intended>, intended is the context.
>
>

So what is the point of the system datastore?
If all references in <running> must be to other nodes in  <running>,
then the 'immutable' flag or other metadata is good enough.

I do not understand why metadata is OK for so many other properties, but a
special datastore
is needed for system-created="true".  Not just a special datastore, but
also breaking how <running>
has worked in routers from Day One.


I don’t think it is possible to validate <system>.  I also don’t recall the
> draft saying one way of the other.  It might be good for the draft to say...
>
>

I don't understand how removing the system config from <running>
makes it easier for clients to configure a server.  Checking one datastore
so you can
create parent nodes and other referenced nodes in another datastore is
complicated.
IMO the current approach (plus immutable flag) is simpler to use.



>
> Obviously, an old client is unaware of the new <system> datastore and will
> never provide the 'resolve-system' leaf.
>
>
> I think that the current plan is to remove the ‘resolve-system’
> parameter.  Perhaps pending more responses from the WG…
>
>
So resolve-system means "figure out which missing system nodes to magically
add, or the edit will fail".?
Seems like setting this to 'false' is a bad idea.


> 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>.
>
>
> It cannot, the parent nodes need to be in <running> as well.   This is my
> #3 case in the other thread.
>
>
> Kent // contributor
>
>
Andy