Re: AW: [Sipping-tispan] draft-jesske-sipping-tispan-requirements-02c

Paul Kyzivat <pkyzivat@cisco.com> Thu, 01 September 2005 13:27 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAp6E-0001lB-67; Thu, 01 Sep 2005 09:27:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAp6C-0001l6-JG for sipping-tispan@megatron.ietf.org; Thu, 01 Sep 2005 09:27:24 -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 JAA03115 for <sipping-tispan@ietf.org>; Thu, 1 Sep 2005 09:27:23 -0400 (EDT)
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAp88-0006TV-1T for sipping-tispan@ietf.org; Thu, 01 Sep 2005 09:29:26 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 01 Sep 2005 06:27:13 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.96,160,1122879600"; d="scan'208"; a="8111817:sNHT23633140"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j81DR0Qv004293; Thu, 1 Sep 2005 09:27:11 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 09:27:10 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 09:27:09 -0400
Message-ID: <431701AD.2090000@cisco.com>
Date: Thu, 01 Sep 2005 09:27:09 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Miguel Garcia <Miguel.An.Garcia@nokia.com>
Subject: Re: AW: [Sipping-tispan] draft-jesske-sipping-tispan-requirements-02c
References: <CAC481363DB73049924DDDCFC1AC60A6EE44D9@esealmw109.eemea.ericsson.se> <4316D0C6.6000408@nokia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-OriginalArrivalTime: 01 Sep 2005 13:27:09.0755 (UTC) FILETIME=[DAE5E8B0:01C5AEF8]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 200d029292fbb60d25b263122ced50fc
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA03115
Cc: "Hans Erik van Elburg \(RY/ETM\)" <hanserik.van.elburg@ericsson.com>, 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


Miguel Garcia wrote:
> Hann Erik:
> 
> According to the discussion, the override requirement is related to the 
> category of the calling party, and affects not only ACR, but also other 
> services. Therefore, it has been decided to separate ACR from the 
> override. The override feature will be required when we go into the 
> REQ-CAT- requirements.

Hmm. That seems questionable to me. It means that there will be an 
important requirement on ACR that is specified independently of the main 
body of specification of ACR requirements.

I would think it clearer if there is a requirement for calling party 
category as a general mechanism, and then, if ACR is expected to behave 
differently in the presence of calling party category, that should be 
called out as an ACR requirement.

I think it is merely a matter getting the references done correctly. 
Perhaps this particular requirement can't be finalized until the REQ-CAT 
is finalized.

	Paul

> /Miguel
> 
> Hans Erik van Elburg (RY/ETM) wrote:
> 
>> Hi,
>>
>> I quite liked the previous proposal from Miguel, I'm not sure about 
>> why we have yet another counter proposal here.
>>
>> Is your reasoning Christian that if "The originating network shall be 
>> able to indicate to the terminating network, that the caller has 
>> requested anonymity." that an omission of this indication indicates 
>> that the network is the source of the restriction and not the caller 
>> and hence that ACR can forward this communication to the caller?
>>
>> I don't know I think I prefer the explicit requirement that Miguel 
>> formulated.
>>
>> Then we get:
>>
>>> REQ-ACR-1: The originating network shall be able to indicate to the
>>>           terminating network, that the caller has requested anonymity.
>>>
>>> REQ-ACR-2: The ACR simulation service requires the caller to be
>>>           informed that the communication was rejected because the
>>>           SIP request was anonymous and the callee had the ACR
>>>           service activated."
>>
>>
>> REQ-ACR-3: "The originating terminating 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."
>>
>>
>> /Hans Erik
>> sip:hanserik.van.elburg@tas.uab.ericsson.se
>>
>>
>> -----Original Message-----
>> From: sipping-tispan-bounces@ietf.org
>> [mailto:sipping-tispan-bounces@ietf.org]On Behalf Of Miguel Garcia
>> Sent: Thursday, September 01, 2005 11:01 AM
>> To: Schmidt, Christian
>> Cc: sipping-tispan@ietf.org; Alexeitsev, D
>> Subject: Re: AW: [Sipping-tispan]
>> draft-jesske-sipping-tispan-requirements-02c
>>
>>
>> This is ok, but can we remove the "override" feature?
>>
>> /Miguel
>>
>> Schmidt, Christian wrote:
>>
>>
>>> Hi,
>>>
>>> if the override request is skipped, we can simplify the ACR 
>>> requirements to
>>>
>>> "This service allows a callee to instruct the network to 
>>> automatically reject
>>> incoming communications when the caller has requested anonymity.  The 
>>> ACR
>>> supplementary service is described in ETSI EN 300 798 [13].
>>>
>>> ACR is a regulatory service.
>>>
>>> REQ-ACR-1: The originating network shall be able to indicate to the
>>>           terminating network, that the caller has requested anonymity.
>>>
>>> REQ-ACR-2: The ACR simulation service requires the caller to be
>>>           informed that the communication was rejected because the
>>>           SIP request was anonymous and the callee had the ACR
>>>           service activated."
>>>
>>> What do you think about?
>>> Christian
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: sipping-tispan-bounces@ietf.org 
>>> [mailto:sipping-tispan-bounces@ietf.org] Im Auftrag von Miguel Garcia
>>> Gesendet: Donnerstag, 1. September 2005 09:50
>>> An: sipping-tispan@ietf.org
>>> Cc: Alexeitsev, D
>>> Betreff: [Sipping-tispan] draft-jesske-sipping-tispan-requirements-02c
>>>
>>>
>>> Hi:
>>>
>>> I have put a new working copy of the requirements draft.
>>>
>>> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan-requirements-02c.txt 
>>>
>>> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan-requirements-02c.html 
>>>
>>>
>>> Changes with respect the previous version.
>>>
>>> - ACR: added a second requirement (REQ-ACR-2) that was discussed here 
>>> in the list, but I kept the old REQ-ACR-2 that now becomes -3.
>>>
>>> - I have added CCBS/CCNR, combined into a single set of requirements.
>>>
>>> I will start a separate thread , per topic, on both requirements, I 
>>> think we need more changes. Please comment on these or any other 
>>> service as you wish.
>>>
>>> /Miguel
>>>
>>
>>
> 

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