Italo Busi <[email protected]> writes: > 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:
Yes, this is valid, I'd just suggest: - remove the default statement for "foo", as it may be confusing to both humans and tools - specify the default (both cases) in the description of "foo" A similar example is in the module ietf-ipv6-router-advertisements, e.g. leaf "min-rtr-adv-interval": https://www.rfc-editor.org/rfc/rfc8349.html#section-9.1 Lada > > 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]] >> Sent: mercoledì 20 gennaio 2021 17:05 >> To: Italo Busi <[email protected]> >> Cc: '[email protected]' <[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/> > > _______________________________________________ > 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
