RE: [XCON] CPCP Issue 31: Expelling a User

[hisham.khartabil at nokia.com]

> -----Original Message-----
> From: ext Noa Kissilov [mailto:NoaK at radvision.com]
> Sent: 24.October.2004 12:41
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon at ietf.org
> Subject: RE: [XCON] CPCP Issue 31: Expelling a User
> 
> 
> Hi,
> 
> As I see it this problem is derived from the problem that 
> authorization
> RULES shouldn't be used to take actions on participants. A RULE is
> something referred to when you consider a certain behaviour. Action,
> such as having a server do something, should have a different 
> mechanism
> to be set. This is only one aspect of another question, which is the
> essence of the conference policy document - is it a state descriptor
> (like described about sidebars: if no sidebar element appears in
> conference policy, it means there are no sidebars currently in the
> conference, and vice versa), policy definition (like rules - someone
> asks to do something, we check it with the policy and then decide upon
> our behavior), or a mechanism to fire actions? I believe 
> currently there
> is a mixture between the 3, and this causes some inconsistency and
> confusion. For example, for expelling a user we need to both change
> policy (so that this user will not be allowed in the 
> conference) and say
> somehow to disconnect it now. These are 2 distinct tasks, and 
> I believe
> they should have 2 distinct mechanisms.

What you describe here is nothing new to us. We know and accept it.

> 
> Another question about this subject: why is it required to 
> have "block"
> value for actions?

Good question. But what you describe below is not a reason. It is a good question because there is no need to explicitly block someone. By not having a rule there, it implicitly means that they are blocked. So I guess "block" is not needed. But the following text in the internet-draft might cause us to add it anyway:

"A focus need not care if a user using a passcode to join is calling
   from a PSTN or an IP phone.  For example: Using a SIP phone, a SIP
   INVITE request arrives directly at the focus.  The focus examines the
   identity and discovers that there are no rules allowing this identity
   to join.  The focus also determines that there are no rules
   explicitly prohibiting this identity from joining.  The focus in this
   case decides to challenge the identity for a passcode, if there is a
   rule that allows users with a passcode knowledge to join.  If no such
   rule exists, the focus would not challenge for a passcode."

Regards,
Hisham


> In the common policy it is stated specifically that
> rules only permit. Why is "block" required anyway, especially 
> when it is
> with the lowest value of 0 and will be overridden upon any other value
> apearance (in other rules)? It is stated that this is the default
> anyway. Let's make it simpler...
> 
>     noa.
> 
> 
> -----Original Message-----
> From: xcon-bounces at ietf.org [mailto:xcon-bounces at ietf.org] On 
> Behalf Of
> hisham.khartabil at nokia.com
> Sent: Monday, September 13, 2004 15:31
> To: hisham.khartabil at nokia.com; xcon at ietf.org
> Subject: RE: [XCON] CPCP Issue 31: Expelling a User
> 
> 
> This is a draft-ietf-xcon-cpcp-00.txt issue now.
> 
> I have not received any comments about this and I honestly 
> have no idea
> how to simplify this besides creating a new expel list (which I don't
> like).
> 
> If no one has any better ideas, then I will keep the text as is (no
> expel list, but to expel a user, multiple rules may need to 
> be altered).
> 
> Regards,
> Hisham
> 
> > -----Original Message-----
> > From: xcon-bounces at ietf.org 
> [mailto:xcon-bounces at ietf.org]On Behalf Of
> 
> > ext hisham.khartabil at nokia.com
> > Sent: 13.August.2004 16:14
> > To: xcon at ietf.org
> > Subject: [XCON] CPCP Issue 31: Expelling a User
> > 
> > 
> > This issue was missed during the presentation since the chair
> > ;) accidentally put up the old version of the slides.'
> > 
> > Back to the issue:
> > 
> > Care must be taken since if one rules allows a user to join and one
> > blocks a user from joining, the result in that the user is 
> allowed to 
> > join.
> >  
> > For example, Bob can join a conference since an 
> authorization rule has
> > been defined to allow everyone at example.com:
> > 
> > <rule id="1">
> >    		<conditions>
> >    			<identity>
> >    				<domain>example.com</domain>
> >    			</identity>
> >    		</conditions>
> >    		<actions>
> >    			<join-handling>allow</join-handling>
> >    		</actions>
> >    		<transformations/>
> > </rule>
> > 
> > Setting the following rule will not block Bob from joining 
> nor will it
> > expel him since the above rule overrides it:
> > 
> >   	<rule id="2">
> >    		<conditions>
> >    			<identity>
> >    				<uri>bob at example.com</uri>
> >    			</identity>
> >    		</conditions>
> >    		<actions>
> >    			<join-handling>block</join-handling>
> >    		</actions>
> > 		<transformations/>
> >    	</rule>
> > 
> > So, in order to expel Bob, the original rule has to be 
> modified using
> > the <except> element:
> > 
> >    	<rule id="1">
> >    		<conditions>
> >    			<identity>
> >    				<domain>example.com</domain>
> >    				<except>bob at domain.com</except>
> >    			</identity>
> >    		</conditions>
> >    		<actions>
> >    			<join-handling>allow</join-handling>
> >    		</actions>
> >    		<transformations/>
> > 	</rule>
> > 
> > This type of behaviour makes it very hard to a client implementation
> > to figure out how to expel a user because it depends on all 
> the rules 
> > in a conference. It must go through all the rules and 
> change all the 
> > necessary ones so that that user is not capable of joining again.
> > 
> > Does anyone have ideas on how to simplify this? A separate 
> expel list
> > that overrides any rules???
> > 
> > Regards,
> > Hisham
> > 
> > _______________________________________________
> > XCON mailing list
> > XCON at ietf.org
> > https://www1.ietf.org/mailman/listinfo/xcon
> > 
> 
> _______________________________________________
> XCON mailing list
> XCON at ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon
> 
> 

_______________________________________________
XCON mailing list
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon