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

[Martin Bjorklund <[e-mail]>]

"Reshad Rahman (rrahman)" <[e-mail]> wrote:
> 
> 
> On 2018-11-09, 8:37 PM, "netmod on behalf of Martin Bjorklund"
> <[e-mail] on behalf of [e-mail]> wrote:
> 
>     Juergen Schoenwaelder <[e-mail]> wrote:
>     > On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
>     > > Juergen Schoenwaelder <[e-mail]> 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.
>     
> <RR> 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
server would be able to implement it.  I think it makes the whole
solution much more complex, w/o much gain.  It is complex enough as it
is.


/martin