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

[Kent Watsen <[e-mail]>]

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.

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

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


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


> 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