Re: Errata #5933 for RFC8200

Fernando Gont <fgont@si6networks.com> Thu, 27 February 2020 23:04 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 5CAD23A046A for <ipv6@ietfa.amsl.com>; Thu, 27 Feb 2020 15:04:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 E4zbMestZ3Kc for <ipv6@ietfa.amsl.com>; Thu, 27 Feb 2020 15:04:44 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8FB3A07F5 for <6man@ietf.org>; Thu, 27 Feb 2020 15:04:44 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (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 832E582A18; Fri, 28 Feb 2020 00:04:39 +0100 (CET)
Subject: Re: Errata #5933 for RFC8200
To: Suresh Krishnan <suresh.krishnan@gmail.com>
Cc: "6man@ietf.org" <6man@ietf.org>
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <0753535F-CBE0-4EC9-9FA9-03E036D0F660@gmail.com> <fbda8743-b794-7170-015b-5c5a832d2b19@si6networks.com> <1220E468-1E57-4B93-A14B-783F6CA28E92@gmail.com> <08e2d74c-c124-a3bf-760b-27c54a8c64a6@si6networks.com> <D83ABC52-ADEE-4498-8E2A-705F4517C169@gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <c765cb1c-bc80-1475-0e91-938728f23529@si6networks.com>
Date: Thu, 27 Feb 2020 20:04:32 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <D83ABC52-ADEE-4498-8E2A-705F4517C169@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/NFkJx1pQOiIjDiuYhSjW2pDjnvg>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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, 27 Feb 2020 23:04:53 -0000

On 27/2/20 19:47, Suresh Krishnan wrote:
> Hi Fernando,
> 
>> On Feb 27, 2020, at 5:31 PM, Fernando Gont <fgont@si6networks.com>
>> wrote:
>> 
>> On 27/2/20 19:19, Suresh Krishnan wrote: [....]
>>>> 
>>>> Just to be clear, I believe that your stated decision of
>>>> processing this errata as "Hold for document update" is not
>>>> only incorrect, but also doesn't represent the consensus this
>>>> working group got during the rfc2460bis effort -- now RFC8200.
>>>> 
>>>> It is also unfortunate to have a second instance of this,
>>>> because, at the time the same group was pushing other IPv6
>>>> insertion/removal ideas, I also objected 6man shipping
>>>> rfc2460bis as such. And we only got to improve on that during
>>>> IETF LC.
>>>> 
>>>> As such, I will formally Appeal your decision.
>>> Please do go ahead. I stand by my assessment that this is a
>>> misuse of the Errata process and it is not a simple clarification
>>> as you claim.
>> 
>> For the third time, may I ask:
>> 
>> Can you please, as AD, answer these questions:
> 
> Personally, it is immaterial what I think as AD but I will answer
> your question below. The issue I have is you are claiming the WG had
> consensus on your proposed text while I clearly remember the
> consensus was extremely tenuous and I cannot make a determination
> *today* if the WG could have formed consensus around this text at
> that time. Please do read the shepherd writeup on RFC8200 to see how
> difficult the current text was to achieve.

There was IETF-wide consensus regarding the clarification. There were 
folks that meant to pretend that the text was ambiguous, simply to 
prepare some playground for what we are having nowadays.

IPv6 never supported header insertion/removal. So we were not proposing 
new behavior. Just making the existing behavior clear.



>> * Does IPv6 support IPv6 header insertion/removal along the packet
>> delivery path?
> 
> No. I would not implement that personally as I believe in the
> strictest reading possible (Postel principle: “Be conservative in
> what you do…”) but I can see how somebody can have a more liberal
> interpretation of it.

Exactly. In fact, Bob himself noted that a while ago (could dig the 
email archive, if you wish).

NOw, if IPv6 has never meant to support that, and folks pretend to claim 
that it does, the clarification is warranted.

That's what the errata I've submitted is all about.

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