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

[Juergen Schoenwaelder <[e-mail]>]

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.

>  * '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.

> 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.

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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>