On 23/07/2018 12:54, Andy Bierman wrote:
On Mon, Jul 23, 2018 at 2:50 AM, Robert Wilton <rwil...@cisco.com
<mailto:rwil...@cisco.com>> wrote:
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".
API versioning is usually done on the message exchanges.
Trying to do the same for datastore contents is not going to work.
A YANG schema can be considered an API. Particularly looking at say the
OpenConfig YANG schema. I doubt all implementations will store all
their configuration and operational state in a central place.
You can write the word MUST in all caps as many times as you want,
but that will not change anything.
I disagree. Marking a requirement as a MUST means that requirement has
to be met for a solution to be considered viable.
I previously had some text in the draft explaining how RFC 2119 text
translates to evaluating the requirements, but was asked to take it out
because it is obvious. Perhaps it should go back in ...
Thanks,
Rob
Thanks,
Rob
Andy
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 <a...@yumaworks.com <mailto:a...@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 <mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
netmod@ietf.org <mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
