Changing the semantics of a definition via augments is bad design.
A system that does not understand the augment will believe the default
is 0. Since there is no way to force an existing implementation to
understand a certain augmentation, different implementation will
rightfully disagree on the default value in effect.
/js
On Mon, Mar 08, 2021 at 08:19:39PM +0000, Italo Busi wrote:
> 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/>
>
--
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
