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

[Andy Bierman <[e-mail]>]

On Wed, Mar 10, 2021 at 6:34 AM William Lupton <[e-mail]>
wrote:

> 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)?
>
>

description-stmt requirements are normative.
RFC 2119 language applies exactly the same as if it were in some text
section insted of the YANG module.

The issue is that the normative requirements for YANG 1.1 defined in RFC
7950 cannot be
negated by a description-stmt. E.g.

module bad {

    leaf turn-off-mandatory {
        type empty;
        description
           "If this leaf is present then all YANG mandatory-stmts are
ignored throughout this module.";
    }

This may be a valid description-stmt and YANG leaf but any server that
implements it is also
violating MUST requirements in RFC 7950.


Andy



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