Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00

As I pointed out at the mic @102 this requirement derives directly from the 1.x requirement of not changing the name of the module/namespace. If you allow for changing the namespace/module name for "major" (i.e., incompatible) changes (i.e., like today) then this 3.1 requirement goes away.

I think the plan is to reword some of these to get closer to the intention which I believe is to allow for smoother transition from one module to the next while making incompatible but mostly non-impacting changes.

Thanks,
Chris.

Andy Bierman <andy@yumaworks.com> writes:

> Hi,
>
> I strongly object to requirement 3.1:
>
>
>     3.1  The solution MUST provide a mechanism to allow servers to
>             support existing clients in a backward compatible way.
>
>
>
> This is not what servers do today at all.
> They provide only one version of an implemented module, as specified in RFC
> 7950.
>
> It is a vendor and operator decision when to upgrade a server such that
> non-backward compatible changes are made. They must decide if/when it is ok
> based on the client applications in use.
>
> This requirement says you cannot make backward-incompatible changes
> which completely contradicts requirements 1.1 and 1.2.
>
> IMO requirement 3.1 should be removed, or change MUST to MAY
>
>
> Andy
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod