Subject: [vmeet] page 9, draft-ietf-genarea-rps-reqs-01.txt

From: Michael Richardson <[email-masked]>
Date: Mon, 23 Jan 2012 19:55:36 -0500

Text:

 Robert cannot understand what Pete is saying about slide 5, but
      Sam doesn't get Pete's attention until Pete is already on slide 7
      and Pete doesn't want to go back.

is duplicated on bottom of page 8, and mid-page 9.

Those are good anecdotes:  it would be useful to understand which ones
have technological solutions, and which ones have proceedural solutions,
and only appear to be technological problems, because the technology
makes it more obvious that there is a problem.

>One of the often-debated aspects of virtual interim meetings is what
>   time to have them in order to make them available to all
>   participants.  That topic is (thankfully) not covered in this
>   document.

change to:

>One of the often-debated aspects of virtual interim meetings is what
>time to have them in order to make them available to all participants.
>Scheduling of real-time meetings is out of scope for this document.
>What is in scope is the understanding that since many participants will
>be attending at a variety of different times of day (and night), it
>must be acknowledged that no assumption can be made that participants
>will be at an "office".

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Jan 2012 17:23:44 -0800

> is duplicated on bottom of page 8, and mid-page 9.

Fixed.

> makes it more obvious that there is a problem.

Everything has a technological solution, and most things have a procedural solution. :-) If people agree that the requirement is that humans doing IM-to-mic translation be exchanged for remote participants being able to speak themselves, most of these fall away. Such a requirement is both technological (there needs to be a way to get the remote voice in the room and also on the audio stream going out to the other participants), but it also involves procedures such as floor control.

>> must be acknowledged that no assumption can be made that participants

Good catch.

--Paul Hoffman

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Jan 2012 07:20:54 -0500

>>>>> "Paul" == Paul Hoffman <[email-masked]> writes:
    >> Those are good anecdotes: it would be useful to understand which
    >> ones have technological solutions, and which ones have
    >> proceedural solutions, and only appear to be technological
    >> problems, because the technology makes it more obvious that there
    >> is a problem.

    Paul> Everything has a technological solution, and most things have
    Paul> a procedural solution. :-) If people agree that the
    Paul> requirement is that humans doing IM-to-mic translation be
    Paul> exchanged for remote participants being able to speak
    Paul> themselves, most of these fall away. Such a requirement is
    Paul> both technological (there needs to be a way to get the remote
    Paul> voice in the room and also on the audio stream going out to
    Paul> the other participants), but it also involves procedures such
    Paul> as floor control.

   o  Sam is speaking for Robert, and Rachel wants to comment on what
      Robert said.  Unless Sam reads the message as he is walking back
      to his seat, Rachel doesn't get to speak.

What I see is that if we could better formalize the jabber-to-mic 
process, such as by giving that person a *MIC*, and/or seating them at
the front, or making it a function of one of the co-chairs, then it
seems that a lot of the issues go away.  Also most of the issues where
the presenter and/or conversation has gone forward.

Part of the problem is that we waste huge amounts of our in-person time
on presentations rather than conversations.  That's why we have
situations like:

   o  Pete starts his presentation by asking for questions to be held
      until the end.  Robert has a question about slide 5, and is
      waiting until the end of the presentation to post the question in
      the Jabber room.  After slide 7, Len jumps to the mic and

=== where was the chair here?

   o  Chris asks "are there any more questions" while Rachel is typing
      furiously, but she doesn't finish before Chris says "I don't see
      anyone, thanks Pete, the next speaker is...".

=== again, failure of the chair here.

   o  This is the first time Pete is presenting at an IETF meeting, and
      Robert has the first question, which is relayed through Sam. Pete
      stays silent, not responding the question.  Robert can't see

=== here, I don't know why Pete is silent.  What's the root cause here?

   o  Pete says something that the AD sitting at the front of the room
      (not near a mic) doesn't like, and the AD says a few sentences but
      doesn't go to the mic.  The chairs try to repeat what the AD says,
      get it only approximately right, but the remote attendees do not
      hear what really was said and therefore cannot comment
      effectively.

