Juergen Schoenwaelder wrote:
But you are right, it is not just the path that is needed to identify data residing in configuration datastores. It is in general a tuple <selector, path> and for configuration data the selector is a configuration datastore name.
Thanks for the clarification. Do you have examples of other (i.e., non-NETCONF) systems that utilise this convention that a path is not an absolute reference to a certain data node? Reviewing with various interested parties, I'm not sure that there are clear cases that form a precedent for this.
If we consider that this then might drive some new behaviour where the systems architecture for NMS differs from elsewhere then we might want to question whether this is necessary complexity. Indeed, for me this comes back to one of the discussions about the other datastores that we had on an interim call.
* 'startup' is really a property of the intended configuration - as to whether it has been made persistent. In general, I see very few changes that are made where we interact only with the persistent version of the intended configuration; and even fewer where the intended configuration is not made persistent. In both cases, it tends to be the lack of a declarative configuration API that drives the need to interact with either.
* 'candidate' is again a property of the intended configuration - insofar that the 'candidate' set of configuration represents a set of changes that have not been requested to be transitioned to the 'applied configuration'. This makes sense when a human is working through building up a transaction (configure protocol X, protocol Y .. protocol Z, then commit) - but isn't quite so clear when it programmatic interaction with the network.
It is quite trivial for me to see cases where an external NMS would never really need to interact with either of these datastores - such that it's quite tricky for me to determine that we really want to architect the entire NMS to be able to carry the <selector,path> tuple (stealing your terms, thanks!), especially if this means that it has to work entirely differently w.r.t paths than the rest of OSS.
r. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
