Re: [Sipping-tispan] Requirements -02g

Paul Kyzivat <pkyzivat@cisco.com> Fri, 30 September 2005 13:33 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELL0Z-0006nw-AG; Fri, 30 Sep 2005 09:33:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELL0X-0006nr-MA for sipping-tispan@megatron.ietf.org; Fri, 30 Sep 2005 09:33:01 -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 JAA10937 for <sipping-tispan@ietf.org>; Fri, 30 Sep 2005 09:33:00 -0400 (EDT)
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELL8P-0005u4-Oa for sipping-tispan@ietf.org; Fri, 30 Sep 2005 09:41:10 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 30 Sep 2005 06:32:53 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.97,162,1125903600"; d="scan'208"; a="11910317:sNHT23008062"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8UDWbTI024603; Fri, 30 Sep 2005 09:32:50 -0400 (EDT)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Sep 2005 09:32:46 -0400
Received: from [161.44.79.87] ([161.44.79.87]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Sep 2005 09:32:45 -0400
Message-ID: <433D3E7D.8000307@cisco.com>
Date: Fri, 30 Sep 2005 09:32:45 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Hans Erik van Elburg (RY/ETM)" <hanserik.van.elburg@ericsson.com>
Subject: Re: [Sipping-tispan] Requirements -02g
References: <CAC481363DB73049924DDDCFC1AC60A6EE45C5@esealmw109.eemea.ericsson.se>
In-Reply-To: <CAC481363DB73049924DDDCFC1AC60A6EE45C5@esealmw109.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Sep 2005 13:32:45.0758 (UTC) FILETIME=[7126A5E0:01C5C5C3]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Content-Transfer-Encoding: 7bit
Cc: sipping-tispan@ietf.org
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


Hans Erik van Elburg (RY/ETM) wrote:
> Hi,
> 
> Since the calling parties category is not suitable nor ment for the case in which override of ACR is needed. And it was  said that we would come back to this requirement once it is time to discuss Calling Party's Category.
> 
> There is currently no TISPAN service that requires calling parties category, but it has been added for interworking reasons (basic call) and to allow services to (as a network option) act on this.  Follows that there is no relation with ACR whatsoever.
> 
> We propose to unhide the requirement that allows certain calls to bypass the ACR service. I think the last formulation of that requirement read:
> 
> 	REQ-ACR-3: The originating network shall be able to indicate to the 
> 	terminating network that the caller of an anonymous communication is 
> 	authorized to bypass the ACR service at the callee's network.

I have trouble with this because I believe the originating network has 
no right to *authorize* anything in the terminating network. It is the 
terminating network that will have to decide to bypass ACR service, and 
so it is the terminating network that must authorize that action.

At best, the originating network may *request* that the terminating 
network bypass the ACR service.

There seem to be at least a couple of mechanisms possible here, 
depending on what role you expect the originating and terminating 
network to take in this process:

- the originating network can simply state that the anonymity of
   the caller is at the pleasure of the originating network rather
   then the originating user. Then the terminating network can,
   if it wishes, decide to bypass ACR in that case.

- the originating network can explicitly indicate that it wishes
   ACR to be bypassed, for reasons of its own. And then the
   terminating network can, if it wishes, decide to honor the
   request and bypass ACR.

These require different information to be passed, and give differing 
amounts of information to the originating and terminating networks about 
  why ACR should be bypassed, and differing amounts of discretion to 
them regarding whether it actually happens.

I prefer the first approach. A requirement consistent with this might be:

   REQ-ACR-3: For anonymous calls, he originating network shall be able
   to indicate to the terminating network whether the identity of the
   caller is, or is not, available to the originating network.

	Paul

> Which was somewhere around
> http://www1.ietf.org/mail-archive/web/sipping-tispan/current/msg00070.html
> in the mailing list.
> 
> Best Regards,
> 
> /Hans Erik
> 
> -----Original Message-----
> From: sipping-tispan-bounces@ietf.org
> [mailto:sipping-tispan-bounces@ietf.org]On Behalf Of Miguel Garcia
> Sent: Wednesday, September 28, 2005 1:26 PM
> To: 'sipping-tispan@ietf.org'
> Cc: Alexeitsev, D
> Subject: [Sipping-tispan] Requirements -02g
> 
> 
> Hi:
> 
> I have this working copy of the requirements, version -02g:
> 
> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan-requirements-02g.txt
> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan-requirements-02g.html
> 
> And a diff version with respect -02f:
> 
> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan-requirements-02f-to-g.html
> 
> The changes in this version are:
> - Grouping of the CCBS/CCNR requirements for better understing
> - A few clarifications to the CDIV requirements
> - Addition of the Calling Party Category requirements.
> 
> Now, I have a few questions.
> 
> - The Calling Party Category requirements do not constitute a service by 
>   itself. In my opinion, they should be General requirements listed a 
> REQ-GEN-4 and REQ-GEN-5. Does anyone oppose to move them to the General 
> section?
> 
> - We had a pending action point to revisit the ACR requirements once we 
> have drafted the Calling Party Category requirements. Now we have 
> achieved this state, and my opinion is that we don't need to add any 
> extra wording to ACR, since the Calling Party Category requirements 
> cover the use case we have been discussing (police anonymously call a 
> user with ACR activated).
> 
> Last, but not least, WE ARE ALMOST DONE with the requirements. So please 
> take a look at this draft and comment on any pending issue. I would like 
> to solve issues as soon as possible and submit the draft for publication.
> 
> Regards,
> 
>          Miguel
> 

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