Hosnieh Rafiee | 7 Mar 16:45 2014

Re: [89attendees] Remote participation is pretty good

John,

> 
> > Just a far suggestion
> >
> > It would be good that there was possibility like a classroom  that the
> >remote participant could really talk (raise their  hands and the jabber
> >scripter gives him/her permission for
> > microphone) and talk. Then I guess the remote participant  wasn't
> >something different than the real participant ...
> 
> Sadly (from my point of view), we know how to do this at least moderately
> well.  It requires some conventions about how the Jabber user (or other
> remote) participant gets the attention of someone in the room and how the
> person in the room gets the attention of the chair, ideally on a priority
basis to
> compensate for the "slow typing" problem you mention.  It ideally requires
> someone watching the Jabber list carefully who is not also charged with
> scribing and a convention about what entries that are typed into Jabber
are to
> go to the microphone (prefixing comments with "Mic:" has been used a lot.
> 
> In Vancouver, we tried giving Jabber scribes and others who were likely to
> carry messages to the microphone special hats so they could easily be seen
by
> chairs, but I'm not convinced it accomplished anything.  And, of course,
if
> there are conventions, everyone needs to be told about them.
> 
> Of course, more advanced technologies like Meetecho and WebEx can help
(Continue reading)

Hosnieh Rafiee | 7 Mar 13:59 2014

just a suggestion

I copied my message that I sent to All attendees here 
-------------------------------
Just a far suggestion
It would be good that there was possibility like a classroom that the remote
participant could really talk (raise their hands and the jabber scripter
gives him/her permission for microphone) and talk. Then I guess the remote
participant wasn't something different than the real participant 

Of course it is just a wild idea.. and needs infrastructure and works.

Thanks for all jabber scripter, all organizers, all people who helped the
remote participant to feel like they are there.

Hosnieh

IETF Secretariat | 28 Jun 23:07 2013
Picon

New Non-WG Mailing List: vmeet -- IETF remote participation meeting services discussion

A new IETF non-working group email list has been created.

List address: vmeet@...
Archive: http://www.ietf.org/mail-archive/web/vmeet/current/maillist.html
To subscribe: https://www.ietf.org/mailman/listinfo/vmeet

Purpose: Explore, specify and develop improved services for remotely participating in IETF meetings.
Look for eventually supporting virtual meetings that have no physical venue. A modest form of a virtual
meeting is a small-group conference call, such as regularly conducted by the IESG, IAB and IAOC.

For additional information, please contact the list administrators.
John Leslie | 1 Oct 16:22 2012
Picon

WebEx on MacOSX

   After a system update Thursday (10.7.5), WebEx stopped working on
my Mac; and sternly refuses to get any better.

   I find Issue 152617 in chromium:
...
" Chrome autoupdated to 22.0.1229.79, and WebEx fails after the restart.

   Since a number of IETF activities depend on WebEx, I sincerely hope
this will find a resolution soon...

--
John Leslie <john@...>
Simon Pietro Romano | 12 Sep 15:54 2012
Picon

Feedback on draft-ietf-genarea-rps-reqs-07

Hi Paul and vmeetters,

thank you for submitting a revised version (-07) of your draft. Please find below my comments, preceded by the usual disclaimer about the length of my message ;-).
I'll take some excerpts of the draft and let them be followed by my comments/observations. As a general comment, I personally think that the document mixes technical and non-technical requirements for the RPS and I find this a bit confusing. Technical requirements are those directly coupled to the functionality that the RPS will have to make available and would be easily described (or mapped) with a formal modeling approach like UML, in much the same way as with any other software requirements specification. Non-technical requirements are most of the times related to 'policies', which, as I have often claimed on IETF mailing list discussions, are always orthogonal to (and hence independent from)  technical details of a system. I'll try to make this clear in my detailed review, but for the sake of clarity I'll give you an example of what I'm saying right below:

- technical requirement:
**Requirement 07-02**: All tools in the RPS MUST be able to use both IPv4 and IPv6 addresses natively. - non-technical (policy-based) requirement:

**Requirement 07-07**: Both local and remote attendees SHOULD be able to easily contact a single entity who is available throughout the meeting if they find problems with any of the RPS tools, and to get fairly rapid response. This entity needs to be able to handle as RPS tool problems in the meeting rooms, or be able to quickly contact someone who can address those problems. My personal preference would be to have a clear distinction between the above classes of requirements. I think this would also make it easier, in the future, to edit a formal
software requirements specification for potential bidders.

