Re: [netmod] yang-08: changing a default

[Phil Shafer <phil at juniper.net>]

Juergen Schoenwaelder writes:
>Martin took the position that changing a default might break a
>contract between a client and a server. In the case where you add a
>default, you can't break a contract since there was no defined
>default. This is a reasonable position.
>
>Andy argues that clients have to know the exact version of the data
>model used by a given server (and its deviations) in order to do the
>right thing. And yes, this is also a defendable position - but it
>means that clients have to be pretty smart and be able to deal with
>many different revisions (even in a single vendor product line). This
>sets the bar of relying on defaults from the client side pretty
>high. So if my client happens to care of the value (means it needs a
>certain value - not that it is fine with whatever default value the
>server will pick), it better sets the value even if the data model
>promises the same default value in its data model. In other words, I
>would very likely not take any advantage of the knowledge of a default
>value on a client side since doing it correctly is way more effort
>that is the saving's gain.

Both are reasonable goals.  Is there a conflict?  If the previous
revision had no default, then the old client will always send a
value if it needs/wants to.  The default can move from unknown
to known, but not from known to known.

The primary issue with the "just make a new knob" is if the knob
is mandatory or referenced by must or when expressions, then it
must be set, even if ignored.

Perhaps what is really needed is two levels of revisions, the
compatible ones and the incompatible ones.  If you change the
default, the new revision is not compatible with the old one,
and clients (and users) should be warned.

Thanks,
 Phil