Re: [netmod] Questions about how to assign default values with YANG
Ladislav Lhotka <ladislav.lhotka@nic.cz> Wed, 10 March 2021 15:14 UTC
Return-Path: <ladislav.lhotka@nic.cz>
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 307E33A0F49 for <netmod@ietfa.amsl.com>; Wed, 10 Mar 2021 07:14:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 mH9VUffzYgst for <netmod@ietfa.amsl.com>; Wed, 10 Mar 2021 07:13:58 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473FF3A0DDD for <netmod@ietf.org>; Wed, 10 Mar 2021 07:13:58 -0800 (PST)
Received: from localhost (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id 730FC140075; Wed, 10 Mar 2021 16:13:55 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1615389235; bh=rcYPSd4fjIFalGcspFi7mge7MM2Vohi9HYo2Nd+wJSQ=; h=From:To:Date; b=vjDL4PJXVSIatatsqYYXZgh7FJRSVtzIKEcywZbCSTa7jOW+3l4zriakkDlW1JHYc eQyObcbW04pIYal41oegJwmvlA8uQbcbUN998cbStrEtRxhvH3RoL1hnLGhYPgZnNA KA6FNBoT0PrRb0sEt4fqcsLOJSaXlgNf/+PnuOLU=
From: Ladislav Lhotka <ladislav.lhotka@nic.cz>
To: William Lupton <wlupton@broadband-forum.org>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Italo Busi <Italo.Busi@huawei.com>, "netmod@ietf.org" <netmod@ietf.org>
In-Reply-To: <CAEe_xxjce3=bVTbjkzkC62T9Gq+yVat8Fg6CQTomEUeTKQaPLg@mail.gmail.com>
References: <a0c43ab5c3c1463a97a1aa594a80ceee@huawei.com> <20210120094737.g5l5pvfzligahrj6@anna.jacobs.jacobs-university.de> <2384a8f549c94ea0ac46d6c772fbca43@huawei.com> <20210120114446.ovih63db7vmv7c7s@anna.jacobs.jacobs-university.de> <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> <20210309195241.k5lfmdnw2zqq6b4o@anna.jacobs.jacobs-university.de> <CABCOCHQkTsToyZ3qW3am41s3m7VLYt=pAdjBMuR0cMCwahbekg@mail.gmail.com> <bbbd4244a0474c48b3fdecb791cb936a@huawei.com> <20210310100058.y7yrbgd6z3rgmo4s@anna.jacobs.jacobs-university.de> <87h7ljfgwp.fsf@nic.cz> <CAEe_xxjce3=bVTbjkzkC62T9Gq+yVat8Fg6CQTomEUeTKQaPLg@mail.gmail.com>
Mail-Followup-To: William Lupton <wlupton@broadband-forum.org>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Italo Busi <Italo.Busi@huawei.com>, "netmod@ietf.org" <netmod@ietf.org>
Date: Wed, 10 Mar 2021 16:13:55 +0100
Message-ID: <87eegnf3d8.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/VRxzpNUl5k_45fU1H1-6t35oLbE>
Subject: Re: [netmod] Questions about how to assign default values with YANG
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: Wed, 10 Mar 2021 15:14:01 -0000
William Lupton <wlupton@broadband-forum.org> writes: > Lada, all, > > Surely a description is the only way to add a normative requirement that > can't be expressed via YANG statements (including XPath expressions)? > > I've always assumed that it's good practice to express what you can using > the modeling language, and then use the description to express any > non-modelable requirements. Obviously there's a problem if the description > conflicts with a modeled requirement (and I think it's also good practice > for the description not to repeat anything that's modeled elsewhere). > > I think that RFC 7950 can be interpreted as indicating that the description > is more than just informative. I found this in Section 11, and I take this > to imply that the description defines the semantics of a definition. Even then, it is unclear what effects are permitted with this "more than informative". In a previous mail I refered to a standard module having a description that defines a (computed) default. This seems to be acceptable. But what about simulating a "when" statement for constraints that cannot be expressed via XPath? For example: description "This leaf is only valid if the value of foo is prime."; I argued in the past that everything that cannot be expressed formally with YANG statements should be left outside of scope for YANG, at least in terms of data tree validation. > > A "description" statement may be added or changed without changing the > > semantics of the definition. > > > For example, if a description says this (this is an example from RFC 7950), > then isn't this a _normative_ semantic requirement? > > "The amount of local storage that can be used to hold syslog messages." Hmm, this seems to state semantics (meaning) of a parameter. What I am talking about are semantic constraints (business rules) that a valid data tree is required to satisfy. Lada > > > William > > On Wed, 10 Mar 2021 at 10:21, Ladislav Lhotka <ladislav.lhotka@nic.cz> > wrote: > >> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes: >> >> > A client that has no clue of the annotated leaf can rightfully assume >> > that the default 0 applies. If another client creates this magic leaf >> > that changes the default to 10, then there is going to be confusion. >> > >> > A definition that says 'default 0' says the default is 0. It does not >> > say the default may be zero or something different depending on >> > whether the moon shines or other circumstances. I believe you can't >> > undo a default statement with a description somewhere else. >> >> The problem with descriptions is that there seems to be a general >> agreement that they can somehow supplement the formal YANG statements in >> specifying the data model. This has no support in RFC 7950 though: >> >> - section 7.21.3 only says that a description is "a human-readable textual >> description of this definition" >> >> - section 8.1 doesn't include constraints specified in descriptions in the >> concept of data tree validity >> >> As a result, data model constraints specified in descriptions is a grey >> area, and it is totally unclear how far-reaching they can possibly be. >> >> Lada >> >> > >> > /js >> > >> > On Wed, Mar 10, 2021 at 08:54:18AM +0000, Italo Busi wrote: >> >> Andy, Juergen, >> >> >> >> I am not sure I understand the issue with a client that does not >> understand the augment. >> >> >> >> When this client writes in the running DS, it will not set the bar >> attribute (which is also defined in the augment module) and therefore the >> default value 0 will be applied by the system, as expected by the client. >> >> >> >> When this client reads from the operational DS the applied >> configuration, provided by another client which understands the augment, it >> will see that the applied configuration for the leaf foo is 10. >> >> >> >> This is a valid applied configuration if the other client had >> explicitly configured the value 10 in the running DS. >> >> >> >> The only difference would be that when the value 10 is explicitly >> configured by the other client the origin is set to intended while when >> “implicitly” configured using the attribute bar, the origin can be set to >> system (I think it would not be correct to set the origin to default in >> this case). >> >> >> >> BTW, I agree that this is not the most elegant/clean design and that >> the best approach would be not to define any default value in the base >> model. I am just willing to understand if a work-around is possible, >> without breaking any client, to allow re-using an existing module which has >> already defined a default value. >> >> >> >> Italo >> >> >> >> From: Andy Bierman [mailto:andy@yumaworks.com] >> >> Sent: martedì 9 marzo 2021 21:12 >> >> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; >> Italo Busi <Italo.Busi@huawei.com>; netmod@ietf.org >> >> Subject: Re: [netmod] Questions about how to assign default values with >> YANG >> >> >> >> >> >> >> >> On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de<mailto: >> j.schoenwaelder@jacobs-university.de>> wrote: >> >> Changing the semantics of a definition via augments is bad design. >> >> >> >> A system that does not understand the augment will believe the default >> >> is 0. Since there is no way to force an existing implementation to >> >> understand a certain augmentation, different implementation will >> >> rightfully disagree on the default value in effect. >> >> >> >> >> >> deviation /ex:example/ex:foo { >> >> delete { >> >> default 0; >> >> } >> >> } >> >> >> >> IMO it was a bad idea to say deviations MUST NOT appear in standard >> modules. >> >> Here is a use-case for it. >> >> >> >> The old-client does not know about the new dynamic default but it could >> know >> >> that the old YANG default is not being used. >> >> >> >> >> >> /js >> >> >> >> Andy >> >> >> >> >> >> On Mon, Mar 08, 2021 at 08:19:39PM +0000, Italo Busi wrote: >> >> > Hi Juergen, >> >> > >> >> > Thanks again for your clear explanation on this topic >> >> > >> >> > I have found a similar but slightly different issue. In this case, a >> YANG default statement exists in the base module but the intention with the >> augmentation is to "overwrite" the default value on the basis of another >> attribute, defined in the module which augments the base module. >> >> > >> >> > For example, I am wondering whether such a code is valid: >> >> > >> >> > module example-base { >> >> > container example { >> >> > leaf foo { >> >> > type uint8; >> >> > default 0; >> >> > } >> >> > } >> >> > } >> >> > >> >> > module example-augment { >> >> > import example { >> >> > prefix ex; >> >> > } >> >> > >> >> > augment "ex:example" { >> >> > leaf bar { >> >> > type empty; >> >> > description >> >> > "When present, the default value for foo is 10."; >> >> > } >> >> > } >> >> > } >> >> > >> >> > >> >> > In this case, when the leaf foo is not configured but the leaf bar is >> present, the value of foo in the operational datastore should be 10 (rather >> than 0). >> >> > >> >> > In this case, I think that it would be better/cleaner if the origin >> is marked as system. >> >> > >> >> > Maybe a better YANG description for bar could be: "When present, the >> system overrides the default value of foo to 10." >> >> > >> >> > What is your and/or WG opinion? >> >> > >> >> > Thanks again >> >> > >> >> > Italo >> >> > >> >> > > -----Original Message----- >> >> > > From: Juergen Schoenwaelder [mailto: >> j.schoenwaelder@jacobs-university.de<mailto: >> j.schoenwaelder@jacobs-university.de>] >> >> > > Sent: mercoledì 20 gennaio 2021 17:05 >> >> > > To: Italo Busi <Italo.Busi@huawei.com<mailto:Italo.Busi@huawei.com >> >> >> >> > > Cc: 'netmod@ietf.org<mailto:netmod@ietf.org>' <netmod@ietf.org >> <mailto:netmod@ietf.org>> >> >> > > Subject: Re: [netmod] Questions about how to assign default values >> with >> >> > > YANG >> >> > > >> >> > > On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote: >> >> > > > >> >> > > > What about the case the leaf is not conditional (but still >> mandatory false >> >> > > since a YANG default statement is defined)? >> >> > > > >> >> > > > May the server still decide not to use/implement this leaf in the >> operational >> >> > > datastore? >> >> > > > >> >> > > > For example, in appendix C.1 of RFC8342, auto-negotiation is >> enabled by >> >> > > default. >> >> > > > What should be the behavior of a system which does not implement >> auto- >> >> > > negotiation? >> >> > > > Return the value false or no value (in the operational datastore)? >> >> > > > >> >> > > >> >> > > Here are some of the rules I personally like: >> >> > > >> >> > > - <operational> is the ground truth about what a system has and >> does >> >> > > - do not implement leafs that do not apply >> >> > > >> >> > > Hence, interfaces supporting auto-negotiation have either auto- >> >> > > negotiation/enabled = true or auto-negotiation/enabled = false in >> >> > > <operational>. And interfaces not supporting auto-negotiation have >> nothing >> >> > > to report about auto-negotiation. Yes, I do not want to see auto- >> >> > > negotiation/enabled = false on a loopback interface. >> >> > > >> >> > > My historic Ethernet interface from the last century would also not >> report >> >> > > auto-negotiation/enabled in <operational>. You may hit applications >> that love >> >> > > to have auto-negotiation/enabled available on all Ethernet >> interfaces and then >> >> > > you end in a debate where the application developers tell you that >> no >> >> > > information in <operational> may have many reasons (instrumentation >> not >> >> > > implemented, access control rules, whatever and by reporting >> enabled=false >> >> > > you do them a favor) but the true answer in such a debate is often >> that >> >> > > modeling things as a boolean is simplistic since there are often >> more than >> >> > > exactly two states (in this case, enabled, disabled, failed, >> not-available, ...). >> >> > > So you settle on blaming the model writer. ;-) >> >> > > >> >> > > /js >> >> > > >> >> > > -- >> >> > > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >> > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >> Germany >> >> > > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> >> >> > >> >> >> >> -- >> >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> >> Fax: +49 421 200 3103 <https://www.jacobs-university.de/> >> >> >> >> _______________________________________________ >> >> netmod mailing list >> >> netmod@ietf.org<mailto:netmod@ietf.org> >> >> https://www.ietf.org/mailman/listinfo/netmod >> > >> > -- >> > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> >> > >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
- [netmod] Questions about how to assign default va… Italo Busi
- Re: [netmod] Questions about how to assign defaul… Juergen Schoenwaelder
- Re: [netmod] Questions about how to assign defaul… Italo Busi
- Re: [netmod] Questions about how to assign defaul… Juergen Schoenwaelder
- Re: [netmod] Questions about how to assign defaul… Italo Busi
- Re: [netmod] Questions about how to assign defaul… Juergen Schoenwaelder
- Re: [netmod] Questions about how to assign defaul… Italo Busi
- Re: [netmod] Questions about how to assign defaul… Andy Bierman
- Re: [netmod] Questions about how to assign defaul… Ladislav Lhotka
- Re: [netmod] Questions about how to assign defaul… Ladislav Lhotka
- Re: [netmod] Questions about how to assign defaul… Andy Bierman
- Re: [netmod] Questions about how to assign defaul… Ladislav Lhotka
- Re: [netmod] Questions about how to assign defaul… Italo Busi
- Re: [netmod] Questions about how to assign defaul… Juergen Schoenwaelder
- Re: [netmod] Questions about how to assign defaul… Andy Bierman
- Re: [netmod] Questions about how to assign defaul… Italo Busi
- Re: [netmod] Questions about how to assign defaul… Juergen Schoenwaelder
- Re: [netmod] Questions about how to assign defaul… Ladislav Lhotka
- Re: [netmod] Questions about how to assign defaul… Andy Bierman
- Re: [netmod] Questions about how to assign defaul… William Lupton
- Re: [netmod] Questions about how to assign defaul… Ladislav Lhotka
- Re: [netmod] Questions about how to assign defaul… Italo Busi
- Re: [netmod] Questions about how to assign defaul… William Lupton
- Re: [netmod] Questions about how to assign defaul… Andy Bierman
- Re: [netmod] Questions about how to assign defaul… Juergen Schoenwaelder
- Re: [netmod] Questions about how to assign defaul… Italo Busi
- Re: [netmod] Questions about how to assign defaul… Juergen Schoenwaelder
- Re: [netmod] Questions about how to assign defaul… Italo Busi
- Re: [netmod] Questions about how to assign defaul… Andy Bierman