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

Fernando Gont <fgont@si6networks.com> Fri, 06 December 2019 21:09 UTC

Return-Path: <fgont@si6networks.com>
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 D8BA612006B; Fri, 6 Dec 2019 13:09:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 5IjEr6BmULtV; Fri, 6 Dec 2019 13:09:23 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4561A120074; Fri, 6 Dec 2019 13:09:23 -0800 (PST)
Received: from [192.168.4.77] (unknown [190.179.35.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 21A17852B6; Fri, 6 Dec 2019 22:09:16 +0100 (CET)
To: otroan@employees.org, Andrew Alston <Andrew.Alston@liquidtelecom.com>
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>, Bob Hinden <bob.hinden@gmail.com>, rtg-ads <rtg-ads@ietf.org>
References: <BN7PR05MB5699EA5F4C041538560282A6AE5F0@BN7PR05MB5699.namprd05.prod.outlook.com> <52132FA9-669E-4B32-BDC8-6F06C98315F3@gmail.com> <CALx6S37r2JYbrMpN-qR3bD3kaOMj3xEceQC5JhVb8dqVzfq=5A@mail.gmail.com> <06B50938-0FC6-4901-9531-CC0385185F13@employees.org> <CALx6S35Y0LgwHzBawJUQEyYcRULgSVsRLCW0f35aqsrjX5QasA@mail.gmail.com> <1CEE1555-3D12-4998-9C69-23757649E908@employees.org> <22D9177B-033C-4657-96BA-FC6579918507@liquidtelecom.com> <CCBD1E90-D36D-42A8-8097-1CD8AC02A8C2@employees.org>
From: Fernando Gont <fgont@si6networks.com>
Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA==
Message-ID: <f2a0ad13-0eba-6f5a-1d3c-e45e2780f201@si6networks.com>
Date: Fri, 6 Dec 2019 18:08:59 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1
MIME-Version: 1.0
In-Reply-To: <CCBD1E90-D36D-42A8-8097-1CD8AC02A8C2@employees.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/Xdiy1rGfXioAtQGxwY13MUTXnqA>
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 21:09:27 -0000

On 6/12/19 16:42, otroan@employees.org wrote:
> 
>> While I may agree with you that is an attack on process here – and you may even find consensus on that statement – I am far from convinced you would find consensus on the question of which group is conducting the attack on process.
> 
> From https://mailarchive.ietf.org/arch/browse/ipv6/?qdr=m&so=frm
> 
> The last month's 10 top posters are:
> Fernando: 25
> Ole:      17 (including this message :-))
[....]

I don't think there is much room for interpretation here, but anyway I
should ask: are you suggesting that I have attacked or been attacking
the process? -- that's quite a statement from a wg chair to a wg
participant. And if not, I wonder what you are trying to illustrate with
the posted stats.


While one may or may not like loud folks, I'm not sure there's much
process specified in that respect. We do have, however, a process that
involves things like "doing a wg call for adoption in order for a wg to
work on a document", or even "make decisions on the mailing list".

What triggered the subject of this thread was, indeed, the fact that you
were implying that 6man had made a decision to work on EH insertion,
without a call for adoption of the relevant document, and without the
list given the chance to have an opinion.

Similarly, we have IETF consensus on what's in RFC8200. You may like it
or not. It may be good or not. But that's the consensus that we have.
But then you start with your rationale about limited domains (for which
there's no consensus) as an argument for folks being able to violate our
*That* is what I would deem as an attack of the process.

The above, that is, not having the wg make the decisions, and finding
ways to violate existing spec without following the due process, is what
would seem to me as an attack to the process.

As someone that is very involved in 6man, that tries to follow the
process as closely as possible, of course I've been loud on the topic.
The above has a lot to do with the fairness environment in which we are
operating, and remaining silent about it would be part of the problem.

You are a 6man wg chair. What I have been trying hard to is for the
decisions to be taken by the wg in a fair way (e.g. when it comes to a
decision to work on a document), and for the existing specs to be
respected and complied with unless there's formal consensus not to
change the specs.

Is being loud about that "attacking the process"? Or is that actually
that should simply happen without any participant asking, anyway?

Other than the theories of "proxy wars" do you've mentioned... have you
considered that there might be a conflict of interests going on, here?
e.g. between the working group consensus and a vendor's agenda?  As
chair, it is the wg that you serve.


We have been a long way when it comes to SRv6. It can be summarized to
include things like:

* When it comes to EH-insertion, rather than come up with a proposal to
say "hey, we want to change the standard, and this is the reason why",
there have been all sorts of manipulations of different kinds.

*  The first one being the claim that there was ambiguity in RFC2460
related to EH-insertion. Which, of course, everyone knew wasn't true.

* But, given the discussion, a number of us suggested that it should be
made even more crystal clear. Even after the insistence of many of us,
6man managed to ship rfc2460bis with such "ambiguity" in, simply because
a large number of folks (from the same vendor with a strong interest in
doing EH insertion), popped up on the list to move things forward "as
is". I did note this to Suresh at the time.... but the document shipped,
anyway.

* An heterogeneous group of folks (Jinmei, Enno, myself, Mark, and
others) weighed in during IETF LC. And then finally the corresponding
"clarification" (which I think was clear to everyone, anyway) was added
to what would eventually become RFC8200.

* During IESG review, it was somehow suggested by a folk (from the same
vendor as in other cases of the previous bullets) that before proceeding
with the publication of this document, we should essentially wait for a
proposal for EH-insertion to be worked out. Fortunately, RFC8200 was
approved and published, anyway.

* spring seems to have continued operating as if EH-insertion was
allowed. -- what looks to me a bit like "cook things up far from 6man",
which is of course unacceptable, since it is 6man that's in charge of
IPv6 standardization.

* When this was raised on 6man, and pointed out, then  we now heard
(after the said failure of "ambiguity in rfc2460" try), that it's okay
for them to violate RFC8200 and do EH-insertion, because they are
operating in a "limited domain" (when the IETF has consensus even about
what a "limited domain" is).

* Then you noted that 6man had decided to work on EHs at Singapore. And
when I polled you about that (how come?), you essentially asked me to go
look at the videos and minutes. But it turns out that there was no call
for adoption of any eh-insertion document (either in favour or against),
and obviously the list wasn't polled about it, either.


As noted, I have simply been trying hard for the decisions to be taken
by the wg (as opposed to "magical consensus"), and for the existing
specs to be respected and complied with unless there's formal consensus
not to do so.

Is being loud about that "attacking the process"? Or is that actually
that should simply happen without any wg participant asking, anyway?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492