On Tue, Aug 11, 2015 at 12:12 AM, Juergen Schoenwaelder < [email protected]> wrote:
> On Fri, Aug 07, 2015 at 03:21:48PM -0400, Rob Shakir 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. > > SNMP has an even more complex naming scheme. > > > 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. > > You can have a NETCONF server without 'startup' and it still has > persistent running config. I have no clue what 'the lack of a > declarative configuration API' means. > > The startup datastore simply represents the config that will be used at the next reboot. It is useful to compare the running config to candidate or startup. > > * '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. > > There are commercial implementations that make use of candidate > datastores and the transaction, validation and rollback capabilities > they provide. You may decide that you do not need them but this does > not imply that nobody else will need them. > > RFC 6241 should be clear that the candidate is a scratchpad. It has no effect on the system unless and until a <commit> is attempted. Since NETCONF (incorrectly) couples the confirmed commit procedure with the candidate config, it is useful to programmatic APIs. In reality, confirmed commit has absolutely nothing to do with candidate, but there seems to be no interest in fixing that. > > 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. > > It is certainly up to you how you architect your NMS the way to think > it works best. I am just trying to explain how NETCONF and YANG > work. But I would expect that an NMS is able to integrate namespaces. > > We should not dumb-down the standard to support dumb NMS software. Datastores and namespaces are part of the standard. Neither are difficult to implement. The <selector, path> approach allows us to use the same path in > different datastores, this is considered to be a feature and not a > bug. > > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
