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

[Andy Bierman]

On Wed, Mar 10, 2021 at 11:24 AM Italo Busi  wrote:

> Hi Jurgen,
>
> Now I can understand your concerns :)
>
> > If all clients are in an
> > NMDA world, the issue is much smaller - it is reduced to "does the client
> > believe the server has a bug or not".
>
> Yes, I was assuming that all the clients and the server were
> NMDA-compliant. It seems worthwhile spelling out this requirement more
> explicitly when defining the work-around.
>
> I think that the solution would also work if the client and the server
> follows the guidelines of section 2 of draft-dsdt-nmda-guidelines-01: in
> this case the behavior of the NMDA module in the running DS would be fully
> compliant with RFC8342, while the non-NMDA module would be an exact copy of
> the operational DS (the client needs to read within this module to get the
> in-use value).
>
> Otherwise, I am not sure how can an non-NMDA client properly operate over
> an NMDA server: the values reported by the server in the running DS do not
> necessarily represent the values in use by the system.
>
> > But even then, I continue to believe that
> > a leaf changing the semantics of another leaf is bad design.
>
> I agree: I am just looking for a reasonable work-around that could work
> when it is not possible to remove an existing YANG default statement.
>
> The lesson-learnt from this discussion is that more care has to be taken
> when defining YANG default statements.
>
>
Or the lesson could be that the concept and implementation of YANG module
conformance
is still "under construction". You want to deviate from the old conformance
and
require a new conformance instead.

In SMIv2, model conformance can be per use-case, not just per-module
and explicit conformance statements are used, instead of conformance
implied by the
YANG statements themselves.

In this case, conformance to the new module is desired (without the YANG
default)
instead of conformance to the old module (with the YANG default). A server
cannot
advertise both modules, unless it also declares that it deviates from the
old module conformance.
(deviate delete default)

A new client finds the new module + the old module + the deviation.
An old client finds the old module and the deviation (if YANG compliant).
An old client thinks the server is deviating from the old module conformance
(because that is exactly what is happening).


Andy


>
> > -Original Message-
> > From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de
> ]
> > Sent: mercoledì 10 marzo 2021 19:34
> > To: Italo Busi 
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] Questions about how to assign default values with
> > YANG
> >
> > On Wed, Mar 10, 2021 at 05:34:41PM +, Italo Busi wrote:
> > > 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.
> >
> > No, it does not confuse the client, the client will ignore it.
> >
> > > 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.
> >
> > Yes, a new implementation will have to declare that it does not implement
> > foo.
> >
> > > 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.
> >
> > A client reading  knows the value in use. But clients do
> not have
> > to real operational.
> >
> > > 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).
> >
> > In general, you can't assume that clients read operational. I can't
> judge the
> > specific circumstances but in traditional NC/RC, a default statement can
> be
> > interpreted as "assume the default value is in force if this lead is not
> > configured" (unless the client uses RFC 6243 report-all). If all clients
> are in an
> > NMDA world, the issue is much 

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

[Italo Busi]

Hi Jurgen,

Now I can understand your concerns :)

> If all clients are in an
> NMDA world, the issue is much smaller - it is reduced to "does the client
> believe the server has a bug or not". 

Yes, I was assuming that all the clients and the server were NMDA-compliant. It 
seems worthwhile spelling out this requirement more explicitly when defining 
the work-around.

I think that the solution would also work if the client and the server follows 
the guidelines of section 2 of draft-dsdt-nmda-guidelines-01: in this case the 
behavior of the NMDA module in the running DS would be fully compliant with 
RFC8342, while the non-NMDA module would be an exact copy of the operational DS 
(the client needs to read within this module to get the in-use value).

Otherwise, I am not sure how can an non-NMDA client properly operate over an 
NMDA server: the values reported by the server in the running DS do not 
necessarily represent the values in use by the system.

> But even then, I continue to believe that
> a leaf changing the semantics of another leaf is bad design.

I agree: I am just looking for a reasonable work-around that could work when it 
is not possible to remove an existing YANG default statement.

The lesson-learnt from this discussion is that more care has to be taken when 
defining YANG default statements.

Italo

