Subject: [vmeet] Fwd: I-D ACTION:draft-ietf-genarea-rps-reqs-05.txt

From: Robert Sparks <[email-masked]>
Date: Mon, 30 Jul 2012 09:31:36 -0700

Some comments on -05:

Could we change the sentence in 05-04 that starts "When possible, the 
delivery SHOULD" to "The system MUST minimize internal latency, should 
avoid unnecessary architectural latency, and be designed with a goal of 
having less than 200 milliseconds of delay to remote attendees who are 
on fast Internet connections."

Could we change requirement 05-06 to
"Many attendees will be in places with limited bandwidth. Remote 
attendees on 56Kbps Internet connections SHOULD be able to receive 
useable versions of all streaming information. The system SHOULD take 
advantage of higher bandwidth audio and video encodings for participants 
on higher bandwidth connections. The system MUST NOT architecturally 
prevent the use of higher bandwidth encodings."

Requirements like 05-10 assume the system has to know the difference 
between registered and unregistered participants, but there's no clear 
requirement for the software to make this distinction. Can we add a 
requirement that makes it clear to a software developer that this is our 
intent?

Do we want a requirement bounding how long it takes to register to 
participate remotely? If someone who thought they would be listening 
only (as described in 05-11) discovers they need to send a text message 
to ask for clarification, will they be able to negotiate getting 
registered and convincing the software that they are registered before 
the session they are listening to concludes?

In Requirement 05-12, are you assuming the passwords provided are unique 
to the registration? Is the intent to prevent one person from 
registering and sharing that password with many people? If so, is there 
a requirement on the software to restrict the use of that password to 
only one (or a small number) of places at a time? Alternatively, why 
aren't we just reusing datatracker logins here?

Is Requirement 05-23 intended to apply to each attendee independently? 
(Or would having one volume knob for the entire mixed audio feed satisfy 
this requirement?)

In Requirement 05-31, how long do you want the "short text string" to 
be? Is 10 characters enough? Is this intended to be arbitrary text 
provided by the remote participant, or should they be choosing between a 
set of pre-configured options?

Could we delete 05-32 and add "It is not acceptable to simply rely on 
humans reading instant messages to allow remote participants to make the 
request for attention." to the end of 05-31? That appears to be what 
05-32 is really intending to prevent.

05-35 and 05-23 appear redundant?

Is there anything special to call out about working groups that have 
multiple sessions during a meeting week? Are there any requirements on 
the tool (particularly around archiving) to combine these sessions into 
some logical unit associated with the working group? How much 
integration with the meeting schedule information are you expecting? 
Should there be explicit requirements to tie into that data store as 
input (the way the week view at <datatracker.ietf.org/meeting/84/agenda> 
does for example).

RjS

-------- Original Message --------
Subject: 	I-D ACTION:draft-ietf-genarea-rps-reqs-05.txt
Date: 	Tue, 17 Jul 2012 15:04:25 -0700
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

A new Internet-Draft is available from the on-line Internet-Drafts directories.

     Title         : Requirements for Remote Participation Services for the IETF
     Author(s)     : P. Hoffman
     Filename      : draft-ietf-genarea-rps-reqs
     Pages         : 30
     Date          : July 17, 2012
     
The IETF has provided some tools for remote participation in its
    activities for many years, and some IETF participants have also used
    their own tools when they felt the need arise.  The IETF now wishes
    to support enhanced remote participation that is as seamless as
    possible, improving the experience for the remote attendee at the
    IETF regular meetings and interim meetings without degrading the
    experience for the people that are physically present.  Before
    deploying the new tools and services needed for this enhanced remote
    participation, the requirements for such tools and services, and the
    impacts they will make on the current procedures and infrastructure,
    must be defined.  This document is meant to be that definition.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-genarea-rps-reqs-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.