Re: [Sipping] [RAI] draft-ietf-sipping-media-policy-dataset: The implied boolean logic of policy operations

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Mon, 07 March 2011 21:46 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: sipping@core3.amsl.com
Delivered-To: sipping@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEBD53A6863; Mon, 7 Mar 2011 13:46:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.585
X-Spam-Level:
X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbTTmw+piAK3; Mon, 7 Mar 2011 13:46:53 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 492AE3A684A; Mon, 7 Mar 2011 13:46:53 -0800 (PST)
X-AuditID: c1b4fb3d-b7bbbae000005311-7a-4d755296efa3
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A0.5A.21265.692557D4; Mon, 7 Mar 2011 22:48:06 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Mon, 7 Mar 2011 22:48:06 +0100
Received: from [131.160.126.150] (rvi2-126-150.lmf.ericsson.se [131.160.126.150]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6479E23F5; Mon, 7 Mar 2011 23:48:05 +0200 (EET)
Message-ID: <4D755294.1040007@ericsson.com>
Date: Mon, 07 Mar 2011 23:48:04 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: "Worley, Dale R (Dale)" <dworley@avaya.com>
References: <CD5674C3CD99574EBA7432465FC13C1B2202288B68@DC-US1MBEX4.global.avaya.com>, <4D67A9A5.7090600@ericsson.com> <CD5674C3CD99574EBA7432465FC13C1B220B5C1554@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B220B5C1554@DC-US1MBEX4.global.avaya.com>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Cc: "rai@ietf.org" <rai@ietf.org>, "sipping@ietf.org" <sipping@ietf.org>, Volker Hilt <volkerh@bell-labs.com>
Subject: Re: [Sipping] [RAI] draft-ietf-sipping-media-policy-dataset: The implied boolean logic of policy operations
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Mar 2011 21:46:54 -0000

Hi Dale,

yes, we are saying the same thing.

Thanks,

Gonzalo

On 07/03/2011 11:46 PM, Worley, Dale R (Dale) wrote:
> Gonzalo Camarillo [Gonzalo.Camarillo@ericsson.com] writes:
>>>    o  The different <stream> elements in a session-policy are
>>>       effectively ORed together, in that the policy intends to permit
>>>       any stream that conforms to *any one* of the <stream> elements.
>>>       This is necessary because e.g. a session-policy can contain one
>>>       <stream> that specifies audio media and restricts the codecs
>>>       permitted for audio, and another <stream> that specifies video
>>>       media and restricts the codecs permitted for video.
>>
>> When policies apply to different aspects (e.g., video codecs and audio
>> codecs), this is true. However, if different policies apply to the same
>> aspect, they need to be merged. And when merging the policies, the
>> resulting stream needs to be compliant to all policies (i.e., an AND
>> operation). For example, if one policy allows codecs 0 and 8 and another
>> only allows 8, the resulting policy is to only use codec 8. If a policy
>> allows only codec 0 and another policy only allows codec 8, the result
>> is a null session. I am not sure if this is what you are saying above
>> (and below in the rest of the section), though.
> 
> I'm not sure I'm understanding you completely here.  And it's possible
> that we aren't talking about exactly the same thing.
> 
> Let me recap my opinion:
> 
> - When there are two <stream> elements in *one* session-policy, then
> the intention is to OR the specified restrictions:  a stream that
> conforms to any one of the <stream> elements is premitted.
> 
> - When we "merge" *two* session-policy's, that is an AND, in that the
> stream is subject to the restrictions of each session-policy
> seperately.
> 
> So within one session-policy, one could have a <stream> element that
> specifies the allowed audio codecs, and another <stream> element that
> specifies the allowed video codecs, because an SDP stream that
> conforms to *either* <stream> element would be allowed.  Thus, if one
> <stream> allows codec G.729 and another <stream> allows codec G.711,
> then either codec could be used in a stream.
> 
> But if one is "merging" two session-policy's, an audio stream would
> only be acceptable to the resulting merged session-policy if its
> codecs conformed to the limitations in both original ession-policy's.
> Thus, if one session-policy allows codec G.729 and the other
> session-policy allows codec G.711, then no codec could be used in an
> audio stream.
> 
> Dale