Re: [netmod] draft-openconfig-netmod-opstate: Changes in -01

[Rob Shakir <[e-mail]>]

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.