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

On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> 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.
>
>

deviation /ex:example/ex:foo {
    delete {
       default 0;
     }
}

IMO it was a bad idea to say deviations MUST NOT appear in standard modules.
Here is a use-case for it.

The old-client does not know about the new dynamic default but it could know
that the old YANG default is not being used.

> /js
>

Andy

>
> 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:
> j.schoenwaelder@jacobs-university.de]
> > > Sent: mercoledì 20 gennaio 2021 17:05
> > > To: Italo Busi <Italo.Busi@huawei.com>
> > > Cc: 'netmod@ietf.org' <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/>
> >
>
> --
> 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>