Re: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt - REQ 6 clarification

[Benoit Claise <[e-mail]>]

Thanks Rob, that clarifies the situation for me.

Regards, Benoit
> On 14 September 2015 at 08:43:53, Benoit Claise ([e-mail]) wrote:
>
>> Re-reading this section 4.5, I understand 6A and 6C, but is 6B also
>> required?
>> Do we need to make the link between a config node and all the derived
>> counters/statistics it influences, which might be in different YANG
>> models btw?
> Yes - we need to deterministically retrieve, for a particular configuration object (e.g., interface, BGP peer) the set set of derived state nodes associated with it, such that we do not need to maintain complex mapping tables on the client side for this - and can efficiently query the server for them.
>
> For instance, knowing that we configured a BGP peer at $SOMEROOT/bgp/neighbors/neighbor[peer-address=‘192.0.2.1’]/config/{leaf-set} then we would find the counters at $SOMEROOT/bgp/neighbors/neighbor[peer-address=‘192.0.2.1’]/state/ - allows us to (based on the fact that we just configured a peer) retrieve the state and counters that a client application will likely want to check without having to map to some other (set of locations).
>
> Note that in previous discussions, it was expressed that this implied that the model had knowledge of how the protocol operates such that it was known that leaf A corresponding to some other derived-state leaf B. However, this isn’t true. As I expressed before, the intention is that it is possible for a NMS layer to easily retrieve the set of state objects that an interested client may require, without many disparate queries, based on the configuration path. The actual meaning may be completely unknown to this layer.
>
> The openconfig-opstate approach allows state and config to be defined in separate modules - since the ‘state’ module in this case can simply augment the relevant ‘state’ containers within the config model.
>
> Regards,
> r.
> .
>