Re: [111attendees] timing

Toerless Eckert <> Wed, 28 July 2021 14:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C4783A11C3 for <>; Wed, 28 Jul 2021 07:04:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.117
X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UiIHEBER0bVJ for <>; Wed, 28 Jul 2021 07:04:05 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D77B53A11BE for <>; Wed, 28 Jul 2021 07:04:00 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:51]) by (Postfix) with ESMTP id 4BF9E548053; Wed, 28 Jul 2021 16:03:54 +0200 (CEST)
Received: by (Postfix, from userid 10463) id 465AB4E7B8B; Wed, 28 Jul 2021 16:03:54 +0200 (CEST)
Date: Wed, 28 Jul 2021 16:03:54 +0200
From: Toerless Eckert <>
To: Vittorio Bertola <>
Cc: Randy Bush <>,
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [111attendees] timing
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mailing list for IETF 111 attendees <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Jul 2021 14:04:11 -0000

I think your "in other words" is simplifying it a bit too much.

My reading of the consensus of the active community deciding (mostly
through manycouches/shmoo and IETF leadership) seems to be
that one rather sticks to a very static setup that is known to create
more suffering for more participants than instead to try to optimize
in a way that would make a mayority more comfortable but may create
more pain in a numeric minority.

As the FAQ states, i think this could easily be changed if just a large
enough number of IETF participants would chime into the actual discussion
on manycouches/shmoo, write a draft, and get at least one spporter/contributor
from every timezone hawaii to new zealand to support it. That should
move the needle.

I think to remember that that minority from New Zealand for example was not
too unhappy about this IETF timing. Compared to one that would have made
europeans more happy.


On Wed, Jul 28, 2021 at 03:31:20PM +0200, Vittorio Bertola wrote:
> > Il 28/07/2021 15:18 Randy Bush <> ha scritto:
> > 
> >  
> > ok, i gotta ask.  i probably just missed the discussion.
> > 
> > why the heck does the meeting start at noon pacific as opposed to seven
> > or eight in the morning?  is this an intentional attack on both asia and
> > europe in one swell foop.
> It's a FAQ, and the answer is: because our first fully virtual meeting in the 5-day-6-hour format (IETF 108) started at noon "local" time, and our leadership (not sure who) concluded that changing this practice for any of the subsequent virtual meetings to make things easier for certain timezones would be unfair to those who had suffered due to this practice in earlier virtual meetings, so we're sticking with it forever, unless strong community consensus on a different practice appears.
> In other words: yes, it is intentional to make Europeans suffer a lot this time, because they haven't been suffering much in past virtual meetings. So, apologies for my garbled spoken English at 2:40am :-)
> -- 
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> Office @ Via Treviso 12, 10144 Torino, Italy
> -- 
> 111attendees mailing list