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
