Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Robert Wilton]

On 12/11/2018 16:29, Martin Bjorklund wrote:

Robert Wilton  wrote:

Hi Martin,


On 09/11/2018 16:31, Martin Bjorklund wrote:

Juergen Schoenwaelder  wrote:

On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:

I think we need to distinguish between the agreement on the
requirement, namely that a server should be able to provide support
for an old and a new definition, and agreement on the solution.

Do you disagree with the requirement? Or do you disagree with the
consequences of implementing multiple versions of the same module
for some of the proposed new versioning schemes? Or both?

I do not agree with the requirement that a server MUST be able to
support multiple revisions of the same module, which is how I
interpret 3.2.  If this is not the intention of 3.2, maybe it can be
clarified.


Here is what 3.2 says:

 3.2  The solution MUST provide a mechanism to allow servers to
  simultaneously support clients using different revisions of
  modules.  A client's choice of particular revision of one or
  more modules may restrict the particular revision of other
  modules that may be used in the same request or session.

This does _not_ say servers MUST implement this.

Item 3.2 establishes a requirement and for some solutions it may be
easy to satisfy this requirement, for others it may be more costly to
satisfy this requirement.

The whole requirements exercise becomes a rather pointless exercise if
we remove requirements so that certain solutions look more
attractive.

Ok, but that's not what I wrote.  I don't agree with this requirement
which says that it MUST be possible for a server to support
different revisions of a given module (again, if this is not the
intention of the text, please clarify).  I simply don't think that
this is a good requirement.

One way to think of this is as YANG data models defining an API
between client and server.

There seem to be lots of REST APIs that implement versioning of their
API by having a version number in the URL.

Yes, but that doesn't mean that a given server supports more than one
version seamlessly.
I agree.  But if a set of translations are being defined between old and 
new it should be possible to identify those cases where the mapping does 
not work.


At the end of the day, if the schema has been expanded in any way, then 
an old client isn't going to understand new functionality used by a new 
client.



  As you wrote, it works fine for operational
state, but it is less obvious how it should work in the general case
for config data.
Even for operational data (if we are discussing mapping different 
versions of a schema) then it is not guaranteed that it is possible to 
map between different representations.  If they are two far apart then a 
good mapping may not be possible.






In fact, I think that
RESTCONF adopts this approach to allow versioning of the protocol.

One solution is as Andy describes.  The underlying server only
implements one version of the a given YANG module, but they may
provide other views on to this data using different versions of YANG
modules.  E.g. the same as how Vendor YANG models, IETF YANG models,
and OpenConfig YANG models might be treated as their own views, mapped
to the same internal YANG modules.

Yes, but this solution is also problematic; it is not always the case
that clients can pick and choose from these different "views" and get
consistent results, simply b/c the mappings are not 100% one-to-one.
But a device performing that mapping should be able to report the 
paths/values that it has not been able to map.


Thanks,
Rob




/martin


Thanks,
Rob




/martin



I have not seen a proposal that addresses all requirements and hence
at the end the WG needs to decide which tradeoffs make sense.

/js

--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.


.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Martin Bjorklund]

Robert Wilton  wrote:
> Hi Martin,
> 
> 
> On 09/11/2018 16:31, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> >> On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:
>  I think we need to distinguish between the agreement on the
>  requirement, namely that a server should be able to provide support
>  for an old and a new definition, and agreement on the solution.
> 
>  Do you disagree with the requirement? Or do you disagree with the
>  consequences of implementing multiple versions of the same module
>  for some of the proposed new versioning schemes? Or both?
> >>> I do not agree with the requirement that a server MUST be able to
> >>> support multiple revisions of the same module, which is how I
> >>> interpret 3.2.  If this is not the intention of 3.2, maybe it can be
> >>> clarified.
> >>>
> >> Here is what 3.2 says:
> >>
> >> 3.2  The solution MUST provide a mechanism to allow servers to
> >>  simultaneously support clients using different revisions of
> >>  modules.  A client's choice of particular revision of one or
> >>  more modules may restrict the particular revision of other
> >>  modules that may be used in the same request or session.
> >>
> >> This does _not_ say servers MUST implement this.
> >>
> >> Item 3.2 establishes a requirement and for some solutions it may be
> >> easy to satisfy this requirement, for others it may be more costly to
> >> satisfy this requirement.
> >>
> >> The whole requirements exercise becomes a rather pointless exercise if
> >> we remove requirements so that certain solutions look more
> >> attractive.
> > Ok, but that's not what I wrote.  I don't agree with this requirement
> > which says that it MUST be possible for a server to support
> > different revisions of a given module (again, if this is not the
> > intention of the text, please clarify).  I simply don't think that
> > this is a good requirement.
> One way to think of this is as YANG data models defining an API
> between client and server.
> 
> There seem to be lots of REST APIs that implement versioning of their
> API by having a version number in the URL.

Yes, but that doesn't mean that a given server supports more than one
version seamlessly.  As you wrote, it works fine for operational
state, but it is less obvious how it should work in the general case
for config data.

> In fact, I think that
> RESTCONF adopts this approach to allow versioning of the protocol.
> 
> One solution is as Andy describes.  The underlying server only
> implements one version of the a given YANG module, but they may
> provide other views on to this data using different versions of YANG
> modules.  E.g. the same as how Vendor YANG models, IETF YANG models,
> and OpenConfig YANG models might be treated as their own views, mapped
> to the same internal YANG modules.

Yes, but this solution is also problematic; it is not always the case
that clients can pick and choose from these different "views" and get
consistent results, simply b/c the mappings are not 100% one-to-one.


/martin

> 
> Thanks,
> Rob
> 
> 
> >
> >
> > /martin
> >
> >
> >> I have not seen a proposal that addresses all requirements and hence
> >> at the end the WG needs to decide which tradeoffs make sense.
> >>
> >> /js
> >>
> >> -- 
> >> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> >> Fax:   +49 421 200 3103 
> >>
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > .
> >
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Juergen Schoenwaelder]

On Mon, Nov 12, 2018 at 05:21:55PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Fri, Nov 09, 2018 at 05:31:59PM +0100, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder  wrote:
> > > > On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:
> > > > > 
> > > > > > I think we need to distinguish between the agreement on the
> > > > > > requirement, namely that a server should be able to provide support
> > > > > > for an old and a new definition, and agreement on the solution.
> > > > > > 
> > > > > > Do you disagree with the requirement? Or do you disagree with the
> > > > > > consequences of implementing multiple versions of the same module
> > > > > > for some of the proposed new versioning schemes? Or both?
> > > > > 
> > > > > I do not agree with the requirement that a server MUST be able to
> > > > > support multiple revisions of the same module, which is how I
> > > > > interpret 3.2.  If this is not the intention of 3.2, maybe it can be
> > > > > clarified.
> > > > >
> > > > 
> > > > Here is what 3.2 says:
> > > > 
> > > >3.2  The solution MUST provide a mechanism to allow servers to
> > > > simultaneously support clients using different revisions of
> > > > modules.  A client's choice of particular revision of one or
> > > > more modules may restrict the particular revision of other
> > > > modules that may be used in the same request or session.
> > > > 
> > > > This does _not_ say servers MUST implement this.
> > > > 
> > > > Item 3.2 establishes a requirement and for some solutions it may be
> > > > easy to satisfy this requirement, for others it may be more costly to
> > > > satisfy this requirement.
> > > > 
> > > > The whole requirements exercise becomes a rather pointless exercise if
> > > > we remove requirements so that certain solutions look more
> > > > attractive.
> > > 
> > > Ok, but that's not what I wrote.  I don't agree with this requirement
> > > which says that it MUST be possible for a server to support
> > > different revisions of a given module (again, if this is not the
> > > intention of the text, please clarify).  I simply don't think that
> > > this is a good requirement.
> > >
> > 
> > I can't follow you or I do not understand what you are after.
> > 
> >   In some versioning schemes, providing support for different
> >   'versions' is relatively easy. If I have modules foo-1 and foo-2,
> >   then I can implement foo-1 and foo-2 (or proper workable subsets of
> >   them) easily. And older clients expecting foo-1 may continue to work
> >   while newer clients move to foo-2. In other versioning schemes,
> >   providing the same possibility to migrate from foo version 1 to foo
> >   version 2, would lead to the support of foo in two different
> >   versions.
> 
> But module 'foo-2' is not a new revision of module 'foo-1'.  It might
> be that 'foo-2' represents a new version of the underlying "function"
> that 'foo-1' represents; but that is a different issue.

This depends on the versioning solution or what we consider a versioning
solution.

> > The requirement tries to express that it must be possible to have a
> > transition path where old clients can continue to function with the
> > old version while new clients start using the new version. The idea is
> > to state this as a requirement without making any assumptions about
> > the solutions.
> > 
> > Are you saying that a requirement saying that there should be a
> > possibility of a transition path is in general a bad requirement?
> 
> No (but I agree w/ Rob Wilton that it is unclear how this should be
> done in non-trivial examples), but again, that is not what I think 3.2
> says.  IMO 3.2 doesn't allow a solution that requires a new module for
> new NBC stuff, since it says that a client should be able to pick a
> particular revision of a module.
>

We apparently lack words for modules that may be versioned by new
module names.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Fri, Nov 09, 2018 at 05:31:59PM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:
> > > > 
> > > > > I think we need to distinguish between the agreement on the
> > > > > requirement, namely that a server should be able to provide support
> > > > > for an old and a new definition, and agreement on the solution.
> > > > > 
> > > > > Do you disagree with the requirement? Or do you disagree with the
> > > > > consequences of implementing multiple versions of the same module
> > > > > for some of the proposed new versioning schemes? Or both?
> > > > 
> > > > I do not agree with the requirement that a server MUST be able to
> > > > support multiple revisions of the same module, which is how I
> > > > interpret 3.2.  If this is not the intention of 3.2, maybe it can be
> > > > clarified.
> > > >
> > > 
> > > Here is what 3.2 says:
> > > 
> > >3.2  The solution MUST provide a mechanism to allow servers to
> > > simultaneously support clients using different revisions of
> > > modules.  A client's choice of particular revision of one or
> > > more modules may restrict the particular revision of other
> > > modules that may be used in the same request or session.
> > > 
> > > This does _not_ say servers MUST implement this.
> > > 
> > > Item 3.2 establishes a requirement and for some solutions it may be
> > > easy to satisfy this requirement, for others it may be more costly to
> > > satisfy this requirement.
> > > 
> > > The whole requirements exercise becomes a rather pointless exercise if
> > > we remove requirements so that certain solutions look more
> > > attractive.
> > 
> > Ok, but that's not what I wrote.  I don't agree with this requirement
> > which says that it MUST be possible for a server to support
> > different revisions of a given module (again, if this is not the
> > intention of the text, please clarify).  I simply don't think that
> > this is a good requirement.
> >
> 
> I can't follow you or I do not understand what you are after.
> 
>   In some versioning schemes, providing support for different
>   'versions' is relatively easy. If I have modules foo-1 and foo-2,
>   then I can implement foo-1 and foo-2 (or proper workable subsets of
>   them) easily. And older clients expecting foo-1 may continue to work
>   while newer clients move to foo-2. In other versioning schemes,
>   providing the same possibility to migrate from foo version 1 to foo
>   version 2, would lead to the support of foo in two different
>   versions.

But module 'foo-2' is not a new revision of module 'foo-1'.  It might
be that 'foo-2' represents a new version of the underlying "function"
that 'foo-1' represents; but that is a different issue.


> The requirement tries to express that it must be possible to have a
> transition path where old clients can continue to function with the
> old version while new clients start using the new version. The idea is
> to state this as a requirement without making any assumptions about
> the solutions.
> 
> Are you saying that a requirement saying that there should be a
> possibility of a transition path is in general a bad requirement?

No (but I agree w/ Rob Wilton that it is unclear how this should be
done in non-trivial examples), but again, that is not what I think 3.2
says.  IMO 3.2 doesn't allow a solution that requires a new module for
new NBC stuff, since it says that a client should be able to pick a
particular revision of a module.


/martin




> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Robert Wilton]

On 11/11/2018 07:07, Andy Bierman wrote:



On Fri, Nov 9, 2018 at 2:53 PM, Robert Wilton > wrote:


Hi Martin,


On 09/11/2018 16:31, Martin Bjorklund wrote:

Juergen Schoenwaelder mailto:j.schoenwael...@jacobs-university.de>> wrote:

On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund
wrote:

I think we need to distinguish between the
agreement on the
requirement, namely that a server should be able
to provide support
for an old and a new definition, and agreement on
the solution.

Do you disagree with the requirement? Or do you
disagree with the
consequences of implementing multiple versions of
the same module
for some of the proposed new versioning schemes?
Or both?

I do not agree with the requirement that a server MUST
be able to
support multiple revisions of the same module, which
is how I
interpret 3.2.  If this is not the intention of 3.2,
maybe it can be
clarified.

Here is what 3.2 says:

        3.2  The solution MUST provide a mechanism to
allow servers to
             simultaneously support clients using
different revisions of
             modules.  A client's choice of particular
revision of one or
             more modules may restrict the particular
revision of other
             modules that may be used in the same request
or session.

This does _not_ say servers MUST implement this.

Item 3.2 establishes a requirement and for some solutions
it may be
easy to satisfy this requirement, for others it may be
more costly to
satisfy this requirement.

The whole requirements exercise becomes a rather pointless
exercise if
we remove requirements so that certain solutions look more
attractive.

Ok, but that's not what I wrote.  I don't agree with this
requirement
which says that it MUST be possible for a server to support
different revisions of a given module (again, if this is not the
intention of the text, please clarify).  I simply don't think that
this is a good requirement.

