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

On 09. 03. 21 18:55, Andy Bierman wrote:
> 
> 
> On Tue, Mar 9, 2021 at 9:32 AM Ladislav Lhotka <ladislav.lhotka@nic.cz
> <mailto:ladislav.lhotka@nic.cz>> wrote:
> 
>     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>
>     > <mailto:ladislav.lhotka@nic.cz <mailto:ladislav.lhotka@nic.cz>>>
>     wrote:
>     >
>     >     Italo Busi <Italo.Busi@huawei.com
>     <mailto:Italo.Busi@huawei.com> <mailto: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?
> 
> 
> Of course not.
> In this case there MUST NOT be a YANG default-stmt in use for the leaf
> or leaf-list.
> 
> If the leaf or leaf-list does have a YANG default-stmt that MUST be
> used, then
> no description-stmt can undo the requirements in 7.6.1

Isn't it exactly what I was suggesting in my two items? Namely: remove
the "default" statement for "foo" and write this in the description of
"foo":

    The default value is 10 if the "bar" sibling leaf exist,
    and zero otherwise.

Lada

> 
>  
> 
>     Lada
> 
> 
> 
> Andy
>  
> 
>     >
>     >  
>     >
>     >     - 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
>     <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>
>     >     <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>
>     >     <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> <mailto:Italo.Busi@huawei.com
>     <mailto:Italo.Busi@huawei.com>>>
>     >     >> Cc: 'netmod@ietf.org <mailto:netmod@ietf.org>
>     <mailto:netmod@ietf.org <mailto:netmod@ietf.org>>' <netmod@ietf.org
>     <mailto:netmod@ietf.org>
>     >     <mailto: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/>
>     <https://www.jacobs-university.de/ <https://www.jacobs-university.de/>>>
>     >     >
>     >     > _______________________________________________
>     >     > netmod mailing list
>     >     > netmod@ietf.org <mailto:netmod@ietf.org>
>     <mailto:netmod@ietf.org <mailto:netmod@ietf.org>>
>     >     > https://www.ietf.org/mailman/listinfo/netmod
>     <https://www.ietf.org/mailman/listinfo/netmod>
>     >     <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>
>     <mailto:netmod@ietf.org <mailto:netmod@ietf.org>>
>     >     https://www.ietf.org/mailman/listinfo/netmod
>     <https://www.ietf.org/mailman/listinfo/netmod>
>     >     <https://www.ietf.org/mailman/listinfo/netmod
>     <https://www.ietf.org/mailman/listinfo/netmod>>
>     >
>     >
>     > _______________________________________________
>     > 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
> 

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67