On Tue, Jul 18, 2017 at 10:57:11AM +0200, David Lamparter wrote: > Jürgen, > > > On Mon, Jul 17, 2017 at 11:51:49PM +0200, Juergen Schoenwaelder wrote: > > I am still not sure what the problem is. We proposed that the > > <operational> datastore always reports the values that are in use, > > whatever their origin is. This seems simple and clear if you want to > > troubleshoot something. > > This is not about the value - this is about the separate single bit of > information that answers the question "is this value in use?" > > My understanding is that the NMDA design wants to communicate this > single bit of information to the client that retrieves data from the > operational datastore.
Yes, 'in use' <=> 'there is a value' in <operational> (the conceptual datastore). > I'm arguing that this single bit of information should not be > transported as "is the value present or absent?", because defaults > specified in the model can interfere with the absence of values. They interfere (i) if you make them interfere or (ii) you have intermediaries that mess around with the data without telling you that they did so. We are trying to resolve (i) by definition of semantics and (ii) seems outside of what specifications can deal with. > > > If this is implemented in an older NETCONF server that does this > > > unconditionally, this effectively breaks operational state retrieval > > > even if the system software does provide correct data with or without > > > defaults. The NETCONF server would just (validly) remove all values > > > that are the same as the model's default -- which then the client would > > > interpret as "these values are not in use". > > > > RFC 6243 was written before <operational> did exist and we propose > > that <operational> always reports the values in use (regardless > > whether they match defaults or not). > > Yes, you can make this work if you specify that the NETCONF server MUST > NOT make any additions or removals regarding defaults for operational > requests. I'm just saying this won't be robust. This is what we are trying to specify. > > > This, for me, lends the conclusion that this would be massively fragile, > > > even if a specific combination could make it work. My position hence > > > changes from "this doesn't work" to "please don't do this, even if it > > > may work." > > > > Always reporting the value in use should be fine. If libraries mess up > > the data it seems a library issue. Libraries should not mess around > > with <operational> data. The data in <operational> data is the ground > > truth of what the device is really doing, messing around with it > > before passing it to an application is not recommended. > > Sure -- I'm not concerned about the value. I'm concerned I won't be > able to tell whether the value is "in use". This is 2 error cases: > > - the value in use is equal to the model's default, and due to mangling > it's misrepresented as "there is no value" / "the value is not in use" > - the value is not in use, and due to mangling it's misrepresented as > "the value in use happens to be the default value" I do not think server randomly mangle data. I am concerned about reporting 'fake' values for not in use leafs with metadata that such leafs are not in use. This seems pretty costly (there usually is lots of stuff not in use). > > > The solution I would suggest would be to have "is the value in use?" as > > > metadata just like the origin. It can either be a new value on the > > > "datastore" identity (=> if a value is not in use, there is no way to > > > report what datastore it came from), or alternatively it can be a > > > separate metadata annotation (=> you can report not-in-use and still > > > have the value and its origin - if that makes sense, which...) > > > > > > (I'm leaning towards adding "not-in-use" on the origin metadata > > > annotation, as opposed to a separate boolean metadata annotation.) > > > > But if something is not in use, it may not even have a value. So I end > > up reporting fake values for things that are not is use decorated with > > metadata that these fake values are not in use? Does not sound very > > efficient to me. > > I would actually suggest that the default for the _origin_metadata_ is > "not-in-use", so you can in fact leave it out of the reply, and the > client knows reliably that it's not in use -- even if something in the > data path processes/interferes with defaults. In XML, metadata is encoded as XML attributes so I need to ship an XML element to ship the XML attribute and hence I need a value (and an empty value might violate the YANG data type contract, so I need a fake value). This does not seem a good proposal to me. /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
