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

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

Return-Path: <jmh@joelhalpern.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9801293DC for <ietf@ietfa.amsl.com>; Tue, 14 Feb 2017 08:24:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 HkaMlWYzCzgm for <ietf@ietfa.amsl.com>; Tue, 14 Feb 2017 08:24:16 -0800 (PST)
Received: from mxb2.tigertech.net (mxb2.tigertech.net [208.80.4.164]) (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 BEE0F129641 for <ietf@ietf.org>; Tue, 14 Feb 2017 08:24:16 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 9FC3532BAF7; Tue, 14 Feb 2017 08:24:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; 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 b2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (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 <brian.e.carpenter@gmail.com>, otroan@employees.org
References: <148599296506.18647.12389618334616420462.idtracker@ietfa.amsl.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> <m2y3xdpmjd.wl-randy@psg.com> <5333378B-0F8D-4966-82B2-DFF9639CEC7D@fugue.com> <3a180e40-936b-956b-9fc3-5ecdd4d905ee@gmail.com> <m2poippisc.wl-randy@psg.com> <13830253-67ab-cb26-4fa0-f40a24f1a5bc@gmail.com> <76D87C97-1ECB-4E92-8FE7-ADAF464DB8FD@employees.org> <a0aaa86f-db08-4363-f9c6-0b55ceadc3b9@gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <48b1988d-2074-3e60-62ba-5943e6ec8b91@joelhalpern.com>
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: <a0aaa86f-db08-4363-f9c6-0b55ceadc3b9@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/rTzoO5XB-c5KeRvBflciddjst-E>
Cc: IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=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.

Yours,
Joel

On 2/11/17 2:24 PM, Brian E Carpenter wrote:
> On 12/02/2017 01:36, otroan@employees.org 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
>
>