Subject: RE: [Sipping] session-indep-policy-01

From: Simonetti Gabrielle <[email-masked]>
Date: Mon, 08 Nov 2004 19:20:59 +0100

inline...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Volker Hilt
> Sent: domenica 7 novembre 2004 1.32
> To: Cullen Jennings
> Cc: sipping; [email-masked]
> Subject: Re: [Sipping] session-indep-policy-01
> 
> Cullen,
> 
> thanks much for the comments! I'll respond in different emails for the
> session-specific and the session-independent draft.
> 
> Cullen Jennings wrote:
> >
> > Moving on to indep-policy ....
> > 
> > What is an implementation supposed to do if it says forbid 
> X and set_all X.
> > Which wins? 
> > 
> Since forbid MUST be processed first, X is removed from the working
> profile and then added again. The behavior is deterministic (although
> it's not the most useful policy).

What about two different property-sets containing opposite policies (e.g. in two NOTIFY for separate subscriptions)? How should the UA solve the conflict in this case?
Gabrielle

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
[email-masked]. Thank you
====================================================================

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Volker Hilt <[email-masked]>
Date: Mon, 08 Nov 2004 14:18:12 -0500

Gabrielle,

> What about two different property-sets containing opposite policies
> (e.g. in two NOTIFY for separate subscriptions)? How should the UA solve
> the conflict in this case?

We need to address the issue of conflicts between policies in general. 
One approach is to define specific conflict resolution rules for each 
policy schema and maybe even for each element in a policy schema (e.g. 
along the lines of Cullens example in the last mail). This is something 
that needs some more discussion and clearly needs to be addressed in the 
next rev of the draft.

Thanks,

Volker

---

From: David R Oran <[email-masked]>
Date: Mon, 8 Nov 2004 15:03:36 -0500

On Nov 8, 2004, at 2:18 PM, Volker Hilt wrote:

> along the lines of Cullens example in the last mail). This is 
> something that needs some more discussion and clearly needs to be 
> addressed in the next rev of the draft.
>
Ouch! for non-trivial policy languages conflict detection is quadratic 
time for policies with >2 terms, and for more complex languages 
conflict resolution can be NP hard.

> Volker
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Volker Hilt <[email-masked]>
Date: Mon, 08 Nov 2004 15:40:44 -0500

David R Oran wrote:
> time for policies with >2 terms, and for more complex languages conflict 
> resolution can be NP hard.
> 
I guess my comment above was not quite clear. I'm *not* saying that we 
should build a general solution for conflict resolution. I agree that 
this would be extremely complex and go way beyond what is needed to make 
this work.

There might be some simple rules that can be defined for specific 
elements. For example, if there are multiple bandwidth restrictions - 
pick the lowest one. Such rules should probably be defined in a policy 
schema. In cases these rules can't resolve a conflict, there might also 
be a simple default behavior, such as "alert the user".

Again, I do not think we should attempt to solve the general problem of 
conflict resolution for this draft!

Volker