Hi,
A variant on your suggestion:
Rather than "diagnostics true;" a potentially more general way of
handling this could be a generalized schema flag to indicate that a
particular node (and its children) is never returned unless explicitly
requested. E.g. "hidden: true" instead of "diagnostics: true". The
data would only be returned if either (i) the filter explicitly
indicated that hidden data should be returned (as per Kent's
suggestion), or possibly also (ii) if the request path (or filter)
explicitly specified the hidden node(s).
Thanks,
Rob
On 15/12/2016 19:23, Vladimir Vassilev wrote:
Hi,
Here is a summary of the proposed solutions so far:
* The solution with introduction of YANG statement "diagnostics
true;", additional datastore and NETCONF protocol change. IMO that
sounds heavy but valid solution.
* The solution with RPC returning the data as output. IMO has the
limitation of not presenting the diagnostics data in the data tree (no
valid instance-identifiers to be used in notifications). But is the
simplest to have in place.
* The solution with RPC enabling the containers only for a certain
session.
I thought also of this alternative solution: The solution is to avoid
clobbering the replies to <get>s without filter or <get>s with filter
matching only parent nodes of the "diagnostics state" container data
and not return those nodes in the reply except in the cases the filter
matches data nodes part of the diagnostics data explicitly.
Example for /interfaces-state/interfaces/diagnostics (using xpath
filter for brevity but valid for the "subtree" case):
These skip "diagnostics":
<get><filter type="xpath" select="/interfaces-state"\></get>
<get><filter type="xpath" select="/interfaces-state/interface"\></get>
These return "diagnostics":
<get><filter type="xpath" select="/interfaces-state/interface/*"\></get>
<get><filter type="xpath"
select="/interfaces-state/interface/diagnostics"\></get>
This looks like a violation of RFC 6241 6.2.5 bullet 12 but IMO the
container is non-mandatory diagnostics data so returning it only when
someone really wants it and not otherwise is the definition of the
solution to the problem.
/Vladimir
On 12/12/2016 05:47 PM, Kent Watsen wrote:
Hi Robert,
You’re right, it should’ve been the <get-data> (not <get-config>).
However, I think that it’s better to use a flag on the
<operational-state> datastore, rather than to define a new
datastore. Not only would it mimic how with-defaults works, but it
also seems more intuitive from a retrieval perspective, as the
diagnostics nodes could be sprinkled throughout a data model, and a
single <get-data> could return all nodes (not just the diagnostics)
for a given subtree. Thoughts?
Separately, from a modelling perspective, presumably there would have
to be an additional flag to go with the config false flag, something
like the below. Is this what you were envisioning?
container thermostat {
leaf configured-temperature {
type int8;
}
leaf current-temperature {
config false;
type int8;
}
container diagnostics {
config false;
diagnostics true; <-- new flag here
...
}
Is all this leading up to a draft? ;)
Kent // contributor
*From: *Robert Wilton <[email protected]>
*Date: *Monday, December 12, 2016 at 6:10 AM
*To: *Kent Watsen <[email protected]>, Andy Bierman
<[email protected]>
*Cc: *"[email protected]" <[email protected]>
*Subject: *Re: [netmod] Modelling different "levels" of data in YANG
Hi Kent,
On 10/12/2016 00:59, Kent Watsen wrote:
> I prefer not to use specialized <get-foo> operations.
Agreed, I was thinking something more along the lines of:
<get-config>
<source>
<operational-state/>
</source>
<with-diagnostics/> <--- note this flag here
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config";
<http://example.com/schema/1.2/config>>
<foo>
<bar/>
</foo>
</top>
</filter>
</get-config>
Thus explicitly requesting all the extra stuff get returned...
Yes, that is roughly along the lines that I was thinking.
Or building on draft-nmdsdt-netmod-revised-datastores:
- presuming the existing of a <get-data/> operation to generically
return the contents of any datastore,
- defining a new <diagnostics> datastore that contains the contents
of the <operational-state> along with all config false schema nodes
labelled as "diagnostics true".
<get-data>
<source>
<diagnostics/>
</source>
<filter type="subtree">
....
<get-data/>
Thanks,
Rob
> In the usage model that Rob described, the service tech will be
> setting diag-mode to 'system' then retrieving the extra
'diag-stats',
>then setting diag-mode back to 'user'.
Right, but this does not seem ideal as the diag-mode toggle is a
global setting that would affect all clients for some window of
time, or do we envision diag-mode dropping the system down to
single-user mode?
Kent // contributor
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
