Re: AW: [Sipping-tispan] TISPAN requirements, first requiements
Paul Kyzivat <pkyzivat@cisco.com> Thu, 25 August 2005 03:31 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1E88Sr-0002lx-Mc; Wed, 24 Aug 2005 23:31:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1E88Sp-0002ls-P4
for sipping-tispan@megatron.ietf.org; Wed, 24 Aug 2005 23:31:39 -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 XAA12107
for <sipping-tispan@ietf.org>; Wed, 24 Aug 2005 23:31:37 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1E88TG-0003Mz-9W
for sipping-tispan@ietf.org; Wed, 24 Aug 2005 23:32:07 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
by sj-iport-1.cisco.com with ESMTP; 24 Aug 2005 20:31:29 -0700
X-IronPort-AV: i="3.96,139,1122879600";
d="scan'208"; a="656630163:sNHT33302332"
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
[128.107.191.63])
by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7P3VQ0J003933;
Wed, 24 Aug 2005 20:31:27 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
Wed, 24 Aug 2005 20:31:26 -0700
Received: from cisco.com ([10.89.16.172]) by xfe-sjc-212.amer.cisco.com with
Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Aug 2005 20:31:26 -0700
Message-ID: <430D3B8D.6020207@cisco.com>
Date: Wed, 24 Aug 2005 23:31:25 -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: "Jesske, R" <R.Jesske@t-com.net>
Subject: Re: AW: [Sipping-tispan] TISPAN requirements, first requiements
References: <E7666D92C64C2845AEF12636FF94F95202319E77@S4DE8PSAAGQ.blf.telekom.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-OriginalArrivalTime: 25 Aug 2005 03:31:26.0230 (UTC)
FILETIME=[79349360:01C5A925]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id XAA12107
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
Jesske, R wrote: > Paul, > With regard to this feature it must be based on trust relationship as defined within RFC3325 for the P-Asserted-Identity. > So the indication that this is a authorised user is included by a network entity like it is done for the P-Asserted-Identiy. > So the network entity knows it via a database that this registered user is a authorised one. Either I don't understand you, or you don't understand me. RFC3325 is a way for some trusted element of the network that knows the source of the request to assert a trusted identity for the source of the message. It doesn't provide any authorization for anything. Ultimately, the ACR service must be implemented near and on behalf of the recipient of the message. It isn't until there that it is known that there is any service to authorize. At that point, the P-Asserted-ID header may be present, but that just says who the caller is, not what role the caller is playing. It seems that you want to do role based authorization, where the role is "entitled-to-override-ACR". So how is this role determined? Surely the recipient can't have a DB of all values of P-Asserted-ID that are authorized. The alternative seems to be that the source inserts not just a simple P-Asserted-ID with a name, but rather also inserts some kind of role identification. I'm looking for more indication of what the expectations are in this regard. Is it the expectation that the source will annotate every call with an indication that the caller is permitted to override ACR? Or with some other more generic categorization of caller type? Or what? > With regard to the PSTN/ISDN this was solved via a indication that the Calling Party Number is restricted by the network. The network included this indication in three cases: > 1. The call was originated within a network that cannot provide a originating number (e.G.) analogue. > 2. The call has no originated number due to interworking with international networks > 3. The call was send from a authorised user (e.G. police). This indication was then set by the network. This feature is especially used in UK. So you are looking for some kind of enhancement to Privacy, that indicates *why* privacy is requested? Paul > So with the requirement proposed by Miguel we hope to find a solution to cover the 3 above mentioned cases. > > With regard to trust we want to have such a indication bind to a trust relationship as it is described within RFC3325. > So trust for interconnection to an other network is based on bilateral agreement. > > > Best Regards > > Roland > > >>-----Ursprüngliche Nachricht----- >>Von: sipping-tispan-bounces@ietf.org >>[mailto:sipping-tispan-bounces@ietf.org] Im Auftrag von Paul Kyzivat >>Gesendet: Mittwoch, 24. August 2005 05:07 >>An: Miguel Garcia >>Cc: sipping-tispan@ietf.org; Alexeitsev, Denis >>Betreff: Re: [Sipping-tispan] TISPAN requirements, first requiements >> >> >> >> >>Miguel Garcia wrote: >> >>>Folks: >>> >>>Since we are tasked to re-draft the TISPAN requirements >> >>adding as much >> >>>clarifications as possible, we would like to start checking >> >>with you if >> >>>the requirements related to the Annonymous Communication >> >>Rejection (ACR) >> >>>service is OK and understandable by everyone. >>> >>>So please take a look at the first version of the (much >> >>incomplete and >> >>>short) draft in either text or HTML: >>> >>> >> >>http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sippin > > g-tispan-requirements-02a.txt > >>http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan-requirements-02a.html >> >> >>The document is fairly short at the moment. Please post your comments here. > > > Regarding REQ-ACR-2: > > >> REQ-ACR-2: It must be possible that authorized callers are not >> subject to the ACR service, thus, allowing the callee to >> receive anonymous requests from authorized callers. This >> effectively requires a mechanism to override the ACR >> service depending on the identity and authorization of the >> caller. This is needed, e.g., when a police officer or >> any other authority is anonymously calling to a user >> having the ACR simulation service activated. > > > How is a caller authorized? Is the mechanism for determining and > conveying this authorization in scope for this service? There is mention > specifically of Police Officers, among others, as being authorized. Are > there a list of attributes like that which must be used to characterize > a caller and that are used to determine the authorization? > > How is this affected by peering and PSTN interconnect? Is an > authorization on one side to be conveyed to the other side and then > trusted their? > > Thanks, > Paul > > _______________________________________________ > Sipping-tispan mailing list > Sipping-tispan@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-tispan > _______________________________________________ Sipping-tispan mailing list Sipping-tispan@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-tispan
- AW: [Sipping-tispan] TISPAN requirements, first r… Jesske, R
- AW: [Sipping-tispan] TISPAN requirements, first r… Schmidt, Christian
- Re: AW: [Sipping-tispan] TISPAN requirements, fir… Miguel Garcia
- Re: AW: [Sipping-tispan] TISPAN requirements, fir… Miguel Garcia
- RE: AW: [Sipping-tispan] TISPAN requirements, fir… Michael Hammer (mhammer)
- Re: AW: [Sipping-tispan] TISPAN requirements, fir… Paul Kyzivat
- RE: AW: [Sipping-tispan] TISPAN requirements, fir… Elwell John
- RE: AW: [Sipping-tispan] TISPAN requirements, fir… Elwell John
- RE: AW: [Sipping-tispan] TISPAN requirements, fir… GARCIN Sebastien RD-CORE-ISS
- Re: AW: [Sipping-tispan] TISPAN requirements, fir… Paul Kyzivat
- RE: AW: [Sipping-tispan] TISPAN requirements, fir… Michael Hammer (mhammer)
- Re: AW: [Sipping-tispan] TISPAN requirements, fir… Paul Kyzivat