Re: WG Review: Call Control UUI for SIP (cuss)

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Thu, 15 July 2010 14:31 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E379A3A680C; Thu, 15 Jul 2010 07:31:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.837
X-Spam-Level:
X-Spam-Status: No, score=-103.837 tagged_above=-999 required=5 tests=[AWL=-1.238, BAYES_00=-2.599, 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 rRTPsEnl7bWq; Thu, 15 Jul 2010 07:31:55 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 1289C3A6A1E; Thu, 15 Jul 2010 07:31:53 -0700 (PDT)
X-AuditID: c1b4fb39-b7b91ae000001aef-bf-4c3f1be33bd2
Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5F.41.06895.3EB1F3C4; Thu, 15 Jul 2010 16:32:03 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jul 2010 16:32:03 +0200
Received: from [131.160.126.225] ([131.160.126.225]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jul 2010 16:32:02 +0200
Message-ID: <4C3F1BE2.5060102@ericsson.com>
Date: Thu, 15 Jul 2010 17:32:02 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
Subject: Re: WG Review: Call Control UUI for SIP (cuss)
References: <4C28F980.3040702@ericsson.com> <AANLkTinf6-mtUKbdtw0p2j0xJQPBr4S-XCiimSNoKNdC@mail.gmail.com> <0010F1C2-2436-474D-BC1C-05AFC8A9E4C5@cisco.com> <4C3D7496.8020905@gmail.com> <71EA364F-6D56-45B3-BB9C-9C9AE1E1266C@cisco.com>
In-Reply-To: <71EA364F-6D56-45B3-BB9C-9C9AE1E1266C@cisco.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Jul 2010 14:32:02.0726 (UTC) FILETIME=[7DC1A460:01CB242A]
X-Brightmail-Tracker: AAAAAA==
Cc: DISPATCH list <dispatch@ietf.org>, IESG IESG <iesg@ietf.org>, IETF-Discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Jul 2010 14:31:59 -0000

Hi Cullen,

the charter already says that the information "may be end-to-end
encrypted by the application". Therefore, proxies will not make any
decision (related or unrelated to call control) based on its contents
because the contents may simply not be available to the proxy.

Do you want the charter to be even more explicit about this?

Thanks,

Gonzalo

On 15/07/2010 5:06 PM, Cullen Jennings wrote:
> 
> I don't think this resolves the issue. The issue is if this information is used for a call control. Basically do proxies need to be able to look at this to make decision about what they are going to do. We at least need a Yes/No answer to this question from the proponents of this work and the charter to make that clear. 
> 
> 
> On Jul 14, 2010, at 2:25 AM, Gonzalo Camarillo wrote:
> 
>> Hi,
>>
>> thanks for your comments on the charter proposal. Per the comments
>> received, we will modify bullet 5 as follows so that it is clearer:
>>
>> OLD:
>> 5. SIP elements may need to apply policy about passing and screening
>>   the information.
>>
>> NEW:
>> 5. SIP elements may need to apply policy about passing and filtering
>>   UUI.  The included application, encoding, semantics, and content
>>   information will allow endpoint or intermediary SIP elements to
>>   allow or block UUI based on the type and originator, not based on
>>   the actual UUI data, which may be end-to-end encrypted by the
>>   application.
>>
>> Further discussions on this topic should happen on the mailing list of
>> this WG.
>>
>> Cheers,
>>
>> Gonzalo
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> 
> 
> Cullen Jennings
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
> 
>