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

["Reshad Rahman (rrahman)" <[e-mail]>]

On 2018-11-09, 8:51 PM, "Martin Bjorklund" <[e-mail]> wrote:

    "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.
I agree that ideally we don't need to have this to solve the problem, but it is a potential solution. If it is removed in the requirements draft but considered in the solutions draft, would you be ok with that?

Regards,
Reshad.
    
    /martin