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

"Joel M. Halpern" <> Tue, 14 February 2017 16:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC9801293DC for <>; Tue, 14 Feb 2017 08:24:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HkaMlWYzCzgm for <>; Tue, 14 Feb 2017 08:24:16 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BEE0F129641 for <>; Tue, 14 Feb 2017 08:24:16 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FC3532BAF7; Tue, 14 Feb 2017 08:24:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=1.tigertech; t=1487089456; bh=VZpW9uZAtoxXNnwzygzqC7kW50HouYiNd6nVDDj3x54=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=beiuTsk9aBksmUyIeFCfnV1WphisDD6lIkLW9s9uz+yYYYwdnoyGMJEb78QRxLEU5 /UroLj2gQMlt8IkrWt/Cd2JcKddtm7rB05fAaVKYJeYHs6AqbhzrVqnZwXXjg0zfW/ Z9t0r/EvvzinpQq9Wr7++5TAWDRwZ9EIDvp783GM=
X-Virus-Scanned: Debian amavisd-new at
Received: from Joels-MacBook-Pro.local ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id F06F132BAF6; Tue, 14 Feb 2017 08:24:15 -0800 (PST)
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
To: Brian E Carpenter <>,
References: <> <> <00af01d27e11$fe539500$> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Tue, 14 Feb 2017 11:24:15 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: IETF discussion list <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Feb 2017 16:24:17 -0000

I want to reinforce this.

There are two separate but related issues here.  One is what behavior we 
want to require.  The other is whether we make the document clear.

I think choosing to leave a document going to Internet Standard 
ambiguous is a serious mistake, bordering on failure.  We know that the 
choice of permitting insertion of extension headers has interoperability 
implications.  There are weveral ways we can clarify the text.
o We could say "MUST NOT" be added.  Preferably with explaantion of the 
problems being avoided.
o We could say "MUST NOT unless some other standards track RFC says it 
is okay" which is technically correct but confusing.
o We can say "SHOULD NOT unless ..." as long as we can write a clear 
description of the conditions under which it is safe.
o We can say "AMY< but note that doing so has the following risks" if 
that is the IETF rough consensus.

But leaving it ambiguous ought to be a non-starter.

Personally, I would go with "MUST NOT", as I think that is the robust 
and interoperable answer.  But that is MUCH less important to me than 
our being unambiguous.


On 2/11/17 2:24 PM, Brian E Carpenter wrote:
> On 12/02/2017 01:36, wrote:
>> Brian,
>>>>> If people who were not involved in the 6man debate have opinions, it
>>>>> would be useful to hear from them. I agree that there is no point in
>>>>> the same people repeating the same arguments.
>>>> in the absence of a (somewhat unbiased) summary of the critical
>>>> issues(s), what do you suggest?
>>> I was going to say this off list, but what the heck?
>>> To be honest I'm trying to stay quiet. I think I've made my opinion
>>> plain, and although I am of course the only human being alive who doesn't
>>> suffer from confirmation bias, I'd *really* like to hear what people
>>> think whose opinion I haven't already heard 20 times.
>>> I try not to be a purist. If the right answer is to allow packet
>>> modifications that break PMTUD and IPsec/AH, let's do it, but let's
>>> also say we're doing it. (I happen to think it's the wrong answer,
>>> but that's my problem.) Leaving the text open to interpretation
>>> would make a mockery of promoting it to Standard.
>> This is really not the discussion we ought to be having.
>> "Allowing" or in any way specifying how header insertion could possibly be made to work is far outside of the scope of advancing 2460 to Internet standard.
> If so, how can it be OK to leave the text ambiguous?
>     Brian