On Tue, Jan 10, 2017 at 9:07 AM, Robert Wilton <rwil...@cisco.com> wrote:
> > > On 10/01/2017 16:16, Juergen Schoenwaelder wrote: > >> On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote: >> >>> On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder < >>> j.schoenwael...@jacobs-university.de> wrote: >>> >>> On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote: >>>> >>>>> I think itt is not realistic to say that datastores are optional. >>>>> >>>>> e.g. <enabled> leaf: If there is a standard way to enable/disable >>>>> config >>>>> then individual "enabled" leafs are redundant. However XPath >>>>> (must/when) >>>>> has no way to describe if the subtree is enabled (which is a >>>>> >>>> show-stopper) >>>> >>>> I may not understand what you are saying. From what I know, there are >>>> implementations that allow to 'comment out' nodes and subtrees and >>>> that work with clients in a backwards compatible way. >>>> >>>> <foo-config> vs <foo-oper>. If the applied or operational datastore is >>>>> assumed, >>>>> then there is no need to model the redundant config-as-operstate. >>>>> If this is left out of the model, then the datastore becomes mandatory. >>>>> If it is left in the model, the datasore becomes redundant. >>>>> >>>>> The basic premise that these datastores are optional is flawed. >>>>> One cannot design a YANG module assuming the datastores are present >>>>> if they are in fact optional. >>>>> >>>> The claim that all datastores are mandatory is equally flawed. >>>> >>>> >>>> correct -- nobody is saying that. >>> >> Well, I originally commented on the statement that intened would be >> required and adding complexity - it does not. >> >> >>> The reason this is different is that the YANG objects are impacted. >>> Candidate vs. running has no impact whatsoever on the set of >>> YANG modules. The protocol is not self-selecting some objects >>> and making other objects invisible. >>> >> Yes. And the same is true for intended as long as an implementation >> does not support templates or inactive configuration objects. >> >> But if I want to model <foo-state>, I will soon have to decide >>> to use <foo-state> and allow all protocols to read it or >>> model get-state(foo) and require a different module for each >>> protocol. >>> >> If you do /foo and /foo-state, things will just work with or without >> an operational state datastore. >> > True, but there would also be an undesirable duplication of data in the > data tree. > > > If you have only /foo, then an >> operational state datastore may come in handy if you have to support >> config and state with different lifetimes. >> > I think that this may be more than "come in handy". I think that there > would be key information that clients would expect to be available in a > model but wouldn't be easily retrievable without supporting the operational > state datastore. Specifically you lose the ability to easily query an > operational property of a system that can be configured, but hasn't been > configured. > > Example: Consider an Ethernet interface speed leaf that in the running ds > represents the configured speed, and in the operational state ds represents > the actual operational speed in use. Normally, the operational speed would > default to the maximum speed supported by the hardware (or the negotiated > value if auto-neg is in effect). If a device doesn't support the > operational state datastore then you wouldn't be able to query the > operational speed of an interface if it hasn't also been configured. > This is my concern -- that data modelers will put in the <oper-speed> leaf to make sure all protocols (including existing NETCONF) can retrieve the oper-value. For many decades, this has been the design approach. There have not been many leafs where interactions with control-plane protocols is a factor. The SNMP-style solution is ad-hoc, but the problem is somewhat rare, so it didn't really matter. The premise now seems to be that the problem is no longer rare and lots of <oper-speed> type of data is needed. I am not even sure this will be true if I2RS is constrained to RIB data (as the charter dictates). Presumably, the same instrumentation gets invoked for get(oper-speed) as get-state(admin-speed) > If the device support the with-defaults extension and appropriate options > then they could presumably retrieve the "complex default" value from the > device using one of the with-default query parameters. > with-defaults is a bit different because the YANG module can provide the default even if the server won't. > > Rob > > > >> /js >> >> > Andy
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
