Subject: [vmeet] Feedback on draft-ietf-genarea-rps-reqs-07

From: Simon Pietro Romano <[email-masked]>
Date: Wed, 12 Sep 2012 15:54:41 +0200

Hi Paul and vmeetters,

thank you for submitting a revised version (-07) of your draft. Please 
find below my comments, preceded by the usual disclaimer about the 
length of my message ;-).
I'll take some excerpts of the draft and let them be followed by my 
comments/observations. As a general comment, I personally think that the 
document mixes technical and non-technical requirements for the RPS and 
I find this a bit confusing. Technical requirements are those directly 
coupled to the functionality that the RPS will have to make available 
and would be easily described (or mapped) with a formal modeling 
approach like UML, in much the same way as with any other software 
requirements specification. Non-technical requirements are most of the 
times related to 'policies', which, as I have often claimed on IETF 
mailing list discussions, are always orthogonal to (and hence 
independent from)  technical details of a system. I'll try to make this 
clear in my detailed review, but for the sake of clarity I'll give you 
an example of what I'm saying right below:

- technical requirement:

**Requirement 07-02**: All tools in the RPS MUST be able to use both
    IPv4 and IPv6 addresses natively.

- non-technical (policy-based) requirement:

**Requirement 07-07**: Both local and remote attendees SHOULD be able
    to easily contact a single entity who is available throughout the
    meeting if they find problems with any of the RPS tools, and to get
    fairly rapid response.  This entity needs to be able to handle as RPS
    tool problems in the meeting rooms, or be able to quickly contact
    someone who can address those problems.

My personal preference would be to have a clear distinction between the 
above classes of requirements. I think this would also make it easier, 
in the future, to edit a formal
software requirements specification for potential bidders.

This said, I also found a third category of requirements which in my 
view fall in a specific class which I would call something like 
"Requirements for the seamless integration of the future RPS system with 
the current IETF tools and meeting materials portal". To provide you an 
example of this third class of requirements, I'll copy/paste a couple below:

**Requirement 07-49**: The RPS MUST automatically convert PowerPoint
    presentations to PDF and make both available for distribution at the
    same time.

NOTE: in the requirement below I assume that with the expression "make both available for distribution" you are referring to slides publication on the
meeting materials page, right?

**Requirement 07-50**: 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 WG chairs.

NOTE: this last example is in my view actually a mix of a "policy-based" and an "integration" requirement.

So, let's get started with the details.

**Requirement 07-09**: The deployment of the tools here MUST take
    into account making the tools accessible to as many IETF attendees as
    possible.  Such deployment is likely to include technical
    accommodations for those with visual and hearing disabilities.

  Agreed. But this formulation sounds a bit too generic. What kind of 
