Subject: Make an all-virtual IETF meeting a 24 hour affair

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 27 Feb 2020 08:06:48 -0500

There have been a number of comments that an all-virtual IETF meeting would
be difficult for some set of attendees due to time zone shifting while
they're in their home time zone. While it's impossible to hold a particular
WG session that works for ALL attendees around the world, let the WG chairs
choose, for each WG, what time out of the 24-hour clock works for the
majority of their active participants. It'll be up to the WG chairs to
figure that out for each WG, with the approval of the relevant AD. But
there's no reason why all of the WGs need to meet during the same
"daylight" hours if the meeting is all virtual. WGs could also have
multiple sessions optimized for different parts of the world, to spread the
pain. Just a thought ....

Cheers,
Andy

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Thu, 27 Feb 2020 13:21:02 +0000

+1 , good suggestion, Andrew!

Thanks
Sergio

From: ietf <[email-masked]> On Behalf Of Andrew G. Malis
Sent: Thursday, February 27, 2020 2:07 PM
To: IETF Discussion <[email-masked]>
Subject: Make an all-virtual IETF meeting a 24 hour affair

There have been a number of comments that an all-virtual IETF meeting would be difficult for some set of attendees due to time zone shifting while they're in their home time zone. While it's impossible to hold a particular WG session that works for ALL attendees around the world, let the WG chairs choose, for each WG, what time out of the 24-hour clock works for the majority of their active participants. It'll be up to the WG chairs to figure that out for each WG, with the approval of the relevant AD. But there's no reason why all of the WGs need to meet during the same "daylight" hours if the meeting is all virtual. WGs could also have multiple sessions optimized for different parts of the world, to spread the pain. Just a thought ....

Cheers,
Andy

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 27 Feb 2020 15:31:45 +0100 (CET)

>     Il 27/02/2020 14:06 Andrew G. Malis <[email-masked]> ha scritto:
> 
> 
But people that have to attend multiple WGs that meet on the same day would potentially have to stay up for 24 hours, if each of those WGs chose a different timezone. I think this would be even worse, and it would make it hard to pop into WGs that you do not normally follow, which is one of the added values of IETF meetings.

It is very hard to solve the timezone problem. A "majority of participants" principle would mean that the minority would get the WG scheduled in the night at each and every meeting. Multiple repeated sessions in different timezones mean that the group would be broken up into smaller groups that would not talk to each other (this approach really only works for webinars). Even rotating the timezone from a session to the next has risks, as each session will tend to be disproportionately populated by people in the local timezone, so the set of participants will differ and the consensus could take different directions depending on that, leading each new session to undo the previous one.

In the end, compacting the meeting into the daytime of a specific timezone and rotating the timezone through different continents one meeting at a time seems to be the fairest and less painful way, and that's what almost all global Internet organizations do.

(Perhaps this thread should move to the manycouches list?)

--

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

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 27 Feb 2020 14:57:00 +0000

> But people that have to attend multiple WGs that meet on the same day would potentially have to stay up for 24 hours, if each of those WGs chose a different timezone. I think this would be even wor…

Just a thought: in a fully virtual scenario there is no need to keep
all the meetings within the current 4.5 days wide slot.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 27 Feb 2020 15:57:55 +0100

> But people that have to attend multiple WGs that meet on the same day

Who says that virtual meetings must be contained to all happen in 5 days ?
If you extend it to say 1 month everyone can easily attend those he pays
attention to without any burden or stretch. 5 day IETF sessions are mainly
due to local logistics which are all gone with moving to virtual reality.

Best,
R.