One way to think of this is as YANG data models defining an API
between client and server.

There seem to be lots of REST APIs that implement versioning of
their API by having a version number in the URL.  In fact, I think
that RESTCONF adopts this approach to allow versioning of the
protocol.

One solution is as Andy describes.  The underlying server only
implements one version of the a given YANG module, but they may
provide other views on to this data using different versions of
YANG modules.  E.g. the same as how Vendor YANG models, IETF YANG
models, and OpenConfig YANG models might be treated as their own
views, mapped to the same internal YANG modules.



I agree with Martin that this requirement is a bad idea.
It will make YANG too complicated and error-prone.
This is not the same as versioning the entire API (e.g., /restconf2, 
/restconf3).

This is conceptually a version number at every node in the tree.

The "outer" models are ignored by the server in this approach.
Only the "inner" model is actually implemented and validated.
A different set of outer models for each client, based on the set of 
modules
the client wants to see, sounds very complicated to design, implement, 
test, and operate.


That is not what I'm proposing.

The server exposes one or more different schema of it's choosing. When 
the client opens the connection with the server it chooses which schema 
to use.


For example, if the server release history was:

Release 1 , supports schema A
Release 1.1, supports schema B
Release 2, supports schema C

Then in release 2, the server may also support the schema associated 
with release 1 and 1.1 (i.e. it supports schema A, B and C)


If this seems too complex, then the server chooses to just implement  
schema C, associated with release 2, and clients are forced to upgrade 
and use the latest schema.


It is not our intention to force servers to implement this version 
selection, only to specify it for vendors who did wish to implement it.


Thanks,
Rob



Thanks,
Rob


Andy




/martin


I have not seen a proposal that addresses all requirements
and hence
at the end the WG needs to decide which t

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Andy Bierman]

On Fri, Nov 9, 2018 at 2:53 PM, Robert Wilton  wrote:

> Hi Martin,
>
>
> On 09/11/2018 16:31, Martin Bjorklund wrote:
>
>> Juergen Schoenwaelder  wrote:
>>
>>> On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:
>>>
 I think we need to distinguish between the agreement on the
> requirement, namely that a server should be able to provide support
> for an old and a new definition, and agreement on the solution.
>
> Do you disagree with the requirement? Or do you disagree with the
> consequences of implementing multiple versions of the same module
> for some of the proposed new versioning schemes? Or both?
>
 I do not agree with the requirement that a server MUST be able to
 support multiple revisions of the same module, which is how I
 interpret 3.2.  If this is not the intention of 3.2, maybe it can be
 clarified.

 Here is what 3.2 says:
>>>
>>> 3.2  The solution MUST provide a mechanism to allow servers to
>>>  simultaneously support clients using different revisions of
>>>  modules.  A client's choice of particular revision of one or
>>>  more modules may restrict the particular revision of other
>>>  modules that may be used in the same request or session.
>>>
>>> This does _not_ say servers MUST implement this.
>>>
>>> Item 3.2 establishes a requirement and for some solutions it may be
>>> easy to satisfy this requirement, for others it may be more costly to
>>> satisfy this requirement.
>>>
>>> The whole requirements exercise becomes a rather pointless exercise if
>>> we remove requirements so that certain solutions look more
>>> attractive.
>>>
>> Ok, but that's not what I wrote.  I don't agree with this requirement
>> which says that it MUST be possible for a server to support
>> different revisions of a given module (again, if this is not the
>> intention of the text, please clarify).  I simply don't think that
>> this is a good requirement.
>>
> One way to think of this is as YANG data models defining an API between
> client and server.
>
> There seem to be lots of REST APIs that implement versioning of their API
> by having a version number in the URL.  In fact, I think that RESTCONF
> adopts this approach to allow versioning of the protocol.
>
> One solution is as Andy describes.  The underlying server only implements
> one version of the a given YANG module, but they may provide other views on
> to this data using different versions of YANG modules.  E.g. the same as
> how Vendor YANG models, IETF YANG models, and OpenConfig YANG models might
> be treated as their own views, mapped to the same internal YANG modules.
>
>

I agree with Martin that this requirement is a bad idea.
It will make YANG too complicated and error-prone.
This is not the same as versioning the entire API (e.g., /restconf2,
/restconf3).
This is conceptually a version number at every node in the tree.

The "outer" models are ignored by the server in this approach.
Only the "inner" model is actually implemented and validated.
A different set of outer models for each client, based on the set of modules
the client wants to see, sounds very complicated to design, implement,
test, and operate.


Thanks,
> Rob
>
>
Andy


>
>
>>
>> /martin
>>
>>
>> I have not seen a proposal that addresses all requirements and hence
>>> at the end the WG needs to decide which t
>>> radeoffs
>>> make sense.
>>>
>>> /js
>>>
>>> --
>>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   +49 421 200 3103 
>>>
>>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>
>>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Robert Wilton]

Hi Martin,


On 09/11/2018 16:31, Martin Bjorklund wrote:

Juergen Schoenwaelder  wrote:

On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:

I think we need to distinguish between the agreement on the
requirement, namely that a server should be able to provide support
for an old and a new definition, and agreement on the solution.

Do you disagree with the requirement? Or do you disagree with the
consequences of implementing multiple versions of the same module
for some of the proposed new versioning schemes? Or both?

I do not agree with the requirement that a server MUST be able to
support multiple revisions of the same module, which is how I
interpret 3.2.  If this is not the intention of 3.2, maybe it can be
clarified.


Here is what 3.2 says:

3.2  The solution MUST provide a mechanism to allow servers to
 simultaneously support clients using different revisions of
 modules.  A client's choice of particular revision of one or
 more modules may restrict the particular revision of other
 modules that may be used in the same request or session.

This does _not_ say servers MUST implement this.

Item 3.2 establishes a requirement and for some solutions it may be
easy to satisfy this requirement, for others it may be more costly to
satisfy this requirement.

The whole requirements exercise becomes a rather pointless exercise if
we remove requirements so that certain solutions look more
attractive.

Ok, but that's not what I wrote.  I don't agree with this requirement
which says that it MUST be possible for a server to support
different revisions of a given module (again, if this is not the
intention of the text, please clarify).  I simply don't think that
this is a good requirement.
One way to think of this is as YANG data models defining an API between 
client and server.


There seem to be lots of REST APIs that implement versioning of their 
API by having a version number in the URL.  In fact, I think that 
RESTCONF adopts this approach to allow versioning of the protocol.


One solution is as Andy describes.  The underlying server only 
implements one version of the a given YANG module, but they may provide 
other views on to this data using different versions of YANG modules.  
E.g. the same as how Vendor YANG models, IETF YANG models, and 
OpenConfig YANG models might be treated as their own views, mapped to 
the same internal YANG modules.


Thanks,
Rob





/martin



I have not seen a proposal that addresses all requirements and hence
at the end the WG needs to decide which tradeoffs make sense.

/js

--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Robert Wilton]

On 09/11/2018 11:38, Andy Bierman wrote:



On Fri, Nov 9, 2018 at 12:15 AM, Juergen Schoenwaelder 
> wrote:


On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder mailto:j.schoenwael...@jacobs-university.de>> wrote:
> > On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> > >
> > > This is what we have today only if modules are updated in
legal ways.
> > > The 3.1 requirement says this backward compatibility is
maintained even
> > > if the module is updated in violation of the module update
rules.
> > >
> >
> > It is stating a requirement. How solutions meet the
requirement is for
> > the solutions to figure out.
> >
> > > How would 3.1 be met if the WG decided to just add a new
'datastore'
> > > key leaf to the /modules-state/module list?
> >
> > Depends on the solution I guess.
> >
> > > IMO the current "deprecate and start over" is actually the
easiest
> > > and most robust solution path, and it requires no changes to
YANG or
> > > the protocols.
> >
> > Yep. But there are people who think that other solutions can do
> > better. The challenge is to find out whether they actually do
better
> > or for whom they do better (and if someone has to pay a price
for it).
> > For having this discussions, it is good to write down
requirements.
> >
> > > >        3.2  The solution MUST provide a mechanism to allow
servers to
> > > >             simultaneously support clients using different
revisions of
> > > >             modules.  A client's choice of particular
revision of one or
> > > >             more modules may restrict the particular
revision of other
> > > >             modules that may be used in the same request
or session.
> > > >
> > > > Today, the version number is effectively an (implicit)
part of the
> > > > module name (plus the revision date for backwards
compatible changes).
> > > > Hence, my understanding is that today's model does satisfy
3.2 as
> > > > well.
> > >
> > > This is not what we have at all. RFC 7950 says a server can
only implement
> > > one revision of a module.
> > >
> >
> > A new version today essentially means a new module name and I
do not
> > see a conflict with what I wrote.
>
> Then I think this requirement needs clarification. It says
"different
> revision of modules", which can be interpreted as different
revisions
> of *the same* module.
>
> Also the second part of the paragraph seems to indicate multiple
> revisions of the same module in the server.
>
> I do not agree with this requirement.

Today, you need to create a new module if you make NBC changes to
existing changes (e.g., you change Bool to Int {0..1} and you are not
creating a new leaf). Since there are now two modules, you _can_
implement both modules if that makes sense.



This does not make sense because a node in YANG is identified by a QName,
not just a local-name.   The node oldmod:foo is not the same as 
newmod:foo.

It never has been and never will be the same node.


Yes, not the same node, but both representing the same property.

For "config false", or stuff coming out of operational then I have no 
issues with two nodes reporting different representations of the same 
property (unless default values are not being returned).  This is quite 
a common thing to do anyway, and clients can ignore the data that is not 
being returned.


But I struggle to understand how have two nodes in the same schema that 
both directly manipulate the same underlying config property works.  I 
think that various folks have suggesting that this is a viable way of 
fixing bugs in config nodes, but I would be interested to see an 
explanation of exactly how this works, and what limitations are deemed 
to be acceptable.





If we allow to make such changes as part of a module revision, i.e.,
without creating a new module, I think we should not loose the ability
to implement both the old version and the new version.


As Balazs asked, how can the data node be a boolean and an integer at 
the same time?
There seem to be plenty of scenarios that cannot be implemented 
simultaneously by a server.
I think that there are lots of questions if you have two properties 
representing the same underlying configurable node:

 - can they both be configured at the same time with different values?
 - can they both be configured at the same time with the same value?
 - what if the configured value for one data node is not representable 
in the other data node?

 - what if the defaults values differ?



I think we need to distinguish between the agreement on the
requirement, namely that a server should be able to 

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Juergen Schoenwaelder]

On Fri, Nov 09, 2018 at 05:31:59PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:
> > > 
> > > > I think we need to distinguish between the agreement on the
> > > > requirement, namely that a server should be able to provide support
> > > > for an old and a new definition, and agreement on the solution.
> > > > 
> > > > Do you disagree with the requirement? Or do you disagree with the
> > > > consequences of implementing multiple versions of the same module
> > > > for some of the proposed new versioning schemes? Or both?
> > > 
> > > I do not agree with the requirement that a server MUST be able to
> > > support multiple revisions of the same module, which is how I
> > > interpret 3.2.  If this is not the intention of 3.2, maybe it can be
> > > clarified.
> > >
> > 
> > Here is what 3.2 says:
> > 
> >3.2  The solution MUST provide a mechanism to allow servers to
> > simultaneously support clients using different revisions of
> > modules.  A client's choice of particular revision of one or
> > more modules may restrict the particular revision of other
> > modules that may be used in the same request or session.
> > 
> > This does _not_ say servers MUST implement this.
> > 
> > Item 3.2 establishes a requirement and for some solutions it may be
> > easy to satisfy this requirement, for others it may be more costly to
> > satisfy this requirement.
> > 
> > The whole requirements exercise becomes a rather pointless exercise if
> > we remove requirements so that certain solutions look more
> > attractive.
> 
> Ok, but that's not what I wrote.  I don't agree with this requirement
> which says that it MUST be possible for a server to support
> different revisions of a given module (again, if this is not the
> intention of the text, please clarify).  I simply don't think that
> this is a good requirement.
>

I can't follow you or I do not understand what you are after.

  In some versioning schemes, providing support for different
  'versions' is relatively easy. If I have modules foo-1 and foo-2,
  then I can implement foo-1 and foo-2 (or proper workable subsets of
  them) easily. And older clients expecting foo-1 may continue to work
  while newer clients move to foo-2. In other versioning schemes,
  providing the same possibility to migrate from foo version 1 to foo
  version 2, would lead to the support of foo in two different
  versions.

The requirement tries to express that it must be possible to have a
transition path where old clients can continue to function with the
old version while new clients start using the new version. The idea is
to state this as a requirement without making any assumptions about
the solutions.

Are you saying that a requirement saying that there should be a
possibility of a transition path is in general a bad requirement?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:
> > 
> > > I think we need to distinguish between the agreement on the
> > > requirement, namely that a server should be able to provide support
> > > for an old and a new definition, and agreement on the solution.
> > > 
> > > Do you disagree with the requirement? Or do you disagree with the
> > > consequences of implementing multiple versions of the same module
> > > for some of the proposed new versioning schemes? Or both?
> > 
> > I do not agree with the requirement that a server MUST be able to
> > support multiple revisions of the same module, which is how I
> > interpret 3.2.  If this is not the intention of 3.2, maybe it can be
> > clarified.
> >
> 
> Here is what 3.2 says:
> 
>3.2  The solution MUST provide a mechanism to allow servers to
> simultaneously support clients using different revisions of
> modules.  A client's choice of particular revision of one or
> more modules may restrict the particular revision of other
> modules that may be used in the same request or session.
> 
> This does _not_ say servers MUST implement this.
> 
> Item 3.2 establishes a requirement and for some solutions it may be
> easy to satisfy this requirement, for others it may be more costly to
> satisfy this requirement.
> 
> The whole requirements exercise becomes a rather pointless exercise if
> we remove requirements so that certain solutions look more
> attractive.

