Re: [netmod] Questions about how to assign default values with YANG

[Italo Busi <[e-mail]>]

Juergen,

I think you have got the problem: "a data model author thought the default is always 0 and later he/she realizes that in some contexts the default should be something different"

Unless I am missing something, creating a new leaf (e.g., foo-new) would confuse an existing client.

For example, within the operational DS, the value of foo will be set to 0 (as per YANG default statement) while the value of foo-new will be set to 10, which represents the actual value in use by the system.

Now, the existing client, which is not aware of foo-new, when reading the value of foo in the operational DS will incorrectly think that the actual value in use by the system is 0 rather than 10.

Am I missing anything?

Instead, if we can find a magic way to apply the value 10 to foo within the operational DS, the existing client can read the value of foo in the operational DS and correctly understand that the actual value in use by the system is 10 (even if this is not the default value of foo).

Italo

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[e-mail]]
> Sent: mercoledì 10 marzo 2021 17:15
> To: Italo Busi <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [netmod] Questions about how to assign default values with
> YANG
>
> I do not understand where the problem is.
>
> a) If a leaf says my default is 0, then the default is 0 and you can't
>    change that by creating other leafs somewhere else that says
>    something different.
>
> b) If a leaf says that is has a default value but the value is
>    determined in some magic way not defined here, then you can add
>    additional leafs that detail the magic for certain contexts
>
> The point is that a) tells clients they can safely assume the default value is 0
> while b) tells clients that they can assume that there is a default but the exact
> default value they will not know unless they understand magic.
>
> If a data model author thought the default is always 0 and later he/she
> realizes that in some contexts the default should be something different, then
> you have to resolve that by creating new leafs (in the current version of YANG)
> or you declares a non-backwards compatible new version of the definition of
> the leaf (if the versioning work gets standardized).
>
> /js
>
> On Wed, Mar 10, 2021 at 03:25:13PM +0000, Italo Busi wrote:
> > Hi Andy,
> >
> > I see your point,
> >
> > At the beginning of this thread, I have had a doubt about how to reconcile
> sec. 7.6.1 of RFC7950 with sec. 5.3 of RFC8342:
> >
> >    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.
> >
> > My understanding that the client will always get the applied value
> independently on whether it is 0 or 10 or another value.
> >
> > Anyway, it seems to me that the issue is mainly about the keyword “default”
> so let me take a step back and try to define the issue I am trying to solve,
> without assuming any solution.
> >
> > What I need is to find a solution that allows a client to request the server to
> apply the value 10 for the leaf foo in the operational DS without “explicitly”
> writing the value 10 in the running DS but “implicitly” by writing another leaf
> bar in the running DS, even if the leaf foo has a YANG default statement
> defining 0 as its default value.
> >
> > I think that the NMDA architecture is quite flexible and could be leveraged
> to resolve this issue.
> >
> > Stepping away from defining default values, one possibility could be that
> the applied configuration of the value of foo is defined by the system before
> applying the intended configuration in the operational DS, as a side effect of
> applying the configuration of the leaf bar.
> >
> > Another alternative which is just jumping to my mind, could be that the
> value of 10 for the leaf foo is set by the system in the intended DS, applying a
> sort of template. Should in this case the definition of the leaf bar be
> interpreted as a template configuration or how should the required template
> configuration be provided?
> >
> > Could any of this option be used to resolve this issue?
> >
> > Italo
> >
> > From: Andy Bierman [mailto:[e-mail]]
> > Sent: mercoledì 10 marzo 2021 15:16
> > To: Italo Busi <[e-mail]<mailto:[e-mail]>>
> > Cc: Juergen Schoenwaelder <[e-mail]<mailto:[e-mail]>>;
> > [e-mail]<mailto:[e-mail]>
> > Subject: Re: [netmod] Questions about how to assign default values
> > with YANG
> >
> >
> >
> > On Wed, Mar 10, 2021 at 12:54 AM Italo Busi
> <[e-mail]<mailto:[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>> wrote:
> > Andy, Juergen,
> >
> > I am not sure I understand the issue with a client that does not understand
> the augment.
> >
> > When this client writes in the running DS, it will not set the bar attribute
> (which is also defined in the augment module) and therefore the default
> value 0 will be applied by the system, as expected by the client.
> >
> > When this client reads from the operational DS the applied configuration,
> provided by another client which understands the augment, it will see that
> the applied configuration for the leaf foo is 10.
> >
> > This is a valid applied configuration if the other client had explicitly
> configured the value 10 in the running DS.
> >
> > The only difference would be that when the value 10 is explicitly configured
> by the other client the origin is set to intended while when “implicitly”
> configured using the attribute bar, the origin can be set to system (I think it
> would not be correct to set the origin to default in this case).
> >
> > BTW, I agree that this is not the most elegant/clean design and that the best
> approach would be not to define any default value in the base model. I am
> just willing to understand if a work-around is possible, without breaking any
> client, to allow re-using an existing module which has already defined a
> default value.
> >
> >
> > Read sec. 7.6.1 again, especially this part:
> >
> >    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.
> >
> >
> >
> >
> >
> > Your proposal violates this MUST because the default is in use
> > according to the rules
> >
> >
> >
> >
> >
> > Italo
> >
> >
> > Andy
> >
> >
> > From: Andy Bierman
> > [mailto:[e-mail]<mailto:[e-mail]>]
> > Sent: martedì 9 marzo 2021 21:12
> > To: Juergen Schoenwaelder
> > <[e-mail]<mailto:j.schoenwaelder@jacobs-un
> > iversity.de>>; Italo Busi
> > <[e-mail]<mailto:[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>>;
> > [e-mail]<mailto:[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>
> > Subject: Re: [netmod] Questions about how to assign default values
> > with YANG
> >
> >
> >
> > On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder
> <[e-mail]<mailto:j.schoenwaelder@jacobs-<mailto:[e-mail]<mailto:[e-mail]>
> university.de>> wrote:
> > Changing the semantics of a definition via augments is bad design.
> >
> > A system that does not understand the augment will believe the default
> > is 0. Since there is no way to force an existing implementation to
> > understand a certain augmentation, different implementation will
> > rightfully disagree on the default value in effect.
> >
> >
> > deviation /ex:example/ex:foo {
> >     delete {
> >        default 0;
> >      }
> > }
> >
> > IMO it was a bad idea to say deviations MUST NOT appear in standard
> modules.
> > Here is a use-case for it.
> >
> > The old-client does not know about the new dynamic default but it
> > could know that the old YANG default is not being used.
> >
> >
> > /js
> >
> > Andy
> >
> >
> > On Mon, Mar 08, 2021 at 08:19:39PM +0000, Italo Busi wrote:
> > > 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:
> > >
> > > 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:[e-mail]<mailto:j.schoenwaelde
> > > > [e-mail]<mailto:[e-mail]>>]
> > > > Sent: mercoledì 20 gennaio 2021 17:05
> > > > To: Italo Busi
> > > > <[e-mail]<mailto:[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>>
> > > > Cc: '[e-mail]<mailto:[e-mail]>'
> > > > <[e-mail]<mailto:[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>>
> > > > 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: [phone]         Campus Ring 1 | 28759 Bremen |
> Germany
> > > > Fax:   [phone]         <https://www.jacobs-university.de/>
> > >
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://www.jacobs-university.de/>
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]<mailto:[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>