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

[Italo Busi <[e-mail]>]

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:[e-mail]]
> Sent: mercoledì 10 marzo 2021 19:34
> To: Italo Busi <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [netmod] Questions about how to assign default values with
> YANG
> 
> On Wed, Mar 10, 2021 at 05:34:41PM +0000, 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 <operational> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>