On 12/06/2016 10:03 PM, Alex Campbell wrote:
IMO using an action or rpc is an okay solution for now, certainly
better than than not including the data at all.
If I have to chose between RPC with 'output' containing the state data
for selected interface and mapping the data to a container/list not
under /interfaces-state (e.g. another top level container) I prefer the
second option since notifications and data models in general can refer
to it as part of the data tree. It allows for simpler monitoring and
implementation of alarms etc.
Perhaps in the future the client could specify which YANG modules it
cares about, in addition to a subtree filter. Then you could put the
extended diagnostic information into another module (using "augment"),
and clients that don't know about the extended diagnostic information
wouldn't request it, and clients that do would know to only request it
when they need it.
One can use xpath 1.0 filter. This option is already available. Example
<get> RPC retrieving only state data of interest.
...
<get>
<filter type="xpath"
select="//*[namespace-uri()='urn:ietf:params:xml:ns:yang:ietf-interfaces'
or namespace-uri()='urn:ietf:params:xml:ns:yang:ietf-system']"/>
</get>
...
Sane server implementations will skip the time consuming calbacks
retrieving detailed data defined in other modules then ietf-intefaces
and ietf-system.
/Vladimir
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
