On 09. 03. 21 17:58, Andy Bierman wrote: > > > 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 >
Are you saying that the (computed) default values specified in description strings (as in ietf-ipv6-router-advertisements) are illegal? Lada > > > > - 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 > <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/ <https://www.jacobs-university.de/>> > > > > _______________________________________________ > > netmod mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/netmod > <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 > <https://www.ietf.org/mailman/listinfo/netmod> > > > _______________________________________________ > 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
