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

[Andy Bierman <[e-mail]>]

On Tue, Mar 9, 2021 at 9:32 AM Ladislav Lhotka <[e-mail]>
wrote:

> On 09. 03. 21 17:58, Andy Bierman wrote:
> >
> >
> > On Tue, Mar 9, 2021 at 8:46 AM Ladislav Lhotka <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Italo Busi <[e-mail] <mailto:[e-mail]>>
> >     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



> 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>):
> >
> >    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:[e-mail]
> >     <mailto:[e-mail]>]
> >     >> Sent: mercoledì 20 gennaio 2021 17:05
> >     >> To: Italo Busi <[e-mail] <mailto:
> [e-mail]>>
> >     >> Cc: '[e-mail] <mailto:[e-mail]>' <[e-mail]
> >     <mailto:[e-mail]>>
> >     >> 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: [phone]         Campus Ring 1 | 28759 Bremen |
> >     Germany
> >     >> Fax:   [phone]
> >      <https://www.jacobs-university.de/ <
> https://www.jacobs-university.de/>>
> >     >
> >     > _______________________________________________
> >     > netmod mailing list
> >     > [e-mail] <mailto:[e-mail]>
> >     > 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
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/netmod
> >     <https://www.ietf.org/mailman/listinfo/netmod>
> >
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>