Re: [Technical Errata Reported] RFC8200 (5933)

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 13 December 2019 09:08 UTC

Return-Path: <alexandre.petrescu@gmail.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 34B00120115 for <ipv6@ietfa.amsl.com>; Fri, 13 Dec 2019 01:08:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level:
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] 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 UqzN65mvJZEU for <ipv6@ietfa.amsl.com>; Fri, 13 Dec 2019 01:08:52 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 838D61200CC for <ipv6@ietf.org>; Fri, 13 Dec 2019 01:08:52 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xBD98oIP048106 for <ipv6@ietf.org>; Fri, 13 Dec 2019 10:08:50 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E352D202C6E for <ipv6@ietf.org>; Fri, 13 Dec 2019 10:08:50 +0100 (CET)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D97CA202BF3 for <ipv6@ietf.org>; Fri, 13 Dec 2019 10:08:50 +0100 (CET)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xBD98ocl031219 for <ipv6@ietf.org>; Fri, 13 Dec 2019 10:08:50 +0100
Subject: Re: [Technical Errata Reported] RFC8200 (5933)
To: ipv6@ietf.org
References: <20191211032724.46F77F406F3@rfc-editor.org> <ead110b0-3198-2894-3c63-9362276b0cc4@gmail.com> <cffb0a8e-2119-a474-4dce-f3b5a67dac47@si6networks.com> <bfa67fe0-850d-941d-a446-559a2907da25@gmail.com> <4efde70d-e368-3b47-58c7-f7b5fb3c13d3@si6networks.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <ec1dd5b7-62ba-7eab-1f80-bf777f842614@gmail.com>
Date: Fri, 13 Dec 2019 10:08:50 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0
MIME-Version: 1.0
In-Reply-To: <4efde70d-e368-3b47-58c7-f7b5fb3c13d3@si6networks.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/sthqjBma8hZroo2R1iaAtQU8KbU>
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: Fri, 13 Dec 2019 09:08:54 -0000


Le 12/12/2019 à 06:45, Fernando Gont a écrit :
> On 11/12/19 23:22, Brian E Carpenter wrote:
>> Yes, a note that updating Segments Left is legal would fix it I think.
> 
> It would seems to me that more is needed. For instance, for RHT0 you had
> to swap the address in the Destination Address with  with the next
> segment in the RHT0 payload.
> 
> So I guess the text should look something like:
> 
>      A Routing Header is not inserted, or deleted by any node along a
>      packet's delivery path, until the packet reaches the final
>      destination node (or each of the set of final destination nodes, in
>      the case of multicast). A Routing Header is not processed by any
>      node along a packet's delivery path, until the packet reaches the
>      destination node (or each of the set of destination nodes, in the
>      case of multicast) identified by the Destination Address field of
>      the IPv6 header.
> 
> ?
> 
> I wonder if it might be better to keep the insertion/deletion part in a
> single place, to avoid repetiton, and then just discuss processing, but
> not insertion/deletion.

I think indeed the insertion/deletion part would deserve a single place 
for its own.  It should be clear by reading it in one place that 
intermediaries (routers in a 15 hop path in the Internet, exhibited by 
traceroute) do not touch a packet originated by an end node other than 
decrementing the Hop Limit and Segments Left, if present.

>  -- Or whether repetition is needed for each of
> the "special" EHs, such that folk do not assume that the comments on
> insertion/deletion do not applyto the "special" EHs.

Suffices it to say _all_ EHs in one place.  But then one has to define 
what is an EH.  'EH' is an acronym used exclusively in email 
discussions, currently.  I took it for an AH version when first saw it.

Alex

> 
> Thoughts?
> 
> Thanks,
>