Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming (off-topic)

bruno.decraene@orange.com Mon, 02 March 2020 14:25 UTC

Return-Path: <bruno.decraene@orange.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 859B93A0770 for <spring@ietfa.amsl.com>; Mon, 2 Mar 2020 06:25:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
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 XSVlJYG2mMEB for <spring@ietfa.amsl.com>; Mon, 2 Mar 2020 06:25:30 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B7063A076F for <spring@ietf.org>; Mon, 2 Mar 2020 06:25:30 -0800 (PST)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 48WMqr32S5z5w2k; Mon, 2 Mar 2020 15:25:28 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1583159128; bh=YbKYxnk1yKvywIPokTunKpiE2lG1+WY63/dDAb9caeg=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=K3UYXuvzmFmpeRTAw3a6lR8RKou4xFaN5vNMx4KQODfBCNW2Ymcb19N1tgLFm4gKy wZ2Vp6KTMDenAZBl8IOtv2Or4fTXDYVlYx6JuerFus7YpvJmTM7RSSHW8tYyLxN+HH Z8rU++V8XZJUqXpB+b95P/OJIZf/GkcZvWe7SQVUsoFbuUPgTT6jmAKJmwDvFQWCwf QBTNdX2clw159ucSvhOZ4fXx2YabyNGB0GI+LTz/tIHmScTfZZQXDhBuJj4hCrj5zO K4FF9w1wlyGvc7wD1vVvo+woaTUjTg4n3sUF2MH5M7WqYtIj8jctoVrhnMknxsHPH6 ypRWv6RqcDezQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 48WMqr0rz0zDq7V; Mon, 2 Mar 2020 15:25:28 +0100 (CET)
Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBM5D.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0487.000; Mon, 2 Mar 2020 15:25:27 +0100
From: bruno.decraene@orange.com
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>
CC: SPRING WG <spring@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>, Robert Raszuk <robert@raszuk.net>
Thread-Topic: [spring] WGLC - draft-ietf-spring-srv6-network-programming (off-topic)
Thread-Index: AQHV8Alp6ApOCqoc9kKxpeYFVnh1Tag0Sg2AgAAEQACAAIMOAIAAiQ0Q
Date: Mon, 02 Mar 2020 14:25:27 +0000
Message-ID: <13177_1583159128_5E5D1758_13177_56_1_53C29892C857584299CBF5D05346208A48DD52F2@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <17421_1575566127_5DE93B2F_17421_93_1_53C29892C857584299CBF5D05346208A48D1A3DA@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <5518_1582908787_5E594573_5518_436_1_53C29892C857584299CBF5D05346208A48DD1BCA@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <C8417F71-D61E-42AC-831E-B85269D5D4A5@steffann.nl> <9b677b7c-fe52-dbae-7f83-2b5be5194325@gont.com.ar> <6.2.5.6.2.20200228132634.1060a610@elandnews.com> <9449c98e-b1d6-2c74-b78d-df3f5ba15ebc@nokia.com> <6.2.5.6.2.20200229223634.093850f0@elandnews.com> <DBBPR03MB54150500DA829FBAB73DFEC1EEE60@DBBPR03MB5415.eurprd03.prod.outlook.com> <6.2.5.6.2.20200301111046.0c0499b0@elandnews.com> <CAOj+MMH3eyjoQe=SokYQ89HM2po01G1V=kgO+653EKx8eaobzw@mail.gmail.com> <abc665ae-603b-49d9-9ce5-c51c3072e571@joelhalpern.com> <DBBPR03MB5415EAB1D2D2992CF7A39FBAEEE70@DBBPR03MB5415.eurprd03.prod.outlook.com>
In-Reply-To: <DBBPR03MB5415EAB1D2D2992CF7A39FBAEEE70@DBBPR03MB5415.eurprd03.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A48DD52F2OPEXCAUBM43corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/JfrdjkEXqqQ0Lid_apNF-y-aQRw>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming (off-topic)
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: Mon, 02 Mar 2020 14:25:33 -0000

Andrew,

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Andrew Alston
Sent: Monday, March 2, 2020 8:07 AM
To: Joel M. Halpern; Robert Raszuk
Cc: SPRING WG
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming (off-topic)

The usual practice when a hair o-authors a document is for the co-chair
to manage all aspects of the document life cycle. In this case, due to
the co-chair being unavailable, we have a bit of a problem. For
non-contentious documents, we can easily manage anyway. In this case,
the document is quite contentious. Which makes things complicated.

Yours,
Joel

In any normal circumstance, I would agree there would be far less of a problem – and we could find an simple way to manage this.  This however, is not a normal situation.

You have a write up of the LC – that states “We had to move this document forward” – there is absolutely nothing in the IETF process that states any document has to move forward in the absence of consensus.  The IETF says – we move forward based on consensus, not based on majority will of the working group to move something forward in the face of sustained unaddressed objections.

[Bruno] “Move this document forward” was related to starting the WG LC.
Also the whole point of the text was to say that the decision for the WGLC would be taken by Martin, not me.
https://mailarchive.ietf.org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/


You have a write up of the LC – which not once – other than in the context of RFC8200 and consensus achieved on that – mentions the word consensus in the context of this RFC – and last I checked, rough consensus was the basis for moving documents forward.
You have multiple issues that have not been addressed – you have a deep point of contention about RFC8200 – you have promises made at the microphone in Montreal (with the chair’s blessing) about providing an analysis of address space used, you have a concern that has been raised about RFC7112, and more and more individuals coming out and saying – we don’t agree with this – for technical reasons.

Now, in light of this – there are going to be questions – particularly in light of the fact that both the chair in question, and the AD in question, have their names on drafts either as contributors or authors which are either the draft in question, or have direct normative references to the draft on question.

Intentional and gaming the process – that I cannot say –

[Bruno] So don’t say.

--Bruno

it is up to each individual to decide on their own action and I do not know these individuals well enough to judge myself, however, I think it is naïve of anyone to believe that there will not be serious questions raised as to the impartiality of participants in the closure  of last call when we are facing such contentious issues, a very clear lack of consensus, and a series of unaddressed issues.

Thanks

Andrew



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.