On 8/2/12 9:29 PM, John Leslie wrote:
Marc Petit-Huguenin <[email protected]> wrote:
On 07/30/2012 09:31 AM, Robert Sparks wrote:
Some comments on -05:
In general, I wish to support Robert's suggestions, but Marc has some
good points.
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 don't know how difficult that 200 msec target will be; but I do note
that some participants will be over 10,000 miles away, and "fast" Internet
connections sometimes have 50 msec last-hop delay. I would prefer to
target about 100 msec for packets to leave the actual servers bound for
the participant. (I'm quite soft on whether 100 msec is the right target.)
You are suggesting a more concrete definition of "unnecessary
architectural latency".
I think we'll get a better result if we push for that to be as small as
we can make it, rather
than try to explicitly create a budget for internal latency vs
transmission latency.
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
(I had interpreted the language to only apply to "participants".)
(it still needs to be reasonable, i.e. < 15 seconds).
15 seconds is painfully long, but I don't think we mean to constrain
this number for mere listeners.
Removing this constraint would probably permit to better serve the
smaller group of remote attendees who signaled that they plan to
participate by registering."
I can't recall a recent IETF-week where there wasn't sufficient
outgoing bandwidth to serve hundreds of participant 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."
Just a few bits of wordsmithing:
- s/all streaming information/streaming information/
At 56kbps, I would want to select the most important streams.
Agreed, but you should still be able to get something usable if you
asked for all
the streams (but almost certainly not as nice as you would get if you
limited the
input to what you considered important).
Do we have a requirement captured somewhere to let a remote participant
_choose_
which streams to receive if multiple streams are available? On a fast
skim, I'm not finding
it (though it could be inferred from the text after 05-52.
- s/prevent the use of/prevent other users from selecting/
wfm
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?
(Agree.)
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.
I agree with Marc it's hard to set such limits.
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?
Good questions!
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.
I can imagine cases where the chair would want to enable two remote
attendees to interrupt each other: s/he would need individual volume
controls to make this work well.
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.
Hmm...
10 characters is rather limiting... I would have interpreted "short"
to mean something under 72 characters. Paul's examples outline the sort
of things one might type -- it would help some folks if there were a
pull-down list to choose from...
Paul - is this enough to build some clarifying text with?
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.
5-32 is perhaps overly strong using "MUST"; but I think there needs
to be a mechanism separate from the jabber stream. I guess I'd let Paul
keep 5-32 but suggest it's perhaps shy of a MUST that the mechanism be
"part of the floor control tool".
05-35 and 05-23 appear redundant?
True... I think Paul had in mind the difference between limiting
volume and removing the user to reduce clutter.
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).
I don't agree any of this needs to be part of the tool. These sound
like human-intensive task better done by the Secretariat or volunteers
appointed by the WGCs.
We should at least keep an eye towards making it easy for the
secretariat or volunteers.
--
John Leslie <[email protected]>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html.
https://www.ietf.org/mailman/listinfo/vmeet
