Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
Robert Wilton <rwilton@cisco.com> Fri, 26 October 2018 09:17 UTC
Return-Path: <rwilton@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 896221293FB for <netmod@ietfa.amsl.com>; Fri, 26 Oct 2018 02:17:53 -0700 (PDT)
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 GZtY9Xabdq0X for <netmod@ietfa.amsl.com>; Fri, 26 Oct 2018 02:17:51 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED18E128CF2 for <netmod@ietf.org>; Fri, 26 Oct 2018 02:17:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8162; q=dns/txt; s=iport; t=1540545471; x=1541755071; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=6kjm4Iw++SwVqeHUJiU6NSUwsAXd0wgNF2RDV+9fFvQ=; b=hQRitoy8C2HO6OA2naePI3cCaIYX240knK+vTH0s1Kmcs/BeGMfPjP2h BDWqT1NF/ayEkpdl5u2aN3lIYylcrxk2AGOsfk4cgc6Hn0ixcFyD8CDQR 2EDCp5FyC9NI2gCSIf3ep9vfnBcBppcIeCP1DlJdmWAl+ULEKi0d5oT+B U=;
X-IronPort-AV: E=Sophos;i="5.54,427,1534809600"; d="scan'208";a="7547419"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2018 09:17:49 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w9Q9HmcS004368; Fri, 26 Oct 2018 09:17:49 GMT
To: Christian Hopps <chopps@chopps.org>
Cc: Joe Clarke <jclarke@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com> <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com> <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org> <a0392622-4405-8286-374b-effd652114cd@cisco.com> <sa636st2a97.fsf@chopps.org>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <01d5056d-7645-cb1d-6e88-fbdbeb8ebca4@cisco.com>
Date: Fri, 26 Oct 2018 10:17:48 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <sa636st2a97.fsf@chopps.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.63, dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/SO_hjpcgEElb2ZjN_hXT3ioKT3Y>
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, 26 Oct 2018 09:17:53 -0000
Hi Chris, On 25/10/2018 18:42, Christian Hopps wrote: > > Hi Rob, > > We've more privately discussed the bug-fix scenario and I'm > sympathetic to it; however, the requirement as written does not > restrict itself to fixing module definition bugs (e.g., a pattern or > other value constraint) in some small but incompatible way -- instead > it's wide open and it will be [ab]used that way. I think that everyone on design team agrees that non-backwards-compatible changes should be minimized and should really only to used for bug fixes where it is anticipated that clients should not be affected. We want to allow non-backwards-compatible changes at the head of the development tree, but again, I think that everyone agrees that keeping it backwards compatible where possible is a good goal. However, I think that there will be cases where a vendor decides that it is right for an enhancement or non backwards compatible change to be made to an already released module. I agree that this is highly undesirable and an abuse of the rules, but I don't believe that whatever versioning scheme we come up with will prevent vendors from doing this. So then the question becomes: Is it better to pretend that this scenario will never happen, design the versioning scheme so that it cannot be expressed, which probably just means that clients will not be able to detect when vendors do this by cheating the rules! Or is it better to accept that this will sometimes occur, provide strong guidance as to why this is bad practice and should be avoided, but have a versioning scheme that still allows this to be expressed (in a bounded way)? I.e. even if the vendors are doing something that is less than ideal, at least the clients can spot where they have done this. --- A separate concern that we had about ties this strictly to bug fixes is that some one will ask for a definition of a bug fix. The design team tried this but we couldn't even agree what a bug fix is, let alone agree with a single definition of a bug fix as it related to a YANG module. So our conclusion was that perhaps it is better not to tie the requirements themselves to bug fix vs enhancement, because the boundary between the two is too vague, and module writers will bend the rules. So I see that the rules should be: - backwards compatible bug fix - this is fine. - non backwards compatible bug fix - this is fine if it is pragmatically expected to not impact any clients, but careful consideration is required if it might break clients. - backwards compatible enhancement - not ideal, but pragmatically OK. - non backwards compatible enhancement - this is bad and should be avoided. But if we don't want to define the difference between a bug fix vs enhancement then I think that you end up with the most general requirement being that we do want to allow for non-backwards-compatible changes in released modules to accommodate the bug fix scenario, but the expectation (and guidance) will be that they should only be used for bug fixes. > > For example: > >> 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. > > Regarding enhancements, these are features, and are naturally > augmentative. I find it hard to believe we have a pressing > need/requirement to support non-backward compatible changes to > existing modules in order to support enhancements. I agree. It was a backwards compatible enhancement that I was considering. Thanks, Rob > > Thanks, > Chris. > > > Robert Wilton <rwilton@cisco.com> writes: > >> Hi Chris, >> >> I think that there are two things driving this requirement: >> >> What I regard as the key one, is that we want to be able to support >> the software >> that we have shipped. In particular, we may need to fix bugs (perhaps >> at the >> operators request) to a YANG model that has already been released. >> I.e. I think >> that there are some scenarios, where forking a YANG module, although >> undesirable >> is the right thing to do to include a fix. I don't believe that >> features or >> deviations help solve this problem. >> The two alternative solutions to being able to fix bugs, neither of >> which I >> think is pragmatic, that I can think of are: >> (i) Vendors ensure that their YANG modules are perfect before they >> ship in a >> release. >> (ii) If a bug is reported, operators are happy to wait until the bug >> has been >> fixed in the current development release, and will migrate to that >> latest >> release to pick up the fix. >> >> The second thing driving this requirement is that vendors sometimes >> get asked >> for enhancements to existing releases, perhaps because the latest >> development >> release is too far out, or ask for an enhancement on the current >> train to be >> back ported to an older release. >> >> So, aiming to have stable YANG modules, trying a lot harder to avoid >> non-backwards-compatible changes, and keeping new functionality to >> the head of >> the development I completely agree with you on. But I still believe >> that there >> are some valid scenarios, that should be limited as much as possible, >> where it >> is necessary to make changes that sometimes break these rules, and >> having a >> limited scheme that clearly indicates where such breakages have >> occurred is >> probably better that the status quo of where the modules get changed, >> but the >> operator doesn't get any useful indication of what type of changes >> are being >> made. >> >> Thanks, >> Rob >> >> >> On 25/10/2018 16:26, Christian Hopps wrote: >>> >>>> 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. >>> >>> >>> 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. >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> . >>> > > . >
- [netmod] Fwd: New Version Notification for draft-… Joe Clarke
- Re: [netmod] New Version Notification for draft-v… Christian Hopps
- Re: [netmod] New Version Notification for draft-v… Robert Wilton
- Re: [netmod] New Version Notification for draft-v… Andy Bierman
- Re: [netmod] New Version Notification for draft-v… Christian Hopps
- Re: [netmod] New Version Notification for draft-v… Robert Wilton
- Re: [netmod] New Version Notification for draft-v… Juergen Schoenwaelder
- Re: [netmod] New Version Notification for draft-v… Andy Bierman
- Re: [netmod] New Version Notification for draft-v… Robert Wilton
- Re: [netmod] New Version Notification for draft-v… Juergen Schoenwaelder
- Re: [netmod] New Version Notification for draft-v… Andy Bierman
- Re: [netmod] New Version Notification for draft-v… Juergen Schoenwaelder
- Re: [netmod] New Version Notification for draft-v… Andy Bierman
- Re: [netmod] New Version Notification for draft-v… Juergen Schoenwaelder
- Re: [netmod] New Version Notification for draft-v… Balázs Lengyel
- Re: [netmod] New Version Notification for draft-v… Balázs Lengyel
- Re: [netmod] New Version Notification for draft-v… Andy Bierman
- Re: [netmod] New Version Notification for draft-v… Martin Bjorklund
- Re: [netmod] New Version Notification for draft-v… Martin Bjorklund
- Re: [netmod] Fwd: New Version Notification for dr… Martin Bjorklund
- Re: [netmod] Fwd: New Version Notification for dr… Joe Clarke
- Re: [netmod] New Version Notification for draft-v… Juergen Schoenwaelder
- Re: [netmod] New Version Notification for draft-v… Andy Bierman
- Re: [netmod] New Version Notification for draft-v… Martin Bjorklund
- Re: [netmod] Fwd: New Version Notification for dr… Martin Bjorklund
- Re: [netmod] New Version Notification for draft-v… Reshad Rahman (rrahman)
- Re: [netmod] New Version Notification for draft-v… Martin Bjorklund
- Re: [netmod] New Version Notification for draft-v… Reshad Rahman (rrahman)
- Re: [netmod] New Version Notification for draft-v… Reshad Rahman (rrahman)
- Re: [netmod] New Version Notification for draft-v… Martin Bjorklund
- Re: [netmod] New Version Notification for draft-v… Juergen Schoenwaelder
- Re: [netmod] New Version Notification for draft-v… Martin Bjorklund
- Re: [netmod] New Version Notification for draft-v… Juergen Schoenwaelder
- Re: [netmod] New Version Notification for draft-v… Robert Wilton
- Re: [netmod] New Version Notification for draft-v… Robert Wilton
- Re: [netmod] Fwd: New Version Notification for dr… Ebben Aries
- Re: [netmod] New Version Notification for draft-v… Andy Bierman
- Re: [netmod] New Version Notification for draft-v… Robert Wilton
- Re: [netmod] New Version Notification for draft-v… Martin Bjorklund
- Re: [netmod] New Version Notification for draft-v… Juergen Schoenwaelder
- Re: [netmod] New Version Notification for draft-v… Martin Bjorklund
- Re: [netmod] New Version Notification for draft-v… Robert Wilton