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.
/js 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] > > Sent: mercoledì 20 gennaio 2021 17:05 > > To: Italo Busi <italo.b...@huawei.com> > > Cc: 'netmod@ietf.org' <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 https://www.ietf.org/mailman/listinfo/netmod