RE: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

"Ackermann, Michael" <MAckermann@bcbsm.com> Thu, 30 March 2017 20:20 UTC

Return-Path: <mackermann@bcbsm.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CA2128708 for <ietf@ietfa.amsl.com>; Thu, 30 Mar 2017 13:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.092
X-Spam-Level:
X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.onmicrosoft.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 I4LCyEn4LbZl for <ietf@ietfa.amsl.com>; Thu, 30 Mar 2017 13:20:51 -0700 (PDT)
Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48563126B72 for <ietf@ietf.org>; Thu, 30 Mar 2017 13:20:51 -0700 (PDT)
Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 8D404C1634 for <ietf@ietf.org>; Thu, 30 Mar 2017 15:20:50 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id D5754C159C; Thu, 30 Mar 2017 15:20:49 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3EA0AFE04E; Thu, 30 Mar 2017 16:21:01 -0400 (EDT)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E7E68FE048; Thu, 30 Mar 2017 16:21:00 -0400 (EDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (unknown [216.32.181.17]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Thu, 30 Mar 2017 16:21:00 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=I6jTIIHr3/EjAkGyxJgsVVYE2Jp5WlnW+HRXyutfXWk=; b=xJFlWiBxIWpngerfOJgLdzuHLBFaubahDb1qHpNLP6RqAmwOpUj2vqJh4vT//7E9qUmexumBTceaf8xOvevg2dvrVD1cszy2DWkp13RoxiLV9+csTi34B8ISegO+BwdKbdBEA7qa1GG/ZnEkNWJWxoQ898HJDLOz1WlRrXCk/Q4=
Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Thu, 30 Mar 2017 20:20:46 +0000
Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1005.010; Thu, 30 Mar 2017 20:20:46 +0000
From: "Ackermann, Michael" <MAckermann@bcbsm.com>
To: Tim Chown <Tim.Chown@jisc.ac.uk>, 6man WG <ipv6@ietf.org>, "draft-ietf-6man-rfc2460bis.all@ietf.org" <draft-ietf-6man-rfc2460bis.all@ietf.org>
CC: IETF Discussion <ietf@ietf.org>
Subject: RE: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Index: AQHSnTZv71giYAPcbUKK9ywM4gSjvqGssVmAgAC6+QCAAAergIAAIVqAgAAFggCAAASRAIAAEj+AgAAYQACAABLvAIAADMoQ
Date: Thu, 30 Mar 2017 20:20:46 +0000
Message-ID: <CY4PR14MB1368A609AEECA1DC2CE660E3D7340@CY4PR14MB1368.namprd14.prod.outlook.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com> <CA+b+ERk8kHWyBY3GPp21-pgrL_SsShaLkrn4UdecFeQPYamSEg@mail.gmail.com> <A0F19A98-7DBE-4616-B949-529ED2A81D62@ericsson.com> <CA+b+ERk_cKGB6a0SQd560cMiOzT4KbSic6fCCwQWrhNkNEcO3Q@mail.gmail.com> <CAJE_bqfBt_uytbgQ+=zO4ed9jnc9p=FgPuLH-efgdjFKa+C4jQ@mail.gmail.com> <5E233A42-42C7-4D16-A755-7E0314BFB2D4@jisc.ac.uk>
In-Reply-To: <5E233A42-42C7-4D16-A755-7E0314BFB2D4@jisc.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: jisc.ac.uk; dkim=none (message not signed) header.d=none;jisc.ac.uk; dmarc=none action=none header.from=bcbsm.com;
x-originating-ip: [2001:67c:370:128:e93e:cd10:473c:bf2a]
x-microsoft-exchange-diagnostics: 1; CY4PR14MB1368; 7:eAvYwE0UesJpsAP1J8gLmGM59NT1giPSB44m8sHEZ1A6cI9HHdWowwgK3a5IckEsO0OdKeElF1CrmFly5Dqwu3uMBk1JLBU6fLJgxf+9SHgFyWKHnAILMqOLG/rQ5SedxT2t43xiLN90AWos3E0Q/Swhg+kmwL+uLeYWhoZ1KvDOCpko9JEcgCVAdXKSj96g7lE9hvTpLWeztiQO1i2b3H4/1CE1OIu5nGxj8yItN/XSeaF7w6c1gca5tnWzRRC8rqwxZQivTuj5/jFd2BkLkFLVRgoxduvPnusZGoohSFKpQdHMyne4WPPjDf3jKYb1YjhowHJk8P8TXwcmBYs0KA==; 20:HNOX2AS7TqGrsaBHMK3L2piTmqvVCqT0iSUrrJ/nxD35VW2pGZtNVFD5waJB57hQmF4daPJQUJvG2WqfcG3Bo9EmI12CokAnF7Be+Z3XYkbj5qT2wUEov15Fyqbpt6EgFddDAroQf6vDFLYjyLJBJ33eH/VOA3D2ukwrh/+NnzA=
x-ms-office365-filtering-correlation-id: ab0d56ad-78f4-46b5-475d-08d477aa3ffb
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY4PR14MB1368;
x-microsoft-antispam-prvs: <CY4PR14MB136844E44607C58A6F2BA170D7340@CY4PR14MB1368.namprd14.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:CY4PR14MB1368; BCL:0; PCL:0; RULEID:; SRVR:CY4PR14MB1368;
x-forefront-prvs: 02622CEF0A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39450400003)(39830400002)(377454003)(13464003)(24454002)(53546009)(8676002)(86362001)(81166006)(3660700001)(7736002)(8936002)(7696004)(2900100001)(305945005)(230783001)(74316002)(561944003)(33656002)(80792005)(5660300001)(189998001)(2950100002)(122556002)(25786009)(38730400002)(229853002)(2501003)(9686003)(53936002)(76176999)(55016002)(6306002)(50986999)(54356999)(99286003)(6246003)(2906002)(6506006)(3280700002)(4326008)(6116002)(6436002)(77096006)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1368; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: bcbsm.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 20:20:46.4808 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1368
X-TM-AS-GCONF: 00
X-VPM-HOST: vmvpm02.z120.zixworks.com
X-VPM-GROUP-ID: 9d8f07ce-4bd3-4f04-88ad-b71316e0d211
X-VPM-MSG-ID: 3d169a4b-c657-4ef5-ad0b-c0585ffa39e7
X-VPM-ENC-REGIME: Plaintext
X-VPM-IS-HYBRID: 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/BjZjpcPGv6sTPbwVT2niWubtWyg>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Mar 2017 20:20:56 -0000

Great thoughts/info and they all make sense from an IETF perspective. 
From an enterprise perspective, it is unlikely that anyone in that world knows what moving to IS means or implies.   
So the problem that I have in trying to get my enterprise, or the many we have direct (or even indirect) connections with, to even THINK about IPv6, is coming up with reasons to do so.   There are a couple of reasons/features that I have hope could be compelling.  But if those features depend on EHs, or anything unsupported, future or "Exceptional",  they will not be compelling at all.  
My world is a tough sell.   I just do not want it to get any tougher.  
Thanks
Mike


-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tim Chown
Sent: Thursday, March 30, 2017 3:27 PM
To: 6man WG <ipv6@ietf.org>rg>; draft-ietf-6man-rfc2460bis.all@ietf.org
Cc: IETF Discussion <ietf@ietf.org>
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

Hi,

> On 30 Mar 2017, at 19:19, 神明達哉 <jinmei@wide.ad.jp> wrote:
> 
> At Thu, 30 Mar 2017 11:52:41 -0500,
> Robert Raszuk <robert@raszuk.net> wrote:
> 
>> Ok so till a new document updates 2460bis any further work on EHs is 
>> frozen as it would reference 2460bis with new text. That was my main point.
> 
> I don't get the logic...an "update" can start immediately once such a 
> draft new proposal is available.  The update won't be formally 
> completed until it gets some formal state like a standard track RFC, 
> and it will take time, but that wouldn't necessarily mean a further 
> work is "frozen"; it's not very clear to me what this term means in 
> this context, but it's quite common development takes place while the 
> spec is being discussed as a draft, and it's also not uncommon some 
> commercial operators even start deploying it.  On the other hand, even 
> if we now agreed that rfc2460bis should explicitly allow such "further 
> work", the discussion itself would take long and wouldn't be completed 
> soon.
> 
> But IMO it's irresponsible to leave the text ambiguous and let some 
> other people misunderstand it, possibly even more casually and/or in 
> the global Internet, for the comfort of some particular future work.
> I think we're now trying to help avoid the latest clarification in 
> rfc2460bis to be interpreted as an "outright ban" of future updates 
> while still trying to be responsible for the soundness of the global 
> Internet.  In my understanding Brian's additional text is one such 
> attempt (I also proposed text in that sense at the time of WGLC, 
> although it wasn't adopted in the end).  If that text is still not 
> enough we can discuss how to phrase it.  And, while I suspect people 
> who wanted to keep the ambiguity will never be satisfied with the 
> result as long as the added clarification remains, I believe that's a 
> reasonable compromise to achieve a balance between being responsible 
> and not (unintentionally) discouraging future updates.

Repeating what I said at the mic, my views echo those of Jinmei, Michael, Lorenzo and Brian. I agree with the decision to progress RFC2460-bis to IS including Suresh’s text. I’d also like to see Brian’s short amendment included, which makes explicit Internet scope as the default target.

Advancing 2460bis doesn’t freeze work on SR; that work can continue today. I don’t see the new SR header insertion draft completing in “a couple of weeks”; it’s much more likely to take several months or even a year to progress through WG adoption and eventual publication, to ensure good and robust input. For adoption, I’d expect many people to want the draft to include text on a) why vanilla encapsulation is not sufficient and b) how the insertion can guaranteed to be done safely for specific scenario(s). But that’s all very possible.

And please do note that publishing 2460-bis as an Internet Standard does not set it in stone. Your SR work can update it, as could other future RFC(s) on other new mechanism(s) or innovation(s) that have yet to be proposed. I’d argue that it’s pretty likely we’ll see other RFCs update 2460-bis; that shouldn’t be a surprise if it’s a protocol that we’ll be using for the next 20-30 years or more. For each, we’ll just see “Updated by:” tags in the RFC header. The current RFC2460 has accumulated nine such tags in 19 years, so about one every two years.

On enterprise deployment I’d argue that, if anything, moving to IS should help strengthen the case for deployment, because it confirms proven widescale deployment.  The four criteria for moving to IS are described in Section 2.2 of RFC6410, but are summarised as "a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community”. I’d hope we have very strong consensus on that statement.

Tim
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.