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

Fernando Gont <fgont@si6networks.com> Thu, 09 February 2017 21:30 UTC

Return-Path: <fgont@si6networks.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 44811129478; Thu, 9 Feb 2017 13:30:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 BsoC_vkIKA-9; Thu, 9 Feb 2017 13:30:17 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1F8129455; Thu, 9 Feb 2017 13:30:16 -0800 (PST)
Received: from [192.168.3.83] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 146FE80EA4; Thu, 9 Feb 2017 22:30:11 +0100 (CET)
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
To: otroan@employees.org
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>
From: Fernando Gont <fgont@si6networks.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <30715b9e-e9b7-320e-f9e2-fc3f64615d5c@si6networks.com>
Date: Thu, 9 Feb 2017 18:30:11 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <23C46409-337C-468D-BCDC-34027BB56CAD@employees.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/5nZXbLEwjx2WwA67269fJ0OAlzw>
Cc: 6man@ietf.org, IETF Discussion <ietf@ietf.org>, Pete Resnick <presnick@qti.qualcomm.com>, draft-ietf-6man-rfc2460bis@tools.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: Thu, 09 Feb 2017 21:30:18 -0000

On 02/09/2017 07:36 AM, otroan@employees.org wrote:
> Fernando,
> 
> Pete asked me to summarize the objections to option 1 - banning header insertion explicitly.
> I responded with the set of objections I've heard for all options, as I couldn't see a straightforward way of only summarising for option 1.
> 
> I don't understand your message.
> Do you disagree with the summary itself? Are there arguments missing?
> Or is your grief that the I have distilled the arguments wrongly or put them in a bad light?
> 
> Or are you just rehashing your position on the issue?

I think that some points are not as clear as they should be:

1) The current state of affairs with respect to IPv6 EH insertion is
that insertion is forbidden. It has always been clear to everyone.

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.

4) Given "1)" and "2)" above, it should be evident that the spec needs
to be crystal-clear on this topic.

5) Arguing in favor of keeping ambiguity in a spec that has generated
600+ messages in the very group that standardizes the protocol pretty
much reads like "Let's publish a lousy spec!". And I think that would be
very bad. We're talking about something that is at the core of the
protocol, essentially "Is IPv6 an end-to-end protocol?". I would expect
rfc2460bis to answer such a very basic question, and I'm curious how we
could move a spec to (full) Standard without answering such a basic
question.


There's no grief at all. If anything, just a concern that some of these
items might not be clear enough, and, in particular that without the
datapoint in "3)", folks might get a misleading interpretation of the
discussions that happened in th wg. "3" could be read pretty much like
"all folks from the same company that has a proposal to insert EHs what
insertion of EHs to be allowed".

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492