=== this seems to be a problem which has NOTHING to do with remote
    participation, as the people in the back of the room didn't get it
    either.    It's just that the remote participation are AWARE that
    they missed something, while the people in the back of the room
    are just lost, because they couldn't even hear the mumbling of the AD.

>   o  Sam only volunteered to be scribe because no one else would do it,
>      and isn't sitting close to the mic, and gets tired of getting up
>      and down all the time, and doesn't really agree with Robert on a
>      particular issue, so Sam doesn't relay a request from Robert.

multiple failures.  Getting the voice into the room (so people can
better shout at each other) is a technological solution to a proceedural
problem here.  

A lot of focus in the document here seems to be about getting the voice
into the room.  As a remote participant who has participated at IETF and
other meetings, I much prefer the IETF method.   
(Particularly that even with the who-is-talking-now bit, unless we can
enforce push-to-talk {how do we do that on a straight PSTN voice
connection?} we will always have the background
noise/people-eating/etc. problem.)  

a) At 2am, it's much better to type at my house than to talk. 
b) If I type my question, it's in the jabber log. 
c) There is a good chance that someone else might answer me, and my
   question does not need to interrupt.  
d) If the chair/presenter could read the questions directly, when it is
   a presentation rather than a discussion, then maybe we do not need
   a MIC and MIC-line, as everyone could use that!

Back in 1996, when I started at the IETF, we had few computer
projectors, but did have transparencies.  A feature of them is that they
are expensive, hard(er than PPT) to produce, and so there was much more
conversation.  

I come back to this, because central to vmeet requirements is what kind
of meetings are we trying to support?

---

From: John Leslie <[email-masked]>
Date: Tue, 24 Jan 2012 07:45:05 -0500

Michael Richardson <[email-masked]> wrote:
>...

   In fact, not only will some folks be participating from home, there
will be those between flights at airports, those stuck as "pretty faces"
at other conferences, and even folks traveling by automobile; so IMHO
we should cover the need for adapting to backgrond sound as well as
poor bandwidth. IMHO, "not at their office" doesn't convey enough...

--
John Leslie <[email-masked]>

---

From: John Leslie <[email-masked]>
Date: Tue, 24 Jan 2012 08:21:40 -0500

Michael Richardson <[email-masked]> wrote:
> process, such as by giving that person a *MIC*, and/or seating them
> at the front, or making it a function of one of the co-chairs, then
> it seems that a lot of the issues go away.

   Well, no they don't -- but some of the particular examples _could_
be treated by this, so perhaps rewording would help.

   For folks to _participate_ remotely, it should be _their_ voice
that others hear; they need to _hear_ the questions that others have
about what they say; and they need to respond to those questions with
a delay not exceeding about ten seconds.

   Jabber doesn't provide those, even if we make it a front-table
co-chair responsibility. Any of many conferencing solutions do provide
for that.

   And IMHO, all WGCs need to keep their attention on following the
conversations, not on jabber.

> on presentations rather than conversations.

   +100 !!

   However, I fear that's mostly out-of-scope for this document.

   All we can cover here is how remote participation can aid us in
getting actual responses to the presentations we do have. Granted, many
times the presentations won't _deserve_ actual response time; but IMHO
the only way to limit presentation-time is to enforce a cost visible
to the WGCs.

> === again, failure of the chair here.

   Granted, I haven't _been_ the WGC in these situations, but I do have
some sympathy for these "failures". They're under a lot of pressure to
get _some_ progress during the very scarce meeting time; and most of
what they hear sounds to them like "wandering in the weeds".

   IMHO, the best tool on the horizon is virtual interims; and that is
where this document can help.

> into the room.

   True... That's a problem we haven't solved; and without solving it
"remote participation" will be an overly-optimistic name for what
folks like me do.

>  As a remote participant who has participated at IETF and other
> meetings, I much prefer the IETF method.   

   I understand that preference.

   And indeed, as "remote attendance" it's more rewarding.

   But, to tell truth, it's not "participation". Most folks get no