Ok, but that's not what I wrote.  I don't agree with this requirement
which says that it MUST be possible for a server to support
different revisions of a given module (again, if this is not the
intention of the text, please clarify).  I simply don't think that
this is a good requirement.


/martin


> I have not seen a proposal that addresses all requirements and hence
> at the end the WG needs to decide which tradeoffs make sense.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Juergen Schoenwaelder]

On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:
> 
> > I think we need to distinguish between the agreement on the
> > requirement, namely that a server should be able to provide support
> > for an old and a new definition, and agreement on the solution.
> > 
> > Do you disagree with the requirement? Or do you disagree with the
> > consequences of implementing multiple versions of the same module
> > for some of the proposed new versioning schemes? Or both?
> 
> I do not agree with the requirement that a server MUST be able to
> support multiple revisions of the same module, which is how I
> interpret 3.2.  If this is not the intention of 3.2, maybe it can be
> clarified.
>

Here is what 3.2 says:

   3.2  The solution MUST provide a mechanism to allow servers to
simultaneously support clients using different revisions of
modules.  A client's choice of particular revision of one or
more modules may restrict the particular revision of other
modules that may be used in the same request or session.

This does _not_ say servers MUST implement this.

Item 3.2 establishes a requirement and for some solutions it may be
easy to satisfy this requirement, for others it may be more costly to
satisfy this requirement.

The whole requirements exercise becomes a rather pointless exercise if
we remove requirements so that certain solutions look more attractive.
I have not seen a proposal that addresses all requirements and hence
at the end the WG needs to decide which tradeoffs make sense.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Martin Bjorklund]

"Reshad Rahman (rrahman)"  wrote:
> 
> On 2018-11-09, 8:51 PM, "Martin Bjorklund"  wrote:
> 
> "Reshad Rahman (rrahman)"  wrote:
> > 
> > 
> > On 2018-11-09, 8:37 PM, "netmod on behalf of Martin Bjorklund"
> >  wrote:
> > 
> > Juergen Schoenwaelder  wrote:
> > > On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
> > > > Juergen Schoenwaelder 
> > > > wrote:
> > > > > On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> > > > > > 
> > > > > > This is what we have today only if modules are updated in
> > > > > > legal
> > > > > > ways.
> > > > > > The 3.1 requirement says this backward compatibility is
> > > > > > maintained
> > > > > > even
> > > > > > if the module is updated in violation of the module update
> > > > > > rules.
> > > > > >
> > > > > 
> > > > > It is stating a requirement. How solutions meet the 
> requirement
> > > > > is
> > > > > for
> > > > > the solutions to figure out.
> > > > > 
> > > > > > How would 3.1 be met if the WG decided to just add a new
> > > > > > 'datastore'
> > > > > > key leaf to the /modules-state/module list?
> > > > > 
> > > > > Depends on the solution I guess.
> > > > >  
> > > > > > IMO the current "deprecate and start over" is actually the
> > > > > > easiest
> > > > > > and most robust solution path, and it requires no changes to
> > > > > > YANG
> > > > > > or
> > > > > > the protocols.
> > > > > 
> > > > > Yep. But there are people who think that other solutions can 
> do
> > > > > better. The challenge is to find out whether they actually do
> > > > > better
> > > > > or for whom they do better (and if someone has to pay a price
> > > > > for
> > > > > it).
> > > > > For having this discussions, it is good to write down
> > > > > requirements.
> > > > > 
> > > > > > >3.2 The solution MUST provide a mechanism to allow
> > > > > > >servers
> > > > > > >to
> > > > > > > simultaneously support clients using different
> > > > > > > revisions of
> > > > > > > modules.  A client's choice of particular
> > > > > > > revision of
> > > > > > > one or
> > > > > > > more modules may restrict the particular
> > > > > > > revision of
> > > > > > > other
> > > > > > > modules that may be used in the same request 
> or
> > > > > > > session.
> > > > > > >
> > > > > > > Today, the version number is effectively an (implicit) 
> part
> > > > > > > of
> > > > > > > the
> > > > > > > module name (plus the revision date for backwards
> > > > > > > compatible
> > > > > > > changes).
> > > > > > > Hence, my understanding is that today's model does satisfy
> > > > > > > 3.2 as
> > > > > > > well.
> > > > > > 
> > > > > > This is not what we have at all. RFC 7950 says a server can
> > > > > > only
> > > > > > implement
> > > > > > one revision of a module.
> > > > > >
> > > > > 
> > > > > A new version today essentially means a new module name and I
> > > > > do not
> > > > > see a conflict with what I wrote.
> > > > 
> > > > Then I think this requirement needs clarification.  It says
> > > > "different
> > > > revision of modules", which can be interpreted as different
> > > > revisions
> > > > of *the same* module.
> > > > 
> > > > Also the second part of the paragraph seems to indicate multiple
> > > > revisions of the same module in the server.
> > > > 
> > > > I do not agree with this requirement.
> > > 
> > > Today, you need to create a new module if you make NBC changes to
> > > existing changes (e.g., you change Bool to Int {0..1} and you are
> > > not
> > > creating a new leaf). Since there are now two modules, you _can_
> > > implement both modules if that makes sense.
> > 
> > Yes.
> > 
> > > If we allow to make such changes as part of a module revision,
> > > i.e.,
> > > without creating a new module, I think we should not loose the
> > > ability
> > > to implement both the old version and the new version.
> > 
> > I don't think we should allow such changes, and if we did, I don't
> > think that both revisions should be implemented at the same time.  I
> > 

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Reshad Rahman (rrahman)]

On 2018-11-09, 8:51 PM, "Martin Bjorklund"  wrote:

"Reshad Rahman (rrahman)"  wrote:
> 
> 
> On 2018-11-09, 8:37 PM, "netmod on behalf of Martin Bjorklund"
>  wrote:
> 
> Juergen Schoenwaelder  wrote:
> > On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder  
wrote:
> > > > On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> > > > > 
> > > > > This is what we have today only if modules are updated in 
legal
> > > > > ways.
> > > > > The 3.1 requirement says this backward compatibility is 
maintained
> > > > > even
> > > > > if the module is updated in violation of the module update 
rules.
> > > > >
> > > > 
> > > > It is stating a requirement. How solutions meet the requirement 
is
> > > > for
> > > > the solutions to figure out.
> > > > 
> > > > > How would 3.1 be met if the WG decided to just add a new
> > > > > 'datastore'
> > > > > key leaf to the /modules-state/module list?
> > > > 
> > > > Depends on the solution I guess.
> > > >  
> > > > > IMO the current "deprecate and start over" is actually the 
easiest
> > > > > and most robust solution path, and it requires no changes to 
YANG
> > > > > or
> > > > > the protocols.
> > > > 
> > > > Yep. But there are people who think that other solutions can do
> > > > better. The challenge is to find out whether they actually do 
better
> > > > or for whom they do better (and if someone has to pay a price 
for
> > > > it).
> > > > For having this discussions, it is good to write down 
requirements.
> > > > 
> > > > > >3.2 The solution MUST provide a mechanism to allow 
servers
> > > > > >to
> > > > > > simultaneously support clients using different
> > > > > > revisions of
> > > > > > modules.  A client's choice of particular 
revision of
> > > > > > one or
> > > > > > more modules may restrict the particular 
revision of
> > > > > > other
> > > > > > modules that may be used in the same request or
> > > > > > session.
> > > > > >
> > > > > > Today, the version number is effectively an (implicit) part 
of
> > > > > > the
> > > > > > module name (plus the revision date for backwards compatible
> > > > > > changes).
> > > > > > Hence, my understanding is that today's model does satisfy 
3.2 as
> > > > > > well.
> > > > > 
> > > > > This is not what we have at all. RFC 7950 says a server can 
only
> > > > > implement
> > > > > one revision of a module.
> > > > >
> > > > 
> > > > A new version today essentially means a new module name and I 
do not
> > > > see a conflict with what I wrote.
> > > 
> > > Then I think this requirement needs clarification.  It says 
"different
> > > revision of modules", which can be interpreted as different 
revisions
> > > of *the same* module.
> > > 
> > > Also the second part of the paragraph seems to indicate multiple
> > > revisions of the same module in the server.
> > > 
> > > I do not agree with this requirement.
> > 
> > Today, you need to create a new module if you make NBC changes to
> > existing changes (e.g., you change Bool to Int {0..1} and you are 
not
> > creating a new leaf). Since there are now two modules, you _can_
> > implement both modules if that makes sense.
> 
> Yes.
> 
> > If we allow to make such changes as part of a module revision, i.e.,
> > without creating a new module, I think we should not loose the 
ability
> > to implement both the old version and the new version.
> 
> I don't think we should allow such changes, and if we did, I don't
> think that both revisions should be implemented at the same time.  I
> think the overall solution would just be too complex.
> 
> > I think we need to distinguish between the agreement on the
> > requirement, namely that a server should be able to provide support
> > for an old and a new definition, and agreement on the solution.
> > 
> > Do you disagree with the requirement? Or do you disagree with the
> > consequences of implementing multiple versions of the same module
> > for some of the proposed new versioning schemes? Or both?
> 
> I do not agree with the requirement that a server MUST be able to
> support multiple revisions of the same 

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Reshad Rahman (rrahman)]

From: netmod  on behalf of 'Andy Bierman' 

Date: Friday, November 9, 2018 at 6:38 PM
To: Juergen Schoenwaelder , Martin 
Bjorklund , 'Andy Bierman' , NetMod WG 

Subject: Re: [netmod] New Version Notification for 
draft-verdt-netmod-yang-versioning-reqs-01.txt



On Fri, Nov 9, 2018 at 12:15 AM, Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>
 wrote:
On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder 
> mailto:j.schoenwael...@jacobs-university.de>>
>  wrote:
> > On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> > >
> > > This is what we have today only if modules are updated in legal ways.
> > > The 3.1 requirement says this backward compatibility is maintained even
> > > if the module is updated in violation of the module update rules.
> > >
> >
> > It is stating a requirement. How solutions meet the requirement is for
> > the solutions to figure out.
> >
> > > How would 3.1 be met if the WG decided to just add a new 'datastore'
> > > key leaf to the /modules-state/module list?
> >
> > Depends on the solution I guess.
> >
> > > IMO the current "deprecate and start over" is actually the easiest
> > > and most robust solution path, and it requires no changes to YANG or
> > > the protocols.
> >
> > Yep. But there are people who think that other solutions can do
> > better. The challenge is to find out whether they actually do better
> > or for whom they do better (and if someone has to pay a price for it).
> > For having this discussions, it is good to write down requirements.
> >
> > > >3.2  The solution MUST provide a mechanism to allow servers to
> > > > simultaneously support clients using different revisions of
> > > > modules.  A client's choice of particular revision of one or
> > > > more modules may restrict the particular revision of other
> > > > modules that may be used in the same request or session.
> > > >
> > > > Today, the version number is effectively an (implicit) part of the
> > > > module name (plus the revision date for backwards compatible changes).
> > > > Hence, my understanding is that today's model does satisfy 3.2 as
> > > > well.
> > >
> > > This is not what we have at all. RFC 7950 says a server can only implement
> > > one revision of a module.
> > >
> >
> > A new version today essentially means a new module name and I do not
> > see a conflict with what I wrote.
>
> Then I think this requirement needs clarification.  It says "different
> revision of modules", which can be interpreted as different revisions
> of *the same* module.
>
> Also the second part of the paragraph seems to indicate multiple
> revisions of the same module in the server.
>
> I do not agree with this requirement.

Today, you need to create a new module if you make NBC changes to
existing changes (e.g., you change Bool to Int {0..1} and you are not
creating a new leaf). Since there are now two modules, you _can_
implement both modules if that makes sense.


This does not make sense because a node in YANG is identified by a QName,
not just a local-name.   The node oldmod:foo is not the same as newmod:foo.
It never has been and never will be the same node.
 I disagree, per https://tools.ietf.org/html/rfc7950#section-4.2.1
   A server may implement a number of modules, allowing multiple views
   of the same data or multiple views of disjoint subsections of the
   server's data.  Alternatively, the server may implement only one
   module that defines all available data.


If we allow to make such changes as part of a module revision, i.e.,
without creating a new module, I think we should not loose the ability
to implement both the old version and the new version.

As Balazs asked, how can the data node be a boolean and an integer at the same 
time?
There seem to be plenty of scenarios that cannot be implemented simultaneously 
by a server.
 Correct, but some scenarios can be implemented. IMO we should document the 
type of changes where this would or would not work.

Regards,
Reshad.


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Martin Bjorklund]

