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.) > 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. - s/prevent the use of/prevent other users from selecting/ >> 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... >> 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. -- 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
