Subject: [Manycouches] Time Zone Selection [was: Re: New Version Notification for draft-kuehlewind-shmoo-online-meeting-01.txt]

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 18 May 2021 15:03:05 +0000

Hi all,

Martin and I worked on an update of the section on Time Zone Selection in draft-kuehlewind-shmoo-online-meeting. We propose to try to establish consensus on selecting 3 time slots that then can be alternatively used for fully online meetings.

I guess there is still some discussion to have about which slots exactly to use and we have an open issue for that:

https://github.com/mirjak/draft-shmoo-online-meeting/issues/7

Please provide your thoughts and input either here or on github!

Mirja

On 18.05.21, 16:51, "[email-masked]" <[email-masked]> wrote:

    A new version of I-D, draft-kuehlewind-shmoo-online-meeting-01.txt
    has been successfully submitted by =?utf-8?q?Mirja_K=C3=BChlewind?= and posted to the
    IETF repository.

    Name:		draft-kuehlewind-shmoo-online-meeting
    Revision:	01
    Title:		Guidelines for the Organization of Fully Online Meetings
    Document date:	2021-05-18
    Group:		Individual Submission
    Pages:		7
    URL:            https://www.ietf.org/archive/id/draft-kuehlewind-shmoo-online-meeting-01.txt
    Status:         https://datatracker.ietf.org/doc/draft-kuehlewind-shmoo-online-meeting/
    Html:           https://www.ietf.org/archive/id/draft-kuehlewind-shmoo-online-meeting-01.html
    Htmlized:       https://tools.ietf.org/html/draft-kuehlewind-shmoo-online-meeting-01
    Diff:           https://www.ietf.org/rfcdiff?url2=draft-kuehlewind-shmoo-online-meeting-01

    Abstract:
       This document provides guidelines for the planning and organization
       of fully online meetings, regarding the number, length, and
       composition of sessions on the meeting agenda.  These guidelines are
       based on the experience after the COVID-19 pandemic in 2020.

    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.

    The IETF Secretariat

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 May 2021 08:53:00 +1200

Hi,
> Martin and I worked on an update of the section on Time Zone Selection in draft-kuehlewind-shmoo-online-meeting. We propose to try to establish consensus on selecting 3 time slots that then can be…

I think the text is too rigid by implying that the three proposed slots must be used for ever. It's fine to define some "default" starting times but I believe they should be suggestions, not a rule. For example:

OLD:
All fully online IETF plenary meetings begin at 0500 ("Asia"), 1200	
("Europe"), or 2100 ("North America") UTC.

NEW:
Suitable starting times for fully online IETF plenary meetings are
0500 ("Asia"), 1200 ("Europe"), or 2100 ("North America") UTC.

Then a nit:

>> 3.1.1.  Rules for selection
>> 
>> The IETF will select a start time from these three choices...

Who is "the IETF"? Do you mean the LLC? The IESG?

> I guess there is still some discussion to have about which slots exactly to use and we have an open issue for that:

My feeling is that it will be an open issue indefinitely, hence the above 
proposed change.

   Brian

> _______________________________________________
> Manycouches mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manycouches
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 18 May 2021 23:22:59 +0200

Le 18/05/2021 à 17:03, Mirja Kuehlewind a écrit :
> Hi all,
> 
> Martin and I worked on an update of the section on Time Zone
> Selection in draft-kuehlewind-shmoo-online-meeting. We propose to try
> to establish consensus on selecting 3 time slots that then can be
> alternatively used for fully online meetings.

Precisely 3 time slots?

Alex

> 
> I guess there is still some discussion to have about which slots
> exactly to use and we have an open issue for that:
> 
> has been successfully submitted by =?utf-8?q?Mirja_K=C3=BChlewind?=
> and posted to the IETF repository.
> 
> Name:		draft-kuehlewind-shmoo-online-meeting Revision:	01 Title:
> Guidelines for the Organization of Fully Online Meetings Document
> date:	2021-05-18 Group:		Individual Submission Pages:		7 URL:
> https://www.ietf.org/archive/id/draft-kuehlewind-shmoo-online-meeting-01.txt
>
> 
Status: 
https://datatracker.ietf.org/doc/draft-kuehlewind-shmoo-online-meeting/
> Html:
> https://www.ietf.org/archive/id/draft-kuehlewind-shmoo-online-meeting-01.html
>
> 
Htmlized: 
https://tools.ietf.org/html/draft-kuehlewind-shmoo-online-meeting-01
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-kuehlewind-shmoo-online-meeting-01
>
>  Abstract: This document provides guidelines for the planning and
> organization of fully online meetings, regarding the number, length,
> and composition of sessions on the meeting agenda.  These guidelines
> are based on the experience after the COVID-19 pandemic in 2020.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> 
> _______________________________________________ Manycouches mailing
> list [email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 18 May 2021 23:51:16 +0200

Given how there was no experimentation with other times in virtual meetings,
and given how i am also not aware of sufficient evidence collected
indicating that these times are "good enough to not bother with others",
i have to disagree with this particular current text. I also fear that 
Brians proposed weakening will not fix the root problem: no desire with
further time experimentation, even though there was enough desire on
manycouches to do so.

Aka: provide more evidence and/or include text like

"recent online meetings used times X, Y, Z. Due to the lacck of exploring other
options, there is not sufficient evidence to decide whether or not these times
are better than alternative times"

In other word: Just continue with leadership making executive decisions,
but do not call it community consensus.

Cheers
    Toerless

On Tue, May 18, 2021 at 03:03:05PM +0000, Mirja Kuehlewind wrote:
> ???On 18.05.21, 16:51, "[email-masked]" <[email-masked]> wrote:
> 
> 

-- 
---
[email-masked]

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 19 May 2021 09:18:51 +0200

Hi Toerless,

See inline.

> On 18. May 2021, at 23:51, Toerless Eckert <[email-masked]> wrote:
> 

Please have a look at the issue that is linked below; there is a bit of discussion about why these slots seems reasonable.
> are better than alternative times"

Not sure why we really need experimentation. Time zones are fixed and there will always be some people that will suffers not mater what time slot we take. Not sure what the goals or such an experiment actually would be?

Mirja

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 19 May 2021 09:24:36 +0200

Yes, this based on the three regions on RFC8719 as described in the doc.

Of course there is more flexibility for online meetings and we can also discuss if more than three slots would improve fairness. I personally don’t believe it would make it much better.

> On 18. May 2021, at 23:22, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
>> A new version of I-D, draft-kuehlewind-shmoo-online-meeting-01.txt has been successfully submitted by =?utf-8?q?Mirja_K=C3=BChlewind?=
>> list [email-masked] https://www.ietf.org/mailman/listinfo/manycouches
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 19 May 2021 09:28:28 +0200

The whole idea about this proposal is to avoid the same discussion for every online meeting in future. But the document does discuss about the opportunity to do experiments and that includes time slots. 

Still the aim right now is to see if we CAN reach consensus for one set of slots. Let’s have some more discussion and see if it’s possible. I would like to at least try and not give up right from the beginning.

> On 18. May 2021, at 22:53, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 19 May 2021 17:10:07 +0200

> Not sure why we really need experimentation. Time zones are fixed and there will always be some people that will suffers not mater what time slot we take. Not sure what the goals or such an experim…

Seriously ? 

You try one time (e.g.: 12 PM PST), you send a questionaire.
One year later (e.g.: maybe IETF111) you try another time (e.g.: 9 AM PST), you send a questionaire
you analyze questionaire results. You now know more how to beter serve the community.

But be that as it may. My main point was that IMHO we can not call any
results picked "community consensus". Not even shmoo/manycouches consensus.
If there is any consensus at all, it seems (from the 9 AM discussion) best
that there is no agreement on timing, and that experimentation and data collection
might help.

I think it would be a lot more honest to lead the document stating that it expresses
the opinion and recommendations of the (leadership) author(s) (and maybe listed constribuors)
and it was derived from open discussion with the community interested to participate,
which is understtood to be just a small subset of the affected community, often likely
not rpresenting that larger communitys preferences (which at large are not well understood
due to lack of experimentation).

Unless there is more experimentation, that disclaimer is the best and most honest
represenation of the process. And i see nothing wrong with that approach. After all,
we do elect leaderhship to also make executive decisions in the absense of technical data.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 19 May 2021 17:20:22 +0200

Please see inline.

> On 19. May 2021, at 17:10, Toerless Eckert <[email-masked]> wrote:
> 

This is not how fairness works. If you do that it would be majority decision. Time zones don’t chance and we know a rough distribution of participants (at least we e.g. know from which area we don’t have participation). Of course that can chance over time and we could need to adopt or we could even decide that we want to select time zones explicitly to attract participation from these regions (I’m not proposing this; just saying it could be an outcome of a discussion). But all this does not need actual experimentation. I can already tell you that I personally would be happier to have my meetings during my day and not during my night; I don’t need to try that to know it. 

> that there is no agreement on timing, and that experimentation and data collection

I’m not trying to call censuses. I'm very aware that there is no consensus yet. I’m trying to build consensus. This is one concrete proposal. But others are invited to make other proposals.

> due to lack of experimentation).

If we cannot reach consensus, the document should document the discussion and say that consensus could not be reached. At the moment, we are still trying if there is maybe a chance to get some consensus by proposing a set of time slot that hopefully are acceptable to the community.

Mirja

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 19 May 2021 17:36:10 +0200

On Wed, May 19, 2021 at 05:20:22PM +0200, Mirja Kuehlewind wrote:
> This is not how fairness works.

I did not claim that. I don't think we have a good metric for fairness other
than obliviousness so far (due to lack of data collection).

> If you do that it would be majority decision.

?? How are the current choices of times a majority decision ?

> Time zones don???t chance and we know a rough distribution of participants (at least we e.g. know from which area we don???t have participation).

I have not seen any analysis of that data, especially not one leading to
any argument why the current times have been picked. The best argument
was that it was some ad-hoc evolution from in-person meeting times..

I wish someone would start proposing how to derive some useful metrics
from the data we have and show the results for different starting times.

> Of course that can chance over time and we could need to adopt or we could even decide that we want to select time zones explicitly to attract participation from these regions (I???m not proposing this; just saying it could be an outcome of a discussion). But all this does not need actual experimentation.

I have lived through 30 years of pushing/pulling people into online
collaboration, and the results collected from them after the fact
where always different from their opinions before.

> I can already tell you that I personally would be happier to have my meetings during my day and not during my night; I don???t need to try that to know it. 

Sure, but just think that one out of three IETF you will get really bad times,
but two out of three IETFs, tuning the choice of starting time may help overall.

> I???m not trying to call censuses. I'm very aware that there is no consensus yet. I???m trying to build consensus. This is one concrete proposal. But others are invited to make other proposals.