benefit of what you do; and jabber isn't _really_ a part of the
meeting. Often, I find that _nobody_ physically present is paying
any attention to the jabber room, and I don't blame them.

> (Particularly that even with the who-is-talking-now bit, unless we
> can enforce push-to-talk {how do we do that on a straight PSTN
> voice connection?} we will always have the background

   (There's the germ of a good discussion here, but Mike needs to
restate this before I can respond intelligently: I suggest it deserves
a separate named thread.)

> a) At 2am, it's much better to type at my house than to talk. 

   There are precious few homes where you can't find a place to sit
with your laptop and speak quietly into a headset.

> b) If I type my question, it's in the jabber log. 

   So what? Most folks ignore the jabber log: I don't blame them. Even
if they read it, what could they do about it?

> c) There is a good chance that someone else might answer me, and
>    my question does not need to interrupt.  

   That is a legitimate function of jabber. It's just not "participation"
in the meeting.

> d) If the chair/presenter could read the questions directly, when it
>    is a presentation rather than a discussion, then maybe we do not
>    need a MIC and MIC-line, as everyone could use that!

   Are you proposing that _all_ questions must be typed into jabber
(even those from local participants)?

> projectors, but did have transparencies.  A feature of them is that
> they are expensive, hard(er than PPT) to produce, and so there was
> much more conversation.  

   +1

> of meetings are we trying to support?  

   I disagree that that's the question.

   We're trying to support "remote participation"; not trying to force
WGCs into any particular "kind of meeting".

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Jan 2012 08:22:52 -0500

Sorry for how long this is.

On page 13, section 4:

   There is an assumption in this section that the meeting chairs will
   continue to control the flow of the discussion.  That is, if a
   presenter is speaking and a remote attendee wants to ask a question,
   the request to do so goes to the chair, not to the presenter.

I think that this is in fact a requirement.
**Requirement 01-00**: The specification should permit a
              speaker/attendee flow of control where requests go to the
              the chair, not to the presenter.

>   **Requirement 01-02**: All tools in the RPS SHOULD be able to be run
>   on the widest possible array of computers.  This means that they need
>   to be able to be run as an application, from any modern web browser,
>   or from the command line of all of (at least) MacOS version 10.6 or
>   later, Windows 7 or later, and any common Linux distribution produced
>   in 2010 or later. [[[ TODO: Do we need to include IOS and Android
>   platforms in that list? ]]]

I find this requirement too weak, and too specific.
For instance, you said "Linux distribution", but failed to specify
whether it needs to be able to run Sparc or PPC or ARM.  That's why you
get into trouble with Android.  Flash is *available* on
MacOS,Windows7,Linux-x86, and even some Android phones, but not iOS.

So, talking about browsers+operating systems is not useful here.
It is worth saying that the solution must be tested on a set of systems
such as you specify, but in the requirements, I suggest it should say
something like:
   Should work on a browser that implements HTML4 + ECMAScript version FOO.
   Some access should be possible with ECMAScript turned off, at least
   to determine what the actual parameters for the IETF protocols involved.
   Additional features may be enabled via platform specific plugin, but
   it is preferred that such plugins be minimized.

I also object to the word "application", as for me, "web browser" is an
application.  Perhaps you mean to say "applet" or some other
inside-the-browser concept?

Please keep the **Requirement at the beginning, so next paragraph
becomes:

   **Requirement 01-03**: Audio, video, instant
   messaging, and slide streams going to and from remote attendees
   SHOULD be delivered in as close to real-time as is practically
   possible.
   A common complaint with the current RPS is that the streaming audio
   can take more than 10 seconds (and sometimes as much as 30 seconds)
   to reach the remote attendee.  This causes many of the problems
   listed in Section 3.3. 

onward to:

>   **Requirement 01-07**: A remote attendee who doesn't want to
>   identified MUST be able to use an anonymized name when appearing in
>   video and instant messaging.  [[[TODO: Is the anonymity appropriate
>   in light of the "note well" and floor control requirements? ]]]

   **Requirement 01-07**: A remote attendee may register any nickname
   they wish that will be shown to other attendees. (Some consideration
   must be given to the secretariat for good taste). The nickname may
   not be changed on a moment by moment basis, but should remain stable
   during a WG meeting.  A remote attendee must register with a
   "verified" name with the secretariat.

