On 8/2/12 2:53 PM, Marc Petit-Huguenin wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Some comments below:
On 07/30/2012 09:31 AM, Robert Sparks wrote:
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."
I think that this change from SHOULD to MUST would have a better chance to
match (future) reality if my proposal to separate the requirements between
participating and non-participating remote attendees was taken in account.
Here's what I said in a previous review:
"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."
The only issue I see with this is synchronizing with any slide
presentation. Having
additional latency for "read-only" users would be acceptable as long as
the latency
was the same across all streams.
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?
Req 05-12 already says that registration has to verify an email address, so it
seems difficult to add a requirement for how long it will take, knowing that
one can be listening on a device that do not have email access at the time one
changes its mind. Slow emails delivery and spam filters also can make this
difficult to manage.
Well, that's pretty much my point. We should make it clear that if
someone wants
to ask "what did they just say" they're going to have to register in
advance or risk
not being able to ask in a timely fashion. That will cut into any
advantage you might
get from having separate pools of registered vs unregistered participants.
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?)
I think controlling individual streams has its usage.
And I think that was the intent - it just needs to be made clearer.
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?
Or both.
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).
- --
Marc Petit-Huguenin
Personal email: [email protected]
Professional email: [email protected]
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBCAAGBQJQGtqhAAoJECnERZXWan7EqgkP/jtaUpVqVd0DimwgdpW4WmSN
yWzdMCgljYkGt9WWFnRCfOJAzQWCGCQGmsGuk+AVQT7H8Yhvk0S9t1ldZKqVhgrB
Fm0pYMYf4ejplYr29WcKYtn7HaX8aE+PaV1d+CxNZmoHSWDYu9Xqzmpd5VFUzSsi
URQuDaU/Qp1NJxMMl4WbEDnfkLco7+WxzRXRu7iQVLrj0MMeJyYAEIHv0WvtaQ06
oW953fkqDP0OyMkXVmK1/IbUQJlEUYsdamwUcDNAcDOEk95s2ACsUO12YQ5V2Jta
V7R3GVn/fGJqtqizXuFKP50vYTwY87FdTwvUH11TskU1KMzZMIPwP05hm6oNme3H
Wb1M9xgSmHWzqK6i0fGLC7hIPAKv/QMvJ3r8vfdoZSIZwvNES24deWfQBHrlxIyK
jIozFqgNcbyFHoSs+u0pk8ArqEiCjB+RNKwMBxTvwsEti/qvfNZf/D4oLSqQOsut
JqZ1zkepSc9Be0l4lItLjZnQ5xTkbZiHHIoCJ36dZxEspLMHCBMPEUQC3r+DvqyE
VRIdIYeWXlMB3lK7USzTMJg2UV8oxdBztfvwp+wpNG384JbKBSEIfaYsbVNAocP6
gUT94rmWMMnB2aM71QDaiIibJVp4KISj1+r+0t82wiFSzU17b8R5/DMGVy6VEnPe
HsnHmjiEi/GTwfisEI4R
=W4yd
-----END PGP SIGNATURE-----
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html.
https://www.ietf.org/mailman/listinfo/vmeet