And i doubt that consensus is a realistic goal. To me it is
a lot more beneficial to consider methods to gain more insight
into the problem to make better educated decisions in the future
(did i say experimentation and data collection ?).

> If we cannot reach consensus, the document should document the discussion and say that consensus could not be reached. At the moment, we are still trying if there is maybe a chance to get some cons…

A lot of time slot sets will be "acceptable". Picking a single set of time slots
and calling that community consensus is like writing a document to call community
consensus on a set of lottery numbers to play.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 19 May 2021 17:43:29 +0200

Le 19/05/2021 à 17:20, Mirja Kuehlewind a écrit :
[...]
> we know a rough distribution of participants (at least we e.g. know
> from which area we don’t have participation).

I suspect we have a large participation from India, China and Japan. 
Probably that group of participants is equally divided.

There were a few participants from Iran and Saudi Arabia too, not to 
mention Western Russia (Moscow, etc.)  This sits on a more western part 
of Asia.

Their timezones are very different.  India is more in kind of Central 
Asia timezone whereas China, Japan and Indonesia are on a more Eastern 
Asia timezone.

My question is why only one timeslot is chosen, and why is that timeslot 
systematically corresponding to the Eastern Asia and not to the Central 
or Western Asia?

If in doubt about my question one would use a geographical map, maybe.

Alex

  Of course that can
