Sorry for how long this is. On page 13, section 4:
There is an assumption in this section that the meeting chairs will
continue to control the flow of the discussion. That is, if a
presenter is speaking and a remote attendee wants to ask a question,
the request to do so goes to the chair, not to the presenter.
I think that this is in fact a requirement.
**Requirement 01-00**: The specification should permit a
speaker/attendee flow of control where requests go to the
the chair, not to the presenter.
> **Requirement 01-02**: All tools in the RPS SHOULD be able to be run
> on the widest possible array of computers. This means that they need
> to be able to be run as an application, from any modern web browser,
> or from the command line of all of (at least) MacOS version 10.6 or
> later, Windows 7 or later, and any common Linux distribution produced
> in 2010 or later. [[[ TODO: Do we need to include IOS and Android
> platforms in that list? ]]]
I find this requirement too weak, and too specific.
For instance, you said "Linux distribution", but failed to specify
whether it needs to be able to run Sparc or PPC or ARM. That's why you
get into trouble with Android. Flash is *available* on
MacOS,Windows7,Linux-x86, and even some Android phones, but not iOS.
So, talking about browsers+operating systems is not useful here.
It is worth saying that the solution must be tested on a set of systems
such as you specify, but in the requirements, I suggest it should say
something like:
Should work on a browser that implements HTML4 + ECMAScript version FOO.
Some access should be possible with ECMAScript turned off, at least
to determine what the actual parameters for the IETF protocols involved.
Additional features may be enabled via platform specific plugin, but
it is preferred that such plugins be minimized.
I also object to the word "application", as for me, "web browser" is an
application. Perhaps you mean to say "applet" or some other
inside-the-browser concept?
Please keep the **Requirement at the beginning, so next paragraph
becomes:
**Requirement 01-03**: Audio, video, instant
messaging, and slide streams going to and from remote attendees
SHOULD be delivered in as close to real-time as is practically
possible.
A common complaint with the current RPS is that the streaming audio
can take more than 10 seconds (and sometimes as much as 30 seconds)
to reach the remote attendee. This causes many of the problems
listed in Section 3.3.
onward to:
> **Requirement 01-07**: A remote attendee who doesn't want to
> identified MUST be able to use an anonymized name when appearing in
> video and instant messaging. [[[TODO: Is the anonymity appropriate
> in light of the "note well" and floor control requirements? ]]]
**Requirement 01-07**: A remote attendee may register any nickname
they wish that will be shown to other attendees. (Some consideration
must be given to the secretariat for good taste). The nickname may
not be changed on a moment by moment basis, but should remain stable
during a WG meeting. A remote attendee must register with a
"verified" name with the secretariat.
This gets rid of the note-well concern: the secretariat knows who is
who. This also deals with pseudonyms, and provides some stability to
identify people in the "room"
> **Requirement 01-11**: Local attendees MUST be able to determine
> which remote attendee is speaking, unless the remote attendee is
> using an anonymized display name (see Requirement 01-07).
I think this could read:
**Requirement 01-11**: Consistent with requirement 01-07, local
attendees MUST be able to determine the nickname of the remote
attendee who is speaking.
Note that remote attendees will be FAR EASIER to identify than when
Mumble Mumble from Mumble Corp. speaks at the mic. For remote
attendees, knowing who is speaking, or even which *MIC* is speaking is
often very very hard.
Change order of 01-13 to move requirement text to front.
It seems to me that the requirements of section 4.2.2 (seperate
paragraphs please), in particular the TODO, is that the room projector
should be controlled by the computer at the chair's desk.
It might be appropriate for the IETF to therefore provide each WG room
with a meeting room computer attached to the projector, rather have
the co-chairs provide theirs.
> As noted earlier, while the current tool's Jabber room is a good way
> to get questions to the mic, it also becomes a second communications
> channel that only a few people in the room are participating in.
I've always found this very unusual: why aren't more people in the room
in the Jabber room? The jabber room proved instantly very very useful
for an official side conversation, in particular for questions of
clarification vs mis-understanding.
> [[[ TODO: Should there be multiple rooms for a meeting? There were
> many requests for a separate "speak into the mic" room, but that is
> not needed if the requirements in Section 4.2.1 are met. Is there a
> need for other rooms? ]]]
I'd like to understand better the problems some WG have had that has led
them to want multiple rooms. My impression is that the problems are
really the result of people using very poor jabber clients, or having
never used IM before and being overwelmed by communication at more than
a few bits/second.
> [[[ TODO: Should non-registered people be allowed to read the IM
> traffic in real time, given that anyone can register anonymously?
> Should people registered anonymously be allowed to post in IM rooms?
> ]]]
Yes, our proceedings and archives are all available anonymously after
the fact. Why shouldn't they be available in real time?
(What does that mean for note-well!!!)
Only registered attendees may post, whether their pseudonym relates to
their real name, or not.
>**Requirement 01-23**: The slide
> stream MUST represent the slides as they are projected in the room,
> allowing the presenter to go back and forth, as well as to edit
> slides in real time.
> **Requirement 01-24**: It MUST be made clear to the remote attendees
> which set of slides, and which slide number, is being currently
> shown.
Requirement 1-23 would seem to imply 1-24. (But if you drop 1-23, and
the slides are actually downloaded and displayed locally, with an
indication of which slide is current, then 1-24 could live without
1-23). Also you speak about slides, not computer screens!
Different implementations of showing what is projecting in the room may
make section 4.2.6 irrelevant. I agree with the analysis in 4.2.6
about when it is useful. Section 4.2.6 implies that such a text editing
system could be part of the RPS, rather than a feature of the shared
screen. I'm not sure that this is a good thing.
It is not needed for non-text documents, but there will be attendees
that are unable to figure out how to edit text documents. (That's not a bug)
> **Requirement 01-25**: The RPS MUST be able to handle both PDF and
> PowerPoint for distributed slides. [[[ TODO: Is there a requirement
> to support other formats? ]]] [[[ TODO: For the distributed slides,
> is there a requirement that animation in PowerPoint be supported, or
> just static slides? ]]]
"Powerpoint" is an application, not a specification. There is "PPT"
and "PPTX" as you know. The RPS MAY support them. The RPS MUST support
ODF (ODP) format, if it supports other than PDF.
Animation of slides is supported in PDF by creating additional slides,
and for the purpose of remote attendees asking questions about
particular state transitions, it is easiest if the states of the "animation"
are represented as slide numbers. As in, "I have a question about the
transition shown on slide 34..."
> **Requirement 01-27**: Presenters MUST be able to update their slides
> on the IETF site up to just before their presentation, if such update
> is allowed by the chairs.
I believe that this is an anti-requirement. Removing this possibility
will make people get their slides in at least an hour before the meeting
begins, which is significantly more fair to all attendees.
section 4.3.1:
It seems that some minor changes to the tools version of the agenda
would permit us to refer to audio streams by WG name, dereferencing
through the meeting room schedule to get the room. That would eliminate
a lot of the confusion as to what document is what.
> Many remote attendees will be in places with limited bandwidth.
> **Requirement 01-43**: All streaming information from the RPS MUST be
> usable over slow Internet connections. [[[ TODO: We need to define
> "slow" here, or drop the requirement.]]]
So I want to point out that I can remote attend today with just a little
more than dialup. I am unaware of anyone having set up a service to
stream the IETF audio stream over a PSTN connection, but I can see that
if I did need to do this, I could participate with the MP3 streamed over
PSTN (using Asterisk in the cloud plus a DID) plus 22Kbits dialup for my
jabber.
So, I suggest:
**Requirement 01-43**: The RPS will solution will detail bandwidth
required per participant for various levels of participation.
The RPS will support a degraded participation mechanism using no more
than 128kbps of data, possibly using a PSTN connection for voice.
Note that if you are bigvendorcorp.com, your 100Mb/s internet connection
might be also inadequate if you have 200 people attending from that
office. I have worked on an internal system that included local reflectors
for the presentation feed, and used web-based chat for
questions. (basically, what we have, only with video as well as audio)
> **Requirement 01-49**: The floor control system MUST allow a chair to
> easily mute all remote attendees.
**Requirement 01-49b**: The floor control system MUST allow a chair to
easily mute all local attendees.
I think that having the various MICs in the room controllable too would
be a very very good thing. I know that this might be very challenging
to integrate with the hotel's meeting space... but maybe not.
> **Requirement 01-50**: The floor control system MUST allow a chair to
> easily allow all remote attendees to speak without requesting
> permission; that is, the chair MUST be able to easily turn on all
> remote attendees mics at once.
This implies that the mic might be on, even if the attendee doesn't have
anything to say.
**Requirement 01-50**: The floor control system MUST allow a chair to
easily allow all remote attendees to speak without requesting
permission; that is, the chair MUST be able to put the conference
into straight push-to-talk mode.
section 4.3.3:
**Requirement 01-59b**: The RPS SHOULD store all archives in DRM-free
audio, video and document formats using commonly available codecs
(patent-free where possible). These archives should be stored
in a resting format, requiring no active code ("web application") to replay.
section 4.4.4:
> **Requirement 01-61**: A system for polling meeting participants,
> including remote attendees at the same time, MUST be provided. It
> MUST be easy to set up a simple poll, and it must be easy for all
> participants to find the poll and participate. [[[ TODO: Should the
> RPS also provide a tool that allows yes / no / abstain indications,
> which comes a lot closer to "voting" than currently is common? ]]]
So, given that you said "meeting participants", it implies that this
system will be used by people in the room. A computer is not presently
a requirement to attend the WG meeting... I have no problem with this,
but it's worth noting this.
section 5:
Video for all-remote meetings may be more important than for face-to-
face meetings. [[[ TODO: Determine if this is true and, if so, the
additional requirements for all the remote attendees. ]]]
I believe that this is not true.
Arbitrary shared screens (any application) is probably more important
that video. For very big groups, being able to all talk at once, but
have the chair sort out the streams and let them out one at a time may
actually be a feature of all-remote meetings. Computers could
contribute to the meeting order by reducing interruptions. I've yet to
see this anywhere, but have wanted it regularly.
> [[[ TODO: What are the requirements for registering? Virtual interim
> meetings are generally considered to have a very different feeling
> than regular IETF meetings; does this affect the idea of
> registration? ]]]
I think that the same registration system is enough. In particular, I
do not want my registration to go away between meetings. If there is a
fee to be paid before I attend, then that needs to be part of the
process.
>7. Security Considerations
>
> People who participate remotely in face-to-face IETF meetings might
> expect the same level of privacy as they have when they participate
> directly in those meetings. Some of the proposed tools might cause
> it to be easier to know which WGs a remote attendee was following.
> When RPS tools are deployed, the IETF should describe the privacy
> implications of using such a tool to the users so they can decide
Actually, those who participate locally in meetings have significantly
less privacy than those remote right now. In particular, many local
participants and chairs do not recall that the MIC and MP3 stream stays
open. It can be very interesting listening after the meeting is closed.
This isn't even a bug, I think :-)
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] [email protected] http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
then sign the petition.
pgp4NWjbpQtFK.pgp
Description: PGP signature
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
