"Reshad Rahman (rrahman)" <rrah...@cisco.com> wrote:
>
> On 2018-11-09, 8:51 PM, "Martin Bjorklund" <m...@tail-f.com> wrote:
>
> "Reshad Rahman (rrahman)" <rrah...@cisco.com> wrote:
> >
> >
> > On 2018-11-09, 8:37 PM, "netmod on behalf of Martin Bjorklund"
> > <netmod-boun...@ietf.org on behalf of m...@tail-f.com> wrote:
> >
> > Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> wrote:
> > > On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
> > > > Juergen Schoenwaelder <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.
> >
> > 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?
Yes; it should be ok for a solution to solve more problems than what
the requirements doc specify.
/martin
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
