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