This gets rid of the note-well concern: the secretariat knows who is
who.  This also deals with pseudonyms, and provides some stability to
identify people in the "room"

>   **Requirement 01-11**: Local attendees MUST be able to determine
>   which remote attendee is speaking, unless the remote attendee is
>   using an anonymized display name (see Requirement 01-07).

I think this could read:

   **Requirement 01-11**: Consistent with requirement 01-07, local
   attendees MUST be able to determine the nickname of the remote
   attendee who is speaking.

Note that remote attendees will be FAR EASIER to identify than when
Mumble Mumble from Mumble Corp. speaks at the mic.  For remote
attendees, knowing who is speaking, or even which *MIC* is speaking is
often very very hard.  

Change order of 01-13 to move requirement text to front.

It seems to me that the requirements of section 4.2.2 (seperate
paragraphs please), in particular the TODO, is that the room projector
should be controlled by the computer at the chair's desk.  
It might be appropriate for the IETF to therefore provide each WG room
with a meeting room computer attached to the projector, rather have
the co-chairs provide theirs.

>   As noted earlier, while the current tool's Jabber room is a good way
>   to get questions to the mic, it also becomes a second communications
>   channel that only a few people in the room are participating in.

I've always found this very unusual: why aren't more people in the room
in the Jabber room?   The jabber room proved instantly very very useful
for an official side conversation, in particular for questions of
clarification vs mis-understanding.

>   [[[ TODO: Should there be multiple rooms for a meeting?  There were
>   many requests for a separate "speak into the mic" room, but that is
>   not needed if the requirements in Section 4.2.1 are met.  Is there a
>   need for other rooms? ]]]

I'd like to understand better the problems some WG have had that has led
them to want multiple rooms.  My impression is that the problems are
really the result of people using very poor jabber clients, or having
never used IM before and being overwelmed by communication at more than
a few bits/second.

>   [[[ TODO: Should non-registered people be allowed to read the IM
>   traffic in real time, given that anyone can register anonymously?
>   Should people registered anonymously be allowed to post in IM rooms?
>   ]]]

Yes, our proceedings and archives are all available anonymously after
the fact.  Why shouldn't they be available in real time?
(What does that mean for note-well!!!) 

Only registered attendees may post, whether their pseudonym relates to
their real name, or not.

>**Requirement 01-23**: The slide
>   stream MUST represent the slides as they are projected in the room,
>   allowing the presenter to go back and forth, as well as to edit
>   slides in real time.

>   **Requirement 01-24**: It MUST be made clear to the remote attendees
>   which set of slides, and which slide number, is being currently
>   shown.

Requirement 1-23 would seem to imply 1-24. (But if you drop 1-23, and
the slides are actually downloaded and displayed locally, with an
indication of which slide is current, then 1-24 could live without
1-23).  Also you speak about slides, not computer screens!

