Re: Errata #5933 for RFC8200

Suresh Krishnan <> Thu, 27 February 2020 22:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0541E3A0DBE for <>; Thu, 27 Feb 2020 14:19:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 XprT6LWDWqNn for <>; Thu, 27 Feb 2020 14:19:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::c2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 29D963A0E39 for <>; Thu, 27 Feb 2020 14:19:21 -0800 (PST)
Received: by with SMTP id t141so1223029ywc.11 for <>; Thu, 27 Feb 2020 14:19:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cjqCYykBfxeKipDPzeZBVUvcMx0Rx5UxuIVKn0cm/sY=; b=Ap3VfjkWySRZE2mbZgTagoMRaX8/YhMNPNhZNEmiq94UUiJGDV6rM0+NQFK0qSulQo e+J8RpQgJiqbgEtv/1MEJZNOinkx9FRSS50S1nsVyaRt/9hS6010X7iZq7hHO7PeC7nH cRLSm+UWSZhjTvOeHrTY3UB4eYsM+kofvTTW27raN30zbBiWEtVnc7DrPnQ7KoZ2KVIA UCkFFzY8VBAVsax7lSHqjCfv9CoBenpzLUMqld5I3XZZ84kAquYN3GKDhwtxQbA33U9B FevuJtbc5zScjnOjbkbbBR3M0o2/nAVjkmiaj+kzZxowS8oyW9+EcZUpOcFhHDznYmZY 3ZWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cjqCYykBfxeKipDPzeZBVUvcMx0Rx5UxuIVKn0cm/sY=; b=BKh7zQ90Y7c60gwL7qsryE5CTt+3xnlBDf9tGJlyF4rdk/+d196hhjwHtnLazeks/z 6Dd9R8vWHi8vWJTeKBfIh/aCzeI7xTHM3VrmpJUiLfQbadieD2W2E5zAf6W9jeWE5BGZ rmLJe3azcvOrNtN8cVbe5469g5A5/lhmK7R3C+xjpWH4YXrJpvP3yj0gdNpauIglLjxa PlfrsW79Hu2qHb5kQs0sJb19I781Hz90kb38BYHnGHQahGJQyI+/6gxjnCO6WH4eA8Y1 he1JNMFvkWtVwDInUrfJ5ZKy+F22YovWmi9QfBNYvtZ9WOAFWx6A4zLBUh8RmhnCMONo Vc0Q==
X-Gm-Message-State: APjAAAVHIBRQld69wu7N/Y4muTFeaxeM+odEtHlRkt92he5VVfeH0Ryh vON+DFT+auSSKx8dsQmMd5uCS3yS
X-Google-Smtp-Source: APXvYqyi2t6pLTPFgMP5mTH7mw9vSvl3bPQg6TY/DXFHlBOaWQ3rKuHjp3IMefwewI9BcW1XagG5LQ==
X-Received: by 2002:a81:3a06:: with SMTP id h6mr1613607ywa.170.1582841960296; Thu, 27 Feb 2020 14:19:20 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id q2sm1533958ywh.71.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Feb 2020 14:19:19 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
Subject: Re: Errata #5933 for RFC8200
From: Suresh Krishnan <>
In-Reply-To: <>
Date: Thu, 27 Feb 2020 17:19:19 -0500
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Fernando Gont <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Feb 2020 22:19:29 -0000

Hi Fernando,

> On Feb 27, 2020, at 5:08 PM, Fernando Gont <> wrote:
> On 27/2/20 18:32, Suresh Krishnan wrote:
>> Hi Fernando,
>>> On Feb 27, 2020, at 3:07 PM, Fernando Gont < <>> wrote:
>>> Suresh,
>>> Two months ago I filled an errata on RFC8200 regarding the processing of IPv6 extension headers. The errata is available here:
>>> While I believe that folks with a knowledge of Internet Protocols would be able to interpret what is in RFC8200, given recent discussions on the topic, and upon a re-read of the text, I believe a clarification is warranted, such that we allow all sorts of curious interpretations of the text.
>> I think this would be fine to clarify, but IMHO the errata process is not the right way to do it.
>> Based on the IESG Statement about processing of RFC Errata for the IETF Stream (
>> "Changes that modify the working of a protocol to something that might be different from the intended consensus when the document was approved should be either Hold for Document Update or Rejected. Deciding between these two depends on judgment. Changes that are clearly modifications to the intended consensus, or involve large textual changes, should be Rejected."
> The intent of the spec is on the spec itself:
> Appendix B:
>   o  Clarified that extension headers (except for the Hop-by-Hop
>      Options header) are not processed, inserted, or deleted by any
>      node along a packet's delivery path.

Correct. This was to clarify the "extension headers are not examined or processed by any node” text in RFC2460 which some people claimed would allow insertion and deletion. And the right way to do that was to do exactly as we did. Waited for the revision of RFC2460 and get WG consensus to make the change. If you had submitted an Erratum on RFC2460 to make the same change on RFC2460 we would have had the same result.

> Routing Headers, for instance, are specified as:
> 4.4.  Routing Header
>   The Routing header is used by an IPv6 source to list one or more
>   intermediate nodes to be "visited" on the way to a packet's
>   destination.
> 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.