[lacnog] Participación remota en reuniones de IETF (era Fwd: Re: Requirements for improving IETF remote participation)

Fernando Gont fernando en gont.com.ar
Vie Ene 6 08:42:33 BRST 2012


En LACNOG 2011 se trató el tema de "asistencia a las reuniones de la IETF".

Acá les reenvio un mail de SM, que hace poquito circuló por la lista
general de la IETF.

P.S.: Este es el el tipo de mail que está escrito de manera tan
brillante, que uno debiera darle una "mano" de barniz, y colgarlo en la
pared de la oficina. ;-)

Un abrazo,
Fernando




-------- Original Message --------
Subject: Re: Requirements for improving IETF remote participation
Date: Fri, 06 Jan 2012 02:00:08 -0800
From: SM <sm en resistor.net>
To: IETF Discussion <ietf en ietf.org>
CC: Paul Hoffman <paul.hoffman en vpnc.org>

At 14:05 05-01-2012, Paul Hoffman wrote:
>This first draft compiles many (but certainly not all!) of the 
>comments I have heard so far, but I expect it to change a fair 
>amount in the coming months. If you are active in the IETF, even if 
>you rarely or never come to IETF meetings, your input is welcome.

  'There are two types of participants at the three-times-a-year IETF
   meetings: those who are at the meeting in person ("local attendees")
   and those who are not at the meeting in person but participate by
   following the meeting online ("remote attendees").'

There are more than two types of participants:

  (a) The old boys club

  (b) usual attendees

  (c) "local" attendees

  (d) people who follow the work to see what is going on

  (e) remote attendees

In Section 2:


  "Bar BoFs at regular IETF meetings are not listed above
   because they mostly happen in places where remote participation can't
   be scheduled."

Aren't Bar BoFs informal?  There are also BoFs and "side-meetings"
(draft-eggert-successful-bar-bof-06).

In Section 3:

  "Some participants think the tools are fine and are grateful that they
   exist"

Some participants are grateful because they don't take things for granted.

  "Local attendees don't have a feeling for how many remote attendees
   are just listening like most of the local attendees."

Local attendees do not care about remote participants.  It is left to
the reader to determine whether participant (b) gives any thought to
from participant (c) (language issue).

  "The IETF has years of experience with the two primary tools used at
   its regular meetings"

And yet the same issues occur again and again.

  "At recent IETF meetings, remote attendance is almost always
   less than 10% of local attendance, and is often less than 5%."

It would be interesting to compare local and remote contributions as
attendance can be passive.

  "Further, a WG chair might copy the latest information and send it
   to the WG mailing list, but there can be later changes."

Please see "Topics to Add" at
http://wiki.tools.ietf.org/group/wgchairs/  There hasn't been a lot
of contributions to that web page over the last five years.  The
community has a culture of arguing against each other and getting RFC
published as quickly as possible instead of contributing.

In Section 3.2.3:

  "It has become fairly common for presenters to not have their
   presentations available for distribution until just before the WG
   meeting."

http://www.ietf.org/mail-archive/web/ietf/current/msg70388.html

The following working groups have not submitted their minutes:

 DHC
 PCP
 SOFTWIRE
 TRILL
 MULTRANS (BOF)
 RADEXT
 AVTCORE
 AVTEXT
 CODEC
 P2PSIP
 VIPR
 TSVWG

Is it fairly common for WG Chairs to do nothing until an AD complains?

In Section 3.3:

  "This method of participation often works adequately, but there are
   many places where it fails."

The problem is the audio delay.  Even if the delay was a few seconds
only, that would still happen as it is difficult to manage the
in-room discussion and remote participation at the same time.

  'The presentation ends and is over time, so Carl says "we need
   to move on", so Robert never gets to ask his question.'

And it can discourage Robert from further participation.

  "Sam only volunteered to be scribe because no one else would do it"

Instead of asking for scribes, it might be helpful to explain what is
required of a scribe and see that people are not disadvantaged from
participating when they volunteer.

In Section 3.4:

  "Although the previous section may seem like it is a bit harsh on WG
   chairs"

Stating the facts can be a harsh.

  "Chris cannot do something about the situation without making
   Sam look bad."

And the WG Chair ends up looking bad.

In Section 3.5, I'll mention that Meetecho can also be used for
remote presentations (I suggest asking them about the details instead
of assuming anything).  The problem with any tool is that people
expect them to work.  Some people do not pay attention to the details
and that can cause last minute surprises.

In Section 4:

  "Meeting rooms have many mics: one or two for the chairs,
   one for the presenter, and at least one for other local attendees to
   ask questions."

And sometimes the mic does not work.

In Section 4.1.2:

  "Remote attendees who are speaking over the
   audio must be visible to the local attendees."

That's not a good idea if the remote participant is many time zones
away. :-)

In Section 4.1.3:

  "The instant messaging system must allow any registered user (even
   those registered anonymously) to post messages in the WG's or BoF's
   room."

Isn't the current XMPP approach workable?  What is the meaning of
"those registered anonymously"?

In Section 4.1.4:

  "The input format for slide presentations must  be either PDF
   or PowerPoint."

See long thread at
http://www.ietf.org/mail-archive/web/ietf/current/msg70422.html about PPTX.

In Section 4.2.1:

  "There is no such confusion in the room of local attendees
   because everyone has a name badge."

There is confusion in the room as the name badge may not be visit or
for other reasons.

  "The RPS tools must be available for lunch meetings scheduled by
   the IETF Secretariat, such  as for the Security Directorate"

I object to the non-inclusion of the kangaroo directorate (no offense
intended). :-)

In Section 4.2.2:

  "Mixing remote attendees into this social structure will be a daunting
   task, but one that has been dealt with in many remote participation
   systems"

This is using a technical solution to solve a social problem.  Going
back to my first comment, participant (c) can be useful input to
participant (e) as they share similar constraints.

  "It is not yet clear how the set of remote attendees would be treated."

The same way participant (a) treat participants from outside their group.

in Section 4.4:

  "At recent IETF meetings, there has been very little input from remote
   attendees even when there is a lot in the room, but that may be due
   to the current setup, not lack of interest."

It's difficult to figure which audio stream is available for the
plenaries.  There isn't anyone to channel questions to the mic.

While a lot of the issues covered in draft-ietf-genarea-rps-reqs-00
affect remote participation, they fall outside the scope of the
IAOC.  A session with 20 attendees does not have the same dynamics as
one with 200 attendees.  25% participation in the first group is
workable; it's not for a wider group.  The Remote Participation
Services takes a one size fits all approach.  I suggest not trying to
solve all the problems at once.  The social issues could be discussed
in a separate document.  As for the technical issues, the
requirements could target a small and manageable audience.  It might
be a way to gain more experience about the problems (identify what
works, what can be addressed without too much effort, and what cannot
be fixed).  This could be done as an experiment.

The alternative is to pursue the current approach.  WG Chairs might
be blamed for problems outside their control.

On an unrelated note, the newcomers training is a failure.  It tries
to cover too much in a limited amount of time.  There is limited
interaction.

Regards,
-sm

_______________________________________________
Ietf mailing list
Ietf en ietf.org
https://www.ietf.org/mailman/listinfo/ietf




Más información sobre la lista de distribución LACNOG