> -Original Message-
> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> Sent: mercoledì 10 marzo 2021 19:34
> To: Italo Busi 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Questions about how to assign default values with
> YANG
> 
> On Wed, Mar 10, 2021 at 05:34:41PM +, Italo Busi wrote:
> > 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.
> 
> No, it does not confuse the client, the client will ignore it.
> 
> > 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.
> 
> Yes, a new implementation will have to declare that it does not implement
> foo.
> 
> > 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.
> 
> A client reading  knows the value in use. But clients do not have
> to real operational.
> 
> > 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).
> 
> In general, you can't assume that clients read operational. I can't judge the
> specific circumstances but in traditional NC/RC, a default statement can be
> interpreted as "assume the default value is in force if this lead is not
> configured" (unless the client uses RFC 6243 report-all). If all clients are 
> in an
> NMDA world, the issue is much smaller - it is reduced to "does the client
> believe the server has a bug or not". But even then, I continue to believe 
> that
> a leaf changing the semantics of another leaf is bad design.
> 
> /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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

On Wed, Mar 10, 2021 at 05:34:41PM +, Italo Busi wrote:
> 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.

No, it does not confuse the client, the client will ignore it.
 
> 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.

Yes, a new implementation will have to declare that it does not
implement foo.
 
> 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.

A client reading  knows the value in use. But clients do
not have to real operational.

> 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).

In general, you can't assume that clients read operational. I can't
judge the specific circumstances but in traditional NC/RC, a default
statement can be interpreted as "assume the default value is in force
if this lead is not configured" (unless the client uses RFC 6243
report-all). If all clients are in an NMDA world, the issue is much
smaller - it is reduced to "does the client believe the server has a
bug or not". But even then, I continue to believe that a leaf changing
the semantics of another leaf is bad design.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Italo Busi]

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:j.schoenwael...@jacobs-university.de]
> Sent: mercoledì 10 marzo 2021 17:15
> To: Italo Busi 
> Cc: netmod@ietf.org
> 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 +, 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  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:a...@yumaworks.com]
> > Sent: mercoledì 10 marzo 2021 15:16
> > To: Italo Busi mailto:italo.b...@huawei.com>>
> > Cc: Juergen Schoenwaelder 
> > mailto:j.schoenwael...@jacobs-university.de>>;
> > netmod@ietf.org<ma

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

[Juergen Schoenwaelder]

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 +, 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  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:a...@yumaworks.com]
> Sent: mercoledì 10 marzo 2021 15:16
> To: Italo Busi 
> Cc: Juergen Schoenwaelder ; 
> netmod@ietf.org
> Subject: Re: [netmod] Questions about how to assign default values with YANG
> 
> 
> 
> On Wed, Mar 10, 2021 at 12:54 AM Italo Busi 
> mailto:italo.b...@huawei.com>> 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, t

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

[Andy Bierman]

On Wed, Mar 10, 2021 at 6:34 AM William Lupton 
wrote:

> Lada, all,
>
> Surely a description is the only way to add a normative requirement that
> can't be expressed via YANG statements (including XPath expressions)?
>
>

description-stmt requirements are normative.
RFC 2119 language applies exactly the same as if it were in some text
section insted of the YANG module.

The issue is that the normative requirements for YANG 1.1 defined in RFC
7950 cannot be
negated by a description-stmt. E.g.

module bad {

leaf turn-off-mandatory {
type empty;
description
   "If this leaf is present then all YANG mandatory-stmts are
ignored throughout this module.";
}

This may be a valid description-stmt and YANG leaf but any server that
implements it is also
violating MUST requirements in RFC 7950.


Andy



> I've always assumed that it's good practice to express what you can using
> the modeling language, and then use the description to express any
> non-modelable requirements. Obviously there's a problem if the description
> conflicts with a modeled requirement (and I think it's also good practice
> for the description not to repeat anything that's modeled elsewhere).
>
> I think that RFC 7950 can be interpreted as indicating that the
> description is more than just informative. I found this in Section 11, and
> I take this to imply that the description defines the semantics of
> a definition.
>
> A "description" statement may be added or changed without changing the
>
> semantics of the definition.
>
>
> For example, if a description says this (this is an example from RFC
> 7950), then isn't this a _normative_ semantic requirement?
>
> "The amount of local storage that can be used to hold syslog messages."
>
>
> William
>
> On Wed, 10 Mar 2021 at 10:21, Ladislav Lhotka 
> wrote:
>
>> Juergen Schoenwaelder  writes:
>>
>> > A client that has no clue of the annotated leaf can rightfully assume
>> > that the default 0 applies. If another client creates this magic leaf
>> > that changes the default to 10, then there is going to be confusion.
>> >
>> > A definition that says 'default 0' says the default is 0. It does not
>> > say the default may be zero or something different depending on
>> > whether the moon shines or other circumstances. I believe you can't
>> > undo a default statement with a description somewhere else.
>>
>> The problem with descriptions is that there seems to be a general
>> agreement that they can somehow supplement the formal YANG statements in
>> specifying the data model. This has no support in RFC 7950 though:
>>
>> - section 7.21.3 only says that a description is "a human-readable textual
>>   description of this definition"
>>
>> - section 8.1 doesn't include constraints specified in descriptions in the
>>   concept of data tree validity
>>
>> As a result, data model constraints specified in descriptions is a grey
>> area, and it is totally unclear how far-reaching they can possibly be.
>>
>> Lada
>>
>> >
>> > /js
>> >
>> > On Wed, Mar 10, 2021 at 08:54:18AM +, Italo Busi 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 mo

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

[William Lupton]

> >> >>
> >> >> 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.
> >> >>
> >> >> Italo
> >> >>
> >> >> From: Andy Bierman [mailto:a...@yumaworks.com]
> >> >> Sent: martedì 9 marzo 2021 21:12
> >> >> To: Juergen Schoenwaelder ;
> >> Italo Busi ; netmod@ietf.org
> >> >> Subject: Re: [netmod] Questions about how to assign default values
> with
> >> YANG
> >> >>
> >> >>
> >> >>
> >> >> On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder <
> >> j.schoenwael...@jacobs-university.de >> j.schoenwael...@jacobs-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 +, 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).
> >> >> >
> >> &g

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

[Italo Busi]

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  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:a...@yumaworks.com]
Sent: mercoledì 10 marzo 2021 15:16
To: Italo Busi 
Cc: Juergen Schoenwaelder ; 
netmod@ietf.org
Subject: Re: [netmod] Questions about how to assign default values with YANG



On Wed, Mar 10, 2021 at 12:54 AM Italo Busi 
mailto:italo.b...@huawei.com>> 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:a...@yumaworks.com<mailto:a...@yumaworks.com>]
Sent: martedì 9 marzo 2021 21:12
To: Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>;
 Italo Busi mailto:italo.b...@huawei.com>>; 
netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Questions about how to assign default values with YANG



On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-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 +, Italo Busi wrote:
> Hi Juergen,
>
> Thanks again for your cle

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

[Ladislav Lhotka]

William Lupton  writes:

