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

神明達哉 <> Fri, 10 February 2017 18:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AFADF129A76; Fri, 10 Feb 2017 10:22:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8gWnuxRFcE6G; Fri, 10 Feb 2017 10:22:54 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E557129A6A; Fri, 10 Feb 2017 10:22:54 -0800 (PST)
Received: by with SMTP id 11so6145808qkl.0; Fri, 10 Feb 2017 10:22:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bwJmQqlVuFR/DJ/c5y0tUZGiTrQghZ5QZhNsLYPVTSw=; b=S1xDdUgoRbdBEkLAM9IOAc4nPrrXvRcAGXrGls4qN7/AYCV8fDgj3sYxHfXNjwBSqm o9Ebw91D8b46/qDMCzQ10/5YmVtfDXiQ46Q4W+swPQFdChK9msjpytEzRjMEYycTnKLG vLIhClv8S48ZUXUJIozSzMNZCZJGMJL0Iz0kNP3rDJvA55FI3DUzVS9MYsXEGO5lHfST HDQf1j2N6O+4KmCRZ+lNgAuLybcWc6aL+GQPp9QWUdfITY8glfY+h0/p6qoKauTd8xy7 0mZ3+XNy0DNZFmgsuOpeE11uWuzSjZW46M/a1MQVxWC1xnMN91rvNQ3KIbn0iH67jJg3 Xq9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=bwJmQqlVuFR/DJ/c5y0tUZGiTrQghZ5QZhNsLYPVTSw=; b=WqKeAFRVIyvZBb+2wRlPU0ffoLfz1OCl/qiGh/M1xE/DiEpKNrGlio1pWYF8nf1KRQ a+uL8+CK+NCoeqWxnfsD4TFJH6oH/gfXltdnzU+11xWiFCKsdnEC1Wu5Dp5/heS5wR/c ApnT5KqHnqtmt1TuWA791aW9eYJgrNTDPWlriolTYFXIAoIuPPb8Q6QOGOLFbZNKfCys Qk0/b1I1ufO5MHaK34Kcn3RJ8nG57HwE11I0dD8HJNEmoU4CN4l2chljC/pzdLPXFaJm ZpdGCH8d13ETZIFUqyzIsqDgtJuIE8DHOvlrn7wSKONW9AY7ceMeJAA65OC0Ks7XOG0i ku5Q==
X-Gm-Message-State: AMke39kxqyIdYpjsu2Fj0arYECLu2lH7aVsBj8MryHnsbWrptcWMwT4FhqaLYqtDSedS3xjNLBXNtdgc53vjhA==
X-Received: by with SMTP id u129mr9561770qkd.219.1486750973229; Fri, 10 Feb 2017 10:22:53 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 10 Feb 2017 10:22:52 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <00af01d27e11$fe539500$> <> <> <> <> <> <> <> <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Fri, 10 Feb 2017 10:22:52 -0800
X-Google-Sender-Auth: rpOfT7KMBZsFesInnOaCVehElnU
Message-ID: <>
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
To: Fernando Gont <>
Content-Type: text/plain; charset=UTF-8
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 18:22:56 -0000

At Thu, 9 Feb 2017 18:30:11 -0300,
Fernando Gont <> 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'll shut up here on this so I won't be a cause of another 600+ email

JINMEI, Tatuya