Different implementations of showing what is projecting in the room may
make section 4.2.6 irrelevant.  I agree with the analysis in 4.2.6
about when it is useful.  Section 4.2.6 implies that such a text editing
system could be part of the RPS, rather than a feature of the shared
screen.  I'm not sure that this is a good thing.
It is not needed for non-text documents, but there will be attendees
that are unable to figure out how to edit text documents. (That's not a bug)

>   **Requirement 01-25**: The RPS MUST be able to handle both PDF and
>   PowerPoint for distributed slides. [[[ TODO: Is there a requirement
>   to support other formats? ]]] [[[ TODO: For the distributed slides,
>   is there a requirement that animation in PowerPoint be supported, or
>   just static slides? ]]]

"Powerpoint" is an application, not a specification.  There is "PPT"
and "PPTX" as you know.  The RPS MAY support them. The RPS MUST support
ODF (ODP) format, if it supports other than PDF.
Animation of slides is supported in PDF by creating additional slides,
and for the purpose of remote attendees asking questions about
particular state transitions, it is easiest if the states of the "animation"
are represented as slide numbers.  As in, "I have a question about the
transition shown on slide 34..."

>   **Requirement 01-27**: Presenters MUST be able to update their slides
>   on the IETF site up to just before their presentation, if such update
>   is allowed by the chairs.

I believe that this is an anti-requirement.  Removing this possibility
will make people get their slides in at least an hour before the meeting
begins, which is significantly more fair to all attendees.

section 4.3.1:
It seems that some minor changes to the tools version of the agenda
would permit us to refer to audio streams by WG name, dereferencing
through the meeting room schedule to get the room.  That would eliminate
a lot of the confusion as to what document is what.

>   Many remote attendees will be in places with limited bandwidth.
>   **Requirement 01-43**: All streaming information from the RPS MUST be
>   usable over slow Internet connections. [[[ TODO: We need to define
>   "slow" here, or drop the requirement.]]]

So I want to point out that I can remote attend today with just a little
more than dialup.  I am unaware of anyone having set up a service to
stream the IETF audio stream over a PSTN connection, but I can see that
if I did need to do this, I could participate with the MP3 streamed over
PSTN (using Asterisk in the cloud plus a DID) plus 22Kbits dialup for my
jabber.  

So, I suggest:

   **Requirement 01-43**: The RPS will solution will detail bandwidth
   required per participant for various levels of participation.
   The RPS will support a degraded participation mechanism using no more
   than 128kbps of data, possibly using a PSTN connection for voice.

Note that if you are bigvendorcorp.com, your 100Mb/s internet connection
might be also inadequate if you have 200 people attending from that
office.  I have worked on an internal system that included local reflectors
for the presentation feed, and used web-based chat for
questions. (basically, what we have, only with video as well as audio)

>   **Requirement 01-49**: The floor control system MUST allow a chair to
>   easily mute all remote attendees.

   **Requirement 01-49b**: The floor control system MUST allow a chair to
   easily mute all local attendees.

I think that having the various MICs in the room controllable too would
be a very very good thing.  I know that this might be very challenging
to integrate with the hotel's meeting space... but maybe not.

>   **Requirement 01-50**: The floor control system MUST allow a chair to
>   easily allow all remote attendees to speak without requesting
>   permission; that is, the chair MUST be able to easily turn on all
>   remote attendees mics at once.

This implies that the mic might be on, even if the attendee doesn't have
anything to say.

   **Requirement 01-50**: The floor control system MUST allow a chair to
   easily allow all remote attendees to speak without requesting
   permission; that is, the chair MUST be able to put the conference
   into straight push-to-talk mode.

section 4.3.3:

   **Requirement 01-59b**: The RPS SHOULD store all archives in DRM-free
   audio, video and document formats using commonly available codecs
   (patent-free where possible).  These archives should be stored
   in a resting format, requiring no active code ("web application") to replay.

section 4.4.4:

>   **Requirement 01-61**: A system for polling meeting participants,
>   including remote attendees at the same time, MUST be provided.  It
>   MUST be easy to set up a simple poll, and it must be easy for all
>   participants to find the poll and participate. [[[ TODO: Should the
>   RPS also provide a tool that allows yes / no / abstain indications,
>   which comes a lot closer to "voting" than currently is common? ]]]

So, given that you said "meeting participants", it implies that this
system will be used by people in the room.  A computer is not presently
a requirement to attend the WG meeting... I have no problem with this,
but it's worth noting this.

section 5:
   Video for all-remote meetings may be more important than for face-to-
   face meetings. [[[ TODO: Determine if this is true and, if so, the
   additional requirements for all the remote attendees. ]]]

I believe that this is not true.  
Arbitrary shared screens (any application) is probably more important
that video.   For very big groups, being able to all talk at once, but
have the chair sort out the streams and let them out one at a time may
actually be a feature of all-remote meetings.  Computers could
contribute to the meeting order by reducing interruptions.  I've yet to
see this anywhere, but have wanted it regularly.

>   [[[ TODO: What are the requirements for registering?  Virtual interim
>   meetings are generally considered to have a very different feeling
>   than regular IETF meetings; does this affect the idea of
>   registration? ]]]

I think that the same registration system is enough.  In particular, I
do not want my registration to go away between meetings.  If there is a
fee to be paid before I attend, then that needs to be part of the
process.

>7.  Security Considerations
>
>   People who participate remotely in face-to-face IETF meetings might
>   expect the same level of privacy as they have when they participate
>   directly in those meetings.  Some of the proposed tools might cause
>   it to be easier to know which WGs a remote attendee was following.
>   When RPS tools are deployed, the IETF should describe the privacy
>   implications of using such a tool to the users so they can decide

Actually, those who participate locally in meetings have significantly
less privacy than those remote right now.  In particular, many local
participants and chairs do not recall that the MIC and MP3 stream stays
open.  It can be very interesting listening after the meeting is closed.
This isn't even a bug, I think :-)

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Jan 2012 15:40:11 +0200

> the presenter and/or conversation has gone forward.

Or you could do away with jabber-to-mic entirely, and replace it with showing those jabber messages beginning with "mic:" on the big screen. They could be queued with a co-chair controlling it.

> === here, I don't know why Pete is silent.  What's the root cause here?

Maybe in Pete's home country you don't interrupt presentations in the middle. Better to ignore the gaffe.
Maybe Pete barely speaks English and couldn't figure out what was said
Maybe Robert said something about channel bindings and Pete has no idea what that means
Maybe Pete has stage fright

>    are just lost, because they couldn't even hear the mumbling of the AD.

And yet it does happen. Local participants can shout "Mic". Remote participants don't even know that they should.

> noise/people-eating/etc. problem.)  