This said, I also found a third category of requirements which in my view fall in a specific class which I would call something like "Requirements for the seamless integration of the future RPS system with the current IETF tools and meeting materials portal". To provide you an example of this third class of requirements, I'll copy/paste a couple below:
**Requirement 07-49**: The RPS MUST automatically convert PowerPoint presentations to PDF and make both available for distribution at the same time. NOTE: in the requirement below I assume that with the expression "make both available for distribution" you are referring to slides publication on the meeting materials page, right? **Requirement 07-50**: 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 WG chairs. NOTE: this last example is in my view actually a mix of a "policy-based" and an "integration" requirement. So, let's get started with the details.
**Requirement 07-09**: The deployment of the tools here MUST take into account making the tools accessible to as many IETF attendees as possible. Such deployment is likely to include technical accommodations for those with visual and hearing disabilities.
 Agreed. But this formulation sounds a bit too generic. What kind of accommodations do you have in mind? As an example, for deaf people, you might be thinking of remote transcription services like "Remote CART" (Communication Access Real-time Translation) captioning, perhaps based on standards like XEP-0301 (Real-Time Text for XMPP -- http://www.xmpp.org/extensions/xep-0301.html). In any case, I would make this part more explicit.

**Requirement 07-10**: All remote attendees at regular IETF meetings and interim meetings who make contributions MUST register with the IETF Secretariat before contributing using any of the RPS tools. This is out of scope for the RPS. I think the basic idea behind section 2.1 is that the IETF secretariat should in the future envisage different registration options (local attendee, remote contributing attendee, remote non-contributing attendee) and the RPS should have access to such information when logging users into the system, so to be capable of associating them with a specific role. In summary, from the RPS's point of view, the only requirement should be that it be capable of supporting different user roles, once again configured through policies. You actually mention something like this when you state, at the end of the section, that "registration might happen in the IETF's Datatracker".

Coming to section 2.3 on Audio, I have already stated on this ML (http://www.ietf.org/mail-archive/web/vmeet/current/msg00548.html) that I strongly believe the priorities you identify in the document are not in the right order. I cannot think of a 'future' RPS which is not capable of reliably supporting audio from remote attendees (both those who have to give presentations and those who just want to make sporadic comments).  I know this brings in some technical obstacles, but I nonetheless insist on this point.
With respect to the specific requirements you identify:

**Requirement 07-20**: The RPS MUST enable relay of messages from IM to the mic to be able to happen as quickly as if the remote attendee was local. It is not clear to me what you mean by "as quickly as if the remote attendee was local".
From a technical standpoint, this should translate in something similar to what I was proposing in the already cited mail, i.e. a solution which automatically announces a request for attention coming, via the jabber room, from a remote: in a few words, if a remote writes a sentence in the chat and lets it be preceded by the [mic] prefix, the RPS should automatically play a predefined 'attention sound' inside the room.

**Requirement 07-21**: The person relaying from IM to the mic must be available throughout the WG meeting. To date, this has been done by WG volunteers in the room. In the future, it could be done the same way, or maybe could be facilitated by hiring people to attend meetings for the specific purpose of being IM-to-mic scribes, this part seems to be out of scope for the RPS
or maybe could be done with tools that allow copy-and-paste of text from IM to a speech synthesizer that reads it to the room. with respect to this part, you should obviously also look after moderation in this case (I copy-and-paste the sentence, but the sentence itself should be read to the room
at the right time, i.e. when the the user's turn to gain the floor arrives).

**Requirement 07-24**: A WG chair MUST be able to control the sound coming from any particular remote attendee. This control MUST allow reduction in volume, all the way to complete muting, of the remote speaker. This requirement, together with others that I will discuss, might be put in a general technical sub-category associated with floor control. With respect to this, I also remark
that if we start talking about moderation and floor control, we have to be careful when identifying roles, meaning that we should avoid making a direct logical link between
the WG chair (who is physically chairing the session) and the moderator (who is actually 'chairing' one or multiple floors/media): the two roles might easily be played by distinct
persons (this is, again, a matter of policies).

**Requirement 07-26**: The audio system used by the RPS MUST be able to integrate with systems commonly used in the venues used for IETF meetings. These venue systems typically include line-level audio outputs from mixers that combine all the mic inputs into a single stream. Some venue systems also allow for headphone level inputs from PCs to be mixed into the audio stream. Right. With reference to this part, you might want to have a look at what we are asking for when it comes to support sessions with Meetecho:

http://recordings.conf.meetecho.com/AudioMixerConfiguration.pdf

**Requirement 07-39**: The IETF Secretariat MUST be able to easily set up the individuals allowed to use the floor control system for a particular meeting and to change the settings at any time, including during the meeting.
Isn't this out of scope for the RPS (policy-related)?

**Requirement 07-40**: The chair SHOULD be able to monitor the sound levels of the audio being delivered to remote attendees to be sure that they can hear what is going on in the room. Beware that this calls for remote monitoring on the client side, which not as easy as one might expect. I would better state that the chair should be able to
'adjust' the sound of the audio of remotes, based on their feedback about the perceived quality.

**Requirement 07-43**: When video is allowed for remote attendees to give presentations (as described in Section 2.3.3), the audience in the room SHOULD be able to see the presenter speaking. Doesn't this simply translate in a requirement to have a secondary beamer in the room which is projecting the remote speaker's video (which would be out of scope for the RPS)?

The whole section 2.5 is in my view related to the third category of requirements I introduced above ("Requirements for the seamless integration of the future RPS system with the current IETF tools and meeting materials portal").
I think that a requirement for the RPS here would just be that of being able to show (in the meeting virtual room) the slides that have been uploaded to the meeting materials page. This might, e.g., be done through a conversion of ppt/pptx/pdf/odp/etc files to whatever the RPS uses internally (e.g. a sequence of images, a low-rate video, etc.).

**Requirement 07-53**: 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. This makes it clear to the remote attendees which set of slides, and which slide number, is being currently shown. Real-time editing of the slides is a tough requirement, indeed. If you think of how this is typically done, the most likely option here would be to have the speaker make his presentation by using some sort of application sharing tool (e.g., by sharing his powerpoint application running on his laptop). I think we should relax this requirement, by associating a MUST to just showing slides and browsing back and forth through the presentation. Slide annotations might then be done by using a whiteboard or some similar tool. What is your feeling about this?

**Requirement 07-60**: A much-lower priority requirement is the ability for group-editing of graphics.
As before, this is a tough one. What do you mean by group editing of graphics? Are you thinking of a sort of shared "Paint", a whiteboard, or what?

**Requirement 07-61**: The RPS MUST support storage and distribution of recordings of the audio, video, and slide presentations for all WG meetings. I would also specify that it is highly desirable to have "synchronized" recordings of the meeting media.

**Requirement 07-64**: Users MUST be able to easily find the archives of the recordings and instant messaging transcripts of a particular WG or BoF session at a particular meeting. This is out of scope for the RPS (policies).

**Requirement 07-66**: The RPS MUST support recording and storage of recordings of the audio, video, and slide presentations of interim meetings as well as regular IETF meetings. Once again, from the RPS perspective, there should be no difference at all between recordings of a regular meeting and recordings of an interim.

**Requirement 07-67**: Given that interim meetings are often run without the help of the IETF Secretariat, making these recordings MUST be easy for WG chairs. Why should the chairs bother about the recordings? I think the RPS should be capable of making recordings in an automated fashion. The chairs
should just don't care about the inner workings.

**Requirement 07-74**: The RPS MUST allow a session to be moved from one room to another during the session This is needed because the Secretariat sometimes need to swap the rooms for WGs when it becomes clear that one is too full and another room has excess space. Apart from the unavoidable association between the mixer in the room and the virtual room in the RPS, this should have no other impact on the RPS itself.

**Requirement 07-79**: Remote attendees MUST be able to easily find all the material they need to effectively participate, including links to audio, video, instant messaging, slides, and so on. This material MUST be available well before the time of the meeting. The page with the meeting material SHOULD allow the remote attendee to easily perform a time conversion to and from the local time at the IETF meeting. Out of scope for the RPS (policies).

**Requirement 07-84**: The RPS SHOULD have a central location where the specifics about how remote participation is supported for every WG interim meeting. This will reduce the problems often seen where messages about how to participate in an interim meeting get buried in the WG mailing list. I don't understand this one, but looks like a policy-related issue.

Hope you'll find this feedback useful.

Cheers,

Simon


















-- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano-7EJwN6hzp+g@public.gmane.org http://www.comics.unina.it/simonpietro.romano <<Molti mi dicono che lo scoraggiamento è l'alibi degli idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/
<div>
    Hi Paul and vmeetters,<br><br>
    thank you for submitting a revised version (-07) of your draft.
    Please find below my comments, preceded by the usual disclaimer
    about the length of my message ;-).<br>
    I'll take some excerpts of the draft and let them be followed by my
    comments/observations. As a general comment, I personally think that
    the document mixes technical and non-technical requirements for the
    RPS and I find this a bit confusing. Technical requirements are
    those directly coupled to the functionality that the RPS will have
    to make available and would be easily described (or mapped) with a
    formal modeling approach like UML, in much the same way as with any
    other software requirements specification. Non-technical
    requirements are most of the times related to 'policies', which, as
    I have often claimed on IETF mailing list discussions, are always
    orthogonal to (and hence independent from)&nbsp; technical details of a
    system. I'll try to make this clear in my detailed review, but for
    the sake of clarity I'll give you an example of what I'm saying
    right below:<br><br>
    - technical requirement: <br>**Requirement 07-02**: All tools in the RPS MUST be able to use both
   IPv4 and IPv6 addresses natively.

    - non-technical (policy-based) requirement:<br><br>**Requirement 07-07**: Both local and remote attendees SHOULD be able
   to easily contact a single entity who is available throughout the
   meeting if they find problems with any of the RPS tools, and to get
   fairly rapid response.  This entity needs to be able to handle as RPS
   tool problems in the meeting rooms, or be able to quickly contact
   someone who can address those problems.

    My personal preference would be to have a clear distinction between
    the above classes of requirements. I think this would also make it
    easier, in the future, to edit a formal<br>
    software requirements specification for potential bidders.<br><br>
    This said, I also found a third category of requirements which in my
    view fall in a specific class which I would call something like
    "Requirements for the seamless integration of the future RPS system
    with the current IETF tools and meeting materials portal". To
    provide you an example of this third class of requirements, I'll
    copy/paste a couple below:<br>**Requirement 07-49**: The RPS MUST automatically convert PowerPoint
   presentations to PDF and make both available for distribution at the
   same time.

NOTE: in the requirement below I assume that with the expression "make both available for distribution" you are referring to slides publication on the 
meeting materials page, right?

**Requirement 07-50**: 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 WG chairs.

    NOTE: this last example is in my view actually a mix of a "policy-based" and an "integration" requirement.

So, let's get started with the details.

    <br>**Requirement 07-09**: The deployment of the tools here MUST take
   into account making the tools accessible to as many IETF attendees as
   possible.  Such deployment is likely to include technical
   accommodations for those with visual and hearing disabilities.

    <br>
    &nbsp;Agreed. But this formulation sounds a bit too generic. What kind of
    accommodations do you have in mind? As an example, for deaf people,
    you might be thinking of remote transcription services like "Remote
    CART" (Communication Access Real-time Translation) captioning,
    perhaps based on standards like XEP-0301 (Real-Time Text for XMPP --
    <a class="moz-txt-link-freetext" href="http://www.xmpp.org/extensions/xep-0301.html">http://www.xmpp.org/extensions/xep-0301.html</a>). In any case, I would
    make this part more explicit.<br><br>**Requirement 07-10**: All remote attendees at regular IETF meetings
   and interim meetings who make contributions MUST register with the
   IETF Secretariat before contributing using any of the RPS tools.
    This is out of scope for the RPS. I think the basic idea behind
    section 2.1 is that the IETF secretariat should in the future
    envisage different registration options (local attendee, remote
    contributing attendee, remote non-contributing attendee) and the RPS
    should have access to such information when logging users into the
    system, so to be capable of associating them with a specific role.
    In summary, from the RPS's point of view, the only requirement
    should be that it be capable of supporting different user roles,
    once again configured through policies. You actually mention
    something like this when you state, at the end of the section, that
    "registration might happen in the IETF's Datatracker".<br><br>
    Coming to section 2.3 on Audio, I have already stated on this ML
    (<a class="moz-txt-link-freetext" href="http://www.ietf.org/mail-archive/web/vmeet/current/msg00548.html">http://www.ietf.org/mail-archive/web/vmeet/current/msg00548.html</a>)
    that I strongly believe the priorities you identify in the document
    are not in the right order. I cannot think of a 'future' RPS which
    is not capable of reliably supporting audio from remote attendees
    (both those who have to give presentations and those who just want
    to make sporadic comments).&nbsp; I know this brings in some technical
    obstacles, but I nonetheless insist on this point. <br>
    With respect to the specific requirements you identify:<br><br>**Requirement 07-20**: The RPS MUST enable relay of messages from IM
   to the mic to be able to happen as quickly as if the remote attendee
   was local.

    It is not clear to me what you mean by "as quickly as if the remote
    attendee was local".<br>
    From a technical standpoint, this should translate in something
    similar to what I was proposing in the already cited mail, i.e. a
    solution which automatically announces a request for attention
    coming, via the jabber room, from a remote: in a few words, if a
    remote writes a sentence in the chat and lets it be preceded by the
    [mic] prefix, the RPS should automatically play a predefined
    'attention sound' inside the room.<br><br>**Requirement 07-21**: The person relaying from IM to the mic must be
   available throughout the WG meeting.  To date, this has been done by
   WG volunteers in the room.  In the future, it could be done the same
   way, or maybe could be facilitated by hiring people to attend
   meetings for the specific purpose of being IM-to-mic scribes, 

    this part seems to be out of scope for the RPS<br>
   or maybe could be done with tools that allow copy-and-paste of text from
   IM to a speech synthesizer that reads it to the room.

    with respect to this part, you should obviously also look after
    moderation in this case (I copy-and-paste the sentence, but the
    sentence itself should be read to the room<br>
    at the right time, i.e. when the the user's turn to gain the floor
    arrives).<br><br>**Requirement 07-24**: A WG chair MUST be able to control the sound
   coming from any particular remote attendee.  This control MUST allow
   reduction in volume, all the way to complete muting, of the remote
   speaker.

    This requirement, together with others that I will discuss, might be
    put in a general technical sub-category associated with floor
    control. With respect to this, I also remark<br>
    that if we start talking about moderation and floor control, we have
    to be careful when identifying roles, meaning that we should avoid
    making a direct logical link between<br>
    the WG chair (who is physically chairing the session) and the
    moderator (who is actually 'chairing' one or multiple floors/media):
    the two roles might easily be played by distinct<br>
    persons (this is, again, a matter of policies).<br><br>**Requirement 07-26**: The audio system used by the RPS MUST be able
   to integrate with systems commonly used in the venues used for IETF
   meetings.  These venue systems typically include line-level audio
   outputs from mixers that combine all the mic inputs into a single
   stream.  Some venue systems also allow for headphone level inputs
   from PCs to be mixed into the audio stream.
    Right. With reference to this part, you might want to have a look at
    what we are asking for when it comes to support sessions with
    Meetecho:<br><br><a class="moz-txt-link-freetext" href="http://recordings.conf.meetecho.com/AudioMixerConfiguration.pdf">http://recordings.conf.meetecho.com/AudioMixerConfiguration.pdf</a><br><br> **Requirement 07-39**: The IETF Secretariat MUST be able to easily
   set up the individuals allowed to use the floor control system for a
   particular meeting and to change the settings at any time, including
   during the meeting.
    <br>
    Isn't this out of scope for the RPS (policy-related)?<br><br>**Requirement 07-40**: The chair SHOULD be able to monitor the sound
   levels of the audio being delivered to remote attendees to be sure
   that they can hear what is going on in the room.

    Beware that this calls for remote monitoring on the client side,
    which not as easy as one might expect. I would better state that the
    chair should be able to <br>
    'adjust' the sound of the audio of remotes, based on their feedback
    about the perceived quality.<br><br>**Requirement 07-43**: When video is allowed for remote attendees to
   give presentations (as described in <a href="http://tools.ietf.org/html/draft-ietf-genarea-rps-reqs-07#section-2.3.3">Section 2.3.3</a>), the audience in
   the room SHOULD be able to see the presenter speaking.

    Doesn't this simply translate in a requirement to have a secondary
    beamer in the room which is projecting the remote speaker's video
    (which would be out of scope for the RPS)?<br><br>
    The whole section 2.5 is in my view related to the third category of
    requirements I introduced above ("Requirements for the seamless
    integration of the future RPS system with the current IETF tools and
    meeting materials portal"). <br>
    I think that a requirement for the RPS here would just be that of
    being able to show (in the meeting virtual room) the slides that
    have been uploaded to the meeting materials page. This might, e.g.,
    be done through a conversion of ppt/pptx/pdf/odp/etc files to
    whatever the RPS uses internally (e.g. a sequence of images, a
    low-rate video, etc.).<br><br>**Requirement 07-53**: 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.  This makes it clear
   to the remote attendees which set of slides, and which slide number,
   is being currently shown.

    Real-time editing of the slides is a tough requirement, indeed. If
    you think of how this is typically done, the most likely option here
    would be to have the speaker make his presentation by using some
    sort of application sharing tool (e.g., by sharing his powerpoint
    application running on his laptop). I think we should relax this
    requirement, by associating a MUST to just showing slides and
    browsing back and forth through the presentation. Slide annotations
    might then be done by using a whiteboard or some similar tool. What
    is your feeling about this?<br><br>**Requirement 07-60**: A much-lower priority requirement is the
   ability for group-editing of graphics.
    <br>
    As before, this is a tough one. What do you mean by group editing of
    graphics? Are you thinking of a sort of shared "Paint", a
    whiteboard, or what?<br><br> **Requirement 07-61**: The RPS MUST support storage and distribution
   of recordings of the audio, video, and slide presentations for all WG
   meetings.

    I would also specify that it is highly desirable to have
    "synchronized" recordings of the meeting media.<br><br> **Requirement 07-64**: Users MUST be able to easily find the archives
   of the recordings and instant messaging transcripts of a particular
   WG or BoF session at a particular meeting.

    This is out of scope for the RPS (policies).<br><br>**Requirement 07-66**: The RPS MUST support recording and storage of
   recordings of the audio, video, and slide presentations of interim
   meetings as well as regular IETF meetings.

    Once again, from the RPS perspective, there should be no difference
    at all between recordings of a regular meeting and recordings of an
    interim.<br><br> **Requirement 07-67**: Given that interim meetings are often run
   without the help of the IETF Secretariat, making these recordings
  MUST be easy for WG chairs.

    Why should the chairs bother about the recordings? I think the RPS
    should be capable of making recordings in an automated fashion. The
    chairs <br>
    should just don't care about the inner workings.<br><br> **Requirement 07-74**: The RPS MUST allow a session to be moved from
   one room to another during the session This is needed because the
   Secretariat sometimes need to swap the rooms for WGs when it becomes
   clear that one is too full and another room has excess space.

    Apart from the unavoidable association between the mixer in the room
    and the virtual room in the RPS, this should have no other impact on
    the RPS itself.<br><br> **Requirement 07-79**: Remote attendees MUST be able to easily find
   all the material they need to effectively participate, including
   links to audio, video, instant messaging, slides, and so on.  This
   material MUST be available well before the time of the meeting.  The
   page with the meeting material SHOULD allow the remote attendee to
   easily perform a time conversion to and from the local time at the
   IETF meeting.

    Out of scope for the RPS (policies).<br><br> **Requirement 07-84**: The RPS SHOULD have a central location where
   the specifics about how remote participation is supported for every
   WG interim meeting.  This will reduce the problems often seen where
   messages about how to participate in an interim meeting get buried in
   the WG mailing list.

    I don't understand this one, but looks like a policy-related issue.<br><br>
    Hope you'll find this feedback useful.<br><br>
    Cheers,<br><br>
    Simon<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
    -- 
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department 
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: <a class="moz-txt-link-abbreviated" href="mailto:spromano@...">spromano@...</a>
          <a class="moz-txt-link-freetext" href="http://www.comics.unina.it/simonpietro.romano">http://www.comics.unina.it/simonpietro.romano</a>

    &lt;&lt;Molti mi dicono che lo scoraggiamento &egrave; l'alibi degli 
   idioti. Ci rifletto un istante; e mi scoraggio&gt;&gt;. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/

  </div>
Russ Housley | 21 Jun 20:08 2012

What should we learn from Google Hangout?

> The RTCWEB interim meeting used a Google hangout.  The remote
> participants were displayed on a separate screen (using a separate
> computer) next to the screen used for the shared presentations.
> It worked extremely well.

So, based on this experience, what should change in the RPS requirements?

Russ
Russ Housley | 20 Jun 21:28 2012

RPS Priority Question: Video

The current draft includes:

2.4.1.  Video from the Room to Remote Attendees

 **Requirement 04-40**: Remote attendees MUST be able to see the
 presenter at a meeting.  A lower-priority requirement is that remote
 attendees SHOULD be able to see who is speaking at the mics in the
 room.

I want to make sure that this represents the community consensus.  Personally, I do not want to put a
cameraman in each meeting room.  Yet, I do not see any way to meet these requirements without (paid) staff to
operate the cameras.

Russ

Marc Petit-Huguenin | 18 Jun 17:24 2012
Picon

draft-ietf-genarea-rps-reqs-04


"  **Requirement 04-01**: The specifications in the RPS MUST rely upon
   IETF and other open standards for all communications and interactions
   wherever possible unless there is an identified gap that cannot be
   met by those standards."

I would add that if such gaps are identified, an effort should be made to
standardize the solutions, at the IETF or elsewhere.

"  **Requirement 04-02**: All tools in the RPS SHOULD be able to be run
   on the widest possible array of computers.  The tools may be stand-
   alone applications, may be run from a modern web browser, or from the
   command line.  The highest priority is that the tool need to be
   available on all of (at least) MacOS version 10.6 or later, Windows 7
   or later, and any common Linux distribution produced in 2010 or
   later.  A lower priority is that the tools be able to run on IOS and
   Android platforms.  The tools MUST NOT rely on Adobe Flash to work
   correctly."

I think that the last sentence should says "... MUST NOT rely on Adobe Flash
in a browser to work correctly." And to be fair, Java applets and Silverlight
applications should also be in the list of technology that must be been used.

"  **Requirement 04-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.  When possible, the
   delivery SHOULD have delays of less than 200 milliseconds to remote
   attendees who are on fast Internet connections.  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 Appendix A.4.1."

I think that these requirements should be relaxed for remote attendees that do
not plan on contributing (i.e. that did not register).  If one has no
intention to comment, it does not matter what the delay is (it still need to
be reasonable, i.e. < 15 seconds).  Removing this constraint would probably
permit to better serve the smaller group of remote attendees who signaled that
they plan to participate by registering.

--

-- 
Marc Petit-Huguenin
Email: marc@...
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
Russ Housley | 13 Jun 22:45 2012

RPS Priority Question: Audio

The current draft says:

2.3.  Audio

 Audio from face-to-face meetings travels in two directions: from the
 room to remote attendees, and (potentially) from remote attendees to
 the room.  Comments on early drafts of this document indicated that
 the latter may not really be a requirement for all attendees if IM-
 to-mic is made predictable.  Given this, reliable IM-to-mic relay for
 comments to speakers is highest priority, audio from remote attendees
 giving presentations is a second priority, and audio from remote
 attendees giving comments to the room is a third priority.

I want to make sure that this represents the community consensus.

My summary:

(1) We have good audio from the room to the remote participant.  Keep doing that.

(2) IM-to-mic is working pretty well too.  Keep doing that, but there might be some improvements that could
be made.

(3) Don't do audio to the meeting room for anyone except a remote presenter for quite some time.

Russ
Russ Housley | 1 Jun 16:46 2012

RPS requirement for IPv6

The IETF has been leading IPv6 adoption by example.  The IETF web site and other servers have supported IPv6
for more than a decade.  In my opinion, the RPS specification needs to explicitly state support for IPv6. 
Right now, it is silent on this topic.

Russ

Robert Sparks | 30 May 00:28 2012

Comments on draft-ietf-genarea-rps-reqs-04

Hi Paul -

I read through draft-ietf-genarea-rps-reqs-04 and have several comments.

Foremost - I think this draft is trying to do too much in one document. 
It's hard to tell what part is a discussing existing policy, what is 
proposed policy, what should turn into requirements for a software 
developer. and what should be operational advice to whoever is running 
whatever software is chosen. If we could explicitly tease those apart, 
probably into separate drafts when we're done, we'd have something that 
would be easier to apply towards change.

Second - the general tone of the draft feels like its proposing a single 
cycle of development and deployment. I would much prefer a message of 
incremental improvement. We need to continue to try different things, 
and we will be learning as we go.

 From a real-time media perspective:

Where did the 200ms number in 04-03 come from? I don't think any hard 
sub-second number is going to help us find the system we really want. 
Can we couch this requirement in terms of what we don't want (the 10-30 
second or multiple minute delays we sometimes experience now), noting 
that the goal is to enable interactive voice conversations so latency 
should be minimized.

The 56Kbps requirement in 04-05 is questionable - did you intend this to 
apply
only to audio? We really shouldn't deprive remote participants that have 
high-bandwidth connections from using high-definition audio, and we 
_really_ don't want to live with sub-56Kbps streaming video. Are you 
perhaps looking for a requirement that different recipients be allowed 
to choose different bitrates?

The remainder of this is a collection of smaller points in document order:

04-04: suggest s/have the same delays/be reasonably synchronized/

04-06: This is a good example of a requirement where we should tease 
apart the policy and operation advice from what we would require of any 
new software.

Section 2.1 first paragraph, last sentence - This example, while 
probably accurate, is speculation as phrased, and the discussion of it 
probably belongs in some other document.

04-08 and 04-09 are written in terms of policy instead of software 
requirements. Is there a requirement here that the software not allow 
someone to speak, or share a slide, or enter IM unless they've 
registered? Is that just registration of the identity with the 
secretariat, or registration for this particular meeting?How is the 
software supposed to know the difference between a listen only attendee 
and a contributor?

Why have any discussion of cost for remote registration in this document?

04-17 : is this a requirement on software, or operational advice? 04-18 
looks like policy, rather than software. Both of these seem to meet the 
out of scope requirement in the Note you have at the end of this section.

04-23: I think you wrote this thinking "systems" meant speakers, 
microphones, and mixers. It would be better to make it explicit. Do we 
also want to require integration with built in projectors and cameras?

04-30: What is the real requirement here? This is a requirement to not 
use a mechanism as stated, and I'm not sure what the assumptions around 
the mechanism to be avoided are. What's wrong if the floor control tool 
happens to be implemented inside the instant messaging system? Is this 
only trying to say that it's not acceptable to have humans watch for 
keywords and implement floor control socially or something like that?

04-37: This is again policy/mechanism. Why is the requirement "simple 
passwords"? Why don't we have requirements that discuss reusing the 
identities we already have with IETF systems (like the tracker login).

There is an odd conflict between 04-40 and 04-41: Either they are 
contradictory (if "who is speaking at the mics in the room" is the same 
as "local attendees at any mic in the meeting") or really odd (if the 
first phrase is the presenter at the front of the room, and the second 
are people at the mic lines on the floor).

04-47 through 50: It would be good to clarify what you mean by 
distribution. I think you are assuming it means "available for download" 
as opposed to "will be streamed synchronized with the presenter".

04-52 requires that slides be editable in real-time.  It would be good 
to be clear whether these edits supposed to be made available for 
distribution in real-time?  How does this interact with the requirement 
to automatically convert powerpoint to pdf?

04-57 - Why does this shared editing have a different latency 
requirement from other forms of media? Why shouldn't this be "reasonably 
synchronized" along with everything else?

04-64 - Why is this SHOULD and not MUST? Having an easy mechanism for 
indexing the audio stream in real-time is a request I've heard for 
years, and the suggested uses go beyond noting changes in speaker.

04-66: s/are run/are often run/

I think 04-67 needs a _lot_ more discussion. That looks like a voting 
tool as written.

04-72 (testing) needs more discussion. Is this simply a test that audio 
and video work? Or are you wanting to test that a remote presenter can 
edit slides? Is there any requirement here on the software, or is this 
just operational guidance?

I have no idea what 04-75 is asking for. Is this saying a WG chair 
should have a form from which the tools to be used at a WG meeting will 
be selected? What does "prepare" mean in this requirement?

04-78 : It should be clearer that this is the "call here to ensure your 
voice and video are set up correctly" test - checking the client 
configuration, not whether the service itself is working. It should also 
be clear whether this is served from a place that never changes, or if 
the server end of this test is expected to move to the physical meeting 
venues.


Gmane