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

[Ebben Aries]

On Nov 09 14:42 PM, Martin Bjorklund wrote:
> > The
> > point of requirement 1.4 was to say that the DT felt previous versions
> > of modules needed to support fixes without bringing in elements from head.
> 
> I think this means that you require branching.
> 
> But is this still the point of the "new 1.4" that was mentioned in the
> session?
> 
> However, as Rob Shakir mentioned in the session, there are other ways
> to do fixes / enhacements than branching a single module.  You can add
> new functionality with augment and make changes with deviations.
> 

So we could potentially result in a cleaner set of base model versioning
but augments and deviations that will need somewhat of it's own
branch versioning now.  I often find that consumers/clients make quite a
few assumptions and expectations when one supports model version X (w/o
the realization that it is X+/- for various reasons)

We'll have a namespace problem which will result in namespaces being
inserted (and removed at later dates) which ultimately has an impact on
clients

Possibly a better middle ground but think there are still considerations
here as well as to the overall impact of this approach

/ebben

___
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

[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 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

[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]

"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] Fwd: New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Martin Bjorklund]

Joe Clarke  wrote:
> On 11/8/18 16:46, Martin Bjorklund wrote:
> > Hi,
> > 
> > After the session today, it seems to me that one fundamental
> > requirement (or non-requirement) is missing.  How much branching does
> > the solution have to support?  The current solution (6020/7950) and (if
> > I understood Rob Shakir correctly) also openconfig have linear
> > versioning *per module*.  If we can get agreement on this requirement,
> > I think it will be easier to find a solution.
> 
> We discussed this in the DT.  We didn't want to discuss levels of
> branching in the requirements as that pointed to certain solutions.

All requirements point to certain solutions, in a sense.

But if you say that branching is not a requirement on a solution, I'm
happy with that.

> The
> point of requirement 1.4 was to say that the DT felt previous versions
> of modules needed to support fixes without bringing in elements from head.

I think this means that you require branching.

But is this still the point of the "new 1.4" that was mentioned in the
session?

However, as Rob Shakir mentioned in the session, there are other ways
to do fixes / enhacements than branching a single module.  You can add
new functionality with augment and make changes with deviations.


/martin


> We discussed branching to satisfy this requirement as well as protecting
> new features with if-feature and using deviations.
> 
> Joe
> 

___
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

[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

[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

[netmod] missing YANG versioning requirements

[Andy Bierman]

Hi,

I think the requirements doc should state that

1) there are many more readers, operators, and client developers than
server developers so the solution MUST take into account the numbers
of people affected when finding a balance between client and server
complexity.

2) if existing protocol and YANG solutions exist then they MUST be used
in favor of developing new solutions.


Andy
___
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

[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

[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
> >