Subject: RE: [XCON] CPCP issue 5: Conflicting rules in ACL

From: [email-masked]
Date: Fri, 21 May 2004 11:29:36 +0300

> -----Original Message-----
> From: Aki Niemi [mailto:[email-masked]]
> Sent: 21.May.2004 10:35
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]
> Subject: Re: [XCON] CPCP issue 5: Conflicting rules in ACL
> 
> 
> Hi,
> 
> Seems to me there are two possibilities:
> 
> 1) Use common-policy type rules, where conflicts are allowed 
> and there's 
> a clean way to recover from them
> 
> 2) Design the schema such that for a given URI, there can only be a 
> single entry. The way to do this would be to use the URI as a 
> unique key 
> in identifying a rule:
> 
> <ACL>
>    <target uri="sip:[email-masked]>Allowed</target>
> </ACL>

That doesn't help. Putting the URI as an attribute does not solve the problem. Only text can describe such restriction, not schema.

/Hisham

> 
> Note that there's still the possibility that conflicts occur, if a 
> wildcarded <target> matches in addition to an exact one. But I think 
> CPCP has rules for recovering from that happening.
> 
> Obviously, I'm personally in favor of 1), but 2) is fine as well.
> 
> Cheers,
> Aki
> 
> ext [email-masked] wrote:
> > It is possible that a user creates conflicting rules in an ACL.
> > Conflicting rules MUST NOT exist (e.g.  both allowed and blocked
> > action is defined for same target).  It is the responsibly of the
> > conference policy server (CPS) to ensure such conflicts do 
> not occur.
> > 
> > 
> > Currently, it is not defined how the CPS would react. The obvious
> > answer is that is returns an error using the protocol that 
> is used to
> > place the rule on the server.
> > 
> > In XCAP, this means sending a 409 error response to the PUT 
> detailing
> > what went wrong. Since the document defines the behaviour of XCAP as
> > a possible protocol to carry and manipulate conference policies, the
> > 409 error response will be used.
> > 
> > Any objections?
> > 
> > Regards, Hisham
> > 
> > _______________________________________________ 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: Aki Niemi <[email-masked]>
Date: Fri, 21 May 2004 11:45:52 +0300

Khartabil Hisham (Nokia-TP-MSW/Helsinki) wrote:
> 
>> -----Original Message----- From: Aki Niemi
>> [mailto:[email-masked]] Sent: 21.May.2004 10:35 To: Khartabil
>> Hisham (Nokia-TP-MSW/Helsinki) Cc: [email-masked] Subject: Re:
>> [XCON] CPCP issue 5: Conflicting rules in ACL
>> 
>> 
>> Hi,
>> 
>> 1) Use common-policy type rules, where conflicts are allowed and
>> there's a clean way to recover from them
>> 
>> unique key in identifying a rule:
>> 
>> <ACL> <target uri="sip:[email-masked]>Allowed</target> </ACL>
> 
> 
> That doesn't help. Putting the URI as an attribute does not solve the
> problem. Only text can describe such restriction, not schema.

I think it does help. At least I don't see how you could ever create 
conflicting rules if each rule has a unique identifier (the URI), and 
that key is used in any PUT/GET in the XCAP selector.

Why do you think it doesn't solve the problem?

Cheers,
Aki

>>  wildcarded <target> matches in addition to an exact one. But I
>> think CPCP has rules for recovering from that happening.
>> 
>> Cheers, Aki
>>> what went wrong. Since the document defines the behaviour of XCAP
>>> as a possible protocol to carry and manipulate conference
>>> policies, the 409 error response will be used.
>>> 
>>> Any objections?
>>> 
>>> Regards, Hisham
>>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 22 May 2004 12:33:58 -0400

Conflicts can arise if:

1. you have multiple documents that contain policies, possibly on 
differing servers

2. you can have rules that define matches based on other criteria than 
URI match. For example, domain match, group membership, traits, etc.

Though (1) or (2) might not be a problem now, downstream if you want to 
do these things, you can't rely on eliminating conflict resolutions at 
the time they are provisioned, especially with (1). As a result, I would 
rather advise a common policy type of approach which defines a clear 
ordering so that, should conflicts arise, there is an unambiguous and 
reasonable resolution.

-Jonathan R.

Aki Niemi wrote:

>>>  single entry. The way to do this would be to use the URI as a unique 
>>> key in identifying a rule:
>>>

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com