Hi Chris, Andy,
On 21/07/2018 17:00, Christian Hopps wrote:
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.
Not sure that I agree.
I think that you have made an assumption here that the server will
continue to support both old and new major revision (with different
name) of the module at the same time. However, these is nothing in the
existing YANG upgrade rules that requires that.
Ultimately, there is a choice whether supporting older module versions
is the servers problem or the clients problem, or perhaps a combination
of the two.
The aim of requirement 3.1 is to ensure that there is a standard
mechanism available so that server implementations that want the
flexibility of supporting older client versions have a standard way of
doing so. My intention is that this part of the solution would be
optional to implement and hence decided by the market, which is why the
text in the requirement is "to allow servers" rather than "to require
servers".
Thanks,
Rob
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 <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
