Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

"Eric Vyncke (evyncke)" <evyncke@cisco.com> Sun, 12 February 2017 20:56 UTC

Return-Path: <evyncke@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC8012943C; Sun, 12 Feb 2017 12:56:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 nPb7_iy7X29x; Sun, 12 Feb 2017 12:56:42 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C9C129A2E; Sun, 12 Feb 2017 12:56:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15100; q=dns/txt; s=iport; t=1486933002; x=1488142602; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GSdSXhBUZZ9e4ZeNfXzg3CDrfdn7ZnhwjXl0jqCPavo=; b=K2zomYUb7gziVbJyXUrneEIAdTizyXuTh/eDqXe2fPFww/8cAF0cinDb aoBcGkTkvi//ek8TKdpQvQjtUNp0IRSX80Kn/4Z+Azknsci5/Ie/iotma 7vFMmSUeKYSi4iLlUUxqWAYDR+ZVH++4EPXHtysSgWG4khWBEMvt4i5Cu Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DqAQBOy6BY/5xdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm86KWGBCQeDUooIkguIDId+hSyCDIYiAhqCYT8YAQIBAQEBAQE?= =?us-ascii?q?BYiiEaQEBAQMBI0sLBQsCAQYCEQMBAiQEAwICAh8RFAkIAgQBDQWJUgMNCJEqn?= =?us-ascii?q?U6CJSuGeQ2EEAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GTIIFgmqCUYIaCRaCUC6?= =?us-ascii?q?CMQWbODoBjXqEGZEFijWIXwEfOIEAURU9EQGEMx0ZgUh1iTOBDAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.35,154,1484006400"; d="scan'208,217";a="382769216"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Feb 2017 20:56:41 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v1CKufPg013975 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 12 Feb 2017 20:56:41 GMT
Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 12 Feb 2017 14:56:40 -0600
Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1210.000; Sun, 12 Feb 2017 14:56:40 -0600
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: Suresh Krishnan <suresh.krishnan@gmail.com>, =?utf-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
Thread-Topic: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
Thread-Index: AQHSfOX4BXu17vCOlEW5Zvc01+W9PaFVw50AgAEB4YCAAInqAIAH3A5rgABc74CAAVJ4AIAAtouAgAFd/wCAANalgIACmaqA
Date: Sun, 12 Feb 2017 20:56:40 +0000
Message-ID: <5CE4B4BF-75A9-4DC9-80AE-220281B046E9@cisco.com>
References: <148599296506.18647.12389618334616420462.idtracker@ietfa.amsl.com> <30725d25-9829-bf50-23c6-9e1b757e5cba@si6networks.com> <7ee506c2-4213-9396-186a-2b742c32f93b@gmail.com> <EA7E5B60-F136-47C6-949C-D123FB8DA70E@cisco.com> <00af01d27e11$fe539500$4001a8c0@gateway.2wire.net> <60F01869-8B32-46D3-80B1-A140DF1DDA8A@employees.org> <8D401C5B-C3C3-4378-9DFA-BF4ACC8E9DAF@qti.qualcomm.com> <D2D907D5-84B4-43BB-9103-F87DA9F122EB@employees.org> <33DC7B74-D240-4FF2-A8FF-C9C5A66809EE@qti.qualcomm.com> <1179DE45-3971-44A1-9630-28F76D2D652D@employees.org> <2ea64b3c-d69d-6b6c-cb04-fe63727a8bee@si6networks.com> <23C46409-337C-468D-BCDC-34027BB56CAD@employees.org> <30715b9e-e9b7-320e-f9e2-fc3f64615d5c@si6networks.com> <CAJE_bqcKu1XVQOPzcd+8b68WcQyjH9QmszaSvKWhT8SvHJ0ppg@mail.gmail.com> <CA+MHpBrPGLebKj1XcSbuv8DyVTLWE_DpjHeZLzPpDBLg0sEpGA@mail.gmail.com>
In-Reply-To: <CA+MHpBrPGLebKj1XcSbuv8DyVTLWE_DpjHeZLzPpDBLg0sEpGA@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1e.0.170107
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.104.91]
Content-Type: multipart/alternative; boundary="_000_5CE4B4BF75A94DC980AE220281B046E9ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/7SYFvF3Eb-l9QVGQ5TLUFCtRq3w>
Cc: "6man@ietf.org" <6man@ietf.org>, IETF Discussion list <ietf@ietf.org>, Pete Resnick <presnick@qti.qualcomm.com>, Fernando Gont <fgont@si6networks.com>, "draft-ietf-6man-rfc2460bis@tools.ietf.org" <draft-ietf-6man-rfc2460bis@tools.ietf.org>, "6man-chairs@ietf.org" <6man-chairs@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Feb 2017 20:56:45 -0000

Suresh, Jinmei and Fernando,

I fully agree with you Suresh, the goal of an IETF last call is to get NEW discussion and to re-do the lengthy discussions we had on 6MAN WG.

-éric

From: ipv6 <ipv6-bounces@ietf.org> on behalf of Suresh Krishnan <suresh.krishnan@gmail.com>
Date: Saturday 11 February 2017 at 07:11
To: 神明達哉 <jinmei@wide.ad.jp>
Cc: "6man@ietf.org" <6man@ietf.org>rg>, IETF Discussion list <ietf@ietf.org>rg>, Pete Resnick <presnick@qti.qualcomm.com>om>, Fernando Gont <fgont@si6networks.com>om>, "draft-ietf-6man-rfc2460bis@tools.ietf.org" <draft-ietf-6man-rfc2460bis@tools.ietf.org>rg>, "6man-chairs@ietf.org" <6man-chairs@ietf.org>
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

Hi Jinmei,

On Feb 10, 2017 1:23 PM, "神明達哉" <jinmei@wide.ad.jp<mailto:jinmei@wide.ad.jp>> wrote:
At Thu, 9 Feb 2017 18:30:11 -0300,
Fernando Gont <fgont@si6networks.com<mailto:fgont@si6networks.com>> wrote:

While I largely agree with Fernando on everything he said, I have to
admit most of the points are just repeated from the 6man discussion,
and won't get us anywhere new by discussing these again at this point.
I guess the only new input for the IETF last call is this:

> 2) However, some folks came up with proposals to insert EH, on the basis
> that "RFC2460 does not explicitly ban EH insertion". If there's people
> arguing that, we clearly need to make this clear in the spec.
>
> 3) There was a consensus call, yes. When the call was made on the
> mailing-list, the vast majority of supporters of "let's keep the
> ambiguity" were folks from the same company as "2)". I have no idea if
> this changes (or not) "consensus"... but this is clearly an important
> datapoint.
Although I don't want to point a finger at particular people or
organizations without an evidence, I guess not a small number of 6man
participants (not only those who explicitly spoke up here) suspected
that the decision process was biased with the influence of a large and
powerful organization and the process and resulting "consensus" was
not really a fair one.  And I'm not an exception to it - in fact, it
was so unbelievable to me that we can't clarify an ambiguity even when
we were also open for future extensions, that I couldn't think of
other reasons than a company agenda.

Of course, it's quite possible that it was just a coincidence that
many people with the same organization genuinely thought we should
leave it ambiguous while many others strongly thought we should
clarify it but few (if not no) people from that organization supported
the clarification.  But I don't think we can prove it either way.

But as Fernando said, I believe this point (and that several, and
arguably more, participants suspected it) should be included in making
the decision at the IESG and at the IETF last call.  And, whatever the
decision, it would be more productive to move on after that and use
our time for some other things.

I am guessing that the people who spoke up during the WG process to not put in an outright prohibition would make their case along with their arguments here as well. We are only a week into a four week long last call.

Thanks
Suresh