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