"Reshad Rahman (rrahman)"  wrote:
> 
> 
> On 2018-11-09, 8:37 PM, "netmod on behalf of Martin Bjorklund"
>  wrote:
> 
> Juergen Schoenwaelder  wrote:
> > On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder  wrote:
> > > > On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> > > > > 
> > > > > This is what we have today only if modules are updated in legal
> > > > > ways.
> > > > > The 3.1 requirement says this backward compatibility is maintained
> > > > > even
> > > > > if the module is updated in violation of the module update rules.
> > > > >
> > > > 
> > > > It is stating a requirement. How solutions meet the requirement is
> > > > for
> > > > the solutions to figure out.
> > > > 
> > > > > How would 3.1 be met if the WG decided to just add a new
> > > > > 'datastore'
> > > > > key leaf to the /modules-state/module list?
> > > > 
> > > > Depends on the solution I guess.
> > > >  
> > > > > IMO the current "deprecate and start over" is actually the easiest
> > > > > and most robust solution path, and it requires no changes to YANG
> > > > > or
> > > > > the protocols.
> > > > 
> > > > Yep. But there are people who think that other solutions can do
> > > > better. The challenge is to find out whether they actually do better
> > > > or for whom they do better (and if someone has to pay a price for
> > > > it).
> > > > For having this discussions, it is good to write down requirements.
> > > > 
> > > > > >3.2 The solution MUST provide a mechanism to allow 
> servers
> > > > > >to
> > > > > > simultaneously support clients using different
> > > > > > revisions of
> > > > > > modules.  A client's choice of particular revision 
> of
> > > > > > one or
> > > > > > more modules may restrict the particular revision of
> > > > > > other
> > > > > > modules that may be used in the same request or
> > > > > > session.
> > > > > >
> > > > > > Today, the version number is effectively an (implicit) part of
> > > > > > the
> > > > > > module name (plus the revision date for backwards compatible
> > > > > > changes).
> > > > > > Hence, my understanding is that today's model does satisfy 3.2 
> as
> > > > > > well.
> > > > > 
> > > > > This is not what we have at all. RFC 7950 says a server can only
> > > > > implement
> > > > > one revision of a module.
> > > > >
> > > > 
> > > > A new version today essentially means a new module name and I do not
> > > > see a conflict with what I wrote.
> > > 
> > > Then I think this requirement needs clarification.  It says "different
> > > revision of modules", which can be interpreted as different revisions
> > > of *the same* module.
> > > 
> > > Also the second part of the paragraph seems to indicate multiple
> > > revisions of the same module in the server.
> > > 
> > > I do not agree with this requirement.
> > 
> > Today, you need to create a new module if you make NBC changes to
> > existing changes (e.g., you change Bool to Int {0..1} and you are not
> > creating a new leaf). Since there are now two modules, you _can_
> > implement both modules if that makes sense.
> 
> Yes.
> 
> > If we allow to make such changes as part of a module revision, i.e.,
> > without creating a new module, I think we should not loose the ability
> > to implement both the old version and the new version.
> 
> I don't think we should allow such changes, and if we did, I don't
> think that both revisions should be implemented at the same time.  I
> think the overall solution would just be too complex.
> 
> > I think we need to distinguish between the agreement on the
> > requirement, namely that a server should be able to provide support
> > for an old and a new definition, and agreement on the solution.
> > 
> > Do you disagree with the requirement? Or do you disagree with the
> > consequences of implementing multiple versions of the same module
> > for some of the proposed new versioning schemes? Or both?
> 
> I do not agree with the requirement that a server MUST be able to
> support multiple revisions of the same module, which is how I
> interpret 3.2.  If this is not the intention of 3.2, maybe it can be
> clarified.
> 
>  It says "The solution MUST provide...", so the solution draft
> MUST provide a solution on how to do this. Whether a server implements
> the solution or not is a different matter. We realize this is a pain
> for most servers but some servers may be able to do it.

I understand.  But I don't agree with this requirement, even if some

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Reshad Rahman (rrahman)]

On 2018-11-09, 8:37 PM, "netmod on behalf of Martin Bjorklund" 
 wrote:

Juergen Schoenwaelder  wrote:
> On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> > > > 
> > > > This is what we have today only if modules are updated in legal 
ways.
> > > > The 3.1 requirement says this backward compatibility is maintained 
even
> > > > if the module is updated in violation of the module update rules.
> > > >
> > > 
> > > It is stating a requirement. How solutions meet the requirement is for
> > > the solutions to figure out.
> > > 
> > > > How would 3.1 be met if the WG decided to just add a new 'datastore'
> > > > key leaf to the /modules-state/module list?
> > > 
> > > Depends on the solution I guess.
> > >  
> > > > IMO the current "deprecate and start over" is actually the easiest
> > > > and most robust solution path, and it requires no changes to YANG or
> > > > the protocols.
> > > 
> > > Yep. But there are people who think that other solutions can do
> > > better. The challenge is to find out whether they actually do better
> > > or for whom they do better (and if someone has to pay a price for it).
> > > For having this discussions, it is good to write down requirements.
> > > 
> > > > >3.2  The solution MUST provide a mechanism to allow 
servers to
> > > > > simultaneously support clients using different 
revisions of
> > > > > modules.  A client's choice of particular revision of 
one or
> > > > > more modules may restrict the particular revision of 
other
> > > > > modules that may be used in the same request or 
session.
> > > > >
> > > > > Today, the version number is effectively an (implicit) part of the
> > > > > module name (plus the revision date for backwards compatible 
changes).
> > > > > Hence, my understanding is that today's model does satisfy 3.2 as
> > > > > well.
> > > > 
> > > > This is not what we have at all. RFC 7950 says a server can only 
implement
> > > > one revision of a module.
> > > >
> > > 
> > > A new version today essentially means a new module name and I do not
> > > see a conflict with what I wrote.
> > 
> > Then I think this requirement needs clarification.  It says "different
> > revision of modules", which can be interpreted as different revisions
> > of *the same* module.
> > 
> > Also the second part of the paragraph seems to indicate multiple
> > revisions of the same module in the server.
> > 
> > I do not agree with this requirement.
> 
> Today, you need to create a new module if you make NBC changes to
> existing changes (e.g., you change Bool to Int {0..1} and you are not
> creating a new leaf). Since there are now two modules, you _can_
> implement both modules if that makes sense.

Yes.

> If we allow to make such changes as part of a module revision, i.e.,
> without creating a new module, I think we should not loose the ability
> to implement both the old version and the new version.

I don't think we should allow such changes, and if we did, I don't
think that both revisions should be implemented at the same time.  I
think the overall solution would just be too complex.

> I think we need to distinguish between the agreement on the
> requirement, namely that a server should be able to provide support
> for an old and a new definition, and agreement on the solution.
> 
> Do you disagree with the requirement? Or do you disagree with the
> consequences of implementing multiple versions of the same module
> for some of the proposed new versioning schemes? Or both?

I do not agree with the requirement that a server MUST be able to
support multiple revisions of the same module, which is how I
interpret 3.2.  If this is not the intention of 3.2, maybe it can be
clarified.

 It says "The solution MUST provide...", so the solution draft MUST provide 
a solution on how to do this. Whether a server implements the solution or not 
is a different matter. We realize this is a pain for most servers but some 
servers may be able to do it.

Regards,
Reshad.

/martin





> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> > > > 
> > > > This is what we have today only if modules are updated in legal ways.
> > > > The 3.1 requirement says this backward compatibility is maintained even
> > > > if the module is updated in violation of the module update rules.
> > > >
> > > 
> > > It is stating a requirement. How solutions meet the requirement is for
> > > the solutions to figure out.
> > > 
> > > > How would 3.1 be met if the WG decided to just add a new 'datastore'
> > > > key leaf to the /modules-state/module list?
> > > 
> > > Depends on the solution I guess.
> > >  
> > > > IMO the current "deprecate and start over" is actually the easiest
> > > > and most robust solution path, and it requires no changes to YANG or
> > > > the protocols.
> > > 
> > > Yep. But there are people who think that other solutions can do
> > > better. The challenge is to find out whether they actually do better
> > > or for whom they do better (and if someone has to pay a price for it).
> > > For having this discussions, it is good to write down requirements.
> > > 
> > > > >3.2  The solution MUST provide a mechanism to allow servers to
> > > > > simultaneously support clients using different revisions 
> > > > > of
> > > > > modules.  A client's choice of particular revision of one 
> > > > > or
> > > > > more modules may restrict the particular revision of other
> > > > > modules that may be used in the same request or session.
> > > > >
> > > > > Today, the version number is effectively an (implicit) part of the
> > > > > module name (plus the revision date for backwards compatible changes).
> > > > > Hence, my understanding is that today's model does satisfy 3.2 as
> > > > > well.
> > > > 
> > > > This is not what we have at all. RFC 7950 says a server can only 
> > > > implement
> > > > one revision of a module.
> > > >
> > > 
> > > A new version today essentially means a new module name and I do not
> > > see a conflict with what I wrote.
> > 
> > Then I think this requirement needs clarification.  It says "different
> > revision of modules", which can be interpreted as different revisions
> > of *the same* module.
> > 
> > Also the second part of the paragraph seems to indicate multiple
> > revisions of the same module in the server.
> > 
> > I do not agree with this requirement.
> 
> Today, you need to create a new module if you make NBC changes to
> existing changes (e.g., you change Bool to Int {0..1} and you are not
> creating a new leaf). Since there are now two modules, you _can_
> implement both modules if that makes sense.

Yes.

> If we allow to make such changes as part of a module revision, i.e.,
> without creating a new module, I think we should not loose the ability
> to implement both the old version and the new version.

I don't think we should allow such changes, and if we did, I don't
think that both revisions should be implemented at the same time.  I
think the overall solution would just be too complex.

> I think we need to distinguish between the agreement on the
> requirement, namely that a server should be able to provide support
> for an old and a new definition, and agreement on the solution.
> 
> Do you disagree with the requirement? Or do you disagree with the
> consequences of implementing multiple versions of the same module
> for some of the proposed new versioning schemes? Or both?

I do not agree with the requirement that a server MUST be able to
support multiple revisions of the same module, which is how I
interpret 3.2.  If this is not the intention of 3.2, maybe it can be
clarified.


/martin





> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Andy Bierman]

On Fri, Nov 9, 2018 at 12:15 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> > > >
> > > > This is what we have today only if modules are updated in legal ways.
> > > > The 3.1 requirement says this backward compatibility is maintained
> even
> > > > if the module is updated in violation of the module update rules.
> > > >
> > >
> > > It is stating a requirement. How solutions meet the requirement is for
> > > the solutions to figure out.
> > >
> > > > How would 3.1 be met if the WG decided to just add a new 'datastore'
> > > > key leaf to the /modules-state/module list?
> > >
> > > Depends on the solution I guess.
> > >
> > > > IMO the current "deprecate and start over" is actually the easiest
> > > > and most robust solution path, and it requires no changes to YANG or
> > > > the protocols.
> > >
> > > Yep. But there are people who think that other solutions can do
> > > better. The challenge is to find out whether they actually do better
> > > or for whom they do better (and if someone has to pay a price for it).
> > > For having this discussions, it is good to write down requirements.
> > >
> > > > >3.2  The solution MUST provide a mechanism to allow servers
> to
> > > > > simultaneously support clients using different
> revisions of
> > > > > modules.  A client's choice of particular revision of
> one or
> > > > > more modules may restrict the particular revision of
> other
> > > > > modules that may be used in the same request or
> session.
> > > > >
> > > > > Today, the version number is effectively an (implicit) part of the
> > > > > module name (plus the revision date for backwards compatible
> changes).
> > > > > Hence, my understanding is that today's model does satisfy 3.2 as
> > > > > well.
> > > >
> > > > This is not what we have at all. RFC 7950 says a server can only
> implement
> > > > one revision of a module.
> > > >
> > >
> > > A new version today essentially means a new module name and I do not
> > > see a conflict with what I wrote.
> >
> > Then I think this requirement needs clarification.  It says "different
> > revision of modules", which can be interpreted as different revisions
> > of *the same* module.
> >
> > Also the second part of the paragraph seems to indicate multiple
> > revisions of the same module in the server.
> >
> > I do not agree with this requirement.
>
> Today, you need to create a new module if you make NBC changes to
> existing changes (e.g., you change Bool to Int {0..1} and you are not
> creating a new leaf). Since there are now two modules, you _can_
> implement both modules if that makes sense.
>
>

This does not make sense because a node in YANG is identified by a QName,
not just a local-name.   The node oldmod:foo is not the same as newmod:foo.
It never has been and never will be the same node.



> If we allow to make such changes as part of a module revision, i.e.,
> without creating a new module, I think we should not loose the ability
> to implement both the old version and the new version.
>
>
As Balazs asked, how can the data node be a boolean and an integer at the
same time?
There seem to be plenty of scenarios that cannot be implemented
simultaneously by a server.



> I think we need to distinguish between the agreement on the
> requirement, namely that a server should be able to provide support
> for an old and a new definition, and agreement on the solution.
>
> Do you disagree with the requirement? Or do you disagree with the
> consequences of implementing multiple versions of the same module
> for some of the proposed new versioning schemes? Or both?
>


I understand the transformation approach (am have implemented something
like it).
This only works if the mapping is complete.  If there are any holes in the
mapping
then the affected nodes are lost.  Vendors have already proven they
can implement this approach without any new standards.

Vendors are already releasing updates to old module revisions by managing
the revision date.
I agree SEMVER is incrementally better than that.

I do not agree that more than 1 revision of a module can be implemented.
A server can have multiple "outside" schema that gets transformed to the
real "inside" schema.
This is fine and breaks no YANG rules.  It also requires no additional
standards unless the
transformation mechanism is going to be standardized.



> /js
>


Andy


>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Juergen Schoenwaelder]

