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

Andrew Alston <> Mon, 02 March 2020 07:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 225783A0E5E for <>; Sun, 1 Mar 2020 23:06:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 66-am2nI4uhG for <>; Sun, 1 Mar 2020 23:06:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2D29F3A0E62 for <>; Sun, 1 Mar 2020 23:06:39 -0800 (PST)
Received: from ( []) (Using TLS) by with ESMTP id uk-mta-114-o-bAMZo8OAK25WE4SsY5lw-1; Mon, 02 Mar 2020 07:06:32 +0000
X-MC-Unique: o-bAMZo8OAK25WE4SsY5lw-1
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.16; Mon, 2 Mar 2020 07:06:30 +0000
Received: from ([fe80::31cd:8171:1d1f:2fa9]) by ([fe80::31cd:8171:1d1f:2fa9%5]) with mapi id 15.20.2772.019; Mon, 2 Mar 2020 07:06:30 +0000
From: Andrew Alston <>
To: "Joel M. Halpern" <>, Robert Raszuk <>
Thread-Topic: [spring] WGLC - draft-ietf-spring-srv6-network-programming (off-topic)
Thread-Index: AQHV8AlrhCaVYkceMUu4Xlknso/BkKg0WtCAgAAEQACAAH4BYA==
Date: Mon, 2 Mar 2020 07:06:30 +0000
Message-ID: =?utf-8?q?=3CDBBPR03MB5415EAB1D2D2992CF7A39FBAEEE70=40DBBPR03MB5?= =?utf-8?q?415=2Eeurprd03=2Eprod=2Eoutlook=2Ecom=3E?=
References: =?utf-8?q?=3C17421=5F1575566127=5F5DE93B2F=5F17421=5F93=5F1=5F53?= =?utf-8?q?C29892C857584299CBF5D05346208A48D1A3DA=40OPEXCAUBM43=2Ecorporate?= =?utf-8?q?=2Eadroot=2Einfra=2Eftgroup=3E_=3C5518=5F1582908787=5F5E594573=5F?= =?utf-8?q?5518=5F436=5F1=5F53C29892C857584299CBF5D05346208A48DD1BCA=40OPEXC?= =?utf-8?q?AUBM43=2Ecorporate=2Eadroot=2Einfra=2Eftgroup=3E?= <> <> <> <> =?utf-8?q?=3C6=2E2=2E5=2E6=2E2=2E20200229223634=2E093850f0=40elandnews=2Eco?= =?utf-8?q?m=3E_=3CDBBPR03MB54150500DA829FBAB73DFEC1EEE60=40DBBPR03MB5415=2E?= =?utf-8?q?eurprd03=2Eprod=2Eoutlook=2Ecom=3E?= <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: [2c0f:fe40:3:1:7439:99c2:1044:543c]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 5bbb5a65-9e89-4bbb-71c2-08d7be783bd9
x-ms-traffictypediagnostic: DBBPR03MB5432:
x-microsoft-antispam-prvs: =?utf-8?q?=3CDBBPR03MB54324C40D325F1846BCDAB14EEE?= =?utf-8?q?70=40DBBPR03MB5432=2Eeurprd03=2Eprod=2Eoutlook=2Ecom=3E?=
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 033054F29A
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810019020=29=284636?= =?utf-8?b?MDA5KSgzOTg2MDQwMDAwMikoMzk2MDAzKSgxMzYwMDMpKDM3NjAwMikoMzY2?= =?utf-8?b?MDA0KSgzNDYwMDIpKDE5OTAwNCkoMTg5MDAzKSg5Njg2MDAzKSg1NjYwMzAw?= =?utf-8?q?002=29=2855016002=29=2871200400001=29=288676002=29=2881156014=29?= =?utf-8?q?=2881166006=29=2866574012=29=28186003=29=2866446008=29=2866946007?= =?utf-8?b?KSg2NjQ3NjAwNykoNjY1NTYwMDgpKDY0NzU2MDA4KSg3NjExNjAwNikoMzE2?= =?utf-8?b?MDAyKSgxMTAxMzYwMDUpKDg2MzYyMDAxKSg2NTA2MDA3KSg3Njk2MDA1KSg1?= =?utf-8?q?2536014=29=28478600001=29=2833656002=29=284326008=29=288936002=29?= =?utf-8?q?=282906002=29=3B?= DIR:OUT; SFP:1102; SCL:1; SRVR:DBBPR03MB5432;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: =?utf-8?q?jesmvBpli2w9IbOn6qwQpuqLNqIL8bf?= =?utf-8?q?k7wQ5SX01w10oxfZDG4T3I3OG9u9II/pXFRH+QB7AMHiGsI0Nk50mKzFRXGY/O5UZ?= =?utf-8?q?K7Q04vyJMZPdYpkVkOQ7MPUWmqFJbF8mospYMhl0CYAr/DenugSl4h4+U9sx91j+G?= =?utf-8?q?fKrDreIJJySe2e+5a+WxAPBnwvs+WroKHhHXAMvXWtSvAOpcrysvtp4U/+4U0BVAk?= =?utf-8?q?fdcDwmePbAFKPlVQ8kkbESNtFNft+oiCuNg2M1hYjGk7jasKXfJiZOJU8aN7rnBl9?= =?utf-8?q?gfXpy83/McDrnwCrPF2ukWjmep1SSIkCE8/+l3Wl46tQZ1wZ/O5f7DYGBsiR3OPA+?= =?utf-8?q?wDWvHJsEbIg36P9K6JxslqkbOcBIXL1CifKwzlBoqt7kU2vaj9XYJZZxvb/IL2/q4?= =?utf-8?q?YUjTgn2HOOQss9BjB36E0Js4/5h?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?kKybUJusDbvHDL//zWfxzTV/3NPsVG?= =?utf-8?q?frlqMte7IAOfq3KS3MCUYsaHZYGvxp2NX68K8Z15fFUBMSI+t7w36EjyvI/2ZE8cn?= =?utf-8?q?oyFR6rXYA9akSaFif+8wiIxNcZkfOatxbkyR05xMnpwckKkzaD3Uvkpuqex9SX5JP?= =?utf-8?q?seXMd1C0j6xWMySvxNujGsIkPjGy3EU/iEsogdXOkMVODocT921smA=3D=3D?=
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5bbb5a65-9e89-4bbb-71c2-08d7be783bd9
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2020 07:06:30.4954 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: =?utf-8?q?4Gx092Q1dE2iZzFGecnw9?= =?utf-8?q?73dGrVHb4Utydw1uuqwVQkpwKNamUGJZm/i4n0bCvJeD2bNUpnM+k12o4NA3hEiny?= =?utf-8?q?+04pnHQFPZBGcBezZms7o=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB5432
X-Mimecast-Spam-Score: 0
Content-Type: multipart/alternative; boundary="_000_DBBPR03MB5415EAB1D2D2992CF7A39FBAEEE70DBBPR03MB5415eurp_"
Archived-At: <>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming (off-topic)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Mar 2020 07:06:43 -0000

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.


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.
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 – 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.