RE: [XCON] CPCP Issue 31: Expelling a User
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [XCON] CPCP Issue 31: Expelling a User
Can you please specify exact text that you would like to appear in the draft?
Thanks,
Hisham
> -----Original Message-----
> From: ext Noa Kissilov [mailto:NoaK at radvision.com]
> Sent: 10.November.2004 14:58
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon at ietf.org
> Subject: FW: [XCON] CPCP Issue 31: Expelling a User
>
>
> Thanks. I am not talking about changing examples, but changing the
> CHOICE that the focus has, regarding challenging a user for
> password or
> not. The following section:
>
> "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."
>
> We started this discussion by saying that this is a reason
> for us having
> the "block" value for <join-handling> action. I am saying that this
> behavior (not challenging if there is a rule with "block") is
> inconsistent, and the behavior should be changed (and as a result the
> "block" value is really unnecessary).
>
> noa.
>
>
> -----Original Message-----
> From: hisham.khartabil at nokia.com [mailto:hisham.khartabil at nokia.com]
> Sent: Wednesday, November 10, 2004 14:34
> To: Noa Kissilov
> Subject: RE: [XCON] CPCP Issue 31: Expelling a User
>
>
> Noa,
>
> Thanks for this email. What you are saying is true. But we
> don't dictate
> how rules should be set. If you want to represent them the way you
> describe, then there is nothing stopping you. We just show very few
> examples in the draft that may or may not fit your taste.
>
> Are you talking about specifically changing examples in the current
> draft? If so, which ones?
>
> Thanks,
> Hisham
>
> > -----Original Message-----
> > From: ext Noa Kissilov [mailto:NoaK at radvision.com]
> > Sent: 10.November.2004 09:59
> > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> > Subject: RE: [XCON] CPCP Issue 31: Expelling a User
> >
> >
> > About passcode challenge: the contradiction is that if
> there is a rule
> > with value "block", the user can't join even if there is a
> way in for
> > him (he knows the passcode). This is a contradiction to
> "block" having
>
> > the lowest value and being overriden if there is any other rule
> > allowing a user to join.
> >
> > I'll give an example to make sure it's clear what I'm trying to say.
> > Consider the following set of rules:
> >
> > <rule id="1">
> > <conditions>
> > <identity>
> > <domain>example.com</domain>
> > </identity>
> > </conditions>
> > <actions>
> > <join-handling>allow</join-handling>
> > </actions>
> > <transformations/>
> > </rule>
> > <rule id="2">
> > <conditions>
> > <identity>
> > <uri>bob at example.com</uri>
> > </identity>
> > </conditions>
> > <actions>
> > <join-handling>block</join-handling>
> > </actions>
> > <transformations/>
> > </rule>
> >
> >
> > In this case bob would be allowed in, even though there is a rule
> > blocking him specifically (I took the example from section
> 5.4.1). Now
>
> > if the first rule is changed to have a passcode, bob will not be
> > allowed in even if he knows the passcode - he simply won't be
> > challenged for it,
> > since there is a rule blocking him:
> >
> > <rule id="1">
> > <conditions>
> > <identity>
> > <domain>example.com</domain>
> > </identity>
> > <participant-passcode/>
> > </conditions>
> > <actions>
> > <join-handling>allow</join-handling>
> > </actions>
> > <transformations/>
> > </rule>
> > <rule id="2">
> > <conditions>
> > <identity>
> > <uri>bob at example.com</uri>
> > </identity>
> > </conditions>
> > <actions>
> > <join-handling>block</join-handling>
> > </actions>
> > <transformations/>
> > </rule>
> >
> > It seems absurd to me that once we decided to protect our
> conference
> > in a password the whole flow changes. BTW, rule no. 2 in
> the original
> > example has no impact otherwise, and needs to be denoted as
> > an <except>
> > portion of the <identity> element. I suggest having it done
> > the same way
> > for using passcodes - these rules are still equivalent to
> >
> > <rule id="1">
> > <conditions>
> > <identity>
> > <domain>example.com</domain>
> > <except>bob at example.com</except>
> > </identity>
> > <participant-passcode/>
> > </conditions>
> > <actions>
> > <join-handling>allow</join-handling>
> > </actions>
> > <transformations/>
> > </rule>
> >
> > And bob will not be allowed in even if he knows the
> passcode. It seems
> > to me like the right way to do it, and then we can also give up the
> > "block" value for this action - it will have no impact.
> >
> > noa.
> >
> >
> > -----Original Message-----
> > From: hisham.khartabil at nokia.com [mailto:hisham.khartabil at nokia.com]
> > Sent: Monday, November 08, 2004 20:10
> > 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: 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
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