> Lada, all,
>
> Surely a description is the only way to add a normative requirement that
> can't be expressed via YANG statements (including XPath expressions)?
>
> I've always assumed that it's good practice to express what you can using
> the modeling language, and then use the description to express any
> non-modelable requirements. Obviously there's a problem if the description
> conflicts with a modeled requirement (and I think it's also good practice
> for the description not to repeat anything that's modeled elsewhere).
>
> I think that RFC 7950 can be interpreted as indicating that the description
> is more than just informative. I found this in Section 11, and I take this
> to imply that the description defines the semantics of a definition.

Even then, it is unclear what effects are permitted with this "more than 
informative". In a previous mail I refered to a standard module having a 
description that defines a (computed) default. This seems to be acceptable.

But what about simulating a "when" statement for constraints that cannot be 
expressed via XPath? For example:

  description
"This leaf is only valid if the value of foo is prime.";

I argued in the past that everything that cannot be expressed formally with 
YANG statements should be left outside of scope for YANG, at least in terms of 
data tree validation.

>
> A "description" statement may be added or changed without changing the
>
> semantics of the definition.
>
>
> For example, if a description says this (this is an example from RFC 7950),
> then isn't this a _normative_ semantic requirement?
>
> "The amount of local storage that can be used to hold syslog messages."

Hmm, this seems to state semantics (meaning) of a parameter. What I am talking 
about are semantic constraints (business rules) that a valid data tree is 
required to satisfy.

Lada

>
>
> William
>
> On Wed, 10 Mar 2021 at 10:21, Ladislav Lhotka 
> wrote:
>
>> Juergen Schoenwaelder  writes:
>>
>> > A client that has no clue of the annotated leaf can rightfully assume
>> > that the default 0 applies. If another client creates this magic leaf
>> > that changes the default to 10, then there is going to be confusion.
>> >
>> > A definition that says 'default 0' says the default is 0. It does not
>> > say the default may be zero or something different depending on
>> > whether the moon shines or other circumstances. I believe you can't
>> > undo a default statement with a description somewhere else.
>>
>> The problem with descriptions is that there seems to be a general
>> agreement that they can somehow supplement the formal YANG statements in
>> specifying the data model. This has no support in RFC 7950 though:
>>
>> - section 7.21.3 only says that a description is "a human-readable textual
>>   description of this definition"
>>
>> - section 8.1 doesn't include constraints specified in descriptions in the
>>   concept of data tree validity
>>
>> As a result, data model constraints specified in descriptions is a grey
>> area, and it is totally unclear how far-reaching they can possibly be.
>>
>> Lada
>>
>> >
>> > /js
>> >
>> > On Wed, Mar 10, 2021 at 08:54:18AM +, Italo Busi 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
>>

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

[William Lupton]

Lada, all,

Surely a description is the only way to add a normative requirement that
can't be expressed via YANG statements (including XPath expressions)?

I've always assumed that it's good practice to express what you can using
the modeling language, and then use the description to express any
non-modelable requirements. Obviously there's a problem if the description
conflicts with a modeled requirement (and I think it's also good practice
for the description not to repeat anything that's modeled elsewhere).

I think that RFC 7950 can be interpreted as indicating that the description
is more than just informative. I found this in Section 11, and I take this
to imply that the description defines the semantics of a definition.

A "description" statement may be added or changed without changing the

semantics of the definition.


For example, if a description says this (this is an example from RFC 7950),
then isn't this a _normative_ semantic requirement?

"The amount of local storage that can be used to hold syslog messages."


William

On Wed, 10 Mar 2021 at 10:21, Ladislav Lhotka 
wrote:

> Juergen Schoenwaelder  writes:
>
> > A client that has no clue of the annotated leaf can rightfully assume
> > that the default 0 applies. If another client creates this magic leaf
> > that changes the default to 10, then there is going to be confusion.
> >
> > A definition that says 'default 0' says the default is 0. It does not
> > say the default may be zero or something different depending on
> > whether the moon shines or other circumstances. I believe you can't
> > undo a default statement with a description somewhere else.
>
> The problem with descriptions is that there seems to be a general
> agreement that they can somehow supplement the formal YANG statements in
> specifying the data model. This has no support in RFC 7950 though:
>
> - section 7.21.3 only says that a description is "a human-readable textual
>   description of this definition"
>
> - section 8.1 doesn't include constraints specified in descriptions in the
>   concept of data tree validity
>
> As a result, data model constraints specified in descriptions is a grey
> area, and it is totally unclear how far-reaching they can possibly be.
>
> Lada
>
> >
> > /js
> >
> > On Wed, Mar 10, 2021 at 08:54:18AM +, Italo Busi 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.
> >>
> >> Italo
> >>
> >> From: Andy Bierman [mailto:a...@yumaworks.com]
> >> Sent: martedì 9 marzo 2021 21:12
> >> To: Juergen Schoenwaelder ;
> Italo Busi ; netmod@ietf.org
> >> Subject: Re: [netmod] Questions about how to assign default values with
> YANG
> >>
> >>
> >>
> >> On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de j.schoenwael...@jacobs-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:examp

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

[Andy Bierman]

On Wed, Mar 10, 2021 at 12:54 AM Italo Busi  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:a...@yumaworks.com]
> *Sent:* martedì 9 marzo 2021 21:12
> *To:* Juergen Schoenwaelder ; Italo
> Busi ; netmod@ietf.org
> *Subject:* Re: [netmod] Questions about how to assign default values with
> YANG
>
>
>
>
>
>
>
> On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-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 +, 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:
> j.schoenwael...@jacobs-university.de]
> > &

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

[Ladislav Lhotka]

Juergen Schoenwaelder  writes:

> A client that has no clue of the annotated leaf can rightfully assume
> that the default 0 applies. If another client creates this magic leaf
> that changes the default to 10, then there is going to be confusion.
>
> A definition that says 'default 0' says the default is 0. It does not
> say the default may be zero or something different depending on
> whether the moon shines or other circumstances. I believe you can't
> undo a default statement with a description somewhere else.

The problem with descriptions is that there seems to be a general agreement 
that they can somehow supplement the formal YANG statements in specifying the 
data model. This has no support in RFC 7950 though:

- section 7.21.3 only says that a description is "a human-readable textual
  description of this definition"

- section 8.1 doesn't include constraints specified in descriptions in the
  concept of data tree validity

As a result, data model constraints specified in descriptions is a grey area, 
and it is totally unclear how far-reaching they can possibly be.

Lada

>
> /js
>
> On Wed, Mar 10, 2021 at 08:54:18AM +, Italo Busi 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.
>> 
>> Italo
>> 
>> From: Andy Bierman [mailto:a...@yumaworks.com]
>> Sent: martedì 9 marzo 2021 21:12
>> To: Juergen Schoenwaelder ; Italo Busi 
>> ; netmod@ietf.org
>> Subject: Re: [netmod] Questions about how to assign default values with YANG
>> 
>> 
>> 
>> On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder 
>> mailto:j.schoenwael...@jacobs-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 +, 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 exam

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

[Juergen Schoenwaelder]

A client that has no clue of the annotated leaf can rightfully assume
that the default 0 applies. If another client creates this magic leaf
that changes the default to 10, then there is going to be confusion.

A definition that says 'default 0' says the default is 0. It does not
say the default may be zero or something different depending on
whether the moon shines or other circumstances. I believe you can't
undo a default statement with a description somewhere else.

/js

On Wed, Mar 10, 2021 at 08:54:18AM +, Italo Busi 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.
> 
> Italo
> 
> From: Andy Bierman [mailto:a...@yumaworks.com]
> Sent: martedì 9 marzo 2021 21:12
> To: Juergen Schoenwaelder ; Italo Busi 
> ; netmod@ietf.org
> Subject: Re: [netmod] Questions about how to assign default values with YANG
> 
> 
> 
> On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder 
> mailto:j.schoenwael...@jacobs-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 +, 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:j.schoenwael.

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

[Italo Busi]

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.

Italo

From: Andy Bierman [mailto:a...@yumaworks.com]
Sent: martedì 9 marzo 2021 21:12
To: Juergen Schoenwaelder ; Italo Busi 
; netmod@ietf.org
Subject: Re: [netmod] Questions about how to assign default values with YANG



On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-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 +, 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:j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>]
> > Sent: mercoledì 20 gennaio 2021 17:05
> > To: Italo Busi mailto:italo.b...@huawei.com>>
> > Cc: 'netmod@ietf.org<mailto: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 +, 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

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

[Andy Bierman]

On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-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 +, 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:
> j.schoenwael...@jacobs-university.de]
> > > Sent: mercoledì 20 gennaio 2021 17:05
> > > To: Italo Busi 
> > > Cc: 'netmod@ietf.org' 
> > > Subject: Re: [netmod] Questions about how to assign default values with
> > > YANG
> > >
> > > On Wed, Jan 20, 2021 at 02:41:39PM +, 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:
> > >
> > >  -  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
> > > . 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 . 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  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 boole

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

[Juergen Schoenwaelder]

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.

/js

On Mon, Mar 08, 2021 at 08:19:39PM +, 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:j.schoenwael...@jacobs-university.de]
> > Sent: mercoledì 20 gennaio 2021 17:05
> > To: Italo Busi 
> > Cc: 'netmod@ietf.org' 
> > Subject: Re: [netmod] Questions about how to assign default values with
> > YANG
> >
> > On Wed, Jan 20, 2021 at 02:41:39PM +, 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:
> >
> >  -  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
> > . 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 . 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  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/>
> 

-- 
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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Italo Busi]

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:a...@yumaworks.com]
Sent: martedì 9 marzo 2021 17:58
To: Italo Busi ; Juergen Schoenwaelder 
; netmod@ietf.org
Subject: Re: [netmod] Questions about how to assign default values with YANG



On Tue, Mar 9, 2021 at 8:46 AM Ladislav Lhotka 
mailto:ladislav.lho...@nic.cz>> wrote:
Italo Busi 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



- 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 

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

[Ladislav Lhotka]