On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> > > 
> > > This is what we have today only if modules are updated in legal ways.
> > > The 3.1 requirement says this backward compatibility is maintained even
> > > if the module is updated in violation of the module update rules.
> > >
> > 
> > It is stating a requirement. How solutions meet the requirement is for
> > the solutions to figure out.
> > 
> > > How would 3.1 be met if the WG decided to just add a new 'datastore'
> > > key leaf to the /modules-state/module list?
> > 
> > Depends on the solution I guess.
> >  
> > > IMO the current "deprecate and start over" is actually the easiest
> > > and most robust solution path, and it requires no changes to YANG or
> > > the protocols.
> > 
> > Yep. But there are people who think that other solutions can do
> > better. The challenge is to find out whether they actually do better
> > or for whom they do better (and if someone has to pay a price for it).
> > For having this discussions, it is good to write down requirements.
> > 
> > > >3.2  The solution MUST provide a mechanism to allow servers to
> > > > simultaneously support clients using different revisions of
> > > > modules.  A client's choice of particular revision of one or
> > > > more modules may restrict the particular revision of other
> > > > modules that may be used in the same request or session.
> > > >
> > > > Today, the version number is effectively an (implicit) part of the
> > > > module name (plus the revision date for backwards compatible changes).
> > > > Hence, my understanding is that today's model does satisfy 3.2 as
> > > > well.
> > > 
> > > This is not what we have at all. RFC 7950 says a server can only implement
> > > one revision of a module.
> > >
> > 
> > A new version today essentially means a new module name and I do not
> > see a conflict with what I wrote.
> 
> Then I think this requirement needs clarification.  It says "different
> revision of modules", which can be interpreted as different revisions
> of *the same* module.
> 
> Also the second part of the paragraph seems to indicate multiple
> revisions of the same module in the server.
> 
> I do not agree with this requirement.

Today, you need to create a new module if you make NBC changes to
existing changes (e.g., you change Bool to Int {0..1} and you are not
creating a new leaf). Since there are now two modules, you _can_
implement both modules if that makes sense.

If we allow to make such changes as part of a module revision, i.e.,
without creating a new module, I think we should not loose the ability
to implement both the old version and the new version.

I think we need to distinguish between the agreement on the
requirement, namely that a server should be able to provide support
for an old and a new definition, and agreement on the solution.

Do you disagree with the requirement? Or do you disagree with the
consequences of implementing multiple versions of the same module
for some of the proposed new versioning schemes? Or both?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> > 
> > This is what we have today only if modules are updated in legal ways.
> > The 3.1 requirement says this backward compatibility is maintained even
> > if the module is updated in violation of the module update rules.
> >
> 
> It is stating a requirement. How solutions meet the requirement is for
> the solutions to figure out.
> 
> > How would 3.1 be met if the WG decided to just add a new 'datastore'
> > key leaf to the /modules-state/module list?
> 
> Depends on the solution I guess.
>  
> > IMO the current "deprecate and start over" is actually the easiest
> > and most robust solution path, and it requires no changes to YANG or
> > the protocols.
> 
> Yep. But there are people who think that other solutions can do
> better. The challenge is to find out whether they actually do better
> or for whom they do better (and if someone has to pay a price for it).
> For having this discussions, it is good to write down requirements.
> 
> > >3.2  The solution MUST provide a mechanism to allow servers to
> > > simultaneously support clients using different revisions of
> > > modules.  A client's choice of particular revision of one or
> > > more modules may restrict the particular revision of other
> > > modules that may be used in the same request or session.
> > >
> > > Today, the version number is effectively an (implicit) part of the
> > > module name (plus the revision date for backwards compatible changes).
> > > Hence, my understanding is that today's model does satisfy 3.2 as
> > > well.
> > 
> > This is not what we have at all. RFC 7950 says a server can only implement
> > one revision of a module.
> >
> 
> A new version today essentially means a new module name and I do not
> see a conflict with what I wrote.

Then I think this requirement needs clarification.  It says "different
revision of modules", which can be interpreted as different revisions
of *the same* module.

Also the second part of the paragraph seems to indicate multiple
revisions of the same module in the server.

I do not agree with this requirement.



/martin


> 
> > > If we want to increase 'agility' in an attempt to make it easier to
> > > deliver early designs and to fix them on the go, the costs will go up
> > > somewhere. The extreme cases are:
> > >
> > > 1) The server can make changes to YANG modules in arbitrary ways and
> > >the clients have to adapt, i.e., clients have to pay the bill.
> > >
> > > 2) The server has to provide strict backwards compatibility in order
> > >to not break clients, i.e., servers have to pay the bill.
> > >
> > >
> > This is not correct. Implementing multiple incompatible revisions of a
> > module
> > (e.g, "module" list keyed 2 different ways) is a huge bill to pay for the
> > server developer.
> 
> Depends on the details and the developer will decide based on the
> impact on the clients and whether a transition period is possible. You
> seem to read that the requirement says one has to implement backwards
> compatibility. This is not what the text says. The text says it must
> be possible.
> 
> > > Unless we go for option 1) above, I believe 3.1 and 3.2 are valid and
> > > important requirements.
> > 
> > I do not agree with the premise that non-compatible data model updates are
> > required.
> > 3.1 can be achieved without such changes. 3.2 violates RFC 7950, requiring
> > a new(much more complicated) version of YANG
> 
> I think you misread the requirements text.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Martin Bjorklund]

Hi,

Juergen Schoenwaelder  wrote:
> Let me add that there was large disagreement what a bug fix is in the
> design team. Hence, any text that talks about 'bug fixes' is ambiguous
> and of limited value to achieve consensus. (Or we may find consensus
> but then not agree on what we have found consensus on.)
> 
> To be more concrete, I learned that Rob's notion of a bug fix is very
> different from my notion of a bug fix. I think it is important for
> having a productive discussion to be aware of this.
> 
> For me, a bug fix is rather limited, i.e., fixing something where the
> correct intention was clear but the model did not properly capture the
> intention correctly, i.e., roughly what we can do with errata in the
> IETF. I think Rob understands bug fixes in a much broader sense,
> including fixes to what essentially are in my view module design
> errors.
> 
> With my narrow definition of bug fixes, bug fixes are essentially
> backwards compatible (even if they may violate RFC 7950 rules - but as
> long as the original intention was clear, we can be flexible).

I agree with this interpretation of a bug fix.  For example
fixing incorrect patterns (e.g. errata 3957 that Andy mentioned).



/martin



> With Rob's notion of bug fixes, we have to handle them as part of the
> versioning system since they may be non-backwards compatible.
> 
> /js
> 
> On Fri, Oct 26, 2018 at 10:17:48AM +0100, Robert Wilton wrote:
> > Hi Chris,
> > 
> > 
> > On 25/10/2018 18:42, Christian Hopps wrote:
> > > 
> > > Hi Rob,
> > > 
> > > We've more privately discussed the bug-fix scenario and I'm sympathetic
> > > to it; however, the requirement as written does not restrict itself to
> > > fixing module definition bugs (e.g., a pattern or other value
> > > constraint) in some small but incompatible way -- instead it's wide open
> > > and it will be [ab]used that way.
> > I think that everyone on design team agrees that non-backwards-compatible
> > changes should be minimized and should really only to used for bug fixes
> > where it is anticipated that clients should not be affected.
> > 
> > We want to allow non-backwards-compatible changes at the head of the
> > development tree, but again, I think that everyone agrees that keeping it
> > backwards compatible where possible is a good goal.
> > 
> > However, I think that there will be cases where a vendor decides that it is
> > right for an enhancement or non backwards compatible change to be made to an
> > already released module.  I agree that this is highly undesirable and an
> > abuse of the rules, but I don't believe that whatever versioning scheme we
> > come up with will prevent vendors from doing this.  So then the question
> > becomes: Is it better to pretend that this scenario will never happen,
> > design the versioning scheme so that it cannot be expressed, which probably
> > just means that clients will not be able to detect when vendors do this by
> > cheating the rules!  Or is it better to accept that this will sometimes
> > occur, provide strong guidance as to why this is bad practice and should be
> > avoided, but have a versioning scheme that still allows this to be expressed
> > (in a bounded way)?  I.e. even if the vendors are doing something that is
> > less than ideal, at least the clients can spot where they have done this.
> > 
> > ---
> > 
> > A separate concern that we had about ties this strictly to bug fixes is that
> > some one will ask for a definition of a bug fix.  The design team tried this
> > but we couldn't even agree what a bug fix is, let alone agree with a single
> > definition of a bug fix as it related to a YANG module.  So our conclusion
> > was that perhaps it is better not to tie the requirements themselves to bug
> > fix vs enhancement, because the boundary between the two is too vague, and
> > module writers will bend the rules.
> > 
> > So I see that the rules should be:
> >  - backwards compatible bug fix  - this is fine.
> >  - non backwards compatible bug fix - this is fine if it is pragmatically
> > expected to not impact any clients, but careful consideration is required if
> > it might break clients.
> >  - backwards compatible enhancement - not ideal, but pragmatically OK.
> >  - non backwards compatible enhancement - this is bad and should be avoided.
> > 
> > But if we don't want to define the difference between a bug fix vs
> > enhancement then I think that you end up with the most general requirement
> > being that we do want to allow for non-backwards-compatible changes in
> > released modules to accommodate the bug fix scenario, but the expectation
> > (and guidance) will be that they should only be used for bug fixes.
> > 
> > 
> > > 
> > > For example:
> > > 
> > > > Here is what I am afraid the vendors want here: A developer on
> > > > release train X can easily change some data structure and then push
> > > > the change into an automated system which generates a new YANG
> > > > module definition and revs a version 

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Andy Bierman]

On Sun, Nov 4, 2018 at 4:39 AM, Balázs Lengyel 
wrote:

> Implementing 3.2 will be very costly. IMHO Ericsson will not implement it..
> We will do our utmost to avoid NBC changes, but if they do happen, I don't
> believe we would support multiple versions.
>
> If the data models are sufficiently NBC e.g. changing a boolean to an
> integer 3.2 may not even be possible. The underlying data that drives the
> device may be an integer or a boolean, but not both. (Strange mapping may
> be possible to imagine, but they will not always work.)
>


IMO the requirements and solutions drafts are both too abstract.
It would help if the authors could point to existing RFCs or I-Ds where a
published module needs specific NBC changes.

The intended usage of the status-stmt in YANG 1.1 seems to be for NBC
changes
to be made by introducing a replacement (maybe sibling) node and changing
the replaced
node status to deprecated.

The requirements draft is not clear at all when this practice should be
followed
and when it is OK to simply change the data node and not deprecate it at
all.
IMO the latter is only OK if the change is truly a bugfix and implementation
of the previous version SHOULD NOT be done.

Even though this means a server MAY implement the old bugfixed version,
that does not
mean an operator gets to choose both versions active at once in a given
server.
It is reasonable to let the operator configure which version to use.

The solution proposal does not indicate how a protocol would support REQ.
3.2.
E.g., how to say "I mean foo the integer not foo the boolean"

regards Balazs
>
>
>
Andy


> On 2018. 10. 27. 1:15, Robert Wilton wrote:
>
>
>
> On 26/10/2018 17:35, Andy Bierman wrote:
>
>
>
> On Fri, Oct 26, 2018 at 2:33 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
>> Let me add that there was large disagreement what a bug fix is in the
>> design team. Hence, any text that talks about 'bug fixes' is ambiguous
>> and of limited value to achieve consensus. (Or we may find consensus
>> but then not agree on what we have found consensus on.)
>>
>> To be more concrete, I learned that Rob's notion of a bug fix is very
>> different from my notion of a bug fix. I think it is important for
>> having a productive discussion to be aware of this.
>>
>> For me, a bug fix is rather limited, i.e., fixing something where the
>> correct intention was clear but the model did not properly capture the
>> intention correctly, i.e., roughly what we can do with errata in the
>> IETF. I think Rob understands bug fixes in a much broader sense,
>> including fixes to what essentially are in my view module design
>> errors.
>>
>> With my narrow definition of bug fixes, bug fixes are essentially
>> backwards compatible (even if they may violate RFC 7950 rules - but as
>> long as the original intention was clear, we can be flexible).
>>
>> With Rob's notion of bug fixes, we have to handle them as part of the
>> versioning system since they may be non-backwards compatible.
>>
>>
>
> IMO requirements 3.1 and 3.2 are the most  important and have the most
> impact
> on the solution space. I do not agree with either of these requirements.
>
> OK.
>
> For 3.1, I think that just means that the solution has to be backwards
> compatible with existing clients (e.g. don't change the protocols in a non
> backwards compatible way).
>
>
> Implementing multiple non-compatible revisions of a module on a server
> sounds hard,
> not to mention that it breaks RFC 7950 rules.
>
> Completely agree that it will be hard.  I envisage that it will optional
> for servers to implement this.
>
> The current protocols do not support the
> ability to specify different versions of the same QName. This change makes
> YANG validation
> much to difficult to specify and implement (as that has to be rewritten as
> well).
>
> The way that I think of one solution for this problem is using datastore
> schema (as per the NMDA definition):
>
> Say for release X, the server natively supports Module A@ver1.0.0 and
> ModuleB@ver1.0.0, call this schema X.
> For release Y, the server natively supports Module A@ver1.1.0 and
> ModuleB@ver2.0.0, call this schema Y.
>
> When a client connects it chooses which schema it wants to use, X, Y, or
> latest.  If it doesn't specify then perhaps it uses the earliest schema (to
> handle requirement 3.1).
>
> If the client wants to use X, then the server has to translate the request
> into the equivalent request using schema Y instead.  Perhaps the server has
> to validate the config both in the context of X and Y.
>
> If the clients wants to use Y then it just talks to the server normally,
> i.e. as it does today.
>
> I think that this is logically the equivalent model mapping that clients
> would have to do to support multiple server revisions.  Yes, I think that
> it is complex.  No, I'm not sure how many vendors will decide to implement
> this, but I think that it is OK to require the solution to specify how this
> is 

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Balázs Lengyel]

  
  
Implementing 3.2 will be very costly. IMHO Ericsson will not
  implement it. We will do our utmost to avoid NBC changes, but if
  they do happen, I don't believe we would support multiple
  versions.