Remote participants should avoid eating people during sessions.

>   a MIC and MIC-line, as everyone could use that!

And a jabber room becomes a place for old friends to get together and run jokes past each other. See what happens around 17:19 at http://www.ietf.org/jabber/logs/ipsecme/2009-03-27.txt

> of meetings are we trying to support?  

A lot of conversation works well for "how are we progressing on the channel bindings document" Presentations work better for proposing new work. Ideally there would be 5-10 minute presentation and a similar amount of time for conversation. Unfortunately, all the time is taken up by the conversation.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Jan 2012 09:52:03 -0800

[[ Changed the subject line to be useful. ]]

> the presenter and/or conversation has gone forward.

There is a basic assumption in the draft that making the current jabber-to-mic process good enough to significantly improve the remote attendee's ability to participate effectively is not possible. I based that assumption on observing many years of IETF meetings.

Is this assumption actually reasonable? Can we somehow make the jabber-to-mic process good enough to not need remote attendee's voice in the room?

--Paul Hoffman

---

From: Dave Cridland <[email-masked]>
Date: Tue, 24 Jan 2012 18:21:08 +0000

> > the presenter and/or conversation has gone forward.

I'm inclined to agree with Michael (speaking - or rather not - as a  
remote participant at a number of IETFs, now).

> Is this assumption actually reasonable? Can we somehow make the  
> jabber-to-mic process good enough to not need remote attendee's  
> voice in the room?

I don't know for certain, but I think there's a few issues with the  
mic line for remote participants that can be solved, and solving 90%  
of the problems would be a great thing to try.

The only things that change by letting me speak in the room are:

a) I will no longer be channelled by an American voice.

b) I won't be able to get the channeller to play Moe to my Bart  
anymore.

Dave.
-- 
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: Melinda Shore <[email-masked]>
Date: Tue, 24 Jan 2012 10:35:52 -0900

On 01/24/2012 09:21 AM, Dave Cridland wrote:
> b) I won't be able to get the channeller to play Moe to my Bart anymore.

You'd also be able to interrupt the person who's answering you.

I do think the flow of conversation would likely be better but
I tend to think that we're usually sufficiently deliberative
that that's not that much of an issue.  I've been a frequent remote
participant and to the extent that there have been problems (and
there have) it's been because someone hasn't been paying attention
to people not in the room.  I think the suggestion to put someone
with a microphone up front is a very good one.