;     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>
> >     <mailto:j.schoenwael...@jacobs-university.de
> <mailto:j.schoenwael...@jacobs-university.de>>]
> >     >> Sent: mercoledì 20 gennaio 2021 17:05
> >     >> To: Italo Busi  <mailto:italo.b...@huawei.com> <mailto:italo.b...@huawei.com
> <mailto:italo.b...@huawei.com>>>
> >     >> Cc: 'netmod@ietf.org <mailto:netmod@ietf.org>
> <mailto:netmod@ietf.org <mailto:netmod@ietf.org>>'  <mailto:netmod@ietf.org>
> >     <mailto: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 +, 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:
> >     >>
> >     >>  -  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
> >     >> . 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 . 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  may have many reasons
> >     (instrume

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

[Andy Bierman]

On Tue, Mar 9, 2021 at 9:32 AM Ladislav Lhotka 
wrote:

> On 09. 03. 21 17:58, Andy Bierman wrote:
> >
> >
> > On Tue, Mar 9, 2021 at 8:46 AM Ladislav Lhotka  > <mailto:ladislav.lho...@nic.cz>> wrote:
> >
> > Italo Busi 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 op

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

[Ladislav Lhotka]

On 09. 03. 21 17:58, Andy Bierman wrote:
> 
> 
> On Tue, Mar 9, 2021 at 8:46 AM Ladislav Lhotka  <mailto:ladislav.lho...@nic.cz>> wrote:
> 
> Italo Busi 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?

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:j.schoenwael...@jacobs-university.de
> <mailto:j.schoenwael...@jacobs-university.de>]
> >> Sent: mercoledì 20 gennaio 2021 17:05
> >> To: Italo Busi mailto:italo.b...@huawei.com>>
> >> Cc: 'netmod@ietf.org <mailto: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 +, Italo Busi wrote:
> >> >
> >> > What about the case the leaf is not conditional (but still
> mandatory false
> >> si

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

[Italo Busi]

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:j.schoenwael...@jacobs-university.de]
> Sent: mercoledì 20 gennaio 2021 17:05
> To: Italo Busi 
> Cc: 'netmod@ietf.org' 
> Subject: Re: [netmod] Questions about how to assign default values with
> YANG
>
> On Wed, Jan 20, 2021 at 02:41:39PM +, 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:
>
>  -  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
> . 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 . 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  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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

On Wed, Jan 20, 2021 at 02:41:39PM +, 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:

 -  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
. 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 . 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 
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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Italo Busi]

Thanks again Juergen,

This was really helpful

I still have one doubt:

> > Does it mean that a server may not use/implement in the operational
> datastore a leaf for which a YANG default statement has been defined?
> >
> 
> RFC 7950 section 7.6.1 mentions describes situations where a leaf is
> conditional, i.e., there is when condition or an if-feature expression or the 
> leaf
> is a case node.
>

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)?

Italo

> -Original Message-
> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> Sent: mercoledì 20 gennaio 2021 12:45
> To: Italo Busi 
> Cc: 'netmod@ietf.org' 
> Subject: Re: [netmod] Questions about how to assign default values with
> YANG
> 
> On Wed, Jan 20, 2021 at 10:51:09AM +, Italo Busi wrote:
> >
> > Does it mean that a server may not use/implement in the operational
> datastore a leaf for which a YANG default statement has been defined?
> >
> 
> RFC 7950 section 7.6.1 mentions describes situations where a leaf is
> conditional, i.e., there is when condition or an if-feature expression or the 
> leaf
> is a case node.
> 
> > What would be the value of defining a YANG default statement for  config
> false leaf?
> >
> 
> Technically, this can happen because a type has a defined default value and
> this type may be used by config false leafs.
> 
> An example is the zero-based-counter32 typedef in RFC 6991. However, this
> style may be debated since it (mis)uses a default statement to define an 
> initial
> value. I am not sure whether the pattern of using default statements for
> specifying intial values is a good one.
> 
> /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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

On Wed, Jan 20, 2021 at 10:51:09AM +, Italo Busi wrote:
> 
> Does it mean that a server may not use/implement in the operational datastore 
> a leaf for which a YANG default statement has been defined?
>

RFC 7950 section 7.6.1 mentions describes situations where a leaf is
conditional, i.e., there is when condition or an if-feature expression
or the leaf is a case node.

> What would be the value of defining a YANG default statement for  config 
> false leaf?
>

Technically, this can happen because a type has a defined default
value and this type may be used by config false leafs.

An example is the zero-based-counter32 typedef in RFC 6991. However,
this style may be debated since it (mis)uses a default statement to
define an initial value. I am not sure whether the pattern of using
default statements for specifying intial values is a good one.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Italo Busi]

Juergen,

Thanks for your quick and clear reply.

Thanks also for the suggestion of using system provided values instead of 
default values.

I have only one doubt and one follow-up question:

> > 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  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.
>

Does it mean that a server may not use/implement in the operational datastore a 
leaf for which a YANG default statement has been defined?

What would be the value of defining a YANG default statement for  config false 
leaf?

Italo

> -Original Message-
> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> Sent: mercoledì 20 gennaio 2021 10:48
> To: Italo Busi 
> Cc: 'netmod@ietf.org' 
> Subject: Re: [netmod] Questions about how to assign default values with
> YANG
> 
> On Wed, Jan 20, 2021 at 08:57:48AM +, 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  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 e

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

[Juergen Schoenwaelder]

On Wed, Jan 20, 2021 at 08:57:48AM +, 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  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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod