Re: [netmod] yang-instance-file include-defaults leaf

Andy Bierman <andy@yumaworks.com> Tue, 27 July 2021 18:11 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D720B3A0544 for <netmod@ietfa.amsl.com>; Tue, 27 Jul 2021 11:11:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0CtpLneOKRf for <netmod@ietfa.amsl.com>; Tue, 27 Jul 2021 11:11:42 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5323A0538 for <netmod@ietf.org>; Tue, 27 Jul 2021 11:11:41 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id u3so23225724lff.9 for <netmod@ietf.org>; Tue, 27 Jul 2021 11:11:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i3ZcMhD5+ugC/Myd953ikrvaxqQOoL9edh3IDlhqYNA=; b=QFFZaGBtvnZ59TeiosGDSzvDZfdk49qzbJT4RlAJmYnxrppHRTWjQmYvsWHZFA5lX9 MeIF6Y9ESm6Lj5DhRTyr+KdpsKMvJTZg6KtlrFUrX62WQr5F2UwDkdSCi4CUrkw2RAh1 bich3yWVNn0D6EL+Z//lSv8maHn2ofF7B6KFfDuQXp05q2BknsmZ+N/HKdczUw8097eA L8OJofJfiP/Bwwj5k4cSu6qL7s6nV4XZGDv5roOZgYuKlSnjKz2db9UeYD3jTQEHn8jM 4z7f6Wd31x3dgLvG1gP4lL3JfidK3cP70zMXjgORWBFsecHSHe/r5scJU+t/0aV4tUwZ JD/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i3ZcMhD5+ugC/Myd953ikrvaxqQOoL9edh3IDlhqYNA=; b=S/1mRnp0ey0KBhTkh+GB2Txa/fuVmWQJuEkxo73hEpixl3N49iYHbrQr3i3lthZZw6 Z47xcY5TIi40jmlhCZYs/IqCXmFq79uBQm4uKoh0f7Xj5anfCrshIBDj70pt/dDaPicT qd3k+6oJnKmQGiA4vCY0CJuZaqdMK/uAYmT8MI7ihewi/RbgTRqBe5ww2fxOQakOTzqa eHEhbwg20Kkp5n5o5oBItwqKMv98HaoR/OLiKcSnHVZ3+T0FMO7iWPXFBVLJWqmrWQ2G cuQrmTID6S5HMJLDyFUptINVRv8yT7ziRWLRIiNC81ZVM7rVt2JFuVIkBy5jF7RoNxXJ 1oOQ==
X-Gm-Message-State: AOAM531mli4FRYTPolZUXWcsKtlKSPkg5nJSO3aqqopGZkH8prfPM1TA WgSfGLWqmAbknHvrwsLe2C6nj9MwDXD17kJfXAY2Ug==
X-Google-Smtp-Source: ABdhPJzDwJzmEgzokJl+0INwjD/4FK9+yC3jztOHQPCR7QPk9QiWIKQ8jWiCNtDq5CAnRFXuTgmwcZZqBbi8UsFQxIE=
X-Received: by 2002:a05:6512:3745:: with SMTP id a5mr16933445lfs.478.1627409499442; Tue, 27 Jul 2021 11:11:39 -0700 (PDT)
MIME-Version: 1.0
References: <CABCOCHQB8=kAXRejif=04ThzbSn87oqvDLB5=oJ2FVcAKrSg4Q@mail.gmail.com> <DM4PR11MB5438F5874CDEB4D78C9A5695B5189@DM4PR11MB5438.namprd11.prod.outlook.com> <CABCOCHRwzRajMmSd2mArLeLr8OOxTdLEid3bEDdVH0vgNysTfg@mail.gmail.com> <DM4PR11MB5438FBF7837C1147D786964CB5E99@DM4PR11MB5438.namprd11.prod.outlook.com> <CABCOCHR=fq2fqw1Lr1kbyegz-K0J-gYdOsPFgELafNWquZ+Whw@mail.gmail.com> <DM4PR11MB5438E049D0AAE4184F5F2B8FB5E99@DM4PR11MB5438.namprd11.prod.outlook.com>
In-Reply-To: <DM4PR11MB5438E049D0AAE4184F5F2B8FB5E99@DM4PR11MB5438.namprd11.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 27 Jul 2021 11:11:28 -0700
Message-ID: <CABCOCHQtJjzDCyGAO+RjZvURAN2vTBd-H3dA+A79rQrD8rE+6g@mail.gmail.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
Cc: Balázs Lengyel <balazs.lengyel@ericsson.com>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001e666f05c81ecd56"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/m5-iqH1dIWRw7DgRsbozuSA1tas>
Subject: Re: [netmod] yang-instance-file include-defaults leaf
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jul 2021 18:11:48 -0000

On Tue, Jul 27, 2021 at 10:47 AM Rob Wilton (rwilton) <rwilton@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 <andy@yumaworks.com>
> *Sent:* 27 July 2021 18:00
> *To:* Rob Wilton (rwilton) <rwilton@cisco.com>
> *Cc:* Balázs Lengyel <balazs.lengyel@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) <rwilton@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 <andy@yumaworks.com>
> *Sent:* 10 July 2021 17:41
> *To:* Rob Wilton (rwilton) <rwilton@cisco.com>
> *Cc:* NetMod WG <netmod@ietf.org>; Balázs Lengyel <
> balazs.lengyel@ericsson.com>
> *Subject:* Re: [netmod] yang-instance-file include-defaults leaf
>
>
>
>
>
>
>
> On Fri, Jul 9, 2021 at 5:23 AM Rob Wilton (rwilton) <rwilton@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-bounces@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
>
>
>
>
>
>