From ecrit-bounces@ietf.org Mon Aug 01 02:53:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzUAt-0000C8-NP; Mon, 01 Aug 2005 02:53:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzUAs-0000C0-HB for ecrit@megatron.ietf.org; Mon, 01 Aug 2005 02:53:22 -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 CAA07396 for ; Mon, 1 Aug 2005 02:53:21 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzUh6-0007V6-E9 for ecrit@ietf.org; Mon, 01 Aug 2005 03:26:41 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j716rAWQ027526; Mon, 1 Aug 2005 08:53:11 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j716rA2X012756; Mon, 1 Aug 2005 08:53:10 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Aug 2005 08:56:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] tschofenig-ecrit-security-threats Date: Mon, 1 Aug 2005 08:53:07 +0200 Message-ID: Thread-Topic: [Ecrit] tschofenig-ecrit-security-threats Thread-Index: AcWUpv3PoES7kTiVSDyLV1k6o+8+mgBZlUDA From: "Tschofenig, Hannes" To: "Cullen Jennings" , X-OriginalArrivalTime: 01 Aug 2005 06:56:39.0640 (UTC) FILETIME=[2AA7D580:01C59666] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi cullen,=20 thanks for the review.=20 > In many ways this looks at the VoIP threats in a very well structured > approach, but I feel like it is missing some of the obvious=20 > overall system > problems - problems that are probably not desirable to solve.=20 i think we should list all threats that are applicable for the ecrit scope.=20 i know that we need to scope our work a bit in this document and focus on threats that are also relevant for the requirements document. the security requirements should then indicate what threats are applicable for us. =20 i know that we list a few threats in the document that are outside the scope. i do not want to be the main driver of this document --- i hope to find someone in the working group to take over the document. i will raise this question again during the ecrit working group session.=20 > Let me give a > few examples of what I mean .... >=20 > Section 5.1 - DOS >=20 > Today, One can DOS a psap by taking a large handful of phones=20 > and dialing > 911 on them all at the same time. This is because of the=20 > limited number of > human operators at the PSAP. We don't want to solve this - we=20 > don't want to > stop more than a handful of phones from calling at once and=20 > we don't want to > add more operators. to a certain extend you are right.=20 what i cannot do with my mobile phone today is place an emergency call here in paris to the police in munich.=20 =20 >=20 > One can DOS a police of fire department by phoning in a bomb=20 > threat to high > school. Folks used to do this at my high school to avoid=20 > exams - I hope it > is not done so casually today. >=20 > 5.2 - Call to PSAP with no Identity >=20 > Do we really want to block 911 calls from pay phones? no. btw, having a pay phone does not have that no identities are used.=20 they are used by they cannot be traced back to real world persons (at least not in some countries). If=20 > caller id does not > work for some reason do we want to block the 911 call. I=20 > think it is more > likely to see that 911 calls will have to work from phones=20 > that have not > been registered and don't have billing accounts that would=20 > even allow a > normal call. there are some operational issues that depend on country specific laws.=20 we need to be prepared that the authenticated identity of the emergency caller might not be available to the psap.=20 =20 >=20 > 5.3 - Location Spoofing >=20 > No matter how we do location on phones, it will not always=20 > work. Today when > I phone 911 in the US from a residential PSTN line, the first=20 > thing they ask > me is where am I. I don't expect this to change. If my phone=20 > says I am in > San Jose but I tell them I am in Dallas, they transfer to me=20 > to Dallas PSAP. > I believe that they should continue to rely on the human=20 > version of where > the human is over the machine version. that's fine. the problem is more if i am in paris but i give them a call and tell them that i am in munich.=20 in some cases i might just not be able to say anything anymore.=20 additionally, you have to consider the instant messaging case where i don't want to type in my location (civic or geospatial location information).=20 >=20 > 5.4 - Impersonating a PSAP >=20 > It would be an absolute travesty if a given region brought a=20 > new PSAP online > and then when I called 911, my phone hung up the call because=20 > it did not > know about the new region. Many, many people are going to end=20 > up having > access to the credentials that would identify a psap as a real pasp. it would also be bad if you would like to place an emergency call and an adversary pretends to be the true psap. we certainly have todo a tradeoff regarding deployment complexity and security vulnerabilities (as we do it with all protocols). >=20 > I could go on with 5.5 to 5.10 but you get the idea. >=20 > My biggest fear about VoIP 911 is that it will be too=20 > complicated and fail > when most needed or that it will not be possible to=20 > continuously test that > it is working. i agree with you.=20 as previously indicated i think it does not hurt to mention all threats if we are later able to decide what threats we would like to address.=20 Usually the bad news about security is that it=20 > is only as > good as the weakest link. I think this is great news for 911,=20 > we don't need > the security to be stronger than the weakest link. And the=20 > weakest link is > pretty minimal. what security properties would you like to see being addressed in the context of ecrit?=20 we could provide the building blocks to secure certain parts if people want. i think we cannot mandate a certain emergency infrastructure to be used. ciao hannes >=20 > Cullen >=20 >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Aug 01 03:27:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzUiC-0007Af-7I; Mon, 01 Aug 2005 03:27:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzUbf-0006CB-Oa for ecrit@megatron.ietf.org; Mon, 01 Aug 2005 03:21:04 -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 DAA01095 for ; Mon, 1 Aug 2005 03:21:00 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzUx4-0008Fa-7v for ecrit@ietf.org; Mon, 01 Aug 2005 03:43:11 -0400 Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com [47.153.200.67]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j7179Ta19086; Mon, 1 Aug 2005 02:09:30 -0500 (CDT) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Aug 2005 17:09:14 +1000 Message-ID: From: "James Winterbottom" To: "Tschofenig, Hannes" , Cullen Jennings , ecrit@ietf.org Subject: RE: [Ecrit] tschofenig-ecrit-security-threats Date: Mon, 1 Aug 2005 17:09:07 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1380663746==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1380663746== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59667.E8712818" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C59667.E8712818 Content-Type: text/plain > > > 5.2 - Call to PSAP with no Identity > > Do we really want to block 911 calls from pay phones? no. btw, having a pay phone does not have that no identities are used. they are used by they cannot be traced back to real world persons (at least not in some countries). [AJW] I am not sure that have any certainty over the identity of a caller today anyway. With a wireline home phone you might know where it is coming from, and like wise with a pay phone. But you cannot say with any level of certainty who is making the call. Is this really something that we should try to introduce? If ------_=_NextPart_001_01C59667.E8712818 Content-Type: text/html Message

>
>
> 5.2 - Call to PSAP with no Identity
>
> Do we really want to block 911 calls from pay phones?

no.

btw, having a pay phone does not have that no identities are used.
they are used by they cannot be traced back to real world persons (at least not in some countries).

[AJW] I am not sure that have any certainty over the identity of a caller today anyway. With a wireline home phone you might know where it is coming from, and like wise with a pay phone. But you cannot say with any level of certainty who is making the call. Is this really something that we should try to introduce?



 If

 ------_=_NextPart_001_01C59667.E8712818-- --===============1380663746== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1380663746==-- From ecrit-bounces@ietf.org Mon Aug 01 04:52:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzW2V-0004kM-OL; Mon, 01 Aug 2005 04:52:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzW2T-0004kH-MQ for ecrit@megatron.ietf.org; Mon, 01 Aug 2005 04:52:50 -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 EAA06070 for ; Mon, 1 Aug 2005 04:52:47 -0400 (EDT) Message-Id: <200508010852.EAA06070@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzWYg-0004ya-2R for ecrit@ietf.org; Mon, 01 Aug 2005 05:26:09 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.51) id 1DzW2A-0005n9-QI; Mon, 01 Aug 2005 03:52:31 -0500 From: "Brian Rosen" To: "'James Winterbottom'" , "'Tschofenig, Hannes'" , "'Cullen Jennings'" , Subject: RE: [Ecrit] tschofenig-ecrit-security-threats Date: Mon, 1 Aug 2005 04:52:27 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWWasvPz+6LZffmQnSUdN1yZCWM0QAC2l2Q X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.4 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0886755516==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0886755516== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C59654.D38A90A0" This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C59654.D38A90A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Not in ecrit. Out of charter. Doesn't have anything to do with routing. Brian _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James Winterbottom Sent: Monday, August 01, 2005 3:09 AM To: Tschofenig, Hannes; Cullen Jennings; ecrit@ietf.org Subject: RE: [Ecrit] tschofenig-ecrit-security-threats > > > 5.2 - Call to PSAP with no Identity > > Do we really want to block 911 calls from pay phones? no. btw, having a pay phone does not have that no identities are used. they are used by they cannot be traced back to real world persons (at least not in some countries). [AJW] I am not sure that have any certainty over the identity of a caller today anyway. With a wireline home phone you might know where it is coming from, and like wise with a pay phone. But you cannot say with any level of certainty who is making the call. Is this really something that we should try to introduce? If ------=_NextPart_000_0017_01C59654.D38A90A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Not in = ecrit.

 

Out of charter.  Doesn’t = have anything to do with routing.

 

Brian

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James = Winterbottom
Sent: Monday, August 01, = 2005 3:09 AM
To: Tschofenig, Hannes; = Cullen Jennings; ecrit@ietf.org
Subject: RE: [Ecrit] tschofenig-ecrit-security-threats

 

>
>
> 5.2 - Call to PSAP with no Identity
>
> Do we really want to block 911 calls from pay phones?

no.

btw, having a pay phone does not have that no identities are used.
they are used by they cannot be traced back to real world persons (at = least not in some countries).

[AJW] I am not sure that have any certainty over the identity of a caller today anyway. With a wireline = home phone you might know where it is coming from, and like wise with a pay phone. = But you cannot say with any level of certainty who is making the call. Is this = really something that we should try to introduce?



 If

------=_NextPart_000_0017_01C59654.D38A90A0-- --===============0886755516== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0886755516==-- From ecrit-bounces@ietf.org Mon Aug 01 05:01:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzWAY-0006i6-HV; Mon, 01 Aug 2005 05:01:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzW9r-0006PJ-C7 for ecrit@megatron.ietf.org; Mon, 01 Aug 2005 05:00:27 -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 FAA06505 for ; Mon, 1 Aug 2005 05:00:25 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzWg5-0005Q7-Ry for ecrit@ietf.org; Mon, 01 Aug 2005 05:33:47 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 01 Aug 2005 02:00:16 -0700 X-IronPort-AV: i="3.95,156,1120460400"; d="scan'208"; a="327791021:sNHT31602160" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7190Bul028733 for ; Mon, 1 Aug 2005 02:00:11 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 02:00:16 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 02:00:15 -0700 From: "Marc Linsner" To: Date: Mon, 1 Aug 2005 05:00:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWWd21qKElJZAv3RSOxH8dNR9P/xA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 01 Aug 2005 09:00:16.0188 (UTC) FILETIME=[6F433FC0:01C59677] X-Spam-Score: 1.1 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Subject: [Ecrit] Presentation slides X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If you are presenting in tomorrow, please forward slides to the chairs.... Thanks, -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Aug 01 05:33:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzWft-0000Dw-7N; Mon, 01 Aug 2005 05:33:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzWLQ-0003CR-QE for ecrit@megatron.ietf.org; Mon, 01 Aug 2005 05:12: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 FAA07060 for ; Mon, 1 Aug 2005 05:12:22 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzWrf-0005qi-69 for ecrit@ietf.org; Mon, 01 Aug 2005 05:45:44 -0400 Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com [47.153.200.67]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j719Bsa05454; Mon, 1 Aug 2005 04:11:54 -0500 (CDT) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Aug 2005 19:10:49 +1000 Message-ID: From: "James Winterbottom" To: Brian Rosen , "'Tschofenig, Hannes'" , "'Cullen Jennings'" , ecrit@ietf.org Subject: RE: [Ecrit] tschofenig-ecrit-security-threats Date: Mon, 1 Aug 2005 19:10:47 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.6 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1313982510==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1313982510== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59678.E70A79B4" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C59678.E70A79B4 Content-Type: text/plain I agree with that Brian, my question was more along the lines of is this even a good thing to do? -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Monday, 1 August 2005 6:52 PM To: Winterbottom, James [WOLL:5500:EXCH]; 'Tschofenig, Hannes'; 'Cullen Jennings'; ecrit@ietf.org Subject: RE: [Ecrit] tschofenig-ecrit-security-threats Not in ecrit. Out of charter. Doesn't have anything to do with routing. Brian _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James Winterbottom Sent: Monday, August 01, 2005 3:09 AM To: Tschofenig, Hannes; Cullen Jennings; ecrit@ietf.org Subject: RE: [Ecrit] tschofenig-ecrit-security-threats > > > 5.2 - Call to PSAP with no Identity > > Do we really want to block 911 calls from pay phones? no. btw, having a pay phone does not have that no identities are used. they are used by they cannot be traced back to real world persons (at least not in some countries). [AJW] I am not sure that have any certainty over the identity of a caller today anyway. With a wireline home phone you might know where it is coming from, and like wise with a pay phone. But you cannot say with any level of certainty who is making the call. Is this really something that we should try to introduce? If ------_=_NextPart_001_01C59678.E70A79B4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
I=20 agree with that Brian, my question was more along the lines of is = this even=20 a good thing to do?
 
-----Original Message-----
From: = Brian Rosen=20 [mailto:br@brianrosen.net]
Sent: Monday, 1 August 2005 = 6:52=20 PM
To: Winterbottom, James [WOLL:5500:EXCH]; 'Tschofenig, = Hannes';=20 'Cullen Jennings'; ecrit@ietf.org
Subject: RE: [Ecrit]=20 tschofenig-ecrit-security-threats

Not in=20 ecrit.

 

Out of = charter. =20 Doesn't have anything to do with = routing.

 

Brian

 

From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James=20 Winterbottom
Sent: = Monday,=20 August 01, 2005 3:09 AM
To:=20 Tschofenig, Hannes; Cullen Jennings; ecrit@ietf.org
Subject: RE: [Ecrit]=20 tschofenig-ecrit-security-threats

 

>
>
> 5.2 - Call to PSAP = with no=20 Identity
>
> Do we really want to block 911 calls from = pay=20 phones?

no.

btw, having a pay phone does not have that = no=20 identities are used.
they are used by they cannot be traced back = to real=20 world persons (at least not in some = countries).

[AJW] I am = not sure=20 that have any certainty over the identity of a caller today anyway. = With a=20 wireline home phone you might know where it is coming from, and like = wise with=20 a pay phone. But you cannot say with any level of certainty who is = making the=20 call. Is this really something that we should try to=20 introduce?



 If

------_=_NextPart_001_01C59678.E70A79B4-- --===============1313982510== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1313982510==-- From ecrit-bounces@ietf.org Mon Aug 01 05:33:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzWft-0000EZ-JC; Mon, 01 Aug 2005 05:33:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzWLm-0003MT-MM for ecrit@megatron.ietf.org; Mon, 01 Aug 2005 05:12:46 -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 FAA07082 for ; Mon, 1 Aug 2005 05:12:44 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzWs1-0005ua-4u for ecrit@ietf.org; Mon, 01 Aug 2005 05:46:06 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 01 Aug 2005 02:12:37 -0700 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 j719CVIs006149 for ; Mon, 1 Aug 2005 02:12:31 -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); Mon, 1 Aug 2005 02:12:33 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 02:12:33 -0700 From: "Marc Linsner" To: Date: Mon, 1 Aug 2005 05:12:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWWeSOAvMc+Oml9RqaDevKRkY0vxg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 01 Aug 2005 09:12:34.0027 (UTC) FILETIME=[270C8BB0:01C59679] X-Spam-Score: 1.1 (+) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [Ecrit] Please read..... X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Come prepared.....please (re)read: http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements-01. txt -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 05:07:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzskc-0002Mb-Co; Tue, 02 Aug 2005 05:07:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzska-0002M0-Km for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 05:07:52 -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 FAA01366 for ; Tue, 2 Aug 2005 05:07:50 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DztH0-0003s5-UU for ecrit@ietf.org; Tue, 02 Aug 2005 05:41:25 -0400 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j7297lsw029877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 2 Aug 2005 05:07:47 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j7297k8n017765 for ; Tue, 2 Aug 2005 05:07:46 -0400 Message-ID: <42EF37E8.6090409@cs.columbia.edu> Date: Tue, 02 Aug 2005 05:07:52 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: [Ecrit] Suggestion for "performance and reliability" section X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I would think capturing the known external requirements as such is helpful. For example, the NENA 2s (dial-to-ring) requirement, which is part of the 10s dial-to-pick-up I mentioned could just be captured as such external guidelines, possibly in a separate "performance and reliability" section. If early implementations, with reasonable assumptions on round-trip times and topology, can't satisfy those, we know we have a problem. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 05:50:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztPS-0004z1-HN; Tue, 02 Aug 2005 05:50:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztPR-0004yC-AK for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 05:50:05 -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 FAA03351 for ; Tue, 2 Aug 2005 05:50:00 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dztvq-0005gq-Jl for ecrit@ietf.org; Tue, 02 Aug 2005 06:23:36 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j729noFI005832 for ; Tue, 2 Aug 2005 11:49:50 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j729noIs002028 for ; Tue, 2 Aug 2005 11:49:50 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Aug 2005 11:53:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Aug 2005 11:49:49 +0200 Message-ID: Thread-Topic: ietf#63 slides Thread-Index: AcWXR4SzQBmz2cQtQSO0UURgDYy6mg== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 02 Aug 2005 09:53:19.0859 (UTC) FILETIME=[034AA430:01C59748] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] ietf#63 slides X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 please find the slides at:=20 http://www.ietf-ecrit.org/IETF63/ ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 08:09:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzva5-0000nm-PA; Tue, 02 Aug 2005 08:09:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzva4-0000j9-2D for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 08:09:12 -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 IAA14348 for ; Tue, 2 Aug 2005 08:09:10 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dzw6W-0004Wd-P5 for ecrit@ietf.org; Tue, 02 Aug 2005 08:42:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Date: Tue, 2 Aug 2005 14:12:28 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C07E@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Thread-Index: AcWMohcYjkmWAhVJTlmirWyCc6wDnwADYWIgAqq2ZXE= From: "Stastny Richard" To: "Brian Rosen" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Brian, =20 in your presentation today you mentioned that the DNS does not need to fillid up fully to the street and number level, you can stop earlier and use a wildcard NAPTR to the PSAP URI =20 We had a discussion on this afterwards and the question came up how a device is then able to check the validity of an address.? =20 So if a device wants to validate an address, how is this done in your proposal? Via a separate database? =20 The other possibility is to fill up the DNS always down to the street and housenumber level even it contains the same PSAP URI =20 regards Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 08:19:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzvjf-0006xA-RG; Tue, 02 Aug 2005 08:19:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzvjd-0006wR-Ls for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 08:19:05 -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 IAA14922 for ; Tue, 2 Aug 2005 08:19:04 -0400 (EDT) Message-Id: <200508021219.IAA14922@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzwG7-00050h-Hs for ecrit@ietf.org; Tue, 02 Aug 2005 08:52:39 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.51) id 1DzvjT-0001UJ-Pl for ecrit@ietf.org; Tue, 02 Aug 2005 07:18:56 -0500 From: "Brian Rosen" To: "'ECRIT'" Date: Tue, 2 Aug 2005 08:18:53 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWXXFji1u8HVdClTKCAX3Oxl6HOSA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.1 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Subject: [Ecrit] Performance Requirement X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1193202403==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1193202403== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B1_01C5973A.D403E6D0" This is a multi-part message in MIME format. ------=_NextPart_000_00B1_01C5973A.D403E6D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Rohan suggested we remove the D5 requirement and replace it with a motivational section, since there was no requirement. I think we should have a concrete goal, with a motivation for how we came to the goal. I propose: The time required to map SHOULD be 500ms, assuming normal caching strategies in the mechanism work. The maximum time SHOULD be 1 second. Motivation: Total time from last digit pressed to ring at the PSAP should be two seconds. Allocating one quarter of that to the mapping mechanism seems reasonable, and achievable if caching mechanisms work well enough for a single element to determine the mapping. Brian ------=_NextPart_000_00B1_01C5973A.D403E6D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Rohan suggested we remove the D5 requirement and = replace it with a motivational section, since there was no requirement.  I = think we should have a concrete goal, with a motivation for how we came to the goal.  I propose:

 

The time required to map SHOULD be 500ms, assuming = normal caching strategies in the mechanism work.  The maximum time SHOULD = be 1 second.

 

Motivation: Total time from last digit pressed to = ring at the PSAP should be two seconds.  Allocating one quarter of that to = the mapping mechanism seems reasonable, and achievable if caching mechanisms = work well enough for a single element to determine the = mapping.

 

Brian

 

 

 

------=_NextPart_000_00B1_01C5973A.D403E6D0-- --===============1193202403== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1193202403==-- From ecrit-bounces@ietf.org Tue Aug 02 08:43:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzw7X-0006kG-LA; Tue, 02 Aug 2005 08:43:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzw7V-0006kB-GZ for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 08:43:45 -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 IAA16074 for ; Tue, 2 Aug 2005 08:43:43 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzwdw-0005zR-G4 for ecrit@ietf.org; Tue, 02 Aug 2005 09:17:19 -0400 Received: from [86.255.27.133] ([::ffff:86.255.27.133]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 02 Aug 2005 08:43:39 -0400 id 00160341.42EF6A7C.00006D72 In-Reply-To: <200508021219.IAA14922@ietf.org> References: <200508021219.IAA14922@ietf.org> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Performance Requirement Date: Tue, 2 Aug 2005 08:43:39 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Aug 2, 2005, at 8:18 AM, Brian Rosen wrote: > Rohan suggested we remove the D5 requirement and replace it with a > motivational section, since there was no requirement. I think we > should have a concrete goal, with a motivation for how we came to > the goal. I propose: > > > > The time required to map SHOULD be 500ms, assuming normal caching > strategies in the mechanism work. The maximum time SHOULD be 1 > second. > > > > Motivation: Total time from last digit pressed to ring at the PSAP > should be two seconds. Allocating one quarter of that to the > mapping mechanism seems reasonable, and achievable if caching > mechanisms work well enough for a single element to determine the > mapping. I believe that if we continue applying 2119 language, then specifying it as a gaol or a requirement has no difference. Also, the mechanism specifies caching. Given we don't know what the requirements are for caching, we should avoid this language. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 09:30:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwqG-0004iT-MW; Tue, 02 Aug 2005 09:30:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwqF-0004go-GI for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 09:29:59 -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 JAA18799 for ; Tue, 2 Aug 2005 09:29:57 -0400 (EDT) Message-Id: <200508021329.JAA18799@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzxMk-00081r-2a for ecrit@ietf.org; Tue, 02 Aug 2005 10:03:34 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.51) id 1Dzwq4-0004du-Rk; Tue, 02 Aug 2005 08:29:49 -0500 From: "Brian Rosen" To: "'Stastny Richard'" , "'ECRIT'" Subject: RE: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Date: Tue, 2 Aug 2005 09:29:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWMohcYjkmWAhVJTlmirWyCc6wDnwADYWIgAqq2ZXEAAsQ44A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C07E@oefeg-s04.oefeg.loc> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This has to do with the ability to start up, vs the ability to validate street addresses for dispatch. When you start, you don't HAVE to load all the data down to street address to be able to map (route) emergency calls. You can populate enough of the database to get the correct mapping needed, and that's all. You can use a wildcard to allow a query to a fully specified location, without a fully specified database. An example would be if you have a PSAP NAPTR wildcard for *.bergen.nj.us.sos.arpa, then a query to 123.main.bergen.nj.us.sos.arpa would return that PSAP NAPTR. You can later go in and populate the data below that level. When you do, you need to put the actual NAPTR in the leaf nodes (123.main...). You then get the ability to validate. Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, August 02, 2005 8:12 AM To: Brian Rosen; ECRIT Subject: Re: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Hi Brian, in your presentation today you mentioned that the DNS does not need to fillid up fully to the street and number level, you can stop earlier and use a wildcard NAPTR to the PSAP URI We had a discussion on this afterwards and the question came up how a device is then able to check the validity of an address.? So if a device wants to validate an address, how is this done in your proposal? Via a separate database? The other possibility is to fill up the DNS always down to the street and housenumber level even it contains the same PSAP URI regards Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 09:37:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwxL-0006uy-9t; Tue, 02 Aug 2005 09:37:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwxJ-0006uq-Fa for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 09:37:17 -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 JAA19049 for ; Tue, 2 Aug 2005 09:37:15 -0400 (EDT) Message-Id: <200508021337.JAA19049@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzxTo-0008Kj-3x for ecrit@ietf.org; Tue, 02 Aug 2005 10:10:52 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.51) id 1Dzwx9-0004xb-IT; Tue, 02 Aug 2005 08:37:08 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] Performance Requirement Date: Tue, 2 Aug 2005 09:36:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWXX8+QACq9+Vf9S1uFAicg2SUTOwABn+lg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org There is a difference between a "motivational" paragraph discussing the problem and an actual requirement. The former is non normative. All of the proposals use caching. I don't see a problem saying that the performance requirement is measured when caching "works" as intended in the mechanism. We can use weasel words like "to the extent caching is employed in the mechanism, the goal of 500ms would be measured when caching strategies in the mechanism work". Brian -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Tuesday, August 02, 2005 8:44 AM To: Brian Rosen Cc: 'ECRIT' Subject: Re: [Ecrit] Performance Requirement On Aug 2, 2005, at 8:18 AM, Brian Rosen wrote: > Rohan suggested we remove the D5 requirement and replace it with a > motivational section, since there was no requirement. I think we > should have a concrete goal, with a motivation for how we came to > the goal. I propose: > > > > The time required to map SHOULD be 500ms, assuming normal caching > strategies in the mechanism work. The maximum time SHOULD be 1 > second. > > > > Motivation: Total time from last digit pressed to ring at the PSAP > should be two seconds. Allocating one quarter of that to the > mapping mechanism seems reasonable, and achievable if caching > mechanisms work well enough for a single element to determine the > mapping. I believe that if we continue applying 2119 language, then specifying it as a gaol or a requirement has no difference. Also, the mechanism specifies caching. Given we don't know what the requirements are for caching, we should avoid this language. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 09:37:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzwxd-0006wb-Q2; Tue, 02 Aug 2005 09:37:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzwxc-0006wW-4K for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 09:37: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 JAA19058 for ; Tue, 2 Aug 2005 09:37:34 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DzxU5-0008Kr-GC for ecrit@ietf.org; Tue, 02 Aug 2005 10:11:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Date: Tue, 2 Aug 2005 15:38:11 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C07F@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Thread-Index: AcWMohcYjkmWAhVJTlmirWyCc6wDnwADYWIgAqq2ZXEAAsQ44AAAeWVe From: "Stastny Richard" To: "Brian Rosen" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Thanks Brian, =20 we also saw another problem here: If we populate the DNS down to the full streetname, we eventually will overrun the DNS domainname and label lenght restrictions, because we have to use IDN. =20 We need to check this. =20 -richard ________________________________ Von: Brian Rosen [mailto:br@brianrosen.net] Gesendet: Di 02.08.2005 15:29 An: Stastny Richard; 'ECRIT' Betreff: RE: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt=20 This has to do with the ability to start up, vs the ability to validate street addresses for dispatch. When you start, you don't HAVE to load all the data down to street = address to be able to map (route) emergency calls. You can populate enough of = the database to get the correct mapping needed, and that's all. You can use = a wildcard to allow a query to a fully specified location, without a fully specified database. An example would be if you have a PSAP NAPTR = wildcard for *.bergen.nj.us.sos.arpa, then a query to = 123.main.bergen.nj.us.sos.arpa would return that PSAP NAPTR. You can later go in and populate the data below that level. When you = do, you need to put the actual NAPTR in the leaf nodes (123.main...). You = then get the ability to validate. Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, August 02, 2005 8:12 AM To: Brian Rosen; ECRIT Subject: Re: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Hi Brian, in your presentation today you mentioned that the DNS does not need to fillid up fully to the street and number level, you can stop earlier and use a wildcard NAPTR to the PSAP URI We had a discussion on this afterwards and the question came up how a device is then able to check the validity of an address.? So if a device wants to validate an address, how is this done in your proposal? Via a separate database? The other possibility is to fill up the DNS always down to the street and housenumber level even it contains the same PSAP URI regards Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 09:41:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzx16-0008AX-5S; Tue, 02 Aug 2005 09:41:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzx14-0008AM-68 for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 09:41:10 -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 JAA19294 for ; Tue, 2 Aug 2005 09:41:08 -0400 (EDT) Message-Id: <200508021341.JAA19294@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzxXY-0008UV-IL for ecrit@ietf.org; Tue, 02 Aug 2005 10:14:45 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.51) id 1Dzx0t-0005J2-MX; Tue, 02 Aug 2005 08:41:00 -0500 From: "Brian Rosen" To: "'Stastny Richard'" , "'ECRIT'" Subject: RE: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Date: Tue, 2 Aug 2005 09:40:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWMohcYjkmWAhVJTlmirWyCc6wDnwADYWIgAqq2ZXEAAsQ44AAAeWVeAAAQpBA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C07F@oefeg-s04.oefeg.loc> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I mentioned this. If you can exceed the length limit, you need to (consistently) use abbreviations. Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, August 02, 2005 9:38 AM To: Brian Rosen; ECRIT Subject: Re: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Thanks Brian, we also saw another problem here: If we populate the DNS down to the full streetname, we eventually will overrun the DNS domainname and label lenght restrictions, because we have to use IDN. We need to check this. -richard ________________________________ Von: Brian Rosen [mailto:br@brianrosen.net] Gesendet: Di 02.08.2005 15:29 An: Stastny Richard; 'ECRIT' Betreff: RE: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt This has to do with the ability to start up, vs the ability to validate street addresses for dispatch. When you start, you don't HAVE to load all the data down to street address to be able to map (route) emergency calls. You can populate enough of the database to get the correct mapping needed, and that's all. You can use a wildcard to allow a query to a fully specified location, without a fully specified database. An example would be if you have a PSAP NAPTR wildcard for *.bergen.nj.us.sos.arpa, then a query to 123.main.bergen.nj.us.sos.arpa would return that PSAP NAPTR. You can later go in and populate the data below that level. When you do, you need to put the actual NAPTR in the leaf nodes (123.main...). You then get the ability to validate. Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, August 02, 2005 8:12 AM To: Brian Rosen; ECRIT Subject: Re: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Hi Brian, in your presentation today you mentioned that the DNS does not need to fillid up fully to the street and number level, you can stop earlier and use a wildcard NAPTR to the PSAP URI We had a discussion on this afterwards and the question came up how a device is then able to check the validity of an address.? So if a device wants to validate an address, how is this done in your proposal? Via a separate database? The other possibility is to fill up the DNS always down to the street and housenumber level even it contains the same PSAP URI regards Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 09:44:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzx4Z-0002HN-0u; Tue, 02 Aug 2005 09:44:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzx4Y-0002HD-HW for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 09:44:46 -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 JAA19571 for ; Tue, 2 Aug 2005 09:44:44 -0400 (EDT) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzxb2-0000EQ-VY for ecrit@ietf.org; Tue, 02 Aug 2005 10:18:21 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j72Dih5S016594 for ; Tue, 2 Aug 2005 15:44:43 +0200 Received: from mhpahx2c.ww002.siemens.net (mhpahx2c.mch.sbs.de [139.25.165.55]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id j72Dig0A007121 for ; Tue, 2 Aug 2005 15:44:42 +0200 Received: from MCHP7R5A.ww002.siemens.net ([139.25.131.163]) by mhpahx2c.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Aug 2005 15:41:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Date: Tue, 2 Aug 2005 15:44:37 +0200 Message-ID: Thread-Topic: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Thread-Index: AcWMohcYjkmWAhVJTlmirWyCc6wDnwADYWIgAqq2ZXEAAsQ44AAAeWVeAAAfkdA= From: "Schwarzbauer, Hanns Juergen" To: "ECRIT" X-OriginalArrivalTime: 02 Aug 2005 13:41:42.0703 (UTC) FILETIME=[EAD2B3F0:01C59767] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org just another "international" issue support of DNS names using unicode has to be considered greetings HannsJuergen -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Stastny Richard Sent: Tuesday, August 02, 2005 3:38 PM To: Brian Rosen; ECRIT Subject: Re: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt=20 Thanks Brian, =20 we also saw another problem here: If we populate the DNS down to the full streetname, we eventually will overrun the DNS domainname and label lenght restrictions, because we have to use IDN. =20 We need to check this. =20 -richard ________________________________ Von: Brian Rosen [mailto:br@brianrosen.net] Gesendet: Di 02.08.2005 15:29 An: Stastny Richard; 'ECRIT' Betreff: RE: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt=20 This has to do with the ability to start up, vs the ability to validate street addresses for dispatch. When you start, you don't HAVE to load all the data down to street address to be able to map (route) emergency calls. You can populate enough of the database to get the correct mapping needed, and that's all. You can use a wildcard to allow a query to a fully specified location, without a fully specified database. An example would be if you have a PSAP NAPTR wildcard for *.bergen.nj.us.sos.arpa, then a query to 123.main.bergen.nj.us.sos.arpa would return that PSAP NAPTR. You can later go in and populate the data below that level. When you do, you need to put the actual NAPTR in the leaf nodes (123.main...). You then get the ability to validate. Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, August 02, 2005 8:12 AM To: Brian Rosen; ECRIT Subject: Re: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Hi Brian, in your presentation today you mentioned that the DNS does not need to fillid up fully to the street and number level, you can stop earlier and use a wildcard NAPTR to the PSAP URI We had a discussion on this afterwards and the question came up how a device is then able to check the validity of an address.? So if a device wants to validate an address, how is this done in your proposal? Via a separate database? The other possibility is to fill up the DNS always down to the street and housenumber level even it contains the same PSAP URI regards Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 09:47:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzx7d-00059S-G7; Tue, 02 Aug 2005 09:47:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzx7b-00056t-NC for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 09:47:55 -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 JAA19755 for ; Tue, 2 Aug 2005 09:47:53 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzxe5-0000N1-Dc for ecrit@ietf.org; Tue, 02 Aug 2005 10:21:30 -0400 Received: from [86.255.27.133] ([::ffff:86.255.27.133]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 02 Aug 2005 09:47:50 -0400 id 001603B9.42EF7986.00007CF1 In-Reply-To: <200508021329.JAA18799@ietf.org> References: <200508021329.JAA18799@ietf.org> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <97F80A8C-106F-47B0-A131-EC634507CEC8@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Date: Tue, 2 Aug 2005 09:47:48 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: 'Stastny Richard' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Aug 2, 2005, at 9:29 AM, Brian Rosen wrote: > When you start, you don't HAVE to load all the data down to street > address > to be able to map (route) emergency calls. You can populate enough > of the > database to get the correct mapping needed, and that's all. You > can use a > wildcard to allow a query to a fully specified location, without a > fully > specified database. An example would be if you have a PSAP NAPTR > wildcard > for *.bergen.nj.us.sos.arpa, then a query to > 123.main.bergen.nj.us.sos.arpa > would return that PSAP NAPTR. I don't think this answers the question. If there is a wildcard *.bergen.nj.us.sos.arpa, for validation purposes how do you distinguish between a correct answer for the query of: 123.main.bergen.nj.us.sos.arpa and this-is-obviously-bogus.bergen.nj.us.sos.arpa -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 10:01:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxKm-0006fU-NH; Tue, 02 Aug 2005 10:01:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxKk-0006fM-Vx for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 10:01:31 -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 KAA20475 for ; Tue, 2 Aug 2005 10:01:28 -0400 (EDT) Message-Id: <200508021401.KAA20475@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzxrF-0000xe-QS for ecrit@ietf.org; Tue, 02 Aug 2005 10:35:06 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.51) id 1DzxKb-0006G1-6e; Tue, 02 Aug 2005 09:01:21 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Date: Tue, 2 Aug 2005 10:01:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWXaMbwnKk+Cy7ER12rCltLd/G25wAAKySA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <97F80A8C-106F-47B0-A131-EC634507CEC8@hxr.us> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: 'Stastny Richard' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org You don't. If there is no validation data, any location is a valid location, and in particular, if you put in any address in the range of the wildcard, validation will pass. Mapping will pass. That is as it should be I think. If you are really concerned about the ability of the client to know if validation data is available, I can propose a solution. Brian -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Tuesday, August 02, 2005 9:48 AM To: Brian Rosen Cc: 'Stastny Richard'; 'ECRIT' Subject: Re: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt On Aug 2, 2005, at 9:29 AM, Brian Rosen wrote: > When you start, you don't HAVE to load all the data down to street > address > to be able to map (route) emergency calls. You can populate enough > of the > database to get the correct mapping needed, and that's all. You > can use a > wildcard to allow a query to a fully specified location, without a > fully > specified database. An example would be if you have a PSAP NAPTR > wildcard > for *.bergen.nj.us.sos.arpa, then a query to > 123.main.bergen.nj.us.sos.arpa > would return that PSAP NAPTR. I don't think this answers the question. If there is a wildcard *.bergen.nj.us.sos.arpa, for validation purposes how do you distinguish between a correct answer for the query of: 123.main.bergen.nj.us.sos.arpa and this-is-obviously-bogus.bergen.nj.us.sos.arpa -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 10:19:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzxbw-0006Sm-2o; Tue, 02 Aug 2005 10:19:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzxbt-0006Qj-NF for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 10:19:13 -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 KAA22553 for ; Tue, 2 Aug 2005 10:19:11 -0400 (EDT) Received: from ip-66.249.239.5.indigital.net ([66.249.239.5] helo=apa7.indigital.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzy8J-0001nb-Fg for ecrit@ietf.org; Tue, 02 Aug 2005 10:52:48 -0400 Received: from [66.170.32.23] (helo=byron) by apa7.indigital.net with smtp (Exim 4.43) id 1Dzxbf-0002gA-4l for ecrit@ietf.org; Tue, 02 Aug 2005 09:18:59 -0500 From: "Byron Smith" To: Subject: RE: [Ecrit] Suggestion for "performance and reliability" section Date: Tue, 2 Aug 2005 09:21:27 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <42EF37E8.6090409@cs.columbia.edu> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Henning, where do you get the NENA 2s and 10s numbers? The only thing I have found in NENA documents is: " 9 Call Set-up Time It is recommended that emergency call set-up time not exceed the average call set-up time for any other type call made by the customers of that particular serving office. It is also strongly recommended that in all circumstances the caller hear either audible ring tone or a recording alerting them that their call is being processed." The above is from NENA 03-501. I have looked for other NENA recommendations, but have not found them. I would appreciate a reference if you have one. Not that this is terribly relevant: But I would make a small wager that more than 50% of the (rural) wireline 911 systems in the country fail to meet the above recommendations. (Probably closer to 80%) The observed call setup time for systems that use CAMA trunks is usually 3-7 seconds dial-to-ring, with 5 seconds being typical. Most digital end-office switches make local dial-to-ring setups on the order of 1 second. Byron > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of > Henning Schulzrinne > Sent: Tuesday, August 02, 2005 4:08 AM > To: ecrit@ietf.org > Subject: [Ecrit] Suggestion for "performance and reliability" section > > > I would think capturing the known external requirements as such is > helpful. For example, the NENA 2s (dial-to-ring) requirement, which is > part of the 10s dial-to-pick-up I mentioned could just be captured as > such external guidelines, possibly in a separate "performance and > reliability" section. If early implementations, with reasonable > assumptions on round-trip times and topology, can't satisfy those, we > know we have a problem. > > Henning > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.338 / Virus Database: 267.9.7/60 - Release Date: 7/28/2005 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 10:19:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxTh-00060D-4d; Tue, 02 Aug 2005 10:10:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxTe-0005wr-QY for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 10:10:42 -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 KAA21452 for ; Tue, 2 Aug 2005 10:10:40 -0400 (EDT) Message-Id: <200508021410.KAA21452@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzy09-0001Lc-K3 for ecrit@ietf.org; Tue, 02 Aug 2005 10:44:17 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.51) id 1DzxTU-0006gh-MW; Tue, 02 Aug 2005 09:10:33 -0500 From: "Brian Rosen" To: "'Brian Rosen'" , "'Andrew Newton'" Subject: RE: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Date: Tue, 2 Aug 2005 10:10:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWXaMbwnKk+Cy7ER12rCltLd/G25wAAKySAAACFbQA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <200508021401.KAA20475@ietf.org> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: 'Stastny Richard' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I reread this and wondered if I misunderstood the question. If you DO have validation data, you DON'T have a wildcard. So if the question was how do I distinguish a valid location from an invalid one if I there is validation data, then the answer is there is no wildcard, and a request to validate would return no RRs. If the question was how do you distinguish between a good location and an obviously bad location when there is no validation data, then the answer is that you can't. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, August 02, 2005 10:01 AM To: 'Andrew Newton' Cc: 'Stastny Richard'; 'ECRIT' Subject: RE: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt You don't. If there is no validation data, any location is a valid location, and in particular, if you put in any address in the range of the wildcard, validation will pass. Mapping will pass. That is as it should be I think. If you are really concerned about the ability of the client to know if validation data is available, I can propose a solution. Brian -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Tuesday, August 02, 2005 9:48 AM To: Brian Rosen Cc: 'Stastny Richard'; 'ECRIT' Subject: Re: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt On Aug 2, 2005, at 9:29 AM, Brian Rosen wrote: > When you start, you don't HAVE to load all the data down to street > address > to be able to map (route) emergency calls. You can populate enough > of the > database to get the correct mapping needed, and that's all. You > can use a > wildcard to allow a query to a fully specified location, without a > fully > specified database. An example would be if you have a PSAP NAPTR > wildcard > for *.bergen.nj.us.sos.arpa, then a query to > 123.main.bergen.nj.us.sos.arpa > would return that PSAP NAPTR. I don't think this answers the question. If there is a wildcard *.bergen.nj.us.sos.arpa, for validation purposes how do you distinguish between a correct answer for the query of: 123.main.bergen.nj.us.sos.arpa and this-is-obviously-bogus.bergen.nj.us.sos.arpa -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 10:49:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzy5P-0001Tc-4h; Tue, 02 Aug 2005 10:49:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzy5N-0001Se-Kn for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 10:49:41 -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 KAA25543 for ; Tue, 2 Aug 2005 10:49:39 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzybp-0003RJ-MA for ecrit@ietf.org; Tue, 02 Aug 2005 11:23:16 -0400 Received: from [86.255.27.133] ([::ffff:86.255.27.133]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 02 Aug 2005 10:49:33 -0400 id 001603BC.42EF87FD.00000AC8 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0232E18C-3AAE-4115-BCAE-9237FC555419@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Date: Tue, 2 Aug 2005 10:49:32 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: 'Stastny Richard' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Aug 2, 2005, at 10:10 AM, Brian Rosen wrote: > I reread this and wondered if I misunderstood the question. Perhaps I asked the question incorrectly. Let me try again. If there is: *.bergen.nj.us.sos.arpa and 123.main.bergen.nj.us.sos.arpa How do you validate (or invalidate): this-is-obviously-bogus.bergen.nj.us.sos.arpa -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 11:08:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzyNX-0007UE-DQ; Tue, 02 Aug 2005 11:08:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzyNW-0007U9-VJ for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 11:08:27 -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 LAA26935 for ; Tue, 2 Aug 2005 11:08:24 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzyty-0004M8-MM for ecrit@ietf.org; Tue, 02 Aug 2005 11:42:02 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j72F7wqI008018 for ; Tue, 2 Aug 2005 10:08:19 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 2 Aug 2005 16:05:04 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0104FA2FC@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'ECRIT'" Subject: RE: [Ecrit] Performance Requirement Date: Tue, 2 Aug 2005 16:05:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Without wishing to get into the discussion of whether we should have a specific value at all, I would note that the specification of a specific value, without qualification of percentage of calls that should meet this value, is utterly meaningless. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 > -----Original Message----- > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org]On Behalf Of > Andrew Newton > Sent: 02 August 2005 13:44 > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] Performance Requirement > > > > On Aug 2, 2005, at 8:18 AM, Brian Rosen wrote: > > > Rohan suggested we remove the D5 requirement and replace it with a > > motivational section, since there was no requirement. I think we > > should have a concrete goal, with a motivation for how we came to > > the goal. I propose: > > > > > > > > The time required to map SHOULD be 500ms, assuming normal caching > > strategies in the mechanism work. The maximum time SHOULD be 1 > > second. > > > > > > > > Motivation: Total time from last digit pressed to ring at the PSAP > > should be two seconds. Allocating one quarter of that to the > > mapping mechanism seems reasonable, and achievable if caching > > mechanisms work well enough for a single element to determine the > > mapping. > I believe that if we continue applying 2119 language, then > specifying > it as a gaol or a requirement has no difference. Also, the > mechanism > specifies caching. Given we don't know what the requirements > are for > caching, we should avoid this language. > > -andy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 11:12:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzyR0-0008Av-U3; Tue, 02 Aug 2005 11:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzyQy-0008AY-QX for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 11:12: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 LAA27134 for ; Tue, 2 Aug 2005 11:11:58 -0400 (EDT) Message-Id: <200508021511.LAA27134@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzyxU-0004VF-2w for ecrit@ietf.org; Tue, 02 Aug 2005 11:45:36 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.51) id 1DzyQn-0000ts-92; Tue, 02 Aug 2005 10:11:49 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Date: Tue, 2 Aug 2005 11:11:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWXcWYZkBq/tpHzQfST6P7y3r/p/wAAsg+g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <0232E18C-3AAE-4115-BCAE-9237FC555419@hxr.us> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: 'Stastny Richard' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org So, I answered this If there is 123.main.bergen...., then you have validation data loaded in the DNS, in which case you do not have a wildcard. You would only have the wildcard if there was not any data below Bergen.nj.us.sos.arpa. Brian -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Tuesday, August 02, 2005 10:50 AM To: Brian Rosen Cc: 'Stastny Richard'; 'ECRIT' Subject: Re: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt On Aug 2, 2005, at 10:10 AM, Brian Rosen wrote: > I reread this and wondered if I misunderstood the question. Perhaps I asked the question incorrectly. Let me try again. If there is: *.bergen.nj.us.sos.arpa and 123.main.bergen.nj.us.sos.arpa How do you validate (or invalidate): this-is-obviously-bogus.bergen.nj.us.sos.arpa -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 11:23:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzybs-0002CK-NB; Tue, 02 Aug 2005 11:23:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzybq-0002C8-Hs for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 11:23:14 -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 LAA28374 for ; Tue, 2 Aug 2005 11:23:11 -0400 (EDT) Message-Id: <200508021523.LAA28374@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzz8M-0005ED-2t for ecrit@ietf.org; Tue, 02 Aug 2005 11:56:50 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.51) id 1Dzybg-0001WT-6G; Tue, 02 Aug 2005 10:23:04 -0500 From: "Brian Rosen" To: "'Drage, Keith \(Keith\)'" , "'ECRIT'" Subject: RE: [Ecrit] Performance Requirement Date: Tue, 2 Aug 2005 11:22:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWXdNvTvgYgIJ4RRrufutw8T5Tr+QAASbLg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <475FF955A05DD411980D00508B6D5FB0104FA2FC@en0033exch001u.uk.lucent.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Fair enough: 90% Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Drage, Keith (Keith) Sent: Tuesday, August 02, 2005 11:05 AM To: 'ECRIT' Subject: RE: [Ecrit] Performance Requirement Without wishing to get into the discussion of whether we should have a specific value at all, I would note that the specification of a specific value, without qualification of percentage of calls that should meet this value, is utterly meaningless. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 > -----Original Message----- > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org]On Behalf Of > Andrew Newton > Sent: 02 August 2005 13:44 > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] Performance Requirement > > > > On Aug 2, 2005, at 8:18 AM, Brian Rosen wrote: > > > Rohan suggested we remove the D5 requirement and replace it with a > > motivational section, since there was no requirement. I think we > > should have a concrete goal, with a motivation for how we came to > > the goal. I propose: > > > > > > > > The time required to map SHOULD be 500ms, assuming normal caching > > strategies in the mechanism work. The maximum time SHOULD be 1 > > second. > > > > > > > > Motivation: Total time from last digit pressed to ring at the PSAP > > should be two seconds. Allocating one quarter of that to the > > mapping mechanism seems reasonable, and achievable if caching > > mechanisms work well enough for a single element to determine the > > mapping. > I believe that if we continue applying 2119 language, then > specifying > it as a gaol or a requirement has no difference. Also, the > mechanism > specifies caching. Given we don't know what the requirements > are for > caching, we should avoid this language. > > -andy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 11:30:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzyjE-0007uH-Sv; Tue, 02 Aug 2005 11:30:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzyjD-0007qn-7C for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 11:30:51 -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 LAA29099 for ; Tue, 2 Aug 2005 11:30:48 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DzzFg-0005e6-E5 for ecrit@ietf.org; Tue, 02 Aug 2005 12:04:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] Suggestion for "performance and reliability" section Date: Tue, 2 Aug 2005 17:32:34 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C080@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Suggestion for "performance and reliability" section Thread-Index: AcWXbmad8YdCM/QtSKK3qBko0hJAxgACQEHq From: "Stastny Richard" To: "Byron Smith" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Not to mention call setup times from mobile phones; from which now > 50% of all emergency calls are made =20 -richard ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von Byron Smith Gesendet: Di 02.08.2005 16:21 An: ecrit@ietf.org Betreff: RE: [Ecrit] Suggestion for "performance and reliability" = section Henning, where do you get the NENA 2s and 10s numbers? The only thing I have found in NENA documents is: " 9 Call Set-up Time It is recommended that emergency call set-up time not exceed the average call set-up time for any other type call made by the customers of that particular serving office. It is also strongly recommended that in all circumstances the = caller hear either audible ring tone or a recording alerting them that their call is being processed." The above is from NENA 03-501. I have looked for other NENA recommendations, but have not found them. I would appreciate a reference if you have one. Not that this is terribly relevant: But I would make a small wager that = more than 50% of the (rural) wireline 911 systems in the country fail to meet = the above recommendations. (Probably closer to 80%) The observed call setup time for systems that use CAMA trunks is usually 3-7 seconds = dial-to-ring, with 5 seconds being typical. Most digital end-office switches make = local dial-to-ring setups on the order of 1 second. Byron > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf = Of > Henning Schulzrinne > Sent: Tuesday, August 02, 2005 4:08 AM > To: ecrit@ietf.org > Subject: [Ecrit] Suggestion for "performance and reliability" section > > > I would think capturing the known external requirements as such is > helpful. For example, the NENA 2s (dial-to-ring) requirement, which is > part of the 10s dial-to-pick-up I mentioned could just be captured as > such external guidelines, possibly in a separate "performance and > reliability" section. If early implementations, with reasonable > assumptions on round-trip times and topology, can't satisfy those, we > know we have a problem. > > Henning > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.338 / Virus Database: 267.9.7/60 - Release Date: = 7/28/2005 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 11:57:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzz8c-0003a6-NC; Tue, 02 Aug 2005 11:57:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzz8b-0003Zy-6C for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 11:57:05 -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 LAA01284 for ; Tue, 2 Aug 2005 11:57:02 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzzf5-00074P-TV for ecrit@ietf.org; Tue, 02 Aug 2005 12:30:41 -0400 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j72Fuvsw023090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Aug 2005 11:56:58 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j72FuuuL018873; Tue, 2 Aug 2005 11:56:57 -0400 Message-ID: <42EF97CF.7080609@cs.columbia.edu> Date: Tue, 02 Aug 2005 11:57:03 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Byron Smith Subject: Re: [Ecrit] Suggestion for "performance and reliability" section References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I don't think I mentioned NENA. My source of the information was the LAPD PSAP (which I visited during the NENA meeting). The person in charge said that their goal was 10s in 95% (not sure about the percentage) from call to human answer. They apparently tracked this information. In their case, the concern was primarily human response time, not routing time. Call setup time in mobile systems often approaches several seconds. Beyond these anecdotal numbers, I'm not sure that we'll be able to rely on existing performance standards and that we can draw much insight from any number we get, except that having a gnome looking up the information in an atlas is likely to be unsatisfactory and that faster is better. I also suspect that the only protocol that would likely fail a reasonable lookup time test, except by pure implementor stupidity, would be one that walked a geo search tree with widely distributed servers for each query. Byron Smith wrote: > Henning, where do you get the NENA 2s and 10s numbers? The only thing I > have found in NENA documents is: > > " 9 Call Set-up Time > It is recommended that emergency call set-up time not exceed the > average call set-up time for any > other type call made by the customers of that particular serving > office. > > It is also strongly recommended that in all circumstances the caller > hear either audible ring tone or a > recording alerting them that their call is being processed." > > The above is from NENA 03-501. I have looked for other NENA > recommendations, but have not found them. > > I would appreciate a reference if you have one. > > Not that this is terribly relevant: But I would make a small wager that more > than 50% of the (rural) wireline 911 systems in the country fail to meet the > above recommendations. (Probably closer to 80%) The observed call setup > time for systems that use CAMA trunks is usually 3-7 seconds dial-to-ring, > with 5 seconds being typical. Most digital end-office switches make local > dial-to-ring setups on the order of 1 second. > > Byron > > > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of >>Henning Schulzrinne >>Sent: Tuesday, August 02, 2005 4:08 AM >>To: ecrit@ietf.org >>Subject: [Ecrit] Suggestion for "performance and reliability" section >> >> >>I would think capturing the known external requirements as such is >>helpful. For example, the NENA 2s (dial-to-ring) requirement, which is >>part of the 10s dial-to-pick-up I mentioned could just be captured as >>such external guidelines, possibly in a separate "performance and >>reliability" section. If early implementations, with reasonable >>assumptions on round-trip times and topology, can't satisfy those, we >>know we have a problem. >> >>Henning >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >>-- >>No virus found in this incoming message. >>Checked by AVG Anti-Virus. >>Version: 7.0.338 / Virus Database: 267.9.7/60 - Release Date: 7/28/2005 >> > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 12:20:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzOn-0007Ce-Le; Tue, 02 Aug 2005 12:13:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzOl-00077j-Bl for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 12:13:47 -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 MAA02526 for ; Tue, 2 Aug 2005 12:13:44 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzzvF-0007ph-VW for ecrit@ietf.org; Tue, 02 Aug 2005 12:47:23 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 02 Aug 2005 09:13:37 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.95,162,1120460400"; d="scan'208"; a="4345841:sNHT23817548" 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 j72GDaVw014131; Tue, 2 Aug 2005 12:13:36 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Aug 2005 12:13:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Suggestion for "performance and reliability" section Date: Tue, 2 Aug 2005 12:13:35 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3669516@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Suggestion for "performance and reliability" section Thread-Index: AcWXew7EBnCho+lWQGmtPbmxCYBt9QAActFQ From: "Michael Hammer \(mhammer\)" To: "Henning Schulzrinne" , "Byron Smith" X-OriginalArrivalTime: 02 Aug 2005 16:13:36.0413 (UTC) FILETIME=[23047CD0:01C5977D] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I don't think it meaningful to put a number on "until human answer" unless you intend to automate humans, or are providing some technical analysis on average call rates and staffing at 911 PSAPs. The latter would be a good NENA exercise, but not sure if that is in scope of ECRIT. Mike =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Henning Schulzrinne > Sent: Tuesday, August 02, 2005 11:57 AM > To: Byron Smith > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Suggestion for "performance and=20 > reliability" section >=20 > I don't think I mentioned NENA. My source of the information=20 > was the LAPD PSAP (which I visited during the NENA meeting).=20 > The person in charge said that their goal was 10s in 95% (not=20 > sure about the > percentage) from call to human answer. They apparently=20 > tracked this information. In their case, the concern was=20 > primarily human response time, not routing time. Call setup=20 > time in mobile systems often approaches several seconds. >=20 > Beyond these anecdotal numbers, I'm not sure that we'll be=20 > able to rely on existing performance standards and that we=20 > can draw much insight from any number we get, except that=20 > having a gnome looking up the information in an atlas is=20 > likely to be unsatisfactory and that faster is better. >=20 > I also suspect that the only protocol that would likely fail=20 > a reasonable lookup time test, except by pure implementor=20 > stupidity, would be one that walked a geo search tree with=20 > widely distributed servers for each query. >=20 >=20 > Byron Smith wrote: > > Henning, where do you get the NENA 2s and 10s numbers? The=20 > only thing=20 > > I have found in NENA documents is: > >=20 > > " 9 Call Set-up Time > > It is recommended that emergency call set-up time not=20 > exceed the=20 > > average call set-up time for any > > other type call made by the customers of that=20 > particular serving=20 > > office. > >=20 > > It is also strongly recommended that in all circumstances the=20 > > caller hear either audible ring tone or a > > recording alerting them that their call is being processed." > >=20 > > The above is from NENA 03-501. I have looked for other NENA > > recommendations, but have not found them. > >=20 > > I would appreciate a reference if you have one. > >=20 > > Not that this is terribly relevant: But I would make a small wager=20 > > that more than 50% of the (rural) wireline 911 systems in=20 > the country=20 > > fail to meet the above recommendations. (Probably closer=20 > to 80%) The=20 > > observed call setup time for systems that use CAMA trunks=20 > is usually=20 > > 3-7 seconds dial-to-ring, with 5 seconds being typical.=20 > Most digital=20 > > end-office switches make local dial-to-ring setups on the=20 > order of 1 second. > >=20 > > Byron > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org]On Behalf=20 > >>Of Henning Schulzrinne > >>Sent: Tuesday, August 02, 2005 4:08 AM > >>To: ecrit@ietf.org > >>Subject: [Ecrit] Suggestion for "performance and=20 > reliability" section > >> > >> > >>I would think capturing the known external requirements as such is=20 > >>helpful. For example, the NENA 2s (dial-to-ring)=20 > requirement, which is=20 > >>part of the 10s dial-to-pick-up I mentioned could just be=20 > captured as=20 > >>such external guidelines, possibly in a separate "performance and=20 > >>reliability" section. If early implementations, with reasonable=20 > >>assumptions on round-trip times and topology, can't satisfy=20 > those, we=20 > >>know we have a problem. > >> > >>Henning > >> > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ecrit > >>-- > >>No virus found in this incoming message. > >>Checked by AVG Anti-Virus. > >>Version: 7.0.338 / Virus Database: 267.9.7/60 - Release Date:=20 > >>7/28/2005 > >> > >=20 > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 12:20:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzSJ-0002jU-AI; Tue, 02 Aug 2005 12:17:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzSH-0002ha-Lg for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 12:17:25 -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 MAA02787 for ; Tue, 2 Aug 2005 12:17:22 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzzym-00080b-Ik for ecrit@ietf.org; Tue, 02 Aug 2005 12:51:01 -0400 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j72GGJsw000016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Aug 2005 12:16:20 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j72GGIBO018995; Tue, 2 Aug 2005 12:16:18 -0400 Message-ID: <42EF9C58.5040006@cs.columbia.edu> Date: Tue, 02 Aug 2005 12:16:24 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Ecrit] Suggestion for "performance and reliability" section References: <072C5B76F7CEAB488172C6F64B30B5E3669516@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3669516@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I was not intending to standardize such a value. It just happened to be the only number I had available, serving as an upper bound on what's reasonable. Michael Hammer (mhammer) wrote: > I don't think it meaningful to put a number on "until human answer" > unless you intend to automate humans, or are providing some technical > analysis on average call rates and staffing at 911 PSAPs. The latter > would be a good NENA exercise, but not sure if that is in scope of > ECRIT. > > Mike > > > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>On Behalf Of Henning Schulzrinne >>Sent: Tuesday, August 02, 2005 11:57 AM >>To: Byron Smith >>Cc: ecrit@ietf.org >>Subject: Re: [Ecrit] Suggestion for "performance and >>reliability" section >> >>I don't think I mentioned NENA. My source of the information >>was the LAPD PSAP (which I visited during the NENA meeting). >>The person in charge said that their goal was 10s in 95% (not >>sure about the >>percentage) from call to human answer. They apparently >>tracked this information. In their case, the concern was >>primarily human response time, not routing time. Call setup >>time in mobile systems often approaches several seconds. >> >>Beyond these anecdotal numbers, I'm not sure that we'll be >>able to rely on existing performance standards and that we >>can draw much insight from any number we get, except that >>having a gnome looking up the information in an atlas is >>likely to be unsatisfactory and that faster is better. >> >>I also suspect that the only protocol that would likely fail >>a reasonable lookup time test, except by pure implementor >>stupidity, would be one that walked a geo search tree with >>widely distributed servers for each query. >> >> >>Byron Smith wrote: >> >>>Henning, where do you get the NENA 2s and 10s numbers? The >> >>only thing >> >>>I have found in NENA documents is: >>> >>>" 9 Call Set-up Time >>> It is recommended that emergency call set-up time not >> >>exceed the >> >>>average call set-up time for any >>> other type call made by the customers of that >> >>particular serving >> >>>office. >>> >>> It is also strongly recommended that in all circumstances the >>>caller hear either audible ring tone or a >>> recording alerting them that their call is being processed." >>> >>>The above is from NENA 03-501. I have looked for other NENA >>>recommendations, but have not found them. >>> >>>I would appreciate a reference if you have one. >>> >>>Not that this is terribly relevant: But I would make a small wager >>>that more than 50% of the (rural) wireline 911 systems in >> >>the country >> >>>fail to meet the above recommendations. (Probably closer >> >>to 80%) The >> >>>observed call setup time for systems that use CAMA trunks >> >>is usually >> >>>3-7 seconds dial-to-ring, with 5 seconds being typical. >> >>Most digital >> >>>end-office switches make local dial-to-ring setups on the >> >>order of 1 second. >> >>>Byron >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: ecrit-bounces@ietf.org >> >>[mailto:ecrit-bounces@ietf.org]On Behalf >> >>>>Of Henning Schulzrinne >>>>Sent: Tuesday, August 02, 2005 4:08 AM >>>>To: ecrit@ietf.org >>>>Subject: [Ecrit] Suggestion for "performance and >> >>reliability" section >> >>>> >>>>I would think capturing the known external requirements as such is >>>>helpful. For example, the NENA 2s (dial-to-ring) >> >>requirement, which is >> >>>>part of the 10s dial-to-pick-up I mentioned could just be >> >>captured as >> >>>>such external guidelines, possibly in a separate "performance and >>>>reliability" section. If early implementations, with reasonable >>>>assumptions on round-trip times and topology, can't satisfy >> >>those, we >> >>>>know we have a problem. >>>> >>>>Henning >>>> >>>>_______________________________________________ >>>>Ecrit mailing list >>>>Ecrit@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>>-- >>>>No virus found in this incoming message. >>>>Checked by AVG Anti-Virus. >>>>Version: 7.0.338 / Virus Database: 267.9.7/60 - Release Date: >>>>7/28/2005 >>>> >>> >>> >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 12:20:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzM7-0001GL-Uz; Tue, 02 Aug 2005 12:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzM4-0001DX-IB for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 12:11:02 -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 MAA02275 for ; Tue, 2 Aug 2005 12:10:57 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzzsY-0007gX-ED for ecrit@ietf.org; Tue, 02 Aug 2005 12:44:36 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 02 Aug 2005 09:10:50 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.95,162,1120460400"; d="scan'208"; a="4345266:sNHT22819060" 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 j72GAnk6012293; Tue, 2 Aug 2005 12:10:49 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Aug 2005 12:10:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Performance Requirement Date: Tue, 2 Aug 2005 12:10:46 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3669512@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Performance Requirement Thread-Index: AcWXdNvTvgYgIJ4RRrufutw8T5Tr+QAASbLgAAGAyqA= From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Drage, Keith \(Keith\)" , "ECRIT" X-OriginalArrivalTime: 02 Aug 2005 16:10:49.0397 (UTC) FILETIME=[BF77DE50:01C5977C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Would you want to characterize the tail using values for: 1-sigma (68%), 2s 2-sigma (95%), 4s 3-sigma (99%), 8s And only leave some small fraction of infinitely long call setups? Mike=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Brian Rosen > Sent: Tuesday, August 02, 2005 11:23 AM > To: 'Drage, Keith (Keith)'; 'ECRIT' > Subject: RE: [Ecrit] Performance Requirement >=20 > Fair enough: 90% >=20 > Brian >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Drage, Keith (Keith) > Sent: Tuesday, August 02, 2005 11:05 AM > To: 'ECRIT' > Subject: RE: [Ecrit] Performance Requirement >=20 > Without wishing to get into the discussion of whether we=20 > should have a specific value at all, I would note that the=20 > specification of a specific value, without qualification of=20 > percentage of calls that should meet this value, is utterly=20 > meaningless. >=20 > regards >=20 > Keith >=20 > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 >=20 >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org]On Behalf Of Andrew Newton > > Sent: 02 August 2005 13:44 > > To: Brian Rosen > > Cc: 'ECRIT' > > Subject: Re: [Ecrit] Performance Requirement > >=20 > >=20 > >=20 > > On Aug 2, 2005, at 8:18 AM, Brian Rosen wrote: > >=20 > > > Rohan suggested we remove the D5 requirement and replace=20 > it with a =20 > > > motivational section, since there was no requirement. I=20 > think we =20 > > > should have a concrete goal, with a motivation for how we=20 > came to =20 > > > the goal. I propose: > > > > > > > > > > > > The time required to map SHOULD be 500ms, assuming normal=20 > caching =20 > > > strategies in the mechanism work. The maximum time SHOULD be 1 =20 > > > second. > > > > > > > > > > > > Motivation: Total time from last digit pressed to ring at=20 > the PSAP =20 > > > should be two seconds. Allocating one quarter of that to the =20 > > > mapping mechanism seems reasonable, and achievable if caching =20 > > > mechanisms work well enough for a single element to=20 > determine the =20 > > > mapping. > > I believe that if we continue applying 2119 language, then=20 > > specifying =20 > > it as a gaol or a requirement has no difference. Also, the=20 > > mechanism =20 > > specifies caching. Given we don't know what the requirements=20 > > are for =20 > > caching, we should avoid this language. > >=20 > > -andy > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 13:02:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E009d-00029T-PE; Tue, 02 Aug 2005 13:02:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E009c-000280-1v for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 13:02:12 -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 NAA05603 for ; Tue, 2 Aug 2005 13:02:06 -0400 (EDT) Received: from ip-66.249.239.5.indigital.net ([66.249.239.5] helo=apa7.indigital.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00g4-0001eA-Iu for ecrit@ietf.org; Tue, 02 Aug 2005 13:35:46 -0400 Received: from [66.170.32.23] (helo=byron) by apa7.indigital.net with smtp (Exim 4.43) id 1E009L-0002KT-0C; Tue, 02 Aug 2005 12:01:55 -0500 From: "Byron Smith" To: "Henning Schulzrinne" , "Michael Hammer \(mhammer\)" Subject: RE: [Ecrit] Suggestion for "performance and reliability" section Date: Tue, 2 Aug 2005 12:04:22 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <42EF9C58.5040006@cs.columbia.edu> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Assigning "hard" performance numbers can become arbitrary. I generally agree with Mike's suggestion on another thread of using percentages/sigma's. The FCC basically did this with wireless phase II position location accuracy. (And I would suggest non-GPS wireless Phase II systems, e.g. network-based positioning systems, frequently fall short of the FCC requirements. An antidotal observation.) To my knowledge, NENA has not put numbers on dial-to-ring or ring-to-answer. If they have, I would love to see a citation. Their idea is simply to keep the system in line with what the user typically experiences in their day-to-day use of the telephone system. That would be good. But a large part of the existing 911 infrastructure in the US falls short of even that pragmatic approach. If today's wireline call setup times are bad, wireless call setup times border on the atrocious. In my experience a 5 second wireless call setup (send-to-ring) would be excellent. I have personally done quite a bit of wireless 911 testing (from inside PSAPs) and observed many wireless call setups of 15 seconds, and more. I doubt the average is much better than 10s. My point is we shouldn't get too hung up on this detail. A system that generally provides a level of performance that is close to what the user generally experiences using, say, an Internet telephone service, or IM, or web browsing, will be adequate. Due to the complexity of routing 911 messages we can expect some additional setup delay, but of course we should strive to keep this to a minimum. I'm confident what finally emerges from this process will prove to be considerably superior to much of the 911 infrastructure that exists today. Carry on. Byron > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, August 02, 2005 11:16 AM > To: Michael Hammer (mhammer) > Cc: Byron Smith; ecrit@ietf.org > Subject: Re: [Ecrit] Suggestion for "performance and reliability" > section > > > I was not intending to standardize such a value. It just happened to be > the only number I had available, serving as an upper bound on what's > reasonable. > > Michael Hammer (mhammer) wrote: > > I don't think it meaningful to put a number on "until human answer" > > unless you intend to automate humans, or are providing some technical > > analysis on average call rates and staffing at 911 PSAPs. The latter > > would be a good NENA exercise, but not sure if that is in scope of > > ECRIT. > > > > Mike > > > > > > > >>-----Original Message----- > >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >>On Behalf Of Henning Schulzrinne > >>Sent: Tuesday, August 02, 2005 11:57 AM > >>To: Byron Smith > >>Cc: ecrit@ietf.org > >>Subject: Re: [Ecrit] Suggestion for "performance and > >>reliability" section > >> > >>I don't think I mentioned NENA. My source of the information > >>was the LAPD PSAP (which I visited during the NENA meeting). > >>The person in charge said that their goal was 10s in 95% (not > >>sure about the > >>percentage) from call to human answer. They apparently > >>tracked this information. In their case, the concern was > >>primarily human response time, not routing time. Call setup > >>time in mobile systems often approaches several seconds. > >> > >>Beyond these anecdotal numbers, I'm not sure that we'll be > >>able to rely on existing performance standards and that we > >>can draw much insight from any number we get, except that > >>having a gnome looking up the information in an atlas is > >>likely to be unsatisfactory and that faster is better. > >> > >>I also suspect that the only protocol that would likely fail > >>a reasonable lookup time test, except by pure implementor > >>stupidity, would be one that walked a geo search tree with > >>widely distributed servers for each query. > >> > >> > >>Byron Smith wrote: > >> > >>>Henning, where do you get the NENA 2s and 10s numbers? The > >> > >>only thing > >> > >>>I have found in NENA documents is: > >>> > >>>" 9 Call Set-up Time > >>> It is recommended that emergency call set-up time not > >> > >>exceed the > >> > >>>average call set-up time for any > >>> other type call made by the customers of that > >> > >>particular serving > >> > >>>office. > >>> > >>> It is also strongly recommended that in all circumstances the > >>>caller hear either audible ring tone or a > >>> recording alerting them that their call is being processed." > >>> > >>>The above is from NENA 03-501. I have looked for other NENA > >>>recommendations, but have not found them. > >>> > >>>I would appreciate a reference if you have one. > >>> > >>>Not that this is terribly relevant: But I would make a small wager > >>>that more than 50% of the (rural) wireline 911 systems in > >> > >>the country > >> > >>>fail to meet the above recommendations. (Probably closer > >> > >>to 80%) The > >> > >>>observed call setup time for systems that use CAMA trunks > >> > >>is usually > >> > >>>3-7 seconds dial-to-ring, with 5 seconds being typical. > >> > >>Most digital > >> > >>>end-office switches make local dial-to-ring setups on the > >> > >>order of 1 second. > >> > >>>Byron > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: ecrit-bounces@ietf.org > >> > >>[mailto:ecrit-bounces@ietf.org]On Behalf > >> > >>>>Of Henning Schulzrinne > >>>>Sent: Tuesday, August 02, 2005 4:08 AM > >>>>To: ecrit@ietf.org > >>>>Subject: [Ecrit] Suggestion for "performance and > >> > >>reliability" section > >> > >>>> > >>>>I would think capturing the known external requirements as such is > >>>>helpful. For example, the NENA 2s (dial-to-ring) > >> > >>requirement, which is > >> > >>>>part of the 10s dial-to-pick-up I mentioned could just be > >> > >>captured as > >> > >>>>such external guidelines, possibly in a separate "performance and > >>>>reliability" section. If early implementations, with reasonable > >>>>assumptions on round-trip times and topology, can't satisfy > >> > >>those, we > >> > >>>>know we have a problem. > >>>> > >>>>Henning > >>>> > >>>>_______________________________________________ > >>>>Ecrit mailing list > >>>>Ecrit@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/ecrit > >>>>-- > >>>>No virus found in this incoming message. > >>>>Checked by AVG Anti-Virus. > >>>>Version: 7.0.338 / Virus Database: 267.9.7/60 - Release Date: > >>>>7/28/2005 > >>>> > >>> > >>> > >>> > >>>_______________________________________________ > >>>Ecrit mailing list > >>>Ecrit@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/ecrit > >> > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ecrit > >> > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.338 / Virus Database: 267.9.8/61 - Release Date: 8/1/2005 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 13:12:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00JL-0005ab-Qn; Tue, 02 Aug 2005 13:12:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00JJ-0005aQ-W0 for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 13:12:14 -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 NAA06313 for ; Tue, 2 Aug 2005 13:12:10 -0400 (EDT) Message-Id: <200508021712.NAA06313@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00pp-0002AG-O1 for ecrit@ietf.org; Tue, 02 Aug 2005 13:45:50 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.51) id 1E00J3-0006f3-CW; Tue, 02 Aug 2005 12:11:58 -0500 From: "Brian Rosen" To: "'Byron Smith'" , "'Henning Schulzrinne'" , "'Michael Hammer \(mhammer\)'" Subject: RE: [Ecrit] Suggestion for "performance and reliability" section Date: Tue, 2 Aug 2005 13:11:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWXhAN+yE0HXAnVSOap5quAw2NO5gAAMztQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm happy with a tail curve as Mike suggests. While I agree the numbers are somewhat arbitrary, experience in ecrit shows that a real number is VERY helpful. So, I think we should have a real number. We can qualify it any way we want, but getting in the number 2 seconds dial to ring is useful. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Byron Smith Sent: Tuesday, August 02, 2005 1:04 PM To: Henning Schulzrinne; Michael Hammer (mhammer) Cc: ecrit@ietf.org Subject: RE: [Ecrit] Suggestion for "performance and reliability" section Assigning "hard" performance numbers can become arbitrary. I generally agree with Mike's suggestion on another thread of using percentages/sigma's. The FCC basically did this with wireless phase II position location accuracy. (And I would suggest non-GPS wireless Phase II systems, e.g. network-based positioning systems, frequently fall short of the FCC requirements. An antidotal observation.) To my knowledge, NENA has not put numbers on dial-to-ring or ring-to-answer. If they have, I would love to see a citation. Their idea is simply to keep the system in line with what the user typically experiences in their day-to-day use of the telephone system. That would be good. But a large part of the existing 911 infrastructure in the US falls short of even that pragmatic approach. If today's wireline call setup times are bad, wireless call setup times border on the atrocious. In my experience a 5 second wireless call setup (send-to-ring) would be excellent. I have personally done quite a bit of wireless 911 testing (from inside PSAPs) and observed many wireless call setups of 15 seconds, and more. I doubt the average is much better than 10s. My point is we shouldn't get too hung up on this detail. A system that generally provides a level of performance that is close to what the user generally experiences using, say, an Internet telephone service, or IM, or web browsing, will be adequate. Due to the complexity of routing 911 messages we can expect some additional setup delay, but of course we should strive to keep this to a minimum. I'm confident what finally emerges from this process will prove to be considerably superior to much of the 911 infrastructure that exists today. Carry on. Byron > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, August 02, 2005 11:16 AM > To: Michael Hammer (mhammer) > Cc: Byron Smith; ecrit@ietf.org > Subject: Re: [Ecrit] Suggestion for "performance and reliability" > section > > > I was not intending to standardize such a value. It just happened to be > the only number I had available, serving as an upper bound on what's > reasonable. > > Michael Hammer (mhammer) wrote: > > I don't think it meaningful to put a number on "until human answer" > > unless you intend to automate humans, or are providing some technical > > analysis on average call rates and staffing at 911 PSAPs. The latter > > would be a good NENA exercise, but not sure if that is in scope of > > ECRIT. > > > > Mike > > > > > > > >>-----Original Message----- > >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >>On Behalf Of Henning Schulzrinne > >>Sent: Tuesday, August 02, 2005 11:57 AM > >>To: Byron Smith > >>Cc: ecrit@ietf.org > >>Subject: Re: [Ecrit] Suggestion for "performance and > >>reliability" section > >> > >>I don't think I mentioned NENA. My source of the information > >>was the LAPD PSAP (which I visited during the NENA meeting). > >>The person in charge said that their goal was 10s in 95% (not > >>sure about the > >>percentage) from call to human answer. They apparently > >>tracked this information. In their case, the concern was > >>primarily human response time, not routing time. Call setup > >>time in mobile systems often approaches several seconds. > >> > >>Beyond these anecdotal numbers, I'm not sure that we'll be > >>able to rely on existing performance standards and that we > >>can draw much insight from any number we get, except that > >>having a gnome looking up the information in an atlas is > >>likely to be unsatisfactory and that faster is better. > >> > >>I also suspect that the only protocol that would likely fail > >>a reasonable lookup time test, except by pure implementor > >>stupidity, would be one that walked a geo search tree with > >>widely distributed servers for each query. > >> > >> > >>Byron Smith wrote: > >> > >>>Henning, where do you get the NENA 2s and 10s numbers? The > >> > >>only thing > >> > >>>I have found in NENA documents is: > >>> > >>>" 9 Call Set-up Time > >>> It is recommended that emergency call set-up time not > >> > >>exceed the > >> > >>>average call set-up time for any > >>> other type call made by the customers of that > >> > >>particular serving > >> > >>>office. > >>> > >>> It is also strongly recommended that in all circumstances the > >>>caller hear either audible ring tone or a > >>> recording alerting them that their call is being processed." > >>> > >>>The above is from NENA 03-501. I have looked for other NENA > >>>recommendations, but have not found them. > >>> > >>>I would appreciate a reference if you have one. > >>> > >>>Not that this is terribly relevant: But I would make a small wager > >>>that more than 50% of the (rural) wireline 911 systems in > >> > >>the country > >> > >>>fail to meet the above recommendations. (Probably closer > >> > >>to 80%) The > >> > >>>observed call setup time for systems that use CAMA trunks > >> > >>is usually > >> > >>>3-7 seconds dial-to-ring, with 5 seconds being typical. > >> > >>Most digital > >> > >>>end-office switches make local dial-to-ring setups on the > >> > >>order of 1 second. > >> > >>>Byron > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: ecrit-bounces@ietf.org > >> > >>[mailto:ecrit-bounces@ietf.org]On Behalf > >> > >>>>Of Henning Schulzrinne > >>>>Sent: Tuesday, August 02, 2005 4:08 AM > >>>>To: ecrit@ietf.org > >>>>Subject: [Ecrit] Suggestion for "performance and > >> > >>reliability" section > >> > >>>> > >>>>I would think capturing the known external requirements as such is > >>>>helpful. For example, the NENA 2s (dial-to-ring) > >> > >>requirement, which is > >> > >>>>part of the 10s dial-to-pick-up I mentioned could just be > >> > >>captured as > >> > >>>>such external guidelines, possibly in a separate "performance and > >>>>reliability" section. If early implementations, with reasonable > >>>>assumptions on round-trip times and topology, can't satisfy > >> > >>those, we > >> > >>>>know we have a problem. > >>>> > >>>>Henning > >>>> > >>>>_______________________________________________ > >>>>Ecrit mailing list > >>>>Ecrit@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/ecrit > >>>>-- > >>>>No virus found in this incoming message. > >>>>Checked by AVG Anti-Virus. > >>>>Version: 7.0.338 / Virus Database: 267.9.7/60 - Release Date: > >>>>7/28/2005 > >>>> > >>> > >>> > >>> > >>>_______________________________________________ > >>>Ecrit mailing list > >>>Ecrit@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/ecrit > >> > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ecrit > >> > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.338 / Virus Database: 267.9.8/61 - Release Date: 8/1/2005 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 13:28:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00ZA-0006s1-5O; Tue, 02 Aug 2005 13:28:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00Z8-0006qx-Qg for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 13:28:34 -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 NAA07060 for ; Tue, 2 Aug 2005 13:28:31 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E015e-0002nN-5w for ecrit@ietf.org; Tue, 02 Aug 2005 14:02:11 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j72HExeq024693 for ; Tue, 2 Aug 2005 12:28:30 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 2 Aug 2005 16:44:48 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0104FA310@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: ecrit@ietf.org Date: Tue, 2 Aug 2005 16:44:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ecrit] Recognition of emergency calls X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I was looking at A3, and was wondering whether we really had two requirements here rather than one: A3. Recognizable: Emergency calls MUST be recognizable by user agents, proxies and other network elements. To prevent fraud, an address identified as an emergency number for call features or authentication override MUST also cause routing to a PSAP. The first requirement is to recognise that an emergency call not already identified as an emergency call is really an emergency call. For example in 3GPP cellular networks, the user has first go at identifying the call as an emergency call by a special button on the phone, but there is a fallback that if the user keys a number, the phone recognises the dialled digits as an emergency call, with a further fallback that the network can also analyse the dialled digits and identify the call as an emergency call. In these cases the call is then tagged with the information that this is an emergency call. The second requirement is to treat a call identified as an emergency call as an emergency call, and for example apply ecrit routeing and so on. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 02 13:38:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00j7-0006HR-5r; Tue, 02 Aug 2005 13:38:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00j5-0006FV-Pv for ecrit@megatron.ietf.org; Tue, 02 Aug 2005 13:38:51 -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 NAA07578 for ; Tue, 2 Aug 2005 13:38:48 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E01Fb-0003Eo-5I for ecrit@ietf.org; Tue, 02 Aug 2005 14:12:28 -0400 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j72Hclsw027405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Aug 2005 13:38:47 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j72HckB3021379; Tue, 2 Aug 2005 13:38:46 -0400 Message-ID: <42EFAFAA.4050806@cs.columbia.edu> Date: Tue, 02 Aug 2005 13:38:50 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Ecrit] Recognition of emergency calls References: <475FF955A05DD411980D00508B6D5FB0104FA310@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB0104FA310@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I suspect we should re-factor A1 and A3 together. Drage, Keith (Keith) wrote: > I was looking at A3, and was wondering whether we really had two requirements here rather than one: > > A3. Recognizable: Emergency calls MUST be recognizable by user > agents, proxies and other network elements. To prevent fraud, an > address identified as an emergency number for call features or > authentication override MUST also cause routing to a PSAP. > > The first requirement is to recognise that an emergency call not already identified as an emergency call is really an emergency call. For example in 3GPP cellular networks, the user has first go at identifying the call as an emergency call by a special button on the phone, but there is a fallback that if the user keys a number, the phone recognises the dialled digits as an emergency call, with a further fallback that the network can also analyse the dialled digits and identify the call as an emergency call. In these cases the call is then tagged with the information that this is an emergency call. > > The second requirement is to treat a call identified as an emergency call as an emergency call, and for example apply ecrit routeing and so on. > > regards > > Keith > > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 03 00:04:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0AUu-0000Va-JZ; Wed, 03 Aug 2005 00:04:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0AUs-0000Uz-V9 for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 00:04:50 -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 AAA05643 for ; Wed, 3 Aug 2005 00:04:47 -0400 (EDT) Received: from [203.117.75.21] (helo=dev.red-aura.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0B1T-0000sR-Iy for ecrit@ietf.org; Wed, 03 Aug 2005 00:38:33 -0400 Received: (qmail 54061 invoked from network); 3 Aug 2005 04:06:48 -0000 Received: from atuileries-153-1-30-38.w82-123.abo.wanadoo.fr (HELO ?192.168.0.53?) (jseng@82.123.237.38) by dev.red-aura.com with RC4-SHA encrypted SMTP; 3 Aug 2005 04:06:48 -0000 Mime-Version: 1.0 (Apple Message framework v733) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ecrit@ietf.org From: James Seng Date: Wed, 3 Aug 2005 12:04:18 +0800 X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Subject: [Ecrit] some observations from yesterday wg meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I am not a regular on this list so whatever I said here is based on what I see at yesterday wg meeting. Pardon me if these already been discussed. 1. There are a lot of talks about how caller can authenticate the emergency response centers (singapore term for what WG's called PSAP) but not much talks about how PSAP is going to authenticate the callers. Considering how many prank calls typical PSAP gets, I wont be surprised if their priority is to identify the caller first and less about your house on fire. No I am serious. That's my experience when dealing with them on E911 when we are working on our IP Telephony framework. 2. Any bet how long it will take PSAP to install a SIP server into their system? Especially a system which will allow anyone from anywhere in the world to call them anonymously? So while it is important for the caller to be able to identify his nearest PSAP, it is equally important for PSAP to be able to (a) identify the caller and (b) establish that the caller is within the zone they are serving. -James Seng _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 03 03:23:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DbN-0002RP-SG; Wed, 03 Aug 2005 03:23:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DbJ-0002RC-G1 for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 03:23:41 -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 DAA20628 for ; Wed, 3 Aug 2005 03:23:40 -0400 (EDT) Message-Id: <200508030723.DAA20628@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0E7u-0008UI-A5 for ecrit@ietf.org; Wed, 03 Aug 2005 03:57:25 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.51) id 1E0Db1-0001wd-Aa; Wed, 03 Aug 2005 02:23:24 -0500 From: "Brian Rosen" To: "'James Seng'" , Subject: RE: [Ecrit] some observations from yesterday wg meeting Date: Wed, 3 Aug 2005 03:23:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWX4Kb9YBREAbJpQeKz56UtR8GhSwAGopXA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org In North America, the PSAPs tell us that their priorities are to: 1. Get the call to the right PSAP 2. Get a call back number 3. Get the location of the caller To the extent that the current PSTN equates "identity" of the caller with the telephone number, they are getting identity as their second point. This discussion is more or less out of charter, as the work in ecrit addresses the first point above. For ecrit, we did have a discussion on the importance of assuring that the location provided is the actual location of the caller. This is actually the biggest part of addressing prank calls. As I said in the meeting, the PSAPs I know would accept a call with no location, no call back and no identity. They might be VERY suspicious of such a call, but they will take it, and depending on what the caller said, they probably will dispatch someone. At least for the PSAPs I know, while they will demand a lot of effort to make sure location and call back are accurate, they will, in fact, accept a call without it. In that regard, I think they care about the house on fire first, and the identity second. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James Seng Sent: Wednesday, August 03, 2005 12:04 AM To: ecrit@ietf.org Subject: [Ecrit] some observations from yesterday wg meeting I am not a regular on this list so whatever I said here is based on what I see at yesterday wg meeting. Pardon me if these already been discussed. 1. There are a lot of talks about how caller can authenticate the emergency response centers (singapore term for what WG's called PSAP) but not much talks about how PSAP is going to authenticate the callers. Considering how many prank calls typical PSAP gets, I wont be surprised if their priority is to identify the caller first and less about your house on fire. No I am serious. That's my experience when dealing with them on E911 when we are working on our IP Telephony framework. 2. Any bet how long it will take PSAP to install a SIP server into their system? Especially a system which will allow anyone from anywhere in the world to call them anonymously? So while it is important for the caller to be able to identify his nearest PSAP, it is equally important for PSAP to be able to (a) identify the caller and (b) establish that the caller is within the zone they are serving. -James Seng _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 03 03:36:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Dnb-0008PB-Fh; Wed, 03 Aug 2005 03:36:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DnZ-0008OA-7A for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 03:36:21 -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 DAA21348 for ; Wed, 3 Aug 2005 03:36:19 -0400 (EDT) Received: from [203.117.75.21] (helo=dev.red-aura.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0EKA-0000n1-LM for ecrit@ietf.org; Wed, 03 Aug 2005 04:10:05 -0400 Received: (qmail 76144 invoked from network); 3 Aug 2005 07:38:26 -0000 Received: from atuileries-153-1-30-38.w82-123.abo.wanadoo.fr (HELO ?192.168.0.53?) (jseng@82.123.237.38) by dev.red-aura.com with RC4-SHA encrypted SMTP; 3 Aug 2005 07:38:25 -0000 Mime-Version: 1.0 (Apple Message framework v733) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <560AD194-EFB6-48F8-A047-75A58D9D797B@seng.cc> Content-Transfer-Encoding: 7bit From: James Seng Subject: Re: [Ecrit] some observations from yesterday wg meeting Date: Wed, 3 Aug 2005 15:35:59 +0800 To: "Brian Rosen" X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org That may be the American experience but certainly not mine. -James Seng On 03 Aug 2005, at 3:23 PM, Brian Rosen wrote: > In North America, the PSAPs tell us that their priorities are to: > 1. Get the call to the right PSAP > 2. Get a call back number > 3. Get the location of the caller > > To the extent that the current PSTN equates "identity" of the > caller with > the telephone number, they are getting identity as their second point. > > This discussion is more or less out of charter, as the work in ecrit > addresses the first point above. > > For ecrit, we did have a discussion on the importance of assuring > that the > location provided is the actual location of the caller. This is > actually > the biggest part of addressing prank calls. > > As I said in the meeting, the PSAPs I know would accept a call with no > location, no call back and no identity. They might be VERY > suspicious of > such a call, but they will take it, and depending on what the > caller said, > they probably will dispatch someone. At least for the PSAPs I > know, while > they will demand a lot of effort to make sure location and call > back are > accurate, they will, in fact, accept a call without it. In that > regard, I > think they care about the house on fire first, and the identity > second. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of > James Seng > Sent: Wednesday, August 03, 2005 12:04 AM > To: ecrit@ietf.org > Subject: [Ecrit] some observations from yesterday wg meeting > > I am not a regular on this list so whatever I said here is based on > what I see at yesterday wg meeting. Pardon me if these already been > discussed. > 1. There are a lot of talks about how caller can authenticate the > emergency response centers (singapore term for what WG's called PSAP) > but not much talks about how PSAP is going to authenticate the > callers. > > Considering how many prank calls typical PSAP gets, I wont be > surprised if their priority is to identify the caller first and less > about your house on fire. > > No I am serious. That's my experience when dealing with them on E911 > when we are working on our IP Telephony framework. > > 2. Any bet how long it will take PSAP to install a SIP server into > their system? Especially a system which will allow anyone from > anywhere in the world to call them anonymously? > > So while it is important for the caller to be able to identify his > nearest PSAP, it is equally important for PSAP to be able to (a) > identify the caller and (b) establish that the caller is within the > zone they are serving. > > -James Seng > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 03 04:07:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0EI7-00083J-8p; Wed, 03 Aug 2005 04:07:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0EI5-00080x-3B for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 04:07:53 -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 EAA23331 for ; Wed, 3 Aug 2005 04:07:51 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E0Eoj-0002FY-8c for ecrit@ietf.org; Wed, 03 Aug 2005 04:41:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Date: Wed, 3 Aug 2005 10:11:14 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C082@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Thread-Index: AcWXcWYZkBq/tpHzQfST6P7y3r/p/wAAsg+gACMjdbs= From: "Stastny Richard" To: "Brian Rosen" , "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Brian,=20 =20 we may run here in a similar problem with DNS wildcards (considered harmful by some ;-) like in ENUM e.g with pilotnumbers. =20 On one side we have: =20 L6. Validation of civic location: It MUST be possible to validate an address prior to its use in an actual emergency call. =20 emphasis on prior =20 on the other hand the mapping protocol MUST return a valid PSAP URI even with an invalid or partially valid location during the emergency call (there is no time during the emergency call to start hazzling the subscriber with a wrongly entered housenumber or misspelled streetname =20 So there is a requirement for the mapping database: If you query the database with a wrong (not existing) civil location, the return MUST contain there most appropriate PSAP URI (e.g. the state default PSAP) AND an indication that the location infromation provided is not existing. =20 In the examples given if you enter this-is-obviously-bogus.bergen.nj.us.sos.arpa =20 and there is a=20 =20 123.main.bergen.nj.us.sos.arpa you get back NXDOMAIN but not a proper NAPTR at all =20 You have then to walk up the tree e.g. using the indication of the enclosing zone to find the default NAPTR for the street or county, etc This default NAPTR is NOT a=20 wildcard -richard =20 =20 ________________________________ Von: Brian Rosen [mailto:br@brianrosen.net] Gesendet: Di 02.08.2005 17:11 An: 'Andrew Newton' Cc: Stastny Richard; 'ECRIT' Betreff: RE: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt=20 So, I answered this If there is 123.main.bergen...., then you have validation data loaded in = the DNS, in which case you do not have a wildcard. You would only have the wildcard if there was not any data below Bergen.nj.us.sos.arpa. Brian -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Tuesday, August 02, 2005 10:50 AM To: Brian Rosen Cc: 'Stastny Richard'; 'ECRIT' Subject: Re: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt On Aug 2, 2005, at 10:10 AM, Brian Rosen wrote: > I reread this and wondered if I misunderstood the question. Perhaps I asked the question incorrectly. Let me try again. If there is: *.bergen.nj.us.sos.arpa and 123.main.bergen.nj.us.sos.arpa How do you validate (or invalidate): this-is-obviously-bogus.bergen.nj.us.sos.arpa -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 03 04:33:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Eh5-0005tq-5t; Wed, 03 Aug 2005 04:33:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Eh3-0005ti-Ee for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 04:33:41 -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 EAA24944 for ; Wed, 3 Aug 2005 04:33:39 -0400 (EDT) Message-Id: <200508030833.EAA24944@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0FDh-0003Xl-Uw for ecrit@ietf.org; Wed, 03 Aug 2005 05:07:26 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.51) id 1E0Egt-0007YM-IY; Wed, 03 Aug 2005 03:33:32 -0500 From: "Brian Rosen" To: "'Stastny Richard'" , "'Andrew Newton'" Subject: RE: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Date: Wed, 3 Aug 2005 04:33:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C082@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWXcWYZkBq/tpHzQfST6P7y3r/p/wAAsg+gACMjdbsAAMt4YA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org In North America, "walking up the tree" may not get you the right PSAP. There is a notion of a "default route", but it's typically more complex then walking up the tree. First of all are you suggesting a new requirement? If so, please state it. Then, are you suggesting that the mechanism has to return the "longest prefix match" equivalent? Is it acceptable that the client do more work if the presented location does not produce a route? We could put a PSAP NAPTR at, say bergen.nj.us.sos.arpa, which a client could query for. That's not a wildcard. If we put a wildcard for *.bergen.nj.us.sos.arpa, it would match this-is-obviously-bogus.bergen.nj.us.sos.arpa. It's not clear to me this is desirable. Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Wednesday, August 03, 2005 4:11 AM To: Brian Rosen; Andrew Newton Cc: ECRIT Subject: Re: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Hi Brian, we may run here in a similar problem with DNS wildcards (considered harmful by some ;-) like in ENUM e.g with pilotnumbers. On one side we have: L6. Validation of civic location: It MUST be possible to validate an address prior to its use in an actual emergency call. emphasis on prior on the other hand the mapping protocol MUST return a valid PSAP URI even with an invalid or partially valid location during the emergency call (there is no time during the emergency call to start hazzling the subscriber with a wrongly entered housenumber or misspelled streetname So there is a requirement for the mapping database: If you query the database with a wrong (not existing) civil location, the return MUST contain there most appropriate PSAP URI (e.g. the state default PSAP) AND an indication that the location infromation provided is not existing. In the examples given if you enter this-is-obviously-bogus.bergen.nj.us.sos.arpa and there is a 123.main.bergen.nj.us.sos.arpa you get back NXDOMAIN but not a proper NAPTR at all You have then to walk up the tree e.g. using the indication of the enclosing zone to find the default NAPTR for the street or county, etc This default NAPTR is NOT a wildcard -richard ________________________________ Von: Brian Rosen [mailto:br@brianrosen.net] Gesendet: Di 02.08.2005 17:11 An: 'Andrew Newton' Cc: Stastny Richard; 'ECRIT' Betreff: RE: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt So, I answered this If there is 123.main.bergen...., then you have validation data loaded in the DNS, in which case you do not have a wildcard. You would only have the wildcard if there was not any data below Bergen.nj.us.sos.arpa. Brian -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Tuesday, August 02, 2005 10:50 AM To: Brian Rosen Cc: 'Stastny Richard'; 'ECRIT' Subject: Re: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt On Aug 2, 2005, at 10:10 AM, Brian Rosen wrote: > I reread this and wondered if I misunderstood the question. Perhaps I asked the question incorrectly. Let me try again. If there is: *.bergen.nj.us.sos.arpa and 123.main.bergen.nj.us.sos.arpa How do you validate (or invalidate): this-is-obviously-bogus.bergen.nj.us.sos.arpa -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 03 04:50:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Ex2-0003qF-4G; Wed, 03 Aug 2005 04:50:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Ex0-0003q9-Km for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 04:50:10 -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 EAA25641 for ; Wed, 3 Aug 2005 04:50:08 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E0FTF-0004CK-0O for ecrit@ietf.org; Wed, 03 Aug 2005 05:23:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Date: Wed, 3 Aug 2005 10:53:04 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C083@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Thread-Index: AcWXcWYZkBq/tpHzQfST6P7y3r/p/wAAsg+gACMjdbsAAMt4YAAA5dee From: "Stastny Richard" To: "Brian Rosen" , "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian wrote: >In North America, "walking up the tree" may not get you the right PSAP. >There is a notion of a "default route", but it's typically more complex = then >walking up the tree. I talked about a "default" PSAP and not the "right" PSAP. IMHO it is a local matter to define always a "default" PSAP for such cases. It may be a neighboring PSAP or in worst case the state default PSAP. >First of all are you suggesting a new requirement? If so, please state = it. Yes, will do, I just have to check the existing requirements if it is an addition to an existing requirement or a new one. >Then, are you suggesting that the mechanism has to return the "longest >prefix match" equivalent? Is it acceptable that the client do more = work if >the presented location does not produce a route? The requirement has to be formulated implementation neutral. If this requires more work on the client or not is dependant on the implementation e.g. in DNS it may require a second query by the client. >We could put a PSAP NAPTR at, say bergen.nj.us.sos.arpa, which a client >could query for. That's not a wildcard. If we put a wildcard for >*.bergen.nj.us.sos.arpa, it would match >this-is-obviously-bogus.bergen.nj.us.sos.arpa. It's not clear to me = this is >desirable. Its either or. If there is no more detail below bergen.nj.us.sos.arpa. =20 you put in a wildcard, If there is more detail, wildcards will not work and you have to put in a normal NAPTR. You see this NAPTR only if you query directly for bergen.nj.us.sos.arpa. =20 -richard -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Wednesday, August 03, 2005 4:11 AM To: Brian Rosen; Andrew Newton Cc: ECRIT Subject: Re: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt Hi Brian, we may run here in a similar problem with DNS wildcards (considered harmful by some ;-) like in ENUM e.g with pilotnumbers. On one side we have: L6. Validation of civic location: It MUST be possible to validate an address prior to its use in an actual emergency call. emphasis on prior on the other hand the mapping protocol MUST return a valid PSAP URI even with an invalid or partially valid location during the emergency call (there is no time during the emergency call to start hazzling the subscriber with a wrongly entered housenumber or misspelled streetname So there is a requirement for the mapping database: If you query the database with a wrong (not existing) civil location, the return MUST contain there most appropriate PSAP URI (e.g. the state default PSAP) AND an indication that the location infromation provided is not existing. In the examples given if you enter this-is-obviously-bogus.bergen.nj.us.sos.arpa and there is a 123.main.bergen.nj.us.sos.arpa you get back NXDOMAIN but not a proper NAPTR at all You have then to walk up the tree e.g. using the indication of the enclosing zone to find the default NAPTR for the street or county, etc This default NAPTR is NOT a wildcard -richard ________________________________ Von: Brian Rosen [mailto:br@brianrosen.net] Gesendet: Di 02.08.2005 17:11 An: 'Andrew Newton' Cc: Stastny Richard; 'ECRIT' Betreff: RE: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt So, I answered this If there is 123.main.bergen...., then you have validation data loaded in = the DNS, in which case you do not have a wildcard. You would only have the wildcard if there was not any data below Bergen.nj.us.sos.arpa. Brian -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Tuesday, August 02, 2005 10:50 AM To: Brian Rosen Cc: 'Stastny Richard'; 'ECRIT' Subject: Re: [Ecrit] FW: I-D ACTION:draft-rosen-dns-sos-02.txt On Aug 2, 2005, at 10:10 AM, Brian Rosen wrote: > I reread this and wondered if I misunderstood the question. Perhaps I asked the question incorrectly. Let me try again. If there is: *.bergen.nj.us.sos.arpa and 123.main.bergen.nj.us.sos.arpa How do you validate (or invalidate): this-is-obviously-bogus.bergen.nj.us.sos.arpa -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 03 05:07:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FDx-0004LC-ME; Wed, 03 Aug 2005 05:07:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FDw-0004L7-Jt for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 05:07:40 -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 FAA26672 for ; Wed, 3 Aug 2005 05:07:38 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Fka-000525-CJ for ecrit@ietf.org; Wed, 03 Aug 2005 05:41:25 -0400 Received: from [86.255.27.116] ([::ffff:86.255.27.116]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 03 Aug 2005 05:07:28 -0400 id 00160356.42F08950.00006D94 In-Reply-To: <200508030723.DAA20628@ietf.org> References: <200508030723.DAA20628@ietf.org> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] some observations from yesterday wg meeting Date: Wed, 3 Aug 2005 05:07:09 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Aug 3, 2005, at 3:23 AM, Brian Rosen wrote: > This discussion is more or less out of charter, as the work in ecrit > addresses the first point above. I don't think so. I think James has made a fairly important point: the notion that L2 location must be signed can simply be circumvented by an attacker contacting the PSAP's SIP server directly. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 03 05:19:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FPI-0002Fc-Q8; Wed, 03 Aug 2005 05:19:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FP1-00029I-IV for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 05:19:07 -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 FAA27440 for ; Wed, 3 Aug 2005 05:19:05 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Fvg-0005YB-Fx for ecrit@ietf.org; Wed, 03 Aug 2005 05:52:52 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j739J4de027613; Wed, 3 Aug 2005 04:19:04 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 3 Aug 2005 10:19:03 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0104FA3DD@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: James Seng Subject: RE: [Ecrit] some observations from yesterday wg meeting Date: Wed, 3 Aug 2005 10:19:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The issue you raise is not created by IP telephony. The problem exists from the start of Pay as you go cellphones. There are now huge numbers of these phones circulating, all capable of making emergency calls, and large numbers of them totally untraceable back to an end user, due to various reasons like the user has moved (innocent) through to the user deliberately wanting a communication device that is untraceable so supplied false details to start off with. However, even with this, I do not currently see the anything different from Brian's listed priorities. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 > -----Original Message----- > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org]On Behalf Of > James Seng > Sent: 03 August 2005 08:36 > To: Brian Rosen > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] some observations from yesterday wg meeting > > > That may be the American experience but certainly not mine. > > -James Seng > > On 03 Aug 2005, at 3:23 PM, Brian Rosen wrote: > > > In North America, the PSAPs tell us that their priorities are to: > > 1. Get the call to the right PSAP > > 2. Get a call back number > > 3. Get the location of the caller > > > > To the extent that the current PSTN equates "identity" of the > > caller with > > the telephone number, they are getting identity as their > second point. > > > > This discussion is more or less out of charter, as the work in ecrit > > addresses the first point above. > > > > For ecrit, we did have a discussion on the importance of assuring > > that the > > location provided is the actual location of the caller. This is > > actually > > the biggest part of addressing prank calls. > > > > As I said in the meeting, the PSAPs I know would accept a > call with no > > location, no call back and no identity. They might be VERY > > suspicious of > > such a call, but they will take it, and depending on what the > > caller said, > > they probably will dispatch someone. At least for the PSAPs I > > know, while > > they will demand a lot of effort to make sure location and call > > back are > > accurate, they will, in fact, accept a call without it. In that > > regard, I > > think they care about the house on fire first, and the identity > > second. > > > > Brian > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > Behalf Of > > James Seng > > Sent: Wednesday, August 03, 2005 12:04 AM > > To: ecrit@ietf.org > > Subject: [Ecrit] some observations from yesterday wg meeting > > > > I am not a regular on this list so whatever I said here is based on > > what I see at yesterday wg meeting. Pardon me if these already been > > discussed. > > 1. There are a lot of talks about how caller can authenticate the > > emergency response centers (singapore term for what WG's > called PSAP) > > but not much talks about how PSAP is going to authenticate the > > callers. > > > > Considering how many prank calls typical PSAP gets, I wont be > > surprised if their priority is to identify the caller first and less > > about your house on fire. > > > > No I am serious. That's my experience when dealing with them on E911 > > when we are working on our IP Telephony framework. > > > > 2. Any bet how long it will take PSAP to install a SIP server into > > their system? Especially a system which will allow anyone from > > anywhere in the world to call them anonymously? > > > > So while it is important for the caller to be able to identify his > > nearest PSAP, it is equally important for PSAP to be able to (a) > > identify the caller and (b) establish that the caller is within the > > zone they are serving. > > > > -James Seng > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 03 05:20:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FQc-0002zA-Lt; Wed, 03 Aug 2005 05:20:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FQb-0002yN-6H for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 05:20:45 -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 FAA27532 for ; Wed, 3 Aug 2005 05:20:43 -0400 (EDT) Message-Id: <200508030920.FAA27532@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0FxG-0005aB-6q for ecrit@ietf.org; Wed, 03 Aug 2005 05:54:30 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.51) id 1E0FQQ-0002Dm-KP; Wed, 03 Aug 2005 04:20:35 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] some observations from yesterday wg meeting Date: Wed, 3 Aug 2005 05:20:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWYCsfaB4TCxNnsSxq3DzxuLSXiyAAATdmw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org But that problem is not in our charter. If an attacker learned a PSAP's SIP URI from any mechanism, they can mount an attack. True. Not in our charter. Determining that a location represents the location of the caller is within charter. I believe identity of caller is NOT a requirement in general, but I think it's clearly not a requirement in ecrit. Brian -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Wednesday, August 03, 2005 5:07 AM To: Brian Rosen Cc: 'James Seng'; ecrit@ietf.org Subject: Re: [Ecrit] some observations from yesterday wg meeting On Aug 3, 2005, at 3:23 AM, Brian Rosen wrote: > This discussion is more or less out of charter, as the work in ecrit > addresses the first point above. I don't think so. I think James has made a fairly important point: the notion that L2 location must be signed can simply be circumvented by an attacker contacting the PSAP's SIP server directly. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 03 05:28:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FYV-0007Y1-4l; Wed, 03 Aug 2005 05:28:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FYS-0007Tb-OZ for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 05:28:53 -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 FAA28286 for ; Wed, 3 Aug 2005 05:28:50 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0G56-0005zH-Q8 for ecrit@ietf.org; Wed, 03 Aug 2005 06:02:38 -0400 Received: from [86.255.27.116] ([::ffff:86.255.27.116]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 03 Aug 2005 05:28:44 -0400 id 0016035B.42F08E4C.0000724E In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <75D53388-EC0D-44A2-BA82-B413344BC56B@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] some observations from yesterday wg meeting Date: Wed, 3 Aug 2005 05:28:36 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Aug 3, 2005, at 5:20 AM, Brian Rosen wrote: > Determining that a location represents the location of the caller > is within > charter. I don't think this is explicitly in the charter either. The charter talks about how to use location, but says nothing about verifying location. The charter aside, if we create the most super,duper concrete security mechanism and validation on location, what James is suggesting is that an attacker can just side step that and communicate directly with the PSAP's SIP server. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 03 05:33:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Fd9-0002r6-5p; Wed, 03 Aug 2005 05:33:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Fd6-0002qC-9B for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 05:33:41 -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 FAA29024 for ; Wed, 3 Aug 2005 05:33:38 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0G9l-0006Gh-Bw for ecrit@ietf.org; Wed, 03 Aug 2005 06:07:25 -0400 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j739Xasw024827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Aug 2005 05:33:37 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j739XYm6025943; Wed, 3 Aug 2005 05:33:35 -0400 Message-ID: <42F08F76.9010404@cs.columbia.edu> Date: Wed, 03 Aug 2005 05:33:42 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Ecrit] some observations from yesterday wg meeting References: <475FF955A05DD411980D00508B6D5FB0104FA3DD@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB0104FA3DD@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org One possible difference is one of scale. You'd have to buy a lot of prepay cell phones to launch a serious DOS attack and then find lots of partners-in-crime to make them appear to come from a large number of different locations. I think we can approximate these limitations in a VoIP scenario by relying on network-layer information. Carrying this information with the call will allow the proxy to recognize that hundreds of calls are all coming from one IP address, say. (Botnets are a different problem.) Drage, Keith (Keith) wrote: > The issue you raise is not created by IP telephony. > > The problem exists from the start of Pay as you go cellphones. There are now huge numbers of these phones circulating, all capable of making emergency calls, and large numbers of them totally untraceable back to an end user, due to various reasons like the user has moved (innocent) through to the user deliberately wanting a communication device that is untraceable so supplied false details to start off with. > > However, even with this, I do not currently see the anything different from Brian's listed priorities. > > regards > > Keith > > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 03 05:35:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FeZ-0004rI-LR; Wed, 03 Aug 2005 05:35:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FeV-0004kp-0T for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 05:35:07 -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 FAA29211 for ; Wed, 3 Aug 2005 05:35:04 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0GBA-0006JI-5m for ecrit@ietf.org; Wed, 03 Aug 2005 06:08:52 -0400 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j739Z0sw025388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Aug 2005 05:35:01 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j739Yx1m025947; Wed, 3 Aug 2005 05:35:00 -0400 Message-ID: <42F08FCB.1090404@cs.columbia.edu> Date: Wed, 03 Aug 2005 05:35:07 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] some observations from yesterday wg meeting References: <75D53388-EC0D-44A2-BA82-B413344BC56B@hxr.us> In-Reply-To: <75D53388-EC0D-44A2-BA82-B413344BC56B@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_LOC 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > The charter aside, if we create the most super,duper concrete security > mechanism and validation on location, what James is suggesting is that > an attacker can just side step that and communicate directly with the > PSAP's SIP server. One would hope that the PSAP SIP server takes a look at the location information and does a sanity check on the data. ("I'm in Kansas and an address in Nigeria is beyond my service area.") _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 03 05:39:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Fin-0007nq-J2; Wed, 03 Aug 2005 05:39:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Fim-0007ni-1i for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 05:39:32 -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 FAA29518 for ; Wed, 3 Aug 2005 05:39:29 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E0GFQ-0006Wm-Rs for ecrit@ietf.org; Wed, 03 Aug 2005 06:13:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] some observations from yesterday wg meeting Date: Wed, 3 Aug 2005 11:42:53 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C084@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] some observations from yesterday wg meeting Thread-Index: AcWYDVQtDMdrpn9tTcuj1jBRp7tSkQAASYfy From: "Stastny Richard" To: "Drage, Keith \(Keith\)" , "James Seng" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org It is even worse. In many countries you still may make emergency calls from mobile phones without a SIM card. The majority of calls come on Sunday morning from people buying mobile phones at the flea-markets using 112 as test-number to check the device. =20 You may also reach the PSAPs from some countries (I wiLL not tell which ;-) via an internatinal number. In most cases your CLI is not delivered (and definitely not if you make a SkypeOut call) =20 So we should try to fix some of the problems existing now, but not world hunger and save the whales. The important thing is, as Brian not gets tired to state: that you reach an PSAP if you need one. =20 -richard ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von Drage, Keith (Keith) Gesendet: Mi 03.08.2005 11:19 An: James Seng Cc: ecrit@ietf.org Betreff: RE: [Ecrit] some observations from yesterday wg meeting The issue you raise is not created by IP telephony. The problem exists from the start of Pay as you go cellphones. There are = now huge numbers of these phones circulating, all capable of making = emergency calls, and large numbers of them totally untraceable back to = an end user, due to various reasons like the user has moved (innocent) = through to the user deliberately wanting a communication device that is = untraceable so supplied false details to start off with. However, even with this, I do not currently see the anything different = from Brian's listed priorities. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 > -----Original Message----- > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org]On Behalf Of > James Seng > Sent: 03 August 2005 08:36 > To: Brian Rosen > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] some observations from yesterday wg meeting > > > That may be the American experience but certainly not mine. > > -James Seng > > On 03 Aug 2005, at 3:23 PM, Brian Rosen wrote: > > > In North America, the PSAPs tell us that their priorities are to: > > 1. Get the call to the right PSAP > > 2. Get a call back number > > 3. Get the location of the caller > > > > To the extent that the current PSTN equates "identity" of the=20 > > caller with > > the telephone number, they are getting identity as their > second point. > > > > This discussion is more or less out of charter, as the work in ecrit > > addresses the first point above. > > > > For ecrit, we did have a discussion on the importance of assuring=20 > > that the > > location provided is the actual location of the caller. This is=20 > > actually > > the biggest part of addressing prank calls. > > > > As I said in the meeting, the PSAPs I know would accept a > call with no > > location, no call back and no identity. They might be VERY=20 > > suspicious of > > such a call, but they will take it, and depending on what the=20 > > caller said, > > they probably will dispatch someone. At least for the PSAPs I=20 > > know, while > > they will demand a lot of effort to make sure location and call=20 > > back are > > accurate, they will, in fact, accept a call without it. In that=20 > > regard, I > > think they care about the house on fire first, and the identity=20 > > second. > > > > Brian > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > > Behalf Of > > James Seng > > Sent: Wednesday, August 03, 2005 12:04 AM > > To: ecrit@ietf.org > > Subject: [Ecrit] some observations from yesterday wg meeting > > > > I am not a regular on this list so whatever I said here is based on > > what I see at yesterday wg meeting. Pardon me if these already been > > discussed. > > 1. There are a lot of talks about how caller can authenticate the > > emergency response centers (singapore term for what WG's > called PSAP) > > but not much talks about how PSAP is going to authenticate the=20 > > callers. > > > > Considering how many prank calls typical PSAP gets, I wont be > > surprised if their priority is to identify the caller first and less > > about your house on fire. > > > > No I am serious. That's my experience when dealing with them on E911 > > when we are working on our IP Telephony framework. > > > > 2. Any bet how long it will take PSAP to install a SIP server into > > their system? Especially a system which will allow anyone from > > anywhere in the world to call them anonymously? > > > > So while it is important for the caller to be able to identify his > > nearest PSAP, it is equally important for PSAP to be able to (a) > > identify the caller and (b) establish that the caller is within the > > zone they are serving. > > > > -James Seng > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 03 05:46:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FpO-0002dX-J4; Wed, 03 Aug 2005 05:46:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FpM-0002cx-Ld for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 05:46:20 -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 FAA00128 for ; Wed, 3 Aug 2005 05:46:18 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E0GM1-0006pO-O0 for ecrit@ietf.org; Wed, 03 Aug 2005 06:20:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] some observations from yesterday wg meeting Date: Wed, 3 Aug 2005 11:46:17 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C085@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] some observations from yesterday wg meeting Thread-Index: AcWYDzD99cxoW+rHTBifI9ZOCpv0xgAAQC61 From: "Stastny Richard" To: "Henning Schulzrinne" , "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org >One would hope that the PSAP SIP server takes a look at the location >information and does a sanity check on the data. ("I'm in Kansas and an >address in Nigeria is beyond my service area.") Do not forget VPNs. For a single call, You may bring up a warning to the call taker, but not reject the call. Thy guy from Nigeria may sit at Starbucks next door. One may implement something if you get a DOS attack from this address, but again, most DOS attacks nowadays use differnt addresses. -richard ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von Henning Schulzrinne Gesendet: Mi 03.08.2005 11:35 An: Andrew Newton Cc: ecrit@ietf.org Betreff: Re: [Ecrit] some observations from yesterday wg meeting > The charter aside, if we create the most super,duper concrete = security > mechanism and validation on location, what James is suggesting is = that > an attacker can just side step that and communicate directly with the > PSAP's SIP server. One would hope that the PSAP SIP server takes a look at the location information and does a sanity check on the data. ("I'm in Kansas and an address in Nigeria is beyond my service area.") _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 03 05:47:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FqM-00039j-VY; Wed, 03 Aug 2005 05:47:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FqJ-000397-E3 for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 05:47:19 -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 FAA00236 for ; Wed, 3 Aug 2005 05:47:17 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0GMy-0006rO-Ba for ecrit@ietf.org; Wed, 03 Aug 2005 06:21:04 -0400 Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com [47.153.200.67]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j739krh00745; Wed, 3 Aug 2005 04:46:54 -0500 (CDT) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Aug 2005 19:45:33 +1000 Message-ID: From: "James Winterbottom" To: Brian Rosen , "'Andrew Newton'" Subject: RE: [Ecrit] some observations from yesterday wg meeting Date: Wed, 3 Aug 2005 19:45:32 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0945739222==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0945739222== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59810.174DA892" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C59810.174DA892 Content-Type: text/plain Bah!!! The problem must exist in someone's charter, and GeoPriv don't seem to want it either! It is not easy, without having relatively substantial local foot print, to spoof emergency calls with in the USA today. In a IP world, that is simply not true any longer with the currently proposed mechanisms of user created location documents, no matter where the source data came from. That is consumers of location (location recipients LRs) have absolutely NO means of assuring that this correct. The same is absolutely not true for 99.999% of PSTN calls. Location is today in the cellular and wireline world is the responsibility of the access provider, and this will need to remain the responsibility of the access provider in the future until telekenic-osmosis becomes a reality. ECRIT or GeoPriv pick it up until then, but stop passing the buck!!! Cheers James -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, 3 August 2005 7:21 PM To: 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] some observations from yesterday wg meeting But that problem is not in our charter. If an attacker learned a PSAP's SIP URI from any mechanism, they can mount an attack. True. Not in our charter. Determining that a location represents the location of the caller is within charter. I believe identity of caller is NOT a requirement in general, but I think it's clearly not a requirement in ecrit. Brian -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Wednesday, August 03, 2005 5:07 AM To: Brian Rosen Cc: 'James Seng'; ecrit@ietf.org Subject: Re: [Ecrit] some observations from yesterday wg meeting On Aug 3, 2005, at 3:23 AM, Brian Rosen wrote: > This discussion is more or less out of charter, as the work in ecrit > addresses the first point above. I don't think so. I think James has made a fairly important point: the notion that L2 location must be signed can simply be circumvented by an attacker contacting the PSAP's SIP server directly. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C59810.174DA892 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Ecrit] some observations from yesterday wg meeting

Bah!!!

The problem must exist in someone's charter, and = GeoPriv don't seem to want it either!

It is not easy, without having relatively substantial = local foot print, to spoof emergency calls with in the USA today. In a = IP world, that is simply not true any longer with the currently = proposed mechanisms of user created location documents, no matter where = the source data came from. That is consumers of location (location = recipients LRs) have absolutely NO means of assuring that this correct. = The same is absolutely not true for 99.999% of PSTN calls.

Location is today in the cellular and wireline world = is the responsibility of the access provider, and this will need to = remain the responsibility of the access provider in the future until = telekenic-osmosis becomes a reality. ECRIT or GeoPriv pick it up until = then, but stop passing the buck!!!


Cheers
James



-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf Of Brian Rosen
Sent: Wednesday, 3 August 2005 7:21 PM
To: 'Andrew Newton'
Cc: ecrit@ietf.org
Subject: RE: [Ecrit] some observations from = yesterday wg meeting


But that problem is not in our charter.  If an = attacker learned a PSAP's SIP URI from any mechanism, they can mount an = attack.

True.

Not in our charter.

Determining that a location represents the location = of the caller is within charter.

I believe identity of caller is NOT a requirement in = general, but I think it's clearly not a requirement in ecrit.

Brian

-----Original Message-----
From: Andrew Newton [mailto:andy@hxr.us]
Sent: Wednesday, August 03, 2005 5:07 AM
To: Brian Rosen
Cc: 'James Seng'; ecrit@ietf.org
Subject: Re: [Ecrit] some observations from = yesterday wg meeting


On Aug 3, 2005, at 3:23 AM, Brian Rosen wrote:

> This discussion is more or less out of charter, = as the work in ecrit
> addresses the first point above.

I don't think so.  I think James has made a = fairly important point: 
the notion that L2 location must be signed can = simply be circumvented 
by an attacker contacting the PSAP's SIP server = directly.

-andy



_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

------_=_NextPart_001_01C59810.174DA892-- --===============0945739222== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0945739222==-- From ecrit-bounces@ietf.org Wed Aug 03 06:09:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GC2-0006En-Kl; Wed, 03 Aug 2005 06:09:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GC0-0006Eb-6v for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 06:09:44 -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 GAA01714 for ; Wed, 3 Aug 2005 06:09:41 -0400 (EDT) Message-Id: <200508031009.GAA01714@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Gif-0007wN-AQ for ecrit@ietf.org; Wed, 03 Aug 2005 06:43:29 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.51) id 1E0GBp-00048u-EV; Wed, 03 Aug 2005 05:09:33 -0500 From: "Brian Rosen" To: "'James Winterbottom'" , "'Andrew Newton'" Subject: RE: [Ecrit] some observations from yesterday wg meeting Date: Wed, 3 Aug 2005 06:09:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWYEEoZKU/PI7AKT92BreoreXAXSwAAkSeg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Chairs? I was not a fan of the narrow focus of the charter. It is what it is. Each change in technology changes the situation for emergency call = systems. It takes away things, and provides new things. When mobile phones came, they removed accurate location and substituted inaccurate location in a totally different, and difficult-for-psap-to-use form. They even took = away call back number in the case of un-initialized phones. They gave the possibility of tracking a moving caller, and they gave the ability to = get calls immediately from the scene of common events like car crashes. On balance, it's a good thing. VoIP is the same; some things are being taken away, some things are = being added. It's different, get over it. Brian ________________________________________ From: James Winterbottom [mailto:winterb@nortel.com]=20 Sent: Wednesday, August 03, 2005 5:46 AM To: Brian Rosen; 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] some observations from yesterday wg meeting Bah!!!=20 The problem must exist in someone's charter, and GeoPriv don't seem to = want it either!=20 It is not easy, without having relatively substantial local foot print, = to spoof emergency calls with in the USA today. In a IP world, that is = simply not true any longer with the currently proposed mechanisms of user = created location documents, no matter where the source data came from. That is consumers of location (location recipients LRs) have absolutely NO means = of assuring that this correct. The same is absolutely not true for 99.999% = of PSTN calls.=20 Location is today in the cellular and wireline world is the = responsibility of the access provider, and this will need to remain the responsibility = of the access provider in the future until telekenic-osmosis becomes a = reality. ECRIT or GeoPriv pick it up until then, but stop passing the buck!!! Cheers=20 James=20 -----Original Message-----=20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Brian Rosen=20 Sent: Wednesday, 3 August 2005 7:21 PM=20 To: 'Andrew Newton'=20 Cc: ecrit@ietf.org=20 Subject: RE: [Ecrit] some observations from yesterday wg meeting=20 But that problem is not in our charter.=A0 If an attacker learned a = PSAP's SIP URI from any mechanism, they can mount an attack. True.=20 Not in our charter.=20 Determining that a location represents the location of the caller is = within charter.=20 I believe identity of caller is NOT a requirement in general, but I = think it's clearly not a requirement in ecrit.=20 Brian=20 -----Original Message-----=20 From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Wednesday, August 03, 2005 5:07 AM=20 To: Brian Rosen=20 Cc: 'James Seng'; ecrit@ietf.org=20 Subject: Re: [Ecrit] some observations from yesterday wg meeting=20 On Aug 3, 2005, at 3:23 AM, Brian Rosen wrote:=20 > This discussion is more or less out of charter, as the work in ecrit=20 > addresses the first point above.=20 I don't think so.=A0 I think James has made a fairly important point:=A0 = the notion that L2 location must be signed can simply be circumvented=A0 = by an attacker contacting the PSAP's SIP server directly.=20 -andy=20 _______________________________________________=20 Ecrit mailing list=20 Ecrit@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ecrit=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 03 06:20:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GMo-0004dT-HC; Wed, 03 Aug 2005 06:20:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GMm-0004dL-HR for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 06:20:52 -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 GAA02241 for ; Wed, 3 Aug 2005 06:20:50 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0GtQ-0008Qs-Qk for ecrit@ietf.org; Wed, 03 Aug 2005 06:54:38 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 03 Aug 2005 03:20:41 -0700 X-IronPort-AV: i="3.95,163,1120460400"; d="scan'208"; a="328515186:sNHT30786688" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j73AKfJL023018; Wed, 3 Aug 2005 03:20:41 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 03:20:41 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 03:20:41 -0700 From: "Marc Linsner" To: "'Andrew Newton'" , "'Brian Rosen'" Subject: RE: [Ecrit] some observations from yesterday wg meeting Date: Wed, 3 Aug 2005 06:20:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <75D53388-EC0D-44A2-BA82-B413344BC56B@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWYDlE/GfxEu8agSLOWKwueJhhrfAAAfJuA Message-ID: X-OriginalArrivalTime: 03 Aug 2005 10:20:41.0383 (UTC) FILETIME=[00211370:01C59815] X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Certainly a PSAP needs to take measures to protect themselves from the evil on the Internet. This is no different than any other entity. -Marc- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Andrew Newton > Sent: Wednesday, August 03, 2005 5:29 AM > To: Brian Rosen > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] some observations from yesterday wg meeting > > > On Aug 3, 2005, at 5:20 AM, Brian Rosen wrote: > > > Determining that a location represents the location of the > caller is > > within charter. > > I don't think this is explicitly in the charter either. The > charter talks about how to use location, but says nothing > about verifying location. > > The charter aside, if we create the most super,duper concrete > security mechanism and validation on location, what James is > suggesting is that an attacker can just side step that and > communicate directly with the PSAP's SIP server. > > -andy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 03 06:32:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GYF-00024t-Gi; Wed, 03 Aug 2005 06:32:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GYE-00024o-50 for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 06:32:42 -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 GAA02827 for ; Wed, 3 Aug 2005 06:32:39 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0H4t-0000Qk-9B for ecrit@ietf.org; Wed, 03 Aug 2005 07:06:27 -0400 Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com [47.153.200.67]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j73AWEh06303; Wed, 3 Aug 2005 05:32:14 -0500 (CDT) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Aug 2005 20:31:24 +1000 Message-ID: From: "James Winterbottom" To: Brian Rosen , "'Andrew Newton'" Subject: RE: [Ecrit] some observations from yesterday wg meeting Date: Wed, 3 Aug 2005 20:31:23 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0989257001==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0989257001== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59816.7F212BF0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C59816.7F212BF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, Let me make sure that I have a clear understanding of your point here. I as a recipient of location information, that provide a service in = good faith, have no right or come back, if the location provided to me is incorrect?=20 Please explain to me how this is a step in a positive direction, and = how this will bolster adoption of IP telephony? I think that people will accept "near-equivalency", but that they will = not accept out and out lack of equivalent service. Cheers James -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, 3 August 2005 8:10 PM To: Winterbottom, James [WOLL:5500:EXCH]; 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] some observations from yesterday wg meeting Chairs? I was not a fan of the narrow focus of the charter. It is what it is. Each change in technology changes the situation for emergency call = systems. It takes away things, and provides new things. When mobile phones = came, they removed accurate location and substituted inaccurate location in a totally different, and difficult-for-psap-to-use form. They even took = away call back number in the case of un-initialized phones. They gave the possibility of tracking a moving caller, and they gave the ability to = get calls immediately from the scene of common events like car crashes. On balance, it's a good thing. VoIP is the same; some things are being taken away, some things are = being added. It's different, get over it. Brian ________________________________________ From: James Winterbottom [mailto:winterb@nortel.com]=20 Sent: Wednesday, August 03, 2005 5:46 AM To: Brian Rosen; 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] some observations from yesterday wg meeting Bah!!!=20 The problem must exist in someone's charter, and GeoPriv don't seem to = want it either!=20 It is not easy, without having relatively substantial local foot print, = to spoof emergency calls with in the USA today. In a IP world, that is = simply not true any longer with the currently proposed mechanisms of user = created location documents, no matter where the source data came from. That is consumers of location (location recipients LRs) have absolutely NO = means of assuring that this correct. The same is absolutely not true for 99.999% = of PSTN calls.=20 Location is today in the cellular and wireline world is the = responsibility of the access provider, and this will need to remain the responsibility = of the access provider in the future until telekenic-osmosis becomes a = reality. ECRIT or GeoPriv pick it up until then, but stop passing the buck!!! Cheers=20 James=20 -----Original Message-----=20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Brian Rosen=20 Sent: Wednesday, 3 August 2005 7:21 PM=20 To: 'Andrew Newton'=20 Cc: ecrit@ietf.org=20 Subject: RE: [Ecrit] some observations from yesterday wg meeting=20 But that problem is not in our charter.=A0 If an attacker learned a = PSAP's SIP URI from any mechanism, they can mount an attack. True.=20 Not in our charter.=20 Determining that a location represents the location of the caller is = within charter.=20 I believe identity of caller is NOT a requirement in general, but I = think it's clearly not a requirement in ecrit.=20 Brian=20 -----Original Message-----=20 From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Wednesday, August 03, 2005 5:07 AM=20 To: Brian Rosen=20 Cc: 'James Seng'; ecrit@ietf.org=20 Subject: Re: [Ecrit] some observations from yesterday wg meeting=20 On Aug 3, 2005, at 3:23 AM, Brian Rosen wrote:=20 > This discussion is more or less out of charter, as the work in ecrit > addresses the first point above.=20 I don't think so.=A0 I think James has made a fairly important = point:=A0=20 the notion that L2 location must be signed can simply be = circumvented=A0=20 by an attacker contacting the PSAP's SIP server directly.=20 -andy=20 _______________________________________________=20 Ecrit mailing list=20 Ecrit@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ecrit=20 ------_=_NextPart_001_01C59816.7F212BF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Ecrit] some observations from yesterday wg meeting

Brian,

Let me make sure that I have a clear understanding of = your point here.
I as a recipient of location information, that = provide a service in good faith, have no right or come back, if the = location provided to me is incorrect?

Please explain to me how this is a step in a positive = direction, and how this will bolster adoption of IP telephony?

I think that people will accept = "near-equivalency", but that they will not accept out and out = lack of equivalent service.

Cheers
James


-----Original Message-----
From: Brian Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, 3 August 2005 8:10 PM
To: Winterbottom, James [WOLL:5500:EXCH]; 'Andrew = Newton'
Cc: ecrit@ietf.org
Subject: RE: [Ecrit] some observations from = yesterday wg meeting


Chairs?

I was not a fan of the narrow focus of the = charter.  It is what it is.

Each change in technology changes the situation for = emergency call systems. It takes away things, and provides new = things.  When mobile phones came, they removed accurate location = and substituted inaccurate location in a totally different, and = difficult-for-psap-to-use form.  They even took away call back = number in the case of un-initialized phones. They gave the possibility = of tracking a moving caller, and they gave the ability to get calls = immediately from the scene of common events like car crashes.  On = balance, it's a good thing.

VoIP is the same; some things are being taken away, = some things are being added.  It's different, get over it.

Brian

________________________________________
From: James Winterbottom [mailto:winterb@nortel.com] =
Sent: Wednesday, August 03, 2005 5:46 AM
To: Brian Rosen; 'Andrew Newton'
Cc: ecrit@ietf.org
Subject: RE: [Ecrit] some observations from = yesterday wg meeting

Bah!!!
The problem must exist in someone's charter, and = GeoPriv don't seem to want it either!
It is not easy, without having relatively = substantial local foot print, to spoof emergency calls with in the USA = today. In a IP world, that is simply not true any longer with the = currently proposed mechanisms of user created location documents, no = matter where the source data came from. That is consumers of location = (location recipients LRs) have absolutely NO means of assuring that = this correct. The same is absolutely not true for 99.999% of PSTN = calls.

Location is today in the cellular and wireline world = is the responsibility of the access provider, and this will need to = remain the responsibility of the access provider in the future until = telekenic-osmosis becomes a reality. ECRIT or GeoPriv pick it up until = then, but stop passing the buck!!!

Cheers
James

-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf Of Brian Rosen
Sent: Wednesday, 3 August 2005 7:21 PM
To: 'Andrew Newton'
Cc: ecrit@ietf.org
Subject: RE: [Ecrit] some observations from = yesterday wg meeting

But that problem is not in our charter.=A0 If an = attacker learned a PSAP's SIP URI from any mechanism, they can mount an = attack. True.

Not in our charter.
Determining that a location represents the location = of the caller is within charter.
I believe identity of caller is NOT a requirement in = general, but I think it's clearly not a requirement in ecrit.
Brian
-----Original Message-----
From: Andrew Newton [mailto:andy@hxr.us]
Sent: Wednesday, August 03, 2005 5:07 AM
To: Brian Rosen
Cc: 'James Seng'; ecrit@ietf.org
Subject: Re: [Ecrit] some observations from = yesterday wg meeting

On Aug 3, 2005, at 3:23 AM, Brian Rosen wrote: =
> This discussion is more or less out of charter, = as the work in ecrit
> addresses the first point above.
I don't think so.=A0 I think James has made a fairly = important point:=A0
the notion that L2 location must be signed can = simply be circumvented=A0
by an attacker contacting the PSAP's SIP server = directly.
-andy

_______________________________________________ =
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit =

------_=_NextPart_001_01C59816.7F212BF0-- --===============0989257001== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0989257001==-- From ecrit-bounces@ietf.org Wed Aug 03 07:03:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0H2P-0003Mo-2e; Wed, 03 Aug 2005 07:03:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0H2L-0003B6-L2 for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 07:03:51 -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 HAA05098 for ; Wed, 3 Aug 2005 07:03:47 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0HZ0-00021C-1j for ecrit@ietf.org; Wed, 03 Aug 2005 07:37:35 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 03 Aug 2005 04:03:38 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j73B3YIs026901; Wed, 3 Aug 2005 04:03:34 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 04:03:38 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 04:03:36 -0700 From: "Marc Linsner" To: "'James Winterbottom'" , "'Brian Rosen'" , "'Andrew Newton'" Subject: RE: [Ecrit] some observations from yesterday wg meeting Date: Wed, 3 Aug 2005 07:03:36 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWYENMwnNguRSJLSaSR6UMXyTlJNQACPGwA Message-ID: X-OriginalArrivalTime: 03 Aug 2005 11:03:37.0150 (UTC) FILETIME=[FF67EDE0:01C5981A] X-Spam-Score: 1.7 (+) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0014890706==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0014890706== Content-Type: multipart/alternative; boundary="----=_NextPart_000_013A_01C597F9.799D25C0" This is a multi-part message in MIME format. ------=_NextPart_000_013A_01C597F9.799D25C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit James, The Internet is not attempting to look like the PSTN. (some would say for good reason) -Marc- _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James Winterbottom Sent: Wednesday, August 03, 2005 5:46 AM To: Brian Rosen; 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] some observations from yesterday wg meeting Bah!!! The problem must exist in someone's charter, and GeoPriv don't seem to want it either! It is not easy, without having relatively substantial local foot print, to spoof emergency calls with in the USA today. In a IP world, that is simply not true any longer with the currently proposed mechanisms of user created location documents, no matter where the source data came from. That is consumers of location (location recipients LRs) have absolutely NO means of assuring that this correct. The same is absolutely not true for 99.999% of PSTN calls. Location is today in the cellular and wireline world is the responsibility of the access provider, and this will need to remain the responsibility of the access provider in the future until telekenic-osmosis becomes a reality. ECRIT or GeoPriv pick it up until then, but stop passing the buck!!! Cheers James -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, 3 August 2005 7:21 PM To: 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] some observations from yesterday wg meeting But that problem is not in our charter. If an attacker learned a PSAP's SIP URI from any mechanism, they can mount an attack. True. Not in our charter. Determining that a location represents the location of the caller is within charter. I believe identity of caller is NOT a requirement in general, but I think it's clearly not a requirement in ecrit. Brian -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Wednesday, August 03, 2005 5:07 AM To: Brian Rosen Cc: 'James Seng'; ecrit@ietf.org Subject: Re: [Ecrit] some observations from yesterday wg meeting On Aug 3, 2005, at 3:23 AM, Brian Rosen wrote: > This discussion is more or less out of charter, as the work in ecrit > addresses the first point above. I don't think so. I think James has made a fairly important point: the notion that L2 location must be signed can simply be circumvented by an attacker contacting the PSAP's SIP server directly. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------=_NextPart_000_013A_01C597F9.799D25C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Ecrit] some observations from yesterday wg = meeting
James,
 
The Internet is not attempting to look like the = PSTN. (some=20 would say for good reason)
 
-Marc-

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of James=20 Winterbottom
Sent: Wednesday, August 03, 2005 5:46 = AM
To:=20 Brian Rosen; 'Andrew Newton'
Cc: = ecrit@ietf.org
Subject:=20 RE: [Ecrit] some observations from yesterday wg = meeting

Bah!!!

The problem must exist in someone's charter, and = GeoPriv don't=20 seem to want it either!

It is not easy, without having relatively = substantial local=20 foot print, to spoof emergency calls with in the USA today. In a IP = world,=20 that is simply not true any longer with the currently proposed = mechanisms of=20 user created location documents, no matter where the source data came = from.=20 That is consumers of location (location recipients LRs) have = absolutely NO=20 means of assuring that this correct. The same is absolutely not true = for=20 99.999% of PSTN calls.

Location is today in the cellular and wireline world = is the=20 responsibility of the access provider, and this will need to remain = the=20 responsibility of the access provider in the future until = telekenic-osmosis=20 becomes a reality. ECRIT or GeoPriv pick it up until then, but stop = passing=20 the buck!!!


Cheers
James =



-----Original Message-----
From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]= On=20 Behalf Of Brian Rosen
Sent: Wednesday, 3 = August 2005=20 7:21 PM
To: 'Andrew Newton'
Cc: ecrit@ietf.org
Subject: RE: = [Ecrit] some=20 observations from yesterday wg meeting


But that problem is not in our charter.  If an = attacker=20 learned a PSAP's SIP URI from any mechanism, they can mount an=20 attack.

True.

Not in our charter.

Determining that a location represents the location = of the=20 caller is within charter.

I believe identity of caller is NOT a requirement in = general,=20 but I think it's clearly not a requirement in ecrit.

Brian

-----Original Message-----
From:=20 Andrew Newton [mailto:andy@hxr.us]=20
Sent: Wednesday, August 03, 2005 5:07 = AM=20
To: Brian Rosen
Cc: = 'James Seng';=20 ecrit@ietf.org
Subject: Re: [Ecrit] some = observations=20 from yesterday wg meeting


On Aug 3, 2005, at 3:23 AM, Brian Rosen = wrote:

> This discussion is more or less out of charter, = as the=20 work in ecrit
> addresses the first point = above.

I don't think so.  I think James has made a = fairly=20 important point: 
the notion that L2 = location=20 must be signed can simply be circumvented 
by an=20 attacker contacting the PSAP's SIP server directly.

-andy



_______________________________________________=20
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit=20

------=_NextPart_000_013A_01C597F9.799D25C0-- --===============0014890706== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0014890706==-- From ecrit-bounces@ietf.org Wed Aug 03 08:16:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0I6B-0004Ht-3D; Wed, 03 Aug 2005 08:11:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0I69-0004E4-5f for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 08:11:49 -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 IAA09302 for ; Wed, 3 Aug 2005 08:11:48 -0400 (EDT) Message-Id: <200508031211.IAA09302@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Icp-0005D3-1q for ecrit@ietf.org; Wed, 03 Aug 2005 08:45:35 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.51) id 1E0I5u-0000sd-Bx; Wed, 03 Aug 2005 07:11:36 -0500 From: "Brian Rosen" To: "'James Winterbottom'" , "'Andrew Newton'" Subject: RE: [Ecrit] some observations from yesterday wg meeting Date: Wed, 3 Aug 2005 08:11:30 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWYFp/w/G6FvlBLQguW7cXzfAe83QADU0yg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.6 (/) X-Scan-Signature: 2ed9477f79f24ff120e9894ad9dc9cb5 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0436222536==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0436222536== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0116_01C59802.F66FB640" This is a multi-part message in MIME format. ------=_NextPart_000_0116_01C59802.F66FB640 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think that we should provide some mechanisms to foster integrity and authentication of source of location. I think that such mechanisms should be widely deployed. I believe there are use cases where such information is useful. I think ONE of those use cases is emergency calls. I think it is not possible to provide assurances that are equivalent to current wireline location for emergency calls. I think location integrity and source authentication is work in geopriv, and not ecrit. Brian _____ From: James Winterbottom [mailto:winterb@nortel.com] Sent: Wednesday, August 03, 2005 6:31 AM To: Brian Rosen; 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] some observations from yesterday wg meeting Brian, Let me make sure that I have a clear understanding of your point here. I as a recipient of location information, that provide a service in good faith, have no right or come back, if the location provided to me is incorrect? Please explain to me how this is a step in a positive direction, and how this will bolster adoption of IP telephony? I think that people will accept "near-equivalency", but that they will not accept out and out lack of equivalent service. Cheers James -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, 3 August 2005 8:10 PM To: Winterbottom, James [WOLL:5500:EXCH]; 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] some observations from yesterday wg meeting Chairs? I was not a fan of the narrow focus of the charter. It is what it is. Each change in technology changes the situation for emergency call systems. It takes away things, and provides new things. When mobile phones came, they removed accurate location and substituted inaccurate location in a totally different, and difficult-for-psap-to-use form. They even took away call back number in the case of un-initialized phones. They gave the possibility of tracking a moving caller, and they gave the ability to get calls immediately from the scene of common events like car crashes. On balance, it's a good thing. VoIP is the same; some things are being taken away, some things are being added. It's different, get over it. Brian ________________________________________ From: James Winterbottom [mailto:winterb@nortel.com] Sent: Wednesday, August 03, 2005 5:46 AM To: Brian Rosen; 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] some observations from yesterday wg meeting Bah!!! The problem must exist in someone's charter, and GeoPriv don't seem to want it either! It is not easy, without having relatively substantial local foot print, to spoof emergency calls with in the USA today. In a IP world, that is simply not true any longer with the currently proposed mechanisms of user created location documents, no matter where the source data came from. That is consumers of location (location recipients LRs) have absolutely NO means of assuring that this correct. The same is absolutely not true for 99.999% of PSTN calls. Location is today in the cellular and wireline world is the responsibility of the access provider, and this will need to remain the responsibility of the access provider in the future until telekenic-osmosis becomes a reality. ECRIT or GeoPriv pick it up until then, but stop passing the buck!!! Cheers James -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, 3 August 2005 7:21 PM To: 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] some observations from yesterday wg meeting But that problem is not in our charter. If an attacker learned a PSAP's SIP URI from any mechanism, they can mount an attack. True. Not in our charter. Determining that a location represents the location of the caller is within charter. I believe identity of caller is NOT a requirement in general, but I think it's clearly not a requirement in ecrit. Brian -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Wednesday, August 03, 2005 5:07 AM To: Brian Rosen Cc: 'James Seng'; ecrit@ietf.org Subject: Re: [Ecrit] some observations from yesterday wg meeting On Aug 3, 2005, at 3:23 AM, Brian Rosen wrote: > This discussion is more or less out of charter, as the work in ecrit > addresses the first point above. I don't think so. I think James has made a fairly important point: the notion that L2 location must be signed can simply be circumvented by an attacker contacting the PSAP's SIP server directly. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------=_NextPart_000_0116_01C59802.F66FB640 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Ecrit] some observations from yesterday wg meeting

I think that we should provide some mechanisms to foster integrity and authentication of source of = location.  I think that such mechanisms should be widely deployed.  I believe = there are use cases where such information is useful.  I think ONE of those use = cases is emergency calls.  I think it is not possible to provide assurances = that are equivalent to current wireline location for emergency calls.  I think location = integrity and source authentication is work in geopriv, and not = ecrit.

 

Brian

 

From: James Winterbottom [mailto:winterb@nortel.com]
Sent: Wednesday, August = 03, 2005 6:31 AM
To: Brian Rosen; 'Andrew = Newton'
Cc: ecrit@ietf.org
Subject: RE: [Ecrit] some observations from yesterday wg meeting

 

Brian,

Let me make sure that I have a clear understanding of your point = here.
I as a recipient of = location information, that provide a service in good faith, have no right or come = back, if the location provided to me is incorrect? =

Please explain to me how this is a step in a positive direction, and how this = will bolster adoption of IP telephony?

I think that people will accept "near-equivalency", but that they will = not accept out and out lack of equivalent = service.

Cheers
James =

 

-----Original Message-----
From: Brian Rosen [mailto:br@brianrosen.net] =
Sent: Wednesday, 3 = August 2005 8:10 PM
To: Winterbottom, James [WOLL:5500:EXCH]; 'Andrew Newton'
Cc: = ecrit@ietf.org
Subject: RE: [Ecrit] = some observations from yesterday wg meeting

 

Chairs?

I was not a fan of the narrow focus of the charter.  It is what it = is.

Each change in technology changes the situation for emergency call systems. = It takes away things, and provides new things.  When mobile phones came, = they removed accurate location and substituted inaccurate location in a = totally different, and difficult-for-psap-to-use form.  They even took away = call back number in the case of un-initialized phones. They gave the = possibility of tracking a moving caller, and they gave the ability to get calls = immediately from the scene of common events like car crashes.  On balance, it's = a good thing.

VoIP is the same; some things are being taken away, some things are being = added.  It's different, get over it.

Brian

________________________________________
From: James Winterbottom = [mailto:winterb@nortel.com] =
Sent: Wednesday, August = 03, 2005 5:46 AM
To: Brian Rosen; 'Andrew = Newton'
Cc: = ecrit@ietf.org
Subject: RE: [Ecrit] = some observations from yesterday wg meeting

Bah!!!
The problem must exist = in someone's charter, and GeoPriv don't seem to want it either!
It is not easy, without = having relatively substantial local foot print, to spoof emergency calls with = in the USA = today. In a IP world, that is simply not true any longer with the currently proposed mechanisms of user created location documents, no matter where the = source data came from. That is consumers of location (location recipients LRs) have absolutely NO means of assuring that this correct. The same is = absolutely not true for 99.999% of PSTN calls.

Location is today in the cellular and wireline world is the responsibility of the = access provider, and this will need to remain the responsibility of the access provider in the future until telekenic-osmosis becomes a reality. ECRIT = or GeoPriv pick it up until then, but stop passing the = buck!!!

Cheers
James =

-----Original Message-----
From: = ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]= On Behalf Of Brian Rosen
Sent: Wednesday, 3 = August 2005 7:21 PM
To: 'Andrew Newton' =
Cc: ecrit@ietf.org =
Subject: RE: [Ecrit] = some observations from yesterday wg meeting

But that problem is not in our charter.  If an attacker learned a PSAP's SIP = URI from any mechanism, they can mount an attack. True. =

Not in our charter.
Determining that a = location represents the location of the caller is within charter. =
I believe identity of = caller is NOT a requirement in general, but I think it's clearly not a requirement in = ecrit.
Brian
-----Original = Message-----
From: Andrew Newton [mailto:andy@hxr.us]
Sent: Wednesday, August = 03, 2005 5:07 AM
To: Brian Rosen =
Cc: 'James Seng'; = ecrit@ietf.org
Subject: Re: [Ecrit] = some observations from yesterday wg meeting

On Aug 3, 2005, at 3:23 AM, Brian Rosen wrote:
> This discussion is = more or less out of charter, as the work in ecrit
> addresses the first = point above.
I don't think so.  = I think James has made a fairly important point: 
the notion that L2 = location must be signed can simply be circumvented 
by an attacker = contacting the PSAP's SIP server directly.
-andy =

______________________________________________= _
Ecrit mailing list =
Ecrit@ietf.org =
https://www1.ietf.org/mailman/listinfo/ecrit

------=_NextPart_000_0116_01C59802.F66FB640-- --===============0436222536== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0436222536==-- From ecrit-bounces@ietf.org Wed Aug 03 09:09:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0J00-0008Ry-HT; Wed, 03 Aug 2005 09:09:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Izw-0008Rn-Kz for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 09:09:30 -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 JAA13708 for ; Wed, 3 Aug 2005 09:09:27 -0400 (EDT) Received: from [203.117.75.21] (helo=dev.red-aura.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0JWZ-00089P-NX for ecrit@ietf.org; Wed, 03 Aug 2005 09:43:12 -0400 Received: (qmail 10060 invoked from network); 3 Aug 2005 13:11:31 -0000 Received: from open-27-125.ietf63.ietf.org (HELO ?127.0.0.1?) (jseng@86.255.27.125) by dev.red-aura.com with SMTP; 3 Aug 2005 13:11:30 -0000 Message-ID: <42F0C1EF.9020106@seng.cc> Date: Wed, 03 Aug 2005 21:09:03 +0800 From: James Seng User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Ecrit] some observations from yesterday wg meeting References: <32755D354E6B65498C3BD9FD496C7D4613C084@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C084@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org whats the use of having the technology to reach PSAP if my PSAP dont use the technology? i would argue documenting the PSAP requirements is equally important as documenting the emergency caller requirements (and in certain sense, falls within the charter). james Stastny Richard wrote: > It is even worse. In many countries you still may make emergency calls > from mobile phones without a SIM card. The majority of calls come > on Sunday morning from people buying mobile phones at the flea-markets > using 112 as test-number to check the device. > > You may also reach the PSAPs from some countries (I wiLL > not tell which ;-) via an internatinal number. In most cases your CLI > is not delivered (and definitely not if you make a SkypeOut call) > > So we should try to fix some of the problems existing now, but not > world hunger and save the whales. The important thing is, as Brian > not gets tired to state: > that you reach an PSAP if you need one. > > -richard > > ________________________________ > > Von: ecrit-bounces@ietf.org im Auftrag von Drage, Keith (Keith) > Gesendet: Mi 03.08.2005 11:19 > An: James Seng > Cc: ecrit@ietf.org > Betreff: RE: [Ecrit] some observations from yesterday wg meeting > > > > The issue you raise is not created by IP telephony. > > The problem exists from the start of Pay as you go cellphones. There are now huge numbers of these phones circulating, all capable of making emergency calls, and large numbers of them totally untraceable back to an end user, due to various reasons like the user has moved (innocent) through to the user deliberately wanting a communication device that is untraceable so supplied false details to start off with. > > However, even with this, I do not currently see the anything different from Brian's listed priorities. > > regards > > Keith > > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 > > > >>-----Original Message----- >>From: ecrit-bounces@ietf.org >>[mailto:ecrit-bounces@ietf.org]On Behalf Of >>James Seng >>Sent: 03 August 2005 08:36 >>To: Brian Rosen >>Cc: ecrit@ietf.org >>Subject: Re: [Ecrit] some observations from yesterday wg meeting >> >> >>That may be the American experience but certainly not mine. >> >>-James Seng >> >>On 03 Aug 2005, at 3:23 PM, Brian Rosen wrote: >> >> >>>In North America, the PSAPs tell us that their priorities are to: >>>1. Get the call to the right PSAP >>>2. Get a call back number >>>3. Get the location of the caller >>> >>>To the extent that the current PSTN equates "identity" of the >>>caller with >>>the telephone number, they are getting identity as their >> >>second point. >> >>>This discussion is more or less out of charter, as the work in ecrit >>>addresses the first point above. >>> >>>For ecrit, we did have a discussion on the importance of assuring >>>that the >>>location provided is the actual location of the caller. This is >>>actually >>>the biggest part of addressing prank calls. >>> >>>As I said in the meeting, the PSAPs I know would accept a >> >>call with no >> >>>location, no call back and no identity. They might be VERY >>>suspicious of >>>such a call, but they will take it, and depending on what the >>>caller said, >>>they probably will dispatch someone. At least for the PSAPs I >>>know, while >>>they will demand a lot of effort to make sure location and call >>>back are >>>accurate, they will, in fact, accept a call without it. In that >>>regard, I >>>think they care about the house on fire first, and the identity >>>second. >>> >>>Brian >>> >>>-----Original Message----- >>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>Behalf Of >>>James Seng >>>Sent: Wednesday, August 03, 2005 12:04 AM >>>To: ecrit@ietf.org >>>Subject: [Ecrit] some observations from yesterday wg meeting >>> >>>I am not a regular on this list so whatever I said here is based on >>>what I see at yesterday wg meeting. Pardon me if these already been >>>discussed. >>>1. There are a lot of talks about how caller can authenticate the >>>emergency response centers (singapore term for what WG's >> >>called PSAP) >> >>>but not much talks about how PSAP is going to authenticate the >>>callers. >>> >>>Considering how many prank calls typical PSAP gets, I wont be >>>surprised if their priority is to identify the caller first and less >>>about your house on fire. >>> >>>No I am serious. That's my experience when dealing with them on E911 >>>when we are working on our IP Telephony framework. >>> >>>2. Any bet how long it will take PSAP to install a SIP server into >>>their system? Especially a system which will allow anyone from >>>anywhere in the world to call them anonymously? >>> >>>So while it is important for the caller to be able to identify his >>>nearest PSAP, it is equally important for PSAP to be able to (a) >>>identify the caller and (b) establish that the caller is within the >>>zone they are serving. >>> >>>-James Seng >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >>> >> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 03 09:33:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0JMm-000443-Nt; Wed, 03 Aug 2005 09:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0JMk-00043w-Nt for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 09:33:02 -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 JAA15929 for ; Wed, 3 Aug 2005 09:33:01 -0400 (EDT) Message-Id: <200508031333.JAA15929@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0JtQ-00017v-Mb for ecrit@ietf.org; Wed, 03 Aug 2005 10:06:50 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.51) id 1E0JMZ-0004si-Iq for ecrit@ietf.org; Wed, 03 Aug 2005 08:32:52 -0500 From: "Brian Rosen" To: Date: Wed, 3 Aug 2005 09:32:48 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWYL9bwk6FPcQwMS8iOTOp4rC4n0A== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.1 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Subject: [Ecrit] Does IDN work for the DNS proposal X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1048526903==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1048526903== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0139_01C5980E.530ECC50" This is a multi-part message in MIME format. ------=_NextPart_000_0139_01C5980E.530ECC50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Michael Haberler did a quick pass of finding 8000 Vienna street names, turning them into IDN, and figuring out if they exceed the 64 character per-label limit of DNS. He didn't find any, but came real close (61). It would be very helpful if we did this test with as many areas as possible, especially in the usual-long-name-suspect's cases. As I observed, if the incidence is low enough, a simple, consistently used abbreviation would work. Even truncation may work well enough. Brian ------=_NextPart_000_0139_01C5980E.530ECC50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Michael Haberler did a quick pass of finding = 8000 Vienna = street names, turning them into IDN, and figuring out if they exceed the 64 = character per-label limit of DNS.  He didn’t find any, but came real = close (61). 

 

It would be very helpful if we did this test = with as many areas as possible, especially in the = usual-long-name-suspect’s cases. 

 

As I observed, if the incidence is low = enough, a simple, consistently used abbreviation would work.  Even truncation = may work well enough. 

 

Brian

 

 

 

------=_NextPart_000_0139_01C5980E.530ECC50-- --===============1048526903== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1048526903==-- From ecrit-bounces@ietf.org Wed Aug 03 10:18:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Jzn-0000mO-Gy; Wed, 03 Aug 2005 10:13:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Jzl-0000ln-FB for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 10:13:21 -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 KAA19296 for ; Wed, 3 Aug 2005 10:13:19 -0400 (EDT) Message-Id: <200508031413.KAA19296@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0KWS-00034F-J3 for ecrit@ietf.org; Wed, 03 Aug 2005 10:47:09 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.51) id 1E0Jza-0006o1-KL; Wed, 03 Aug 2005 09:13:11 -0500 From: "Brian Rosen" To: "'McCalmont, Patti'" , Subject: RE: [Ecrit] Does IDN work for the DNS proposal Date: Wed, 3 Aug 2005 10:13:06 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <422D410BD61FC04185076AD99AA7207AFD09E2@inilmx01.lgmt.trdo> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWYL9bwk6FPcQwMS8iOTOp4rC4n0AABC7KQAABNBMA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.2 (/) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0094926344==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0094926344== Content-Type: multipart/alternative; boundary="----=_NextPart_000_014B_01C59813.F37467E0" This is a multi-part message in MIME format. ------=_NextPart_000_014B_01C59813.F37467E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm sure it didn't. Of course, that would be a separate name (field). If someone had access to that data, and could check that field independently for potential problems, that would be helpful. Brian _____ From: McCalmont, Patti [mailto:Patti.McCalmont@intrado.com] Sent: Wednesday, August 03, 2005 10:07 AM To: Brian Rosen; ecrit@ietf.org Subject: RE: [Ecrit] Does IDN work for the DNS proposal Does this data include Apartment Numbers/Suite numbers as this is also critical in validation of location? High rises and apartment complexes for a given street address must be included when determining maximum characters required. Patti McCalmont _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, August 03, 2005 8:33 AM To: ecrit@ietf.org Subject: [Ecrit] Does IDN work for the DNS proposal Michael Haberler did a quick pass of finding 8000 Vienna street names, turning them into IDN, and figuring out if they exceed the 64 character per-label limit of DNS. He didn't find any, but came real close (61). It would be very helpful if we did this test with as many areas as possible, especially in the usual-long-name-suspect's cases. As I observed, if the incidence is low enough, a simple, consistently used abbreviation would work. Even truncation may work well enough. Brian ------=_NextPart_000_014B_01C59813.F37467E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m sure it = didn’t.  Of course, that would be a separate name (field).  If someone had = access to that data, and could check that field independently for potential = problems, that would be helpful.

 

Brian

 

From: = McCalmont, Patti [mailto:Patti.McCalmont@intrado.com]
Sent: Wednesday, August = 03, 2005 10:07 AM
To: Brian Rosen; = ecrit@ietf.org
Subject: RE: [Ecrit] Does = IDN work for the DNS proposal

 

Does this data include Apartment Numbers/Suite numbers as this is also critical in validation of = location? High rises and apartment complexes for a given street address must be = included when determining maximum characters required.

 

Patti = McCalmont

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Wednesday, August = 03, 2005 8:33 AM
To: ecrit@ietf.org
Subject: [Ecrit] Does IDN = work for the DNS proposal

 

Michael Haberler did a quick pass of finding = 8000 Vienna = street names, turning them into IDN, and figuring out if they exceed the 64 = character per-label limit of DNS.  He didn’t find any, but came real = close (61). 

 

It would be very helpful if we did this test = with as many areas as possible, especially in the = usual-long-name-suspect’s cases. 

 

As I observed, if the incidence is low = enough, a simple, consistently used abbreviation would work.  Even truncation = may work well enough. 

 

Brian

 

 

 

------=_NextPart_000_014B_01C59813.F37467E0-- --===============0094926344== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0094926344==-- From ecrit-bounces@ietf.org Wed Aug 03 11:08:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Kqj-0007Ng-No; Wed, 03 Aug 2005 11:08:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0JuC-0007pL-2k for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 10:07: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 KAA18635 for ; Wed, 3 Aug 2005 10:07:34 -0400 (EDT) Received: from ns2.sccx.com ([209.108.197.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0KQt-0002mi-8g for ecrit@ietf.org; Wed, 03 Aug 2005 10:41:23 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Does IDN work for the DNS proposal X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 3 Aug 2005 09:07:09 -0500 Message-ID: <422D410BD61FC04185076AD99AA7207AFD09E2@inilmx01.lgmt.trdo> Thread-Topic: [Ecrit] Does IDN work for the DNS proposal Thread-Index: AcWYL9bwk6FPcQwMS8iOTOp4rC4n0AABC7KQ From: "McCalmont, Patti" To: "Brian Rosen" , X-OriginalArrivalTime: 03 Aug 2005 14:07:11.0392 (UTC) FILETIME=[A467E200:01C59834] X-Spam-Score: 0.2 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 X-Mailman-Approved-At: Wed, 03 Aug 2005 11:08:03 -0400 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1788620935==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1788620935== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59834.A3D1B618" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59834.A3D1B618 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does this data include Apartment Numbers/Suite numbers as this is also critical in validation of location? High rises and apartment complexes for a given street address must be included when determining maximum characters required.=20 =20 Patti McCalmont =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, August 03, 2005 8:33 AM To: ecrit@ietf.org Subject: [Ecrit] Does IDN work for the DNS proposal =20 Michael Haberler did a quick pass of finding 8000 Vienna street names, turning them into IDN, and figuring out if they exceed the 64 character per-label limit of DNS. He didn't find any, but came real close (61). =20 =20 It would be very helpful if we did this test with as many areas as possible, especially in the usual-long-name-suspect's cases. =20 =20 As I observed, if the incidence is low enough, a simple, consistently used abbreviation would work. Even truncation may work well enough. =20 =20 Brian =20 =20 =20 ------_=_NextPart_001_01C59834.A3D1B618 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Does this data include Apartment Numbers/Suite numbers as this is also critical in validation of = location? High rises and apartment complexes for a given street address must be = included when determining maximum characters required.

 

Patti = McCalmont

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Wednesday, August = 03, 2005 8:33 AM
To: ecrit@ietf.org
Subject: [Ecrit] Does IDN = work for the DNS proposal

 

Michael Haberler did a quick pass of finding = 8000 Vienna = street names, turning them into IDN, and figuring out if they exceed the 64 = character per-label limit of DNS.  He didn’t find any, but came real = close (61). 

 

It would be very helpful if we did this test = with as many areas as possible, especially in the = usual-long-name-suspect’s cases. 

 

As I observed, if the incidence is low = enough, a simple, consistently used abbreviation would work.  Even truncation = may work well enough. 

 

Brian

 

 

 

------_=_NextPart_001_01C59834.A3D1B618-- --===============1788620935== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1788620935==-- From ecrit-bounces@ietf.org Wed Aug 03 11:49:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0LV9-0001Va-93; Wed, 03 Aug 2005 11:49:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0LLi-0004rR-Ck for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 11:40:06 -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 LAA26330 for ; Wed, 3 Aug 2005 11:40:04 -0400 (EDT) Received: from sip.mah.priv.at ([81.223.16.194] helo=www.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0LsP-00078y-HD for ecrit@ietf.org; Wed, 03 Aug 2005 12:13:54 -0400 Received: from localhost ([127.0.0.1] helo=mah9.inode.at) by www.mah.priv.at with esmtp (Exim 3.36 #1 (Debian)) id 1E0LLH-0002j9-00; Wed, 03 Aug 2005 17:39:40 +0200 Message-Id: <6.2.1.2.2.20050803173807.054f31a8@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 03 Aug 2005 17:39:38 +0200 To: "McCalmont, Patti" , "Brian Rosen" , From: Michael Haberler Subject: RE: [Ecrit] Does IDN work for the DNS proposal In-Reply-To: <422D410BD61FC04185076AD99AA7207AFD09E2@inilmx01.lgmt.trdo> References: <422D410BD61FC04185076AD99AA7207AFD09E2@inilmx01.lgmt.trdo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-2D4168A X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Wed, 03 Aug 2005 11:49:49 -0400 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org no, it didnt. Strictly street names. See the Excel sheet at http://mah.priv.at/112/vienna-streetnames-idn.xls to get the idea. -Michael At 16:07 03.08.2005, McCalmont, Patti wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; >boundary="----_=_NextPart_001_01C59834.A3D1B618"; x-avg-checked=avg-ok-2D4168A > >Does this data include Apartment Numbers/Suite numbers as this is also >critical in validation of location? High rises and apartment complexes for >a given street address must be included when determining maximum >characters required. > >Patti McCalmont > > >---------- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >Brian Rosen >Sent: Wednesday, August 03, 2005 8:33 AM >To: ecrit@ietf.org >Subject: [Ecrit] Does IDN work for the DNS proposal > >Michael Haberler did a quick pass of finding 8000 Vienna street names, >turning them into IDN, and figuring out if they exceed the 64 character >per-label limit of DNS. He didn't find any, but came real close (61). > >It would be very helpful if we did this test with as many areas as >possible, especially in the usual-long-name-suspect's cases. > >As I observed, if the incidence is low enough, a simple, consistently used >abbreviation would work. Even truncation may work well enough. > >Brian > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 03 19:06:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0SJi-0002wo-9A; Wed, 03 Aug 2005 19:06:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0SJg-0002wj-ET for ecrit@megatron.ietf.org; Wed, 03 Aug 2005 19:06:28 -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 TAA25265 for ; Wed, 3 Aug 2005 19:06:24 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0SqQ-0000tb-B4 for ecrit@ietf.org; Wed, 03 Aug 2005 19:40:20 -0400 Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com [47.153.200.67]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j73N60h24871; Wed, 3 Aug 2005 18:06:00 -0500 (CDT) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Aug 2005 09:04:40 +1000 Message-ID: From: "James Winterbottom" To: Brian Rosen , "'Andrew Newton'" Subject: RE: [Ecrit] some observations from yesterday wg meeting Date: Thu, 4 Aug 2005 09:04:39 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.7 (/) X-Scan-Signature: 2ed9477f79f24ff120e9894ad9dc9cb5 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0005483141==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0005483141== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5987F.B9B61F5A" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5987F.B9B61F5A Content-Type: text/plain I agree Brian. Andy, is this something that we can have explicitly added to the charter please? -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, 3 August 2005 10:12 PM To: Winterbottom, James [WOLL:5500:EXCH]; 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] some observations from yesterday wg meeting I think that we should provide some mechanisms to foster integrity and authentication of source of location. I think that such mechanisms should be widely deployed. I believe there are use cases where such information is useful. I think ONE of those use cases is emergency calls. I think it is not possible to provide assurances that are equivalent to current wireline location for emergency calls. I think location integrity and source authentication is work in geopriv, and not ecrit. Brian _____ From: James Winterbottom [mailto:winterb@nortel.com] Sent: Wednesday, August 03, 2005 6:31 AM To: Brian Rosen; 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] some observations from yesterday wg meeting Brian, Let me make sure that I have a clear understanding of your point here. I as a recipient of location information, that provide a service in good faith, have no right or come back, if the location provided to me is incorrect? Please explain to me how this is a step in a positive direction, and how this will bolster adoption of IP telephony? I think that people will accept "near-equivalency", but that they will not accept out and out lack of equivalent service. Cheers James -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net ] Sent: Wednesday, 3 August 2005 8:10 PM To: Winterbottom, James [WOLL:5500:EXCH]; 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] some observations from yesterday wg meeting Chairs? I was not a fan of the narrow focus of the charter. It is what it is. Each change in technology changes the situation for emergency call systems. It takes away things, and provides new things. When mobile phones came, they removed accurate location and substituted inaccurate location in a totally different, and difficult-for-psap-to-use form. They even took away call back number in the case of un-initialized phones. They gave the possibility of tracking a moving caller, and they gave the ability to get calls immediately from the scene of common events like car crashes. On balance, it's a good thing. VoIP is the same; some things are being taken away, some things are being added. It's different, get over it. Brian ________________________________________ From: James Winterbottom [mailto:winterb@nortel.com ] Sent: Wednesday, August 03, 2005 5:46 AM To: Brian Rosen; 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] some observations from yesterday wg meeting Bah!!! The problem must exist in someone's charter, and GeoPriv don't seem to want it either! It is not easy, without having relatively substantial local foot print, to spoof emergency calls with in the USA today. In a IP world, that is simply not true any longer with the currently proposed mechanisms of user created location documents, no matter where the source data came from. That is consumers of location (location recipients LRs) have absolutely NO means of assuring that this correct. The same is absolutely not true for 99.999% of PSTN calls. Location is today in the cellular and wireline world is the responsibility of the access provider, and this will need to remain the responsibility of the access provider in the future until telekenic-osmosis becomes a reality. ECRIT or GeoPriv pick it up until then, but stop passing the buck!!! Cheers James -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org ] On Behalf Of Brian Rosen Sent: Wednesday, 3 August 2005 7:21 PM To: 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] some observations from yesterday wg meeting But that problem is not in our charter. If an attacker learned a PSAP's SIP URI from any mechanism, they can mount an attack. True. Not in our charter. Determining that a location represents the location of the caller is within charter. I believe identity of caller is NOT a requirement in general, but I think it's clearly not a requirement in ecrit. Brian -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us ] Sent: Wednesday, August 03, 2005 5:07 AM To: Brian Rosen Cc: 'James Seng'; ecrit@ietf.org Subject: Re: [Ecrit] some observations from yesterday wg meeting On Aug 3, 2005, at 3:23 AM, Brian Rosen wrote: > This discussion is more or less out of charter, as the work in ecrit > addresses the first point above. I don't think so. I think James has made a fairly important point: the notion that L2 location must be signed can simply be circumvented by an attacker contacting the PSAP's SIP server directly. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C5987F.B9B61F5A Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
I=20 agree Brian.
 
Andy,=20 is this something that we can have explicitly added to the charter=20 please?
 
-----Original Message-----
From: = Brian Rosen=20 [mailto:br@brianrosen.net]
Sent: Wednesday, 3 August 2005 = 10:12=20 PM
To: Winterbottom, James [WOLL:5500:EXCH]; 'Andrew=20 Newton'
Cc: ecrit@ietf.org
Subject: RE: [Ecrit] = some=20 observations from yesterday wg meeting

I think = that we=20 should provide some mechanisms to foster integrity and authentication = of=20 source of location.  I think that such mechanisms should be = widely=20 deployed.  I believe there are use cases where such information = is=20 useful.  I think ONE of those use cases is emergency = calls.  I think=20 it is not possible to provide assurances that are equivalent to = current=20 wireline location for emergency calls.  I think location = integrity and=20 source authentication is work in geopriv, and not=20 ecrit.

 

Brian

 

From: James=20 Winterbottom [mailto:winterb@nortel.com]
Sent: Wednesday, August 03, = 2005 6:31=20 AM
To: Brian = Rosen; 'Andrew=20 Newton'
Cc:=20 ecrit@ietf.org
Subject: RE:=20 [Ecrit] some observations from yesterday wg=20 meeting

 

Brian,

Let me=20 make sure that I have a clear understanding of your point = here.=20
I as a recipient = of location=20 information, that provide a service in good faith, have no right or = come back,=20 if the location provided to me is incorrect? =

Please=20 explain to me how this is a step in a positive direction, and how = this will=20 bolster adoption of IP telephony?

I think=20 that people will accept "near-equivalency", but that they will not = accept out=20 and out lack of equivalent service.

Cheers
James

 

-----Original Message----- =
From: Brian Rosen [mailto:br@brianrosen.net]=20
Sent: Wednesday,=20 3 August 2005 8:10 PM
To: Winterbottom, James [WOLL:5500:EXCH]; = 'Andrew=20 Newton'
Cc:=20 ecrit@ietf.org
Subject: RE: [Ecrit] some observations from = yesterday=20 wg meeting

 

Chairs?

I was not=20 a fan of the narrow focus of the charter.  It is what it=20 is.

Each=20 change in technology changes the situation for emergency call = systems. It=20 takes away things, and provides new things.  When mobile phones = came,=20 they removed accurate location and substituted inaccurate location in = a=20 totally different, and difficult-for-psap-to-use form.  They = even took=20 away call back number in the case of un-initialized phones. They gave = the=20 possibility of tracking a moving caller, and they gave the ability to = get=20 calls immediately from the scene of common events like car = crashes.  On=20 balance, it's a good thing.

VoIP is=20 the same; some things are being taken away, some things are being = added. =20 It's different, get over it.

Brian

________________________________________=20
From: James = Winterbottom [mailto:winterb@nortel.com]=20
Sent: Wednesday,=20 August 03, 2005 5:46 AM
To: Brian Rosen; 'Andrew = Newton'=20
Cc:=20 ecrit@ietf.org
Subject: RE: [Ecrit] some observations from = yesterday=20 wg meeting

Bah!!!=20
The = problem must=20 exist in someone's charter, and GeoPriv don't seem to want it either! =
It = is not easy,=20 without having relatively substantial local foot print, to spoof = emergency=20 calls with in the USA today. In a IP = world, that is=20 simply not true any longer with the currently proposed mechanisms of = user=20 created location documents, no matter where the source data came = from. That is=20 consumers of location (location recipients LRs) have absolutely NO = means of=20 assuring that this correct. The same is absolutely not true for = 99.999% of=20 PSTN calls.

Location=20 is today in the cellular and wireline world is the responsibility of = the=20 access provider, and this will need to remain the responsibility of = the access=20 provider in the future until telekenic-osmosis becomes a reality. = ECRIT or=20 GeoPriv pick it up until then, but stop passing the=20 buck!!!

Cheers=20
James=20

-----Original Message----- =
From: ecrit-bounces@ietf.org = [mailto:ecrit-bounces@ietf.org= ] On=20 Behalf Of Brian Rosen
Sent: Wednesday, 3 August 2005 7:21 PM=20
To: = 'Andrew=20 Newton'
Cc:=20 ecrit@ietf.org
Subject: RE: [Ecrit] some observations from = yesterday=20 wg meeting

But that=20 problem is not in our charter.  If an attacker learned a PSAP's = SIP URI=20 from any mechanism, they can mount an attack. True.=20

Not in=20 our charter.
Determining that a location represents the = location of=20 the caller is within charter.
I believe identity of caller is NOT a = requirement in=20 general, but I think it's clearly not a requirement in ecrit.=20
Brian=20
-----Original=20 Message-----
From: Andrew Newton [mailto:andy@hxr.us] =
Sent: Wednesday, August 03, = 2005 5:07 AM=20
To: = Brian Rosen=20
Cc: = 'James Seng';=20 ecrit@ietf.org
Subject: Re: [Ecrit] some observations from = yesterday=20 wg meeting

On Aug 3,=20 2005, at 3:23 AM, Brian Rosen wrote:
> This discussion is more or less out of = charter,=20 as the work in ecrit
> addresses the first point above.=20
I = don't think=20 so.  I think James has made a fairly important point: =20
the = notion that=20 L2 location must be signed can simply be circumvented =20
by = an attacker=20 contacting the PSAP's SIP server directly.
-andy =

_______________________________________________=20
Ecrit mailing=20 list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit=20

------_=_NextPart_001_01C5987F.B9B61F5A-- --===============0005483141== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0005483141==-- From ecrit-bounces@ietf.org Thu Aug 04 02:51:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ZZs-0006TB-O9; Thu, 04 Aug 2005 02:51:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ZZp-0006T0-E9 for ecrit@megatron.ietf.org; Thu, 04 Aug 2005 02:51:38 -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 CAA04950 for ; Thu, 4 Aug 2005 02:51:36 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0a6f-0008St-E0 for ecrit@ietf.org; Thu, 04 Aug 2005 03:25:33 -0400 Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com [47.153.200.67]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j746o8I19304; Thu, 4 Aug 2005 01:50:08 -0500 (CDT) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Aug 2005 16:49:03 +1000 Message-ID: From: "Martin Thomson" To: "'Marc Linsner'" , "'Andrew Newton'" Subject: RE: [Ecrit] some observations from yesterday wg meeting Date: Thu, 4 Aug 2005 16:49:03 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1534625648==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1534625648== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C598C0.986E6884" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C598C0.986E6884 Content-Type: text/plain The question has been asked: should we help? I think we can if we so choose and I would suggest that we should try. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Wednesday, 3 August 2005 12:21 PM To: 'Andrew Newton'; 'Brian Rosen' Cc: ecrit@ietf.org Subject: RE: [Ecrit] some observations from yesterday wg meeting Certainly a PSAP needs to take measures to protect themselves from the evil on the Internet. This is no different than any other entity. -Marc- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Andrew Newton > Sent: Wednesday, August 03, 2005 5:29 AM > To: Brian Rosen > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] some observations from yesterday wg meeting > > > On Aug 3, 2005, at 5:20 AM, Brian Rosen wrote: > > > Determining that a location represents the location of the > caller is > > within charter. > > I don't think this is explicitly in the charter either. The > charter talks about how to use location, but says nothing > about verifying location. > > The charter aside, if we create the most super,duper concrete > security mechanism and validation on location, what James is > suggesting is that an attacker can just side step that and > communicate directly with the PSAP's SIP server. > > -andy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C598C0.986E6884 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Ecrit] some observations from yesterday wg meeting

The question has been asked: should we help?  I = think we can if we so choose and I would suggest that we should = try.

-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf Of Marc Linsner
Sent: Wednesday, 3 August 2005 12:21 PM
To: 'Andrew Newton'; 'Brian Rosen'
Cc: ecrit@ietf.org
Subject: RE: [Ecrit] some observations from = yesterday wg meeting


Certainly a PSAP needs to take measures to protect = themselves from the evil on the Internet.  This is no different = than any other entity.

-Marc-



> -----Original Message-----
> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ]
> On Behalf Of Andrew Newton
> Sent: Wednesday, August 03, 2005 5:29 AM
> To: Brian Rosen
> Cc: ecrit@ietf.org
> Subject: Re: [Ecrit] some observations from = yesterday wg meeting
>
>
> On Aug 3, 2005, at 5:20 AM, Brian Rosen = wrote:
>
> > Determining that a location represents the = location of the
> caller is
> > within charter.
>
> I don't think this is explicitly in the charter = either.  The
> charter talks about how to use location, but = says nothing
> about verifying location.
>
> The charter aside, if we create the most = super,duper concrete
> security mechanism and validation on location, = what James is
> suggesting is that an attacker can just side = step that and
> communicate directly with the PSAP's SIP = server.
>
> -andy
>
> = _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

------_=_NextPart_001_01C598C0.986E6884-- --===============1534625648== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1534625648==-- From ecrit-bounces@ietf.org Thu Aug 04 04:39:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bFv-0005nm-Jf; Thu, 04 Aug 2005 04:39:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bFt-0005mX-9A for ecrit@megatron.ietf.org; Thu, 04 Aug 2005 04:39:09 -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 EAA12330 for ; Thu, 4 Aug 2005 04:39:07 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0bmj-0005R1-8s for ecrit@ietf.org; Thu, 04 Aug 2005 05:13:06 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 Aug 2005 01:38:58 -0700 X-IronPort-AV: i="3.95,166,1120460400"; d="scan'208"; a="328882652:sNHT31604340" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j748cuoo003901; Thu, 4 Aug 2005 01:38:56 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 01:38:56 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.132]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 01:38:55 -0700 Message-Id: <4.3.2.7.2.20050803114522.0327bf08@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Aug 2005 03:38:53 -0500 To: "James Winterbottom" From: "James M. Polk" Subject: RE: [Ecrit] some observations from yesterday wg meeting In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 04 Aug 2005 08:38:55.0552 (UTC) FILETIME=[F32EF400:01C598CF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 07:45 PM 8/3/2005 +1000, James Winterbottom wrote: >The problem must exist in someone's charter, and GeoPriv don't seem to >want it either! >Location is today in the cellular and wireline world is the responsibility >of the access provider, and this will need to remain the responsibility of >the access provider in the future until telekenic-osmosis becomes a >reality. ECRIT or GeoPriv pick it up until then, but stop passing the buck!!! James - not every problem has a charter in the IETF. The Geopriv charter is addressing Location delivery with Privacy Considerations - there is nothing about certifying the location is correct in that charter. In fact, per RFC3693 (Geopriv's base requirements doc), the location provided can be quite imprecise on purpose. The ECRIT charter is narrowly focused on identification of emergency calls and routing of those calls to the correct PSAP of the location provided. I continue to argue validating location is outside the IETF's scope, much less ECRIT's charter. None of the above says validating location is a bad idea, BTW. >Cheers >James > > >-----Original Message----- >From: ecrit-bounces@ietf.org >[mailto:ecrit-bounces@ietf.org] On Behalf >Of Brian Rosen >Sent: Wednesday, 3 August 2005 7:21 PM >To: 'Andrew Newton' >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] some observations from yesterday wg meeting > >But that problem is not in our charter. If an attacker learned a PSAP's >SIP URI from any mechanism, they can mount an attack. > >True. > >Not in our charter. > >Determining that a location represents the location of the caller is >within charter. > >I believe identity of caller is NOT a requirement in general, but I think >it's clearly not a requirement in ecrit. > >Brian > >-----Original Message----- >From: Andrew Newton [mailto:andy@hxr.us] >Sent: Wednesday, August 03, 2005 5:07 AM >To: Brian Rosen >Cc: 'James Seng'; ecrit@ietf.org >Subject: Re: [Ecrit] some observations from yesterday wg meeting > >On Aug 3, 2005, at 3:23 AM, Brian Rosen wrote: > > > This discussion is more or less out of charter, as the work in ecrit > > addresses the first point above. > >I don't think so. I think James has made a fairly important point: >the notion that L2 location must be signed can simply be circumvented >by an attacker contacting the PSAP's SIP server directly. > >-andy > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Aug 04 04:53:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bTM-0001KQ-Sm; Thu, 04 Aug 2005 04:53:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bTL-0001KI-0l for ecrit@megatron.ietf.org; Thu, 04 Aug 2005 04:53:03 -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 EAA13175 for ; Thu, 4 Aug 2005 04:53:00 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0c0A-00065e-ML for ecrit@ietf.org; Thu, 04 Aug 2005 05:27:00 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 04 Aug 2005 01:52:52 -0700 X-IronPort-AV: i="3.95,166,1120460400"; d="scan'208,217"; a="328887599:sNHT42565988" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j748qiQM009899; Thu, 4 Aug 2005 01:52:45 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 01:52:49 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 01:52:48 -0700 From: "Marc Linsner" To: "'Martin Thomson'" , "'Andrew Newton'" Subject: RE: [Ecrit] some observations from yesterday wg meeting Date: Thu, 4 Aug 2005 04:52:48 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWYwPWBf/QABNymS4ycv3GyId7clgAD/KTA Message-ID: X-OriginalArrivalTime: 04 Aug 2005 08:52:48.0994 (UTC) FILETIME=[E3F41C20:01C598D1] X-Spam-Score: 2.0 (++) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0236249504==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0236249504== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0246_01C598B0.5DFFABF0" This is a multi-part message in MIME format. ------=_NextPart_000_0246_01C598B0.5DFFABF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I do believe we can create tools to assist the PSAP, what I don't believe is that we can guarantee to the PSAP community nirvana. -Marc- _____ From: Martin Thomson [mailto:martin.thomson@nortel.com] Sent: Thursday, August 04, 2005 2:49 AM To: 'Marc Linsner'; 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] some observations from yesterday wg meeting The question has been asked: should we help? I think we can if we so choose and I would suggest that we should try. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Wednesday, 3 August 2005 12:21 PM To: 'Andrew Newton'; 'Brian Rosen' Cc: ecrit@ietf.org Subject: RE: [Ecrit] some observations from yesterday wg meeting Certainly a PSAP needs to take measures to protect themselves from the evil on the Internet. This is no different than any other entity. -Marc- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Andrew Newton > Sent: Wednesday, August 03, 2005 5:29 AM > To: Brian Rosen > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] some observations from yesterday wg meeting > > > On Aug 3, 2005, at 5:20 AM, Brian Rosen wrote: > > > Determining that a location represents the location of the > caller is > > within charter. > > I don't think this is explicitly in the charter either. The > charter talks about how to use location, but says nothing > about verifying location. > > The charter aside, if we create the most super,duper concrete > security mechanism and validation on location, what James is > suggesting is that an attacker can just side step that and > communicate directly with the PSAP's SIP server. > > -andy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------=_NextPart_000_0246_01C598B0.5DFFABF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Ecrit] some observations from yesterday wg = meeting
I do believe we can create tools to assist the = PSAP, what I=20 don't  believe is that we can guarantee to the PSAP community=20 nirvana.
 
-Marc-

From: Martin Thomson=20 [mailto:martin.thomson@nortel.com]
Sent: Thursday, August = 04, 2005=20 2:49 AM
To: 'Marc Linsner'; 'Andrew Newton'
Cc:=20 ecrit@ietf.org
Subject: RE: [Ecrit] some observations from = yesterday=20 wg meeting

The question has been asked: should we help?  I = think we=20 can if we so choose and I would suggest that we should try. =

-----Original Message-----
From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]= On=20 Behalf Of Marc Linsner
Sent: Wednesday, 3 = August 2005=20 12:21 PM
To: 'Andrew Newton'; 'Brian = Rosen'=20
Cc: ecrit@ietf.org
Subject: RE:=20 [Ecrit] some observations from yesterday wg meeting


Certainly a PSAP needs to take measures to protect = themselves=20 from the evil on the Internet.  This is no different than any = other=20 entity.

-Marc-



> -----Original Message-----
>=20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]= =20
> On Behalf Of Andrew Newton
>=20 Sent: Wednesday, August 03, 2005 5:29 AM
> To:=20 Brian Rosen
> Cc: ecrit@ietf.org =
> Subject: Re: [Ecrit] some observations from yesterday wg = meeting
>
>=20
> On Aug 3, 2005, at 5:20 AM, Brian Rosen = wrote:
>
> = >=20 Determining that a location represents the location of the =
> caller is
> > within = charter.=20
>
> I don't think = this is=20 explicitly in the charter either.  The
>=20 charter talks about how to use location, but says nothing =
> about verifying location.
> =
> The charter aside, if we create the = most=20 super,duper concrete
> security mechanism = and=20 validation on location, what James is
> = suggesting=20 is that an attacker can just side step that and
>=20 communicate directly with the PSAP's SIP server.
>=20
> -andy
>=20
>=20 _______________________________________________
>=20 Ecrit mailing list
> = Ecrit@ietf.org=20
> https://www1.ietf.org/mailman/listinfo/ecrit =

_______________________________________________=20
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit=20

------=_NextPart_000_0246_01C598B0.5DFFABF0-- --===============0236249504== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0236249504==-- From ecrit-bounces@ietf.org Fri Aug 05 03:24:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0wZX-0001bE-AX; Fri, 05 Aug 2005 03:24:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0wZW-0001b6-83 for ecrit@megatron.ietf.org; Fri, 05 Aug 2005 03:24:50 -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 DAA21913 for ; Fri, 5 Aug 2005 03:24:48 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0x6Y-0005Vb-80 for ecrit@ietf.org; Fri, 05 Aug 2005 03:58:59 -0400 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j757Oksw005590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 5 Aug 2005 03:24:46 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j757Ojiu001227 for ; Fri, 5 Aug 2005 03:24:45 -0400 Message-ID: <42F31446.4080704@cs.columbia.edu> Date: Fri, 05 Aug 2005 03:24:54 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 3.5 (+++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Ecrit] Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org is the longest known locality name (http://teachingtreasures.com.au/student-projects/Llanfair.htm), at 60 characters. Google for "longest street name" yields something like http://www.tolc.org/gintas.htm (Rancho de los Penasquitos Boulevard). Rather than search the world for long names, another suggestion: just hash the city/street name and store the (MD5) hash, at a fixed length of 32 hex characters. This avoids the potential problems with truncation or abbreviation. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Aug 05 11:12:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E13rx-0007SQ-KB; Fri, 05 Aug 2005 11:12:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E13rw-0007Rp-N1 for ecrit@megatron.ietf.org; Fri, 05 Aug 2005 11:12:20 -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 LAA15867 for ; Fri, 5 Aug 2005 11:12:18 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E14P2-0001l3-Uq for ecrit@ietf.org; Fri, 05 Aug 2005 11:46:34 -0400 Received: from [83.145.64.147] ([::ffff:83.145.64.147]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 05 Aug 2005 11:12:15 -0400 id 00160362.42F381CF.00000547 Mime-Version: 1.0 (Apple Message framework v733) Content-Transfer-Encoding: 7bit Message-Id: <38A9BCD8-3137-4A6B-B4CB-72A5F0D51D27@hxr.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Andrew Newton Date: Fri, 5 Aug 2005 11:12:12 -0400 X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [Ecrit] comments on ECRIT requirements X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Here are some comments on the ECRIT requirements document: R1. This requirement seems to be saying that an ASP is not required, but the motivation goes on to explain that ASP is just not a traditional ASP, not that they do not run the application. A6. What is the purpose of this requirement? L6. I think the following should be added: Validation of civic addresses MUST NOT be required to enable any feature that is part of the emergency call process. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Aug 05 13:13:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E15lf-0002vu-Ko; Fri, 05 Aug 2005 13:13:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E15ld-0002vo-IG for ecrit@megatron.ietf.org; Fri, 05 Aug 2005 13:13:57 -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 NAA20831 for ; Fri, 5 Aug 2005 13:13:50 -0400 (EDT) Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E16Ig-0004zp-PE for ecrit@ietf.org; Fri, 05 Aug 2005 13:48:07 -0400 Received: from rrc-its-ieg02.cc.telcordia.com (rrc-its-ieg02.cc.telcordia.com [128.96.109.3]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j75HDbB08180 for ; Fri, 5 Aug 2005 13:13:38 -0400 (EDT) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-its-ieg02.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005080513133313795 for ; Fri, 05 Aug 2005 13:13:33 -0400 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Aug 2005 13:09:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] comments on ECRIT requirements Date: Fri, 5 Aug 2005 13:09:13 -0400 Message-ID: Thread-Topic: [Ecrit] comments on ECRIT requirements Thread-Index: AcWZz8FXRd4EJeWnRjegB9nWNgJ/bgAD8Q9g From: "Abbott, Nadine B" To: "ECRIT" X-OriginalArrivalTime: 05 Aug 2005 17:09:21.0439 (UTC) FILETIME=[6C0C32F0:01C599E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Andy, I'm not sure of the purpose for your addition to requirement L6? The purpose of location validation of civic addresses before they are used in a call origination is to ensure that the address will result in successful routing/mapping if used during an emergency call, and to avoid the necessity for default routing and associated delays, if at all possible. This would seem to me to be a "required feature that is part of the emergency call process" (although I think there is agreement that it should precede any actual emergency call processing)? Thanks, Nadine -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Andrew Newton Sent: Friday, August 05, 2005 11:12 AM To: ECRIT Subject: [Ecrit] comments on ECRIT requirements Here are some comments on the ECRIT requirements document: R1. This requirement seems to be saying that an ASP is not required, =20 but the motivation goes on to explain that ASP is just not a =20 traditional ASP, not that they do not run the application. A6. What is the purpose of this requirement? L6. I think the following should be added: Validation of civic =20 addresses MUST NOT be required to enable any feature that is part of =20 the emergency call process. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Aug 05 18:06:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1AKz-0001PW-ER; Fri, 05 Aug 2005 18:06:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1AKx-0001PR-V2 for ecrit@megatron.ietf.org; Fri, 05 Aug 2005 18:06:44 -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 SAA06321 for ; Fri, 5 Aug 2005 18:06:41 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1As7-0004lK-QA for ecrit@ietf.org; Fri, 05 Aug 2005 18:41:01 -0400 Received: from [83.145.64.148] ([::ffff:83.145.64.148]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 05 Aug 2005 18:06:37 -0400 id 001603C6.42F3E2EE.00004FAE In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65C00834-D1CB-47FD-9AA1-5B12E7666FD1@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] comments on ECRIT requirements Date: Fri, 5 Aug 2005 18:06:33 -0400 To: "Abbott, Nadine B" X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Aug 5, 2005, at 1:09 PM, Abbott, Nadine B wrote: > Andy, > > I'm not sure of the purpose for your addition to requirement L6? > The purpose of location validation of civic addresses before they are > used in a call origination is to ensure that the address will > result in > successful routing/mapping if used during an emergency call, and to > avoid the necessity for default routing and associated delays, if > at all > possible. > This would seem to me to be a "required feature that is part of the > emergency call process" (although I think there is agreement that it > should precede any actual emergency call processing)? Nadine, You have identified three items: 1) ensure that the address will result in successful routing/mapping if used during an emergency call. Since this is not done during the emergency call, it would not be covered and is not part of the emergency call process. 2) avoid the necessity for default routing Determining that a call from a location does not need to resort to default routing also does not seem to be covered as this is not part of the emergency call process, or at least does not have to be part of the emergency call process. 3) avoid associated delays This would be covered as it seems to be a performance issue, which we only care about during the emergency call process. A system designed only to avoid delays if validation has been conducted penalizes the areas of the world where validation does not occur. It also has the undesired effect of requiring re-validation when parts of the system are reinitialized for other reasons. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Aug 06 03:05:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Ikp-0003xW-Jv; Sat, 06 Aug 2005 03:05:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Ikn-0003xR-RV for ecrit@megatron.ietf.org; Sat, 06 Aug 2005 03:05:58 -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 DAA09776 for ; Sat, 6 Aug 2005 03:05:56 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1JI3-0007D3-47 for ecrit@ietf.org; Sat, 06 Aug 2005 03:40:19 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Sat, 6 Aug 2005 03:05:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] comments on ECRIT requirements Date: Sat, 6 Aug 2005 00:05:13 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657502D927C4@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] comments on ECRIT requirements Thread-Index: AcWZz8FXRd4EJeWnRjegB9nWNgJ/bgAD8Q9gAAEkfAA= From: "Roger Marshall" To: "Abbott, Nadine B" , "Andrew Newton" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Comments to R1: I see the point that Andy is making. Based on the input, I've attempted a rewrite of the motivation section to R1, yet with some questions still of how this (autonomous case) would actually work. We should explore the boundaries of this case. R1. Application Service Provider: The existence of a =20 Application Service Provider (ASP) MUST NOT be assumed. Motivation: The caller may not have a voice service=20 Provider in the traditional sense, i.e., a corporate entity that provides voice services as a Business, or may not have any separable voice service provider at all. Examples of these include, a residence having its own DNS domain and running its own SIP proxy server for that domain, a large University which may provide voice services to its students and staff,=20 (yet still not be known as a telecommunication provider), or a individual device may operate autonomously, without any additioanl reliance on external entities, other than for the transport of individual data packets. Comments to A6: I think we all have a sense of what backward-compatibility means, which (at least to me) would equate to the idea that whatever protocol that ecrit comes up with for emergency routing, that it'll work for legacy (pre-ecrit) handsets. Perhaps a simpler, alternate wording is in order, such as: A6. Backward-compatible:"> Emergency routing protocols and functions MUST be backward-compatible for use with existing devices. Comments to L6: I agree with the idea that there should be no pre-ordered requirement that a "valid address" should be required, since we're talking about more than just North America, and more than just civic addresses. I would propose adding a separate requirement for this one. LX. Validation of civic addresses MUST NOT be required to enable any feature that is part of the emergency call process. Motivation: Emergency routing protocols must take into account location based on a variety of forms and formats, (e.g. civic address, MSAG, USPS, lat/lon, etc.) and be able to perform adequate PSAP routing for the context in which the call is initiated. Roger Marshall -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Abbott, Nadine B Sent: Friday, August 05, 2005 10:09 AM To: ECRIT Subject: RE: [Ecrit] comments on ECRIT requirements Andy, I'm not sure of the purpose for your addition to requirement L6? The purpose of location validation of civic addresses before they are used in a call origination is to ensure that the address will result in successful routing/mapping if used during an emergency call, and to avoid the necessity for default routing and associated delays, if at all possible. This would seem to me to be a "required feature that is part of the emergency call process" (although I think there is agreement that it should precede any actual emergency call processing)? Thanks, Nadine -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Andrew Newton Sent: Friday, August 05, 2005 11:12 AM To: ECRIT Subject: [Ecrit] comments on ECRIT requirements Here are some comments on the ECRIT requirements document: R1. This requirement seems to be saying that an ASP is not required, =20 but the motivation goes on to explain that ASP is just not a =20 traditional ASP, not that they do not run the application. A6. What is the purpose of this requirement? L6. I think the following should be added: Validation of civic =20 addresses MUST NOT be required to enable any feature that is part of =20 the emergency call process. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Aug 06 03:34:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1JCP-0000pP-IM; Sat, 06 Aug 2005 03:34:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1JCO-0000pK-A8 for ecrit@megatron.ietf.org; Sat, 06 Aug 2005 03:34:28 -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 DAA10622 for ; Sat, 6 Aug 2005 03:34:26 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1Jjd-0007vq-2z for ecrit@ietf.org; Sat, 06 Aug 2005 04:08:50 -0400 Received: from [83.145.64.150] ([::ffff:83.145.64.150]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Sat, 06 Aug 2005 03:34:23 -0400 id 001603CC.42F467FF.00001DA6 In-Reply-To: <8C837214C95C864C9F34F3635C2A657502D927C4@SEA-EXCHVS-2.telecomsys.com> References: <8C837214C95C864C9F34F3635C2A657502D927C4@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] comments on ECRIT requirements Date: Sat, 6 Aug 2005 03:34:21 -0400 To: Roger Marshall X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Roger, Thanks for doing the hard work. My comments are in-line: On Aug 6, 2005, at 3:05 AM, Roger Marshall wrote: > R1. Application Service Provider: The existence of a > Application Service Provider (ASP) MUST NOT be assumed. > > Motivation: The caller may not have a voice service > Provider in the traditional sense, i.e., a corporate entity that > provides voice services as a Business, or may not have any separable > voice service provider at all. Examples of these include, a residence > having its own DNS domain and running its own SIP proxy server for > that > domain, a large University which may provide voice services to its > students and staff, > (yet still not be known as a telecommunication provider), or a > individual device may operate autonomously, without any additioanl > reliance on external entities, other than for the transport of > individual data packets. This works for me. Thanks. > > Comments to A6: I think we all have a sense of what > backward-compatibility means, which (at least to me) would equate > to the > idea that whatever protocol that ecrit comes up with for emergency > routing, that it'll work for legacy (pre-ecrit) handsets. > > Perhaps a simpler, alternate wording is in order, such as: > > A6. Backward-compatible:"> Emergency routing protocols and functions > MUST be backward-compatible for use with existing devices. I still do not understand this requirement. If this working group creates a method for emergency call routing that does not already exist, which is the purpose of this group, then by definition it will not be backwards compatible with existing devices. When I read this requirement, to me it indicates that we either are not producing a new standards track document or we should close down the working group. Perhaps there needs to be more definition with regard to the meaning of "backward-compatible". > Comments to L6: I agree with the idea that there should be no > pre-ordered requirement that a "valid address" should be required, > since > we're talking about more than just North America, and more than just > civic addresses. I would propose adding a separate requirement for > this > one. > > LX. Validation of civic addresses MUST NOT be required to enable any > feature that is part of the emergency call process. > > Motivation: Emergency routing protocols must take into account > location > based on a variety of forms and formats, (e.g. civic address, MSAG, > USPS, lat/lon, etc.) and be able to perform adequate PSAP routing for > the context in which the call is initiated. I'm fine with this too. Again, thanks Roger for doing the hard work. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Aug 06 05:37:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1L6y-0003Tp-If; Sat, 06 Aug 2005 05:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1L6v-0003Th-W0 for ecrit@megatron.ietf.org; Sat, 06 Aug 2005 05:36:58 -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 FAA14156 for ; Sat, 6 Aug 2005 05:36:55 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1LeC-0001q4-N6 for ecrit@ietf.org; Sat, 06 Aug 2005 06:11:21 -0400 Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com [47.153.200.67]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j769aYV11563; Sat, 6 Aug 2005 04:36:34 -0500 (CDT) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 6 Aug 2005 19:36:33 +1000 Message-ID: From: "James Winterbottom" To: "Abbott, Nadine B" , ECRIT Subject: RE: [Ecrit] comments on ECRIT requirements Date: Sat, 6 Aug 2005 19:36:32 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0610199608==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0610199608== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59A6A.545FAA76" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C59A6A.545FAA76 Content-Type: text/plain Hi Nadine, This is another of the requirements that I think bridges the boundary between GeoPriv and ECRIT, and is, in my opinion anyway, in the same ilk as location dependability. It seems that the are charter for ECRIT is strictly routing, probably reasonable if a conclusion is to be reached, but I think that the Geopriv charter needs to be revised to include location dependability, and location validation. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Abbott, Nadine B Sent: Saturday, 6 August 2005 3:09 AM To: ECRIT Subject: RE: [Ecrit] comments on ECRIT requirements Andy, I'm not sure of the purpose for your addition to requirement L6? The purpose of location validation of civic addresses before they are used in a call origination is to ensure that the address will result in successful routing/mapping if used during an emergency call, and to avoid the necessity for default routing and associated delays, if at all possible. This would seem to me to be a "required feature that is part of the emergency call process" (although I think there is agreement that it should precede any actual emergency call processing)? Thanks, Nadine -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Andrew Newton Sent: Friday, August 05, 2005 11:12 AM To: ECRIT Subject: [Ecrit] comments on ECRIT requirements Here are some comments on the ECRIT requirements document: R1. This requirement seems to be saying that an ASP is not required, but the motivation goes on to explain that ASP is just not a traditional ASP, not that they do not run the application. A6. What is the purpose of this requirement? L6. I think the following should be added: Validation of civic addresses MUST NOT be required to enable any feature that is part of the emergency call process. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C59A6A.545FAA76 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Ecrit] comments on ECRIT requirements

Hi Nadine,

This is another of the requirements that I think = bridges the boundary between GeoPriv and ECRIT, and is, in my opinion = anyway, in the same ilk as location dependability. It seems that the = are charter for ECRIT is strictly routing, probably reasonable if a = conclusion is to be reached, but I think that the Geopriv charter needs = to be revised to include location dependability, and location = validation.

Cheers
James

-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf Of Abbott, Nadine B
Sent: Saturday, 6 August 2005 3:09 AM
To: ECRIT
Subject: RE: [Ecrit] comments on ECRIT = requirements


Andy,

I'm not sure of the purpose for your addition to = requirement L6? The purpose of location validation of civic addresses = before they are used in a call origination is to ensure that the = address will result in successful routing/mapping if used during an = emergency call, and to avoid the necessity for default routing and = associated delays, if at all possible. This would seem to me to be a = "required feature that is part of the emergency call process" = (although I think there is agreement that it should precede any actual = emergency call processing)?

Thanks,
Nadine

-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf Of Andrew Newton
Sent: Friday, August 05, 2005 11:12 AM
To: ECRIT
Subject: [Ecrit] comments on ECRIT = requirements


Here are some comments on the ECRIT requirements = document:

R1.  This requirement seems to be saying that an = ASP is not required, 
but the motivation goes on to explain that ASP is = just not a 
traditional ASP, not that they do not run the = application.

A6.  What is the purpose of this = requirement?

L6.  I think the following should be = added:  Validation of civic 
addresses MUST NOT be required to enable any feature = that is part of 
the emergency call process.

-andy


_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

------_=_NextPart_001_01C59A6A.545FAA76-- --===============0610199608== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0610199608==-- From ecrit-bounces@ietf.org Tue Aug 09 05:15:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QDD-0001ny-CC; Tue, 09 Aug 2005 05:15:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QD8-0001l3-ET for ecrit@megatron.ietf.org; Tue, 09 Aug 2005 05:15:50 -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 FAA23846 for ; Tue, 9 Aug 2005 05:15:48 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Qkz-0000ic-Qu for ecrit@ietf.org; Tue, 09 Aug 2005 05:50:51 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j799FdSF017769 for ; Tue, 9 Aug 2005 11:15:39 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j799FcwU025860 for ; Tue, 9 Aug 2005 11:15:39 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Aug 2005 11:15:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2005 11:15:33 +0200 Message-ID: Thread-Topic: review of Thread-Index: AcWcwuY17NoUTS5rR5qT2jZNsBsROw== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 09 Aug 2005 09:15:35.0653 (UTC) FILETIME=[E69C7950:01C59CC2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] review of X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 i went through the draft and found a few issues that deserve a discussion. i have split my comments into sections to make it easier to address them.=20 ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 09 05:16:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QDy-00028j-Oq; Tue, 09 Aug 2005 05:16:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QDv-00028b-1M for ecrit@megatron.ietf.org; Tue, 09 Aug 2005 05:16:40 -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 FAA23869 for ; Tue, 9 Aug 2005 05:16:36 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Qll-0000jp-SC for ecrit@ietf.org; Tue, 09 Aug 2005 05:51:39 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j799GRJU017592 for ; Tue, 9 Aug 2005 11:16:27 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j799GRWG008776 for ; Tue, 9 Aug 2005 11:16:27 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Aug 2005 11:16:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2005 11:16:20 +0200 Message-ID: Thread-Topic: introduction section () Thread-Index: AcWcwwIazq7kc+SKSX+RFJjJ1VomkA== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 09 Aug 2005 09:16:24.0591 (UTC) FILETIME=[03C7D1F0:01C59CC3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] introduction section () X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 please find my comments below (#).=20 i think the introduction is too long and repeats requirements.=20 1. Introduction Users of telephone-like services expect to be able to call for emergency help, such as police, the fire department or an ambulance, regardless of where they are, what (if any) service provider they are using and what kind of device they are using. Unfortunately, the mechanisms for emergency calls that have evolved in the public circuit-switched telephone network (PSTN) are not quite appropriate for evolving IP-based voice, text and real-time multimedia communications. This document outlines the key requirements that end systems and network elements such as SIP proxies need to satisfy in order to provide emergency call services that offer at least the same functionality as existing PSTN services, with the goal of making emergency calling more robust, cheaper to implement and multimedia- capable. In the future, users of other real-time and near real-time services may also expect to be able to summon emergency help. For example, instant messaging (IM) users may want to use such services. IM is particularly helpful for hearing-disabled users (RFC 3351 [4]) and in cases where bandwidth is scarce. This document only focuses on end-to-end IP-based calls, i.e., where the emergency call originates from an IP end system, (Internet device), and terminates to an IP-capable PSAP, done entirely over an IP network. # ------ i would shorten the following paragraphs below by just saying something like.=20 Section 2 defines terminology, Section 3 lists high-level requirements, etc...=20 =20 This document identifies functional and security issues for # ^^^^^^^^^^^^^^^^ # in fact this document does not specify security requirements.=20 determining the correct emergency identifier, for identifying the appropriate PSAP (emergency address) and for identifying the caller and its current location. Emergency calls need to be identified (Section 6). Emergency identifiers are used by the emergency caller to declare a call to be an emergency call. The device MUST recognize the emergency identifiers used and convert them to an emergency address to guide the call to a PSAP. The emergency address MUST be a predefined "sip", "sips" or "tel" URI scheme. Emergency calls need to be routed to the appropriate PSAP (ref. Section 6). Several terms are used for causing the call signaling to reach the geographically appropriate PSAP. This has been referred to as call routing, (PSAP) lookup or location mapping, all capturing aspects of the problem. Emergency calls need to identify who placed the call (Section 7). In most jurisdictions, callers do not have a choice as to whether they want to reveal their location or identity; such disclosure is Schulzrinne & Marshall Expires November 2, 2005 [Page 3] =0C Internet-Draft ECRIT requirements May 2005 typically mandated by law. Emergency calls need to identify the location from which the call is initiated (Section 5). The caller location needs to be identified for two purposes, namely to route the call to the appropriate PSAP and to display the caller location to the call taker to simplify dispatching emergency assistance to the correct location. Emergency calls may not be subject to access restrictions placed on non-emergency calls. Also, some call features may interfere with emergency calls, particularly if triggered accidentally (Section 7). --- ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 09 05:16:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QEC-0002A8-3c; Tue, 09 Aug 2005 05:16:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QE9-00029s-Ph for ecrit@megatron.ietf.org; Tue, 09 Aug 2005 05:16:54 -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 FAA23904 for ; Tue, 9 Aug 2005 05:16:50 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Qm0-0000kj-VY for ecrit@ietf.org; Tue, 09 Aug 2005 05:51:53 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j799Gg9c017787 for ; Tue, 9 Aug 2005 11:16:42 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j799Gbpx009475 for ; Tue, 9 Aug 2005 11:16:42 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Aug 2005 11:16:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2005 11:16:35 +0200 Message-ID: Thread-Topic: Terminology section () Thread-Index: AcWcwwryHcNyexfAREOj8pOahjOUTg== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 09 Aug 2005 09:16:36.0342 (UTC) FILETIME=[0AC8E160:01C59CC3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Terminology section () X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 please find my comments below (#).=20 a number of requirements are not needed and some others are missing.=20 2. Terminology # i have the impression that we go a little bit far with the terminology section.=20 In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations. Since a requirements document does not directly specify an implement able protocol, these compliance labels should be read as indicating requirements for the protocol or architecture, rather than an implementation. For lack of a better term, we will use the term "caller" or "emergency caller" to refer to the person placing an emergency call or sending an emergency IM. Access Infrastructure Provider (AIP): An organization that provides physical network connectivity to its customers or users, e.g. through digital subscriber lines, cable TV plants, Ethernet, leased lines or radio frequencies. This entity may or may not also provide IP routing, IP addresses, or other Internet protocol services. Examples of such organizations include telecommunication carriers, municipal utilities, larger enterprises with their own network infrastructure, and government organizations such as the military. [Ed. AIP vs. IAP vs. ? not yet clear as to general agreement on a single term.] # do we use this term in the document? i don't think so.=20 # if we think that these terms are needed then we should introduce a (sub)section about actors. # (at least something similar to section 4 of http://www.ietf.org/internet-drafts/draft-tschofenig-ecrit-security-thre ats-01.txt) address: A description of a location of a person, organization, or building, most often consisting of numerical and text elements such as street number, street name, and city arranged in a particular format. # why do we need to define what an address is?=20 administrative domain: An area or group of services falling with in a specific category or jurisdictional boundary. # why do we need this term?=20 Application (Voice) Service Provider (ASP, VSP): The organization that provides voice or other application-layer services, such as call routing, a SIP URI or PSTN termination. This organization can be a private individual, an enterprise, a government or a service provider. We avoid the term voice service provider as emergency calls are likely to use other media, including text and video, in the future. For a particular user, the ASP may not be the same organization as the AIP or ISP. Schulzrinne & Marshall Expires November 2, 2005 [Page 5] =0C Internet-Draft ECRIT requirements May 2005 Basic Emergency Service: Basic Emergency Service allows a user to reach a PSAP serving its current location, but the PSAP may not be able to determine the identity or geographic location of the caller (except by having the call taker ask the caller). # why do we need to distinguish between basic and enhanced emergency service?=20 call taker: A call taker is an agent at the PSAP that accepts calls and may dispatch emergency help. (Sometimes the functions of call taking and dispatching are handled by different groups of people, but these divisions of labor are not generally visible to the outside and thus do not concern us here.) civic location: A described location based on some defined grid, such as a jurisdictional, postal, metropolitan, or rural reference system (e.g. street address). domain authentication and validation entity: A node that has authority within a given domain to authenticate and validate user location information. # i think we don't use this term anymore in the document.=20 Emergency Control Center (ECC): Facilities used by emergency organizations to accept and handle emergency calls. A PSAP (below) forwards emergency calls to the emergency control center, which dispatches police, fire, rescue and other emergency services. An ECC serves a limited geographic area. A PSAP and ECC can be combined into one facility (ETSI SR 002 180 definition). We assume that the ECC is reachable by IP-based protocols, such as SIP for call signaling and RTP for media. # haven't we once said that we want to use either psap or ecc. i remember that we agreed to use the term psap.=20 emergency address: The sip:uri, sips:uri, or tel:uri which represents the network address of the PSAP useful for the completion of a VoIP emergency call. emergency caller: The user or user device entity which sends his/her location to another entity in the network. emergency identifier: The numerical and/or text identifier which is supplied by a user or a user device, which identifies the call as an emergency call and is translated into an emergency address for call routing and completion. enhanced emergency service: Enhanced emergency services add the ability to identify the caller identity and/or caller location to basic emergency services. (Sometimes, only the caller location may be known, e.g. from a public access point that is not owned by an individual.) Schulzrinne & Marshall Expires November 2, 2005 [Page 6] =0C Internet-Draft ECRIT requirements May 2005 ESRP (Emergency Services Routing Proxy): An ESRP is a call routing entity that invokes the location-to-URL mapping, which in turn may return either the URL for another ESRP or the PSAP. (In a SIP system, the ESRP would typically be a SIP proxy, but could also be a Back-to-back user agent (B2BUA). # do we really all these geo-specific terms? geocoding: The process of finding the location of a street address on a map. The location can be an x,y coordinate or a feature such as a street segment, postal delivery location, or building. In GIS, geocoding requires a reference dataset that contains address attributes for the geographic features in the area of interest. geographic coordinates: A representation (measurement) of a location on the earth's surface expressed in degrees of latitude and longitude. geographic coordinate system: A reference system that uses latitude and longitude to define the locations of points on the surface of a sphere or spheroid. geographic transformation: A method of converting data between two geographic coordinate systems (datums). geographic location: A reference to a locatable point described by a set of defined coordinates within a geographic coordinate system, (e.g. lat/lon within WGS-84 datum) Internet Service Provider (ISP): An organization that provides IP network-layer services to its customers or users. This entity may or may not provide the physical-layer and layer-2 connectivity, such as fiber or Ethernet. location: A geographic identification assigned to a region or feature based on a specific coordinate system, or by other precise information such as a street address. In the geocoding process, the location is defined with an x,y coordinate value according to the distance north or south of the equator and east or west of the prime meridian. Location Key (LK): A key identifier used to query a location server in order to retrieve a specific end user or end user device location. # we don't use this term in the document anymore.=20 location validation: A caller location is considered valid if the civic or geographic location is recognizable within an acceptable location reference systems (e.g. USPS, WGS84, etc.), and can be mapped to one or more PSAPs. Location validation ensures that a location is reference able, but makes no assumption about the Schulzrinne & Marshall Expires November 2, 2005 [Page 7] =0C Internet-Draft ECRIT requirements May 2005 association between the caller and the caller's location. PSAP (Public Safety Answering Point): Physical location where emergency calls are received under the responsibility of a public authority. (This terminology is used by both ETSI, in ETSI SR 002 180, and NENA.) In the United Kingdom, PSAPs are called Operator Assistance Centres, in New Zealand Communications Centres. Within this document, it is assumed, unless stated otherwise, that PSAP is that which supports the receipt of emergency calls over IP. It is also assumed that the PSAP is reachable by IP-based protocols, such as SIP for call signaling and RTP for media. x,y coordinates: A pair of values that represents the distance from an origin (0,0) along two axes, a horizontal axis (x) representing east-west, and a vertical axis (y) representing north-south. On a map, x,y coordinates are used to represent features at the location they are found on the earth's spherical surface. # we don't need this term.=20 # more terminology is required: i would like to see terms for the mapping protocol (or something similar).=20 additionally, the client and the server actors using the protocol are required (e.g., mapping protocol client and the server) # what is the name for the 'process for determining the location to uri mapping' ? resolution?=20 # additionally, we need a name for an 'iterative' and a 'recursive' query to the distributed directory.=20 # a definition for the 'distributed directory' or 'distributed database' is also needed.=20 ------- ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 09 05:19:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QGf-0002Wo-EQ; Tue, 09 Aug 2005 05:19:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QGb-0002U7-FB for ecrit@megatron.ietf.org; Tue, 09 Aug 2005 05:19:27 -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 FAA23996 for ; Tue, 9 Aug 2005 05:19:22 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2QoT-0000oX-II for ecrit@ietf.org; Tue, 09 Aug 2005 05:54:26 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j799JFSu020776 for ; Tue, 9 Aug 2005 11:19:15 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j799JFst011631 for ; Tue, 9 Aug 2005 11:19:15 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Aug 2005 11:19:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2005 11:19:10 +0200 Message-ID: Thread-Topic: High-Level Requirements section () Thread-Index: AcWcw2cUuVxKvZGwQGevKCLhxfbeiQ== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 09 Aug 2005 09:19:15.0309 (UTC) FILETIME=[698951D0:01C59CC3] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] High-Level Requirements section () X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 please find my comments below (#).=20 just a few minor fixes.=20 3. High-Level Requirements Below, we summarize high-level architectural requirements that guide some of the component requirements detailed later in the document. R1. Application Service Provider: The existence of a Application Service Provider (ASP) MUST NOT be assumed. Motivation: The caller may not have a voice service provider, i.e., a corporate entity that provides voice services as a business.=20 # i suggest to shorten the sentence since we already defined the term voice service provider.=20 # hence, the complete sentence would read:=20 " The caller may not have a voice service provider. " For example, a residence may have its own DNS domain and run its own SIP proxy server for that domain. On a larger scale, a university might provide voice services to its students and staff, but not be a telecommunication provider. R2. International: The protocols and protocol extensions developed MUST support regional, political and organizational differences. Motivation: It MUST be possible for a device or software developed ^^^^^^ # the motivation paragraph should not contain capitalized must, may or shoulds.=20 or purchased in one country to place emergency calls in another country. System components should not be biased towards a particular set of emergency numbers or languages. Also, different countries have evolved different ways of organizing emergency services, e.g. either centralizing them or having smaller regional subdivisions such as United States counties or municipalities handle emergency calls. R3. Distributed Administration: Deployment of emergency services MUST NOT depend on a sole central administration authority. Motivation: Once common standards are established, it must be possible to deploy and administer emergency calling features on a regional or national basis without requiring coordination with other regions or nations. The system cannot assume, for example, that there is a single global entity issuing certificates for PSAPs, ASPs, AIPs or other participants. R4. Multiple Modes: Multiple communication modes, including Multimedia data and services MUST be supported. # rephrase the sentence to:=20 " Multiple communication modes, such as audio, video and text messaging MUST be supported. " Motivation: Emergency calling must support a variety of media, not just voice and TDD (telecommunication device for the deaf) beyond the capabilities of current limitations. Such additional media should include conversational text, instant messaging and video. # what is the difference between 'conversational text' and 'instant messaging' in this context? =20 In addition, it should be possible to convey telemetry data, such as data from automobile crash sensors. # i think that this would be a separate requirement.=20 Schulzrinne & Marshall Expires November 2, 2005 [Page 9] =0C Internet-Draft ECRIT requirements May 2005 R5. Minimum Connectivity: An emergency call should succeed as long as there is a working network path between the caller and the PSAP. In particular, reliance during call set-up and calls on entities and network paths that are located elsewhere should be minimized. Example: A caller in New York who needs to contact a PSAP in the same city shouldn't have to get information from some entity in Texas to make that call, as the call would then fail if the New York to Texas path is unavailable. (To avoid this, the caller could, for example, have cached mapping information, use a local server that has the necessary information, or use other mechanisms to avoid such off-path dependencies.) [Ed. No resolution yet agreed to for the above requirement.] R6. Incremental Deployment The output of the ECRIT mapping protocol will be one or more URIs that can be used as the target of an emergency communication. These must be usable by an appropriately capable device even if that device has no knowledge of the mapping protocol. As an example, if the mapping protocol returns a SIP URI any SIP-capable phone should be able to use it as a target of the call; no special extension to SIP should be required. # R6 does not seem to be a requirement or it is, at the moment, not phrased as one.=20 ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 09 05:21:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QIE-0003AZ-Le; Tue, 09 Aug 2005 05:21:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QIC-00037i-Qc for ecrit@megatron.ietf.org; Tue, 09 Aug 2005 05:21:04 -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 FAA24040 for ; Tue, 9 Aug 2005 05:21:02 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Qq5-0000rV-4p for ecrit@ietf.org; Tue, 09 Aug 2005 05:56:05 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j799Ks0H022242 for ; Tue, 9 Aug 2005 11:20:54 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j799Ksu2030417 for ; Tue, 9 Aug 2005 11:20:54 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Aug 2005 11:20:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2005 11:20:51 +0200 Message-ID: Thread-Topic: Emergency Address section () Thread-Index: AcWcw6OFTBUl5BM9R3G2loYdRH7xCA== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 09 Aug 2005 09:20:53.0561 (UTC) FILETIME=[A4196290:01C59CC3] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Emergency Address section () X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 please find my comments below (#).=20 minor fixes as well.=20 4. Emergency Address A1. Universal: Each device and all network elements MUST recognize one or more universal (global) emergency identifiers, regardless of the location of the device, the service provider used (if any) # ^^^^ # voice or other factors. Examples of these might include: 911, 112, and sos.* # move the examples into the motivation section.=20 Motivation: SIP and other call signaling protocols are not specific to one country or service provider and devices are likely to be used across national or service provider boundaries. Since services such as disabling mandatory authentication for emergency ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # this sounds strange. if it is mandatory then it cannot be disabled.=20 calls requires the cooperation of outbound proxies, the outbound proxy has to be able to recognize the emergency address and be assured that it will be routed as an emergency call. =20 # the following sentence either needs to be removed or requires further explanation.=20 # ----------- Thus, a simple declaration on a random URI that it is an emergency call will likely lead to fraud and possibly attacks on the network infrastructure. # ------------ A universal address also makes it possible to create user interface elements that are correctly configured without user intervention. UA features could be made to work without such an identifier, but the user interface would then have to provide an unambiguous way to declare a particular call an emergency call. A3. Recognizable: Emergency calls MUST be recognizable by user agents, proxies and other network elements. To prevent fraud, an address identified as an emergency number for call features or authentication override MUST also cause routing to a PSAP. # i suggest to move the last line to a motivation section.=20 A4. Minimal configuration: Any local emergency identifiers SHOULD be configured automatically, without user intervention. Motivation: A new UA "unofficially imported" into an organization from elsewhere should have the same emergency capabilities as one officially installed. A6. Backwards-compatible: Existing devices that predate the specification of emergency call-related protocols and conventions MUST be able reach a PSAP. ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 09 05:22:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QK3-0004Mo-3h; Tue, 09 Aug 2005 05:22:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QK1-0004Kj-74 for ecrit@megatron.ietf.org; Tue, 09 Aug 2005 05:22:57 -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 FAA24177 for ; Tue, 9 Aug 2005 05:22:54 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Qrt-0000vL-Kd for ecrit@ietf.org; Tue, 09 Aug 2005 05:57:58 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j799MkEc023883 for ; Tue, 9 Aug 2005 11:22:46 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j799MkD2015760 for ; Tue, 9 Aug 2005 11:22:46 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Aug 2005 11:22:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2005 11:22:45 +0200 Message-ID: Thread-Topic: Identifying the Caller Location section () Thread-Index: AcWcw+ct3JMO1w3JRrmTynt0KVvFKA== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 09 Aug 2005 09:22:46.0260 (UTC) FILETIME=[E745E340:01C59CC3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Identifying the Caller Location section () X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 please find my comments below (#).=20 5. Identifying the Caller Location This section supplements the requirements outlined in RFC 3693 [5]. # i think that this statement is wrong (or at least not very specific).=20 # i suggest to delete this sentence.=20 Thus, the requirements enumerated there are not repeated here. # i think it would be reasonable to repeat requirements from rfc 3693 if they are relevant.=20 # i wonder what the relevant requirements are.=20 In general, we can distinguish three modes of operation: UA-inserted: The caller's user agent inserts the location information, derived from sources such as GPS, DHCP or link-layer announcements (LLDP). # a few references wouldn't matter here.=20 UA-referenced: The caller's user agent provides a reference, via a permanent or temporary identifier, # i suggest to rephrase the above sentence to: # ... a reference to location is stored by... # the permanent / temporary id does not make too much sense.=20 to the location which is stored by a location service somewhere else and then retrieved by the PSAP. Proxy-inserted: A proxy along the call path inserts the location or location reference. L6. Validation of civic location: It MUST be possible to validate an address prior to its use in an actual emergency call. # is this a protocol requirement or an architecture requirement?=20 # when should this validation take place?=20 Motivation: Location validation refers to a process to determine whether or not a given civic location is valid or not. # we don't need to explain location validation anymore. it is already described in the terminology section A location is said to be valid if it can be mapped exactly to a unique emergency address for a PSAP, known to the emergency services directory/mapping database. L10. Preferred datum: The preferred geographic coordinate system for ^^^^^^^^^^^ # the correct term is coordinate reference system.=20 emergency calls SHALL be WGS-84. # SHALL? why not MUST? L28. Location Provided: If location is provided to the routing proxy, it MUST be provided to the PSAP. # the requirement should rather say something like:=20 # An Emergency Services Routing Proxy (ESRP) MUST NOT remove location information after performing location based routing.=20 # the motivation would then indicate that the ESRP and the PSAP use the same location information object but for a different purpose.=20 Motivation: Transmission of the current location of the contacting device to the PSAP. # this is a strange motivation. maybe a little bit more text would be nice.=20 ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 09 05:24:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QLW-0004d1-Qn; Tue, 09 Aug 2005 05:24:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QLV-0004co-45 for ecrit@megatron.ietf.org; Tue, 09 Aug 2005 05:24:29 -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 FAA24224 for ; Tue, 9 Aug 2005 05:24:26 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2QtM-0000xE-Tr for ecrit@ietf.org; Tue, 09 Aug 2005 05:59:29 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j799OIFS025844 for ; Tue, 9 Aug 2005 11:24:18 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j799OIMs017036 for ; Tue, 9 Aug 2005 11:24:18 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Aug 2005 11:24:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2005 11:24:17 +0200 Message-ID: Thread-Topic: Identifying the Appropriate PSAP section () Thread-Index: AcWcxB4Ykhbww/uDSlGv9R3LWR8B1A== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 09 Aug 2005 09:24:17.0463 (UTC) FILETIME=[1DA25C70:01C59CC4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Identifying the Appropriate PSAP section () X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 please find my comments below (#).=20 this section seems to require some editing.=20 6. Identifying the Appropriate PSAP # this section outlines the requirements for the mapping protocol.=20 # maybe we should just give it that name.=20 # i also think that the next few paragraphs can be replaced by a short paragraph describing the problem statement.=20 # this is all about determining the mapping between location information and one (or multiple) uris.=20 # it is ok to mention that there are two approaches for triggering the mapping protocol:=20 * caller-based=20 * mediated.=20 From the previous section, we take the requirement of a single (or small number of) emergency addresses which are independent of the caller's location. However, since for reasons of robustness, jurisdiction and local knowledge, PSAPs only serve a limited geographic region, having the call reach the correct PSAP is crucial. While a PSAP may be able to transfer an errant call, any such transfer is likely to add tens of seconds to call setup latency and is prone to errors. # the last sentence either needs more explanation or needs to be removed.=20 (In the United States, there are about 6,100 PSAPs.) # what is the relationship to the rest of the paragraph?=20 There appears to be two basic architectures for translating an emergency identifier into the correct PSAP emergency address. We refer to these as caller-based and mediated. In caller-based resolution, the caller's user agent consults a directory and determines the correct PSAP based on its location.=20 We assume that the user agent can determine its own location, either by knowing it locally or asking some third party for it. A UA could conceivably store a complete list of all PSAPs across the world, but that would require frequent synchronization with a master database as PSAPs merge or jurisdictional boundaries change. # i would delete these few sentences. it is obvious that the entity that triggered the mapping protocol needs to use location information as input to the protocol.=20 For mediated resolution, a call signaling server, such as a SIP (outbound) proxy or redirect server performs this function. Note that the latter case includes the architecture where the call is effectively routed to a copy of the database, rather than having some non-SIP protocol query the database. # what should the last sentence tell us?=20 # is this a protocol proposal? Since servers may be used as outbound proxy servers by clients that are not in the same geographic area as the proxy server, any proxy server has to be able to translate any caller location to the appropriate PSAP. (A traveler may, for example, accidentally or intentionally configure its home proxy server as its outbound proxy server, even while far away from home.) The resolution may take place well before the actual emergency call is placed, or at the time of the call. # we could add this somewhere to the requirements? if the resolution took place before the emergency call was triggered then no constraints are imposed on the solution. in fact this statement is captured with I42.=20 The problem # Location-based (or context based) routing=20 is harder than for traditional web or email services. There, the originator knows which entity it wants to reach, identified by the email address or HTTP URL. # i think that the comparison with http is not really appropriate.=20 However, the emergency caller only dialed an emergency identifier. Depending on the location, any of several ten thousand PSAPs around the world could be valid. # we use several different terms to denote a psap that is responsible for a certain geographical region: valid, appropriate, correct In addition, the caller probably does not care which specific PSAP answers the call, but rather that it be an accredited PSAP, e.g. one run by the local government authorities. (Many PSAPs are run by private entities. For example, universities and corporations with large campuses often have their own emergency response centers.) # i suggest to move these issues down to the requirements. the fact that a psap might be run by a private entity is an operation requirement and might not even belong to this document.=20 Schulzrinne & Marshall Expires November 2, 2005 [Page 13] =0C Internet-Draft ECRIT requirements May 2005 I1. Correct PSAP: Calls Must be routed to the PSAP responsible for ^^^^ # MUST this particular geographic area. Motivation: In particular, the location determination should not be fooled by the location of IP telephony gateways or dial-in lines into a corporate LAN (and dispatch emergency help to the gateway or campus, rather than the caller), multi-site LANs and similar arrangements. # i don't see how the motivation relates to the requirement=20 I3. Multi-stage resolution: # multi-stage resolution is a confusing term here. we should use terms we introduced in the terminology section.=20 A mapping server for a large geographic area SHOULD be able to refer clients to mapping servers responsible for subsets of the geographic area. # this requirement should read : "The mapping protocol MUST support redirection functionality." (if we use the terms 'mapping protocol' and 'redirection') Motivation: In some cases, an initial mapping may provide a single URL for a large geographic area. The ESRP identified by that URL then re-invokes the mapping protocol on a different database to obtain another URL for an ESRP or PSAP covering a smaller area. I4. Return multiple PSAPs: The mapping protocol MUST be able to return multiple URLs for different PSAPs that cover the same area. The mapping protocol MUST provide additional information that allows the querying entity to determine relevant properties of the URL. Motivation: In some cases, the same geographic area is served by several PSAPs, for example, a corporate campus might be served by both a corporate security department and the municipal PSAP. The mapping protocol should then return URLs for both, with information allowing the querying entity to choose one or the other. The choice would typically be made by an ESRP based on local policy, not by a human user. # the last sentence does not make sense if you also support caller-based resolution.=20 I7. Traceable resolution: The entity requesting mapping SHOULD be able to definitively and securely # what does 'definitively and securely' mean?=20 determine the entity or entities who provided the emergency address resolution information. # we should be a bit more specific about this requirement. what is the impact of this requirement?=20 is it sufficient to add an attribute to the returned object that the mapping was provided by X or do we demand signing of the entity that created the mapping?=20 I8. Resilience against server failure: A client MUST be able to fail over to another replica of the mapping server, so that a failure of a server does not endanger the ability to perform the mapping. I10. Incrementally deployable: The mapping function MUST be capable of being deployed incrementally.=20 # here starts the motiviation.=20 It must not be necessary, for example, to have a global street level database before deploying the system. It is acceptable to have some misrouting of calls when the database does not (yet) contain accurate boundary information. Schulzrinne & Marshall Expires November 2, 2005 [Page 14] =0C Internet-Draft ECRIT requirements May 2005 I13. Existing infrastructure support:=20 # this requirement needs to be split into a requirements part and a motivation part.=20 It SHOULD be possible for the mapping function to provide information that allows the requesting entity to determine if ecrit compatible emergency call support is available in the jurisdiction where the location is proferred for mapping. # hmm. i am not sure what this means.=20 Where ecrit compatible emergency calling is NOT available, the mapping function MAY yield information which could be used to route emergency calls using existing, country specific methods. # what is ecrit compatibility?=20 in the working group we develop requirements and (hopefully soon) a solution for a mapping protocol.=20 For example, a tel URI may be provided for a PSTN routed call, or a routing code which has meaning only within a country specific routing mechanism. I25. Mapping can be requested from anywhere: The mapping protocol MUST be able to provide the mapping regardless of where the querier is located, either geographically or by network location. Motivation: The querier, such as the ESRP, may not necessarily be anywhere close to the caller or the appropriate PSAP, but must still be able to obtain a mapping. I31: In response to a mapping request, a server will normally provide a URI or set of URIs for contacting the appropriate PSAP. The protocol must also be to return a URI or contact method explicitly marked as an alternate contact. When this is used will be described in an operational document. # rewrite this paragraph as a requirement:=20 # I31: Multiple URIs: The mapping protocol MUST allow a response to carry multiple URIs.=20 # the alternative contact might be a separate requirement.=20 I39: It SHOULD be possible to have updates of location (which may occur when measuring devices provider early, but imprecise "first fix" location) which can change routing of calls. # add I39: Location Update:=20 I40. The mapping protocol MUST be extensible to allow for the inclusion of new location fields. Motivation: This is needed, for example, to accommodate future extensions to location information that might be included in the PIDF-LO. # reference to pidf-lo missing.=20 I41. Split responsibility: The mapping protocol MUST allow that within a single level of the civic address hierarchy, multiple mapping servers handle subsets of the data elements. # why is this only related to civic location info?=20 Motivation: For example, two directories for the same city or county may handle different streets within that city or county. I42. The mapping function MUST be able to be invoked at any time, including while an emergency call is in process. ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 09 05:26:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QNK-0005ie-0H; Tue, 09 Aug 2005 05:26:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QNI-0005iZ-Cy for ecrit@megatron.ietf.org; Tue, 09 Aug 2005 05:26:20 -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 FAA24303 for ; Tue, 9 Aug 2005 05:26:17 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2QvA-000113-Rt for ecrit@ietf.org; Tue, 09 Aug 2005 06:01:21 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j799Q95q027627 for ; Tue, 9 Aug 2005 11:26:10 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j799Q92c001984 for ; Tue, 9 Aug 2005 11:26:09 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Aug 2005 11:26:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2005 11:25:39 +0200 Message-ID: Thread-Topic: Emergency Address Directory section () Thread-Index: AcWcxE8dRoIBgPHJTW6vbu45Ql4WFA== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 09 Aug 2005 09:26:07.0959 (UTC) FILETIME=[5F7EB670:01C59CC4] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Emergency Address Directory section () X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 please find my comments below (#).=20 i think that this section should be merged with the previous section since most requirements directly relate to the mapping protocol. 7. Emergency Address Directory D1. PSAP Identification: The mapping information MUST be available without having to enroll with a service provider. # what mapping information?=20 # how does this relate to psap identification?=20 # this seems to be an operational requirement, if i understood it correctly. isn't this already covered by R1 partially? should this, if needed at all, be moved to section 3?=20 Motivation: The mapping server may well be operated by a service provider, but access to the server offering the mapping MUST NOT require use of a specific ISP or VSP. # motivation should not juse capitalized MUST, MAY, SHOULD, etc.=20 D5. Call setup latency: The directory lookup SHOULD minimize any added delay to the call setup. # i suggest not to talk about call setup latency. we are working on a mapping protocol. how can we control things that are outside the scope of our work?=20 # i understand if we have a requirement like: # Efficiency: The mapping protocol SHOULD have a minimum number of roundtrips.=20 Motivation: Since outbound proxies will likely be asked to resolve the same geographic coordinates repeatedly, a suitable time-limited caching mechanism should be supported. # the motivation does not match the requirement. if we think that there is a requirement for caching then we should phrase is at such.=20 D7. Referral: The querier MUST be able to contact any server and be referred to another server that is more qualified to answer the query. Motivation: This requirement alleviates the potential for misconfigurations to cause calls to fail, particularly for caller- based queries. # this requirement should be related to I3. place them next to each other.=20 D9. Baseline query protocol: A mandatory-to-implement protocol MUST be specified. Motivation: An over-abundance of similarly-capable choices appears undesirable for interoperability. ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 09 05:26:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QNS-0005jQ-9f; Tue, 09 Aug 2005 05:26:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QNR-0005jI-2J for ecrit@megatron.ietf.org; Tue, 09 Aug 2005 05:26:29 -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 FAA24314 for ; Tue, 9 Aug 2005 05:26:26 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2QvI-000118-U9 for ecrit@ietf.org; Tue, 09 Aug 2005 06:01:30 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j799QGLS028882 for ; Tue, 9 Aug 2005 11:26:16 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j799QD72019243 for ; Tue, 9 Aug 2005 11:26:16 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Aug 2005 11:26:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2005 11:26:10 +0200 Message-ID: Thread-Topic: Supplemental Information section () Thread-Index: AcWcxGGTX2gMEVu+RY2WTEfU/a2+Pg== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 09 Aug 2005 09:26:12.0662 (UTC) FILETIME=[624C5560:01C59CC4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Supplemental Information section () X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 please find my comments below (#).=20 this section does not provide enough information to understand the requirements.=20 8. Supplemental Information SD1 The format both of the query and of the result returned by the protocol must be extensible to accommodate new types of ^^^^^ # MUST information. # isn't this requirement already capture with I40?=20 Motivation: In addition to information sent with the call, additional information may be available, supplemental to the call, which is retrieved from internal or external databases using a key to the information included with the call. This key may also include information to identify/address the database. # the subsequent requirements SD2 - SD9 do not provide enough information to understand them.=20 # in fact i am not sure whether these requirements are actually needed.=20 SD2 Additional information MAY be available to the call taker based on the location of the caller. SD3 Additional information MAY be available to the call taker based on the owner of the structure. SD4 Additional information MAY be available to the call taker based on the tenant of the structure. SD5 Where a vehicle is involved, additional information MAY be available. SD6 Additional information MAY be available based on the Address of Record (AoR) of the caller. In this context, AoR equates to the caller. SD7 Consideration SHOULD be given to permitting users to have domain independent mechanisms to supply information related to the caller, for example, another datum related to user. SD8. Additional Data: Transfer of additional data SHOULD be supported. Motivation: Capabilities to contact PSAP by automatic means and for the transfer of additional information (alarm equipment, cars, buses, trucks with dangerous loads, ...) SD9 Mechanism MUST be provided to automatically generate and provide misroute and location error reports. ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 09 05:36:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QXZ-0000Wd-DY; Tue, 09 Aug 2005 05:36:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QXM-0000Vg-1H for ecrit@megatron.ietf.org; Tue, 09 Aug 2005 05:36:44 -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 FAA24656 for ; Tue, 9 Aug 2005 05:36:41 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2R5D-0001Ga-OG for ecrit@ietf.org; Tue, 09 Aug 2005 06:11:45 -0400 Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net [141.153.198.113]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j799aegQ025703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Aug 2005 05:36:41 -0400 (EDT) Message-ID: <42F87979.8060807@cs.columbia.edu> Date: Tue, 09 Aug 2005 05:38:01 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: [Ecrit] introduction section () References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I agree that this can be shortened, but would like suggesting keeping text that allows the reader to identify how our overall sequence of steps work. This is far from obvious to most "bystanders" and we don't have another document to point to. Below, I trimmed stuff I think is unncessary details and did some re-ordering. Tschofenig, Hannes wrote: > hi all, > > please find my comments below (#). > > i think the introduction is too long and repeats requirements. > > > 1. Introduction > > Users of telephone-like services expect to be able to call for > emergency help, such as police, the fire department or an ambulance, > regardless of where they are, what (if any) service provider they are > using and what kind of device they are using. Unfortunately, the > mechanisms for emergency calls that have evolved in the public > circuit-switched telephone network (PSTN) are not quite appropriate > for evolving IP-based voice, text and real-time multimedia > communications. This document outlines the key requirements that end > systems and network elements such as SIP proxies need to satisfy in > order to provide emergency call services that offer at least the same > functionality as existing PSTN services, with the goal of making > emergency calling more robust, cheaper to implement and multimedia- > capable. > > > This document only focuses on end-to-end IP-based calls, i.e., where > the emergency call originates from an IP end system, (Internet > device), and terminates to an IP-capable PSAP, done entirely over an > IP network. > > > > # ------ i would shorten the following paragraphs below by just saying > something like. > Section 2 defines terminology, Section 3 lists high-level requirements, > etc... > > > This document identifies functional and security issues for > # ^^^^^^^^^^^^^^^^ > # in fact this document does not specify security requirements. > > determining the correct emergency identifier, for identifying the > appropriate PSAP (emergency address) and for identifying the caller > and its current location. [should be in section order] > Emergency calls need to identify the location from which the call is > initiated (Section 5). The caller location needs to be identified > for two purposes, namely to route the call to the appropriate PSAP > and to display the caller location to the call taker to simplify > dispatching emergency assistance to the correct location. > > Emergency calls need to be identified (Section 6). Emergency > identifiers are used by the emergency caller to declare a call to be > an emergency call. > > Emergency calls need to be routed to the appropriate PSAP (ref. > Section 6). > Emergency calls need to identify who placed the call (Section 7). _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 09 06:27:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2RKq-0003IR-6W; Tue, 09 Aug 2005 06:27:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2RKn-0003IE-Oo for ecrit@megatron.ietf.org; Tue, 09 Aug 2005 06:27:49 -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 GAA26650 for ; Tue, 9 Aug 2005 06:27:44 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Rsc-0002Vf-WE for ecrit@ietf.org; Tue, 09 Aug 2005 07:02:49 -0400 Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net [141.153.198.113]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j79ARhbv010626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Aug 2005 06:27:44 -0400 (EDT) Message-ID: <42F8856E.8030508@cs.columbia.edu> Date: Tue, 09 Aug 2005 06:29:02 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: [Ecrit] Emergency Address Directory section () References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tschofenig, Hannes wrote: > hi all, > D5. Call setup latency: The directory lookup SHOULD minimize any > added delay to the call setup. > > # i suggest not to talk about call setup latency. we are working on a > mapping protocol. how can we control things that are outside the scope > of our work? > # i understand if we have a requirement like: > It talks about *adding* delay to call setup, which is a valid concern. The caller doesn't care about the mapping delay, after all, just the total. Maybe rephrase as D5. Minimal additional delay: The directory lookup SHOULD cause minimal additional delay at call-setup time. [Delay at other times, such as during address verification, is not as important.] Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 09 06:31:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ROD-000447-Lt; Tue, 09 Aug 2005 06:31:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ROB-00043u-II for ecrit@megatron.ietf.org; Tue, 09 Aug 2005 06:31:19 -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 GAA26807 for ; Tue, 9 Aug 2005 06:31:16 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Rw2-0002aM-OL for ecrit@ietf.org; Tue, 09 Aug 2005 07:06:21 -0400 Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net [141.153.198.113]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j79AVBvr015810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Aug 2005 06:31:15 -0400 (EDT) Message-ID: <42F8863E.1080505@cs.columbia.edu> Date: Tue, 09 Aug 2005 06:32:30 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: [Ecrit] High-Level Requirements section () References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > > # what is the difference between 'conversational text' and 'instant > messaging' in this context? Let's not restart this one. The difference has been well explored (to say the least) on the SIPPING mailing list, in at least 893 messages... Conversational text is shown as you type it, letter by letter, while IM is message-oriented (type + hit return => whole message gets sent). See the ToIP drafts, which should probably be cited here. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 09 06:36:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2RSu-0006kF-I2; Tue, 09 Aug 2005 06:36:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2RSt-0006k6-5D for ecrit@megatron.ietf.org; Tue, 09 Aug 2005 06:36:11 -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 GAA27157 for ; Tue, 9 Aug 2005 06:36:08 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2S0m-0002jW-Cu for ecrit@ietf.org; Tue, 09 Aug 2005 07:11:12 -0400 Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net [141.153.198.113]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j79Aa9is016597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Aug 2005 06:36:10 -0400 (EDT) Message-ID: <42F88768.70805@cs.columbia.edu> Date: Tue, 09 Aug 2005 06:37:28 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: [Ecrit] Terminology section () References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tschofenig, Hannes wrote: > hi all, > > > address: A description of a location of a person, organization, or > building, most often consisting of numerical and text elements > such as street number, street name, and city arranged in a > particular format. > > # why do we need to define what an address is? Since this might be confused with (say) a network address. > > administrative domain: An area or group of services falling with in a > specific category or jurisdictional boundary. > > # why do we need this term? If not used, it clearly can go. > > Basic Emergency Service: Basic Emergency Service allows a user to > reach a PSAP serving its current location, but the PSAP may not be > able to determine the identity or geographic location of the > caller (except by having the call taker ask the caller). > > # why do we need to distinguish between basic and enhanced emergency > service? Because it differs in the requirements, albeit not for the mapping protocol. Basic emergency services only need mapping and location accurate enough for mapping, but do not deliver location information suitable for dispatch to the call taker. > domain authentication and validation entity: A node that has > authority within a given domain to authenticate and validate user > location information. > > # i think we don't use this term anymore in the document. Agreed. > > # haven't we once said that we want to use either psap or ecc. i > remember that we agreed to use the term psap. Yes, this should be PSAP throughout. > ESRP (Emergency Services Routing Proxy): An ESRP is a call routing > entity that invokes the location-to-URL mapping, which in turn may > return either the URL for another ESRP or the PSAP. (In a SIP > system, the ESRP would typically be a SIP proxy, but could also be > a Back-to-back user agent (B2BUA). > > # do we really all these geo-specific terms? No, we don't. Some of the original documents provided more architecture, so they contributed these terms. > > geocoding: The process of finding the location of a street address on > a map. The location can be an x,y coordinate or a feature such as > a street segment, postal delivery location, or building. In GIS, > geocoding requires a reference dataset that contains address > attributes for the geographic features in the area of interest. > > geographic coordinates: A representation (measurement) of a location > on the earth's surface expressed in degrees of latitude and > longitude. > > geographic coordinate system: A reference system that uses latitude > and longitude to define the locations of points on the surface of > a sphere or spheroid. > > geographic transformation: A method of converting data between two > geographic coordinate systems (datums). > > geographic location: A reference to a locatable point described by a > set of defined coordinates within a geographic coordinate system, > (e.g. lat/lon within WGS-84 datum) I don't think we need any of these, except possibly the latter. > # more terminology is required: i would like to see terms for the > mapping protocol (or something similar). > additionally, the client and the server actors using the protocol are > required (e.g., mapping protocol client and the server) > > # what is the name for the 'process for determining the location to uri > mapping' ? resolution? Mapping? This would go nicely with 'mapping server'. > > # additionally, we need a name for an 'iterative' and a 'recursive' > query to the distributed directory. > # a definition for the 'distributed directory' or 'distributed database' > is also needed. > Distributed mapping service? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 09 09:44:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2UPb-0004qz-0q; Tue, 09 Aug 2005 09:44:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2UPZ-0004ny-7V for ecrit@megatron.ietf.org; Tue, 09 Aug 2005 09:44:57 -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 JAA07270 for ; Tue, 9 Aug 2005 09:44:55 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2UxT-0008CI-Ph for ecrit@ietf.org; Tue, 09 Aug 2005 10:20:00 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j79DiTVk026000; Tue, 9 Aug 2005 15:44:29 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j79DiTuH031264; Tue, 9 Aug 2005 15:44:29 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Aug 2005 15:44:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Emergency Address Directory section () Date: Tue, 9 Aug 2005 15:44:24 +0200 Message-ID: Thread-Topic: [Ecrit] Emergency Address Directory section () Thread-Index: AcWczQJZ0VZNURXiTsmBySfqZCwV+gAGiCkw From: "Tschofenig, Hannes" To: "Henning Schulzrinne" X-OriginalArrivalTime: 09 Aug 2005 13:44:25.0044 (UTC) FILETIME=[747A3940:01C59CE8] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi henning,=20 > Tschofenig, Hannes wrote: > > hi all,=20 >=20 > > D5. Call setup latency: The directory lookup SHOULD minimize any > > added delay to the call setup. > >=20 > > # i suggest not to talk about call setup latency. we are=20 > working on a > > mapping protocol. how can we control things that are=20 > outside the scope > > of our work?=20 > > # i understand if we have a requirement like: > >=20 >=20 > It talks about *adding* delay to call setup, which is a valid=20 > concern.=20 > The caller doesn't care about the mapping delay, after all, just the=20 > total. Maybe rephrase as it is true that the emergency caller cares about the total delay.=20 i just want to be realistic about what we can actually do and how we should phrase our requirements.=20 >=20 > D5. Minimal additional delay: The directory lookup SHOULD=20 > cause minimal=20 > additional delay at call-setup time. >=20 > [Delay at other times, such as during address verification, is not as=20 > important.] the suggested rewording might already be sufficient.=20 ciao hannes >=20 > Henning >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 09 09:48:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2UT5-0006Oc-CO; Tue, 09 Aug 2005 09:48:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2UT3-0006OH-Mt for ecrit@megatron.ietf.org; Tue, 09 Aug 2005 09:48:33 -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 JAA07575 for ; Tue, 9 Aug 2005 09:48:31 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2V0x-0008KU-EX for ecrit@ietf.org; Tue, 09 Aug 2005 10:23:36 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j79DmAIk028954; Tue, 9 Aug 2005 15:48:10 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j79DmAPW019989; Tue, 9 Aug 2005 15:48:10 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Aug 2005 15:48:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] High-Level Requirements section () Date: Tue, 9 Aug 2005 15:48:09 +0200 Message-ID: Thread-Topic: [Ecrit] High-Level Requirements section () Thread-Index: AcWczYofNlsj9wV6RemG5A2s9xBcwgAG09Eg From: "Tschofenig, Hannes" To: "Henning Schulzrinne" X-OriginalArrivalTime: 09 Aug 2005 13:48:09.0583 (UTC) FILETIME=[FA5027F0:01C59CE8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi henning,=20 i haven't seen these discussions.... a reference is just fine.=20 ciao hannes > > # what is the difference between 'conversational text' and 'instant > > messaging' in this context? =20 >=20 > Let's not restart this one. The difference has been well explored (to=20 > say the least) on the SIPPING mailing list, in at least 893=20 > messages... >=20 > Conversational text is shown as you type it, letter by=20 > letter, while IM=20 > is message-oriented (type + hit return =3D> whole message gets sent). >=20 > See the ToIP drafts, which should probably be cited here. >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 09 09:50:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2UUc-00084l-BU; Tue, 09 Aug 2005 09:50:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2UUa-00080C-C2 for ecrit@megatron.ietf.org; Tue, 09 Aug 2005 09:50:08 -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 JAA07714 for ; Tue, 9 Aug 2005 09:50:06 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2V2U-0008PW-KI for ecrit@ietf.org; Tue, 09 Aug 2005 10:25:11 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j79DnnkP031156; Tue, 9 Aug 2005 15:49:49 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j79DnmWK021802; Tue, 9 Aug 2005 15:49:49 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Aug 2005 15:49:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] introduction section () Date: Tue, 9 Aug 2005 15:49:43 +0200 Message-ID: Thread-Topic: [Ecrit] introduction section () Thread-Index: AcWcxeEc4QhuUXggQkO5qbZW4sOzHwAIzLBQ From: "Tschofenig, Hannes" To: "Henning Schulzrinne" X-OriginalArrivalTime: 09 Aug 2005 13:49:44.0311 (UTC) FILETIME=[32C68070:01C59CE9] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi henning,=20 > I agree that this can be shortened, but would like suggesting keeping=20 > text that allows the reader to identify how our overall sequence of=20 > steps work. This is far from obvious to most "bystanders" and=20 > we don't=20 > have another document to point to. that's true. we don't have another document at the moment. > Below, I trimmed stuff I think is=20 > unncessary details and did some re-ordering. good.=20 ciao hannes >=20 > Tschofenig, Hannes wrote: > > hi all,=20 > >=20 > > please find my comments below (#).=20 > >=20 > > i think the introduction is too long and repeats requirements.=20 > >=20 > >=20 > > 1. Introduction > >=20 > > Users of telephone-like services expect to be able to call for > > emergency help, such as police, the fire department or=20 > an ambulance, > > regardless of where they are, what (if any) service=20 > provider they are > > using and what kind of device they are using. Unfortunately, the > > mechanisms for emergency calls that have evolved in the public > > circuit-switched telephone network (PSTN) are not quite=20 > appropriate > > for evolving IP-based voice, text and real-time multimedia > > communications. This document outlines the key=20 > requirements that end > > systems and network elements such as SIP proxies need to=20 > satisfy in > > order to provide emergency call services that offer at=20 > least the same > > functionality as existing PSTN services, with the goal of making > > emergency calling more robust, cheaper to implement and=20 > multimedia- > > capable. > >=20 >=20 > >=20 > > This document only focuses on end-to-end IP-based calls,=20 > i.e., where > > the emergency call originates from an IP end system, (Internet > > device), and terminates to an IP-capable PSAP, done=20 > entirely over an > > IP network. > >=20 > >=20 > >=20 > > # ------ i would shorten the following paragraphs below by=20 > just saying > > something like.=20 > > Section 2 defines terminology, Section 3 lists high-level=20 > requirements, > > etc...=20 > >=20 > > =20 > > This document identifies functional and security issues for > > # ^^^^^^^^^^^^^^^^ > > # in fact this document does not specify security requirements.=20 > >=20 > > determining the correct emergency identifier, for identifying the > > appropriate PSAP (emergency address) and for identifying=20 > the caller > > and its current location. >=20 > [should be in section order] >=20 > > Emergency calls need to identify the location from=20 > which the call is > > initiated (Section 5). The caller location needs to be=20 > identified > > for two purposes, namely to route the call to the=20 > appropriate PSAP > > and to display the caller location to the call taker to simplify > > dispatching emergency assistance to the correct location. >=20 >=20 >=20 >=20 > >=20 > > Emergency calls need to be identified (Section 6). Emergency > > identifiers are used by the emergency caller to declare=20 > a call to be > > an emergency call. =20 > >=20 > > Emergency calls need to be routed to the appropriate PSAP (ref. > > Section 6). =20 >=20 > > Emergency calls need to identify who placed the call=20 > (Section 7).=20 >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 09 15:59:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2aFj-0002U3-9C; Tue, 09 Aug 2005 15:59:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2aFh-0002Tm-Lr for ecrit@megatron.ietf.org; Tue, 09 Aug 2005 15:59:09 -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 PAA04759 for ; Tue, 9 Aug 2005 15:59:07 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2ane-00035H-I3 for ecrit@ietf.org; Tue, 09 Aug 2005 16:34:16 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j79Jwmsa004065; Tue, 9 Aug 2005 12:58:49 -0700 (PDT) Received: from [10.30.5.108] (vpn-10-50-0-123.qualcomm.com [10.50.0.123]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j79JwkVG025378; Tue, 9 Aug 2005 12:58:46 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 9 Aug 2005 12:58:43 -0700 To: "Tschofenig, Hannes" , From: Ted Hardie Subject: Re: [Ecrit] High-Level Requirements section () Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 11:19 AM +0200 8/9/05, Tschofenig, Hannes wrote: > R6. Incremental Deployment The output of the ECRIT mapping protocol > will be one or more URIs that can be used as the target of an > emergency communication. These must be usable by an appropriately > capable device even if that device has no knowledge of the mapping > protocol. As an example, if the mapping protocol returns a SIP > URI any SIP-capable phone should be able to use it as a target of > the call; no special extension to SIP should be required. > > ># R6 does not seem to be a requirement or it is, at the moment, not >phrased as one. > The requirement is that what the mapping protocol returns be in the standard format for the communication protocol; that is, it should return something in a SIP context that *any* SIP capable phone would be able to use--it should not have special purpose URIs or schemes as its output, since those would not be understood by "legacy" SIP devices. I think it is reasonably clear on that point. In some sense it is a constraint rather than a requirement, but I think it is important to capture somewhere. regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Aug 11 09:30:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3D8h-0001JU-Ud; Thu, 11 Aug 2005 09:30:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3D8g-0001JP-B6 for ecrit@megatron.ietf.org; Thu, 11 Aug 2005 09:30:30 -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 JAA01537 for ; Thu, 11 Aug 2005 09:30:28 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Dgz-0004tB-AA for ecrit@ietf.org; Thu, 11 Aug 2005 10:05:58 -0400 Received: from [10.0.1.2] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 11 Aug 2005 09:30:24 -0400 id 00124782.42FB52F1.000049AE Mime-Version: 1.0 (Apple Message framework v733) Content-Transfer-Encoding: 7bit Message-Id: <4460AB84-6BA7-410C-8A68-773F045B62C6@hxr.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Andrew Newton Date: Thu, 11 Aug 2005 09:30:25 -0400 X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: [Ecrit] More on L6 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Or, I guess, this could be a new one as Roger has suggested in the past, or perhaps this in an Ix. Signaling of Wrong Location: For the purposes of validation of location, the mapping protocol SHOULD provide the capability to signal reasons why a location is invalid, either through descriptive text or predefined error values or both. This protocol feature MUST NOT impose upon the primary function of the mapping protocol to convert location information to URIs. And semi-related to location validation, another one that might go in the I section: Default URIs: The mapping protocol MUST be capable of providing a default set of URIs when given an invalid location. Motivation: If the a mapping service is given the address 123 Maple St. but no Maple St. exists within the city, it should still be capable of providing a set of URIs to a PSAP deemed most appropriate for that location. The determination of this default or most appropriate set of URIs is a matter of local policy. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Aug 11 09:46:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3DOD-0004P8-W9; Thu, 11 Aug 2005 09:46:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3DOC-0004Ov-H2 for ecrit@megatron.ietf.org; Thu, 11 Aug 2005 09:46:32 -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 JAA02254 for ; Thu, 11 Aug 2005 09:46:30 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3DwU-0005Gr-BQ for ecrit@ietf.org; Thu, 11 Aug 2005 10:22:00 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j7BDkHUD024977; Thu, 11 Aug 2005 15:46:17 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j7BDkHxB004794; Thu, 11 Aug 2005 15:46:17 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 11 Aug 2005 15:46:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] High-Level Requirements section () Date: Thu, 11 Aug 2005 15:46:12 +0200 Message-ID: Thread-Topic: [Ecrit] High-Level Requirements section () Thread-Index: AcWdHNAEvBOqoYY0RJ2fP11HApRFbABXjYzQ From: "Tschofenig, Hannes" To: "Ted Hardie" , X-OriginalArrivalTime: 11 Aug 2005 13:46:12.0598 (UTC) FILETIME=[09692960:01C59E7B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi ted,=20 what about the following text: > -----Urspr=FCngliche Nachricht----- > Von: Ted Hardie [mailto:hardie@qualcomm.com]=20 > Gesendet: Dienstag, 9. August 2005 21:59 > An: Tschofenig, Hannes; ecrit@ietf.org > Betreff: Re: [Ecrit] High-Level Requirements section=20 > () >=20 >=20 > At 11:19 AM +0200 8/9/05, Tschofenig, Hannes wrote: > > R6. Incremental Deployment The output of the ECRIT=20 > mapping protocol > > will be one or more URIs that can be used as the target of an > > emergency communication. These must be usable by an=20 > appropriately > > capable device even if that device has no knowledge of=20 > the mapping > > protocol. As an example, if the mapping protocol returns a SIP > > URI any SIP-capable phone should be able to use it as=20 > a target of > > the call; no special extension to SIP should be required. > > > > > ># R6 does not seem to be a requirement or it is, at the moment, not > >phrased as one. > > >=20 > The requirement is that what the mapping protocol returns be in > the standard format for the communication protocol; that is,=20 > it should return > something in a SIP context that *any* SIP capable phone would=20 > be able to use--it > should not have special purpose URIs or schemes as its output, since > those would not be understood by "legacy" SIP devices. I=20 > think it is reasonably > clear on that point. In some sense it is a constraint rather=20 > than a requirement, > but I think it is important to capture somewhere. > regards, > Ted Hardie >=20 >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Aug 11 09:48:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3DQ4-00051Y-2e; Thu, 11 Aug 2005 09:48:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3DQ3-00051Q-0A for ecrit@megatron.ietf.org; Thu, 11 Aug 2005 09:48:27 -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 JAA02378 for ; Thu, 11 Aug 2005 09:48:25 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3DyL-0005J8-PN for ecrit@ietf.org; Thu, 11 Aug 2005 10:23:55 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j7BDmFhe012666; Thu, 11 Aug 2005 15:48:16 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j7BDmFlh010187; Thu, 11 Aug 2005 15:48:15 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 11 Aug 2005 15:48:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] High-Level Requirements section () Date: Thu, 11 Aug 2005 15:48:15 +0200 Message-ID: Thread-Topic: [Ecrit] High-Level Requirements section () Thread-Index: AcWdHNAEvBOqoYY0RJ2fP11HApRFbABXlEsg From: "Tschofenig, Hannes" To: "Ted Hardie" , X-OriginalArrivalTime: 11 Aug 2005 13:48:15.0576 (UTC) FILETIME=[52B61D80:01C59E7B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi ted,=20 what about the following text?=20 " R6. Incremental Deployment: The ECRIT mapping protocol MUST return at least one URI that is useable = by a standard signaling protocol (i.e., without special emergency = extensions) unless an error is returned. =20 Motivation:=20 The format of the output returned by the mapping protocol is, for = example, a URI that can be used by any SIP capable phone. Special = purpose URIs would not be understood by "legacy" SIP devices since they = do not have knowledge about the mapping protocol. " ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: Ted Hardie [mailto:hardie@qualcomm.com]=20 > Gesendet: Dienstag, 9. August 2005 21:59 > An: Tschofenig, Hannes; ecrit@ietf.org > Betreff: Re: [Ecrit] High-Level Requirements section=20 > () >=20 >=20 > At 11:19 AM +0200 8/9/05, Tschofenig, Hannes wrote: > > R6. Incremental Deployment The output of the ECRIT=20 > mapping protocol > > will be one or more URIs that can be used as the target of an > > emergency communication. These must be usable by an=20 > appropriately > > capable device even if that device has no knowledge of=20 > the mapping > > protocol. As an example, if the mapping protocol returns a SIP > > URI any SIP-capable phone should be able to use it as=20 > a target of > > the call; no special extension to SIP should be required. > > > > > ># R6 does not seem to be a requirement or it is, at the moment, not > >phrased as one. > > >=20 > The requirement is that what the mapping protocol returns be in > the standard format for the communication protocol; that is,=20 > it should return > something in a SIP context that *any* SIP capable phone would=20 > be able to use--it > should not have special purpose URIs or schemes as its output, since > those would not be understood by "legacy" SIP devices. I=20 > think it is reasonably > clear on that point. In some sense it is a constraint rather=20 > than a requirement, > but I think it is important to capture somewhere. > regards, > Ted Hardie >=20 >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Aug 11 13:35:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3GxI-0000LS-J7; Thu, 11 Aug 2005 13:35:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3GxG-0000Jz-Hc for ecrit@megatron.ietf.org; Thu, 11 Aug 2005 13:34:58 -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 NAA15679 for ; Thu, 11 Aug 2005 13:34:56 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3HVb-00034w-2m for ecrit@ietf.org; Thu, 11 Aug 2005 14:10:29 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j7BHYYS0014198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 Aug 2005 10:34:35 -0700 (PDT) Received: from [10.30.5.108] (vpn-10-50-0-51.qualcomm.com [10.50.0.51]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j7BHYWVG000601; Thu, 11 Aug 2005 10:34:32 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 11 Aug 2005 10:34:28 -0700 To: "Tschofenig, Hannes" , From: Ted Hardie Subject: Re: AW: [Ecrit] High-Level Requirements section () Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by numenor.qualcomm.com id j7BHYYS0014198 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 3:48 PM +0200 8/11/05, Tschofenig, Hannes wrote: >hi ted, > >what about the following text? > >" >R6. Incremental Deployment: > >The ECRIT mapping protocol MUST return at least one URI that is useable = by a standard signaling protocol (i.e., without special emergency extensi= ons) unless an error is returned.=20 I think this changes the sense. I still believe we're saying "the URIs r= eturned should require no knowledge of special emergency extensions"; why should we say only one of the URIs returned must have this property? regards, Ted >Motivation: > >The format of the output returned by the mapping protocol is, for exampl= e, a URI that can be used by any SIP capable phone. Special purpose URIs = would not be understood by "legacy" SIP devices since they do not have kn= owledge about the mapping protocol. >" > >ciao >hannes > > >> -----Urspr=FCngliche Nachricht----- >> Von: Ted Hardie [mailto:hardie@qualcomm.com] >> Gesendet: Dienstag, 9. August 2005 21:59 >> An: Tschofenig, Hannes; ecrit@ietf.org >> Betreff: Re: [Ecrit] High-Level Requirements section >> () >> >> >> At 11:19 AM +0200 8/9/05, Tschofenig, Hannes wrote: >> > R6. Incremental Deployment The output of the ECRIT >> mapping protocol >> > will be one or more URIs that can be used as the target of an >> > emergency communication. These must be usable by an >> appropriately >> > capable device even if that device has no knowledge of >> the mapping >> > protocol. As an example, if the mapping protocol returns a SIP >> > URI any SIP-capable phone should be able to use it as >> a target of >> > the call; no special extension to SIP should be required. >> > >> > >> ># R6 does not seem to be a requirement or it is, at the moment, not >> >phrased as one. >> > >> >> The requirement is that what the mapping protocol returns be in >> the standard format for the communication protocol; that is, >> it should return >> something in a SIP context that *any* SIP capable phone would >> be able to use--it >> should not have special purpose URIs or schemes as its output, since >> those would not be understood by "legacy" SIP devices. I >> think it is reasonably >> clear on that point. In some sense it is a constraint rather >> than a requirement, >> but I think it is important to capture somewhere. >> regards, >> Ted Hardie >> >> >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Aug 11 16:08:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3JLV-0001La-Dh; Thu, 11 Aug 2005 16:08:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3JLT-0001LT-PA for ecrit@megatron.ietf.org; Thu, 11 Aug 2005 16:08:07 -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 QAA24909 for ; Thu, 11 Aug 2005 16:08:05 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Jtn-0007Vn-9b for ecrit@ietf.org; Thu, 11 Aug 2005 16:43:38 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j7BK7qhJ022025; Thu, 11 Aug 2005 22:07:52 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j7BK7qNs012087; Thu, 11 Aug 2005 22:07:52 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 11 Aug 2005 22:06:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: AW: [Ecrit] High-Level Requirements section () Date: Thu, 11 Aug 2005 22:06:49 +0200 Message-ID: Thread-Topic: AW: [Ecrit] High-Level Requirements section () Thread-Index: AcWemwCcvZT/zNzLRJagGngXZsU8uwAFOfGw From: "Tschofenig, Hannes" To: "Ted Hardie" , X-OriginalArrivalTime: 11 Aug 2005 20:06:50.0398 (UTC) FILETIME=[35CCE3E0:01C59EB0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi ted,=20 you are right. here is another try:=20 " R6. Incremental Deployment: The ECRIT mapping protocol MUST return URIs that=20 are useable by a standard signaling protocol (i.e., without=20 special emergency extensions) unless an error is returned.=20 " ciao hannes > At 3:48 PM +0200 8/11/05, Tschofenig, Hannes wrote: > >hi ted, > > > >what about the following text? > > > >" > >R6. Incremental Deployment: > > > >The ECRIT mapping protocol MUST return at least one URI that=20 > is useable by a standard signaling protocol (i.e., without=20 > special emergency extensions) unless an error is returned.=20 >=20 > I think this changes the sense. I still believe we're saying=20 > "the URIs returned should > require no knowledge of special emergency extensions"; why=20 > should we say > only one of the URIs returned must have this property? >=20 > regards, > Ted >=20 > >Motivation: > > > >The format of the output returned by the mapping protocol=20 > is, for example, a URI that can be used by any SIP capable=20 > phone. Special purpose URIs would not be understood by=20 > "legacy" SIP devices since they do not have knowledge about=20 > the mapping protocol. > >" > > > >ciao > >hannes > > > > > >> -----Urspr=FCngliche Nachricht----- > >> Von: Ted Hardie [mailto:hardie@qualcomm.com] > >> Gesendet: Dienstag, 9. August 2005 21:59 > >> An: Tschofenig, Hannes; ecrit@ietf.org > >> Betreff: Re: [Ecrit] High-Level Requirements section > >> () > >> > >> > >> At 11:19 AM +0200 8/9/05, Tschofenig, Hannes wrote: > >> > R6. Incremental Deployment The output of the ECRIT > >> mapping protocol > >> > will be one or more URIs that can be used as the=20 > target of an > >> > emergency communication. These must be usable by an > >> appropriately > >> > capable device even if that device has no knowledge of > >> the mapping > >> > protocol. As an example, if the mapping protocol=20 > returns a SIP > >> > URI any SIP-capable phone should be able to use it as > >> a target of > >> > the call; no special extension to SIP should be required. > >> > > >> > > >> ># R6 does not seem to be a requirement or it is, at the=20 > moment, not > >> >phrased as one. > >> > > >> > >> The requirement is that what the mapping protocol returns be in > >> the standard format for the communication protocol; that is, > >> it should return > >> something in a SIP context that *any* SIP capable phone would > >> be able to use--it > >> should not have special purpose URIs or schemes as its=20 > output, since > >> those would not be understood by "legacy" SIP devices. I > >> think it is reasonably > >> clear on that point. In some sense it is a constraint rather > >> than a requirement, > >> but I think it is important to capture somewhere. > >> regards, > >> Ted Hardie > >> > >> > >> >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Aug 11 23:54:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Qcf-0006Pp-Ig; Thu, 11 Aug 2005 23:54:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Qcd-0006Pk-Mj for ecrit@megatron.ietf.org; Thu, 11 Aug 2005 23:54:20 -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 XAA16568 for ; Thu, 11 Aug 2005 23:54:17 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3RB5-00037I-73 for ecrit@ietf.org; Fri, 12 Aug 2005 00:29:55 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 11 Aug 2005 20:54:10 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7C3s2QM008588; Thu, 11 Aug 2005 20:54:02 -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); Thu, 11 Aug 2005 20:54:05 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.122.8]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 20:54:04 -0700 Message-Id: <4.3.2.7.2.20050811224913.035cbf08@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 11 Aug 2005 22:54:03 -0500 To: Andrew Newton , Roger Marshall From: "James M. Polk" Subject: Re: [Ecrit] comments on ECRIT requirements In-Reply-To: References: <8C837214C95C864C9F34F3635C2A657502D927C4@SEA-EXCHVS-2.telecomsys.com> <8C837214C95C864C9F34F3635C2A657502D927C4@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 12 Aug 2005 03:54:04.0921 (UTC) FILETIME=[7BAD9E90:01C59EF1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 03:34 AM 8/6/2005 -0400, Andrew Newton wrote: >Roger, > >Thanks for doing the hard work. > >My comments are in-line: > >On Aug 6, 2005, at 3:05 AM, Roger Marshall wrote: >>Comments to A6: I think we all have a sense of what >>backward-compatibility means, which (at least to me) would equate >>to the >>idea that whatever protocol that ecrit comes up with for emergency >>routing, that it'll work for legacy (pre-ecrit) handsets. >> >>Perhaps a simpler, alternate wording is in order, such as: >> >>A6. Backward-compatible:"> Emergency routing protocols and functions >>MUST be backward-compatible for use with existing devices. > >I still do not understand this requirement. I also do not understand this requirement (now). >If this working group >creates a method for emergency call routing that does not already >exist, which is the purpose of this group, then by definition it will >not be backwards compatible with existing devices. When I read this >requirement, to me it indicates that we either are not producing a >new standards track document or we should close down the working group. > >Perhaps there needs to be more definition with regard to the meaning >of "backward-compatible". I agree here - maybe we need to define first exactly what this phrase means to everyone. Is it backwards-compatible message routing? Is it backwards-compatible signaling protocol and which extensions? meaning: for SIP, is it only 3261 elements, or 3261 plus the 34 PS-RFCs since 3261? Is it backwards-compatible addressing? Which, or all 3? >-andy > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Aug 12 11:57:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3buZ-000191-HB; Fri, 12 Aug 2005 11:57:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3buY-00018u-Jm for ecrit@megatron.ietf.org; Fri, 12 Aug 2005 11:57:34 -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 LAA02425 for ; Fri, 12 Aug 2005 11:57:31 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3cT5-0005dv-4a for ecrit@ietf.org; Fri, 12 Aug 2005 12:33:16 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Fri, 12 Aug 2005 11:57:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] comments on ECRIT requirements Date: Fri, 12 Aug 2005 08:57:14 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657502E241AA@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] comments on ECRIT requirements Thread-Index: AcWe8YBKwE1VK6u1SrKoin8LQrILjQAY4VEg From: "Roger Marshall" To: "James M. Polk" , "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org All: In reference to comments received on requirement A6 "Backward-Compatible", I will considering deleting this from the draft if there is no champion for it. It is problematic to me for the following reasons: Definition of the term to everyone's satisfaction may be difficult, since the term's use has a wide breadth of use. Lack of clarity as to the essential meaning of the term, as James points out. Is it backward-compatible message routing? Signaling protocol, or addressing? Roger Marshall -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com]=20 Sent: Thursday, August 11, 2005 8:54 PM To: Andrew Newton; Roger Marshall Cc: ECRIT Subject: Re: [Ecrit] comments on ECRIT requirements At 03:34 AM 8/6/2005 -0400, Andrew Newton wrote: >Roger, > >Thanks for doing the hard work. > >My comments are in-line: > >On Aug 6, 2005, at 3:05 AM, Roger Marshall wrote: >>Comments to A6: I think we all have a sense of what >>backward-compatibility means, which (at least to me) would equate >>to the >>idea that whatever protocol that ecrit comes up with for emergency >>routing, that it'll work for legacy (pre-ecrit) handsets. >> >>Perhaps a simpler, alternate wording is in order, such as: >> >>A6. Backward-compatible:"> Emergency routing protocols and functions >>MUST be backward-compatible for use with existing devices. > >I still do not understand this requirement. I also do not understand this requirement (now). >If this working group >creates a method for emergency call routing that does not already >exist, which is the purpose of this group, then by definition it will >not be backwards compatible with existing devices. When I read this >requirement, to me it indicates that we either are not producing a >new standards track document or we should close down the working group. > >Perhaps there needs to be more definition with regard to the meaning >of "backward-compatible". I agree here - maybe we need to define first exactly what this phrase means=20 to everyone. Is it backwards-compatible message routing? Is it backwards-compatible signaling protocol and which extensions? meaning: for SIP, is it only 3261 elements, or 3261 plus the 34 PS-RFCs=20 since 3261? Is it backwards-compatible addressing? Which, or all 3? >-andy > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Aug 15 02:20:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4YKL-0004vD-1q; Mon, 15 Aug 2005 02:20:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4YKK-0004tx-6S for ecrit@megatron.ietf.org; Mon, 15 Aug 2005 02:20:04 -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 CAA15121 for ; Mon, 15 Aug 2005 02:20:00 -0400 (EDT) Received: from sv7.prth.eftel.com ([203.24.100.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4YtK-0006fq-M8 for ecrit@ietf.org; Mon, 15 Aug 2005 02:56:16 -0400 Received: from [127.0.0.1] (dialup-1-212.MelbournePwrtl2.dft.com.au [203.123.89.212]) by sv7.prth.eftel.com (Postfix) with ESMTP id D830B1438AA; Mon, 15 Aug 2005 14:19:48 +0800 (WST) Message-ID: <430033F6.2050907@bigfoot.com.au> Date: Mon, 15 Aug 2005 16:19:34 +1000 From: Barry Dingle User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit X-Spam-Score: 1.0 (+) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: [Ecrit] Text requirements in draft-schulzrinne-ecrit-requirements-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1898571564==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============1898571564== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All,

I have just been made aware of this group and the  draft-schulzrinne-ecrit-requirements-01 document. I have been involved with ToIP so some comments.

I agree with comments of Hannes and Henning regarding making the Introduction less repetitive. As part of the deletions, a mixed message about IM and RFC3351 was removed.

However, it may be worth still referencing RFC 3351 for informational purposes. Another reference that may be of interest is  the draft requirements for ToIP (see http://www.ietf.org/internet-drafts/draft-ietf-sipping-toip-01.txt ) that is in its final stages of editing. ToIP is designed to provide a real-time text conversation service that meets user performance requirements and overcomes packet loss with in-built redundancy. It is consistent with RFC3351.

I agree with Henning that the IM versus ToIP debate should not be repeated in this WG, however, it may be worth noting the new ToIP RFC - RFC4103 "RTP Payload for Text Conversation" - and maybe referencing it when talking about 'conversation text'. ToIP meets the ToIP requirements. ToIP is also completely consistent with VoIP as it uses SIP (unchanged), SDP (adds media type 'text/t140') and RTP (as described in RFC4103).

-----
Terminology section - the Application Service Provider refers to 'conversational text' as a 'future requirement'. This is inconsistent with Requirement R4. I suggest that the words "in the future" be deleted.

Requirement R4 - The term TDD is not used much. Most people use the terms TTY or textphone. In addition, the wording of R4 needs more clarity. I suggest that the Motivation: read -
"Emergency calling must support a variety of media, not just traditional voice and text using a textphone/TTY, including conversational text, instant messaging and video. In addition, it should be possible to convey telemetry data, such as data from automobile crash sensors."

(BTW - ToIP would be an ideal way to transfer crash sensor information.)

Cheers,
/Barry
Barry DINGLE
Telecommunications Consultant
Fellow of the University of Melbourne
Chair - ACIF Customer Equipment and Cable Reference Panel (CECRP) 
    barry.dingle@bigfoot.com.au
  Mob:   +61 (0)41 911 7578
  Fixed: +61 (0)3 9725 3937
--===============1898571564== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1898571564==-- From ecrit-bounces@ietf.org Wed Aug 17 04:37:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5JQB-0002UJ-K1; Wed, 17 Aug 2005 04:37:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5JQB-0002UE-8O for ecrit@megatron.ietf.org; Wed, 17 Aug 2005 04:37:15 -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 EAA15392 for ; Wed, 17 Aug 2005 04:37:13 -0400 (EDT) Received: from s50.loopia.se ([194.9.94.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Jzg-0007ye-J5 for ecrit@ietf.org; Wed, 17 Aug 2005 05:13:57 -0400 Received: (qmail 23831 invoked from network); 17 Aug 2005 08:37:04 -0000 Received: from 136.240.13.217.in-addr.dgcsystems.net (HELO vit) ([217.13.240.136]) (envelope-sender ) by s50.loopia.se (qmail-ldap-1.03) with SMTP for ; 17 Aug 2005 08:37:04 -0000 From: "Gunnar Hellstrom" To: Subject: Re: [Ecrit] introduction section () Date: Wed, 17 Aug 2005 10:37:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 7bit X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I want to suggest to sharpen up wording about other media than voice. There is one part of the introduction about this topic that needs sharpening and there is another later specifically on other media. This is my proposed wording of these sections: 1. In 1. Introduction: ------------------------------------------------------------------------ --------- "Users of other real-time and near real-time services also expect to be able to summon emergency help. For example, instant messaging (IM) and real time text users want to use such services. IM and real time text are particularly helpful for hearing-disabled users (RFC 3351 [4]), when there is a need for exactness as for example for spelling out names and addresses and in cases where bandwidth is scarce." 3. In 3. High Level requirements ------------------------------------------------------------------------ ---------- "R4. Multiple Modes: Multiple communication modes, including Multimedia data and services MUST be supported. Motivation: In PSTN, voice and text telephony ( often called TTY or TDD in North America ) are the only commonly supported media. Emergency calling must support a variety of media. Such media should include voice, conversational text, instant messaging and video. It should also be possible to involve relay services in the call for translation between different modes. It should be possible to connect the relay service so that the direct flow of media to the emergency service is maintained. In addition, it should be possible to convey telemetry data, such as data from automobile crash sensors. " I hope you find them useful. Motivations for the proposed modifications: a. Real time text and IM are not for the future. They are here now, and their older PSTN companion is used for emergency since long. We cannot leave a gap in service provision until some undefined future! b. There are clear observations that relay services are important to include in some calls for translation between different media. c. Mention both real time text and IM. The users should be provided with the service they use daily, also when they need to do the emergency call. They have different characteristics, and both will be used for different purposes or by different users. Regards Gunnar Hellstrom. ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- >-----Original Message----- >From: i-d-announce-bounces@ietf.org >[mailto:i-d-announce-bounces@ietf.org]On Behalf Of >Internet-Drafts@ietf.org >Sent: Monday, July 11, 2005 9:50 PM >To: i-d-announce@ietf.org >Subject: I-D ACTION:draft-schulzrinne-ecrit-requirements-01.txt > > >A New Internet-Draft is available from the on-line >Internet-Drafts directories. > > > Title : Requirements for Emergency Context >Resolution with Internet Technologies > Author(s) : H. Schulzrinne, R. Marshall > Filename : draft-schulzrinne-ecrit-requirements-01.txt > Pages : 23 > Date : 2005-7-11 > >This document enumerates requirements for emergency calls placed by > the public using voice-over-IP (VoIP) and general Internet >multimedia > systems, where Internet protocols are used end-to-end. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-req uirements-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-schulzrinne-ecrit-requirements-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-schulzrinne-ecrit-requirements-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Aug 18 12:06:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5muQ-0001vO-1j; Thu, 18 Aug 2005 12:06:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5muP-0001v9-HW for ecrit@megatron.ietf.org; Thu, 18 Aug 2005 12:06:25 -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 MAA14458 for ; Thu, 18 Aug 2005 12:06:23 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5nUA-0005Wz-KN for ecrit@ietf.org; Thu, 18 Aug 2005 12:43:24 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j7IG4F202548 for ; Thu, 18 Aug 2005 12:04:15 -0400 (EDT) Received: from [127.0.0.1] (acart095.ca.nortel.com [47.130.17.15]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RCFTNFHH; Thu, 18 Aug 2005 12:06:04 -0400 Message-ID: <4304B1D5.5030603@nortel.com> Date: Thu, 18 Aug 2005 12:05:41 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Subject: [Ecrit] Security requirements absorbed from pre-interim requirements document X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This note is just a record of decisions taken at the May interim meeting that affect the security requirements document. It's basic spadework preceding an update of that document. For starters, some of the requirements in draft-schulzrinne-ecrit-requirements-00.txt were considered to be security requirements. Here is the list, with comments from the minutes of the interim meeting: L24. Location Query Authorization: The ability to query emergency caller location using a location key MUST be limited to authorized end points. Motivation: Where the Emergency Caller does not desire the transmission of their location in-band with their call setup, they shall have the option of requesting a unique query key such that only authorized end points may query the location directly from the domain. Ted commented that the real requirement is that the user of the mapping function be able to protect location information from eavesdropping. I30: Routing information MUST be secured against unauthorized modification. PSAPs (or perhaps a higher level civic authority such as a county, state/province or national body) or their designated representative must be the only entities permitted to change routing information. D2. Assuring directory identity: The query agent (e.g UA or server) MUST be able to assure that it is querying the intended directory. D3. Query response integrity: The query agent MUST be able to be confident that the query or response has not been tampered with. D4. Assurance of Update integrity: Any update mechanism for the directory MUST ensure that only authorized users can change directory information and must keep an audit log of all change transactions. D4 was considered to be out of scope unless brought back into scope by the specific design chosen by the WG. S1. Authentication override: All outbound proxies and other call filtering elements MUST be able to be configured so that they allow unauthenticated emergency calls. In many jurisdictions, emergency calls can be placed by any device, regardless of whether it has subscribed for service. S4. Integrity: Implementations MUST provide mechanisms that ensure the integrity of IP protocol components that are crucial to providing reliable emergency call service. (This requirement implies authentication of the caller to allow integrity protection of the request and authentication of the PSAP to allow integrity protection of responses.) [Ed. changed "SIP protocol component" to "IP protocol components". This requirement is not well understood based on comments received. Further clarification requested.] 11. Security Considerations Note: Security Considerations originally described in this section have removed and will be resubmitted to the ECRIT security document. No reference yet available. SEC1. Safeguards from Attacks: Safeguards SHOULD be provided to assure against network system attacks. Motivation: Safeguards to protect the emergency infrastructure and ECC facilities against malicious attacks, especially to prevent DoS attacks. SEC2. Denial of Service attacks: Special consideration SHOULD be given to "Distributed Denial of Service" attacks. SEC3 Protocols MUST NOT facilitate denial-of-service attacks, e.g., by amplifying incoming unauthenticated messages. [Ed. (per hgs, suggested replacement above first two requirements with third requirement.] What follows is action items extracted from the portion of the minutes dealing specifically with the security document. "Chart x" refers to charts at http://www.ietf-ecrit.org/Interim2005/ecrit-security.ppt. - Terminology to be updated to match the requirements document. - chart 3: key point is that caller identity is irrelevant for routing, but is needed for accountability (Chart 6 seems to agree.) - chart 8: second part out of scope - chart 10 mostly out of scope - chart 11, impersonation of PSAP: out of scope Out of the discussion, an action to identify the protocol-specific security requirements and report them to the list. (Presumably I am picking up this action as editor of the security threats document.) Tom Taylor _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Aug 18 14:02:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5oip-0002tc-T3; Thu, 18 Aug 2005 14:02:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5oio-0002tU-5L for ecrit@megatron.ietf.org; Thu, 18 Aug 2005 14:02:34 -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 OAA20687 for ; Thu, 18 Aug 2005 14:02:33 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5pIa-0000ca-IW for ecrit@ietf.org; Thu, 18 Aug 2005 14:39:33 -0400 Received: from [10.0.1.4] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 18 Aug 2005 14:02:31 -0400 id 000C7DBA.4304CD37.000035C8 In-Reply-To: <4304B1D5.5030603@nortel.com> References: <4304B1D5.5030603@nortel.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Security requirements absorbed from pre-interim requirements document Date: Thu, 18 Aug 2005 14:02:36 -0400 To: Tom-PT Taylor X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Aug 18, 2005, at 12:05 PM, Tom-PT Taylor wrote: > This note is just a record of decisions taken at the May interim > meeting that affect the security requirements document. It's basic > spadework preceding an update of that document. Are you looking for comments on these items now, or do you want us to wait until the draft is written? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Aug 18 14:57:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5pZp-0007aI-Ey; Thu, 18 Aug 2005 14:57:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5pZn-0007Zf-4s for ecrit@megatron.ietf.org; Thu, 18 Aug 2005 14:57:20 -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 OAA23446 for ; Thu, 18 Aug 2005 14:57:17 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5q9Z-0002CL-T6 for ecrit@ietf.org; Thu, 18 Aug 2005 15:34:19 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j7IIutD20536; Thu, 18 Aug 2005 14:56:55 -0400 (EDT) Received: from [127.0.0.1] (acart095.ca.nortel.com [47.130.17.15]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RCFTNGT1; Thu, 18 Aug 2005 14:56:56 -0400 Message-ID: <4304D9E7.5050703@nortel.com> Date: Thu, 18 Aug 2005 14:56:39 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Security requirements absorbed from pre-interim requirements document References: <4304B1D5.5030603@nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I suppose it would be a more efficient use of people's time if we focus on the re-issued I-D. I'll try to have that out in a day or so. Andrew Newton wrote: > > On Aug 18, 2005, at 12:05 PM, Tom-PT Taylor wrote: > >> This note is just a record of decisions taken at the May interim >> meeting that affect the security requirements document. It's basic >> spadework preceding an update of that document. > > > Are you looking for comments on these items now, or do you want us to > wait until the draft is written? > > -andy > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Aug 19 10:37:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E67zr-0005eq-99; Fri, 19 Aug 2005 10:37:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E67zq-0005el-HW for ecrit@megatron.ietf.org; Fri, 19 Aug 2005 10:37:26 -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 KAA06939 for ; Fri, 19 Aug 2005 10:37:23 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E68Zn-0002oG-L0 for ecrit@ietf.org; Fri, 19 Aug 2005 11:14:36 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 19 Aug 2005 07:37:17 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j7JEaVZb005577; Fri, 19 Aug 2005 07:37:14 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 Aug 2005 10:37:08 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Ecrit] Security requirements absorbed from pre-interimrequirements document Date: Fri, 19 Aug 2005 10:37:07 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E374CBB0@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Security requirements absorbed from pre-interimrequirements document Thread-Index: AcWkDwZhcItmW6ZPRTi0Kh6AMpZ/uAAvCE7w From: "Michael Hammer \(mhammer\)" To: "Tom-PT Taylor" , X-OriginalArrivalTime: 19 Aug 2005 14:37:08.0606 (UTC) FILETIME=[7A3CF9E0:01C5A4CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tom, Can you put this comment into the queue for the draft: =20 > S4. Integrity: Implementations MUST provide mechanisms=20 > that ensure > the integrity of IP protocol components that are crucial to > providing reliable emergency call service. (This requirement > implies authentication of the caller to allow=20 > integrity protection > of the request and authentication of the PSAP to allow=20 > integrity > protection of responses.) Do not intertwine integrity with authentication. You can integrity protect a communications without knowing who you are communicating with. Mike _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Aug 19 10:55:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E68H7-0001la-HK; Fri, 19 Aug 2005 10:55:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E68H6-0001lV-JC for ecrit@megatron.ietf.org; Fri, 19 Aug 2005 10:55:16 -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 KAA08004 for ; Fri, 19 Aug 2005 10:55:13 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E68qz-0003Nm-9m for ecrit@ietf.org; Fri, 19 Aug 2005 11:32:27 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j7JEfhs23590; Fri, 19 Aug 2005 10:41:43 -0400 (EDT) Received: from [127.0.0.1] (acart542.ca.nortel.com [47.130.17.199]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RCFTNKJA; Fri, 19 Aug 2005 10:43:32 -0400 Message-ID: <4305F001.7060104@nortel.com> Date: Fri, 19 Aug 2005 10:43:13 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Ecrit] Security requirements absorbed from pre-interimrequirements document References: <072C5B76F7CEAB488172C6F64B30B5E374CBB0@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E374CBB0@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Agreed. Michael Hammer (mhammer) wrote: > Tom, > > Can you put this comment into the queue for the draft: > > >> S4. Integrity: Implementations MUST provide mechanisms >>that ensure >> the integrity of IP protocol components that are crucial to >> providing reliable emergency call service. (This requirement >> implies authentication of the caller to allow >>integrity protection >> of the request and authentication of the PSAP to allow >>integrity >> protection of responses.) > > > Do not intertwine integrity with authentication. You can integrity > protect a communications without knowing who you are communicating with. > > Mike > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Aug 22 13:23:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7G0w-0005io-Ot; Mon, 22 Aug 2005 13:23:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7G0w-0005id-7X for ecrit@megatron.ietf.org; Mon, 22 Aug 2005 13:23:14 -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 NAA29490 for ; Mon, 22 Aug 2005 13:23:11 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7GbX-0008CG-MI for ecrit@ietf.org; Mon, 22 Aug 2005 14:01:04 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Mon, 22 Aug 2005 13:22:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] introduction section() Date: Mon, 22 Aug 2005 10:22:53 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657502F2449F@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] introduction section() Thread-Index: AcWjBywFSORuZVobSNet7PXEBrZyXwENoEFw From: "Roger Marshall" To: "Gunnar Hellstrom" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Gunnar: These points are well made. I've incorporated the bulk of your suggestions outlined below into the next version of the requirements ECRIT wg document, which I hope to have out very soon. Roger Marshall > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Gunnar Hellstrom > Sent: Wednesday, August 17, 2005 1:37 AM > To: ecrit@ietf.org > Subject: Re: [Ecrit] introduction section( requirements-01.txt>) >=20 > I want to suggest to sharpen up wording about other media than voice. > There is one part of the introduction about this topic that needs > sharpening and there is another later specifically on other media. >=20 > This is my proposed wording of these sections: >=20 > 1. In 1. Introduction: > ------------------------------------------------------------------------ > --------- > "Users of other real-time and near real-time services > also expect to be able to summon emergency help. For example, > instant messaging (IM) and real time text users want to use such > services. IM and real time text are particularly helpful for > hearing-disabled users (RFC 3351 [4]), when there is a need for > exactness as for example for spelling out names and addresses and in > cases where bandwidth is scarce." >=20 >=20 > 3. In 3. High Level requirements > ------------------------------------------------------------------------ > ---------- >=20 > "R4. Multiple Modes: Multiple communication modes, including > Multimedia data and services MUST be supported. > Motivation: In PSTN, voice and text telephony > ( often called TTY or TDD in North America ) are the only commonly > supported media. > Emergency calling must support a variety of media. Such > media should include voice, conversational text, instant > messaging and video. >=20 > It should also be possible to involve relay services in the call > for translation between different modes. It should be possible > to connect the relay service so that the direct flow of media > to the emergency service is maintained. > In addition, it should be possible to convey telemetry data, > such as data from automobile crash sensors. " >=20 >=20 > I hope you find them useful. > Motivations for the proposed modifications: >=20 > a. Real time text and IM are not for the future. They are here now, and > their older PSTN companion is used for emergency since long. We cannot > leave a gap in service provision until some undefined future! >=20 > b. There are clear observations that relay services are important to > include in some calls for translation between different media. >=20 >=20 > c. Mention both real time text and IM. The users should be provided with > the service they use daily, also when they need to do the emergency > call. They have different characteristics, and both will be used for > different purposes or by different users. >=20 > Regards >=20 > Gunnar Hellstrom. > ------------------------------------------- > Gunnar Hellstrom > Omnitor AB > Renathvagen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- >=20 >=20 > >-----Original Message----- > >From: i-d-announce-bounces@ietf.org > >[mailto:i-d-announce-bounces@ietf.org]On Behalf Of > >Internet-Drafts@ietf.org > >Sent: Monday, July 11, 2005 9:50 PM > >To: i-d-announce@ietf.org > >Subject: I-D ACTION:draft-schulzrinne-ecrit-requirements-01.txt > > > > > >A New Internet-Draft is available from the on-line > >Internet-Drafts directories. > > > > > > Title : Requirements for Emergency Context > >Resolution with Internet Technologies > > Author(s) : H. Schulzrinne, R. Marshall > > Filename : draft-schulzrinne-ecrit-requirements-01.txt > > Pages : 23 > > Date : 2005-7-11 > > > >This document enumerates requirements for emergency calls placed by > > the public using voice-over-IP (VoIP) and general Internet > >multimedia > > systems, where Internet protocols are used end-to-end. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-req > uirements-01.txt >=20 > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-schulzrinne-ecrit-requirements-01.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-schulzrinne-ecrit-requirements-01.txt". >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 23 10:58:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7aET-0008OU-GP; Tue, 23 Aug 2005 10:58:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7aEP-0008Ns-DZ; Tue, 23 Aug 2005 10:58:29 -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 KAA08895; Tue, 23 Aug 2005 10:58:26 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E7aEV-00072a-B6; Tue, 23 Aug 2005 10:58:37 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 23 Aug 2005 17:02:01 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B20C9@oefeg-s04.oefeg.loc> Thread-Topic: A proposal for closing the gap between i2 and i3 Thread-Index: AcWnO/hDWlh+1K+yRfyk7o2a1uI4mQApkRLQAAMpEHA= From: "Stastny Richard" To: "Brian Rosen" , "Dale Worley" , "sipping" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org Subject: [Ecrit] A proposal for closing the gap between i2 and i3 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Thank you Brian fort his comprehensive elaboration I just want to add a proposal Ecrit is working on a solution (i3 for short) allowing finally any IP-based device to access the responsible PSAP for the given location. Since (many) PSAPs on the other hand will not be reachable via IP for some time, as you say, there is work done on a national basis to allow VoIP providers to access the national specific emergency=20 system via national specific interfaces. This architecture (e.g i2 in the US) is different in every country. "Interconnected" VoIP providers (whatever that means) are required to interface to these systems, "not-interconnected" are not. This is not a good idea. On the other hand one cannot require from all VoIP providers to interface to 200 different national PSTN-emergency systems. So there is a substantial gap between i2 and i3. This situation could be substantially improved by providing national Emergency Service Routing Proxies (ESRP) doing the mapping between i3 and i2. The ESRP take the calls from VoIP providers and route it according to the location information given to the PSTN and the correct PSAP interfacing with the national emergency system The roadmap is very simple: The ecrit mapping database is loaded initially with the ESRP per country or state (e.g. in at.sos.arpa or ca.us.sos.arpa) The ESRP is doing the additional mapping via the location information given in the INVITE, in the beginning e.g. to the state emergency PSAP (this is as good as now) If a better location information is given, it can do better. Also, if PSAP appear on the Internet, their URIs are entered in the ecrit mapping database until in 10-20 years (just kidding) the ESRP can be shut down. The ESRP could also provide input to existing (also national specific) location databases (e.g. EISEC in UK) and also provide national virtual temporarily call-back numbers for VoIP users without E.164 numbers. The advantage of this method is a smooth migration and on the other hand an immediate availability of access to emergency calls from ALL VoIP providers (not "interconnected" and also alien) This will improve the situation substantially for the customer and also avoid the discussion what "interconnected" means. The investment for the ESRP is not so huge, the investment for the gateways is substantial and has to be funded (USF?) My question is: who may be responsible for guidelines on an international basis? -richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com =20 > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Tuesday, August 23, 2005 3:26 PM > To: 'Dale Worley'; 'sipping' > Subject: RE: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer >=20 > Couple of points to be made: >=20 > 1. The term PSAP is not US-centric. It appears in several other countries > lexicons. There is no universally accepted term, and the authors of > various > works on the subject have tried "Emergency Response Center" without much > success. PSAP will do. >=20 > 2. There is quite a bit of effort underway to develop new IP based > technology at the PSAP. It will probably be possible some day to have a > SIP > call terminate right at the call taker workstation. This requires > upgrades > at the PSAPs, and that is notoriously difficult to accomplish, primarily > (almost exclusively) because of funding issues. Unless you are prepared > to > state how new software, hardware and network connectivity, with > accompanying > processes, firewalls, training, etc is going to be paid for, then you > might > have to wait the usual decade (in the U.S., often longer elsewhere) until > every PSAP can terminate a SIP call. I have some optimism that there will > be some funding available in the U.S. I don't have any reason to be > optimistic at the moment elsewhere. Please also realize that, typically, > once a call is answered at a PSAP, it is transferred to the appropriate > responder(s). They too may need upgrades to their telephony systems. >=20 > 3. It is not trivial to connect SIP based VoIP callers to existing > systems, > although the difficulty varies quite a bit with the sophistication of the > emergency call network. In North America, it's pretty hard if it is > possible to roam, because existing systems assume the location of the > caller > is statically determinable from a database queried by the telephone > number, > or the carrier participates in a medium complexity scheme that allows a > dynamic location of the caller to be sent to the PSAP when it queries the > database. Also, emergency calls are NOT sent through the PSTN. In North > America, each switch (central office) has special trunks that connect to a > special tandem switch to which PSAPs are connected. In other countries > there is no need for a special tandem, but most use special trunks > directly > from the CO switch. You can use a relatively straightforward gateway > (typically SS7 signaling on the TDM side, sometimes, in North America, an > odd MF signaling standard called CAMA), but it connects to the 9-1-1 > tandem > (called a "selective router"), or directly to the PSAP. >=20 > There is a standard (called "i2") that NENA (the North American Emergency > Number Association) developed that does allow VoIP calls to be put into > the > current NA system correctly. It involves a couple of new databases > derived > from the existing one, a specialized service provider and gateways to the > Selective Routers. >=20 > 4. The ecrit work will provide a way to route a call to a SIP uri based on > the location of the caller. That is one of the key mechanisms required to > accomplish 1) above. The mechanism is not decided, but, roughly, you > query > a database with location, and it gives you a URI. Any entity could > implement that mechanism, even a P2P UA. Given a URI, that P2P UA could, > theoretically, route the call to the PSAP, where, again, theoretically, it > could be answered by the call taker. That implies that the PSAP > implements > P2P SIP, whatever that turns out to be as well as regular SIP, which is > the > current assumption. I would personally not consider that to be much of an > obstacle, but it depends on the complexity, security and other operational > issues that are unknown at the moment. >=20 > Brian >=20 > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf > Of Dale Worley > Sent: Monday, August 22, 2005 1:03 PM > To: 'sipping' > Subject: RE: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer >=20 > > From: Michael Hammer (mhammer) > > > > Absolutely! The Public Safety Access Points (PSAP or emergency call > > center -- a colleague reminded me that that is a US-centric term) might > > be able to use less expensive terminals (PC?), and would have a more > > rich environment to work with, IF they stop requiring backward > > compatibility with the PSTN-based systems. >=20 > That isn't a technological issue -- it would be straightforward to > overhaul > an emergency call center to handle incoming calls from a "SIP trunk", and > to > process the calls using workstations that are SIP UAs. For PSTN > compatibility, incoming PSTN trunks could be attached to "SIP gateways" > that > translate PSTN calls to SIP calls. (Gateways are made by Audiocodes, > Vegastream, Cisco, and a number of other companies.) This is only a bit > different from what many companies are now doing with their internal PBX > systems. (And there might be a lot of cost savings to be had, too.) >=20 > Dale >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 23 11:53:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7b5k-0003gn-Uq; Tue, 23 Aug 2005 11:53:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7b5j-0003ge-3s; Tue, 23 Aug 2005 11:53:35 -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 LAA11772; Tue, 23 Aug 2005 11:53:32 -0400 (EDT) Message-Id: <200508231553.LAA11772@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7b5r-0000Lz-Pg; Tue, 23 Aug 2005 11:53:44 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1E7b5V-000272-IR; Tue, 23 Aug 2005 10:53:22 -0500 From: "Brian Rosen" To: "'Stastny Richard'" , "'Dale Worley'" , "'sipping'" Date: Tue, 23 Aug 2005 11:53:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <62B89492B130A740A48CEE3227174D9D9D0D901D@stntexch04.cis.neustar.com> Thread-Index: AcWnO/hDWlh+1K+yRfyk7o2a1uI4mQApkRLQAAMpEHAAAo888A== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: [Ecrit] RE: A proposal for closing the gap between i2 and i3 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Let me see if I'm following you: You want a government owned function that has an IP (e.g. Internet) connection to VoIP systems, and has connections to all the Selective Routers (in a State in North America) or PSAPs (in a Country elsewhere). You imagine we would deploy the ecrit mechanism soon, and use it to route to that function, and then it would use the i2 mechanism (in North America anyway) to route the call onward. I think the VoIP carriers would jump on that idea immediately. It would cut their 9-1-1 cost to near zero. They would still have to run a web based LIS with a call center or some other mechanism to update location for roamers until we got automatic location from access networks. Please do check in with us in 2010; we may have the funding for that figured out. Of course, we'll probably figure out how to upgrade the PSAPs to i3 around that time. If I understand the situation in the EU, you have the same problem. You want the government to change the emergency call system to match the characteristics of the VoIP system, and you want to do that as an INTERIM step before you change the actual PSAP systems. I don't think that works, not because we couldn't make it work technically, but we couldn't figure out how to pay for it, especially as an interim step. Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, August 23, 2005 11:02 AM To: Brian Rosen; Dale Worley; sipping Cc: ecrit@ietf.org Subject: A proposal for closing the gap between i2 and i3 Thank you Brian fort his comprehensive elaboration I just want to add a proposal Ecrit is working on a solution (i3 for short) allowing finally any IP-based device to access the responsible PSAP for the given location. Since (many) PSAPs on the other hand will not be reachable via IP for some time, as you say, there is work done on a national basis to allow VoIP providers to access the national specific emergency system via national specific interfaces. This architecture (e.g i2 in the US) is different in every country. "Interconnected" VoIP providers (whatever that means) are required to interface to these systems, "not-interconnected" are not. This is not a good idea. On the other hand one cannot require from all VoIP providers to interface to 200 different national PSTN-emergency systems. So there is a substantial gap between i2 and i3. This situation could be substantially improved by providing national Emergency Service Routing Proxies (ESRP) doing the mapping between i3 and i2. The ESRP take the calls from VoIP providers and route it according to the location information given to the PSTN and the correct PSAP interfacing with the national emergency system The roadmap is very simple: The ecrit mapping database is loaded initially with the ESRP per country or state (e.g. in at.sos.arpa or ca.us.sos.arpa) The ESRP is doing the additional mapping via the location information given in the INVITE, in the beginning e.g. to the state emergency PSAP (this is as good as now) If a better location information is given, it can do better. Also, if PSAP appear on the Internet, their URIs are entered in the ecrit mapping database until in 10-20 years (just kidding) the ESRP can be shut down. The ESRP could also provide input to existing (also national specific) location databases (e.g. EISEC in UK) and also provide national virtual temporarily call-back numbers for VoIP users without E.164 numbers. The advantage of this method is a smooth migration and on the other hand an immediate availability of access to emergency calls from ALL VoIP providers (not "interconnected" and also alien) This will improve the situation substantially for the customer and also avoid the discussion what "interconnected" means. The investment for the ESRP is not so huge, the investment for the gateways is substantial and has to be funded (USF?) My question is: who may be responsible for guidelines on an international basis? -richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Tuesday, August 23, 2005 3:26 PM > To: 'Dale Worley'; 'sipping' > Subject: RE: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer > > Couple of points to be made: > > 1. The term PSAP is not US-centric. It appears in several other countries > lexicons. There is no universally accepted term, and the authors of > various > works on the subject have tried "Emergency Response Center" without much > success. PSAP will do. > > 2. There is quite a bit of effort underway to develop new IP based > technology at the PSAP. It will probably be possible some day to have a > SIP > call terminate right at the call taker workstation. This requires > upgrades > at the PSAPs, and that is notoriously difficult to accomplish, primarily > (almost exclusively) because of funding issues. Unless you are prepared > to > state how new software, hardware and network connectivity, with > accompanying > processes, firewalls, training, etc is going to be paid for, then you > might > have to wait the usual decade (in the U.S., often longer elsewhere) until > every PSAP can terminate a SIP call. I have some optimism that there will > be some funding available in the U.S. I don't have any reason to be > optimistic at the moment elsewhere. Please also realize that, typically, > once a call is answered at a PSAP, it is transferred to the appropriate > responder(s). They too may need upgrades to their telephony systems. > > 3. It is not trivial to connect SIP based VoIP callers to existing > systems, > although the difficulty varies quite a bit with the sophistication of the > emergency call network. In North America, it's pretty hard if it is > possible to roam, because existing systems assume the location of the > caller > is statically determinable from a database queried by the telephone > number, > or the carrier participates in a medium complexity scheme that allows a > dynamic location of the caller to be sent to the PSAP when it queries the > database. Also, emergency calls are NOT sent through the PSTN. In North > America, each switch (central office) has special trunks that connect to a > special tandem switch to which PSAPs are connected. In other countries > there is no need for a special tandem, but most use special trunks > directly > from the CO switch. You can use a relatively straightforward gateway > (typically SS7 signaling on the TDM side, sometimes, in North America, an > odd MF signaling standard called CAMA), but it connects to the 9-1-1 > tandem > (called a "selective router"), or directly to the PSAP. > > There is a standard (called "i2") that NENA (the North American Emergency > Number Association) developed that does allow VoIP calls to be put into > the > current NA system correctly. It involves a couple of new databases > derived > from the existing one, a specialized service provider and gateways to the > Selective Routers. > > 4. The ecrit work will provide a way to route a call to a SIP uri based on > the location of the caller. That is one of the key mechanisms required to > accomplish 1) above. The mechanism is not decided, but, roughly, you > query > a database with location, and it gives you a URI. Any entity could > implement that mechanism, even a P2P UA. Given a URI, that P2P UA could, > theoretically, route the call to the PSAP, where, again, theoretically, it > could be answered by the call taker. That implies that the PSAP > implements > P2P SIP, whatever that turns out to be as well as regular SIP, which is > the > current assumption. I would personally not consider that to be much of an > obstacle, but it depends on the complexity, security and other operational > issues that are unknown at the moment. > > Brian > > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf > Of Dale Worley > Sent: Monday, August 22, 2005 1:03 PM > To: 'sipping' > Subject: RE: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer > > > From: Michael Hammer (mhammer) > > > > Absolutely! The Public Safety Access Points (PSAP or emergency call > > center -- a colleague reminded me that that is a US-centric term) might > > be able to use less expensive terminals (PC?), and would have a more > > rich environment to work with, IF they stop requiring backward > > compatibility with the PSTN-based systems. > > That isn't a technological issue -- it would be straightforward to > overhaul > an emergency call center to handle incoming calls from a "SIP trunk", and > to > process the calls using workstations that are SIP UAs. For PSTN > compatibility, incoming PSTN trunks could be attached to "SIP gateways" > that > translate PSTN calls to SIP calls. (Gateways are made by Audiocodes, > Vegastream, Cisco, and a number of other companies.) This is only a bit > different from what many companies are now doing with their internal PBX > systems. (And there might be a lot of cost savings to be had, too.) > > Dale > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 23 12:03:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bFj-00056s-HR; Tue, 23 Aug 2005 12:03:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bFi-00056h-1G for ecrit@megatron.ietf.org; Tue, 23 Aug 2005 12:03:54 -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 MAA12187 for ; Tue, 23 Aug 2005 12:03:51 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7bFn-0000cf-Nh for ecrit@ietf.org; Tue, 23 Aug 2005 12:04:03 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j7NG3eNH024114 for ; Tue, 23 Aug 2005 18:03:40 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j7NG3ejY008325 for ; Tue, 23 Aug 2005 18:03:40 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Aug 2005 18:03:39 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 23 Aug 2005 18:03:38 +0200 Message-ID: Thread-Topic: The requirements draft Thread-Index: AcWnO/hDWlh+1K+yRfyk7o2a1uI4mQApkRLQAAMpEHAAAo888AAAr/Hw From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 23 Aug 2005 16:03:39.0146 (UTC) FILETIME=[39B186A0:01C5A7FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] The requirements draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 it would be great if we could put all our efforts into the requirements document. we need to finish it as soon as possible.=20 please send text to resolve the remaining open issues.=20 ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 23 13:30:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7cbM-0001wL-Fx; Tue, 23 Aug 2005 13:30:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7cbI-0001ta-Vf; Tue, 23 Aug 2005 13:30:17 -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 NAA17067; Tue, 23 Aug 2005 13:30:13 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E7cbQ-0003UZ-Vl; Tue, 23 Aug 2005 13:30:26 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 23 Aug 2005 19:33:39 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0F1@oefeg-s04.oefeg.loc> Thread-Topic: A proposal for closing the gap between i2 and i3 Thread-Index: AcWnO/hDWlh+1K+yRfyk7o2a1uI4mQApkRLQAAMpEHAAAo888AADfmEg From: "Stastny Richard" To: "Brian Rosen" , "Dale Worley" , "sipping" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org Subject: [Ecrit] Re: A proposal for closing the gap between i2 and i3 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian wrote: >You want a government owned function that has an IP (e.g. Internet) >connection to VoIP systems, and has connections to all the Selective = Routers >(in a State in North America) or PSAPs (in a Country elsewhere). You >imagine we would deploy the ecrit mechanism soon, and use it to route = to >that function, and then it would use the i2 mechanism (in North America >anyway) to route the call onward. =20 Not necessarily government owned. The financing is also a national = matter. It could be of course government or USF founded or paid by the emergency call takers (ok, other goverment founds), as EISEC is in UK. >I think the VoIP carriers would jump on that idea immediately. It = would cut >their 9-1-1 cost to near zero. =20 Why should VoIP carreirs pay at all for a intermediate solution and i2. = With i3 they also have near zero cost. They are finally out of the picture =20 >They would still have to run a web based LIS >with a call center or some other mechanism to update location for = roamers >until we got automatic location from access networks. As I elaborate, the start could be with a very sketchy location = infomation >Please do check in with us in 2010; we may have the funding for that = figured >out. Of course, we'll probably figure out how to upgrade the PSAPs to = i3 >around that time. You should also consider that most countries have much more simpler systems. You just need a gateway to the PSTN and a correct routing = information In simple cuase you could just route a the geo-number of the PSAP, you = just have to now it and here we are again with the mapping database >If I understand the situation in the EU, you have the same problem. = You >want the government to change the emergency call system to match the >characteristics of the VoIP system, and you want to do that as an = INTERIM >step before you change the actual PSAP systems. =20 not interim, parallel and as a migration, and as I said, in Europe most = systems are simpler.=20 >I don't think that works, not because we couldn't make it work = technically, >but we couldn't figure out how to pay for it, especially as an interim = step. =20 If they want it, and they want it working for all VoIP providers, they = must find a funding. And then there is no excuse NOT to provide access to = emergency services =20 -richard Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, August 23, 2005 11:02 AM To: Brian Rosen; Dale Worley; sipping Cc: ecrit@ietf.org Subject: A proposal for closing the gap between i2 and i3 Thank you Brian fort his comprehensive elaboration I just want to add a proposal Ecrit is working on a solution (i3 for short) allowing finally any IP-based device to access the responsible PSAP for the given location. Since (many) PSAPs on the other hand will not be reachable via IP for some time, as you say, there is work done on a national basis to allow VoIP providers to access the national specific emergency system via national specific interfaces. This architecture (e.g i2 in the US) is different in every country. "Interconnected" VoIP providers (whatever that means) are required to interface to these systems, "not-interconnected" are not. This is not a good idea. On the other hand one cannot require from all VoIP providers to interface to 200 different national PSTN-emergency systems. So there is a substantial gap between i2 and i3. This situation could be substantially improved by providing national Emergency Service Routing Proxies (ESRP) doing the mapping between i3 and i2. The ESRP take the calls from VoIP providers and route it according to the location information given to the PSTN and the correct PSAP interfacing with the national emergency system The roadmap is very simple: The ecrit mapping database is loaded initially with the ESRP per country or state (e.g. in at.sos.arpa or ca.us.sos.arpa) The ESRP is doing the additional mapping via the location information given in the INVITE, in the beginning e.g. to the state emergency PSAP (this is as good as now) If a better location information is given, it can do better. Also, if PSAP appear on the Internet, their URIs are entered in the ecrit mapping database until in 10-20 years (just kidding) the ESRP can be shut down. The ESRP could also provide input to existing (also national specific) location databases (e.g. EISEC in UK) and also provide national virtual temporarily call-back numbers for VoIP users without E.164 numbers. The advantage of this method is a smooth migration and on the other hand an immediate availability of access to emergency calls from ALL VoIP providers (not "interconnected" and also alien) This will improve the situation substantially for the customer and also avoid the discussion what "interconnected" means. The investment for the ESRP is not so huge, the investment for the gateways is substantial and has to be funded (USF?) My question is: who may be responsible for guidelines on an international basis? -richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Tuesday, August 23, 2005 3:26 PM > To: 'Dale Worley'; 'sipping' > Subject: RE: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer > > Couple of points to be made: > > 1. The term PSAP is not US-centric. It appears in several other countries > lexicons. There is no universally accepted term, and the authors of > various > works on the subject have tried "Emergency Response Center" without much > success. PSAP will do. > > 2. There is quite a bit of effort underway to develop new IP based > technology at the PSAP. It will probably be possible some day to have a > SIP > call terminate right at the call taker workstation. This requires > upgrades > at the PSAPs, and that is notoriously difficult to accomplish, primarily > (almost exclusively) because of funding issues. Unless you are prepared > to > state how new software, hardware and network connectivity, with > accompanying > processes, firewalls, training, etc is going to be paid for, then you > might > have to wait the usual decade (in the U.S., often longer elsewhere) until > every PSAP can terminate a SIP call. I have some optimism that there will > be some funding available in the U.S. I don't have any reason to be > optimistic at the moment elsewhere. Please also realize that, typically, > once a call is answered at a PSAP, it is transferred to the appropriate > responder(s). They too may need upgrades to their telephony systems. > > 3. It is not trivial to connect SIP based VoIP callers to existing > systems, > although the difficulty varies quite a bit with the sophistication of the > emergency call network. In North America, it's pretty hard if it is > possible to roam, because existing systems assume the location of the > caller > is statically determinable from a database queried by the telephone > number, > or the carrier participates in a medium complexity scheme that allows a > dynamic location of the caller to be sent to the PSAP when it queries the > database. Also, emergency calls are NOT sent through the PSTN. In North > America, each switch (central office) has special trunks that connect to a > special tandem switch to which PSAPs are connected. In other countries > there is no need for a special tandem, but most use special trunks > directly > from the CO switch. You can use a relatively straightforward gateway > (typically SS7 signaling on the TDM side, sometimes, in North America, an > odd MF signaling standard called CAMA), but it connects to the 9-1-1 > tandem > (called a "selective router"), or directly to the PSAP. > > There is a standard (called "i2") that NENA (the North American Emergency > Number Association) developed that does allow VoIP calls to be put into > the > current NA system correctly. It involves a couple of new databases > derived > from the existing one, a specialized service provider and gateways to the > Selective Routers. > > 4. The ecrit work will provide a way to route a call to a SIP uri based on > the location of the caller. That is one of the key mechanisms required to > accomplish 1) above. The mechanism is not decided, but, roughly, you > query > a database with location, and it gives you a URI. Any entity could > implement that mechanism, even a P2P UA. Given a URI, that P2P UA could, > theoretically, route the call to the PSAP, where, again, theoretically, it > could be answered by the call taker. That implies that the PSAP > implements > P2P SIP, whatever that turns out to be as well as regular SIP, which is > the > current assumption. I would personally not consider that to be much of an > obstacle, but it depends on the complexity, security and other operational > issues that are unknown at the moment. > > Brian > > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf > Of Dale Worley > Sent: Monday, August 22, 2005 1:03 PM > To: 'sipping' > Subject: RE: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer > > > From: Michael Hammer (mhammer) > > > > Absolutely! The Public Safety Access Points (PSAP or emergency call > > center -- a colleague reminded me that that is a US-centric term) might > > be able to use less expensive terminals (PC?), and would have a more > > rich environment to work with, IF they stop requiring backward > > compatibility with the PSTN-based systems. > > That isn't a technological issue -- it would be straightforward to > overhaul > an emergency call center to handle incoming calls from a "SIP trunk", and > to > process the calls using workstations that are SIP UAs. For PSTN > compatibility, incoming PSTN trunks could be attached to "SIP gateways" > that > translate PSTN calls to SIP calls. (Gateways are made by Audiocodes, > Vegastream, Cisco, and a number of other companies.) This is only a bit > different from what many companies are now doing with their internal PBX > systems. (And there might be a lot of cost savings to be had, too.) > > Dale > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 23 16:05:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7f1U-0008DR-8p; Tue, 23 Aug 2005 16:05:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7f1S-00088y-7M; Tue, 23 Aug 2005 16:05:26 -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 QAA00007; Tue, 23 Aug 2005 16:05:24 -0400 (EDT) Message-Id: <200508232005.QAA00007@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7f1d-00014S-Bv; Tue, 23 Aug 2005 16:05:37 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1E7f1B-0007xu-Rt; Tue, 23 Aug 2005 15:05:10 -0500 From: "Brian Rosen" To: "'Juha Heinanen'" , "'Stastny Richard'" Date: Tue, 23 Aug 2005 16:05:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <17163.25426.612197.52789@rautu.tutpro.com> Thread-Index: AcWoC/UXA5CcugYuR8i3uf9fV9b0BgAEBrlQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: 'sipping' , ecrit@ietf.org, 'Dale Worley' Subject: [Ecrit] RE: [Sipping] Re: A proposal for closing the gap between i2 and i3 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think this is na=EFve. Where is the location information coming from? In i2, it initially = comes from a self reported location =3D a website the VoIP carrier runs. = That's a poor answer, but it's the only one we can do in a short time frame. = What you want is automatic location reporting, and that takes a bunch of work = in the access network, and the phones and/or the call servers. Is the government going to run the website? =20 Then you need to decide if PSTN routing from a gateway, is appropriate. Most emergency call systems I know about don't do this; they have = special routing directly from the end office serving the subscriber to the PSAP = (or to the special tandem in North America). Using the PSTN to route calls = has been considered (several times) here, and it has been rejected. One = reason is that 9-1-1 calls are not given special treatment in normal = inter-switch routing (because they aren't sent between switches except as noted). Then you have the problem of Denial of Service. If you make it real = easy to "bomb" the emergency service with lots of calls with no authentication, = they will not be happy. Brian -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com]=20 Sent: Tuesday, August 23, 2005 1:57 PM To: Stastny Richard Cc: Brian Rosen; Dale Worley; sipping; ecrit@ietf.org Subject: [Sipping] Re: A proposal for closing the gap between i2 and i3 Stastny Richard writes: > You should also consider that most countries have much more simpler > systems. You just need a gateway to the PSTN and a correct routing > information. exactly, in finland when my sip user dials 112, my proxy simply prefixes that number with string 3979, where is a three digit code of the town the caller is in. pstn network then knows how to route the call the correct emergency center based on the community code. thus any sip/pstn gw can handle also emergency calls and the cost to sip provider is zero. the next step that i'm pushing is that government sets up these sip/pstn gws for emergency call purpose, which would make the system independent of sip providers. this would cost the government almost nothing and would allow also sip user who are not customers to any sip provider to make emergency calls. the next step is to include real location information in the sip request based, for example, on mobile base station coordinates. -- juha _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Aug 23 16:56:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7foa-0000g3-SA; Tue, 23 Aug 2005 16:56:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7foS-0000f8-S9; Tue, 23 Aug 2005 16:56:05 -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 QAA11214; Tue, 23 Aug 2005 16:56:02 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E7foc-0005hQ-KJ; Tue, 23 Aug 2005 16:56:16 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 23 Aug 2005 22:59:27 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0F4@oefeg-s04.oefeg.loc> Thread-Topic: [Sipping] Re: A proposal for closing the gap between i2 and i3 Thread-Index: AcWoC/UXA5CcugYuR8i3uf9fV9b0BgAEBrlQAAIsEyw= From: "Stastny Richard" To: "Brian Rosen" , "Juha Heinanen" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: sipping , ecrit@ietf.org, Dale Worley Subject: [Ecrit] Re: [Sipping] Re: A proposal for closing the gap between i2 and i3 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian wrote: >Where is the location information coming from? In i2, it initially = comes >from a self reported location =3D a website the VoIP carrier runs. = That's a >poor answer, but it's the only one we can do in a short time frame. = What >you want is automatic location reporting, and that takes a bunch of = work in >the access network, and the phones and/or the call servers. Is the >government going to run the website?=20 In my proposal also the VoIP providers could still provide this web-site and all calls are still routed via the providers proxy. >Then you need to decide if PSTN routing from a gateway, is appropriate. >Most emergency call systems I know about don't do this; they have = special >routing directly from the end office serving the subscriber to the PSAP = (or >to the special tandem in North America). Using the PSTN to route calls = has >been considered (several times) here, and it has been rejected. One = reason >is that 9-1-1 calls are not given special treatment in normal = inter-switch >routing (because they aren't sent between switches except as noted). =20 The ESRP is basically feeding a gateway connected to the PSTN as PoI and using the same functionality like a connection between altenative operators to the incumbent. In this case the calls may also immediately routed from the originating switch (where the PoI is connected) to the switch where the PSAP is connected. This is a national matter >Then you have the problem of Denial of Service. If you make it real = easy to >"bomb" the emergency service with lots of calls with no authentication, = they >will not be happy. =20 the DoS and other problems have to be solved in any case for i3. =20 Richard Brian -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com] Sent: Tuesday, August 23, 2005 1:57 PM To: Stastny Richard Cc: Brian Rosen; Dale Worley; sipping; ecrit@ietf.org Subject: [Sipping] Re: A proposal for closing the gap between i2 and i3 Stastny Richard writes: > You should also consider that most countries have much more simpler > systems. You just need a gateway to the PSTN and a correct routing > information. exactly, in finland when my sip user dials 112, my proxy simply prefixes that number with string 3979, where is a three digit code of the town the caller is in. pstn network then knows how to route the call the correct emergency center based on the community code. thus any sip/pstn gw can handle also emergency calls and the cost to sip provider is zero. the next step that i'm pushing is that government sets up these sip/pstn gws for emergency call purpose, which would make the system independent of sip providers. this would cost the government almost nothing and would allow also sip user who are not customers to any sip provider to make emergency calls. the next step is to include real location information in the sip request based, for example, on mobile base station coordinates. -- juha _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 24 14:32:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E802r-0005zS-Jx; Wed, 24 Aug 2005 14:32:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E802o-0005yh-85; Wed, 24 Aug 2005 14:32:14 -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 OAA10191; Wed, 24 Aug 2005 14:32:12 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E803A-0002ay-R9; Wed, 24 Aug 2005 14:32:37 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 24 Aug 2005 11:32:04 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,138,1122879600"; d="scan'208"; a="7182162:sNHT24321304" 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 j7OIVWTW015550; Wed, 24 Aug 2005 14:32:01 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Aug 2005 14:31:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Aug 2005 14:31:56 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E37C5096@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sipping] Re: A proposal for closing the gap between i2 and i3 Thread-Index: AcWoaoKBDbItxAF4Qm2wPSq11cCq0wAbf1Fw From: "Michael Hammer \(mhammer\)" To: "Juha Heinanen" , "Brian Rosen" X-OriginalArrivalTime: 24 Aug 2005 18:31:56.0473 (UTC) FILETIME=[1B53A290:01C5A8DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: Stastny Richard , sipping , ecrit@ietf.org Subject: [Ecrit] RE: [Sipping] Re: A proposal for closing the gap between i2 and i3 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org =20 > -----Original Message----- > From: sipping-bounces@ietf.org=20 > [mailto:sipping-bounces@ietf.org] On Behalf Of Juha Heinanen > Sent: Wednesday, August 24, 2005 1:08 AM > To: Brian Rosen > Cc: 'Stastny Richard'; 'sipping'; ecrit@ietf.org > Subject: RE: [Sipping] Re: A proposal for closing the gap=20 > between i2 and i3 >=20 > Brian Rosen writes: >=20 > > Where is the location information coming from? In i2, it=20 > initially comes > from a self reported location =3D a website=20 > the VoIP carrier runs. =20 >=20 > right now community information comes from whatever the user=20 > has configured in his proxy as his community using a web=20 > page. so this seems to match what you have. >=20 > > That's a > > poor answer, but it's the only one we can do in a short=20 > time frame. What > you want is automatic location=20 > reporting, and that takes a bunch of work in > the access=20 > network, and the phones and/or the call servers. Is the >=20 > government going to run the website? =20 >=20 > the only thing i have proposed is that each mobile operator=20 > is MANDATED to have a web site accessible via xml-rpc, for=20 > example, that contains coordinates of their mobile base=20 > stations. =20 Competitively, no mobiel carrier will do that. Security-wise, why not mail this to terrorist organizations while you are at it. sip phone having mobile network access, can then=20 > calculate its location that can be mapped to community code=20 > by another xml-rpc call. gps would be another choice, but=20 > not a very good one, because it seems to work only outside=20 > and even then takes long time to initialize. >=20 > > Then you need to decide if PSTN routing from a gateway, is=20 > appropriate. > > Most emergency call systems I know about don't do this;=20 > they have special > routing directly from the end office=20 > serving the subscriber to the PSAP (or > to the special=20 > tandem in North America). =20 >=20 > this is not the case in many countries outside of n.a. >=20 > > Then you have the problem of Denial of Service. If you=20 > make it real easy to > "bomb" the emergency service with=20 > lots of calls with no authentication, they > will not be happy. >=20 > today it is possible to make emergency calls with a cell=20 > phone without a sim card. so the same problem exists=20 > already. the question is, which is more important: =20 > possibility to make emergency call anonymously or not to be=20 > able to make the call at all. >=20 > -- juha Ummm, what is the cost of doing that many prank calls from cell phones, versus using a bot-net to do this via the Internet? Mike >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 24 14:55:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80Oz-0004wY-NN; Wed, 24 Aug 2005 14:55:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80Ow-0004vn-CW; Wed, 24 Aug 2005 14:55:06 -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 OAA11231; Wed, 24 Aug 2005 14:55:05 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E80PG-0003GI-H4; Wed, 24 Aug 2005 14:55:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Aug 2005 20:55:03 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0FA@oefeg-s04.oefeg.loc> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Sipping] Re: A proposal for closing the gap between i2 and i3 Thread-Index: AcWoaoKBDbItxAF4Qm2wPSq11cCq0wAbf1FwAAE1oiY= From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "Juha Heinanen" , "Brian Rosen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Cc: sipping , ecrit@ietf.org Subject: [Ecrit] Re: [Sipping] Re: A proposal for closing the gap between i2 and i3 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Mike writes: >Ummm, what is the cost of doing that many prank calls from cell phones, >versus using a bot-net to do this via the Internet? =20 A sore thunb =20 Get yourself a GSM-phone on the flea market, power it on without a SIM card and push the right button under the screen named SOS every ten seconds. =20 -richard =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 24 15:32:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80zZ-0000wl-IK; Wed, 24 Aug 2005 15:32:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80zW-0000wa-Q6; Wed, 24 Aug 2005 15:32:55 -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 PAA14351; Wed, 24 Aug 2005 15:32:53 -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 1E80zt-0004X6-2l; Wed, 24 Aug 2005 15:33:18 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 24 Aug 2005 12:32:44 -0700 X-IronPort-AV: i="3.96,138,1122879600"; d="scan'208"; a="656556834:sNHT33030616" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7OJWAQi024497; Wed, 24 Aug 2005 12:32:41 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Aug 2005 15:32:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Aug 2005 15:32:33 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E37C50D9@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sipping] Re: A proposal for closing the gap between i2 and i3 Thread-Index: AcWo3l7BpCiYJhTEQ2eo5EsQhbHokAAAq88w From: "Michael Hammer \(mhammer\)" To: "Juha Heinanen" X-OriginalArrivalTime: 24 Aug 2005 19:32:33.0807 (UTC) FILETIME=[9358C1F0:01C5A8E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: Stastny Richard , sipping , ecrit@ietf.org Subject: [Ecrit] RE: [Sipping] Re: A proposal for closing the gap between i2 and i3 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org =20 > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com]=20 > Sent: Wednesday, August 24, 2005 3:02 PM > To: Michael Hammer (mhammer) > Cc: Brian Rosen; Stastny Richard; sipping; ecrit@ietf.org > Subject: RE: [Sipping] Re: A proposal for closing the gap=20 > between i2 and i3 >=20 > Michael Hammer \(mhammer\) writes: >=20 > > Competitively, no mobiel carrier will do that. >=20 > so you don't care about p2p sip users being able to tell=20 > where they are when they make emergency call? =20 No one is suggesting anything of the sort. Saying that one solution has seriouse drawbacks, does not mean that there isn't another means of addressing the core requirement. If you are talking to the cell site, it can tell you where you are. That does not necessarily tell a miscreant exactly which of many antennas visible is the one you are using at the moment. Also, you would need at least three towers to provide any meaningful location information. That is what TOA, DOA, and other methods rely on. there is=20 > always a trade-off and i don't consider competition good=20 > enough reason to prevent emergency calling with location information. >=20 > > Security-wise, why not mail this to terrorist=20 > organizations while you > are at it. >=20 > it is easy to anyone to figure out where the base stations in=20 > any particular area are. we could use the community to post=20 > that information to an unofficial web site (each collecting=20 > the information in the area where they live), but i would=20 > prefer to do it officially. >=20 > looks like in the u.s. anything is now terrorist related. i=20 > think you should cool down a bit and perhaps choose better=20 > leaders next time. All I am trying to say is that technological solutions that live in the real world have additional considerations that may make them sub-optimal. As for politics, we get bombed no matter who we elect. But, such discussion is out of scope of this list. > > Ummm, what is the cost of doing that many prank calls from=20 > cell phones, > versus using a bot-net to do this via the Internet? >=20 > you can buy a smart cell phone=20 clearly a higher cost than software based call sources, and likely easier to find in physical world. Mike and program it to make as many=20 > anonymous emergency calls as you like. >=20 > -- juha _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Aug 24 16:16:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81b7-0007pr-6u; Wed, 24 Aug 2005 16:11:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81b4-0007pR-Gg; Wed, 24 Aug 2005 16:11:42 -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 QAA17818; Wed, 24 Aug 2005 16:11:40 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E81bQ-0006O1-9W; Wed, 24 Aug 2005 16:12:06 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 24 Aug 2005 16:11:31 -0400 X-IronPort-AV: i="3.96,138,1122868800"; d="scan'208"; a="67736643:sNHT30645376" 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 j7OKApTg011747; Wed, 24 Aug 2005 16:11:28 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Aug 2005 16:11:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Aug 2005 16:11:25 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E37C5109@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sipping] Re: A proposal for closing the gap between i2 and i3 Thread-Index: AcWoaoKBDbItxAF4Qm2wPSq11cCq0wAbf1FwAAE1oiYAAqjMIA== From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "Juha Heinanen" , "Brian Rosen" X-OriginalArrivalTime: 24 Aug 2005 20:11:26.0386 (UTC) FILETIME=[01AC1120:01C5A8E8] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: sipping , ecrit@ietf.org Subject: [Ecrit] RE: [Sipping] Re: A proposal for closing the gap between i2 and i3 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Still doesn't beat a bot-net. Mike=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Wednesday, August 24, 2005 2:55 PM > To: Michael Hammer (mhammer); Juha Heinanen; Brian Rosen > Cc: sipping; ecrit@ietf.org > Subject: Re: [Sipping] Re: A proposal for closing the gap=20 > between i2 and i3 >=20 > Mike writes: > >Ummm, what is the cost of doing that many prank calls from=20 > cell phones,=20 > >versus using a bot-net to do this via the Internet? > =20 > A sore thunb > =20 > Get yourself a GSM-phone on the flea market, power it on=20 > without a SIM card and push the right button under the screen=20 > named SOS every ten seconds. > =20 > -richard > =20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Aug 26 08:07:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8czt-000821-AZ; Fri, 26 Aug 2005 08:07:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80WB-0006hn-VB; Wed, 24 Aug 2005 15:02: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 PAA11706; Wed, 24 Aug 2005 15:02:34 -0400 (EDT) Received: from plasmid91.gprs.dnafinland.fi ([62.78.124.91] helo=rautu.tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E80WW-0003XX-4v; Wed, 24 Aug 2005 15:02:59 -0400 Received: from rautu.tutpro.com (jh@localhost [127.0.0.1]) by rautu.tutpro.com (8.13.4/8.13.4/Debian-3) with ESMTP id j7OJ2K30031224; Wed, 24 Aug 2005 22:02:20 +0300 Received: (from jh@localhost) by rautu.tutpro.com (8.13.4/8.13.4/Submit) id j7OJ2J6x031221; Wed, 24 Aug 2005 22:02:19 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17164.50235.934928.895955@rautu.tutpro.com> Date: Wed, 24 Aug 2005 22:02:19 +0300 From: Juha Heinanen To: "Michael Hammer \(mhammer\)" In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E37C5096@xmb-rtp-20b.amer.cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E37C5096@xmb-rtp-20b.amer.cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 26 Aug 2005 08:07:47 -0400 Cc: Stastny Richard , sipping , ecrit@ietf.org Subject: [Ecrit] RE: [Sipping] Re: A proposal for closing the gap between i2 and i3 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Michael Hammer \(mhammer\) writes: > Competitively, no mobiel carrier will do that. so you don't care about p2p sip users being able to tell where they are when they make emergency call? there is always a trade-off and i don't consider competition good enough reason to prevent emergency calling with location information. > Security-wise, why not mail this to terrorist organizations while you > are at it. it is easy to anyone to figure out where the base stations in any particular area are. we could use the community to post that information to an unofficial web site (each collecting the information in the area where they live), but i would prefer to do it officially. looks like in the u.s. anything is now terrorist related. i think you should cool down a bit and perhaps choose better leaders next time. > Ummm, what is the cost of doing that many prank calls from cell phones, > versus using a bot-net to do this via the Internet? you can buy a smart cell phone and program it to make as many anonymous emergency calls as you like. -- juha _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Aug 27 06:07:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8xbD-0002Q0-RC; Sat, 27 Aug 2005 06:07:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8xbC-0002Pv-Gb for ecrit@megatron.ietf.org; Sat, 27 Aug 2005 06:07:42 -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 GAA05967 for ; Sat, 27 Aug 2005 06:07:39 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8xc3-0003bd-N9 for ecrit@ietf.org; Sat, 27 Aug 2005 06:08:39 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j7RA7Q0d021214 for ; Sat, 27 Aug 2005 12:07:26 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j7RA7Qvn027842 for ; Sat, 27 Aug 2005 12:07:26 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 27 Aug 2005 12:07:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 27 Aug 2005 12:06:27 +0200 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: Thread-Topic: ietf#63 ecrit meeting minutes Thread-Index: AcWq7v0U+M0dvxOySSej6tFN4E/RBg== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 27 Aug 2005 10:07:26.0424 (UTC) FILETIME=[2035F580:01C5AAEF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] ietf#63 ecrit meeting minutes X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 please find the meeting minutes at:=20 http://www.ietf-ecrit.org/IETF63/Ecrit-MeetingMinutes.txt please send me a mail if something is missing or wrong.=20 ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit