Subject: Re: [XCON] Reminder: FC Reqs last call

From: Cullen Jennings <[email-masked]>
Date: Fri, 02 Apr 2004 06:33:48 -0800

This document has a section titled "Open Issues" - that's enough proof for
me that it is not ready to go to IESG. Particularly given the open issues is
we have not figured out the security requirements.

There are requirements - there is also an model of the solution. Is this
also the framework document for floor control or just the requirements?

Cullen

On 3/22/04 10:04 AM, "Adam Roach" <[email-masked]> wrote:

> As a reminder, we are currently conducting a last call
> for the Floor Control Requirements document. This last
> call period has two weeks remaining.
> 
> /a
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/xcon
> 

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Thu, 22 Apr 2004 13:38:25 +0300

Hi,

Apologies for late comments. Especially since the chairs did a great job 
in reminding us about the approaching DL. Shame on me... ;)

Cheers,
Aki

---

* In the Introduction (1st Ch.), 5th para: I wonder if there is 
something specific in these studies that is to be leveraged? If so, 
maybe it should be mentioned here.

* In the Model (4th Ch.), second para.: In the last sentence, I don't 
understand the benefit in singling out the case where the floor control 
server itself processes the floor control requests. Logically, there is 
still a floor chair, however now it is colocated with the server.

* 4th Ch., 4th para: this talks about policy data pertaining to a floor, 
that is outside the actual floor control protocol. Perhaps we need to 
explicitly talk about floor control policy here. (It's briefly mentioned 
in REQ 15, nowhere else.)

* In the Integration (Ch. 5), first para: this suggests CPCP take care 
of setting floor control policy. I'd rather see floor control policy be 
defined as an independent component (read: document). (Of course, e.g., 
XCAP could still be used to manipulate it, and it should be linked with 
a conference policy). However, setting priviledges (who can set up, 
change, remove floors) might still be good to have as a CPCP feature.

* REQ-6: Instead of a SHOULD, I think a MAY is more appropriate. What 
does a SHOULD mean in requirements anyway...

* REQ-13: Should this be a MUST? Of course, I would think the time you 
spend between requesting the floor and having the floor granted to you 
implicitly already means "queuing".

* REQ-15: As above talks about floor policy descriptions, but maybe this 
term should be floor control policy, and described in the Model already.

* REQ-17: I agree this requirement is important. SInce floors can be 
used across so many different types of conference applications - ranging 
from ones where floor operations are time sensitive to ones where they 
really aren't - we might really be talking about different protocols 
altogether. For elaborate descriptions in floor requests, you almost 
want something like email, whereas in simple mutex a much more simple 
protocol is required. Can the requirements somehow reflect this? I.e., 
make the smallest common denominator (the latter protocol) MUST, and 
everything on top a MAY?

* REQ-18: This again talks about a priviledge for a conference (e.g., 
ABLE_TO_SEE_FLOOR). I don't believe current CPCP addresses this.

* REQ-19: Same as above, this seems like a conference priviledge that 
CPCP currently doesn't address. Also, what is the difference with REQ-18?

* In Open Issues (Ch. 7): IMO, these privacy preferences aren't 
necessarily something that the floor requester should indicate; rahter I 
think they should be set in the floor control policy, and indicated to 
all participants (i.e., I think it is the conference admin who decides 
what the privacy settings should be)

* Also, REQ-b sounds again like another priviledge in a conference 
(ABLE_TO_SEE_FLOOR_CHAIR).

---

ext Adam Roach wrote:
> call period ends in one week. Lacking any comments, the
> chairs will request publication as an RFC at that time.
> 
> /a
>

---

From: [email-masked]
Date: Fri, 23 Apr 2004 09:01:03 +0530

My comments:

IN REQ-18: Conference members and the chair MUST have the capability to
   learn who has the floor and who has requested the floor. (Note:
   Conference policy may prevent members seeing this.)

In open issues we have:
In RRQ-a we have "It MUST be possible for the floor requester to
indicate her
   privacy preference"options :anonymous and we have RRQ-b to hide.

So,as per requirements we are confirming that,
Conference members and the chair MUST have the capability 
To learn who has floor and who has requested the floor.

But we still have a open issue on this!!!
So why dont we make as SHOULD.

>>does a SHOULD mean in requirements anyway...
I think SHOULD is correctr because "we expect to" be possible for a
user..... 

>>implicitly already means "queuing".
This should be SHOULD only because you cannot restrict by telling that
you MUST
Inform that the floor request is pending...It is "expected to" to
that(it is upto the implementation again to make it or not).
In SIP,we have 183,180 which are optional. Similary here also.

Regards,
SReeram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Niemi Aki (Nokia-M/Espoo)
Sent: Thursday, April 22, 2004 4:08 PM
To: ext Adam Roach
Cc: [email-masked]'
Subject: Re: [XCON] Reminder: FC Reqs last call

Hi,

Cheers,
Aki

---

* REQ-19: Same as above, this seems like a conference priviledge that 
CPCP currently doesn't address. Also, what is the difference with
REQ-18?

---

ext Adam Roach wrote:
> call period ends in one week. Lacking any comments, the chairs will 
> request publication as an RFC at that time.
> 
> /a
>