HI Alex,
Note, that when it comes to the NMDA <operational> datastore there are
no default values. Only the values that are "in use".
Thanks,
Rob
On 17/01/2018 19:09, Alexander Clemm wrote:
Hi Einar,
I suggest we add clarification that default values must be reported.
For on-change, clearly all changes need to be reported, whether the
change is to a default value or not, everything else would be
confusing. Also for periodic, it would be confusing to leave out
readings when a value is at default versus not (the object might also
have been deleted, etc). So, I don’t think we need to add a flag or
such that would allow to exclude defaults which appear to be of
limited benefit to applications while introducing a lot more
complexity to deal with corner cases such as the ones described.
--- Alex
*From:*netmod [mailto:[email protected]] *On Behalf Of *Einar
Nilsen-Nygaard (einarnn)
*Sent:* Wednesday, January 17, 2018 5:27 AM
*To:* [email protected]
*Subject:* [netmod] yang-push issue: draft-ietf-netconf-yang-push-12
and default values and RFC 6243
All,
In discussions with some customers and on implementation, the issue of
defaults has come up. For get/get-config we have the “with defaults
capability” defined in RFC 6243 that allows us to control the
behaviour with respect to defaults. To remind folk with an example, we
could have:
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<interfaces xmlns="http://example.com/ns/interfaces"/>
</filter>
<with-defaults
xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
report-all
</with-defaults>
</get>
</rpc>
The addition of the “with-defaults” tag and value determines the
behavior of the get in this example (taken from A.3.1 in RFC 6243
<https://tools.ietf.org/html/rfc6243#page-22>).
It strikes me that we need to have a similar mechanism for telemetry,
allowing a user to specify, for example, that for a periodic
subscription on a subtree, they also wish default values to be
reported. I think at minimum we need clarification on this, as section
3.7 of draft-ietf-netconf-yang-push-12 currently says:
/The content of the update record is equivalent to the contents
that would be obtained had the same data been explicitly retrieved
using e.g., a NETCONF "get" operation, with the same filters applied./
This text can currently only refer to a “get” as defined in RFC 6241
as there is no reference to RFC 6243 as yet. I think we need to
address this issue now to define expectations, even if it is to
explicitly not consider an RFC 6243-like mechanism or to say that we
only consider explicitly set values in telemetry, or…
Cheers,
Einar
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
