On Wed, Aug 21, 2024 at 9:28 AM Kent Watsen <[email protected]> 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
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
