As side-effect that should be clarified (was: Re: IETF 107 Vancouver In-Person Meeting Cancelled)

John C Klensin <> Tue, 10 March 2020 22:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B8143A0828; Tue, 10 Mar 2020 15:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zE8HikwFhIZG; Tue, 10 Mar 2020 15:59:47 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1459B3A0827; Tue, 10 Mar 2020 15:59:46 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1jBnqj-000JbI-3n; Tue, 10 Mar 2020 18:59:45 -0400
Date: Tue, 10 Mar 2020 18:59:39 -0400
From: John C Klensin <>
Subject: As side-effect that should be clarified (was: Re: IETF 107 Vancouver In-Person Meeting Cancelled)
Message-ID: <CA8380B1318C7C0895B9EB1D@PSB>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Mar 2020 22:59:48 -0000

Apologies for the extra copy - I fat-fingered the IESG's address
on the previous version


While I share the appreciation of others for what must have been
a difficult decision and support it (whether I would have made
the same decision or not is irrelevant, especially because I
don't have the information the IESG clearly solicited and
obtained), my recollection is that we have a series of dates and
actions tied to the first IETF meeting of the year (see RFC 8713
for an example).  The turnover dates for the IESG, IAB, etc.,
are (therefore) tied to that meeting.

If the meeting is "cancelled", rather than, e.g., being replaced
with a virtual one, the first meeting of 2020 would be the one
in Madrid at the end of July.  Assuming our intention is not to
delay the changeover of assorted Nomcom-selected bodies, I hope
someone has looked at the appropriate specifications and started
working on workarounds or will do so soon.

Yes, this is a procedural nit, but it is one that could come
back to haunt us if it, and the transition, were not handled in
an orderly way.