If the data models are sufficiently NBC e.g. changing a boolean
  to an integer 3.2 may not even be possible. The underlying data
  that drives the device may be an integer or a boolean, but not
  both. (Strange mapping may be possible to imagine, but they will
  not always work.)
regards Balazs


On 2018. 10. 27. 1:15, Robert Wilton
  wrote:


  
  
  
  
  On 26/10/2018 17:35, Andy Bierman
wrote:
  
  

  

  On Fri, Oct 26, 2018 at 2:33 AM,
Juergen Schoenwaelder 
wrote:
Let me add that
  there was large disagreement what a bug fix is in the
  design team. Hence, any text that talks about 'bug
  fixes' is ambiguous
  and of limited value to achieve consensus. (Or we may
  find consensus
  but then not agree on what we have found consensus
  on.)
  
  To be more concrete, I learned that Rob's notion of a
  bug fix is very
  different from my notion of a bug fix. I think it is
  important for
  having a productive discussion to be aware of this.
  
  For me, a bug fix is rather limited, i.e., fixing
  something where the
  correct intention was clear but the model did not
  properly capture the
  intention correctly, i.e., roughly what we can do with
  errata in the
  IETF. I think Rob understands bug fixes in a much
  broader sense,
  including fixes to what essentially are in my view
  module design
  errors.
  
  With my narrow definition of bug fixes, bug fixes are
  essentially
  backwards compatible (even if they may violate RFC
  7950 rules - but as
  long as the original intention was clear, we can be
  flexible).
  
  With Rob's notion of bug fixes, we have to handle them
  as part of the
  versioning system since they may be non-backwards
  compatible.
  





IMO requirements 3.1 and 3.2 are the most
   important and have the most impact
on the solution space. I do not agree with either
  of these requirements.
  

  

  
  OK.
  
  For 3.1, I think that just means that the solution has to be
  backwards compatible with existing clients (e.g. don't change the
  protocols in a non backwards compatible way).
  
  

  

  


Implementing multiple non-compatible revisions of a
  module on a server sounds hard,
not to mention that it breaks RFC 7950 rules. 
  

  

  
  Completely agree that it will be hard.  I envisage that it will
  optional for servers to implement this.
  
  

  

  
The current protocols do not support the
ability to specify different versions of the same
  QName. This change makes YANG validation
much to difficult to specify and implement (as that
  has to be rewritten as well).
  

  

  
  The way that I think of one solution for this problem is using
  datastore schema (as per the NMDA definition):
  
  Say for release X, the server natively supports Module A@ver1.0.0 and ModuleB@ver1.0.0, call this schema X.
  For release Y, the server natively supports Module A@ver1.1.0 and ModuleB@ver2.0.0, call this schema Y.
  
  When a client connects it chooses which schema it wants to use, X,
  Y, or latest.  If it doesn't specify then perhaps it uses the
  earliest schema (to handle requirement 3.1).
  
  If the client wants to use X, then the server has to translate the
  request into the equivalent request using schema Y instead. 
  Perhaps the server has to validate the config both in the context
  of X and Y.
  
  If the clients wants to 

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Balázs Lengyel]

Hello,

Deprecate and startover today, with the current definition of 
deprecated, allows: remove and startover. The server is not mandated to 
support deprecated nodes.


Deprecating/Removing stuff is not just backwards incompatible, it also 
leads to the client not knowing whether deprecated stuff is supported or 
not. So IMHO anything is better then the current deprecated.


regards Balazs

On 2018. 10. 27. 20:50, Andy Bierman wrote:
IMO the current "deprecate and start over" is actually the easiest and 
most robust

solution path, and it requires no changes to YANG or the protocols.


--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Andy Bierman]

On Sat, Oct 27, 2018 at 1:36 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Fri, Oct 26, 2018 at 04:36:26PM -0700, Andy Bierman wrote:
> > On Fri, Oct 26, 2018 at 4:01 PM, Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> > > On Fri, Oct 26, 2018 at 09:35:39AM -0700, Andy Bierman wrote:
> > > >
> > > > IMO requirements 3.1 and 3.2 are the most  important and have the
> most
> > > > impact
> > > > on the solution space. I do not agree with either of these
> requirements.
> > > >
> > > > Implementing multiple non-compatible revisions of a module on a
> server
> > > > sounds hard,
> > > > not to mention that it breaks RFC 7950 rules. The current protocols
> do
> > > not
> > > > support the
> > > > ability to specify different versions of the same QName. This change
> > > makes
> > > > YANG validation
> > > > much to difficult to specify and implement (as that has to be
> rewritten
> > > as
> > > > well).
> > > >
> > > > It is one thing to deploy rapidly changing, buggy YANG modules in
> order
> > > to
> > > > gain experience quickly.  It is quite another to complicate YANG and
> the
> > > > protocols
> > > > to preserve these interim mistakes, and bake into the standards the
> > > notion
> > > > that this
> > > > is good engineering.
> > > >
> > >
> > > So how do you think this conflict between more agility and client
> > > stability should be handled? It seems you can't easily have both at
> > > the same time. Are you saying that backwards compatibility to support
> > > existing clients is not important?
> > >
> > >
> > It depends on the data model and how broken it is in the replaced
> version.
> > YANG validation is slow and complicated enough without pretending there
> > are 8 or 10 separate schema trees within a datastore. It might be
> impossible
> > for all constraints to be true in all schema trees at once.  It is a
> burden
> > on operators
> > and client developers to understand and properly manage multiple
> > incompatible revisions
> > of the same module
> >
> > yang-library is a good example of a clean break.
> > The /yang-library tree completely replaces the /modules-state tree.
> > A server can easily support both subtrees.
> > No new YANG or protocol features are needed at all.
> > This was not a bugfix, just the normal instability in the IETF.
> >
> > Even with this clean break, there could be external modules that have
> > leafref
> > or must/when that point at the /modules-state subtree.  They have to be
> > rewritten
> > to use /yang-library instead. But this can happen as needed since the old
> > tree is unchanged.
> >
> > For truly broken changes (e.g. change a node from a container to a list;
> > change a leaf from type boolean to an enumerated type w/ 6 enums;
> > remove or rename lots of existing nodes) the cross-references from
> external
> > modules can easily be incorrect if used with the new version.
> >
> > The NETMOD WG chose to add a new /yang-library tree instead of
> > mangling the existing nodes. One design choice makes req. 3.1 easy and
> 3.2
> > not needed.
> >
>
>3.1  The solution MUST provide a mechanism to allow servers to
> support existing clients in a backwards-compatible way.
>
> I believe 3.1 is exactly what we have today. If it is necessary to
> make incompatible changes, you create new definitions. This allows
> servers to support existing clients in a backwards-compatible way (as
> long as the old and new definitions are not conflicting.)
>


This is what we have today only if modules are updated in legal ways.
The 3.1 requirement says this backward compatibility is maintained even
if the module is updated in violation of the module update rules.

How would 3.1 be met if the WG decided to just add a new 'datastore' key
leaf
to the /modules-state/module list?

IMO the current "deprecate and start over" is actually the easiest and most
robust
solution path, and it requires no changes to YANG or the protocols.




>3.2  The solution MUST provide a mechanism to allow servers to
> simultaneously support clients using different revisions of
> modules.  A client's choice of particular revision of one or
> more modules may restrict the particular revision of other
> modules that may be used in the same request or session.
>
> Today, the version number is effectively an (implicit) part of the
> module name (plus the revision date for backwards compatible changes).
> Hence, my understanding is that today's model does satisfy 3.2 as
> well.
>
>

This is not what we have at all. RFC 7950 says a server can only implement
one revision of a module.



> If we want to increase 'agility' in an attempt to make it easier to
> deliver early designs and to fix them on the go, the costs will go up
> somewhere. The extreme cases are:
>
> 1) The server can make changes to YANG modules in arbitrary ways and
>the clients have to adapt, i.e., 

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Juergen Schoenwaelder]

On Fri, Oct 26, 2018 at 04:36:26PM -0700, Andy Bierman wrote:
> On Fri, Oct 26, 2018 at 4:01 PM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > On Fri, Oct 26, 2018 at 09:35:39AM -0700, Andy Bierman wrote:
> > >
> > > IMO requirements 3.1 and 3.2 are the most  important and have the most
> > > impact
> > > on the solution space. I do not agree with either of these requirements.
> > >
> > > Implementing multiple non-compatible revisions of a module on a server
> > > sounds hard,
> > > not to mention that it breaks RFC 7950 rules. The current protocols do
> > not
> > > support the
> > > ability to specify different versions of the same QName. This change
> > makes
> > > YANG validation
> > > much to difficult to specify and implement (as that has to be rewritten
> > as
> > > well).
> > >
> > > It is one thing to deploy rapidly changing, buggy YANG modules in order
> > to
> > > gain experience quickly.  It is quite another to complicate YANG and the
> > > protocols
> > > to preserve these interim mistakes, and bake into the standards the
> > notion
> > > that this
> > > is good engineering.
> > >
> >
> > So how do you think this conflict between more agility and client
> > stability should be handled? It seems you can't easily have both at
> > the same time. Are you saying that backwards compatibility to support
> > existing clients is not important?
> >
> >
> It depends on the data model and how broken it is in the replaced version.
> YANG validation is slow and complicated enough without pretending there
> are 8 or 10 separate schema trees within a datastore. It might be impossible
> for all constraints to be true in all schema trees at once.  It is a burden
> on operators
> and client developers to understand and properly manage multiple
> incompatible revisions
> of the same module
> 
> yang-library is a good example of a clean break.
> The /yang-library tree completely replaces the /modules-state tree.
> A server can easily support both subtrees.
> No new YANG or protocol features are needed at all.
> This was not a bugfix, just the normal instability in the IETF.
> 
> Even with this clean break, there could be external modules that have
> leafref
> or must/when that point at the /modules-state subtree.  They have to be
> rewritten
> to use /yang-library instead. But this can happen as needed since the old
> tree is unchanged.
> 
> For truly broken changes (e.g. change a node from a container to a list;
> change a leaf from type boolean to an enumerated type w/ 6 enums;
> remove or rename lots of existing nodes) the cross-references from external
> modules can easily be incorrect if used with the new version.
> 
> The NETMOD WG chose to add a new /yang-library tree instead of
> mangling the existing nodes. One design choice makes req. 3.1 easy and 3.2
> not needed.
>

   3.1  The solution MUST provide a mechanism to allow servers to
support existing clients in a backwards-compatible way.

I believe 3.1 is exactly what we have today. If it is necessary to
make incompatible changes, you create new definitions. This allows
servers to support existing clients in a backwards-compatible way (as
long as the old and new definitions are not conflicting.)

   3.2  The solution MUST provide a mechanism to allow servers to
simultaneously support clients using different revisions of
modules.  A client's choice of particular revision of one or
more modules may restrict the particular revision of other
modules that may be used in the same request or session.

Today, the version number is effectively an (implicit) part of the
module name (plus the revision date for backwards compatible changes).
Hence, my understanding is that today's model does satisfy 3.2 as
well.

If we want to increase 'agility' in an attempt to make it easier to
deliver early designs and to fix them on the go, the costs will go up
somewhere. The extreme cases are:

1) The server can make changes to YANG modules in arbitrary ways and
   the clients have to adapt, i.e., clients have to pay the bill.

2) The server has to provide strict backwards compatibility in order
   to not break clients, i.e., servers have to pay the bill.

The question is whether there is a solution somewhere in the middle
that balances the costs and eases the process of adapting clients to
servers and vice versa. It might very well be that there is no sweet
point.

Unless we go for option 1) above, I believe 3.1 and 3.2 are valid and
important requirements.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Andy Bierman]

On Fri, Oct 26, 2018 at 4:01 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Fri, Oct 26, 2018 at 09:35:39AM -0700, Andy Bierman wrote:
> >
> > IMO requirements 3.1 and 3.2 are the most  important and have the most
> > impact
> > on the solution space. I do not agree with either of these requirements.
> >
> > Implementing multiple non-compatible revisions of a module on a server
> > sounds hard,
> > not to mention that it breaks RFC 7950 rules. The current protocols do
> not
> > support the
> > ability to specify different versions of the same QName. This change
> makes
> > YANG validation
> > much to difficult to specify and implement (as that has to be rewritten
> as
> > well).
> >
> > It is one thing to deploy rapidly changing, buggy YANG modules in order
> to
> > gain experience quickly.  It is quite another to complicate YANG and the
> > protocols
> > to preserve these interim mistakes, and bake into the standards the
> notion
> > that this
> > is good engineering.
> >
>
> So how do you think this conflict between more agility and client
> stability should be handled? It seems you can't easily have both at
> the same time. Are you saying that backwards compatibility to support
> existing clients is not important?
>
>
It depends on the data model and how broken it is in the replaced version.
YANG validation is slow and complicated enough without pretending there
are 8 or 10 separate schema trees within a datastore. It might be impossible
for all constraints to be true in all schema trees at once.  It is a burden
on operators
and client developers to understand and properly manage multiple
incompatible revisions
of the same module

yang-library is a good example of a clean break.
The /yang-library tree completely replaces the /modules-state tree.
A server can easily support both subtrees.
No new YANG or protocol features are needed at all.
This was not a bugfix, just the normal instability in the IETF.

Even with this clean break, there could be external modules that have
leafref
or must/when that point at the /modules-state subtree.  They have to be
rewritten
to use /yang-library instead. But this can happen as needed since the old
tree is unchanged.

