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:[email protected]] > Sent: mercoledì 10 marzo 2021 19:34 > To: Italo Busi <[email protected]> > Cc: [email protected] > 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
