IETF Logo Mail Archive

Re: Network Programming - Penultimate Segment Popping

otroan@employees.org Thu, 05 December 2019 20:57 UTC

Return-Path: <otroan@employees.org>
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 A4BB5120137; Thu, 5 Dec 2019 12:57:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 nK50J9vqxkr6; Thu, 5 Dec 2019 12:57:04 -0800 (PST)
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 006DD1200EF; Thu, 5 Dec 2019 12:57:03 -0800 (PST)
Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:47d8:c5ba:f887:5271:a211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 572E44E11AAA; Thu, 5 Dec 2019 20:57:03 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by astfgl.hanazo.no (Postfix) with ESMTP id 95BBC250DF0B; Thu, 5 Dec 2019 21:57:01 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Subject: Re: Network Programming - Penultimate Segment Popping
From: otroan@employees.org
In-Reply-To: <BN7PR05MB569946D6AA5C6B78AFC05F6BAE5C0@BN7PR05MB5699.namprd05.prod.outlook.com>
Date: Thu, 05 Dec 2019 21:57:01 +0100
Cc: "Darren Dukes (ddukes)" <ddukes@cisco.com>, SPRING WG <spring@ietf.org>, 6man <6man@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8DEDE597-B7B0-48F5-959E-69757315C2AC@employees.org>
References: <BN7PR05MB56998A05469327E759B5B671AE5D0@BN7PR05MB5699.namprd05.prod.outlook.com> <3AD3BD11-8C34-41FE-B88F-49A9F2561D78@cisco.com> <BN7PR05MB569946D6AA5C6B78AFC05F6BAE5C0@BN7PR05MB5699.namprd05.prod.outlook.com>
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/KRZMR5VZpj_myVpi1I0YNrEO5go>
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, 05 Dec 2019 20:57:06 -0000

Ron,

> Currently, there is no consensus that IPv6 allows insertion of extension headers by intermediate nodes, even if those intermediate nodes are segment endpoints . Given this lack of consensus, the authors of network programming have wisely agreed to remove header insertion from the draft.
>  
> Likewise, there is no consensus that IPv6 allows removal of extension headers by intermediate nodes, even if those intermediate nodes are segment endpoints. Why, then, have the authors of network programming not agreed to remove PSP from the draft?

With regards to working group process; may I gently remind you that it is the chairs that call consensus.

Best regards,
Ole

v2.23.0 | Report a Bug | By Email