Re: IETF 110 schedule update

Loa Andersson <loa@pi.nu> Mon, 28 December 2020 04:13 UTC

Return-Path: <loa@pi.nu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9DF3A0FB1 for <ietf@ietfa.amsl.com>; Sun, 27 Dec 2020 20:13:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 oE4efn5kcZY5 for <ietf@ietfa.amsl.com>; Sun, 27 Dec 2020 20:13:21 -0800 (PST)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F873A0FAF for <ietf@ietf.org>; Sun, 27 Dec 2020 20:13:20 -0800 (PST)
Received: from [192.168.1.11] (unknown [124.104.17.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 0AFDE322D68; Mon, 28 Dec 2020 05:13:17 +0100 (CET)
Subject: Re: IETF 110 schedule update
To: Benjamin Kaduk <kaduk@mit.edu>, Michael Richardson <mcr+ietf@sandelman.ca>
Cc: IETF <ietf@ietf.org>
References: <1324823E-EEDC-4633-A6BB-978BE9D55252@ietf.org> <67AFF440-70DF-46C0-AD77-58BB0847C725@mnot.net> <20250.1609026566@localhost> <20201227043745.GF89068@kduck.mit.edu>
From: Loa Andersson <loa@pi.nu>
Message-ID: <48fa84db-d121-192c-3e8c-26f043493853@pi.nu>
Date: Mon, 28 Dec 2020 12:13:13 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <20201227043745.GF89068@kduck.mit.edu>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/MCvhx1AXMiYPBwyOEDmQBKgeiws>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Dec 2020 04:13:23 -0000

Folks,

On 27/12/2020 12:37, Benjamin Kaduk wrote:
> On Sat, Dec 26, 2020 at 06:49:26PM -0500, Michael Richardson wrote:
>>
>>      >> As previously announced, IETF 110 will be an online meeting [1]. IETF
>>      >> 110 working sessions will take place 8-12 March, from 12:00 to 18:00 UTC
>>      >> each day. This time block was chosen to schedule the meeting during the
>>      >> normal meeting hours in Prague, the original meeting location, and to be
>>      >> consistent with the intent of guidance in Section 2 of RFC 8719 related
>>      >> to meeting rotation. IETF 107, 108, and 109 similarly started in the
>>      >> early afternoon local time in the original meeting locations.
>>
>> Okay, each time we complain that starting time *ISN'T* the time that we would
>> have started if we were local, I'm told that it is consistent with the
>> previous decision.
>>
>> It is then noted that IETF107 was scheduled without a lot of thought.
>> So we are being consistent with a random decision in my opinion.
> 
> In some sense, yes ... but given that in person we can meet for 9+ hours,
> and online we're lucky to be productive for 6 straight, it also seems
> fairly arbitrary whether we start at the same time, or end at the same
> time (or somewhere in between) that we would if meeting in person.
> 

Kind of agree, but really why do we need to consider the local time, at 
least for some of the cities we are (virtually) going to have very few 
local participants.

I will not do any meetings that is before 6am or after midnight. I think 
it would be better to try the 6 hours that is reasonably hard for the 
participants that get the hardest deal, maybe even find two alternate 6 
hour slots. But they need not have anything to do with the "local time".

/Loa
>> I have serious, serious doubts about IETF111.
>> {But, some ideas on how to salvage it}
>>
>> I want to point that we previously, PRE-PANDEMIC, moved a meeting from SFO to
>> Montreal on the basis of difficulties getting *VISA*s approved.
>> Does anyone think it's going to be any easier?
>> Many people are likely to attend IETF110, 111, and even 112 remotely.
> 
> If you look in the recently published draft budget for 2021, you will note
> that there is a preduction for 15% reduced in-person attendance.
> 
>> Meeting time zones will be:
>>          Europe-friendly
>>          Pacific-friendly,
>>          Europe-friendly(2)
>> in 2021.
>>
>> Note something missing here?
>>
>> So, I wrote a document for shmoo.  The WG has neither rejected it, nor
> 
> (link?)
> 
>> adopted it, nor really done anything with it.    If someone else has a
>> better idea, then please write an ID.
>>
>> *I* won't be updating my document.
>>
>> I think that based upon the above decision, SHMOO has failed because the IESG
>> isn't really listening.
> 
> That's an interesting statement and interesting implied metric.
> (I, for one, am not even subscribed to the SHMOO list, since I already owe
> a few people updates on documents, etc. and shouldn't be adding more to my
> reading pile.)  I trust the IESG members who are on the list to report back
> to the full IESG when there is consensus on topics relevant to our
> decisions, but I also assume that untill there is some sense of consensus
> in SHMOO there's not a whole lot for the IESG to act on from its output (or
> input, for that matter).
> 
> -Ben
> 

-- 

Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert                          loa.pi.nu@gmail.com
Bronze Dragon Consulting             phone: +46 739 81 21 64