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

Martin Bjorklund <mbj@tail-f.com> Fri, 09 November 2018 14:24 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15B71277C8 for <netmod@ietfa.amsl.com>; Fri, 9 Nov 2018 06:24:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4MrQ7HiSCLC for <netmod@ietfa.amsl.com>; Fri, 9 Nov 2018 06:24:51 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBCC130E08 for <netmod@ietf.org>; Fri, 9 Nov 2018 06:24:50 -0800 (PST)
Received: from localhost (h-40-120.A165.priv.bahnhof.se [94.254.40.120]) by mail.tail-f.com (Postfix) with ESMTPSA id 100FC1AE0493; Fri, 9 Nov 2018 15:24:49 +0100 (CET)
Date: Fri, 09 Nov 2018 15:24:48 +0100 (CET)
Message-Id: <20181109.152448.2106746182360412729.mbj@tail-f.com>
To: rrahman@cisco.com
Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <D89C3875-E54A-478D-9AB1-BA901185488E@cisco.com>
References: <44622200-AB28-4826-9CEC-8A17264E033A@cisco.com> <20181109.145106.380003384922236577.mbj@tail-f.com> <D89C3875-E54A-478D-9AB1-BA901185488E@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/CvfcE2D5wptG87vLorFD6VLScMI>
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Nov 2018 14:24:53 -0000

"Reshad Rahman (rrahman)" <rrahman@cisco.com> wrote:
> 
> On 2018-11-09, 8:51 PM, "Martin Bjorklund" <mbj@tail-f.com> wrote:
> 
>     "Reshad Rahman (rrahman)" <rrahman@cisco.com> wrote:
>     > 
>     > 
>     > On 2018-11-09, 8:37 PM, "netmod on behalf of Martin Bjorklund"
>     > <netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote:
>     > 
>     >     Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>     >     > On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
>     >     > > Juergen Schoenwaelder <j.schoenwaelder@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