For truly broken changes (e.g. change a node from a container to a list;
change a leaf from type boolean to an enumerated type w/ 6 enums;
remove or rename lots of existing nodes) the cross-references from external
modules can easily be incorrect if used with the new version.

The NETMOD WG chose to add a new /yang-library tree instead of
mangling the existing nodes. One design choice makes req. 3.1 easy and 3.2
not needed.
Another - just the opposite.


Andy



/js
>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Juergen Schoenwaelder]

On Fri, Oct 26, 2018 at 09:35:39AM -0700, Andy Bierman wrote:
> 
> IMO requirements 3.1 and 3.2 are the most  important and have the most
> impact
> on the solution space. I do not agree with either of these requirements.
> 
> Implementing multiple non-compatible revisions of a module on a server
> sounds hard,
> not to mention that it breaks RFC 7950 rules. The current protocols do not
> support the
> ability to specify different versions of the same QName. This change makes
> YANG validation
> much to difficult to specify and implement (as that has to be rewritten as
> well).
> 
> It is one thing to deploy rapidly changing, buggy YANG modules in order to
> gain experience quickly.  It is quite another to complicate YANG and the
> protocols
> to preserve these interim mistakes, and bake into the standards the notion
> that this
> is good engineering.
>

So how do you think this conflict between more agility and client
stability should be handled? It seems you can't easily have both at
the same time. Are you saying that backwards compatibility to support
existing clients is not important?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Robert Wilton]

On 26/10/2018 17:35, Andy Bierman wrote:



On Fri, Oct 26, 2018 at 2:33 AM, Juergen Schoenwaelder 
> wrote:


Let me add that there was large disagreement what a bug fix is in the
design team. Hence, any text that talks about 'bug fixes' is ambiguous
and of limited value to achieve consensus. (Or we may find consensus
but then not agree on what we have found consensus on.)

To be more concrete, I learned that Rob's notion of a bug fix is very
different from my notion of a bug fix. I think it is important for
having a productive discussion to be aware of this.

For me, a bug fix is rather limited, i.e., fixing something where the
correct intention was clear but the model did not properly capture the
intention correctly, i.e., roughly what we can do with errata in the
IETF. I think Rob understands bug fixes in a much broader sense,
including fixes to what essentially are in my view module design
errors.

With my narrow definition of bug fixes, bug fixes are essentially
backwards compatible (even if they may violate RFC 7950 rules - but as
long as the original intention was clear, we can be flexible).

With Rob's notion of bug fixes, we have to handle them as part of the
versioning system since they may be non-backwards compatible.



IMO requirements 3.1 and 3.2 are the most  important and have the most 
impact

on the solution space. I do not agree with either of these requirements.

OK.

For 3.1, I think that just means that the solution has to be backwards 
compatible with existing clients (e.g. don't change the protocols in a 
non backwards compatible way).




Implementing multiple non-compatible revisions of a module on a server 
sounds hard,

not to mention that it breaks RFC 7950 rules.
Completely agree that it will be hard.  I envisage that it will optional 
for servers to implement this.



The current protocols do not support the
ability to specify different versions of the same QName. This change 
makes YANG validation
much to difficult to specify and implement (as that has to be 
rewritten as well).
The way that I think of one solution for this problem is using datastore 
schema (as per the NMDA definition):


Say for release X, the server natively supports Module A@ver1.0.0 and 
ModuleB@ver1.0.0, call this schema X.
For release Y, the server natively supports Module A@ver1.1.0 and 
ModuleB@ver2.0.0, call this schema Y.


When a client connects it chooses which schema it wants to use, X, Y, or 
latest.  If it doesn't specify then perhaps it uses the earliest schema 
(to handle requirement 3.1).


If the client wants to use X, then the server has to translate the 
request into the equivalent request using schema Y instead.  Perhaps the 
server has to validate the config both in the context of X and Y.


If the clients wants to use Y then it just talks to the server normally, 
i.e. as it does today.


I think that this is logically the equivalent model mapping that clients 
would have to do to support multiple server revisions.  Yes, I think 
that it is complex.  No, I'm not sure how many vendors will decide to 
implement this, but I think that it is OK to require the solution to 
specify how this is done, so that servers that do want to support this, 
and clients that want to use this, can do so.


But all the QNames, validations, etc, I think would be constrained to a 
particular schema.




It is one thing to deploy rapidly changing, buggy YANG modules in order to
gain experience quickly..  It is quite another to complicate YANG and 
the protocols
to preserve these interim mistakes, and bake into the standards the 
notion that this

is good engineering.

Thanks,
Rob




/js


Andy


On Fri, Oct 26, 2018 at 10:17:48AM +0100, Robert Wilton wrote:
> Hi Chris,
>
>
> On 25/10/2018 18:42, Christian Hopps wrote:
> >
> > Hi Rob,
> >
> > We've more privately discussed the bug-fix scenario and I'm
sympathetic
> > to it; however, the requirement as written does not restrict
itself to
> > fixing module definition bugs (e.g., a pattern or other value
> > constraint) in some small but incompatible way -- instead it's
wide open
> > and it will be [ab]used that way.
> I think that everyone on design team agrees that
non-backwards-compatible
> changes should be minimized and should really only to used for
bug fixes
> where it is anticipated that clients should not be affected.
>
> We want to allow non-backwards-compatible changes at the head of the
> development tree, but again, I think that everyone agrees that
keeping it
> backwards compatible where possible is a good goal.
>
> However, I think that there will be cases where a vendor decides
that it is
> right for an enhancement or non backwards compatible change to
be made to an
> already released module.  I 

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Andy Bierman]

On Fri, Oct 26, 2018 at 2:33 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> Let me add that there was large disagreement what a bug fix is in the
> design team. Hence, any text that talks about 'bug fixes' is ambiguous
> and of limited value to achieve consensus. (Or we may find consensus
> but then not agree on what we have found consensus on.)
>
> To be more concrete, I learned that Rob's notion of a bug fix is very
> different from my notion of a bug fix. I think it is important for
> having a productive discussion to be aware of this.
>
> For me, a bug fix is rather limited, i.e., fixing something where the
> correct intention was clear but the model did not properly capture the
> intention correctly, i.e., roughly what we can do with errata in the
> IETF. I think Rob understands bug fixes in a much broader sense,
> including fixes to what essentially are in my view module design
> errors.
>
> With my narrow definition of bug fixes, bug fixes are essentially
> backwards compatible (even if they may violate RFC 7950 rules - but as
> long as the original intention was clear, we can be flexible).
>
> With Rob's notion of bug fixes, we have to handle them as part of the
> versioning system since they may be non-backwards compatible.
>
>

IMO requirements 3.1 and 3.2 are the most  important and have the most
impact
on the solution space. I do not agree with either of these requirements.

Implementing multiple non-compatible revisions of a module on a server
sounds hard,
not to mention that it breaks RFC 7950 rules. The current protocols do not
support the
ability to specify different versions of the same QName. This change makes
YANG validation
much to difficult to specify and implement (as that has to be rewritten as
well).

It is one thing to deploy rapidly changing, buggy YANG modules in order to
gain experience quickly.  It is quite another to complicate YANG and the
protocols
to preserve these interim mistakes, and bake into the standards the notion
that this
is good engineering.


/js
>

Andy


>
> On Fri, Oct 26, 2018 at 10:17:48AM +0100, Robert Wilton wrote:
> > Hi Chris,
> >
> >
> > On 25/10/2018 18:42, Christian Hopps wrote:
> > >
> > > Hi Rob,
> > >
> > > We've more privately discussed the bug-fix scenario and I'm sympathetic
> > > to it; however, the requirement as written does not restrict itself to
> > > fixing module definition bugs (e.g., a pattern or other value
> > > constraint) in some small but incompatible way -- instead it's wide
> open
> > > and it will be [ab]used that way.
> > I think that everyone on design team agrees that non-backwards-compatible
> > changes should be minimized and should really only to used for bug fixes
> > where it is anticipated that clients should not be affected.
> >
> > We want to allow non-backwards-compatible changes at the head of the
> > development tree, but again, I think that everyone agrees that keeping it
> > backwards compatible where possible is a good goal.
> >
> > However, I think that there will be cases where a vendor decides that it
> is
> > right for an enhancement or non backwards compatible change to be made
> to an
> > already released module.  I agree that this is highly undesirable and an
> > abuse of the rules, but I don't believe that whatever versioning scheme
> we
> > come up with will prevent vendors from doing this.  So then the question
> > becomes: Is it better to pretend that this scenario will never happen,
> > design the versioning scheme so that it cannot be expressed, which
> probably
> > just means that clients will not be able to detect when vendors do this
> by
> > cheating the rules!  Or is it better to accept that this will sometimes
> > occur, provide strong guidance as to why this is bad practice and should
> be
> > avoided, but have a versioning scheme that still allows this to be
> expressed
> > (in a bounded way)?  I.e. even if the vendors are doing something that is
> > less than ideal, at least the clients can spot where they have done this.
> >
> > ---
> >
> > A separate concern that we had about ties this strictly to bug fixes is
> that
> > some one will ask for a definition of a bug fix.  The design team tried
> this
> > but we couldn't even agree what a bug fix is, let alone agree with a
> single
> > definition of a bug fix as it related to a YANG module.  So our
> conclusion
> > was that perhaps it is better not to tie the requirements themselves to
> bug
> > fix vs enhancement, because the boundary between the two is too vague,
> and
> > module writers will bend the rules.
> >
> > So I see that the rules should be:
> >  - backwards compatible bug fix  - this is fine.
> >  - non backwards compatible bug fix - this is fine if it is pragmatically
> > expected to not impact any clients, but careful consideration is
> required if
> > it might break clients.
> >  - backwards compatible enhancement - not ideal, but pragmatically OK.
> >  - non backwards compatible enhancement - 

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Juergen Schoenwaelder]

Let me add that there was large disagreement what a bug fix is in the
design team. Hence, any text that talks about 'bug fixes' is ambiguous
and of limited value to achieve consensus. (Or we may find consensus
but then not agree on what we have found consensus on.)

To be more concrete, I learned that Rob's notion of a bug fix is very
different from my notion of a bug fix. I think it is important for
having a productive discussion to be aware of this.

For me, a bug fix is rather limited, i.e., fixing something where the
correct intention was clear but the model did not properly capture the
intention correctly, i.e., roughly what we can do with errata in the
IETF. I think Rob understands bug fixes in a much broader sense,
including fixes to what essentially are in my view module design
errors.

With my narrow definition of bug fixes, bug fixes are essentially
backwards compatible (even if they may violate RFC 7950 rules - but as
long as the original intention was clear, we can be flexible).

With Rob's notion of bug fixes, we have to handle them as part of the
versioning system since they may be non-backwards compatible.

/js

On Fri, Oct 26, 2018 at 10:17:48AM +0100, Robert Wilton wrote:
> Hi Chris,
> 
> 
> On 25/10/2018 18:42, Christian Hopps wrote:
> > 
> > Hi Rob,
> > 
> > We've more privately discussed the bug-fix scenario and I'm sympathetic
> > to it; however, the requirement as written does not restrict itself to
> > fixing module definition bugs (e.g., a pattern or other value
> > constraint) in some small but incompatible way -- instead it's wide open
> > and it will be [ab]used that way.
> I think that everyone on design team agrees that non-backwards-compatible
> changes should be minimized and should really only to used for bug fixes
> where it is anticipated that clients should not be affected.
> 
> We want to allow non-backwards-compatible changes at the head of the
> development tree, but again, I think that everyone agrees that keeping it
> backwards compatible where possible is a good goal.
> 
> However, I think that there will be cases where a vendor decides that it is
> right for an enhancement or non backwards compatible change to be made to an
> already released module.  I agree that this is highly undesirable and an
> abuse of the rules, but I don't believe that whatever versioning scheme we
> come up with will prevent vendors from doing this.  So then the question
> becomes: Is it better to pretend that this scenario will never happen,
> design the versioning scheme so that it cannot be expressed, which probably
> just means that clients will not be able to detect when vendors do this by
> cheating the rules!  Or is it better to accept that this will sometimes
> occur, provide strong guidance as to why this is bad practice and should be
> avoided, but have a versioning scheme that still allows this to be expressed
> (in a bounded way)?  I.e. even if the vendors are doing something that is
> less than ideal, at least the clients can spot where they have done this.
> 
> ---
> 
> A separate concern that we had about ties this strictly to bug fixes is that
> some one will ask for a definition of a bug fix.  The design team tried this
> but we couldn't even agree what a bug fix is, let alone agree with a single
> definition of a bug fix as it related to a YANG module.  So our conclusion
> was that perhaps it is better not to tie the requirements themselves to bug
> fix vs enhancement, because the boundary between the two is too vague, and
> module writers will bend the rules.
> 
> So I see that the rules should be:
>  - backwards compatible bug fix  - this is fine.
>  - non backwards compatible bug fix - this is fine if it is pragmatically
> expected to not impact any clients, but careful consideration is required if
> it might break clients.
>  - backwards compatible enhancement - not ideal, but pragmatically OK.
>  - non backwards compatible enhancement - this is bad and should be avoided.
> 
> But if we don't want to define the difference between a bug fix vs
> enhancement then I think that you end up with the most general requirement
> being that we do want to allow for non-backwards-compatible changes in
> released modules to accommodate the bug fix scenario, but the expectation
> (and guidance) will be that they should only be used for bug fixes.
> 
> 
> > 
> > For example:
> > 
> > > Here is what I am afraid the vendors want here: A developer on
> > > release train X can easily change some data structure and then push
> > > the change into an automated system which generates a new YANG
> > > module definition and revs a version number -- all done! They don't
> > > have to deal with the inertia of making this change in their release
> > > train Y or Z and they don't have to treat modules as a stable API
> > > they are exporting, b/c they now have these new wonderful versions
> > > from this work. Meanwhile we the users now have to deal with N forks
> > > with all the various 

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Robert Wilton]

