On 09. 03. 21 18:55, Andy Bierman wrote:
>
>
> On Tue, Mar 9, 2021 at 9:32 AM Ladislav Lhotka <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 09. 03. 21 17:58, Andy Bierman wrote:
> >
> >
> > On Tue, Mar 9, 2021 at 8:46 AM Ladislav Lhotka
> <[email protected] <mailto:[email protected]>
> > <mailto:[email protected] <mailto:[email protected]>>>
> wrote:
> >
> > Italo Busi <[email protected]
> <mailto:[email protected]> <mailto:[email protected]
> <mailto:[email protected]>>>
> > 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:[email protected]
> <mailto:[email protected]>
> > <mailto:[email protected]
> <mailto:[email protected]>>]
> > >> Sent: mercoledì 20 gennaio 2021 17:05
> > >> To: Italo Busi <[email protected]
> <mailto:[email protected]> <mailto:[email protected]
> <mailto:[email protected]>>>
> > >> Cc: '[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>' <[email protected]
> <mailto:[email protected]>
> > <mailto:[email protected] <mailto:[email protected]>>>
> > >> 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
> > > [email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > > 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
> > [email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > 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
> > [email protected] <mailto:[email protected]>
> > 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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
