Subject: [vmeet] Comments on draft-ietf-genarea-rps-reqs-04

From: Robert Sparks <[email-masked]>
Date: Tue, 29 May 2012 17:28:53 -0500

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.