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: 07.November.2004 15:01
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon at ietf.org
> Subject: RE: [XCON] CPCP Issue 31: Expelling a User
> 
> 
> 
> 
>     noa.
> 
> 
> -----Original Message-----
> From: hisham.khartabil at nokia.com [mailto:hisham.khartabil at nokia.com] 
> Sent: Friday, November 05, 2004 12:18
> To: Noa Kissilov; xcon at ietf.org
> Subject: RE: [XCON] CPCP Issue 31: Expelling a User
> 
> 
> 
> 
> > -----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.
> [noa] but now they are mixed. For example, it is said that when a
> <join-handling> in a rule is set to "block", the focus should send
> "bye".
> 
> "  Expelling a user is performed by a privileged user creating or
>    manipulating an existing authorization rule and setting that user's
>    <join-handling> action to "block>.  The focus reacts by terminating
>    the session with that participant, such as a sending SIP BYE
> request."
> 
> Now we can say that since <join-handling> is an action, it is OK that
> changing an action part of a rule causes action. But 
> <join-handling> is
> also used as a rule - to say who is allowed in the conference 
> and who is
> not. It is part of the evaluation of joining request - which 
> is exactly
> a rule. So I'm confused about that...

It is a rule.  When a user changes a rule, the focus needs to be informed about it. The focus, in this case, will be informed that a user has been blocked now. The focus reacts by removing that user if no other rule permits him to stay.

> 
> > 
> > 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."
> 
> [noa] why do we need this? I mean, what happens if we challenge for
> passcode in any case there is a rule with passcode? If we 
> leave the flow
> like this, it means that <join-handling> with value "block" has
> precedence over passcode with <join-handling> with value "confirm" or
> "allow". Isn't it a contradiction? Just because passcode is something
> that has to be specifically asked for, I don't think it should affect
> the logic of rules processing.

A focus has to run through the rules anytime a user tries to join. What is contradicting? A focus MAY choose to challenge for a passcode if it does not find a rule explicitly blocking a user from joining.

/Hisham

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