Lada, Andy, Thanks for your feedbacks.
If I understand correctly, if the base model and the augmentation model are defined at the same time, we can avoid defining any YANG default statement in the base model and providing a proper description of the desired behavior. Based on previous discussion with Juergen, I have understood that, in this case, the origin in the operational datastore can be either set to default or to system (Juergen prefers the latter but the former is allowed by section 5.3.4 of RFC8342). I think this would be the ideal solution, but in practice there are cases where the base model has been written before the augmentation model and/or the author of the base model is not aware of the needs from the author of the augmentation model. In these cases, the YANG default statement already exists in the base model. Is it really required to change the base model or could a work-around be found? In principle, the system has enough information to understand that, if no value for the leaf foo is provided in the intended DS, the value in the applied configuration for the leaf foo should be 10 rather than the value defined in the YANG default statement (i.e., 0). Based your comments, I think that in this case, the origin in the operational datastore must not be set to default, but I am wondering whether it could be set to system instead. In other words, the applied configuration for foo is provided by the system on the basis of the rules associated with the configuration of bar. If this is possible, then the issue could be solved without the need to request a change to the base model. The description in the augmented model needs to be cleaned-up since in my initial mail it was misleading. Maybe a better alternative could be something like “When bar is present and foo is not configured, the system applies the value 10 to foo rather than its default value.” (it could be further improved). What do you think? Italo From: Andy Bierman [mailto:[email protected]] Sent: martedì 9 marzo 2021 17:58 To: Italo Busi <[email protected]>; Juergen Schoenwaelder <[email protected]>; [email protected] Subject: Re: [netmod] Questions about how to assign default values with YANG On Tue, Mar 9, 2021 at 8:46 AM Ladislav Lhotka <[email protected]<mailto:[email protected]>> wrote: Italo Busi <[email protected]<mailto:[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: I do not agree. I do not see how the description-stmt for /foo can change the default leaf processing for /bar - remove the default statement for "foo", as it may be confusing to both humans and tools sec 7.3.4: If the base type has a default value and the new derived type does not specify a new default value, the base type's default value is also the default value of the new derived type. sec 7.6.1 The default value of a leaf is the value that the server uses if the leaf does not exist in the data tree. The usage of the default value depends on the leaf's closest ancestor node in the schema tree that is not a non-presence container (see Section 7.5.1<https://tools.ietf.org/html/rfc7950#section-7.5.1>): o If no such ancestor exists in the schema tree, the default value MUST be used. o Otherwise, if this ancestor is a case node, the default value MUST be used if any node from the case exists in the data tree or the case node is the choice's default case, and if no nodes from any other case exist in the data tree. o Otherwise, the default value MUST be used if the ancestor node exists in the data tree. - 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 Andy > > 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/> > > _______________________________________________ > netmod mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
