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

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Fri, 09 November 2018 14:07 UTC

Return-Path: <rrahman@cisco.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 BD704130DFF for <netmod@ietfa.amsl.com>; Fri, 9 Nov 2018 06:07:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 vUm-frq8YHxf for <netmod@ietfa.amsl.com>; Fri, 9 Nov 2018 06:07:30 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B9CC1277C8 for <netmod@ietf.org>; Fri, 9 Nov 2018 06:07:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8442; q=dns/txt; s=iport; t=1541772450; x=1542982050; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pKX2Hotu590m2hcbRqsWEwRBzFAnTzigsErDN/eC0OE=; b=VfUClNrqCyOkZH21SfJiuH0lwOoGZCGysKgVgNjn+wGSI0Uiq9KiKrm7 42OdiLKSuR92iXGEwDZ5NflMirDL5eCAnrTEm3rPkUBX9yLKQAKzqK4sq JQo4bEDktf8fP6j9Th83XwxoPIDraIj7BXWMlbZ+nrLNwvY9WEzxeo7ur U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAAA+k+Vb/5BdJa1kGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBggOBaCcKg26IGIt6gg2XMhSBZgsBAYRsAheDCyI0DQ0BAwEBAgEBAm0ohToBAQEBAgEjETgKAQIFCwIBCA4CCAICJgICAjAVEAIEDgUbgwaBeginUoEuiiGBC4pxF4FBP4ERJx+BTn6EZgIWFyOCSjGCJgKJPYVFkEoJApEXGIFXjxeJVo10AhEUgSYdOIFVcBU7KgGCQYInFxKOCkExi3KBHwEB
X-IronPort-AV: E=Sophos;i="5.54,483,1534809600"; d="scan'208";a="198976870"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Nov 2018 14:07:29 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id wA9E7Tx3028677 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Nov 2018 14:07:29 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 9 Nov 2018 08:07:28 -0600
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Fri, 9 Nov 2018 08:07:28 -0600
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "j.schoenwaelder@jacobs-university.de" <j.schoenwaelder@jacobs-university.de>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
Thread-Index: AQHUbQzN26pBXqFS9Uuo4XPBFQXcdaUxl7WAgAB13oCAAGvkAIAACa0AgACW4gCAAFffAIAAe8KAgBL0rgCAALEIgIAAWdaA//+ulYCAAFU5AP//sL2A
Date: Fri, 09 Nov 2018 14:07:28 +0000
Message-ID: <D89C3875-E54A-478D-9AB1-BA901185488E@cisco.com>
References: <20181109081557.kzalxvnsk2k2fycm@anna.jacobs.jacobs-university.de> <20181109.143729.1869485019013831956.mbj@tail-f.com> <44622200-AB28-4826-9CEC-8A17264E033A@cisco.com> <20181109.145106.380003384922236577.mbj@tail-f.com>
In-Reply-To: <20181109.145106.380003384922236577.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.241.214]
Content-Type: text/plain; charset="utf-8"
Content-ID: <B6358FBDDC84E04886E96D304D4240C1@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/7xKHhOo1JVGFSPVbdrfzP3fTfeM>
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:07:33 -0000

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?

Regards,
Reshad.
    
    /martin