On Tue, Mar 9, 2021 at 9:32 AM Ladislav Lhotka <ladislav.lho...@nic.cz> wrote:
> On 09. 03. 21 17:58, Andy Bierman wrote: > > > > > > On Tue, Mar 9, 2021 at 8:46 AM Ladislav Lhotka <ladislav.lho...@nic.cz > > <mailto:ladislav.lho...@nic.cz>> wrote: > > > > Italo Busi <italo.b...@huawei.com <mailto:italo.b...@huawei.com>> > > 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? > > Of course not. In this case there MUST NOT be a YANG default-stmt in use for the leaf or leaf-list. If the leaf or leaf-list does have a YANG default-stmt that MUST be used, then no description-stmt can undo the requirements in 7.6.1 > Lada > > Andy > > > > > > > > - 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:j.schoenwael...@jacobs-university.de > > <mailto:j.schoenwael...@jacobs-university.de>] > > >> Sent: mercoledì 20 gennaio 2021 17:05 > > >> To: Italo Busi <italo.b...@huawei.com <mailto: > italo.b...@huawei.com>> > > >> Cc: 'netmod@ietf.org <mailto:netmod@ietf.org>' <netmod@ietf.org > > <mailto: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/ < > https://www.jacobs-university.de/>> > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org <mailto:netmod@ietf.org> > > > 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 > > netmod@ietf.org <mailto:netmod@ietf.org> > > https://www.ietf.org/mailman/listinfo/netmod > > <https://www.ietf.org/mailman/listinfo/netmod> > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
