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

Christian Hopps <chopps@chopps.org> Thu, 25 October 2018 15:26 UTC

Return-Path: <chopps@chopps.org>
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 39EE9130E7C; Thu, 25 Oct 2018 08:26:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 iYVRZDU8aMg5; Thu, 25 Oct 2018 08:26:27 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id E0E03130E76; Thu, 25 Oct 2018 08:26:26 -0700 (PDT)
Received: from stubbs.int.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 3231060068; Thu, 25 Oct 2018 15:26:26 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Christian Hopps <chopps@chopps.org>
In-Reply-To: <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com>
Date: Thu, 25 Oct 2018 11:26:25 -0400
Cc: Christian Hopps <chopps@chopps.org>, "netmod@ietf.org" <netmod@ietf.org>, "netmod-ver-dt@ietf.org" <netmod-ver-dt@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org>
References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com> <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com>
To: Joe Clarke <jclarke@cisco.com>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/dUk3MsqZ85DsCAHYA_AaVYy6Ecg>
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: Thu, 25 Oct 2018 15:26:28 -0000


> On Oct 20, 2018, at 1:55 PM, Joe Clarke <jclarke@cisco.com> wrote:
> 
> * New requirement 1.4 for supporting over-arching software releases

[ I read this as supporting various different module versions based on a vendor's different software release trains. If this is wrong then the rest of this doesn't apply and I would just ask for the text to be update to clarify what it means. ]

How many operators/users have asked for this or indicated it's a requirement for them?

What problem is intractable without this requirement being met, and what is the cost of this requirement on the actual users?

I have pushed back multiple times on this b/c I believe this "requirement" is really being pushed to make it easier for vendors (a small affected group) to develop their software at the cost of their users (the much larger affected group) who would then have to deal with multiple trains of the same module.

Here is what I am afraid the vendors want here: A developer on release train X can easily change some data structure and then push the change into an automated system which generates a new YANG module definition and revs a version number -- all done! They don't have to deal with the inertia of making this change in their release train Y or Z and they don't have to treat modules as a stable API they are exporting, b/c they now have these new wonderful versions from this work. Meanwhile we the users now have to deal with N forks with all the various little incompatible changes random developers at the company wanted to make without having to coordinate with their coworkers/other internal teams. Now multiply this by M vendors. It's a nightmare. It shouldn't be what we are optimizing for, let alone making a requirement.

We already have features and deviations why are they not enough to deal with functionality that is present or not in various software release/devices?

FWIW I'm not against making it easier to develop software, but we have to be mindful if we are just pushing the cost (and magnifying it greatly) to other people in the community.

Thanks,
Chris.