For what its worth, the NMDA documents for NETCONF and RESTCONF posted today state that with-defaults only applies to non-operational datastores and that values are always reported for operational datastores, regardless whether they match any defaults.
/js On Wed, Jan 17, 2018 at 07:09:52PM +0000, 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:netmod-boun...@ietf.org] On Behalf Of Einar > Nilsen-Nygaard (einarnn) > Sent: Wednesday, January 17, 2018 5:27 AM > To: netmod@ietf.org > 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 > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
