On Tue, Jul 27, 2021 at 10:47 AM Rob Wilton (rwilton) <[email protected]>
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 <[email protected]>
> *Sent:* 27 July 2021 18:00
> *To:* Rob Wilton (rwilton) <[email protected]>
> *Cc:* Balázs Lengyel <[email protected]>; NetMod WG <
> [email protected]>
> *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) <[email protected]>
> 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 <[email protected]>
> *Sent:* 10 July 2021 17:41
> *To:* Rob Wilton (rwilton) <[email protected]>
> *Cc:* NetMod WG <[email protected]>; Balázs Lengyel <
> [email protected]>
> *Subject:* Re: [netmod] yang-instance-file include-defaults leaf
>
>
>
>
>
>
>
> On Fri, Jul 9, 2021 at 5:23 AM Rob Wilton (rwilton) <[email protected]>
> 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 <[email protected]> *On Behalf Of *Andy Bierman
> *Sent:* 08 July 2021 18:16
> *To:* NetMod WG <[email protected]>
> *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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
