On Tue, Jul 18, 2017 at 04:50:19PM +0200, David Lamparter wrote: > Let me rephrase/develop my suggestion. > > - don't send anything for a value that's not in use. > - specify that if a client can't find an origin attribute, e.g. because > the entire tag is missing, it MUST assume "not-in-use" > This implies: > - data that actually is in use MUST always have an origin attribute, > otherwise the client will go "not-in-use" > > This kinda forces people to do the right thing not only for not-in-use > signaling, but also for the origin metadata. No easy way out in just > not sending it, if you don't know you have to own up your amnesia and > admit to "unknown". > > ... and with the current wording in the draft, it already suggests a > value in all cases, since the last paragraph in in 4.7.3 is: > In the case that a device cannot provide an accurate origin for a > particular data node then it should use the origin "unknown". > > I'm just saying that to determine whether a value is in use, the > data's consumer must look at the origin attribute (including its > absence), not at the fact whether there is some value.
This is the relevant current text: Requests to retrieve nodes from <operational> always return the value in use if the node exists, regardless of any default value specified in the YANG module. If no value is returned for a given node, then this implies that the node is not used by the device. I am still unsure why the presence of an origin attribute adds value here. The last sentence clearly says 'if no value is returned for a given node, then this implies that the node is not used by the device.' FYI: There is another ongoing discussion whether origin metadata for config false nodes makes sense at all and one option considered right now is to have origin metadata only on config true nodes. If so, you can't overload the presence of origin metadata with another meaning. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
