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

> So do we hit a requirement (which is independent of versioning) that a > mechanism is needed to select different module sets (or views), given > that the reality gives us overlapping and competing models? And then > as a side effect, such a mechanism may also be used to select between >

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

One answer to a slightly more general version of this question (why is OK for the clients to do nothing while the servers do the work) is that the client developers are often the server developers customers, they pay the bills. Also in general there is a one to many mapping from a server to

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

On 26/07/2018 15:16, Juergen Schoenwaelder wrote: On Thu, Jul 26, 2018 at 11:19:07AM +0100, Robert Wilton wrote: I think that some aspects of versioning are the same problem.  E.g. I think that there is a difference between a major release where more backwards compatible changes could be

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

On Thu, Jul 26, 2018 at 11:19:07AM +0100, Robert Wilton wrote: > > I think that some aspects of versioning are the same problem.  E.g. I think > that there is a difference between a major release where more backwards > compatible changes could be expected, vs maintenance releases where one >

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

On 25/07/2018 17:59, Juergen Schoenwaelder wrote: On Wed, Jul 25, 2018 at 05:25:32PM +0100, Robert Wilton wrote: One alternative way to build a robust client would be to have an internally defined schema by the client (perhaps based on open models, or perhaps a particular version of vendor

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

On Wed, Jul 25, 2018 at 05:25:32PM +0100, Robert Wilton wrote: > > > One alternative way to build a robust client would be to have an internally > defined schema by the client (perhaps based on open models, or perhaps a > particular version of vendor models, possibly with some deviations, or

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

On 25/07/2018 12:03, Juergen Schoenwaelder wrote: On Tue, Jul 24, 2018 at 04:32:05PM +0100, Robert Wilton wrote: But if fixing a definition requires a whole new module name then I think that causes lots of problems (e.g. consider needing to change ief-interfaces to ietf-interfaces-v2 because

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

On Tue, Jul 24, 2018 at 04:32:05PM +0100, Robert Wilton wrote: > > But if fixing a definition requires a whole new module name then I think > that causes lots of problems (e.g. consider needing to change ief-interfaces > to ietf-interfaces-v2 because of changing one random leaf). I assume this

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

On Tue, Jul 24, 2018 at 8:32 AM, Robert Wilton wrote: > > > On 24/07/2018 16:11, Andy Bierman wrote: > > > > On Tue, Jul 24, 2018 at 2:29 AM, Juergen Schoenwaelder < > j.schoenwael...@jacobs-university.de> wrote: > >> On Sat, Jul 21, 2018 at 05:47:45PM -0400, Christian Hopps wrote: >> >> > There

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

On 24/07/2018 16:11, Andy Bierman wrote: On Tue, Jul 24, 2018 at 2:29 AM, Juergen Schoenwaelder > wrote: On Sat, Jul 21, 2018 at 05:47:45PM -0400, Christian Hopps wrote: > There are actual instances where small perhaps non-disruptive

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

On Tue, Jul 24, 2018 at 2:29 AM, Juergen Schoenwaelder < j.schoenwael...@jacobs-university.de> wrote: > On Sat, Jul 21, 2018 at 05:47:45PM -0400, Christian Hopps wrote: > > > There are actual instances where small perhaps non-disruptive but > > incompatible changes are required. The example given

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

On Sat, Jul 21, 2018 at 05:47:45PM -0400, Christian Hopps wrote: > There are actual instances where small perhaps non-disruptive but > incompatible changes are required. The example given to me for this > type of change was when the original specification had an obvious > bug (e.g., a range was

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

Before RESTCONF, I implemented a versioned REST API that maintained constant object URIs, while allowing the objects themselves to be versioned, by using the Content-Type and Accept headers (yes, we created a media type for every "object" in the system). The server always natively understood

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

On Mon, Jul 23, 2018 at 7:32 AM, Robert Wilton wrote: > > > On 23/07/2018 15:08, Andy Bierman wrote: > > > > On Mon, Jul 23, 2018 at 6:24 AM, Robert Wilton wrote: > >> >> >> On 23/07/2018 12:54, Andy Bierman wrote: >> >> >> >> On Mon, Jul 23, 2018 at 2:50 AM, Robert Wilton wrote: >> >>> Hi

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

On 23/07/2018 15:08, Andy Bierman wrote: On Mon, Jul 23, 2018 at 6:24 AM, Robert Wilton > wrote: On 23/07/2018 12:54, Andy Bierman wrote: On Mon, Jul 23, 2018 at 2:50 AM, Robert Wilton mailto:rwil...@cisco.com>> wrote: Hi Chris, Andy,

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

On Mon, Jul 23, 2018 at 6:24 AM, Robert Wilton wrote: > > > On 23/07/2018 12:54, Andy Bierman wrote: > > > > On Mon, Jul 23, 2018 at 2:50 AM, Robert Wilton wrote: > >> Hi Chris, Andy, >> >> >> On 21/07/2018 17:00, Christian Hopps wrote: >> >>> As I pointed out at the mic @102 this requirement

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

On 23/07/2018 12:54, Andy Bierman wrote: On Mon, Jul 23, 2018 at 2:50 AM, Robert Wilton > 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

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

On Mon, Jul 23, 2018 at 2:50 AM, Robert Wilton 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

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

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)

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

Perhaps you are mistaking my intention here? I want a simple solution. I advocated for *not* introducing a new major version component. I don't want models changing all the time. I don't believe there is a large need for incompatible changes. There are actual instances where small perhaps

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

On Sat, Jul 21, 2018 at 9:00 AM, 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)

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

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

On Sat, Jul 21, 2018 at 3:12 AM, Juergen Schoenwaelder < j.schoenwael...@jacobs-university.de> wrote: > On Sat, Jul 21, 2018 at 01:48:37AM -0700, Andy Bierman wrote: > > > > But you can tell the 2 subtrees apart this way. > > If I change /foo from a container to a list, then how do you support

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

On Sat, Jul 21, 2018 at 01:48:37AM -0700, Andy Bierman wrote: > > But you can tell the 2 subtrees apart this way. > If I change /foo from a container to a list, then how do you support both > implementations > of container /foo and list /foo at the same time? > Well, all of this is the

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

On Fri, Jul 20, 2018 at 10:49 PM, Juergen Schoenwaelder < j.schoenwael...@jacobs-university.de> wrote: > On Fri, Jul 20, 2018 at 02:41:33PM -0700, Andy Bierman wrote: > > Hi, > > > > I strongly object to requirement 3.1: > > > > > > 3.1 The solution MUST provide a mechanism to allow servers

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

On Fri, Jul 20, 2018 at 02:41:33PM -0700, Andy Bierman wrote: > 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

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

My understanding is that the MUST puts a requirement on the solution and the rest is an "allow servers", i.e., something that servers may want to do. (I was against using RFC 2119 keywords in the first place for this document.) /js On Fri, Jul 20, 2018 at 02:41:33PM -0700, Andy Bierman wrote: >

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

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