Subject: Requirements for improving IETF remote participation

From: Paul Hoffman <[email-masked]>
Date: Thu, 5 Jan 2012 14:05:53 -0800

Greetings again. As Ray Pelletier said on this list earlier, I have been tasked with creating a set of requirements for the IETF's remote participation system (RPS). The first draft is now at <http://tools.ietf.org/html/draft-ietf-genarea-rps-reqs-00>. The discussion of the requirements is happening on the "vmeet" mailing list; see <https://www.ietf.org/mailman/listinfo/vmeet>.

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.

--Paul Hoffman

---

From: SM <[email-masked]>
Date: Fri, 06 Jan 2012 02:00:08 -0800

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

---

From: todd glassey <[email-masked]>
Date: Fri, 06 Jan 2012 04:53:50 -0800

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

The key comment should be "That one can fully participate without having
to bear the expense of continuous travel to the various global spots the
ISOC and IETF place the meetings".

The issue is whether  direct in-person participation is necessary and to
date it has been a mandatory part of holding office inside the IETF so
this also is a concern with how it mandates access for the ADA as well.

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

-- 
Todd S. Glassey
This is from my personal email account and any materials from this
account come with personal disclaimers.

Further I OPT OUT of any and all commercial emailings.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 6 Jan 2012 15:10:26 -0000

> There are more than two types of participants:

Not sure if I count as an "old boy" or not. Don't think I am as old as I feel.

Anyway, I think it important to add to the categories of participants those who
*are* local participants, but who are not in the room where the meeting is
taking place. A number of people attempt to follow multiple parallel meetings
using jabber and/or headphones. For them, speaking participation usually
requires someone to channel over jabber, or a sprint between rooms.

Such participants, like remote participants, would benefit from having the
projector streamed as well as audio.

> (draft-eggert-successful-bar-bof-06).

Yes. Please do not make *any* provisions for remote participation at side
meetings. If the organisers want to arrange that sort of thing they can put
their mobile phone on the bar!

> in-room discussion and remote participation at the same time.

I have found that the audio delay builds. Disconnecting and reconnecting to the
meeting catches you up.

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

It is also not a requirement and may be impractical on low b/w links.
Should I send a short video of me typing this email?

Cheers,
Adrian

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 6 Jan 2012 07:56:58 -0800

Thanks for the comments, but it would be *really* good if you took them to the vmeet mailing list:

On Jan 5, 2012, at 2:05 PM, Paul Hoffman wrote:

> The discussion of the requirements is happening on the "vmeet" mailing list; see <https://www.ietf.org/mailman/listinfo/vmeet>.

You of all people should be aware of the utility of having discussions on one focused mailing list. :-)

--Paul

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 6 Jan 2012 11:48:06 -0500

> Should I send a short video of me typing this email?

In this context "seeing" and "visible" are frequently used to mean that the
fact of participation is visible, not that they are "on screen," and
that is how I interpreted
the above.

For example, WebEx and similar services show you who has joined the
meeting, and who of that list
is speaking, but not (as generally used in the IETF) a video feed. So,
you do get to see who's speaking, even
if you can't see them on screen.

Also, other remote attendees should see this too.

So, how about

    "At a minimum the email addresses of remote attendees who are
speaking over the
     audio must be visible to the local and remote attendees."

I say email addresses should be required because

- you have to give an email address to join any WG mail list and
- we do not require a mapping of email addresses to legal names on WG
mail lists so
- this would allow for exactly the same amount of identification and
privacy as on WG mail lists.

Also, I suggest that we use the phrase "on video" or "on screen" to
make it clear when that is specifically intended. And, on that
subject, can we have a glossary in this document to describe such
specialized jargon, as there is a bunch ?

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 6 Jan 2012 11:50:41 -0500

> their mobile phone on the bar!

I go further : Any meeting that uses IETF RPS is an official IETF
meeting subject to the NOTE WELL and
(where appropriate) IETF rules for announcements and minute taking.

Regards
Marshall

---

From: SM <[email-masked]>
Date: Fri, 06 Jan 2012 11:22:28 -0800

>Not sure if I count as an "old boy" or not. Don't think I am as old as I feel.

You are not in that group.  BTW, it's not age related.

>their mobile phone on the bar!

:-)

>It is also not a requirement and may be impractical on low b/w links.

I didn't see any discussion of low bandwidth access in the 
draft.  Based on a comment posted last year, it looks like it will 
not be part of RPS.

>Should I send a short video of me typing this email?

No. :-)

>You of all people should be aware of the utility of having 
>discussions on one focused mailing list. :-)

Yes, like vip.  :-)

I forgot the following requirement:

   "The specifications shall rely solely upon IETF and other open
    standards for all communications and interactions."

The IETF uses Skype for remote presentations.  It will turn a blind 
eye when the above requirement is bypassed.

>I say email addresses should be required because

There are XMPP identities (JID).  That unfortunately does not map to 
a participant's email address as Jabber never reached "must have" status.

Regards,
-sm

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 6 Jan 2012 14:51:26 -0500

On Fri, Jan 6, 2012 at 2:22 PM, SM <[email-masked]> wrote:
> I didn't see any discussion of low bandwidth access in the draft.  Based on
> a comment posted last year, it looks like it will not be part of RPS.
>
>
> The IETF uses Skype for remote presentations.  It will turn a blind eye when
> the above requirement is bypassed.
>
>
> There are XMPP identities (JID).  That unfortunately does not map to a
> participant's email address as Jabber never reached "must have" status.
>

True. Acquiring data to make that mapping would be useful, but this
might to too much to
require.

Marshall

---

From: Dave Cridland <[email-masked]>
Date: Fri, 06 Jan 2012 20:40:30 +0000

> "those registered anonymously"?

XMPP does allow ANONYMOUS SASL access, although such accounts are  
often restricted. It may mean this.

It might also mean anonymous in the sense of the XEP-0045 room  
occupant, whose real jid can be revealed (or not) as the room's  
configuration dictates.

As a general note, if there is specific functionality that the IETF  
feels is desirable from XEP-0045 or XMPP in general, the XSF would be  
delighted to hear about it - enough XSF participants are also IETF  
participants than merely discussing it here it probably fine, but if  
someone posts things to [email-masked] that'd be great too.

Dave. (Some parts of this message in some respects as XSF chair,  
which isn't a parallel to IETF chair, so probably best I don't dwell  
on it...).
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Dave Cridland <[email-masked]>
Date: Fri, 06 Jan 2012 20:40:29 +0000

> True. Acquiring data to make that mapping would be useful, but this

XEP-0054 provides a method for discovering any email address the  
owner of the jid has provided.

It's very widely supported, although whether people have placed an  
email address into their vCard is entirely up to them.

(Also, JIDs look like, and might even be, the same as an email  
address, however they're fully internationalized, and have different  
resitrictions. Nevertheless, as a stable identifier for a person,  
they're pretty good, relatively hard to spoof, and almost as easy to  
obtain.)

Dave.

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 09 Jan 2012 09:09:48 -0800

> I object to the non-inclusion of the kangaroo directorate (no offense

That implies coverage of a much greater number of rooms, e.g. 16 or more
potentialy. when you count the offices and small breakout rooms in
addition to the 8 scheduled meeting rooms.