William Lupton <wlup...@broadband-forum.org> 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 <ladislav.lho...@nic.cz>
> wrote:
>
>> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> 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:a...@yumaworks.com]
>> >> Sent: martedì 9 marzo 2021 21:12
>> >> To: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>;
>> Italo Busi <italo.b...@huawei.com>; netmod@ietf.org
>> >> Subject: Re: [netmod] Questions about how to assign default values with
>> YANG
>> >>
>> >>
>> >>
>> >> On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder <
>> j.schoenwael...@jacobs-university.de<mailto:
>> j.schoenwael...@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.schoenwael...@jacobs-university.de<mailto:
>> j.schoenwael...@jacobs-university.de>]
>> >> > > Sent: mercoledì 20 gennaio 2021 17:05
>> >> > > To: Italo Busi <italo.b...@huawei.com<mailto:italo.b...@huawei.com
>> >>
>> >> > > Cc: 'netmod@ietf.org<mailto:netmod@ietf.org>' <netmod@ietf.org
>> <mailto: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<mailto:netmod@ietf.org>
>> >> https://www.ietf.org/mailman/listinfo/netmod
>> >
>> > --
>> > 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
>>
>> --
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