Hi Chris,


On 25/10/2018 18:42, Christian Hopps wrote:


Hi Rob,

We've more privately discussed the bug-fix scenario and I'm 
sympathetic to it; however, the requirement as written does not 
restrict itself to fixing module definition bugs (e.g., a pattern or 
other value constraint) in some small but incompatible way -- instead 
it's wide open and it will be [ab]used that way.
I think that everyone on design team agrees that 
non-backwards-compatible changes should be minimized and should really 
only to used for bug fixes where it is anticipated that clients should 
not be affected.


We want to allow non-backwards-compatible changes at the head of the 
development tree, but again, I think that everyone agrees that keeping 
it backwards compatible where possible is a good goal.


However, I think that there will be cases where a vendor decides that it 
is right for an enhancement or non backwards compatible change to be 
made to an already released module.  I agree that this is highly 
undesirable and an abuse of the rules, but I don't believe that whatever 
versioning scheme we come up with will prevent vendors from doing this.  
So then the question becomes: Is it better to pretend that this scenario 
will never happen, design the versioning scheme so that it cannot be 
expressed, which probably just means that clients will not be able to 
detect when vendors do this by cheating the rules!  Or is it better to 
accept that this will sometimes occur, provide strong guidance as to why 
this is bad practice and should be avoided, but have a versioning scheme 
that still allows this to be expressed (in a bounded way)?  I.e. even if 
the vendors are doing something that is less than ideal, at least the 
clients can spot where they have done this.


---

A separate concern that we had about ties this strictly to bug fixes is 
that some one will ask for a definition of a bug fix.  The design team 
tried this but we couldn't even agree what a bug fix is, let alone agree 
with a single definition of a bug fix as it related to a YANG module.  
So our conclusion was that perhaps it is better not to tie the 
requirements themselves to bug fix vs enhancement, because the boundary 
between the two is too vague, and module writers will bend the rules.


So I see that the rules should be:
 - backwards compatible bug fix  - this is fine.
 - non backwards compatible bug fix - this is fine if it is 
pragmatically expected to not impact any clients, but careful 
consideration is required if it might break clients.

 - backwards compatible enhancement - not ideal, but pragmatically OK.
 - non backwards compatible enhancement - this is bad and should be 
avoided.


But if we don't want to define the difference between a bug fix vs 
enhancement then I think that you end up with the most general 
requirement being that we do want to allow for non-backwards-compatible 
changes in released modules to accommodate the bug fix scenario, but the 
expectation (and guidance) will be that they should only be used for bug 
fixes.





For example:

Here is what I am afraid the vendors want here: A developer on 
release train X can easily change some data structure and then push 
the change into an automated system which generates a new YANG module 
definition and revs a version number -- all done! They don't have to 
deal with the inertia of making this change in their release train Y 
or Z and they don't have to treat modules as a stable API they are 
exporting, b/c they now have these new wonderful versions from this 
work. Meanwhile we the users now have to deal with N forks with all 
the various little incompatible changes random developers at the 
company wanted to make without having to coordinate with their 
coworkers/other internal teams. Now multiply this by M vendors. It's 
a nightmare. It shouldn't be what we are optimizing for, let alone 
making a requirement.


Regarding enhancements, these are features, and are naturally 
augmentative. I find it hard to believe we have a pressing 
need/requirement to support non-backward compatible changes to 
existing modules in order to support enhancements.

I agree.  It was a backwards compatible enhancement that I was considering.

Thanks,
Rob




Thanks,
Chris.


Robert Wilton  writes:


Hi Chris,

I think that there are two things driving this requirement:

What I regard as the key one, is that we want to be able to support 
the software
that we have shipped. In particular, we may need to fix bugs (perhaps 
at the
operators request) to a YANG model that has already been released. 
I.e. I think
that there are some scenarios, where forking a YANG module, although 
undesirable
is the right thing to do to include a fix. I don't believe that 
features or

deviations help solve this problem.
The two alternative solutions to being able to fix bugs, neither of 
which I

think is pragmatic, that I can think of are:
(i) Vendors ensure that their YANG modules are perfect before they 
ship 

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Christian Hopps]

Hi Rob,

We've more privately discussed the bug-fix scenario and I'm sympathetic to it; 
however, the requirement as written does not restrict itself to fixing module 
definition bugs (e.g., a pattern or other value constraint) in some small but 
incompatible way -- instead it's wide open and it will be [ab]used that way.

For example:


Here is what I am afraid the vendors want here: A developer on release train X 
can easily change some data structure and then push the change into an 
automated system which generates a new YANG module definition and revs a 
version number -- all done! They don't have to deal with the inertia of making 
this change in their release train Y or Z and they don't have to treat modules 
as a stable API they are exporting, b/c they now have these new wonderful 
versions from this work. Meanwhile we the users now have to deal with N forks 
with all the various little incompatible changes random developers at the 
company wanted to make without having to coordinate with their coworkers/other 
internal teams. Now multiply this by M vendors. It's a nightmare. It shouldn't 
be what we are optimizing for, let alone making a requirement.


Regarding enhancements, these are features, and are naturally augmentative. I 
find it hard to believe we have a pressing need/requirement to support 
non-backward compatible changes to existing modules in order to support 
enhancements.

Thanks,
Chris.


Robert Wilton  writes:


Hi Chris,

I think that there are two things driving this requirement:

What I regard as the key one, is that we want to be able to support the software
that we have shipped. In particular, we may need to fix bugs (perhaps at the
operators request) to a YANG model that has already been released. I.e. I think
that there are some scenarios, where forking a YANG module, although undesirable
is the right thing to do to include a fix. I don't believe that features or
deviations help solve this problem.
The two alternative solutions to being able to fix bugs, neither of which I
think is pragmatic, that I can think of are:
(i) Vendors ensure that their YANG modules are perfect before they ship in a
release.
(ii) If a bug is reported, operators are happy to wait until the bug has been
fixed in the current development release, and will migrate to that latest
release to pick up the fix.

The second thing driving this requirement is that vendors sometimes get asked
for enhancements to existing releases, perhaps because the latest development
release is too far out, or ask for an enhancement on the current train to be
back ported to an older release.

So, aiming to have stable YANG modules, trying a lot harder to avoid
non-backwards-compatible changes, and keeping new functionality to the head of
the development I completely agree with you on. But I still believe that there
are some valid scenarios, that should be limited as much as possible, where it
is necessary to make changes that sometimes break these rules, and having a
limited scheme that clearly indicates where such breakages have occurred is
probably better that the status quo of where the modules get changed, but the
operator doesn't get any useful indication of what type of changes are being
made.

Thanks,
Rob


On 25/10/2018 16:26, Christian Hopps wrote:



On Oct 20, 2018, at 1:55 PM, Joe Clarke  wrote:

* New requirement 1.4 for supporting over-arching software releases

[ I read this as supporting various different module versions based on a 
vendor's different software release trains. If this is wrong then the rest of 
this doesn't apply and I would just ask for the text to be update to clarify 
what it means. ]

How many operators/users have asked for this or indicated it's a requirement 
for them?

What problem is intractable without this requirement being met, and what is the 
cost of this requirement on the actual users?

I have pushed back multiple times on this b/c I believe this "requirement" is 
really being pushed to make it easier for vendors (a small affected group) to develop 
their software at the cost of their users (the much larger affected group) who would then 
have to deal with multiple trains of the same module.


We already have features and deviations why are they not enough to deal with 
functionality that is present or not in various software release/devices?

FWIW I'm not against making it easier to develop software, but we have to be 
mindful if we are just pushing the cost (and magnifying it greatly) to other 
people in the community.

Thanks,
Chris.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Andy Bierman]

On Thu, Oct 25, 2018 at 8:26 AM, Christian Hopps  wrote:

>
>
> > On Oct 20, 2018, at 1:55 PM, Joe Clarke  wrote:
> >
> > * New requirement 1.4 for supporting over-arching software releases
>
>
This text?

   1.4  The solution MUST allow for modules to be versioned by
software release.  In particular, backwards-compatible
enhancements and bug fixes MUST be allowed in any non-latest
release.



IMO these requirements are mostly intended to legitimize bad practices be
server vendors,
entirely at the expense of client developers.

It is clear that SEMVER is required to support this requirement to
treat every platform as an isolated release of what are supposed to be
shared modules.
The revision date no longer identifies the latest (e.g, 1.6.1 could have a
newer date than 1.9.0)
However, SEMVER becomes less useful if 1.6.1 actually has more features
than 1.9.0.

YANG clients already have to deal with different variants (revision,
features, deviations) on every server,
so it would be easy to think that all these server variants are not a new
problem.
However, this only applies to parsing incoming data.  A client that is
designed to
formulate requests against specific data models is greatly harmed by a lack
of server
consistency.

If YANG is ever going to grow up, the 3rd party client development needs to
be taken more seriously.


Andy


[ I read this as supporting various different module versions based on a
> vendor's different software release trains. If this is wrong then the rest
> of this doesn't apply and I would just ask for the text to be update to
> clarify what it means. ]
>
> How many operators/users have asked for this or indicated it's a
> requirement for them?
>
> What problem is intractable without this requirement being met, and what
> is the cost of this requirement on the actual users?
>
> I have pushed back multiple times on this b/c I believe this "requirement"
> is really being pushed to make it easier for vendors (a small affected
> group) to develop their software at the cost of their users (the much
> larger affected group) who would then have to deal with multiple trains of
> the same module.
>
> Here is what I am afraid the vendors want here: A developer on release
> train X can easily change some data structure and then push the change into
> an automated system which generates a new YANG module definition and revs a
> version number -- all done! They don't have to deal with the inertia of
> making this change in their release train Y or Z and they don't have to
> treat modules as a stable API they are exporting, b/c they now have these
> new wonderful versions from this work. Meanwhile we the users now have to
> deal with N forks with all the various little incompatible changes random
> developers at the company wanted to make without having to coordinate with
> their coworkers/other internal teams. Now multiply this by M vendors. It's
> a nightmare. It shouldn't be what we are optimizing for, let alone making a
> requirement.
>
> We already have features and deviations why are they not enough to deal
> with functionality that is present or not in various software
> release/devices?
>
> FWIW I'm not against making it easier to develop software, but we have to
> be mindful if we are just pushing the cost (and magnifying it greatly) to
> other people in the community.
>
> Thanks,
> Chris.
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Robert Wilton]

Hi Chris,

I think that there are two things driving this requirement:

What I regard as the key one, is that we want to be able to support the 
software that we have shipped.  In particular, we may need to fix bugs 
(perhaps at the operators request) to a YANG model that has already been 
released.  I.e. I think that there are some scenarios, where forking a 
YANG module, although undesirable is the right thing to do to include a 
fix.  I don't believe that features or deviations help solve this problem.


The two alternative solutions to being able to fix bugs, neither of 
which I think is pragmatic, that I can think of are:
(i) Vendors ensure that their YANG modules are perfect before they ship 
in a release.
(ii) If a bug is reported, operators are happy to wait until the bug has 
been fixed in the current development release, and will migrate to that 
latest release to pick up the fix.


The second thing driving this requirement is that vendors sometimes get 
asked for enhancements to existing releases, perhaps because the latest 
development release is too far out, or ask for an enhancement on the 
current train to be back ported to an older release.


So, aiming to have stable YANG modules, trying a lot harder to avoid 
non-backwards-compatible changes, and keeping new functionality to the 
head of the development I completely agree with you on.  But I still 
believe that there are some valid scenarios, that should be limited as 
much as possible, where it is necessary to make changes that sometimes 
break these rules, and having a limited scheme that clearly indicates 
where such breakages have occurred is probably better that the status 
quo of where the modules get changed, but the operator doesn't get any 
useful indication of what type of changes are being made.


Thanks,
Rob


On 25/10/2018 16:26, Christian Hopps wrote:



On Oct 20, 2018, at 1:55 PM, Joe Clarke  wrote:

* New requirement 1.4 for supporting over-arching software releases

[ I read this as supporting various different module versions based on a 
vendor's different software release trains. If this is wrong then the rest of 
this doesn't apply and I would just ask for the text to be update to clarify 
what it means. ]

How many operators/users have asked for this or indicated it's a requirement 
for them?

What problem is intractable without this requirement being met, and what is the 
cost of this requirement on the actual users?

I have pushed back multiple times on this b/c I believe this "requirement" is 
really being pushed to make it easier for vendors (a small affected group) to develop 
their software at the cost of their users (the much larger affected group) who would then 
have to deal with multiple trains of the same module.

Here is what I am afraid the vendors want here: A developer on release train X 
can easily change some data structure and then push the change into an 
automated system which generates a new YANG module definition and revs a 
version number -- all done! They don't have to deal with the inertia of making 
this change in their release train Y or Z and they don't have to treat modules 
as a stable API they are exporting, b/c they now have these new wonderful 
versions from this work. Meanwhile we the users now have to deal with N forks 
with all the various little incompatible changes random developers at the 
company wanted to make without having to coordinate with their coworkers/other 
internal teams. Now multiply this by M vendors. It's a nightmare. It shouldn't 
be what we are optimizing for, let alone making a requirement.

We already have features and deviations why are they not enough to deal with 
functionality that is present or not in various software release/devices?

FWIW I'm not against making it easier to develop software, but we have to be 
mindful if we are just pushing the cost (and magnifying it greatly) to other 
people in the community.

Thanks,
Chris.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod