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