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

otroan@employees.org Thu, 05 December 2019 21:41 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 E7071120168; Thu, 5 Dec 2019 13:41:37 -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 SOW79Wp4QIXL; Thu, 5 Dec 2019 13:41:36 -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 4E32E1200EF; Thu, 5 Dec 2019 13:41:36 -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 968D64E11B71; Thu, 5 Dec 2019 21:41:35 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by astfgl.hanazo.no (Postfix) with ESMTP id 38EA8250FAE7; Thu, 5 Dec 2019 22:41:33 +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: <1e36a492-5931-02de-cf85-63339522b13a@si6networks.com>
Date: Thu, 5 Dec 2019 22:41:33 +0100
Cc: Ron Bonica <rbonica@juniper.net>, SPRING WG <spring@ietf.org>, 6man <6man@ietf.org>, "int-ads@ietf.org" <int-ads@ietf.org>, rtg-ads <rtg-ads@tools.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F6DD2C7C-DBBF-4B48-B890-3C86005FB9CF@employees.org>
References: <BN7PR05MB56998A05469327E759B5B671AE5D0@BN7PR05MB5699.namprd05.prod.outlook.com> <3AD3BD11-8C34-41FE-B88F-49A9F2561D78@cisco.com> <BN7PR05MB569946D6AA5C6B78AFC05F6BAE5C0@BN7PR05MB5699.namprd05.prod.outlook.com> <8DEDE597-B7B0-48F5-959E-69757315C2AC@employees.org> <BN7PR05MB56996FFC117F512EEA04AFC8AE5C0@BN7PR05MB5699.namprd05.prod.outlook.com> <4FAB68A3-C533-471D-94D0-3F6EB1F32FC1@employees.org> <1e36a492-5931-02de-cf85-63339522b13a@si6networks.com>
To: Fernando Gont <fgont@si6networks.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/szzJ-LCnJuSk8pylvP5Gmk3_StY>
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: Thu, 05 Dec 2019 21:41:38 -0000

Fernando,

>>> Point taken. Could you comment on the current state of WG consensus?
>> 
>> The working group session in Singapore ended with what appeared to be a view that we should continue work on both documents (Mark's and the Voyer draft).
>> For the state of the wg consensus, I haven't checked with Bob, but I think he will agree with it being classified as "evolving".
> 
> I polled you about this decision
> (https://mailarchive.ietf.org/arch/msg/ipv6/12Qwp_eeQT2EmbUrSxBLL5HTcnM), and
> you never responded.

Sorry, which decision is that supposed to be?

> Suresh (INT AD) clarified this one list, here:
> https://mailarchive.ietf.org/arch/msg/ipv6/Db6_SGfmeIDzaE56Ps5kUDCYEzY
> 
> Suresh noted that there wasn't consensus call, even at the f2f meeting
> (not to mention that the list was never polled in this respect).

Right, neither of these two documents are adopted as working group documents. And perhaps a more correct phrasing above would be that "The working group session in Singapore ended with what appeared to be a view that work could continue on both of these documents".

> I would say that it seems we have not been following the processes that
> should be followed. This has happened repeatedly over time, for this
> very same topic. The process seems to be biased, and thus unfair to the
> rest of the wg participants.

Which process are you talking about? Is that documented in an RFC?
You seem to take it on yourself to represent the "rest of the wg participants", but from my perspective it looks like a few very loud voices.
Perhaps we should let others speak up, if there is anything more to be said on this topic.

Ole