> chance over time and we could need to adopt or we could even decide
> that we want to select time zones explicitly to attract participation
> from these regions (I’m not proposing this; just saying it could be
> an outcome of a discussion). But all this does not need actual
> experimentation. I can already tell you that I personally would be
> happier to have my meetings during my day and not during my night; I
> don’t need to try that to know it.
> 
>> 
>> But be that as it may. My main point was that IMHO we can not call 
>> any results picked "community consensus". Not even 
>> shmoo/manycouches consensus. If there is any consensus at all, it 
>> seems (from the 9 AM discussion) best that there is no agreement
>> on timing, and that experimentation and data collection might
>> help.
> 
> I’m not trying to call censuses. I'm very aware that there is no 
> consensus yet. I’m trying to build consensus. This is one concrete 
> proposal. But others are invited to make other proposals.
> 
>> 
>> I think it would be a lot more honest to lead the document stating 
>> that it expresses the opinion and recommendations of the 
>> (leadership) author(s) (and maybe listed constribuors) and it was 
>> derived from open discussion with the community interested to 
>> participate, which is understtood to be just a small subset of the 
>> affected community, often likely not rpresenting that larger 
>> communitys preferences (which at large are not well understood due 
>> to lack of experimentation).
> 
> If we cannot reach consensus, the document should document the 
> discussion and say that consensus could not be reached. At the 
> moment, we are still trying if there is maybe a chance to get some 
> consensus by proposing a set of time slot that hopefully are 
> acceptable to the community.
> 
> Mirja
> 
> 
> 
>> 
>> Unless there is more experimentation, that disclaimer is the best 
>> and most honest represenation of the process. And i see nothing 
>> wrong with that approach. After all, we do elect leaderhship to 
>> also make executive decisions in the absense of technical data.
>> 
>> Cheers Toerless
>> 
>>> Mirja
>>> 
>>> 
>>>> 
>>>> In other word: Just continue with leadership making executive 
>>>> decisions, but do not call it community consensus.
>>>> 
>>>> Cheers Toerless
>>>> 
>>>>> Selection in draft-kuehlewind-shmoo-online-meeting. We 
>>>>> propose to try to establish consensus on selecting 3 time 
>>>>> slots that then can be alternatively used for fully online 
>>>>> meetings.
>>>>> 
>>>>> I guess there is still some discussion to have about which 
>>>>> slots exactly to use and we have an open issue for that:
>>>>> 
>>>>> A new version of I-D, 
>>>>> draft-kuehlewind-shmoo-online-meeting-01.txt has been 
>>>>> successfully submitted by =?utf-8?q?Mirja_K=C3=BChlewind?= 
>>>>> Name:		draft-kuehlewind-shmoo-online-meeting Revision:	01 
>>>>> Title:		Guidelines for the Organization of Fully Online 
>>>>> Meetings Document date:	2021-05-18 Group:		Individual 
>>>>> Submission Pages:		7 URL: 
Status:
Htmlized:
Abstract:
>>>>> This document provides guidelines for the planning and 
>>>>> organization of fully online meetings, regarding the number, 
>>>>> length, and composition of sessions on the meeting agenda. 
>>>>> These guidelines are based on the experience after the 
>>>>> COVID-19 pandemic in 2020.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Please note that it may take a couple of minutes from the 
>>>>> time of submission until the htmlized version and diff are 
>>>>> available at tools.ietf.org.
>>>>> 
>>>>> The IETF Secretariat
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________ Manycouches 
>>>>> mailing list [email-masked] 
>>>> -- --- [email-masked]
>>>> _______________________________________________ Manycouches 
>>>> mailing list [email-masked] 
>> -- --- [email-masked]
>> _______________________________________________ Manycouches
>> mailing list [email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 19 May 2021 17:44:42 +0200

IMHO, the most important thing to do is to collect feedback from the
larger community through questionaires. Obviously with questions
that help us to optimize our choices an allow comparison of the
options explored or planned to be explored.

Short of more data from opinion polling and experimentation, picking
of times is best left as an execuive decision.

Cheers
    Toerless

On Wed, May 19, 2021 at 09:28:28AM +0200, Mirja Kuehlewind wrote:
> Still the aim right now is to see if we CAN reach consensus for one set of slots. Let???s have some more discussion and see if it???s possible. I would like to at least try and not give up right from the beginning.
> 
> 

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 19 May 2021 17:59:46 +0200

Right now i think he answer would be that it purly depended on the virual
host cities time zone. The next best answer is probably some type of
Americas/Euro/Asia reference timezone.

The way i look at this is more like this:
Think about a preference metric to have to work at some hour:

  For every hour of the day, 0 = worst ... 5 = best, maybe default:
               0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
     Midnight: 1 0 0 0 0 1 2 3 4 5  5  5  5  5  5  5  5  4  3  3  3  2  2  2

  Now you calculate for every participant avg/min/max for the IETF,
  you calculate over the overall community the worst affected (max number
  of min metric), etc. pp

When picking any set of three times (across the three IETF), i think we're all
thinking around optimizing any of the possible metrics derived from one of
the calculations. The "fairness" people i think would look at the minimum
worst-case, but then all may suffer. The "productivity" people would look for
the best aggregate maximum.

Cheers
    Toerless

On Wed, May 19, 2021 at 05:43:29PM +0200, Alexandre Petrescu wrote:
> > from which area we don???t have participation).
> 
> There were a few participants from Iran and Saudi Arabia too, not to mention
> Western Russia (Moscow, etc.)  This sits on a more western part of Asia.
> 
> Their timezones are very different.  India is more in kind of Central Asia
> timezone whereas China, Japan and Indonesia are on a more Eastern Asia
> timezone.
> 
> systematically corresponding to the Eastern Asia and not to the Central or
> Western Asia?
> 
> > from these regions (I???m not proposing this; just saying it could be
> > don???t need to try that to know it.
> > 
> > > 
> > > any results picked "community consensus". Not even shmoo/manycouches
> > > consensus. If there is any consensus at all, it seems (from the 9 AM
> > > discussion) best that there is no agreement
> > I???m not trying to call censuses. I'm very aware that there is no
> > consensus yet. I???m trying to build consensus. This is one concrete
> > discussion and say that consensus could not be reached. At the moment,
> > we are still trying if there is maybe a chance to get some consensus by
> > proposing a set of time slot that hopefully are acceptable to the
> > community.
> > 
> > Mirja
> > 
> > 
> > 
> > > 
> > > wrong with that approach. After all, we do elect leaderhship to also
> > > make executive decisions in the absense of technical data.
> > > 
> > > Cheers Toerless
> > > 
> > > > Mirja
> > > > 
> > > > 
> > > > > 
> > > > > In other word: Just continue with leadership making
> > > > > executive decisions, but do not call it community consensus.
> > > > > 
> > > > > Cheers Toerless
> > > > > 
> > > > > > Martin and I worked on an update of the section on Time
> > > > > > Zone Selection in draft-kuehlewind-shmoo-online-meeting.
> > > > > > We propose to try to establish consensus on selecting 3
> > > > > > time slots that then can be alternatively used for fully
> > > > > > online meetings.
> > > > > > 
> > > > > > I guess there is still some discussion to have about
> > > > > > which slots exactly to use and we have an open issue for
> > > > > > that:
> > > > > > 
> > > > > > successfully submitted by
> > > > > > =?utf-8?q?Mirja_K=C3=BChlewind?= and posted to the IETF
> > > > > > repository.
> > > > > > 
> > > > > > Revision:	01 Title:		Guidelines for the Organization of
> > > > > > Fully Online Meetings Document date:	2021-05-18
> > > > > > Group:		Individual Submission Pages:		7 URL: https://www.ietf.org/archive/id/draft-kuehlewind-shmoo-online-meeting-01.txt
> > > > > > 
> > > > > > 
> > > > > > 
> Status:
> > > > > > organization of fully online meetings, regarding the
> > > > > > number, length, and composition of sessions on the
> > > > > > meeting agenda. These guidelines are based on the
> > > > > > experience after the COVID-19 pandemic in 2020.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Please note that it may take a couple of minutes from
> > > > > > the time of submission until the htmlized version and
> > > > > > diff are available at tools.ietf.org.
> > > > > > 
> > > > > > The IETF Secretariat
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Manycouches mailing list [email-masked]
> > _______________________________________________ Manycouches mailing list
> > [email-masked] https://www.ietf.org/mailman/listinfo/manycouches
> > 
> 

-- 
---
[email-masked]

On Wed, May 19, 2021 at 05:43:29PM +0200, Alexandre Petrescu wrote:
> > from which area we don???t have participation).
> 
> There were a few participants from Iran and Saudi Arabia too, not to mention
> Western Russia (Moscow, etc.)  This sits on a more western part of Asia.
> 
> Their timezones are very different.  India is more in kind of Central Asia
> timezone whereas China, Japan and Indonesia are on a more Eastern Asia
> timezone.
> 
> systematically corresponding to the Eastern Asia and not to the Central or
> Western Asia?
> 
> > from these regions (I???m not proposing this; just saying it could be
> > don???t need to try that to know it.
> > 
> > > 
> > > any results picked "community consensus". Not even shmoo/manycouches
> > > consensus. If there is any consensus at all, it seems (from the 9 AM
> > > discussion) best that there is no agreement
> > I???m not trying to call censuses. I'm very aware that there is no
> > consensus yet. I???m trying to build consensus. This is one concrete
> > discussion and say that consensus could not be reached. At the moment,
> > we are still trying if there is maybe a chance to get some consensus by
> > proposing a set of time slot that hopefully are acceptable to the
> > community.
> > 
> > Mirja
> > 
> > 
> > 
> > > 
> > > wrong with that approach. After all, we do elect leaderhship to also
> > > make executive decisions in the absense of technical data.
> > > 
> > > Cheers Toerless
> > > 
> > > > Mirja
> > > > 
> > > > 
> > > > > 
> > > > > In other word: Just continue with leadership making
> > > > > executive decisions, but do not call it community consensus.
> > > > > 
> > > > > Cheers Toerless
> > > > > 
> > > > > > Martin and I worked on an update of the section on Time
> > > > > > Zone Selection in draft-kuehlewind-shmoo-online-meeting.
> > > > > > We propose to try to establish consensus on selecting 3
> > > > > > time slots that then can be alternatively used for fully
> > > > > > online meetings.
> > > > > > 
> > > > > > I guess there is still some discussion to have about
> > > > > > which slots exactly to use and we have an open issue for
> > > > > > that:
> > > > > > 
> > > > > > successfully submitted by
> > > > > > =?utf-8?q?Mirja_K=C3=BChlewind?= and posted to the IETF
> > > > > > repository.
> > > > > > 
> > > > > > Revision:	01 Title:		Guidelines for the Organization of
> > > > > > Fully Online Meetings Document date:	2021-05-18
> > > > > > Group:		Individual Submission Pages:		7 URL: https://www.ietf.org/archive/id/draft-kuehlewind-shmoo-online-meeting-01.txt
> > > > > > 
> > > > > > 
> > > > > > 
> Status:
> > > > > > organization of fully online meetings, regarding the
> > > > > > number, length, and composition of sessions on the
> > > > > > meeting agenda. These guidelines are based on the
> > > > > > experience after the COVID-19 pandemic in 2020.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Please note that it may take a couple of minutes from
> > > > > > the time of submission until the htmlized version and
> > > > > > diff are available at tools.ietf.org.
> > > > > > 
> > > > > > The IETF Secretariat
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Manycouches mailing list [email-masked]
> > _______________________________________________ Manycouches mailing list
> > [email-masked] https://www.ietf.org/mailman/listinfo/manycouches
> > 
> 

-- 
---
[email-masked]

---

From: Andrew Campling <[email-masked]>
Date: Wed, 19 May 2021 16:04:46 +0000

> Of course there is more flexibility for online meetings and we can also discuss if more than three slots would improve fairness. I personally don’t believe it would make it much better.

I agree that the use of three slots, preferably evenly spaced, seems to give reasonable fairness to most of us for the majority of the time whilst maintaining the 1-1-1 part of the 1-1-1-* approach and sharing the pain.  Given that we will hopefully move back to in-person meetings soon, or more likely in-person meetings with enhanced remote attendance, we will hopefully not speed too much more energy trying to optimise the three slots - especially when the reality is that our individual optimisations are mutually exclusive.  

I hope that we don't lose sight of the importance of sharing the pain if we are to improve the geographic diversity of the community.  Equally, I hope that we all accept that timings will revert to those that suit the host site as soon as we move back to in-person meetings.

Andrew

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 19 May 2021 18:08:24 +0200

> On 19. May 2021, at 17:36, Toerless Eckert <[email-masked]> wrote:
> 

We have data. What I’m trying to say is that the only relevant data is in which location (on country or actually time zone level) our participants are based and we have this data from each attendee list.

I assume you are looking for some kind of opinion data about which time zones are acceptable for each individual. I just don’t think that that kind of data would provide us any useful input.

There seems to be two view points here about how to “optimize”. One is to make the time most conformable to those who attend. The other is to share the pain more equally, more or less independent of how many people attend from a certain region (as long as that number is not close to zero). Optimising for the actual attendees (only) does help productivity and is something I support for interim meetings. The later approach is for me inline with RFC8719 and given that cross participation and also attracting new participants are goals for the plenary meetings, I think what we should retain such a policy also for fully online meeting. We can discuss if we even want to extend that policy but at least I’m not proposing this. Others are free to do so.

> ?? How are the current choices of times a majority decision ?

They aren’t. I meant if we would base our decision (solely) on survey results, they would be, which I don’t think is desirable.

> from the data we have and show the results for different starting times.

This what we try to do in the issue on GitHub based on the plots Martin posted there:

Again I think the revenant data here is from which region we have a set of participants and based on that data, the time zones shown in the images have been selected. 

We can now agree which times are consider worst or should be avoided as much as possible and that the discussion we currently have on the issue.

> but two out of three IETFs, tuning the choice of starting time may help overall.

Yes, this is what I trying to do with the proposed time slots because those slot would cover an morning and an afternoon slots for two of the three region from RFC8719, as explained in the draft.

> And i doubt that consensus is a realistic goal.

That’s okay. But at the moment that my personal goal for submitting this proposal.

> To me it is

If we have more knowledge and we come to a different decision/consensus in the future, it easy enough to revise this doc. Right now I just don’t think it is helpful to have basically the exactly same discussion before every meeting (without much progress). Therefore let’s try to get consensus for what we do now, go for it for a while, and then reconsider if needed.

However, I actually hope that we don’t need to have as much experience with is in future as we did in the last year and therefore the options for experimentation might anyway be (more) limited in future.

> consensus on a set of lottery numbers to play.

I think having a discussion to use slightly different time slots each time, which will always make some people unhappy, is not helpful either. There is no perfect time zone to pick. All I'm asking for is that I get two out of three meetings in a reasonable time zone. And I believe that is actually possible with the proposed slots if we all are a bit more open on how we definite “reasonable” for ourselves.

Mirja

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 19 May 2021 18:12:51 +0200 (CEST)

> Il 19/05/2021 17:59 Toerless Eckert <[email-masked]> ha scritto:
> 

You still seem to be missing an angle. Inclusion policies are exactly about picking a solution which is not the optimum (or the minimum worst case) for the entire population, but only for a subset whose participation you want to facilitate disproportionately, a subset that may be chosen differently meeting by meeting. Picking a place (if physical) or a timezone (if virtual) for meetings of global organizations is not a mathematical problem, it is a policy problem (though one of the possible policies is to downgrade it to a mathematical problem - but that's still a policy choice).

Anyway, hopefully this discussion will be pointless from IETF 112 on, when hopefully we will revert to a meeting format whose timeframe will be determined by the location of its physical part.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 19 May 2021 18:15:29 +0200

As Andrews mentions going back to in-person:

I think it would be importing to better understand the
priorities for the remote attendants. I for once i can see that bad timing
may not be the top priority, but more equal access to the productive parts of
the conference with local participants.

Aka: as silly as it may look upfront, we're a technology conference, so why
not even explore stuff like his for remote participants to be able to participate
in hallway discussion:

https://www.doublerobotics.com/

(no endorsement mean, no idea if these are good, probably lots of similar options around).

Ok, great. Now we've identified maybe the "most far-out-option". But what
are the "lowest-hanging-fruits" to improve remote participation in an on-site
meeting that we have not tackled ?

Cheers
    Toerless

On Wed, May 19, 2021 at 04:04:46PM +0000, Andrew Campling wrote:
> > Of course there is more flexibility for online meetings and we can also discuss if more than three slots would improve fairness. I personally don???t believe it would make it much better.
> 

-- 
---
[email-masked]

---

From: Martin Duke <[email-masked]>
Date: Wed, 19 May 2021 09:15:46 -0700

On Wed, May 19, 2021 at 9:13 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

>
> Anyway, hopefully this discussion will be pointless from IETF 112 on, when
> hopefully we will revert to a meeting format whose timeframe will be
> determined by the location of its physical part.
>

The entire purpose of the shmoo working group is to develop policies to
inform future virtual meetings after the pandemic is over.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 19 May 2021 18:21:48 +0200

On Wed, May 19, 2021 at 06:08:24PM +0200, Mirja Kuehlewind wrote:
> We have data. What I???m trying to say is that the only relevant data is in which location (on country or actually time zone level) our participants are based and we have this data from each attendee list.

Right. I just have not seen an analysis like the one i proposed in the other reply with
applying metrics to this info.

> I assume you are looking for some kind of opinion data about which time zones 
                                                                     ^^^^^^^^^^ times ?
> are acceptable for each individual.

> I just don???t think that that kind of data > would provide us any useful input.

Strange. Sounds like you prefer assuming what attendants want over actually asking them.
I must be misunderstanding something.

> There seems to be two view points here about how to ???optimize???. One is to make the time most conformable to those who attend. The other is to share the pain more equally, more or less independent of how many people attend from a certain region (as long as that number is not close to zero). 

Probably a lot mor than just two opimizations.

> Optimising for the actual attendees (only) does help productivity and is something I support for interim meetings. The later approach is for me inline with RFC8719 and given that cross participation and also attracting new participants are goals for the plenary meetings, I think what we should retain such a policy also for fully online meeting. We can discuss if we even want to extend that policy but at least I???m not proposing this. Others are free to do so.

Agreed that any in-person meeting should prioriize time foremost on in-person
attendants, but procedures to be as inclusive for remote ones as possible.

Cheers
    Toerless

> They aren???t. I meant if we would base our decision (solely) on survey results, they would be, which I don???t think is desirable.
> 
> > 
> That???s okay. But at the moment that my personal goal for submitting this proposal.
> 
> > To me it is
> If we have more knowledge and we come to a different decision/consensus in the future, it easy enough to revise this doc. Right now I just don???t think it is helpful to have basically the exactly same discussion before every meeting (without much progress). Therefore let???s try to get consensus for what we do now, go for it for a while, and then reconsider if needed.
> 
> However, I actually hope that we don???t need to have as much experience with is in future as we did in the last year and therefore the options for experimentation might anyway be (more) limited in future.
> 
> > 
> I think having a discussion to use slightly different time slots each time, which will always make some people unhappy, is not helpful either. There is no perfect time zone to pick. All I'm asking for is that I get two out of three meetings in a reasonable time zone. And I believe that is actually possible with the proposed slots if we all are a bit more open on how we definite ???reasonable??? for ourselves.
> 
> Mirja
> 
> 
> 
> 
> > 
> > Cheers
> >    Toerless
> > 
> >> 
> >> Mirja
> >> 
> >> 
> >> 
> >>> 

-- 
---
[email-masked]

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 19 May 2021 18:24:10 +0200

Changing subject because I think we should really separate these issues here.

Also, Shmoo is explicitly chartered to only consider online-only meeting, but I agree that starting some discussion about option for hybrid meetings is probably appropriate timing-wise. As Jay said, the secretariat is already looking in to certain topics and I assume will report at some point back after ietf-111. So I personally would wait for that.

However, I also have o say that I think you picked the hardest part. And for IETF-112 (only) I would be already extremely happy if I could have some hallway discussion with some people in the real world at all.

> On 19. May 2021, at 18:15, Toerless Eckert <[email-masked]> wrote:
>

---

From: Martin Duke <[email-masked]>
Date: Wed, 19 May 2021 09:25:15 -0700

This working group is chartered to work on fully online meetings If you
would like to work on the experience of remote attendees in an in-person
meetings, perhaps a draft to gendispatch?

On Wed, May 19, 2021 at 9:15 AM Toerless Eckert <[email-masked]> wrote:

> > > Of course there is more flexibility for online meetings and we can
> also discuss if more than three slots would improve fairness. I personally
> don???t believe it would make it much better.
> >
> > I agree that the use of three slots, preferably evenly spaced, seems to
> give reasonable fairness to most of us for the majority of the time whilst
> maintaining the 1-1-1 part of the 1-1-1-* approach and sharing the pain.
> Given that we will hopefully move back to in-person meetings soon, or more
> likely in-person meetings with enhanced remote attendance, we will
> hopefully not speed too much more energy trying to optimise the three slots
> - especially when the reality is that our individual optimisations are
> mutually exclusive.
> >
> > I hope that we don't lose sight of the importance of sharing the pain if
> we are to improve the geographic diversity of the community.  Equally, I
> hope that we all accept that timings will revert to those that suit the
> host site as soon as we move back to in-person meetings.
> >
> > Andrew

---

From: Fred Baker <[email-masked]>
Date: Wed, 19 May 2021 09:26:08 -0700

Maybe the right model would be to recharter Shmoo to include hybrid meetings.

> On May 19, 2021, at 9:24 AM, Mirja Kuehlewind <[email-masked]> wrote:
>

---

From: Martin Duke <[email-masked]>
Date: Wed, 19 May 2021 09:27:11 -0700

Aren't all meetings "hybrid"?

On Wed, May 19, 2021 at 9:26 AM Fred Baker <[email-masked]> wrote:

> > Also, Shmoo is explicitly chartered to only consider online-only
> meeting, but I agree that starting some discussion about option for hybrid
> meetings is probably appropriate timing-wise. As Jay said, the secretariat
> is already looking in to certain topics and I assume will report at some
> point back after ietf-111. So I personally would wait for that.
> >
> > However, I also have o say that I think you picked the hardest part. And
> for IETF-112 (only) I would be already extremely happy if I could have some
> hallway discussion with some people in the real world at all.
> >
> >
> >
> >>> I agree that the use of three slots, preferably evenly spaced, seems
> to give reasonable fairness to most of us for the majority of the time
> whilst maintaining the 1-1-1 part of the 1-1-1-* approach and sharing the
> pain.  Given that we will hopefully move back to in-person meetings soon,
> or more likely in-person meetings with enhanced remote attendance, we will
> >>> I hope that we don't lose sight of the importance of sharing the pain
> if we are to improve the geographic diversity of the community.  Equally, I

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 19 May 2021 18:28:32 +0200

Yes, we should do this but maybe after ietf-111 or even ietf-112…? IETF-112 will be an unusual meeting no matter what but I think it could give us some useful experience about what it means to have a hybrid meeting or, let’s say, a meeting with potentially more remote attendees than in-person attendees.

> On 19. May 2021, at 18:26, Fred Baker <[email-masked]> wrote:
>

---

From: Fred Baker <[email-masked]>
Date: Wed, 19 May 2021 09:28:35 -0700

> On May 19, 2021, at 9:27 AM, Martin Duke <[email-masked]> wrote:
> 

For the past year, none of us has travelled anywhere. But yes, historically (and here I'm going back decades) all meetings have had both remote and local participants.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 19 May 2021 18:33:45 +0200

> On 19. May 2021, at 18:21, Toerless Eckert <[email-masked]> wrote:
> 

The analysis we did is in GitHub:

You are free to do a different analysis and provide your results.

> I must be misunderstanding something.

I think it fair to assume that no-ones likes to have meeting in the middle of the night. I believe Jay did have a question about time slot preferences in one of thee survey; can find the results right now but I don’t remember that the results were anyhow insightful.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 19 May 2021 18:35:48 +0200

> On 19. May 2021, at 18:33, Mirja Kuehlewind <[email-masked]> wrote:
> 
> 
> 

Sorry missing not here, I meant: I can’t find the results right now… but I’m sure google can help.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 May 2021 12:44:35 -0400

Toerless Eckert <[email-masked]> wrote:
    > Right now i think he answer would be that it purly depended on the
    > virual host cities time zone. The next best answer is probably some
    > type of Americas/Euro/Asia reference timezone.

    > The way i look at this is more like this: Think about a preference
    > metric to have to work at some hour:

So, this graph sort of assumes the meeting is only 1 minute (or 1hr) long.

Starting at 9pm might be an acceptable time, but it means ending at 3am (assuming 6hr
packed meeting).   Or, starting at 5am may be unpleasant, but it means ending
at 11am may be just fine.  On the other hand, starting at 00:00 might mean
still being awake at 5am, which would be a problem.

As I went on about for IETF109,  the choice of starting time also has a
significant impact on side meeting time.  Do people get up just in time for
the meeting, and then stay awake after the meeting?  Or do they have their
day, and then "stay up" for the meeting, going to sleep as soon as it's over?

The two modes of do not overlap well for side meeting, and other *needed*
social interactions that establish trust.

While many people attend only one or two WGs, a significant minority attend
more than a dozen meetings during the week, including IAB and IESG.
It seems that we hear from the people who attend very few meetings out of
proportion, when the meeting is not at a convenient time for them.

Are all attendees equal?  Are some more equal than others?
Should I get vote for each WG I attend?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Andrew Campling <[email-masked]>
Date: Wed, 19 May 2021 16:58:39 +0000

On 19 May 2021, at 17:45, Michael Richardson <[email-masked]> wrote:

> As I went on about for IETF109,  the choice of starting time also has a significant impact on side meeting time.  Do people get up just in time for the meeting, and then stay awake after the meeting?  Or do they have their day, and then "stay up" for the meeting, going to sleep as soon as it's over?
> 
> The two modes of do not overlap well for side meeting, and other *needed* social interactions that establish trust.

Agreed but, IMHO, the social interaction element is very hard (impossible?) to do well remotely.  Whilst a great deal of time and energy could be expended on this, I worry that we'd be pursuing an unachievable goal.  Perhaps we should accept that virtual meetings are different and we're best advised not trying to emulate every element of the latter.    

Andrew

---

From: Andrew Campling <[email-masked]>
Date: Wed, 19 May 2021 17:01:47 +0000

> Yes, we should do this but maybe after ietf-111 or even ietf-112…? IETF-112 will be an unusual meeting no matter what but I think it could give us some useful experience about what it means to have…

Waiting until after IETF 112 seems reasonable assuming that we have better data by then on what the new "normal" might look like.  

Andrew

---

From: Bob Hinden <[email-masked]>
Date: Wed, 19 May 2021 10:14:16 -0700

> On May 19, 2021, at 9:04 AM, Andrew Campling <[email-masked]> wrote:
> 

I suspect that we might get back to face to face meetings before this discussion concludes :-(

> I hope that we don't lose sight of the importance of sharing the pain if we are to improve the geographic diversity of the community.  Equally, I hope that we all accept that timings will revert to…

+1

Bob

---

From: John C Klensin <[email-masked]>
Date: Wed, 19 May 2021 13:38:11 -0400

Let me make a few observations to see if they help.  With slight
extrapolations, most have applicability much broader than this
particular question (and maybe I should put a variation of it on
the IETF list):

(1) I am convinced, as most (clearly not all) others seem to be,
that we will never find a perfect set of times or even a perfect
compromise.  Ultimately, part of that is that some of us are
looking at geography (e.g., time zones) and others are looking
at demographics (e.g., locations of IETF participants and/or
population distributions generally).  There are no "right"
answers and we can argue forever.

(2) I obviously do not know about others, but I look at all of
the time that is going into writing and reading these messages
and wonder what the process is doing to make the Internet
better.  How much more useful technical work could the IETF be
doing if the resources were going in that direction rather than
into trying to fine-tune the IETF?  Of course that assumes our
technical work actually leads to improvements in the Internet
rather than in ways that will not be adopted or that will have
no noticeable effect?

(3) There seems to be a tendency of late to look at an RFC, or
even at an IESG Statement or dictum, and act almost as if they
are equivalent to the stereotype of decisions of self-important
absolute monarchs or presumed deities while in office of old:
chiseled into stone, immutable for all time, never to be
questioned, and possibly even to be mentioned or referenced in
sufficiently solemn terms to make clear that the mere reference
settles whatever the question is at hand.    That isn't the IETF
that defined many or most of the technical foundations for the
modern Internet.  In that IETF, there were no sacred texts.
Documents and statements defined things that were believed to
work and be useful.  When they stopped working or being useful
and helpful, we discussed them, changed them, and moved on.

(4) So, rather than either giving up or having this conversation
draw out indefinitely, let me suggest that we take the times we
have, more forward, and do so with a provision for review and
reconsideration in, say, 18 months or two years.  That review
should not start with a clean sheet and should have clear
options of "not broken, don't fix it" as well as "argue
endlessly and/or start a WG" or even "we don't expect all-remote
meetings any time soon so put this off", but whatever is decided
now should not treated as irreversibly applying to "every online
meeting we have in the future".

best,
   john

--On Wednesday, May 19, 2021 09:28 +0200 Mirja Kuehlewind
<[email-masked]> wrote:

> The whole idea about this proposal is to avoid the same
> discussion for every online meeting in future. But the
> document does discuss about the opportunity to do experiments
> and that includes time slots. 
> 
> Still the aim right now is to see if we CAN reach consensus
> for one set of slots. Let's have some more discussion and
> see if it's possible. I would like to at least try and not
> give up right from the beginning.
>...

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 19 May 2021 19:53:36 +0200

The question is whether shmoo actually has or wants to usurp the power to 
limit the use of manycouches to only shmoo WG scope. Remember that manycouches
predates shmoo and had a much less rigid scope. IMHO this mailing list
is still the best to discuss these original broader topics instead o
fragementing the community (one of the reason for shmoo to jump onto manycouches as well).

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 19 May 2021 20:06:59 +0200

> You are free to do a different analysis and provide your results.

Would be good to add an explicit reference to that URL into your draft in
the place of the text where you would leverage it.

Right now the nice tabl from Martin on that URL does not even reflect
the currently choosen 12 PM PST for IETF111, so adding that would help
to compare with the times you propose. If this could be an editable
(e.g.: xls) document i'd be happy to add the 9 AM PST option for easire
comparison as well.

> I think it fair to assume that no-ones likes to have meeting in the middle of the night.

You said that feedback would not provide useful input very broadly.
Is not a good justification for such a broad statement to come up with
one likely already obvious data point. Thats all i said. 

> I believe Jay did have a question about time slot preferences in one of thee survey; can find the results right now but I don???t remember that the results were anyhow insightful.

Would be great to capture (pointers to) all he data we have in your draft.
Even if we do not rech consensus that would make your draft the one stop shop
for folks interested in th subject (and solutions).

Cheers
    Toerless

---

From: Fred Baker <[email-masked]>
Date: Wed, 19 May 2021 11:14:44 -0700

+1

Sent using a machine that autocorrects in interesting ways...

> On May 19, 2021, at 10:38 AM, John C Klensin <[email-masked]> wrote:
>

---

From: Fred Baker <[email-masked]>
Date: Wed, 19 May 2021 11:17:59 -0700

If there is any concept of using times that are consistent with local practice, or anything that was used for the first 100+ meetings, a 9:00 AM start time should be one of the options in the table.

> On May 19, 2021, at 11:07 AM, Toerless Eckert <[email-masked]> wrote:
>

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 19 May 2021 20:20:33 +0200

> So, this graph sort of assumes the meeting is only 1 minute (or 1hr) long.

No, i implied to add up the metrics for all hours of a proposed IETF timing
and capture minimum and average.

> still being awake at 5am, which would be a problem.

Agreed. the implied algo i had in mind would come to the same result. And hsould
hopefully be a good basis to compare any proposed timings.

> social interactions that establish trust.

Maybe simplified: whenever hours 1-5 AM are in play for the official meeting, likelyhood
is high that the person can not hae productive side meetings AND official meetings -
unless he/she is very disciplined and lives a week on a different clock (which
i have read few reports about on our lists).

> more than a dozen meetings during the week, including IAB and IESG.

By that notion we should hav probably only considered Amer/EU friendly times
to make mayority of IESG/IAB most happy. 

But lets think of the times when we will have hybrid again. Would an AD get
elected into office when she says she is self sponsored and can not afford to
travel to all meetings, but when she is not present, she would make herself
available all time she would if she was there in-person (e.g.: by adjusting
day cycle during IETF week as explained above) ?

> proportion, when the meeting is not at a convenient time for them.

Sure. Should weigh voices accordingly.

> Should I get vote for each WG I attend?

Folks called M)ichael can only vote for M)ondays.

Kidding aside:

How is th WG schedule built ? any NP-complete search tool ?
I its extensible, then WG chairs might be able to add preference of time/days,
and then the NP search just figures out the best combination... Of course
results will always suck, but at last then we have shown to do a reasonable
best process of determining that best/worse combination.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Martin Duke <[email-masked]>
Date: Wed, 19 May 2021 11:24:24 -0700

Toerless,

You have many posts in this thread with some generalized critiques. As a
document author, I am having a lot of trouble extracting what concrete
changes you would like.

It would really help if you filed a PR that showed how you would like the
text to change.

Thanks,
Martin

---

From: Martin Duke <[email-masked]>
Date: Wed, 19 May 2021 11:31:48 -0700

I filed a PR to clarify that the LLC makes the time slot assignment, and
that it MAY not use the listed times or selection criteria, with
consultation, if they turn out to be bad:
https://github.com/mirjak/draft-shmoo-online-meeting/pull/8

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 19 May 2021 21:13:46 +0200

The 0700/1500/2200 UTC alternate option that Martin is proposing in the issue is roughly that 9am start time, depending on which time zone you look exactly for each region and if you look at summer or winter time:

(I personally think that optimises rather for one region in each slot while in my proposal of 0500/1200/2100 UTC I was trying to cover two regions in each slot but respectively with slightly less good time for each but I'm open for discussion and can agree with whatever we can reach consensus on).

> On 19. May 2021, at 20:17, Fred Baker <[email-masked]> wrote:
>

---

From: Martin Duke <[email-masked]>
Date: Wed, 19 May 2021 12:20:25 -0700

The draft is meant to apply to planned online meetings, rather than
in-person ones that are then cancelled. So the notion of "local time" is a
little dangerous though our draft has a rough notion thanks to 1-1-1.

I agree with Mirja: the tradeoff between the times in the draft and the
ones in my PR is that the former tries harder to get two regions into
something like optimal hours, while the PR centers the needs of the "host
region" while also trying to avoid the middle-of-the-night as much as
possible.

Like her, I'm willing to get behind any emerging consensus for the exact
times, as long as they involve roughly 8-hour offsets.

On Wed, May 19, 2021 at 12:13 PM Mirja Kuehlewind <[email-masked]>
wrote:

> The 0700/1500/2200 UTC alternate option that Martin is proposing in the
> issue is roughly that 9am start time, depending on which time zone you look
> exactly for each region and if you look at summer or winter time:
>
> (I personally think that optimises rather for one region in each slot
> while in my proposal of 0500/1200/2100 UTC I was trying to cover two
> regions in each slot but respectively with slightly less good time for each
> but I'm open for discussion and can agree with whatever we can reach
> consensus on).
>
>
>
> > If there is any concept of using times that are consistent with local
> practice, or anything that was used for the first 100+ meetings, a 9:00 AM
> start time should be one of the options in the table.
> >

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 19 May 2021 21:24:50 +0200

Thanks, Martin,

As said in other mails:

I very much appreciate the work Mirja and you ae doing here, but alas or rather hopefully,
we will return to in-person meeting pretty soon, so i think the priority should rather
be to spend time on that option and not spend too much time on this particular limited-use problem,
as much fun as the discussion has been. I will be happy to support WG last call for this,
whatever the remaining details are. I have said what i wanted to say about the technical
details here, but (see above) i am not adament about them. If at all, then more references
to the relevant work such as the questionaires that where done would be welcome to make this
doc a best one-stop-shop reference.

If you do not want to spend the effort to go through IESG with this doc now, it would also
be equally interesting to wrap it up after IETF 111 and hence the likely / hopefully last
solely-online full IETF and use this document also as a reference for our first round of fully virtuals.

(and i am sure we may want to return to the solely-online discussion later on, but that
 then might be a tim for another draft).

Thanks!
    Toerless

-- 
---
[email-masked]

---

From: Jay Daley <[email-masked]>
Date: Thu, 20 May 2021 07:30:47 +1200

Before IETF 108 we did a planning survey that asked people about preferred timeslots (p51) and their own timezones (p33)

	https://www.ietf.org/media/documents/survey-planning-possible-online-meetings-responses.pdf

Jay

> On 20/05/2021, at 3:59 AM, Toerless Eckert <[email-masked]> wrote:
> 

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Wed, 19 May 2021 15:33:55 -0400

--On Wednesday, May 19, 2021 11:31 -0700 Martin Duke
<[email-masked]> wrote:

> I filed a PR to clarify that the LLC makes the time slot
> assignment, and that it MAY not use the listed times or
> selection criteria, with consultation, if they turn out to be
> bad:

Martin,

While, per my prior note, I believe this thread and that part of
the document are better finished than having us invest further
time on them, this PR raises two other questions:

(1) Assuming that this discussion is forever etched on the
memories of those who make decisions in the LLC (and it will
remain in mail archives, Github, etc.), if you put in text
saying that the LLC is free to ignore whatever the document says
on the subject, why not simply remove all of the sample times
and discussion, delegate the authority to the LLC, shorten the
document, and move on?

(2) I fear that, after the experience of the last several
meetings, we know where the text you suggest leads.  The LLC get
feedback from someone [1] saying "the choice is bad".  They
respond --as your text nearly requires-- by launching a
consultation on whether it is really bad.  We repeat and
re-litigate the entire thread, with people claiming badness and
that other plans would be better.  If that discussion does not
lead to a conclusive decision that the times not bad --and I
think we have ample evidence that would not happen -- then they
launch a consultation about proposed alternate times.  Then we
have exactly the same discussion again.  Unless we get very
lucky and that discussion starts far enough in advance or ends
quickly, the LLC ends up making a semi-arbitrary and preemptive
decision in order to let the meeting go forward.  Same result;
endless hours spent in ways that don't make the Internet better.

While my earlier note could be interpreted as a criticism of
what I interpreted as Mirja's "let's settle this once and for
all", I agree with what I think was her main point: it is just
not in the best interests of the IETF community to debate this
endlessly (and/or before every meeting), taking time away from
the IETF doing useful technical/substantive work in the process.
So, if we want to make a rule, let's make a rule (ideally, as I
suggested earlier, providing for periodic but infrequent
reviews).  Or, if we want to delegate this to the LLC, let's
delegate to the LLC and be done with it, doing so in a way that
prefers fewer consultations rather than more unless they see
clear evidence that new consultations will produce significant
new input rather than rehashing.  And I don't want to see a
consultation about the definition of clear evidence either: part
of the goal of the LLC (like IASA before it) should be to reduce
administrative workload on IETF participants so we can get
technical work done, not to transform and increase that workload
into consultations on subjects about which they ought to know
the answers or good approximations to them.   And, if we don't
like the pattern of what the LLC comes up with, then we either
have effective remedies or it is far more important to go to
work on that than to quibble about meetings time for the (I hope
few) all-online meetings we have left.

Disclaimer: I personally don't like the times in your I-D and
think a slightly different model would make better sense.
However, I recognize that everyone is going to be inconvenienced
sometimes and that, by the luck of the draw, some of going to be
inconvenienced more often that others and therefore think we are
better off making a choice and moving forward than continue to
argue about which groups to inconvenience (I write this as I try
to prepare for a non-IETF meeting that effectively starts at
3:30AM in my time zone tomorrow).

best,
   john

[1] Any number of likely candidates can be identified by reading
this list and/or the IETF one for the last several months.

---

From: Martin Duke <[email-masked]>
Date: Wed, 19 May 2021 12:45:12 -0700

Hi Toerless,

While you are right to question my sanity in driving this discussion, here
we are in shmoo/manycouches, where we are supposed to be discussing how
remote meetings should work if we end up doing them again post-pandemic, by
design or due to another emergency.

Thanks for your flexibility on the details.

On Wed, May 19, 2021 at 12:24 PM Toerless Eckert <[email-masked]> wrote:

> > >> > Starting at 9pm might be an acceptable time, but it means ending at
> 3am
> > >> (assuming 6hr
> > >> > packed meeting).   Or, starting at 5am may be unpleasant, but it
> means
> > >> ending
> > >> > at 11am may be just fine.  On the other hand, starting at 00:00
> might
> > >> mean
> > >> Agreed. the implied algo i had in mind would come to the same result.
> And
> > >> hsould
> > >> > significant impact on side meeting time.  Do people get up just in
> time
> > >> for
> > >> > day, and then "stay up" for the meeting, going to sleep as soon as
> it's
> > >> over?
> > >> >
> > >> is high that the person can not hae productive side meetings AND
> official
> > >> meetings -
> > >> unless he/she is very disciplined and lives a week on a different
> clock
> > >> (which
> > >> But lets think of the times when we will have hybrid again. Would an
> AD
> > >> get
> > >> > It seems that we hear from the people who attend very few meetings
> out
> > >> of

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 19 May 2021 21:45:30 +0200

Just quickly a short note on this idea.

> On 19. May 2021, at 20:20, Toerless Eckert <[email-masked]> wrote:
> 

As it is already hard enough to de-conflict the sessions, I would likely say this is an impossible request. There is tooling support for the initial version but then there is a lot of manually tweaking by the secretariat.

---

From: Martin Duke <[email-masked]>
Date: Wed, 19 May 2021 13:01:30 -0700

John,

> and discussion, delegate the authority to the LLC, shorten the

Because the purpose of this WG is to develop a consensus policy for the LLC
to follow, rather than improvising everything as we have had to do
throughout this pandemic. It'd be nice to think through the tradeoffs and
have a well-considered set of time slots that prevent heavy weighting
towards particular time zones (in the way that interims are heavily
weighted to the Atlantic, for example), or endless debates before every
remote meeting about what time to start.

The "free to ignore" text involves some consultation, so that is a glib way
to summarize what it says. I added it in response to concerns that our
proposed times might be overcome by events, but if we'd just prefer rigid
times that's fine with me -- it really doesn't matter much.

> endless hours spent in ways that don't make the Internet better.

That is not the procedure. If the LLC gets feedback that "the choice is
bad", they say that they are implementing the IETF consensus in this
document and the conversation is done. If they decide to change the times
in this document for some reason, they'd better have a good reason because
they will have exactly the issue you fear.

IMO The proposal to simply omit times is what creates procedure; every
remote meeting would require a consultation process for the start time and
result in endless and unresolvable arguments. That is what we are currently
enduring with no fixed remote meeting schedule.

If the text of the PR is not clear on when consultation needs to happen,
please suggest a clearer alternative.

> few) all-online meetings we have left.

Again, the entire intent of this draft is to document IETF consensus so
that this is never an issue again, and failure to publish it results
precisely in the endless debate taht you fear.

> 3:30AM in my time zone tomorrow).

Mirja and I have proposed two different time schedules, and have both
stated that we are happy to agree to any other set of time slots that the
group converges on, provided they provide roughly 8-hour separation to
preserve geographic burden-sharing.

Martin

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 May 2021 20:00:34 -0400

> No, i implied to add up the metrics for all hours of a proposed IETF
    > timing and capture minimum and average.

Well, you need a lot more numbers than you had.

    >> 3am (assuming 6hr packed meeting).  Or, starting at 5am may be
    >> unpleasant, but it means ending at 11am may be just fine.  On the
    >> other hand, starting at 00:00 might mean still being awake at 5am,
    >> which would be a problem.

    > Agreed. the implied algo i had in mind would come to the same
    > result. And hsould hopefully be a good basis to compare any proposed
    > timings.

My interest in being awake at 5am depends upon whether I am just starting the
day, or whether I am about to end the day.  (Or somewhere in between).

    > Maybe simplified: whenever hours 1-5 AM are in play for the official
    > meeting, likelyhood is high that the person can not hae productive side
    > meetings AND official meetings - unless he/she is very disciplined and
    > lives a week on a different clock (which i have read few reports about
    > on our lists).

We live a week on a different clock everytime we travel for IETF.
I starting doing that kind of thing 15 years ago.

    > But lets think of the times when we will have hybrid again. Would an AD
    > get elected into office when she says she is self sponsored and can not
    > afford to travel to all meetings, but when she is not present, she
    > would make herself available all time she would if she was there
    > in-person (e.g.: by adjusting day cycle during IETF week as explained
    > above) ?

We've had a number of such people on the IESG.

    >> Are all attendees equal?  Are some more equal than others?  Should I
    >> get vote for each WG I attend?

    > Folks called M)ichael can only vote for M)ondays.

