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
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
