Hi, Rob Shakir <r...@rob.sh> wrote: > > > 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.
One example is SNMP, where a tuple (enginge id, context, OID) is needed. In general you also need a device id of some sort (address, port). How the necessary info is handled seems to be an implementation detail, and it seems to be pretty trivial, but maybe I have misunderstood something. > 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. I do not understand this comment. Are you proposing some kind of changes to current YANG models to handle 'startup'? Are you proposing changing NETCONF? > * '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. If I understand your terms correctly, 'running' would be the intended configuration. 'candidate' is a separate structure, that is not part of the intended configuration. Are you proposing some YANG or NETCONF changes to handle the candidate? > 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. Even if we had the four separate datastores 'startup', 'running', 'candidate', and 'applied', it is not entirely clear to me why the datastore would have to be carried together with the path internally all the time. (We do not carry the current datastores in our system today). Maybe this is an implementation issue? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