accommodations do you have in mind? As an example, for deaf people, you 
might be thinking of remote transcription services like "Remote CART" 
(Communication Access Real-time Translation) captioning, perhaps based 
on standards like XEP-0301 (Real-Time Text for XMPP -- 
http://www.xmpp.org/extensions/xep-0301.html). In any case, I would make 
this part more explicit.

**Requirement 07-10**: All remote attendees at regular IETF meetings
    and interim meetings who make contributions MUST register with the
    IETF Secretariat before contributing using any of the RPS tools.

This is out of scope for the RPS. I think the basic idea behind section 
2.1 is that the IETF secretariat should in the future envisage different 
registration options (local attendee, remote contributing attendee, 
remote non-contributing attendee) and the RPS should have access to such 
information when logging users into the system, so to be capable of 
associating them with a specific role. In summary, from the RPS's point 
of view, the only requirement should be that it be capable of supporting 
different user roles, once again configured through policies. You 
actually mention something like this when you state, at the end of the 
section, that "registration might happen in the IETF's Datatracker".

Coming to section 2.3 on Audio, I have already stated on this ML 
(http://www.ietf.org/mail-archive/web/vmeet/current/msg00548.html) that 
I strongly believe the priorities you identify in the document are not 
in the right order. I cannot think of a 'future' RPS which is not 
capable of reliably supporting audio from remote attendees (both those 
who have to give presentations and those who just want to make sporadic 
comments).  I know this brings in some technical obstacles, but I 
nonetheless insist on this point.
With respect to the specific requirements you identify:

**Requirement 07-20**: The RPS MUST enable relay of messages from IM
    to the mic to be able to happen as quickly as if the remote attendee
    was local.

It is not clear to me what you mean by "as quickly as if the remote 
attendee was local".
 From a technical standpoint, this should translate in something similar 
to what I was proposing in the already cited mail, i.e. a solution which 
automatically announces a request for attention coming, via the jabber 
room, from a remote: in a few words, if a remote writes a sentence in 
the chat and lets it be preceded by the [mic] prefix, the RPS should 
automatically play a predefined 'attention sound' inside the room.

**Requirement 07-21**: The person relaying from IM to the mic must be
    available throughout the WG meeting.  To date, this has been done by
    WG volunteers in the room.  In the future, it could be done the same
    way, or maybe could be facilitated by hiring people to attend
    meetings for the specific purpose of being IM-to-mic scribes,

this part seems to be out of scope for the RPS

    or maybe could be done with tools that allow copy-and-paste of text from
    IM to a speech synthesizer that reads it to the room.

with respect to this part, you should obviously also look after 
moderation in this case (I copy-and-paste the sentence, but the sentence 
itself should be read to the room
at the right time, i.e. when the the user's turn to gain the floor arrives).

**Requirement 07-24**: A WG chair MUST be able to control the sound
    coming from any particular remote attendee.  This control MUST allow
    reduction in volume, all the way to complete muting, of the remote
    speaker.

This requirement, together with others that I will discuss, might be put 
in a general technical sub-category associated with floor control. With 
respect to this, I also remark
that if we start talking about moderation and floor control, we have to 
be careful when identifying roles, meaning that we should avoid making a 
direct logical link between
the WG chair (who is physically chairing the session) and the moderator 
(who is actually 'chairing' one or multiple floors/media): the two roles 
might easily be played by distinct
persons (this is, again, a matter of policies).

**Requirement 07-26**: The audio system used by the RPS MUST be able
    to integrate with systems commonly used in the venues used for IETF
    meetings.  These venue systems typically include line-level audio
    outputs from mixers that combine all the mic inputs into a single
    stream.  Some venue systems also allow for headphone level inputs
    from PCs to be mixed into the audio stream.

Right. With reference to this part, you might want to have a look at 
what we are asking for when it comes to support sessions with Meetecho:

http://recordings.conf.meetecho.com/AudioMixerConfiguration.pdf

  **Requirement 07-39**: The IETF Secretariat MUST be able to easily
    set up the individuals allowed to use the floor control system for a
    particular meeting and to change the settings at any time, including
    during the meeting.

Isn't this out of scope for the RPS (policy-related)?

**Requirement 07-40**: The chair SHOULD be able to monitor the sound
    levels of the audio being delivered to remote attendees to be sure
    that they can hear what is going on in the room.

Beware that this calls for remote monitoring on the client side, which 
not as easy as one might expect. I would better state that the chair 
should be able to
'adjust' the sound of the audio of remotes, based on their feedback 
about the perceived quality.

**Requirement 07-43**: When video is allowed for remote attendees to
    give presentations (as described inSection 2.3.3  <http://tools.ietf.org/html/draft-ietf-genarea-rps-reqs-07#section-2.3.3>), the audience in
    the room SHOULD be able to see the presenter speaking.

Doesn't this simply translate in a requirement to have a secondary 
beamer in the room which is projecting the remote speaker's video (which 
would be out of scope for the RPS)?

The whole section 2.5 is in my view related to the third category of 
requirements I introduced above ("Requirements for the seamless 
integration of the future RPS system with the current IETF tools and 
meeting materials portal").
I think that a requirement for the RPS here would just be that of being 
able to show (in the meeting virtual room) the slides that have been 
uploaded to the meeting materials page. This might, e.g., be done 
through a conversion of ppt/pptx/pdf/odp/etc files to whatever the RPS 
uses internally (e.g. a sequence of images, a low-rate video, etc.).

**Requirement 07-53**: 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.  This makes it clear
    to the remote attendees which set of slides, and which slide number,
    is being currently shown.

Real-time editing of the slides is a tough requirement, indeed. If you 
think of how this is typically done, the most likely option here would 
be to have the speaker make his presentation by using some sort of 
application sharing tool (e.g., by sharing his powerpoint application 
running on his laptop). I think we should relax this requirement, by 
associating a MUST to just showing slides and browsing back and forth 
through the presentation. Slide annotations might then be done by using 
a whiteboard or some similar tool. What is your feeling about this?

**Requirement 07-60**: A much-lower priority requirement is the
    ability for group-editing of graphics.

As before, this is a tough one. What do you mean by group editing of 
graphics? Are you thinking of a sort of shared "Paint", a whiteboard, or 
what?

  **Requirement 07-61**: The RPS MUST support storage and distribution
    of recordings of the audio, video, and slide presentations for all WG
    meetings.

I would also specify that it is highly desirable to have "synchronized" 
recordings of the meeting media.

  **Requirement 07-64**: Users MUST be able to easily find the archives
    of the recordings and instant messaging transcripts of a particular
    WG or BoF session at a particular meeting.

This is out of scope for the RPS (policies).

**Requirement 07-66**: The RPS MUST support recording and storage of
    recordings of the audio, video, and slide presentations of interim
    meetings as well as regular IETF meetings.

Once again, from the RPS perspective, there should be no difference at 
all between recordings of a regular meeting and recordings of an interim.

  **Requirement 07-67**: Given that interim meetings are often run
    without the help of the IETF Secretariat, making these recordings
   MUST be easy for WG chairs.

Why should the chairs bother about the recordings? I think the RPS 
should be capable of making recordings in an automated fashion. The chairs
should just don't care about the inner workings.

  **Requirement 07-74**: The RPS MUST allow a session to be moved from
    one room to another during the session This is needed because the
    Secretariat sometimes need to swap the rooms for WGs when it becomes
    clear that one is too full and another room has excess space.

Apart from the unavoidable association between the mixer in the room and 
the virtual room in the RPS, this should have no other impact on the RPS 
itself.

  **Requirement 07-79**: Remote attendees MUST be able to easily find
    all the material they need to effectively participate, including
    links to audio, video, instant messaging, slides, and so on.  This
    material MUST be available well before the time of the meeting.  The
    page with the meeting material SHOULD allow the remote attendee to
    easily perform a time conversion to and from the local time at the
    IETF meeting.

Out of scope for the RPS (policies).

  **Requirement 07-84**: The RPS SHOULD have a central location where
    the specifics about how remote participation is supported for every
    WG interim meeting.  This will reduce the problems often seen where
    messages about how to participate in an interim meeting get buried in
    the WG mailing list.

I don't understand this one, but looks like a policy-related issue.

Hope you'll find this feedback useful.

Cheers,

Simon

/
/

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]
           http://www.comics.unina.it/simonpietro.romano

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 24 Sep 2012 11:20:28 -0700

After a couple of weeks, no one has responded to this message. I will break the substantiative responses into smaller chunks, but probably will not act on much unless others feel that it is important.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 24 Sep 2012 11:25:57 -0700

On Sep 12, 2012, at 6:54 AM, Simon Pietro Romano <[email-masked]> wrote:

> As a general comment, I personally think that the document mixes technical and non-technical requirements for the RPS and I find this a bit confusing. Technical requirements are those directly coupled to the functionality that the RPS will have to make available and would be easily described (or mapped) with a formal modeling approach like UML, in much the same way as with any other software requirements specification. Non-technical requirements are most of the times related to 'policies', which, as I have often claimed on IETF mailing list discussions, are always orthogonal to (and hence independent from)  technical details of a system.

The document definitely mixes those. I like your description of non-technical requirements as "policies".

> My personal preference would be to have a clear distinction between the above classes of requirements.

Why is that clear distinction important? Someone reading the document can make the distinction themselves. In the case where a requirement straddles both classes, the reader can say "this seems like both.

> I think this would also make it easier, in the future, to edit a formal

The IAOC might or might not want to do that, but that's up to them. The requirements of both categories came from the IETF community; the IAOC can decide how they want to deal with those requirements.

> This said, I also found a third category of requirements which in my view fall in a specific class which I would call something like "Requirements for the seamless integration of the future RPS system with the current IETF tools and meeting materials portal".

That is a good example of things that can be technical or policies. I am not sure who would benefit from calling that out in this document.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 24 Sep 2012 11:32:11 -0700

On Sep 12, 2012, at 6:54 AM, Simon Pietro Romano <[email-masked]> wrote:

>  Agreed. But this formulation sounds a bit too generic. What kind of accommodations do you have in mind? As an example, for deaf people, you might be thinking of remote transcription services like "Remote CART" (Communication Access Real-time Translation) captioning, perhaps based on standards like XEP-0301 (Real-Time Text for XMPP -- http://www.xmpp.org/extensions/xep-0301.html). In any case, I would make this part more explicit.

The community didn't give an explicit set of accommodations; it expressed a general goal. This community has little practice in dealing with accommodating disabilities ahead of time, but reasonable practice of doing it when it is needed. Is your concern that we would miss a particular set of disabilities that are important?

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 24 Sep 2012 11:37:39 -0700

On Sep 12, 2012, at 6:54 AM, Simon Pietro Romano <[email-masked]> wrote:

> This is out of scope for the RPS.

I fully disagree. There was strong consensus on this. It is a policy that is driven by the desire to clearly delineate contributors as is already defined in the IETF procedures.

> I think the basic idea behind section 2.1 is that the IETF secretariat should in the future envisage different registration options (local attendee, remote contributing attendee, remote non-contributing attendee) and the RPS should have access to such information when logging users into the system, so to be capable of associating them with a specific role. 

No. The requirement is that the Secretariat differentiate the differences as soon as possible. There was a community desire to have remote participation also involve registration.

> In summary, from the RPS's point of view, the only requirement should be that it be capable of supporting different user roles, once again configured through policies.

We disagree. The registration is part of the RPS.

> You actually mention something like this when you state, at the end of the section, that "registration might happen in the IETF's Datatracker".

That's seems like a creative reading of that sentence.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 24 Sep 2012 11:41:17 -0700

On Sep 12, 2012, at 6:54 AM, Simon Pietro Romano <[email-masked]> wrote:

> Coming to section 2.3 on Audio, I have already stated on this ML (http://www.ietf.org/mail-archive/web/vmeet/current/msg00548.html) that I strongly believe the priorities you identify in the document are not in the right order. I cannot think of a 'future' RPS which is not capable of reliably supporting audio from remote attendees (both those who have to give presentations and those who just want to make sporadic comments).  I know this brings in some technical obstacles, but I nonetheless insist on this point. 
> It is not clear to me what you mean by "as quickly as if the remote attendee was local".
> From a technical standpoint, this should translate in something similar to what I was proposing in the already cited mail, i.e. a solution which automatically announces a request for attention coming, via the jabber room, from a remote: in a few words, if a remote writes a sentence in the chat and lets it be preceded by the [mic] prefix, the RPS should automatically play a predefined 'attention sound' inside the room.
> 

There was consensus in the earlier discussion against what you "strongly believe". You might want to bring this up again in IETF Last Call. If there is consensus then that having remote attendees voice in the room, then there will also need to be a major reworking of the document, particularly the floor control parts (as you point out later in your message).

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 24 Sep 2012 11:44:19 -0700

On Sep 12, 2012, at 6:54 AM, Simon Pietro Romano <[email-masked]> wrote:

> Beware that this calls for remote monitoring on the client side, which not as easy as one might expect. I would better state that the chair should be able to 
> 'adjust' the sound of the audio of remotes, based on their feedback about the perceived quality.

This is a good point. The requirement in general is that the chair should be able to respond to what the chair hears from remote participants. That could easily be based on the chair seeing people in the Jabber room saying "we can't hear; tell the presenter to talk into the mic".

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 24 Sep 2012 11:51:11 -0700

On Sep 12, 2012, at 6:54 AM, Simon Pietro Romano <[email-masked]> wrote:

> Real-time editing of the slides is a tough requirement, indeed. If you think of how this is typically done, the most likely option here would be to have the speaker make his presentation by using some sort of application sharing tool (e.g., by sharing his powerpoint application running on his laptop).

That's not how it is typically done in the IETF. Instead, people just start editing whatever they were presenting. If it is a Powerpoint presentation, they start editing in Powerpoint. If it's PDF, they give up.

> I think we should relax this requirement, by associating a MUST to just showing slides and browsing back and forth through the presentation. Slide annotations might then be done by using a whiteboard or some similar tool. What is your feeling about this?

That would restrict the current workflow that WGs often employ.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 24 Sep 2012 11:56:00 -0700

On Sep 12, 2012, at 6:54 AM, Simon Pietro Romano <[email-masked]> wrote:

> Why should the chairs bother about the recordings?

Because if an interim does not have a recording, it has a significant negative effect on the WG's progress.

> I think the RPS should be capable of making recordings in an automated fashion. The chairs 

How do you see that working? If there is an interim meeting that was not coordinated through the IETF Secretariat, how could the RPS "make recordings in an automated fashion"?

--Paul Hoffman

---

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 24 Sep 2012 22:45:18 +0200

Hi Paul,

> After a couple of weeks, no one has responded to this message.

:-) this is no news, indeed. People hardly ever respond to my "way-too-long" e-mails!

> I will break the substantiative responses into smaller chunks, but probably will not act on much unless others feel that it is important.

Agreed.

Simon

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

---

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 24 Sep 2012 22:50:29 +0200

Hello again,

> There was consensus in the earlier discussion against what you "strongly believe". You might want to bring this up again in IETF Last Call. If there is consensus then that having remote attendees v…

I see. If this was the consensus, then my voice will keep on being "clamans in deserto" until last call.

Simon

                     					       _\\|//_
                           				      ( O-O )

---

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 24 Sep 2012 22:55:31 +0200

Here we go again,

> Because if an interim does not have a recording, it has a significant negative effect on the WG's progress.

Sure...actually this part of my comment was 'propaedeutical' to the one which follows.

> How do you see that working? If there is an interim meeting that was not coordinated through the IETF Secretariat, how could the RPS "make recordings in an automated fashion"?

...sometimes magic happens!

Simon

                     					       _\\|//_
                           				      ( O-O )

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Sep 2012 17:16:14 -0400

On 9/24/12 4:55 PM, Simon Pietro Romano wrote:
>> How do you see that working? If there is an interim meeting that was
>> not coordinated through the IETF Secretariat, how could the RPS "make
>> recordings in an automated fashion"?
>

Perhaps a standard template for creating an interim meeting conference, 
that sets recording by default - to be started automatically.

I would *really* like the option to specify recording when defining a 
conference, in such a way that it will just happen without the need to 
do anything manually when the meeting starts. (It is *way* too easy to 
forget to start the recording.)

	Thanks,
	Paul

---

From: [email-masked]
Date: Tue, 25 Sep 2012 00:16:55 +0200

+1 to both comments.

Simon

Quoting Paul Kyzivat <[email-masked]>:

> Perhaps a standard template for creating an interim meeting  
> conference, that sets recording by default - to be started  
> automatically.
>
> I would *really* like the option to specify recording when defining  
> a conference, in such a way that it will just happen without the  
> need to do anything manually when the meeting starts. (It is *way*  
> too easy to forget to start the recording.)
>
> 	Thanks,
> 	Paul
>
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html.
> https://www.ietf.org/mailman/listinfo/vmeet
>
>

     <<Molti mi dicono che lo scoraggiamento ? l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 24 Sep 2012 15:43:39 -0700

On Sep 24, 2012, at 2:16 PM, Paul Kyzivat <[email-masked]> wrote:

> Perhaps a standard template for creating an interim meeting conference, that sets recording by default - to be started automatically.

The requirement is discussing interims that are not coordinated with the IETF. Are you suggesting that these would have to be done through an IETF-supported audio system, regardless of the location where they are held? If so, I agree that a template would work. However, that would also limit chairs to being in places that can hook into the IETF's system. Is that a reasonable trade-off?

--Paul Hoffman

---

From: joel jaeggli <[email-masked]>
Date: Mon, 24 Sep 2012 19:53:05 -0700

It not rocket science to record a webex, you generally set that up when 
you schedule the meeting.

the methodology varies with other technologies that we use, but exists 
as well e.g. meetecho, xmpp/jabber.

On 9/24/12 3:16 PM, [email-masked] wrote:
>> conference, that sets recording by default - to be started automatically.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Sep 2012 23:53:30 -0400

> The requirement is discussing interims that are not coordinated with the IETF. Are you suggesting that these would have to be done through an IETF-supported audio system, regardless of the location…

Well, maybe I am missing something.
AFAIK the current effort is to specify some tools.
So if we are talking about interims in that context, then it must be 
interims supported by the tools being specified.

I guess that is independent of where the server is. Either way the tool 
could create a conference that is set to automatically record.

If the conference is set up on a server without the ability to record 
then of course it won't get recorded. If it hurts, don't do it.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Sep 2012 23:57:20 -0400

> as well e.g. meetecho, xmpp/jabber.

No, it's not rocket science with webex. You can specify it when you 
create the conference. But in spite of that you must then take a manual 
action after the conference starts to actually start the recording. More 
than once I have forgotten to do that. Blame me for being absent minded 
if you like, but it happens. And it's worse if the host is delayed and 
the meeting starts without the host.

I would rather have it be deterministic that if you specify a recording 
when setting up the conference then you get a recording.

	Thanks,	
	Paul