On Thu, Feb 27, 2020 at 3:32 PM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> There have been a number of comments that an all-virtual IETF
> meeting would be difficult for some set of attendees due to time zone
> shifting while they're in their home time zone. While it's impossible to
> hold a particular WG session that works for ALL attendees around the world,
> let the WG chairs choose, for each WG, what time out of the 24-hour clock
> works for the majority of their active participants. It'll be up to the WG
> chairs to figure that out for each WG, with the approval of the relevant
> AD. But there's no reason why all of the WGs need to meet during the same
> But people that have to attend multiple WGs that meet on the same day
> would potentially have to stay up for 24 hours, if each of those WGs chose
> a different timezone. I think this would be even worse, and it would make
> it hard to pop into WGs that you do not normally follow, which is one of
> the added values of IETF meetings.
>
> It is very hard to solve the timezone problem. A "majority of
> participants" principle would mean that the minority would get the WG
> scheduled in the night at each and every meeting. Multiple repeated
> sessions in different timezones mean that the group would be broken up into
> smaller groups that would not talk to each other (this approach really only
> works for webinars). Even rotating the timezone from a session to the next
> has risks, as each session will tend to be disproportionately populated by
> people in the local timezone, so the set of participants will differ and
> the consensus could take different directions depending on that, leading
> each new session to undo the previous one.
>
> In the end, compacting the meeting into the daytime of a specific timezone
> and rotating the timezone through different continents one meeting at a
> time seems to be the fairest and less painful way, and that's what almost
> all global Internet organizations do.
>
> [email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 27 Feb 2020 15:09:39 +0000

> On 27 Feb 2020, at 13:06, Andrew G. Malis <[email-masked]> wrote:
> 

That is not a good idea.

Different WGs would pick different “day” times making it difficult to attend multiple groups.

A better idea is to shift your day to whatever TZ is proposed for the meeting as a whole. That will be no different from what you have to do when travelling, with the advantage of no dehydration and no time lost at the airport.

- Stewart

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 27 Feb 2020 10:16:56 -0500

It really is different than traveling.  I have been trying to figure out 
a simpler case, where I have already shifted my time by traveling, then 
am going home and attending a remote meeting in the time zone where I 
was.  Even for that, trying to figure out when and I how I will eat and 
sleep is complicated.  And that is with my family being very supportive.

Yours,
Joel

---

From: Bob Hinden <[email-masked]>
Date: Thu, 27 Feb 2020 08:01:03 -0800

> On Feb 27, 2020, at 7:09 AM, Stewart Bryant <[email-masked]> wrote:
> 
> 
> 

Right, it would require attendees to stay awake for 24 hours for multiple days.  Not very workable.

Bob

---

From: Kent Watsen <[email-masked]>
Date: Thu, 27 Feb 2020 17:25:32 +0000

The premise of a few ongoing threads (and others over the years) is that there’s a need to preserve having synchronous communication amongst participants.  Stated rationale include the ability to close issues more quickly to just getting to know each other.

Certainly knowing each other’s mannerisms is incredibly important, so as to have that understanding when conversation spills over to the list, but I question how often issues close more quickly, as all is to be closed on the list anyways, which is especially important to do when key participants don’t show, as effectively happens at every meeting already.

I propose moving IETF to pure-virtual *asynchronous* meetings as follows:

1)  let each speaker give a time-bound virtual presentation including both “slides" and “facetime”, whereby “slides” may include other forms of screen share (e.g., to show a demo), and “facetime” is a videobox  showing the presenter talking throughout the presentation (note that this is purposely audio+video, as opposed to audio-only, so as to help people to get to “know” the presenter).

1a)  the presentation is as usual, a focus on the open issues, ideally a preface providing background info for those that aren’t following happenings as closely as others.

1b) the presentation should have "pause points" where feedback is being solicited.  Depending on the nature of the presentation, there may be a pause point for each open issue, or perhaps just one after the entire presentation is complete.  For example, adopted work will likely have a multiplicity of open issues, whereby unadopted work may not.

1c) the presentation must be reviewed by the chairs prior to publication, to ensure it meets IETF guidelines, stays within the allotted time, etc.

2) provide a bounded number of days for responses, responses to responses. etc.  For instance, assuming an upper-limit of three-rounds for exchanges (until the issue has to be taken to the list), this limit may be 3 days.

2a) let each response be either audio-only, audio+video, or audio+video+screenshare.  Text-only responses are not supported (and facetime encouraged!) so as to foster the "getting to know each other” aspect of the experience.

2b) anonymous responses are not permitted.  IETF registration required (same as needed to use the MeetEcho “mic” today).  This also enables private side-channels amongst participants (e.g., “you mentioned FOO, which I’m also interested in…”)

2c) with trepidation I’ll suggest also perhaps not permitting anonymous views (i.e. IETF registration required).  This is in part for the chairs to understand who all viewed the presentation, especially the key participants, so as to gauge consensus.  But this is also in part to aid the IESG in understand overall community interest in the WG and, perhaps, accrue a little revenue to cover the cost of the infrastructure needed to host the “meeting”.

