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

[William Lupton <[e-mail]>]

Thanks Lada. By my last point I just intended to illustrate that
descriptions need to be regarded as normative even if they don't use
normative language.

On Wed, 10 Mar 2021 at 15:13, Ladislav Lhotka <[e-mail]>
wrote:

> William Lupton <[e-mail]> writes:
>
> > Lada, all,
> >
> > Surely a description is the only way to add a normative requirement that
> > can't be expressed via YANG statements (including XPath expressions)?
> >
> > I've always assumed that it's good practice to express what you can using
> > the modeling language, and then use the description to express any
> > non-modelable requirements. Obviously there's a problem if the
> description
> > conflicts with a modeled requirement (and I think it's also good practice
> > for the description not to repeat anything that's modeled elsewhere).
> >
> > I think that RFC 7950 can be interpreted as indicating that the
> description
> > is more than just informative. I found this in Section 11, and I take
> this
> > to imply that the description defines the semantics of a definition.
>
> Even then, it is unclear what effects are permitted with this "more than
> informative". In a previous mail I refered to a standard module having a
> description that defines a (computed) default. This seems to be acceptable.
>
> But what about simulating a "when" statement for constraints that cannot
> be expressed via XPath? For example:
>
>   description
>     "This leaf is only valid if the value of foo is prime.";
>
> I argued in the past that everything that cannot be expressed formally
> with YANG statements should be left outside of scope for YANG, at least in
> terms of data tree validation.
>
> >
> > A "description" statement may be added or changed without changing the
> >
> > semantics of the definition.
> >
> >
> > For example, if a description says this (this is an example from RFC
> 7950),
> > then isn't this a _normative_ semantic requirement?
> >
> > "The amount of local storage that can be used to hold syslog messages."
>
> Hmm, this seems to state semantics (meaning) of a parameter. What I am
> talking about are semantic constraints (business rules) that a valid data
> tree is required to satisfy.
>
> Lada
>
> >
> >
> > William
> >
> > On Wed, 10 Mar 2021 at 10:21, Ladislav Lhotka <[e-mail]>
> > wrote:
> >
> >> Juergen Schoenwaelder <[e-mail]> writes:
> >>
> >> > A client that has no clue of the annotated leaf can rightfully assume
> >> > that the default 0 applies. If another client creates this magic leaf
> >> > that changes the default to 10, then there is going to be confusion.
> >> >
> >> > A definition that says 'default 0' says the default is 0. It does not
> >> > say the default may be zero or something different depending on
> >> > whether the moon shines or other circumstances. I believe you can't
> >> > undo a default statement with a description somewhere else.
> >>
> >> The problem with descriptions is that there seems to be a general
> >> agreement that they can somehow supplement the formal YANG statements in
> >> specifying the data model. This has no support in RFC 7950 though:
> >>
> >> - section 7.21.3 only says that a description is "a human-readable
> textual
> >>   description of this definition"
> >>
> >> - section 8.1 doesn't include constraints specified in descriptions in
> the
> >>   concept of data tree validity
> >>
> >> As a result, data model constraints specified in descriptions is a grey
> >> area, and it is totally unclear how far-reaching they can possibly be.
> >>
> >> Lada
> >>
> >> >
> >> > /js
> >> >
> >> > On Wed, Mar 10, 2021 at 08:54:18AM +0000, Italo Busi wrote:
> >> >> Andy, Juergen,
> >> >>
> >> >> I am not sure I understand the issue with a client that does not
> >> understand the augment.
> >> >>
> >> >> When this client writes in the running DS, it will not set the bar
> >> attribute (which is also defined in the augment module) and therefore
> the
> >> default value 0 will be applied by the system, as expected by the
> client.
> >> >>
> >> >> When this client reads from the operational DS the applied
> >> configuration, provided by another client which understands the
> augment, it
> >> will see that the applied configuration for the leaf foo is 10.
> >> >>
> >> >> This is a valid applied configuration if the other client had
> >> explicitly configured the value 10 in the running DS.
> >> >>
> >> >> The only difference would be that when the value 10 is explicitly
> >> configured by the other client the origin is set to intended while when
> >> “implicitly” configured using the attribute bar, the origin can be set
> to
> >> system (I think it would not be correct to set the origin to default in
> >> this case).
> >> >>
> >> >> BTW, I agree that this is not the most elegant/clean design and that
> >> the best approach would be not to define any default value in the base
> >> model. I am just willing to understand if a work-around is possible,
> >> without breaking any client, to allow re-using an existing module which
> has
> >> already defined a default value.
> >> >>
> >> >> Italo
> >> >>
> >> >> From: Andy Bierman [mailto:[e-mail]]
> >> >> Sent: martedì 9 marzo 2021 21:12
> >> >> To: Juergen Schoenwaelder <[e-mail]>;
> >> Italo Busi <[e-mail]>; [e-mail]
> >> >> Subject: Re: [netmod] Questions about how to assign default values
> with
> >> YANG
> >> >>
> >> >>
> >> >>
> >> >> On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder <
> >> [e-mail]<mailto:
> >> [e-mail]>> 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:
> >> [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/>
> >> >> >
> >> >>
> >> >> --
> >> >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >> >> Phone: [phone]         Campus Ring 1 | 28759 Bremen |
> Germany
> >> >> Fax:   [phone]         <https://www.jacobs-university.de/>
> >> >>
> >> >> _______________________________________________
> >> >> netmod mailing list
> >> >> [e-mail]<mailto:[e-mail]>
> >> >> https://www.ietf.org/mailman/listinfo/netmod
> >> >
> >> > --
> >> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> >> > Fax:   [phone]         <https://www.jacobs-university.de/>
> >> >
> >> > _______________________________________________
> >> > netmod mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/netmod
> >>
> >> --
> >> Ladislav Lhotka
> >> Head, CZ.NIC Labs
> >> PGP Key ID: 0xB8F92B08A9F76C67
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> [e-mail]
> >> 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
>