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

From: [email-masked]
Date: Thu, 22 Apr 2004 14:31:30 +0300

Hi,

Thanks for the comments. See inline..

> * 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.

We'll change the wording (the idea was just to mention that this work
is largely based on the earlier work).

> * 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.

There isn't always a chair. Floor policy (set via CPCP) may define different policies 
(say, fcfs) in which the server itself can take the decision. 
 
> * 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.)

Sections 4 and 5 talk about this, but perhaps the wording
is not best possibly and this issue can be further clarified.

> 
> * In the Integration (Ch. 5), first para: this suggests CPCP 
> take care of setting floor control policy. 

Yes, this is correct. CPCP (or whatever sets the conf policy) sets the floor policy.

> I'd rather see floor control policy be defined as an independent component (read: document). 

Possibly, but I guess this does not relate to FC-reqs document.
It has been agreed already that CPCP sets the floor policy. 

> (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.

Later, we may possibly define additional documents about different floor policies
but setting the policy is done via CPCP.

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

I thought it means that solution should provide that but it is not absolutely required
Anyway, it can be changed to MAY.

> * 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".

It is not necessarily queueing (moderator is thinking about the request:)
The need to send status indication may depend on 
the time it takes to complete the process, bandwidth/load issues etc.
Therefore I guess SHOULD is ok.

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

agreed, floor policy (or floor control policy) not both.

> * 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?

I'd rather have this kind of general requirement or remove it altogether
(rather than detailed requirements for these 2 different scenarios).

> * 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.

Actually, this is not about CPCP privileges but about floor control
and the floor holder list etc. There may be e.g. SIP floor event
available to which users may subscribe. This is FC-requirement,
maybe CPCP can later also support this privilege (otherwise,
all users may subscribe to it).

> * 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?

This can probably be combined with REQ-18.

--
Petri

> 
> * In Open Issues (Ch. 7): IMO, these privacy preferences aren't 
> necessarily something that the floor requester should 
> indicate; rather 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:
> > As a reminder, we are currently conducting a last call
> > for the Floor Control Requirements document. This last
> > call period ends in one week. Lacking any comments, the
> > chairs will request publication as an RFC at that time.
> > 
> > /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
> 

_______________________________________________
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 16:46:34 +0300

Inline.

ext [email-masked] wrote:

<snip />

> (say, fcfs) in which the server itself can take the decision. 

I agree there isn't always a "human" chair, but logically, whether 
co-located with the server or not, there is always a chair that has some 
policy in granting the floor (could be FCFS, a beauty-contest etc.).

However, this isn't a big deal but more of a philosophical question. I 
don't think there's anything broken as such with the model.

<snip />

> Therefore I guess SHOULD is ok.

I'm sorry, I meant to say "pending". I agree some sort of status 
indication is needed.

In fact, it seems that the requestor needs to get an immediate response 
(either showing pending state, or granted/denied), and in case of 
pending, needs the final response within a finite time period 
(time-outs). This is why I actually think this is a MUST requirement.

<snip />

> (rather than detailed requirements for these 2 different scenarios).

Yeah, I guess I'm happy with just having a general requirement like this.

> all users may subscribe to it).

I'm a bit confused. To me they look like priviledges that are given to 
conference participants, and as such I don't see a difference in 
granting ability to subscribe to conference-info and granting ability to 
subscribe to floor events.

Granted, these may actually pend on whether the participant was allowed 
into the conference in the first place.

Am I missing something?

> This can probably be combined with REQ-18.

Agreed.

>>(ABLE_TO_SEE_FLOOR_CHAIR).

BTW, you missed the last two comments. ;)

Although the second one is pretty much the same issue as above with 
REQ-18/19.

Cheers,
AKi