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:[email protected]]
> Sent: mercoledì 20 gennaio 2021 17:05
> To: Italo Busi <[email protected]>
> Cc: '[email protected]' <[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/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
