Hi,
On 07/12/2016 13:30, Vladimir Vassilev wrote:
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.
Given that there is a desire (draft-nmdsdt-netmod-revised-datastores-00,
section 6.4) to deprecate "/foo-state" and to merge it with the
configuration held under "/foo" then I would think that introducing a
new top level "/foo-diagnostics" would seem to be heading in the wrong
direction.
Athanasios' suggestion to just define RPCs for this information, and
only make the information available via RPC operations, seems like a
reasonable one. Clients don't get spammed with stuff that they don't
care about, but the information is still programmatically available if
it is required.
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.
Alas, xpath filtering is optional, and I'm not sure how many devices
have implemented support for it. Further, this still requires every
client to be coded to avoid receiving the information that they are very
unlikely to be interested in.
I would much prefer a solution where the clients don't get this (mostly
noise) data unless they explicitly ask for it. Otherwise for an
Ethernet interface you might return 10 leaves of potentially useful
opstate information, along with 50+ leaves of quite low layer
diagnostics information that is likely to be of very little use except
for to the select few people that are actively involved in trying to
diagnose hardware faults.
Thanks,
Rob
/Vladimir
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
