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.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html.
https://www.ietf.org/mailman/listinfo/vmeet
