Re: [spring] We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)

otroan@employees.org Fri, 06 December 2019 17:06 UTC

Return-Path: <otroan@employees.org>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AD712010E; Fri, 6 Dec 2019 09:06:20 -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 pnEeA3ujFhsT; Fri, 6 Dec 2019 09:06:19 -0800 (PST)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.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 27C111200A3; Fri, 6 Dec 2019 09:06:13 -0800 (PST)
Received: from astfgl.hanazo.no (246.51-175-81.customer.lyse.net [51.175.81.246]) (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 85BC34E11B2F; Fri, 6 Dec 2019 17:06:12 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by astfgl.hanazo.no (Postfix) with ESMTP id D3B262526BF5; Fri, 6 Dec 2019 18:06:10 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: otroan@employees.org
In-Reply-To: <CALx6S37r2JYbrMpN-qR3bD3kaOMj3xEceQC5JhVb8dqVzfq=5A@mail.gmail.com>
Date: Fri, 6 Dec 2019 18:06:10 +0100
Cc: Bob Hinden <bob.hinden@gmail.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, SPRING WG <spring@ietf.org>, 6man <6man@ietf.org>, "int-ads@ietf.org" <int-ads@ietf.org>, rtg-ads <rtg-ads@tools.ietf.org>, Fernando Gont <fgont@si6networks.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <06B50938-0FC6-4901-9531-CC0385185F13@employees.org>
References: <BN7PR05MB5699EA5F4C041538560282A6AE5F0@BN7PR05MB5699.namprd05.prod.outlook.com> <52132FA9-669E-4B32-BDC8-6F06C98315F3@gmail.com> <CALx6S37r2JYbrMpN-qR3bD3kaOMj3xEceQC5JhVb8dqVzfq=5A@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/bV-zuR48peTGkhfkSdh-Ob9z5z0>
Subject: Re: [spring] We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2019 17:06:21 -0000

Tom,

> The advice from the chairs seems to be continue discussion. The
> problem with that is that EH insertion has been discussed ad nauseum
> over the past two years since the draft first appeared. It seems like
> we are at the point where the same arguments on the topic are just
> being rehashed on the list. As you mention above, the current
> consensus is that the EH insertion conflicts with RFC8200. Right now
> it seems like further discussion is open ended and without any
> constraints a likely outcome will be attrition and eventual
> acquiescence to accepting yet another non-conformant protocol that
> became so widely deployed so that it can be fixed.
> 
> In light of this, can the chairs or AD provide some guidance or
> expectations on framing any further discussion on the topic to ensure
> that it's productive and the process is moving forward.

You should absolutely continue the discussion.
Let me share a secret with you. Please don't share.
The 6man working group has been tasked by the IETF leadership to
ensure engaging discussions all year around.
I have not been told the hidden establishment agenda behind this,
but I can only presume that it is to keep the IPv6 enthusiasts
away from affecting the real work being done in other areas of the IETF.

The leadership has tasked us with circulating the discussions between the following topics:
 - 64 bit boundary
 - M/O bits
 - ULA or not ULA
 - Extension headers
 - Defining new mechanisms for IID formats

There is a scheduled switch to the M/O bits topic in mid January.
Please continue to the good work on EH in the meantime.

Ole