Juergen Schoenwaelder <[email protected]> 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:[email protected]] >> Sent: martedì 9 marzo 2021 21:12 >> To: Juergen Schoenwaelder <[email protected]>; Italo Busi >> <[email protected]>; [email protected] >> Subject: Re: [netmod] Questions about how to assign default values with YANG >> >> >> >> On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder >> <[email protected]<mailto:[email protected]>> >> 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:[email protected]<mailto:[email protected]>] >> > > Sent: mercoledì 20 gennaio 2021 17:05 >> > > To: Italo Busi <[email protected]<mailto:[email protected]>> >> > > Cc: '[email protected]<mailto:[email protected]>' >> > > <[email protected]<mailto:[email protected]>> >> > > 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 >> [email protected]<mailto:[email protected]> >> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
