On Wed, Jan 20, 2021 at 08:57:48AM +0000, Italo Busi wrote:
> Hi all,
>
> I have read RFC7950 and RFC8342 but I have still some questions for
> clarification about how to deal with default values in YANG.
>
> Let's consider a config true leaf for which a YANG default statement has been
> defined in the YANG module.
>
> If the client does not configure that leaf in the running datastore, the leaf
> is not present (cannot be read) in the running datastore.
>
> The default value for that leaf is assigned by server in the operational
> datastore as part of the applied configuration (assuming that other
> configurations do not override it).
>
> If that leaf exists in the operational datastore, the server shall return the
> default value if that leaf is read.
>
> Is our understanding correct?
Yes. And you would tag the value with or:origin="or:default", appendix C.1
in RFC 8342 is a good example.
> Is it possible for a server not to use that leaf and not to return any value
> if that leaf is read?
>
> According to this text from RFC8342, it seems that this is possible:
>
> Requests to retrieve nodes from <operational> always return the value
> in use if the node exists, regardless of any default value specified
> in the YANG module. If no value is returned for a given node, then
> this implies that the node is not used by the device.
>
> However, according to this text from RFC7950, it seems that this is not
> possible:
>
> When the default value is in use, the server MUST operationally
> behave as if the leaf was present in the data tree with the default
> value as its value.
I do not see the conflict. Note that RFC 7950 predates the notion of
an operational datastore.
> There are case where the default value to assign to a leaf depends on the
> configuration of other leaves. In this case, the default value cannot be
> defined using a YANG default statement.
>
> In this case, is it possible in this case to define the default value in the
> description (maybe referencing some other standard specification)?
>
> Would the behavior of the system be exactly the same as in the cases where
> the default value is assigned using a YANG default statement?
RFC 8342 says:
o default: represents configuration using a default value specified
in the data model, using either values in the "default" statement
or any values described in the "description" statement. The
default origin is only used when the configuration has not been
provided by any other source.
and
identity default {
base origin;
description
"Denotes configuration that does not have a configured or
learned value but has a default value in use. Covers both
values defined in a 'default' statement and values defined
via an explanation in a 'description' statement.";
}
So it is possible to define the default in a description clause.
> Would it be possible in this case to define a default value for a leaf
> defined in a base model which depends on an attribute defined in another
> model which augments the base model?
> In this case, the description of the leaf in the base model cannot be changed
> in the augmented model. Should the default value for the leaf defined in the
> base model be described in the description for the leaf defined in the
> augmenting module?
> For example, would this YANG be valid/correct to define a default value 10
> for the leaf foo when the leaf bar exist?
>
> module example-base {
> container example {
> leaf foo {
> type uint8;
> }
> }
> }
>
> module example-augment {
> import example {
> prefix ex;
> }
>
> augment "ex:example" {
> leaf bar {
> type empty;
> description
> "When present, the default value for foo is 10.";
> }
> }
> }
>
Well, this may be meaningful in some cases but it is also risky, if
multiple augementations start to disagree on what should be the
default of some other leaf. Alternatively, you could report the value
foo=10 with the origin "system". For most clients, it likely does not
matter much whether foo=10 is reported with origin=default or
origin=system if the default derivation logic becomes more complex.
For me personally, if there is more complex logic involved in deriving
a value for a leaf (i.e., the existence of other leafs or values of
other leafs matter), then I would rather call it a system provided
value and not a default value.
/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
