Re: AW: AW: AW: [Sipping-tispan] TISPAN requirements, first requiements

Miguel Garcia <Miguel.An.Garcia@nokia.com> Tue, 30 August 2005 12:41 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA5Qr-0003ev-PV; Tue, 30 Aug 2005 08:41:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA5Qm-0003dM-L7 for sipping-tispan@megatron.ietf.org; Tue, 30 Aug 2005 08:41:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09972 for <sipping-tispan@ietf.org>; Tue, 30 Aug 2005 08:41:35 -0400 (EDT)
Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA5SJ-0008OL-Ab for sipping-tispan@ietf.org; Tue, 30 Aug 2005 08:43:12 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j7UCfQB0008915; Tue, 30 Aug 2005 15:41:27 +0300
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Aug 2005 15:41:24 +0300
Received: from [127.0.0.1] ([172.21.35.195]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 30 Aug 2005 15:41:23 +0300
Message-ID: <431453F4.8040805@nokia.com>
Date: Tue, 30 Aug 2005 15:41:24 +0300
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en, es-es
MIME-Version: 1.0
To: Tom-PT Taylor <taylor@nortel.com>
Subject: Re: AW: AW: AW: [Sipping-tispan] TISPAN requirements, first requiements
References: <072C5B76F7CEAB488172C6F64B30B5E382D98D@xmb-rtp-20b.amer.cisco.com> <43135A54.4090400@nokia.com> <43136C90.10801@nortel.com>
In-Reply-To: <43136C90.10801@nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Aug 2005 12:41:23.0781 (UTC) FILETIME=[21580750:01C5AD60]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit
Cc: sipping-tispan@ietf.org, "Alexeitsev, D" <D.Alexeitsev@t-com.net>
X-BeenThere: sipping-tispan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion of requirements for SIP introduced by ETSI TISPAN <sipping-tispan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/sipping-tispan>
List-Post: <mailto:sipping-tispan@ietf.org>
List-Help: <mailto:sipping-tispan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=subscribe>
Sender: sipping-tispan-bounces@ietf.org
Errors-To: sipping-tispan-bounces@ietf.org

Tom-PT Taylor wrote:


>>
>> Well, I am not sure if that will work at all. Essentially this 
>> requires to allocate a bunch of bogus identities to those authorities 
>> that can bypass ACR. Anonymity will be achieved by having a large 
>> number of bogus identities, and having the UAC software able to change 
>> the identity on every call to the same callee (otherwise, the callee 
>> will know who is ringing the second time).
>>
>> Still it won't solve the issue of what happens if that authority 
>> selects the "anonymity" button in his UAC, and does an anonymous call? 
>> If you read the european privacy act (referred to in this list a few 
>> days ago),  the call will not go through if the calle has ACR 
>> activated, and most likely, the operatore will be responsible for it. 
>> Perhaps something that we shouldn't be taking a risk on.
>>
> [PTT] I still don't understand.  Why would a bunch of bogus identities 
> have to be allocated?  Why can't the common identity: "Official" be 
> used, for instance?

Because if you allocate an "Official" identity, which is presented to 
the callee, then a second call that will come from the same identit the 
callee would actually know who is calling... Well, perhaps you can argue 
that there is no requirement to tackle this problem (and perhaps you are 
right): it seems that the goal of the regulator is to deliver the call 
to the callee, not to prevent the callee to guess who is calling.

So, ok, perhaps we don't need "a bunch" if bogus identities, but just a 
bogus identity (per category).

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:miguel.an.garcia@openlaboratory.net
Nokia Research Center      Helsinki, Finland


_______________________________________________
Sipping-tispan mailing list
Sipping-tispan@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-tispan