On Tue, Jul 27, 2021 at 10:47 AM Rob Wilton (rwilton) <rwil...@cisco.com> wrote:
> Hi Andy, > > > > The comment at the end of my email was: > > “With this, I’m not sure whether we need the “includes-default” leaf > currently specified in the draft, but if we do, then I would think that > leaf should be entirely optional, i.e., without the default “trim”.” > OK then we are in agreement about the default-stmt. WRT: the absence of a data node does not necessarily mean that the default value is in effect, Agreed. However this is not a server-wide corner-case, so a global flag does not really help. Even if the server is adding defaults, it may not know the current "in-use" value for 1 leaf. Following NMDA rules, the server does not report anything. Note that this is a corner-case within NMDA <operational> and has nothing whatsoever to do with the YANG instance file RFC. The solution to this NMDA problem is to report the unknown leaf with an attribute that indicates "no-data". Otherwise a missing leaf with a YANG default will be incorrectly interpreted as an "in-use" value. > Regards, > > Rob > > > Andy > > > *From:* Andy Bierman <a...@yumaworks.com> > *Sent:* 27 July 2021 18:00 > *To:* Rob Wilton (rwilton) <rwil...@cisco.com> > *Cc:* Balázs Lengyel <balazs.leng...@ericsson.com>; NetMod WG < > netmod@ietf.org> > *Subject:* Re: [netmod] yang-instance-file include-defaults leaf > > > > Hi, > > > > None of this addresses my point that a default value of "trim" is not > appropriate. > > Simply remove the default-stmt so that a missing leaf instance means that > > no information is provided, rather than meaning defaults were added for > basic-mode=trim. > > > > > > Andy > > > > > > On Tue, Jul 27, 2021 at 8:38 AM Rob Wilton (rwilton) <rwil...@cisco.com> > wrote: > > Hi Andy, Balazs, > > > > So, the reason that I want a flag to indicate whether default values are > in use is because of this definition of operational in RFC 8342: > > > > 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. > > > > It was written this way because otherwise a consumer of operational data > cannot differentiate between: > > (i) This value is not present because it matches the > default value specified in the YANG module, and > > (ii) This value is not present because the server has > failed to return it for some reason (e.g., perhaps the daemon that would > have provided this value is down or not available, or perhaps it is a bug, > or perhaps it is not implemented and is a missing deviation). > > > > So, I think that in some cases, the absence of a data node does not > necessarily mean that the default value is in effect, and I wanted the > instance-data document to be able to contain and correctly report this data. > > > > I think that this behaviour could be captured by a single leaf. Another > way of articulating this would be: > > > > leaf in-use-values { > > type boolean; > > default false; > > description > > “Only if set to true, the absence of a value in the > > instance data for a given data node implies that the > > node is not used rather than implicitly taking the > > default value specified by any corresponding > > ‘default’ statement specified in the YANG schema.”; > > } > > > > With this, I’m not sure whether we need the “includes-default” leaf > currently specified in the draft, but if we do, then I would think that > leaf should be entirely optional, i.e., without the default “trim”. > > > > Regards, > Rob > > > > > > *From:* Andy Bierman <a...@yumaworks.com> > *Sent:* 10 July 2021 17:41 > *To:* Rob Wilton (rwilton) <rwil...@cisco.com> > *Cc:* NetMod WG <netmod@ietf.org>; Balázs Lengyel < > balazs.leng...@ericsson.com> > *Subject:* Re: [netmod] yang-instance-file include-defaults leaf > > > > > > > > On Fri, Jul 9, 2021 at 5:23 AM Rob Wilton (rwilton) <rwil...@cisco.com> > wrote: > > Andy, > > > > Yes, when I suggested this, I was thinking that a boolean flag might be > sufficient. My point being that automatically filtering out default values > isn’t always the right thing to do. > > > > > > > > The solution is simple. > > Get rid of the inappropriate "default trim" statement. > > > > If the leaf is present then it identifies the basic-mode that was used to > include defaults. > > If not then the information is either not known, not applicable, or > defaults were not added. > > > > The "default" statement is a bug because there is no default basic-mode. > > All of the basic-modes are in use in deployments and no camp has ever > > been able to convince the others that theirs is right. > > > > > > Andy > > > > E.g., something along these lines: > > > > leaf exclude-defaults { > > type boolean; > > default true; > > description > > “Can be used to reduce the size of the content data file. > > > > When unset or set to true, data nodes that have a default defined and > > where the actual value is the default value are excluded from the > content > > data. > > > > When set to false, data nodes with default value are not filtered, > and > > may appear in the content data.” > > } > > > > Would this satisfy your concern? > > > > Regards, > Rob > > > > > > *From:* netmod <netmod-boun...@ietf.org> *On Behalf Of *Andy Bierman > *Sent:* 08 July 2021 18:16 > *To:* NetMod WG <netmod@ietf.org> > *Subject:* [netmod] yang-instance-file include-defaults leaf > > > > Hi, > > > > The module has this object: > > > > leaf includes-defaults { > > type enumeration { > > enum report-all { > > value 1; > > description > > "All data nodes SHOULD be included independent of > > any default values."; > > } > > enum trim { > > value 2; > > description > > "Data nodes that have a default defined and where > > the actual value is the default value SHOULD > > NOT be included."; > > } > > enum explicit { > > value 3; > > description > > "Data nodes that have a default defined and where > > the actual value is the default value SHOULD NOT be > > included. However, if the actual value was set by > > a NETCONF client or other management application > > by the way of an explicit management operation the > > data node SHOULD be included."; > > } > > } > > default trim; > > > > The draft is extremely server-centric, like most IETF standards, but this > > leaf is too server-centric to ignore. > > > > Consider the possibility that the source of the file is NOT a NETCONF > server. > > This data may not be known so the default of "trim" may not be correct. > > > > IMO this leaf is noise because any tool that knows the schema will also > > know the YANG defaults. The solution is incomplete anyway because > > the presence of a leaf that has a YANG default is not enough. > > The "report-all-tagged" mode must be used to identify defaults. > > IMO this leaf should be removed, but at least add an enum called "unknown". > > > > > > Andy > > > > > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod