Re: [netmod] Questions about how to assign default values with YANG

On 09. 03. 21 17:58, Andy Bierman wrote:
> 
> 
> On Tue, Mar 9, 2021 at 8:46 AM Ladislav Lhotka <ladislav.lhotka@nic.cz
> <mailto:ladislav.lhotka@nic.cz>> wrote:
> 
>     Italo Busi <Italo.Busi@huawei.com <mailto:Italo.Busi@huawei.com>>
>     writes:
> 
>     > 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:
> 
>     Yes, this is valid, I'd just suggest:
> 
> 
> I do not agree.
> I do not see how the description-stmt for /foo can change the default
> leaf processing for /bar
> 

Are you saying that the (computed) default values specified in
description strings (as in ietf-ipv6-router-advertisements) are illegal?

Lada

> 
>  
> 
>     - remove the default statement for "foo", as it may be confusing to
>     both humans and tools
> 
> 
> sec 7.3.4:
> 
>    If the base type has a default value and the new derived type does
>    not specify a new default value, the base type's default value is
>    also the default value of the new derived type.
> 
> 
> 
> sec 7.6.1
> 
> 
>    The default value of a leaf is the value that the server uses if the
>    leaf does not exist in the data tree.  The usage of the default value
>    depends on the leaf's closest ancestor node in the schema tree that
>    is not a non-presence container (see Section 7.5.1 <https://tools.ietf.org/html/rfc7950#section-7.5.1>):
> 
>    o  If no such ancestor exists in the schema tree, the default value
>       MUST be used.
> 
>    o  Otherwise, if this ancestor is a case node, the default value MUST
>       be used if any node from the case exists in the data tree or the
>       case node is the choice's default case, and if no nodes from any
>       other case exist in the data tree.
> 
>    o  Otherwise, the default value MUST be used if the ancestor node
>       exists in the data tree.
> 
> 
> 
> 
>     - specify the default (both cases) in the description of "foo"
> 
>     A similar example is in the module ietf-ipv6-router-advertisements,
>     e.g. leaf "min-rtr-adv-interval":
> 
>     https://www.rfc-editor.org/rfc/rfc8349.html#section-9.1
>     <https://www.rfc-editor.org/rfc/rfc8349.html#section-9.1>
> 
>     Lada
> 
> 
> 
> Andy
>  
> 
> 
>     >
>     > 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/ <https://www.jacobs-university.de/>>
>     >
>     > _______________________________________________
>     > netmod mailing list
>     > netmod@ietf.org <mailto:netmod@ietf.org>
>     > https://www.ietf.org/mailman/listinfo/netmod
>     <https://www.ietf.org/mailman/listinfo/netmod>
> 
>     -- 
>     Ladislav Lhotka
>     Head, CZ.NIC Labs
>     PGP Key ID: 0xB8F92B08A9F76C67
> 
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org <mailto:netmod@ietf.org>
>     https://www.ietf.org/mailman/listinfo/netmod
>     <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