2d) tooling would be needed to support threaded-responses and chair-driving humming on issues.  Whilst registration would be required to hum, the hums can be anonymous (shielded from the chairs), as only the count totals (especially as compared to the virtual blue sheets) matter.

3) Miscellanea

3a) IETF Plenary, etc. would be run the same way.  Perhaps with mandatory viewing prior to participants being able to view any WG “session”.

3b) Same for each WG, there could be a mandatory to view "Chairs Intro” before being able to view any of the other presentations.

3c) The idea is that the entire “meeting” would occur in a single week.  Note that there is no issue with WG overlaps - all WG sessions could open at the same time starting Monday, with the response-cutoff being at the end of the week (skewed for timezones, so no one has to work over the weekend).

3d) Everything would be archived for posterity.

I'll stop here because, hopefully, the gist of the idea is clear and the message is already long, but let me throw out a quick scoring:

PROs:

1) The dependence on physical travel is removed.
2) The dependence on reliable broadband is removed.
3) Everyone can stay comfy in their local timezones.
4) Enables non-English native participants time to digest material.
5) Avoids having to scale infrastructure to support synchronous attendance.
6) Anything else?

CONs:

1) In-person communication benefits are lost.
2) Adhoc meetings (hallway huddles, meals, etc.) are not catered to.
3) Presents an opportunity for corporate gaming (e.g., “prepared" responses)
4) Ability to show off badge-stickers eliminated  ;)
5) No ability to share gifts
6) Anything else?

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 27 Feb 2020 20:34:44 +0100

Kent,

Excellent idea and brilliant summary !

I would add one more PRO (which one could think should be in IETF's best
interest):

*Make those who can not attend IETF meetings equal class citizens of IETF
standardization work. *

Today we see in vast majority attendees from vendors and providers of
various Internet services who pay for its employees to promote their
products and ideas or simply sponsor them to keep up with IETF work. It is
virtually impossible for someone unknown to remotely propose an idea, run
through IETF machine and get RFC out.

I think this is also one of the fundamental problems with limited
innovation in networking space. The doors are generally closed. If you are
a student and want to propose your brilliant P4 idea you are working on it,
testing it and publish via github or docker hub. If you are an enterprise
engineer it is really quite tough to sell value of IETF to anyone. Same for
startups where they watch every dollar spent.

And as others said I do like to participate on site and meet folks, talk
face to face, go for a beer etc ... but I also recognize that this is
getting harder and harder for wider group of people year by year. And I do
think we should really encourage new generations to get involved in
Internet standards globally by making IETF work not only open and read-only
accessible to anyone, but also allowing empowering anyone equally to
propose ideas and standardize them.

Kind regards,
Robert.

On Thu, Feb 27, 2020 at 6:26 PM Kent Watsen <[email-masked]> wrote:

>
> The premise of a few ongoing threads (and others over the years) is that
> there’s a need to preserve having synchronous communication amongst
> participants.  Stated rationale include the ability to close issues more
> quickly to just getting to know each other.
>
> Certainly knowing each other’s mannerisms is incredibly important, so as
> to have that understanding when conversation spills over to the list, but I
> question how often issues close more quickly, as all is to be closed on the
> list anyways, which is especially important to do when key participants
> don’t show, as effectively happens at every meeting already.
>
>
> 1)  let each speaker give a time-bound virtual presentation including both
> “slides" and “facetime”, whereby “slides” may include other forms of screen
> share (e.g., to show a demo), and “facetime” is a videobox  showing the
> presenter talking throughout the presentation (note that this is purposely
> audio+video, as opposed to audio-only, so as to help people to get to
> “know” the presenter).
>
> 1a)  the presentation is as usual, a focus on the open issues, ideally a
> preface providing background info for those that aren’t following
> happenings as closely as others.
>
> 1b) the presentation should have "pause points" where feedback is being
> solicited.  Depending on the nature of the presentation, there may be a
> pause point for each open issue, or perhaps just one after the entire
> presentation is complete.  For example, adopted work will likely have a
> multiplicity of open issues, whereby unadopted work may not.
>
> 1c) the presentation must be reviewed by the chairs prior to publication,
> to ensure it meets IETF guidelines, stays within the allotted time, etc.
>
>
> 2) provide a bounded number of days for responses, responses to responses.
> etc.  For instance, assuming an upper-limit of three-rounds for exchanges
> (until the issue has to be taken to the list), this limit may be 3 days.
>
> 2a) let each response be either audio-only, audio+video, or
> audio+video+screenshare.  Text-only responses are not supported (and
> facetime encouraged!) so as to foster the "getting to know each other”
> aspect of the experience.
>
> 2b) anonymous responses are not permitted.  IETF registration required
> (same as needed to use the MeetEcho “mic” today).  This also enables
> private side-channels amongst participants (e.g., “you mentioned FOO, which
> I’m also interested in…”)
>
> 2c) with trepidation I’ll suggest also perhaps not permitting anonymous
> views (i.e. IETF registration required).  This is in part for the chairs to
> understand who all viewed the presentation, especially the key
> participants, so as to gauge consensus.  But this is also in part to aid
> the IESG in understand overall community interest in the WG and, perhaps,
> accrue a little revenue to cover the cost of the infrastructure needed to
> host the “meeting”.
>
> 2d) tooling would be needed to support threaded-responses and
> chair-driving humming on issues.  Whilst registration would be required to
> hum, the hums can be anonymous (shielded from the chairs), as only the
> count totals (especially as compared to the virtual blue sheets) matter.
>
>
> 3) Miscellanea
>
> 3a) IETF Plenary, etc. would be run the same way.  Perhaps with mandatory
> viewing prior to participants being able to view any WG “session”.
>
> 3b) Same for each WG, there could be a mandatory to view "Chairs Intro”
> before being able to view any of the other presentations.
>
> 3c) The idea is that the entire “meeting” would occur in a single week.
> Note that there is no issue with WG overlaps - all WG sessions could open
> at the same time starting Monday, with the response-cutoff being at the end
> of the week (skewed for timezones, so no one has to work over the weekend).
>
> I'll stop here because, hopefully, the gist of the idea is clear and the
> message is already long, but let me throw out a quick scoring:
>
>
> PROs:
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 27 Feb 2020 17:19:27 -0500

> I propose moving IETF to pure-virtual *asynchronous* meetings as

...  This is worth trying out.

    > 5) No ability to share gifts

The big problem I see is that there could be a trend towards sophisticated video
production processes, with directors, cast, green-screens, CGI graphics.
But, I am still willing to try it out.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Feb 2020 18:01:42 -0500

On 2/27/20 12:25 PM, Kent Watsen wrote:

> I propose moving IETF to pure-virtual*asynchronous*  meetings as follows:
>

IMO expecting people to record video in order to air their views is an 
Extremely Bad Idea, one which would marginalize everyone who doesn't 
have the time/energy/facilities to produce good video.

(IMO expecting people to post Internet-Drafts in xmlrfc format is 
already too much burden.   Expecting video would be far worse than that.)

And it doesn't really matter if the expectation isn't a formal 
requirement, if it turns out to be necessary in practice.

Keith

---

From: Nico Williams <[email-masked]>
Date: Thu, 27 Feb 2020 17:54:08 -0600

On Thu, Feb 27, 2020 at 05:25:32PM +0000, Kent Watsen wrote:
> The premise of a few ongoing threads (and others over the years) is
> that there’s a need to preserve having synchronous communication
> amongst participants.  Stated rationale include the ability to close
> issues more quickly to just getting to know each other.

Mailing lists are our async communication mechanism.

Mailing lists (async comms) have a buffering problem: too much content
can pile up for participants to catch up with.

Physical meetings (sync comms) avoid that by slowing down the pipe by
forcing speakers to take turns.

Things that may help:

 - better IM, with baton passing for turn taking during scheduled
   meetings

    - IM is lower bandwidth than email, still asynchronous, but closer
      to synchronous, and with baton passing it would be synchronous

    - IM can have persistence like email

    - IM archives can be published and posted to the lists

    - given a BUI, IM can be almost as accessible as email

 - ???

If the timescale for a meeting is to be stretched as you suggest (e.g.,
to allow participants to attend within their timezones), then baton
passing may not be as workable.

Nico
--