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

Fernando Gont <> Fri, 10 February 2017 00:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 04A661295AD; Thu, 9 Feb 2017 16:29:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7_zfAVMtim8L; Thu, 9 Feb 2017 16:29:47 -0800 (PST)
Received: from ( [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D91A6129543; Thu, 9 Feb 2017 16:29:46 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 6764E81A4C; Fri, 10 Feb 2017 01:29:41 +0100 (CET)
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
References: <> <> <> <> <00af01d27e11$fe539500$> <> <> <> <> <> <> <> <> <> <> <>
From: Fernando Gont <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Thu, 09 Feb 2017 21:29:25 -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: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc:, IETF Discussion <>, Pete Resnick <>,,
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Feb 2017 00:29:48 -0000

On 02/09/2017 08:36 PM, wrote:
>>> I don't think it has. In fact, that's the whole point: some
>>> people have *not* deduced that rule from the RFC2460/RFC1883
>>> wording.
>> "It has always been clear.... till these proposals on EH insertion
>> arised".
>> Since some people didn't "deduce" it from the current text, that's
>> a clear indication that a clarification is warranted.
> You can now optimize this discussion without having to bother the
> whole IETF list. Just look up the counter arguments in the previously
> posted summary.

We're moving RFC2460 to full Standard. You have to make arguments to
*change* the spec, not to clarify what's already in there -- for
instance, ne would expect that part of the benefit of the process is to
clarify the spec where necessary.

If you can make enough of a case to enable EH insertion, then propose
that as what it actually is: a *modification* to the spec.

If we move RFC2460 to full Std without even being able to tell people
whether this is an end-to-end protocol or not, I think that would be a
*very* bad outcome.

Me, I'm done with this discussion. A number of us (Enno Rey, Mark Smith,
and others) have commented on our view on the topic (for IETF folks that
didn't participate in the 6man discussions).

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492