Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
"Leddy, John" <John_Leddy@comcast.com> Sun, 12 February 2017 23:05 UTC
Return-Path: <John_Leddy@comcast.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 3A83612945D; Sun, 12 Feb 2017 15:05:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 4HgiFchWh_3B; Sun, 12 Feb 2017 15:05:54 -0800 (PST)
Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) (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 F1697126D74; Sun, 12 Feb 2017 15:05:53 -0800 (PST)
X-AuditID: 60721c4c-61fff70000007eaf-74-58a0ea4efafd
Received: from VAADCEX47.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by (SMTP Gateway) with SMTP id F4.BE.32431.E4AE0A85; Sun, 12 Feb 2017 18:05:52 -0500 (EST)
Received: from VAADCEX41.cable.comcast.com (147.191.103.218) by VAADCEX47.cable.comcast.com (147.191.103.224) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 12 Feb 2017 18:05:49 -0500
Received: from VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268]) by VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268%19]) with mapi id 15.00.1263.000; Sun, 12 Feb 2017 18:05:49 -0500
From: "Leddy, John" <John_Leddy@comcast.com>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, Suresh Krishnan <suresh.krishnan@gmail.com>, 神明達哉 <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//+vlgA=
Date: Sun, 12 Feb 2017 23:05:49 +0000
Message-ID: <A823FD1C-4ED8-4788-81F0-0F672F1FA364@cable.comcast.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> <5CE4B4BF-75A9-4DC9-80AE-220281B046E9@cisco.com>
In-Reply-To: <5CE4B4BF-75A9-4DC9-80AE-220281B046E9@cisco.com>
Accept-Language: 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: [68.87.29.11]
Content-Type: multipart/alternative; boundary="_000_A823FD1C4ED8478881F00F672F1FA364cablecomcastcom_"
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsWSUOxpoRvwakGEwaadFha7p0xjs1i54i6T xe5FPawWX/YvYLR4tnE+i8Wi3QfYLK5cbWG2OLLhLKsDh8eU3xtZPXbOusvusWTJTyaPRVOf MXp8ufyZzWPv02NsAWxRXDYpqTmZZalF+nYJXBktT1ezFPyZx1hxu6+DrYHx9izGLkZODgkB E4kT7ROZuhi5OIQEZjJJXOhexAzhHGKU2HT0CAuEc5JR4vyEL2AtbAI6EjOmXWMFSYgITGCU uL7hA1g/s0Azk8TU76fZQRxhgTZGiakXnjJClLUzSqxr+cEK0i8iUCbx7doEJhCbRUBV4nDn djCbV8BF4t+UXWwQC5eyS1yY/YsFJMEpYCsxp7cTrIhRQEzi+6k1YDazgLjErSfzmSD+EJBY suc8M4QtKvHy8T+wZaICehIbL0xjh4jrSJy9/gTqbwOJrUv3Ac3nALLlJT7OZQIxmQXSJZ6u cIM4R1Di5MwnLBDV4hKHj+xgncAoOQvJ4lkIHbOQdECENSXW79KHqFaUmNL9kB3C1pBonTMX ynaQuNvUx4isZgEjxypGubLExJTk3Iz80hIDI73kxKScVL3k/NzkxOISEL2JEZRmimR8djB+ muZxiFGAg1GJhzfr5oIIIdbEsuLKXGDEcTArifAufAgU4k1JrKxKLcqPLyrNSS0+xCjNwaIk zpt0aEaEkEB6YklqdmpqQWoRTJaJg1OqgdGe6Ui03f9b9y8I50hd+7w+wKLz8PMr7y7rPF/4 dmYK71OnfTrPpR5npnfNTDpqtsbgxreQC29UHSbd3mjtWJFvmpBn7Dm7aMph/l1NC3XXv35x k5tlucm5x3MPm+dqerW9mibwvUu57LRf0YoUBsXXldK39bYsSBJm2mkZu2Xer4N+HgoLCiSV WIozEg21mIuKEwFnM2eSLwMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/KERaIFvlMFLFhCIZ1oPlXiaoAcI>
Cc: "draft-ietf-6man-rfc2460bis@tools.ietf.org" <draft-ietf-6man-rfc2460bis@tools.ietf.org>, Pete Resnick <presnick@qti.qualcomm.com>, "6man@ietf.org" <6man@ietf.org>, IETF Discussion list <ietf@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 23:05:56 -0000
I’m trying to understand how a ban of this functionality would work. Is it targeted at vendor products, precluding them from implementing the functionality? If there is a technical problem that can be solved by using EH insertion within a domain where there are no harmful side effects, it should be able to be used. In a software networking world where functionality is being deployed that is not from traditional network vendors; solutions that solve problems efficiently will get deployed. John Leddy From: ietf <ietf-bounces@ietf.org> on behalf of "Eric Vyncke (evyncke)" <evyncke@cisco.com> Date: Sunday, February 12, 2017 at 3:56 PM To: Suresh Krishnan <suresh.krishnan@gmail.com>, 神明達哉 <jinmei@wide.ad.jp> Cc: "6man@ietf.org" <6man@ietf.org>, IETF Discussion list <ietf@ietf.org>, Pete Resnick <presnick@qti.qualcomm.com>, "draft-ietf-6man-rfc2460bis@tools.ietf.org" <draft-ietf-6man-rfc2460bis@tools.ietf.org>, "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 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>, 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> 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
- Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (I… The IESG
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Brian E Carpenter
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Brian E Carpenter
- RE: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Manfredi, Albert E
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Stefano Previdi (sprevidi)
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… C. M. Heard
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… 神明達哉
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Brian E Carpenter
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Suresh Krishnan
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Pete Resnick
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Enno Rey
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… otroan
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… otroan
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Brian E Carpenter
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… otroan
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Philip Homburg
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… 神明達哉
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Randy Bush
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Ted Lemon
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Randy Bush
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Scott Bradner
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Suresh Krishnan
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Eric Vyncke (evyncke)
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Leddy, John
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Brian E Carpenter
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Mark Smith
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Tal Mizrahi
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Mark Smith
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… t.petch
- RE: [EXT] Re: Last Call: <draft-ietf-6man-rfc2460… Tal Mizrahi
- RE: [EXT] Re: Last Call: <draft-ietf-6man-rfc2460… David Mozes
- Re: [EXT] Re: Last Call: <draft-ietf-6man-rfc2460… Brian E Carpenter
- Re: [EXT] Re: Last Call: <draft-ietf-6man-rfc2460… Mark Smith
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Sander Steffann
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Sander Steffann
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Address types [was: Last Call: <draft-ietf-6man-r… Brian E Carpenter
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Erik Kline