I guess you get Tuesday *and* Thursday then :-)

    > How is th WG schedule built ? any NP-complete search tool ?

NP-complete doesn't help, as the problem is over-constrained, and the
decision as to who to screw (which constraints to ignore) are context dependant.
The LLC is apparently going to try again.

The only out is to have fewer session requests.

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 20 May 2021 03:05:46 +0200

I hope future virtual meetings will happen, but i don't expect the
1-1-1 virtual meeting starting time discussion to be reuseable then,
because we might just do a 1-v-1 and restart discussion with
"lets start 10 AM local to the city where this meeting would have been".

One way for LLC to get out of the way for a fully virtual meeting:

Everybody who registers/pays attendance before some deadline is given a rank-choice
vote page for the starting time for the registration. E.g. 24 choices for start time, assign
rank 1 (lowest) to 24 (highest). Done. On day of deadline, the start
time meeting is calculated and published.

To me, this is a no-brainer. Every good WG chair does some as lightweight
as possible equivalent for side meetings such as a doodle. For something as large as
a full meeting, we just need to eradicate the late email negotiations that
ensue on doodle's and make it fully automatic.

Cheers
    Toerless

P.S.: In defense of spending time here (against JonC's valid concern):
This is not so different from NP complete Traffic Engineering in networks, so i feel
drawn to this question and can't resist.

On Wed, May 19, 2021 at 12:45:12PM -0700, Martin Duke wrote:
> > > >> meeting, likelyhood

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 20 May 2021 03:58:30 +0200

Thanks Jay, i had lost the URL. Hope Mirja/Martin add it to their doc.
Hope the URL will be is persistent. Somewhat hidden given how
/media, /media/documents is not searchable.

One question/suggestion:

| Q16 If in-person IETF meetings need to be replaced with online IETF
| meetings on a regular basis then what do you think of the following
| approaches for setting the timezone of the virtual IETF meeting?
| 
|                                  Strong   Approve  Neutral   Disapprove Strong
| Poll potential attendees for
| each online IETF meeting          27%       30%      22%       12%        9%
| and pick the best time
| 
| Use the timezone of the
| cancelled in-person IETF          18%       38%      26%       12%        7%
| meeting
| 
Looks to me as if polling was the top option. Was that not the path taken
(i don't remember polls for 109, 110) because LLC saw that this very poll
itself had less participation from AsiaPac than its normal share in IETF
participants - hence leading to the fear that AsiaPac preferences would
be underrepresented in a poll ?

If that was the reason for not doing polling, a technical consideration:
The polling results per Country could be re-weighted by taking IETF
country partcipation stats into account.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 20 May 2021 11:39:58 +0200

> time meeting is calculated and published.

I support.

It is a mechanism, among others, to poll participants desires and adapt 
to that.

It might be more effective that simply pursuing a tradition.

It could be further refined to reach more satisfaction of more people.

Alex

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 20 May 2021 11:55:39 +0200

I think this would be exactly what some of us would like to avoid because that would select a time that a majority wants and would put the pain to same set of people from regions where we have less participation each time.

> On 20. May 2021, at 11:39, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> It is a mechanism, among others, to poll participants desires and adapt to that.
>

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 20 May 2021 15:43:24 +0200

Mirja/Martin:

Would be good to explicitly refer to Jay's 2020 poll which clearly indicates
that polling attendees for timing is the preferred choice and that you decidedly
recommend not to do that because of that issue. Having had LLC don that poll
with that result and then not to relate to that in the draft would be strange.

Has anyone asked a good mathematician ? E.g.: if we would do ranked-choice polling
of attendees, for example with this "assign a preference 1..24 for every of the 24 UTC
starting time offsets" and then run the ranking algorithm not down to one winner, but
to the top three. Should that not be able to derive the top three times one each for
amer/emea/asia ? Maybe ranked choice is not he right class of algo, but i can't believe
there is not an appropriate "find optimum representative averages for of top N(3) cluster" algo.

Std disclaimer: interesting theoretical problem. No priority for near term challenges.

Cheers
    toerlss

-- 
---
[email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 20 May 2021 10:03:47 -0400

There does not seem any point in asking a mathematician or statistician 
until we agree on what the goal is.  What goals should the time 
selection meeting?  What is "fair" for our purposes? For example, is 
makng everyone very unhappy a good answer or a bad one?  It is "fair".

Yours,
Joel

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 20 May 2021 17:06:42 +0200

Le 20/05/2021 à 16:03, Joel M. Halpern a écrit :
> There does not seem any point in asking a mathematician or
> statistician until we agree on what the goal is.  What goals should
> the time selection meeting?  What is "fair" for our purposes? For
> example, is makng everyone very unhappy a good answer or a bad one?
> It is "fair".

Fair playing is a good goal that many people can qualify when they see
it, and that is sufficient very often.

IMHO, one immediate goal is to reduce the wake-up-early pain.

An example of the current pain is: in last online meetings Californians
suffered 2 or 3 times (had to wake up early) whereas Europeans did not
suffer at all (consistently in the afternoon).

An example of reducing the pain is the following: for each of
[Europeans, Americans, Eastern Asians] it has to suffer the
wake-up-early pain at most once, and at least once, during a given time
period, maybe one year, or 24 months, or so.

Other than this wake-up-early pain there are other criteria that could
be used: demographics, wishes of penetration of Internet to certain
regions, wishes of registered participants, and more.

Alex

> Yours, Joel
>> Would be good to explicitly refer to Jay's 2020 poll which clearly
>>  indicates that polling attendees for timing is the preferred
>> choice and that you decidedly recommend not to do that because of
>> that issue. Having had LLC don that poll with that result and then
>> not to relate to that in the draft would be strange.
>> 
>> Has anyone asked a good mathematician ? E.g.: if we would do 
>> ranked-choice polling of attendees, for example with this "assign a
>> preference 1..24 for every of the 24 UTC starting time offsets" and
>> then run the ranking algorithm not down to one winner, but to the
>> top three. Should that not be able to derive the top three times
>> one each for amer/emea/asia ? Maybe ranked choice is not he right
>> class of algo, but i can't believe there is not an appropriate
>> "find optimum representative averages for of top N(3) cluster"
>> algo.
>> 
>> Cheers toerlss
>>> I think this would be exactly what some of us would like to avoid
>>>  because that would select a time that a majority wants and would
>>> put the pain to same set of people from regions where we have
>>> less participation each time.
>>> 
>>> 
>>>>> I hope future virtual meetings will happen, but i don't
>>>>> expect the 1-1-1 virtual meeting starting time discussion to
>>>>> be reuseable then, because we might just do a 1-v-1 and
>>>>> restart discussion with "lets start 10 AM local to the city
>>>>> where this meeting would have been". One way for LLC to get
>>>>> out of the way for a fully virtual meeting: Everybody who
>>>>> registers/pays attendance before some deadline is given a
>>>>> rank-choice vote page for the starting time for the
>>>>> registration. E.g. 24 choices for start time, assign rank 1
>>>>> (lowest) to 24 (highest). Done. On day of deadline, the
>>>>> start time meeting is calculated and published.
>>>> 
>>>> I support.
>>>> 
>>>>> To me, this is a no-brainer. Every good WG chair does some as
>>>>>  lightweight as possible equivalent for side meetings such as
>>>>> a doodle. For something as large as a full meeting, we just
>>>>> need to eradicate the late email negotiations that ensue on
>>>>> doodle's and make it fully automatic. Cheers Toerless P.S.:
>>>>> In defense of spending time here (against JonC's valid
>>>>> concern): This is not so different from NP complete Traffic
>>>>> Engineering in networks, so i feel drawn to this question and
>>>>> can't resist. On Wed, May 19, 2021 at 12:45:12PM -0700,
>>>>> Martin Duke wrote:
>>>>>> Hi Toerless,
>>>>>> 
>>>>>> While you are right to question my sanity in driving this 
>>>>>> discussion, here we are in shmoo/manycouches, where we are
>>>>>> supposed to be discussing how remote meetings should work
>>>>>> if we end up doing them again post-pandemic, by design or
>>>>>> due to another emergency.
>>>>>> 
>>>>>>> I very much appreciate the work Mirja and you ae doing
>>>>>>> here, but alas or rather hopefully, we will return to
>>>>>>> in-person meeting pretty soon, so i think the priority 
>>>>>>> should rather be to spend time on that option and not
>>>>>>> spend too much time on this particular limited-use
>>>>>>> problem, as much fun as the discussion has been. I will
>>>>>>> be happy to support WG last call for this, whatever the
>>>>>>> remaining details are. I have said what i wanted to say
>>>>>>> about the technical details here, but (see above) i am
>>>>>>> not adament about them. If at all, then more references 
>>>>>>> to the relevant work such as the questionaires that where
>>>>>>> done would be welcome to make this doc a best
>>>>>>> one-stop-shop reference.
>>>>>>> 
>>>>>>> If you do not want to spend the effort to go through IESG
>>>>>>> with this doc now, it would also be equally interesting
>>>>>>> to wrap it up after IETF 111 and hence the likely / 
>>>>>>> hopefully last solely-online full IETF and use this
>>>>>>> document also as a reference for our first round of fully
>>>>>>> virtuals.
>>>>>>> 
>>>>>>> (and i am sure we may want to return to the solely-online
>>>>>>>  discussion later on, but that then might be a tim for
>>>>>>> another draft).
>>>>>>> 
>>>>>>> Thanks! Toerless
>>>>>>> 
>>>>>>> 
>>>>>>>> I filed a PR to clarify that the LLC makes the time
>>>>>>>> slot assignment, and that it MAY not use the listed
>>>>>>>> times or selection criteria, with consultation, if they
>>>>>>>> turn out to be bad: 
On Wed, May 19, 2021 at 11:24 AM Martin Duke
>>>>>>>>> You have many posts in this thread with some
>>>>>>>>> generalized critiques. As
>>>>>>> a
>>>>>>>>> document author, I am having a lot of trouble
>>>>>>>>> extracting what concrete changes you would like.
>>>>>>>>> 
>>>>>>>>> It would really help if you filed a PR that showed
>>>>>>>>> how you would like
>>>>>>> the
>>>>>>>>> text to change.
>>>>>>>>> 
>>>>>>>>> Thanks, Martin
>>>>>>>>> 
>>>>>>>>> On Wed, May 19, 2021 at 11:20 AM Toerless Eckert
>>>>>>>>> <[email-masked]>
>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>>> So, this graph sort of assumes the meeting is
>>>>>>>>>>> only 1 minute (or 1hr)
>>>>>>>>>> long.
>>>>>>>>>> 
>>>>>>>>>> No, i implied to add up the metrics for all hours
>>>>>>>>>> of a proposed IETF timing and capture minimum and
>>>>>>>>>> average.
>>>>>>>>>> 
>>>>>>>>>> hsould hopefully be a good basis to compare any
>>>>>>>>>> proposed timings.
>>>>>>>>>> 
>>>>>>>>>>> As I went on about for IETF109,  the choice of
>>>>>>>>>>> starting time also
>>>>>>> has a
>>>>>>>>>>> the meeting, and then stay awake after the
>>>>>>>>>>> meeting?  Or do they have
>>>>>>>>>> their
>>>>>>>>>>> The two modes of do not overlap well for side
>>>>>>>>>>> meeting, and other
>>>>>>>>>> *needed*
>>>>>>>>>> Maybe simplified: whenever hours 1-5 AM are in play
>>>>>>>>>> for the official meeting, likelyhood is high that
>>>>>>>>>> the person can not hae productive side meetings
>>>>>>>>>> AND
>>>>>>> official
>>>>>>>>>> meetings - unless he/she is very disciplined and
>>>>>>>>>> lives a week on a different
>>>>>>> clock
>>>>>>>>>> (which i have read few reports about on our
>>>>>>>>>> lists).
>>>>>>>>>> 
>>>>>>>>>>> While many people attend only one or two WGs, a
>>>>>>>>>>> significant minority
>>>>>>>>>> attend
>>>>>>>>>> By that notion we should hav probably only
>>>>>>>>>> considered Amer/EU friendly times to make mayority
>>>>>>>>>> of IESG/IAB most happy.
>>>>>>>>>> 
>>>>>>>>>> get elected into office when she says she is self
>>>>>>>>>> sponsored and can not afford to travel to all
>>>>>>>>>> meetings, but when she is not present, she would 
>>>>>>>>>> make herself available all time she would if she
>>>>>>>>>> was there in-person (e.g.: by adjusting day cycle
>>>>>>>>>> during IETF week as explained above) ?
>>>>>>>>>> 
>>>>>>>>>>> Are all attendees equal?  Are some more equal
>>>>>>>>>>> than others? Should I get vote for each WG I
>>>>>>>>>>> attend?
>>>>>>>>>> 
>>>>>>>>>> How is th WG schedule built ? any NP-complete
>>>>>>>>>> search tool ? I its extensible, then WG chairs
>>>>>>>>>> might be able to add preference of time/days, and
>>>>>>>>>> then the NP search just figures out the best 
>>>>>>>>>> combination... Of
>>>>>>> course
>>>>>>>>>> results will always suck, but at last then we have
>>>>>>>>>> shown to do a reasonable best process of
>>>>>>>>>> determining that best/worse combination.
>>>>>>>>>> 
>>>>>>>>>> Cheers Toerless
>>>>>>>>>> 
>>>>>>>>>>> -- Michael Richardson <[email-masked]>   .
>>>>>>>>>>> o O ( IPv6 IøT
>>>>>>>>>> consulting )

---

From: Fred Baker <[email-masked]>
Date: Thu, 20 May 2021 12:42:05 -0700

> On May 19, 2021, at 12:28 AM, Mirja Kuehlewind <[email-masked]> wrote:
> 

There has already been quite a bit of discussion on manycounches@. Consensus is a judgment call, but I would frankly be surprised to get speakers that haven't already spoken. My sense of the discussion is that folks setting the agenda are pretty sure they want to start at mid-day or later, and other voices including mine request that we follow the practice of the IETF from IETF 1 through 106, which is to start at 9:00 AM; we started at 10:00 AM in China, Taiwan, and, IIRC, Japan in deference to local custom.

---

From: Martin Duke <[email-masked]>
Date: Thu, 20 May 2021 13:30:23 -0700

Fred,

Personally, I think the issue of when in-person meetings start (1 through
106) is completely orthogonal to when remote meetings start. In-person
meetings are definitely not in scope for this draft.

I will note that
https://github.com/mirjak/draft-shmoo-online-meeting/issues/7 is
specifcally about whether we start mid-day or in the morning of the region
to which a remote meeting is attributed, and the existing text in the draft
defines how to determine that attribution. Mirja and I, who I guess is who
you mean by "folks setting the agenda", actually mildly disagree on this
point in the issue, so I don't understand the basis for your statement.

If "other voices" think it should be in the morning then they should
support the sentiment in the issue. Instead, the reaction has been "this
doesn't matter, we're going back to in-person anyway" (in which case,
you're on the wrong mailing list) or "there should be no consensus
recommendation so that no one complains when the LLC/IESG makes an
arbitrary timing decision" (which ISTM is exactly backwards).

Martin

On Thu, May 20, 2021 at 12:42 PM Fred Baker <[email-masked]>
wrote:

> > Still the aim right now is to see if we CAN reach consensus for one set
> of slots. Let’s have some more discussion and see if it’s possible. I would
> like to at least try and not give up right from the beginning.
>
> There has already been quite a bit of discussion on manycounches@.
> Consensus is a judgment call, but I would frankly be surprised to get
> speakers that haven't already spoken. My sense of the discussion is that
> folks setting the agenda are pretty sure they want to start at mid-day or
> later, and other voices including mine request that we follow the practice
> of the IETF from IETF 1 through 106, which is to start at 9:00 AM; we
> started at 10:00 AM in China, Taiwan, and, IIRC, Japan in deference to
> local custom.
>
> >>> Martin and I worked on an update of the section on Time Zone Selection
> in draft-kuehlewind-shmoo-online-meeting. We propose to try to establish
> consensus on selecting 3 time slots that then can be alternatively used for
> fully online meetings.
> >>
> >> I think the text is too rigid by implying that the three proposed slots
> must be used for ever. It's fine to define some "default" starting times
> but I believe they should be suggestions, not a rule. For example:
> >>
> >> OLD:
> Meetings
> >>>   URL:
> organization
> submission

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 20 May 2021 22:35:29 +0200

And we moved lunch breaks from 1130-1300 to 1230-1400 due to local customs for IETF63 in Paris
(restaurants only opening at 1230), but that one hour extended morning must have been so terrible
for the IETF that next time at IETF83, the secretariat or meeting committee must have persuaded
some restaurants to open at 1200, so we could return to our traditional morning and lunch break schedule
and we learned how to sit around closed restaurants for 30 minutes.

Hope i remember this correctly, not that it matter much other than to emphasize
that "tradition" is a good argument to make for any IETF decision whenever its applicable.
(for better or worse).

Chrers
   Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 20 May 2021 23:00:14 +0200

Not sure what shmoo WG policy is, i am happy if discussion is pushed
to github instead of email, just excuse that folks like me need to be repeatedly
reminded that thats the authors preference beecause that whole github discussion
thing is still not a tradition ;-).

Added:

I would prefer UTC1600 over UTC1500: Matches traditional in-person 9AM for PST location. In a simple metric of "bad-hours 0100-0500", this change would be better by one bad hour for japan and sydney but worse one bad hour for India.

UTC0700 is fine as its traditional in-person 0900 for CET.

UTC0200 would match traditional in-person 1000 for China. In my metric it would also save two bad-hours for Pacific and leaves East-Coast as he unchanged sore looser.

Of course, the "traditional" argument is equivalent to "actually closest to preferred times if this was happening in the particular prime TZ for this meeting". Aka: roughly one third participants who should be most happy (if they where most happy with in-person IETF timings).

Cheers
    Toerless

On Thu, May 20, 2021 at 01:30:23PM -0700, Martin Duke wrote:
> > of slots. Let???s have some more discussion and see if it???s possible. I would

-- 
---
[email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 20 May 2021 17:27:08 -0400

As far as I know, shmoo has never held any discussion of allowing 
discussion to be anywhere other than the email list.  As such, my 
understanding is that the email list is the place to discuss issues. 
github can be used to track issues.  Can be used by the authors for 
documents.  Etc. as specified by the BCP on the topic.  (Capturing 
proposed changes with PRs seems well within those limits, as long as the 
discussion of non-editorial matters takes place on the list.  Which 
seems to be the practice.)

I am only writing this because Toeless' note seemed to indicate 
something different.  Sorry if I am belabouring the obvious.

Yours,
joel

On 5/20/2021 5:00 PM, Toerless Eckert wrote:
> to github instead of email, ...

---

From: Martin Duke <[email-masked]>
Date: Thu, 20 May 2021 14:29:12 -0700

To be clear, I am happy to take reactions to the github issue on the list.
My complaint is that many of the comments here seem detached from the
purpose of the WG, the purpose of the draft, and the actual content of the
draft and concrete proposed changes.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 27 May 2021 22:51:02 -0700

On 5/20/2021 7:03 AM, Joel M. Halpern wrote:
> example, is making everyone very unhappy a good answer or a bad one?  
> It is "fair".
>
There are several plausible definition of "fair", but the one I like is 
"minimax": maximize the gain in the worst scenario, or, in our case, 
minimize the pain for the worst sufferer. This is a strategy that many 
IETF WG follow, when instead of reaching "the best standard for the 
majority" they go for "the standard that everybody can live with".

Let suppose that we can grade pain associated with time as perceived by 
participants. We could say for example that the middle of the night is 
very painful, that the evenings and early morning are somewhat painful, 
and that business hours are just fine. If we have to set a meeting in a 
small group, we will try to fine a time when everybody meets during 
business hours, and failing that a time when nobody needs to be up in 
the middle of the night, so that the worst case is merely somewhat 
painful instead of very painful.

Of course, when the group gets too large, when we look at just one 
meeting, there is no solution. If we have participants in every time 
zone, whatever time we pick, someone will be up in the middle of the 
night. But if we look at a series of maybe 3 meetings, we can most 
probably find solutions in which nobody as to work in the middle of the 
nigh for more than 1 in three meetings. Such solutions end up minimizing 
the pain for the "worst case" participant, which seems like a reasonable 
goal.

-- Christian Huitema

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 28 May 2021 07:52:41 -0400

In addition to Christian's point, for each meeting, it would be better to
be pragmatic than dogmatic. Rather than saying all meetings must start at X
hour (pick one, such as local 9 AM or noon),  we look at each one
individually and try to minimize pain for that coming meeting. For example,
the next meeting is going to use San Francisco daylight savings time as the
local time zone. Given that constraint, the point has previously been made
on this list that starting at 9 AM PDT has overall less pain for most
participants than starting at noon PDT. For other meetings, a different
starting time that's based on the local time zone may be better.

Cheers,
Andy

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 May 2021 10:33:37 -0400

Andrew G. Malis <[email-masked]> wrote:
    > In addition to Christian's point, for each meeting, it would be better
    > to be pragmatic than dogmatic. Rather than saying all meetings must
    > start at X hour (pick one, such as local 9 AM or noon), we look at each
    > one individually and try to minimize pain for that coming meeting.

That really works against distributing the pain.  How will you account for the pain
of person X during meeting A, and then favour them for meeting B?

Overtime, you will optimize the meeting time for the majority, which will
shrink the minority until they shrink to zero.

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 28 May 2021 17:26:28 +0200

look at the metrics Martin and I used for him to measure earlier in the
threa and see if you can come up with something you think would be better.
 Without being able to actually run numbers, suggestions are no very actionable.

IMHO those metrics used where exactly doing that min/max.

Cheers
   Toerless

On Thu, May 27, 2021 at 10:51:02PM -0700, Christian Huitema wrote:
> > making everyone very unhappy a good answer or a bad one?  It is "fair".
> > 
> minimize the pain for the worst sufferer. This is a strategy that many IETF
> WG follow, when instead of reaching "the best standard for the majority"
> they go for "the standard that everybody can live with".
> 
> participants. We could say for example that the middle of the night is very
> painful, that the evenings and early morning are somewhat painful, and that
> business hours are just fine. If we have to set a meeting in a small group,
> we will try to fine a time when everybody meets during business hours, and
> failing that a time when nobody needs to be up in the middle of the night,
> so that the worst case is merely somewhat painful instead of very painful.
> 
> Of course, when the group gets too large, when we look at just one meeting,
> there is no solution. If we have participants in every time zone, whatever
> time we pick, someone will be up in the middle of the night. But if we look
> at a series of maybe 3 meetings, we can most probably find solutions in
> which nobody as to work in the middle of the nigh for more than 1 in three
> meetings. Such solutions end up minimizing the pain for the "worst case"
> participant, which seems like a reasonable goal.
> 
> -- Christian Huitema
> 
> 

-- 
---
[email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Fri, 28 May 2021 11:42:57 -0700

Christian,

> On May 27, 2021, at 10:51 PM, Christian Huitema <[email-masked]> wrote:
> 
> 
>> There does not seem any point in asking a mathematician or statistician until we agree on what the goal is.  What goals should the time selection meeting?  What is "fair" for our purposes? For example, is making everyone very unhappy a good answer or a bad one?  It is "fair".
>> 
> There are several plausible definition of "fair", but the one I like is "minimax": maximize the gain in the worst scenario, or, in our case, minimize the pain for the worst sufferer. This is a strategy that many IETF WG follow, when instead of reaching "the best standard for the majority" they go for "the standard that everybody can live with".
> 
> Let suppose that we can grade pain associated with time as perceived by participants. We could say for example that the middle of the night is very painful, that the evenings and early morning are somewhat painful, and that business hours are just fine. If we have to set a meeting in a small group, we will try to fine a time when everybody meets during business hours, and failing that a time when nobody needs to be up in the middle of the night, so that the worst case is merely somewhat painful instead of very painful.

What makes this challenging is the number of time zones per region.   For example:

The Americas: 4 (UTC—03 to UTC -07)
Europe: 3 (UTC+1 to UTC+3)
Asia:  6 (UTC+3 to UTC+9)
  or
Asia+Pacific 9 (UTC+3 to UTC+12)

It varies based on Daylight or Standard time a little, but Asia/Asia-Pacific makes this all very challenging.

Bob

> 
> Of course, when the group gets too large, when we look at just one meeting, there is no solution. If we have participants in every time zone, whatever time we pick, someone will be up in the middle of the night. But if we look at a series of maybe 3 meetings, we can most probably find solutions in which nobody as to work in the middle of the nigh for more than 1 in three meetings. Such solutions end up minimizing the pain for the "worst case" participant, which seems like a reasonable goal.

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 28 May 2021 20:55:03 +0200

Indeed. And in Martins calculation of metrics that lead to the result
that some "goodness"/"evilness" of different hour changes averaged
just over timezones results in at most 12% differences between different
hour choices. And of course that calculation did not take into account
the number of attends per timezone, so as to be equally fair to everbody
instead of to timezone-cluser-mayorities.

Cheers
    Toerless

On Fri, May 28, 2021 at 11:42:57AM -0700, Bob Hinden wrote:
> The Americas: 4 (UTC???03 to UTC -07)

-- 
---
[email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Fri, 28 May 2021 16:20:31 -0700

On 5/28/2021 11:42 AM, Bob Hinden wrote:
> Christian,
>
>> On May 27, 2021, at 10:51 PM, Christian Huitema<[email-masked]>  wrote:
>>
>>

It is challenging, but it is also not that hard. Instead of having a 
table with three entries, one per region, we would need a table with one 
entry per time zone -- or maybe only for those time zones from which 
some IETF members participate. Then, for a given set of three meetings 
and three proposed times, compute some evaluation of the hardship 
experienced by each type zone. Then tries a couple of tweaks until the 
maximum pain is minimal.

-- Christian Huitema

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 29 May 2021 03:32:34 +0200

How is this different (give or take changes in the hardship metric details)
from what Martin did  calculate and present here on the list ?

On Fri, May 28, 2021 at 04:20:31PM -0700, Christian Huitema wrote:
> It is challenging, but it is also not that hard. Instead of having a table
> with three entries, one per region, we would need a table with one entry per
> time zone -- or maybe only for those time zones from which some IETF members
> participate. Then, for a given set of three meetings and three proposed
> times, compute some evaluation of the hardship experienced by each type
> zone. Then tries a couple of tweaks until the maximum pain is minimal.
> 
> -- Christian Huitema
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 28 May 2021 18:46:13 -0700

> On May 20, 2021, at 1:30 PM, Martin Duke <[email-masked]> wrote:
> 
> 
> Fred,
> 
> Personally, I think the issue of when in-person meetings start (1 through 106) is completely orthogonal to when remote meetings start. In-person meetings are definitely not in scope for this draft.

Given that many and perhaps most of meetings before 107 were “hybrid” in the sense that there were both local and remote attendees, and we expect the same to be true in the future, I’m not sure how they would be orthogonal. If we’re only talking about IETF 111, whatever. But I fully expect future meetings to continue to be hybrid.

> I will note that https://github.com/mirjak/draft-shmoo-online-meeting/issues/7 is specifcally about whether we start mid-day or in the morning of the region to which a remote meeting is attributed, and the existing text in the draft defines how to determine that attribution. Mirja and I, who I guess is who you mean by "folks setting the agenda", actually mildly disagree on this point in the issue, so I don't understand the basis for your statement.

The proposed schedules I have seen suggest neither starting mid- morning nor at noon. They seem to start after lunch, allowing people to sleep in. Maybe I’m wrong in that.

> If "other voices" think it should be in the morning then they should support the sentiment in the issue. Instead, the reaction has been "this doesn't matter, we're going back to in-person anyway" (in which case, you're on the wrong mailing list)

Maybe I’m on the wrong mailing list. What would you recommend?

> or "there should be no consensus recommendation so that no one complains when the LLC/IESG makes an arbitrary timing decision" (which ISTM is exactly backwards).
> 
> Martin
> 
> 
> 
>> On Thu, May 20, 2021 at 12:42 PM Fred Baker <[email-masked]> wrote:
>> 
>>