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 <ladislav.lho...@nic.cz> wrote: > 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