Melinda

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Jan 2012 17:20:58 -0500

>>>>> "John" == John Leslie <[email-masked]> writes:

    John> +100 !!

    John> However, I fear that's mostly out-of-scope for this document.

Well, then we need a requirements requirement process!

If we are optimizing our meetings for one-way powerpoint presentations
with questions held to the end, answered only by the presenter, then
that argues for one technical solution.

If we are optimizing our meetings for multi-party conversations, then
maybe it's going to be a different technical solution.  

Also, the two things do not scale the same way. My sense is that we
want to use the RPS as much for interim virtual meetings (and "design
team" meetings) as for meetings, so in fact, the multi-party
conversation solution is actually the more interesting one.

... as you said:
    John> IMHO, the best tool on the horizon is virtual interims; and that is
    John> where this document can help.

    John> But, to tell truth, it's not "participation". Most folks get no
    John> benefit of what you do; and jabber isn't _really_ a part of the
    John> meeting. Often, I find that _nobody_ physically present is paying
    John> any attention to the jabber room, and I don't blame them.

I'm really lost about that. *I* sure do when I'm present.

    >> noise/people-eating/etc. problem.)  

    John> (There's the germ of a good discussion here, but Mike needs to
    John> restate this before I can respond intelligently: I suggest it
    John> deserves 
    John> a separate named thread.)

okay.

    >> need a MIC and MIC-line, as everyone could use that!

    John> Are you proposing that _all_ questions must be typed into jabber
    John> (even those from local participants)?

It's an interesting idea, don't you think?

    >> they are expensive, hard(er than PPT) to produce, and so there was

    John> +1

    >> of meetings are we trying to support?  

    John> I disagree that that's the question.

    John> We're trying to support "remote participation"; not trying to force
    John> WGCs into any particular "kind of meeting".

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Jan 2012 17:31:42 -0500

>>> must be acknowledged that no assumption can be made that participants

    John> In fact, not only will some folks be participating from home, there
    John> will be those between flights at airports, those stuck as "pretty faces"
    John> at other conferences, and even folks traveling by automobile; so IMHO
    John> we should cover the need for adapting to backgrond sound as well as
    John> poor bandwidth. IMHO, "not at their office" doesn't convey enough...

Noting that we mostly do not support this currently.  One can certainly
do jabber and streamed mp3 over a 3G connection using either a
smartphone or a laptop+tether/laptop+3G.stick.

I'm relatively unconvinced we will get anything interactive useful for
voice over 3G latencies.  Perhaps if the application captured the voice
comment, and then reliably transmitted it to the chair, who would then
play it (because the chair was maintaining a virtual mic-line, but
participants could make their comment at any time), it would work. 

Maybe LTE solves everything for your use cases, but I think for many
people in many places, it's gonna be a PSTN bridge to get that
interactive voice.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Jan 2012 18:04:34 -0500

>>>>> "Paul" == Paul Hoffman <[email-masked]> writes:
    Paul> [[ Changed the subject line to be useful. ]]

    Paul> On Jan 24, 2012, at 4:20 AM, Michael Richardson wrote:

    >> process, such as by giving that person a *MIC*, and/or seating
    >> them at the front, or making it a function of one of the
    >> co-chairs, then it seems that a lot of the issues go away.  Also
    >> most of the issues where the presenter and/or conversation has
    >> gone forward.

    Paul> There is a basic assumption in the draft that making the
    Paul> current jabber-to-mic process good enough to significantly
    Paul> improve the remote attendee's ability to participate
    Paul> effectively is not possible. I based that assumption on
    Paul> observing many years of IETF meetings.

    Paul> Is this assumption actually reasonable? Can we somehow make
    Paul> the jabber-to-mic process good enough to not need remote
    Paul> attendee's voice in the room?

As a now 8 to 12 time remote participant, often the only one at ipsecme
othar than Yoav,  I find the jabber-to-mic process sufficient, but needs
only a few tweaks.  
Having the chair/meeting-room-controller displaying mic: entries on the
big screen at appropriate times would actually be just fine.  
(Just make sure that the title of the box says "twitter feed", so the
cool kids will understand what it is)

