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

otroan@employees.org Fri, 06 December 2019 23:55 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 944C71200EF; Fri, 6 Dec 2019 15:55:53 -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 HTqaaaEi2Fhi; Fri, 6 Dec 2019 15:55:51 -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 31F47120073; Fri, 6 Dec 2019 15:55:51 -0800 (PST)
Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:47d8:c8b:f971:52ca:e1ba]) (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 528654E11AF5; Fri, 6 Dec 2019 23:55:50 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by astfgl.hanazo.no (Postfix) with ESMTP id 65459252ED36; Sat, 7 Dec 2019 00:55:47 +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: <eb101558-5106-c6ef-6007-3fb7673e9611@si6networks.com>
Date: Sat, 7 Dec 2019 00:55:47 +0100
Cc: 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>, Andrew Alston <Andrew.Alston@liquidtelecom.com>, rtg-ads <rtg-ads@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DA77DF83-D8E8-4561-B445-18D072922084@employees.org>
References: <f2a0ad13-0eba-6f5a-1d3c-e45e2780f201@si6networks.com> <D666EA6E-E8E9-439A-9CDE-20857F03CB65@employees.org> <eb101558-5106-c6ef-6007-3fb7673e9611@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/okW-qTZLpFoomE8WyIMuZ7NTnrY>
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 23:55:54 -0000

> * polling the mailing list instead of deciding (on your own) that the
> group wants to work on EH insertion, and,

Which decision are you referring to?
I have certainly never decided that working group wants to work on header insertion.

With regards to the documents, I believe I clarified the statement of the working group seeing no reason why both documents couldn't be continue to be worked on.
Those documents are not adopted, nor has any decision about adoption been made, nor is any adoption call of those documents planned.

I certainly don't want us as a group or myself personally to be working on header insertion.
You might not be alone, but you certainly keep repeatedly forcing the working group to consider the issue.

> * complying with existing specifications unless there's formal consensus
> for them to be formally updated.

I believe I have responded multiple times to this point.
I do not in principle see a conflict with specifying how header insertion can work in a specific case,
and the text in RFC8200. I would strongly oppose updating RFC8200, since header insertion is clearly
something that can only apply in specific use cases.

> As a 6man chair, I would expect that you would be doing exactly that
> yourself, as opposed to essentially suggesting the group is going to
> work on a document without polling the wg for adoption (particularly
> when the topic has been, at best, controversial), or encourage other
> groups to violate the same specs that this same wg produced.

I try to do the best job I can, and be fair, neutral, open and transparent.
That job is clearly not easy when this particular debate is as disruptive as it is.
You at least always have RFC2026, section 6.5.

Best regards,
Ole