---

From: John Leslie <[email-masked]>
Date: Fri, 27 Jan 2012 10:29:01 -0500

> Well, then we need a requirements requirement process!

   Hmm... let's try that as a thread...

> Also, the two things do not scale the same way.

   +10

> My sense is that we want to use the RPS as much for interim virtual
> meetings (and "design team" meetings) as for meetings, so in fact,
> the multi-party conversation solution is actually the more interesting
> one.

   +1

   Additionally, the >2-way conversations during IETF-week meetings is
the most productive part of those meetings, IMHO.

> I'm really lost about that. *I* sure do when I'm present.

   And who listens to you?

   (I don't blame them because they have so many other things on their
minds that making space for someone they didn't think of as participating
and who isn't "paying his way" is asking more than I wish to ask.)

> It's an interesting idea, don't you think?

   It's a _dreadful_ idea!

   We _have_ IETF-week meetings because some things just don't happen
on mailing-lists. Making IETF-week more like mailing-lists would only
mean it doesn't happen during IETF-week either!

---

From: Wes Beebee <[email-masked]>
Date: Fri, 27 Jan 2012 10:39:22 -0500

> and who isn't "paying his way" is asking more than I wish to ask.)

Which is exactly why there can't be any progress on facilitating remote
participation without addressing the financial question - those in the room
have no incentive to make remote participation work.

- Wes

---

From: John Leslie <[email-masked]>
Date: Fri, 27 Jan 2012 10:41:12 -0500

Michael Richardson <[email-masked]> wrote:
>>>> What is in scope is the understanding that since many participants
>>>> will be attending at a variety of different times of day (and night),
>>>> it must be acknowledged that no assumption can be made that
>>>> participants will be at an "office".
> 
>> John> In fact, not only will some folks be participating from home,
>> John> there will be those between flights at airports, those stuck as
>> John> "pretty faces" at other conferences, and even folks traveling
>> John> by automobile; so IMHO we should cover the need for adapting to
>> John> backgrond sound as well as poor bandwidth. IMHO, "not at their
>> John> office" doesn't convey enough...
> 
> voice over 3G latencies.

   It's pretty easy for folks to adapt to one-second latencies. Where
do you expect worse than that?

> Perhaps if the application captured the voice comment, and then
> reliably transmitted it to the chair, who would then play it (because
> the chair was maintaining a virtual mic-line, but participants could
> make their comment at any time), it would work. 

   This sort of thing may be worth trying, especially for high-noise
cases.

> people in many places, it's gonna be a PSTN bridge to get that

   I don't disagree.

   But I'd like to state "requirements" as what is needed, rather than
how we expect it will be done.

---

From: Brian Rosen <[email-masked]>
Date: Fri, 27 Jan 2012 10:57:06 -0500

> do you expect worse than that?
I've done work on this.  It's true for 1 way audio.  It's not true for 2 way audio.  Communication is severely impaired with more than 150 ms one way delay.   You can't adapt, you are handicapped.  You can force it to work, it's not that communication is impossible, it's just severely impaired.

Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 27 Jan 2012 13:54:46 -0500

>>>>> "John" == John Leslie <[email-masked]> writes:
    John> Are you proposing that _all_ questions must be typed into
    John> jabber (even those from local participants)?

    >> It's an interesting idea, don't you think?

    John>    It's a _dreadful_ idea!

    John>    We _have_ IETF-week meetings because some things just don't
    John> happen on mailing-lists. Making IETF-week more like
    John> mailing-lists would only mean it doesn't happen during
    John> IETF-week either!

okay, I partially agree with you.

How about if we got a few wireless MICs, and rather than have a MIC
lineup, we all used the same "raise-hand-go-into-queue" system in person
as for remote people.  The chair gets to then manage a single queue of
physical and virtual people, with the next 2-3 people in the queue
marked (and on the projector screen), so they would know to acquire a MIC.