From ecrit-bounces@ietf.org Tue Mar 1 04:14:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05260; Tue, 1 Mar 2005 04:14:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D63Tx-0006et-IJ; Tue, 01 Mar 2005 04:15:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D63Ru-0001C8-0D; Tue, 01 Mar 2005 04:13:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D63Rr-0001Bz-VZ for ecrit@megatron.ietf.org; Tue, 01 Mar 2005 04:13:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05198 for ; Tue, 1 Mar 2005 04:13:46 -0500 (EST) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D63Sn-0006dU-0O for ecrit@ietf.org; Tue, 01 Mar 2005 04:14:45 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j219DkZ4017205 for ; Tue, 1 Mar 2005 10:13:46 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j219Djdh022667 for ; Tue, 1 Mar 2005 10:13:45 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <1XNRP5S8>; Tue, 1 Mar 2005 10:13:45 +0100 Message-ID: From: Tschofenig Hannes To: "'ecrit@ietf.org'" Date: Tue, 1 Mar 2005 10:11:57 +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: 50a516d93fd399dc60588708fd9a3002 Subject: [Ecrit] IETF#62 ECRIT Agenda (tentative) 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 hi all, we prepared a first agenda proposal. Draft Agenda for ECRIT at IETF 62 Time: Wed., 09-Mar-05 09:00-11:30 ----------------------------------- 1) Agenda Bashing (5 min) (Chairs) 2) Requirements for Session Initiation Protocol (SIP)-based Emergency Calls Emergency Services for Internet Telephony based on the Session Initiation Protocol (SIP) (H. Schulzrinne, 15 min) http://www.ietf.org/internet-drafts/draft-schulzrinne-sipping-emergency-req- 01.txt http://www.ietf-ecrit.org/cache/draft-schulzrinne-sipping-sos-04.txt 3) ECRIT Location Scope Requirements (J. Winterbottom, 10 min) http://www.ietf.org/internet-drafts/draft-winterbottom-ecrit-location-scope- req-00.txt 4) Emergency Call Requirements for IP Telephony Services In Japan (M. Kawanishi, 10 min) http://www.ietf.org/internet-drafts/draft-arai-ecrit-japan-req-00.txt 5) NENA Requirements for Emergency Call processing (B. Rosen, 10 min) http://www.ietf.org/internet-drafts/draft-rosen-nena-ecrit-requirements-00.t xt 6) The basic requirements for emergency services via the Internet (R. Stastny, 10 min) http://www.ietf.org/internet-drafts/draft-stastny-ecrit-requirements-00.txt 7) Next Steps and AOB (5 min) (Chairs) Please let us know when you would like to have something added. ciao hannes/marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 1 04:33:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06367; Tue, 1 Mar 2005 04:33:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D63ld-0006yz-56; Tue, 01 Mar 2005 04:34:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D63iP-0003l3-Ns; Tue, 01 Mar 2005 04:30:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D63iM-0003kv-Mz for ecrit@megatron.ietf.org; Tue, 01 Mar 2005 04:30:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06204 for ; Tue, 1 Mar 2005 04:30:48 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D63jH-0006vz-OF for ecrit@ietf.org; Tue, 01 Mar 2005 04:31:48 -0500 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 j219Tnp11142; Tue, 1 Mar 2005 03:29:49 -0600 (CST) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id <1J4ZVHZY>; Tue, 1 Mar 2005 20:29:49 +1100 Message-ID: From: "James Winterbottom" To: Tschofenig Hannes , "'ecrit@ietf.org'" Subject: RE: [Ecrit] IETF#62 ECRIT Agenda (tentative) Date: Tue, 1 Mar 2005 20:29:48 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee 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="===============1773390876==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae 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. --===============1773390876== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51E41.3645E046" 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_01C51E41.3645E046 Content-Type: text/plain Hi All, My requirements are quite specific to location information. In some regards they are therefore the lowest level. It may actually be better if these went towards the end rather than up front. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig Hannes Sent: Tuesday, 1 March 2005 8:12 PM To: 'ecrit@ietf.org' Subject: [Ecrit] IETF#62 ECRIT Agenda (tentative) hi all, we prepared a first agenda proposal. Draft Agenda for ECRIT at IETF 62 Time: Wed., 09-Mar-05 09:00-11:30 ----------------------------------- 1) Agenda Bashing (5 min) (Chairs) 2) Requirements for Session Initiation Protocol (SIP)-based Emergency Calls Emergency Services for Internet Telephony based on the Session Initiation Protocol (SIP) (H. Schulzrinne, 15 min) http://www.ietf.org/internet-drafts/draft-schulzrinne-sipping-emergency-req- 01.txt http://www.ietf-ecrit.org/cache/draft-schulzrinne-sipping-sos-04.txt 3) ECRIT Location Scope Requirements (J. Winterbottom, 10 min) http://www.ietf.org/internet-drafts/draft-winterbottom-ecrit-location-scope- req-00.txt 4) Emergency Call Requirements for IP Telephony Services In Japan (M. Kawanishi, 10 min) http://www.ietf.org/internet-drafts/draft-arai-ecrit-japan-req-00.txt 5) NENA Requirements for Emergency Call processing (B. Rosen, 10 min) http://www.ietf.org/internet-drafts/draft-rosen-nena-ecrit-requirements-00.t xt 6) The basic requirements for emergency services via the Internet (R. Stastny, 10 min) http://www.ietf.org/internet-drafts/draft-stastny-ecrit-requirements-00.txt 7) Next Steps and AOB (5 min) (Chairs) Please let us know when you would like to have something added. ciao hannes/marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C51E41.3645E046 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Ecrit] IETF#62 ECRIT Agenda (tentative)

Hi All,

My requirements are quite specific to location = information. In some regards they are therefore the lowest level. It = may actually be better if these went towards the end rather than up = front.

Cheers
James


-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf Of Tschofenig Hannes
Sent: Tuesday, 1 March 2005 8:12 PM
To: 'ecrit@ietf.org'
Subject: [Ecrit] IETF#62 ECRIT Agenda = (tentative)


hi all,

we prepared a first agenda proposal.

Draft Agenda for ECRIT at IETF 62
Time: Wed., 09-Mar-05 09:00-11:30
-----------------------------------

1) Agenda Bashing (5 min)
(Chairs)

2) Requirements for Session Initiation Protocol = (SIP)-based Emergency Calls
Emergency Services for Internet Telephony based on = the Session Initiation Protocol (SIP) (H. Schulzrinne, 15 min)

http://www.ietf.org/internet-drafts/draft-schulzrinne-= sipping-emergency-req-
01.txt http://www.ietf-ecrit.org/cache/draft-schulzrinne-sipp= ing-sos-04.txt

3) ECRIT Location Scope Requirements
(J. Winterbottom, 10 min)

http://www.ietf.org/internet-drafts/draft-winterbottom= -ecrit-location-scope-
req-00.txt

4) Emergency Call Requirements for IP Telephony = Services In Japan (M. Kawanishi, 10 min)

http://www.ietf.org/internet-drafts/draft-arai-ecrit-j= apan-req-00.txt

5) NENA Requirements for Emergency Call = processing
(B. Rosen, 10 min)

http://www.ietf.org/internet-drafts/draft-rosen-nena-e= crit-requirements-00.t
xt

6) The basic requirements for emergency services via = the Internet (R. Stastny, 10 min)

http://www.ietf.org/internet-drafts/draft-stastny-ecri= t-requirements-00.txt

7) Next Steps and AOB (5 min)
(Chairs)

Please let us know when you would like to have = something added.

ciao
hannes/marc

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

------_=_NextPart_001_01C51E41.3645E046-- --===============1773390876== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1773390876==-- From ecrit-bounces@ietf.org Tue Mar 1 04:38:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06750; Tue, 1 Mar 2005 04:38:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D63qK-00074G-Oc; Tue, 01 Mar 2005 04:39:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D63ni-0004gh-8C; Tue, 01 Mar 2005 04:36:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D63ng-0004gW-2T for ecrit@megatron.ietf.org; Tue, 01 Mar 2005 04:36:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06547 for ; Tue, 1 Mar 2005 04:36:18 -0500 (EST) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D63ob-00071i-2m for ecrit@ietf.org; Tue, 01 Mar 2005 04:37:17 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j219aHH4030648; Tue, 1 Mar 2005 10:36:18 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j219aHXk013273; Tue, 1 Mar 2005 10:36:17 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <1XNRP62B>; Tue, 1 Mar 2005 10:36:17 +0100 Message-ID: From: Tschofenig Hannes To: "'James Winterbottom'" , "'ecrit@ietf.org'" Subject: AW: [Ecrit] IETF#62 ECRIT Agenda (tentative) Date: Tue, 1 Mar 2005 10:32:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.9 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 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="===============1820839410==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a 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. --===============1820839410== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51E41.9E05B990" 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_01C51E41.9E05B990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ok.=20 =20 http://www.ietf-ecrit.org/IETF62/ECRIT-Agenda.txt =20 =20 ciao hannes =20 -----Urspr=FCngliche Nachricht----- Von: James Winterbottom [mailto:winterb@nortel.com]=20 Gesendet: Dienstag, 1. M=E4rz 2005 10:30 An: Tschofenig Hannes; 'ecrit@ietf.org' Betreff: RE: [Ecrit] IETF#62 ECRIT Agenda (tentative) Hi All,=20 My requirements are quite specific to location information. In some = regards they are therefore the lowest level. It may actually be better if these = went towards the end rather than up front. Cheers=20 Ja=20 mes=20 -----Original Message-----=20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org ] On Behalf Of Tschofenig Hannes=20 Sent: Tuesday, 1 March 2005 8:12 PM=20 To: 'ecrit@ietf.org'=20 Subject: [Ecrit] IETF#62 ECRIT Agenda (tentative)=20 hi all,=20 we prepared a first agenda proposal.=20 Draft Agenda for ECRIT at IETF 62=20 Time: Wed., 09-Mar-05 09:00-11:30=20 -----------------------------------=20 1) Agenda Bashing (5 min)=20 (Chairs)=20 2) Requirements for Session Initiation Protocol (SIP)-based Emergency = Calls=20 Emergency Services for Internet Telephony based on the Session = Initiation Protocol (SIP) (H. Schulzrinne, 15 min)=20 http://www.ietf.org/internet-drafts/draft-schulzrinne-sipping-emergency-= req- =20 01.txt = http://www.ietf-ecrit.org/cache/draft-schulzrinne-sipping-sos-04.txt = 3) ECRIT Location Scope Requirements=20 (J. Winterbottom, 10 min)=20 http://www.ietf.org/internet-drafts/draft-winterbottom-ecrit-location-sc= ope- =20 req-00.txt=20 4) Emergency Call Requirements for IP Telephony Services In Japan (M. Kawanishi, 10 min)=20 http://www.ietf.org/internet-drafts/draft-arai-ecrit-japan-req-00.txt = =20 5) NENA Requirements for Emergency Call processing=20 (B. Rosen, 10 min)=20 http://www.ietf.org/internet-drafts/draft-rosen-nena-ecrit-requirements-= 00.t =20 xt=20 6) The basic requirements for emergency services via the Internet (R. Stastny, 10 min)=20 http://www.ietf.org/internet-drafts/draft-stastny-ecrit-requirements-00.= txt =20 7) Next Steps and AOB (5 min)=20 (Chairs)=20 Please let us know when you would like to have something added.=20 ciao=20 hannes/marc=20 _______________________________________________=20 Ecrit mailing list=20 Ecrit@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ecrit =20 ------_=_NextPart_001_01C51E41.9E05B990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nachricht
ok.=20
 
http://www.ie= tf-ecrit.org/IETF62/ECRIT-Agenda.txt
 
ciao
hannes
 
-----Urspr=FCngliche Nachricht-----
Von: James = Winterbottom=20 [mailto:winterb@nortel.com]
Gesendet: Dienstag, 1. M=E4rz = 2005=20 10:30
An: Tschofenig Hannes; = 'ecrit@ietf.org'
Betreff: RE:=20 [Ecrit] IETF#62 ECRIT Agenda (tentative)

Hi All,

My requirements are quite specific to location = information. In=20 some regards they are therefore the lowest level. It may actually be = better if=20 these went towards the end rather than up front.

Cheers
Ja 

 mes=20


-----Original Message-----
From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On=20 Behalf Of Tschofenig Hannes
Sent: Tuesday, = 1 March=20 2005 8:12 PM
To: 'ecrit@ietf.org' =
Subject: [Ecrit] IETF#62 ECRIT Agenda (tentative) =


hi all,

we prepared a first agenda proposal.

Draft Agenda for ECRIT at IETF 62
Time: Wed., 09-Mar-05 09:00-11:30
-----------------------------------

1) Agenda Bashing (5 min)
(Chairs)

2) Requirements for Session Initiation Protocol = (SIP)-based=20 Emergency Calls
Emergency Services for = Internet=20 Telephony based on the Session Initiation Protocol (SIP) (H. = Schulzrinne, 15=20 min)

http://www.ietf.org/internet-drafts/draft-schulzrinne-si= pping-emergency-req-=20
01.txt http://www.ietf-ecrit.org/cache/draft-schulzrinne-sippin= g-sos-04.txt=20

3) ECRIT Location Scope Requirements =
(J. Winterbottom, 10 min)

http://www.ietf.org/internet-drafts/draft-winterbottom-e= crit-location-scope-=20
req-00.txt

4) Emergency Call Requirements for IP Telephony = Services In=20 Japan (M. Kawanishi, 10 min)

http://www.ietf.org/internet-drafts/draft-arai-ecrit-jap= an-req-00.txt=20

5) NENA Requirements for Emergency Call = processing=20
(B. Rosen, 10 min)

http://www.ietf.org/internet-drafts/draft-rosen-nena-ecr= it-requirements-00.t=20
xt

6) The basic requirements for emergency services = via the=20 Internet (R. Stastny, 10 min)

http://www.ietf.org/internet-drafts/draft-stastny-ecrit-= requirements-00.txt=20

7) Next Steps and AOB (5 min)
(Chairs)

Please let us know when you would like to have = something=20 added.

ciao
hannes/marc =

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

------_=_NextPart_001_01C51E41.9E05B990-- --===============1820839410== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1820839410==-- From ecrit-bounces@ietf.org Tue Mar 1 08:04:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21295; Tue, 1 Mar 2005 08:04:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D673k-0002aa-JC; Tue, 01 Mar 2005 08:05:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D66tF-0000lz-QE; Tue, 01 Mar 2005 07:54:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D639E-0006Sn-EL for ecrit@megatron.ietf.org; Tue, 01 Mar 2005 03:54:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04051 for ; Tue, 1 Mar 2005 03:54:30 -0500 (EST) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D63A8-0006AK-MT for sipping-emergency@ietf.org; Tue, 01 Mar 2005 03:55:29 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j218sTGm001472 for ; Tue, 1 Mar 2005 09:54:29 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j218sSGk004146 for ; Tue, 1 Mar 2005 09:54:28 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <1XNRP5BH>; Tue, 1 Mar 2005 09:54:28 +0100 Message-ID: From: Tschofenig Hannes To: sipping-emergency@ietf.org Date: Tue, 1 Mar 2005 09:52:29 +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: 50a516d93fd399dc60588708fd9a3002 X-Mailman-Approved-At: Tue, 01 Mar 2005 07:54:17 -0500 Subject: [Ecrit] IETF#62 ECRIT Agenda (tentative) 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 hi all, we prepared a first agenda proposal. Draft Agenda for ECRIT at IETF 62 Time: Wed., 09-Mar-05 09:00-11:30 ----------------------------------- 1) Agenda Bashing (5 min) (Chairs) 2) Requirements for Session Initiation Protocol (SIP)-based Emergency Calls Emergency Services for Internet Telephony based on the Session Initiation Protocol (SIP) (H. Schulzrinne, 15 min) http://www.ietf.org/internet-drafts/draft-schulzrinne-sipping-emergency-req- 01.txt http://www.ietf-ecrit.org/cache/draft-schulzrinne-sipping-sos-04.txt 3) ECRIT Location Scope Requirements (J. Winterbottom, 10 min) http://www.ietf.org/internet-drafts/draft-winterbottom-ecrit-location-scope- req-00.txt 4) Emergency Call Requirements for IP Telephony Services In Japan (M. Kawanishi, 10 min) http://www.ietf.org/internet-drafts/draft-arai-ecrit-japan-req-00.txt 5) NENA Requirements for Emergency Call processing (B. Rosen, 10 min) http://www.ietf.org/internet-drafts/draft-rosen-nena-ecrit-requirements-00.t xt 6) The basic requirements for emergency services via the Internet (R. Stastny, 10 min) http://www.ietf.org/internet-drafts/draft-stastny-ecrit-requirements-00.txt 7) Next Steps and AOB (5 min) (Chairs) Please let us know when you would like to have something added. ciao hannes/marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 4 08:19:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16461; Fri, 4 Mar 2005 08:19:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7CjS-0002KL-Gj; Fri, 04 Mar 2005 08:20:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7CfK-0004fN-Te; Fri, 04 Mar 2005 08:16:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7ByL-0005TO-Mh for ecrit@megatron.ietf.org; Fri, 04 Mar 2005 07:32:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09778 for ; Fri, 4 Mar 2005 07:32:00 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D7Bzt-0000kY-2h for sipping-emergency@ietf.org; Fri, 04 Mar 2005 07:33:38 -0500 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: Fri, 4 Mar 2005 13:34:02 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D4601D878@oefeg-s04.oefeg.loc> Thread-Topic: ETSI EMTEL Emergency Requirements Thread-Index: AcUVvu5EcwP4G1H9QVOn5aoNAVIoIgK9DnFA From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 04 Mar 2005 08:16:25 -0500 Subject: [Ecrit] ETSI EMTEL Emergency 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 Content-Transfer-Encoding: quoted-printable Dear all, we have now quite a collection of requirements together. To complicate the issue further and complete the global view,=20 I want to add the (approved) requirements from Europe submitted from EMTEL to ETSI TISPAN WG1 this week (05bTD017): 05bTD182r1 DES01019 _Requirements of the NGN network to support=20 the emergency service for communication from citizen to authority_ The requirements where also checked against the requirements for 3GPP IMS as outlined in the draft TR 23 867. IT was then agreed that this document is approved at the project level ... Best regards Richard Stastny Citations from the document: 1 Scope The present document contains the requirements of a NGN to support emergency communications (EMTEL) from the citizen to the authority. The requirements are independent of the NGN subsystem and transport layer unless specifically referred to. ..... 4 Emergency Sessions Requirements The following is a list of very high level requirements for an emergency call/session between a user and the PSAP/ECC when an 112 type service is requested. =20 *Provide a voice link, maintained throughout the call *Receive immediate priority treatment over other calls *Must not be subject to restrictive network management practices *Must be subject to normal call records, charging and accounting (even though the call is free) *Must provide a unique ID to enable a callback (eg CLI) and Network Operator ID *Originating geographic location must be automatically provided to determine=20 - correct PSAP operator to route the call to - appropriate local emergency service centre - location to accurately despatch assistance. *Location information must be automatically available at the PSAP centre *Must be migrated to multi-party calls under the control of the PSAP operator *Shall be subject to "last party clear", or other method for handling false calls *Shall be restored with priority over normal calls. *Need IP and PSTN Emergency Call Centre solution Note by Richard: this seems quite extreme, but is softened in the further text 4.1 General Requirements It shall be possible to establish a session for an emergency speech call. These Emergency calls shall be routed to the emergency services in accordance with the national regulations of where the caller is located which may require that these calls receive a higher level of priority than a normal communication.. An emergency call may be allowed to be establish without the need to 'dial' a dedicated number to avoid a mis-connection in the nomadic case, e.g. the use of entities such as menu, by use of a 'red button' may be deployed. Emergency Calls may be supported without a dedicated authentication device or procedure being present for this session. Note: It will be left to the national authorities to decide whether the network should accept emergency calls without the dedicated authentication device or procedure being present for this session. It may be possible to initiate emergency calls to different emergency call centres, depending on the type of emergency. The following types of emergency calls shall be possible: - Police - Ambulance - Fire Brigade - Marine Guard - Mountain Rescue - Common emergency answering point - Spare, at least [three] different types The Man Machine Interface (MMI) on specific NGN Terminal may be specified by the regulatory authority in which the customer's service contract is agreed. This interface is then stored on this NGN Terminal and this shall be deployed whenever an emergency call/session is attempted. =20 It maybe possible to tie any emergency call number, specified in the preferred emergency call MMI(s) above, to any single emergency call type or to any combination of emergency types. The association between emergency numbers and emergency call type maybe able to be programmed on the NGN Terminal by the regulatory authority where the customer's service contract is agreed. Considering the "Directive 2002/21/EC on a common regulatory framework for electronic communications and services (the "Framework Directive"), and in particular Article 19". European Law [1] requires that 112 Emergency Voice services are available across the European Union, It is noted that in some countries (e.g. Germany) this code does not translate to the Police, where as in other counties (e.g. Italy) this is always delivered to the Police who include other Emergency services. In other countries 112 is delivered to a PSAP that offer a number of services. .... Note: if the NGN Terminal does not recognise the emergency call number but the serving network recognises the dialled number as an emergency call number used in the country. Then a normal call set up takes place and after the serving network has recognised the emergency number the call is routed as an emergency call. A user friendly MMI that specifies the type of emergency directly (e.g. via a menu) may be supported for use in any (i.e. home or visited) network to avoid the miss-connection in the nomadic case. This shall be allowed both with and without authentication procedures taken place. The serving network may download additional emergency numbers to the NGN Terminal in order to ensure that local emergency numbers are known to the NGN Terminal. The NGN Terminal shall regard these emergency numbers as valid in that country only and shall discard them when a new country is entered. 4.1.1 Identification of emergency numbers To handle nomadicity, the NGN Terminal shall be able to place calls on a locally supported Emergency number, it should be able store Emergency numbers, and in the case of a SIP Terminal, to store Emergency SIP URIs. When an Emergency call or session is required, the correct Number/URI is presented to the network on the basis of national knowledge and information made available at the Access to the network. In Europe, this shall be 112, and optionally a national possibly service specific number.) =09 Additional the NGN Terminal may store emergency numbers that may have been downloaded by the serving network. 4.1.2 Location information derivation and handling. The location information shall [2] be derived from the known information available in the network, to the extent technically feasible. Upon initiating the emergency session any location information shall be sent with the set-up of the session.=20 If all location information is not available at the time of the set-up of the emergency session then what is available is sent and the network may use other positioning means to obtain other location information This location information shall be identified as its to the origin, such that all the NGN Terminal derived location information is indicated to the emergency authority. The NGN Terminal provided Location Information is indicated such that the origin of the information can be verified. The location information shall be stored until the emergency authority no longer requires it. This location information is sent to appropriate emergency authority upon a request from this authority. The location information shall be treated as private information [3] and as such it is subject to the privacy regulation of data as specified by the regulatory authority where the session is initiated. This may include any authorisation and security procedures and obligations of the customer, NGN Terminal and emergency authority. 4.1.3 Domains priority and selection for NGN Terminal attempts to emergency call A PSTN/ISDN emulation subsystem and IMS subsystem capable NGN Terminal attempting an emergency call shall give priority to the PSTN/ISDN emulation subsystem domain.=20 In case where the call attempt in the PSTN/ISDN emulation subsystem domain fails, the NGN Terminal should automatically make a second attempt in the IMS subsystem domain, where the NGN Terminal is facilitated and attached to both domains. In the case where the NGN Terminal cannot support the IMS subsystem capabilities but is able to support the PSTN/ISDN emulation subsystem and the emergency call attempt in this domain fails the call is rejected and an indication to try again given to the caller. 4.2 Requirements for a PSTN/ISDN Emulation Subsystem and Simulation services in the IMS providing Emergency calls A PSTN/ISDN emulation subsystem and simulation services in the IMS shall support the emergency communication service as defined in SR 002 180 [4]. This clause deals with Emergency Voice services as mandated [1] hence the PSAP/ECC is assumed to be either in the PSTN/ISDN network or at least inter-worked to by a Media and boarder gateways. 4.3 Requirements for an IMS Subsystem Emergency Sessions This clause deals with Evolutionary services where Emergency sessions are established from a SIP Enabled terminal to a SIP enabled Emergency Control Centre, via a SIP enabled PSAP. Where the SIP enabled PSAP is viewed as a SIP Application Server in the IMS; the PSAP may select the appropriate ECC on the bases on the service requested in the Session Request (e.g. the SDP payload in the SIP INVITE). Where the PSAP is an enhanced termination Similar-forwarding capabilities may be provided before any optimally routed streaming media is established. The solution for emergency sessions in the IMS subsystem shall fulfil the following capability requirements: 1. It should be independent from the underlying IP connectivity network in respect to the detection and routing of emergency sessions. 2. All emergency contact identifiers, (e.g. emergency numbers, SIP emergency URIs) and any special indications for emergency sessions within the SIP signalling must be supported specifically IETF proposals on addressing should be taken into consideration. 3. Emergency sessions should have priority access to resources, when the network resources are under load, over "ordinary" sessions by the network. 4. Set-up of IMS emergency sessions shall be possible for users with a barred public user identity. 5. The primary solution shall be that the NGN Terminal will detect an initiation of an emergency session (e.g. by evaluating the SIP-URI or the dialled number) by itself and then indicates the emergency session to the network.=20 However the NGN shall also support the scenario where the NGN Terminal cannot detect an initiation of an emergency session, then the NGN shall be able to detect and indicate an emergency session in progress. 6. The NGN must be able to support the scenario where the authorisation of the NGN Terminal to the network is accomplished with the aid of an ISIM module. In this case the NGN shall be able to set-up an emergency session if this identification module is not present.=20 7. An Emergency Service shall not be a subscription service and will therefore be supported in a visited network and provided without interaction with a "Home" network for the nomadic case. =20 8. For the nomadicity scenario where an emergency session request is routed via the home network, the home network shall be able to detect that the session is for emergency service (whether indicated or not) and respond to the NGN Terminal indicating that the NGN Terminal should initiate an emergency session in the visited network. Alternatively the visited network may be able to detect that the session request is for an emergency session (whether indicated or not)and route to session to the appropriate PSAP/ECC. 9. The Location of the caller to the session establishment shall be supported according to clause 4.1.2 above in accordance with the EU Directives [2] and [3]. 10. PSAPs/Emergency control centres shall be connected to the PSTN/ISDN emulation domain, however the emergency centre may also be connected to the IMS domain or any other packet network. 11. PSAPs/Emergency control centres shall be able to call back the user, if a CLI is provided or ISIM is used to authenticate the user. In the ISIM-less Simulation Case this may not be possible. 12. The visited network shall be able to download emergency numbers to the NGN Terminal using procedures as described in TS 24.008 [5], in order to ensure that local emergency numbers are known to the NGN Terminal.=20 =20 .... 4.6 Architecture requirements The solution for emergency sessions shall also fulfil the following architectural requirements: 1. The architecture for Emergency Service should be driven by the specific capabilities requirements. Specification should minimise the changes to existing 3GPP IMS architecture and procedures, and re-use existing 3GPP IMS functional entities. However the specification should not be constrained by the existing functional entities. 2. The architecture should take into account that it may be possible to make emergency calls on other media than voice. It needs to take account support, for example, the deaf and hearing-impaired using a text phone that might generate information, for example, using procedures for Multimedia services or the 3GPP Instant Messaging Service based on the 3GPP IMS or the F-MMS messaging procedures. There may also be a need to work with phones that attempt the emergency call as a video telephony call. 3. The architecture should support the evolution of PSAPs/Emergency Control Centres from terminating access to the PSTN/ISDN, to direct inter-working via Media and boarder gateways, to the case where they are part of the SIP infrastructure. Allowing the case that not all PSAPs/ECC will migrate at the same time. Legacy ECC with Enhanced ISDN access only may persist for some time. 4. Service Inter-working is an important consideration if a SIP aware terminal places a multimedia, MMS or Instant message Emergency session to an PSAP/ECC that only supports ISDN voice. Rejection or fallback considerations will be serious. 4.7 Protocol & Security requirements The following issues have been identified as requirements that need a solution for the support of VoIP Technology. It has been identified that the following possible limitations for the support of Emergency Voice Services (e.g. E112 and SOS SIP URIs must be alleviated. These issues include: * Reliability of location information * Authentication of caller id and location stored in a NGN Terminal * Monitor and validate (1) terminal syntatical behavoiur (2) and network behabiour on denial of service attacks and mitigate against the effects of aforementioned behaviour. * VPN access problem: o Globally accessible routing o Secure routing globally * Enterprise DHCP server for location information (private) * Residential DHCP issues * Overhead of organisations that provide access to public Emergency Voice Services (e.g. E112) * Global/international regulation * PSAP reconnect capability _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 4 10:10:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26442; Fri, 4 Mar 2005 10:10:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7ET3-0004tq-H4; Fri, 04 Mar 2005 10:11:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7ENB-0006OZ-LI; Fri, 04 Mar 2005 10:05:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Ddc-0006q2-AU for ecrit@megatron.ietf.org; Fri, 04 Mar 2005 09:18:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21550 for ; Fri, 4 Mar 2005 09:18:42 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7DfB-0003iO-SN for sipping-emergency@ietf.org; Fri, 04 Mar 2005 09:20:22 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 04 Mar 2005 06:18:36 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,134,1107763200"; d="scan'208"; a="165191069:sNHT35028848" Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j24EIUTM004183; Fri, 4 Mar 2005 06:18:30 -0800 (PST) Received: from MLINSNER (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA17412; Fri, 4 Mar 2005 06:18:27 -0800 (PST) Message-Id: <200503041418.GAA17412@malone.cisco.com> From: "Marc Linsner" To: "'Stastny Richard'" , Subject: RE: [Ecrit] ETSI EMTEL Emergency Requirements Date: Fri, 4 Mar 2005 09:18:16 -0500 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: <32755D354E6B65498C3BD9FD496C7D4601D878@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Thread-Index: AcUVvu5EcwP4G1H9QVOn5aoNAVIoIgK9DnFAAAO8kiA= X-Spam-Score: 1.1 (+) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 04 Mar 2005 10:05:48 -0500 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 X-Spam-Score: 1.1 (+) X-Scan-Signature: 73f7847c44628482de9d5f1018acf469 Content-Transfer-Encoding: 7bit Richard, Thanks for submitting this....it's great to see other organizations working on emergency calling issues. I'll contact EMTEL to see if someone can formalize these into a draft. -Marc Linsner- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Stastny Richard > Sent: Friday, March 04, 2005 7:34 AM > To: sipping-emergency@ietf.org > Subject: [Ecrit] ETSI EMTEL Emergency Requirements > > Dear all, > > we have now quite a collection of requirements together. > > To complicate the issue further and complete the global view, > I want to add the (approved) requirements from Europe > submitted from EMTEL to ETSI TISPAN WG1 this week (05bTD017): > > 05bTD182r1 DES01019 _Requirements of the NGN network to support > the emergency service for communication from citizen to authority_ > > The requirements where also checked against the requirements for 3GPP > IMS as outlined in the draft TR 23 867. IT was then agreed that this > document is approved at the project level ... > > Best regards > Richard Stastny > > Citations from the document: > > 1 Scope > > The present document contains the requirements of a NGN to support > emergency communications (EMTEL) from the citizen to the authority. The > requirements are independent of the NGN subsystem and transport layer > unless specifically referred to. > > ..... > > 4 Emergency Sessions Requirements > > The following is a list of very high level requirements for an emergency > call/session between a user and the PSAP/ECC when an 112 type service is > requested. > > *Provide a voice link, maintained throughout the call > *Receive immediate priority treatment over other calls > *Must not be subject to restrictive network management practices > *Must be subject to normal call records, charging and accounting (even > though the call is free) > *Must provide a unique ID to enable a callback (eg CLI) and Network > Operator ID > *Originating geographic location must be automatically provided to > determine > - correct PSAP operator to route the call to > - appropriate local emergency service centre > - location to accurately despatch assistance. > *Location information must be automatically available at the PSAP centre > *Must be migrated to multi-party calls under the control of the PSAP > operator > *Shall be subject to "last party clear", or other method for handling > false calls > *Shall be restored with priority over normal calls. > *Need IP and PSTN Emergency Call Centre solution > > Note by Richard: this seems quite extreme, but is softened in the > further > text > > 4.1 General Requirements > > It shall be possible to establish a session for an emergency speech > call. These Emergency calls shall be routed to the emergency services in > accordance with the national regulations of where the caller is located > which may require that these calls receive a higher level of priority > than a normal communication.. An emergency call may be allowed to be > establish without the need to 'dial' a dedicated number to avoid a > mis-connection in the nomadic case, e.g. the use of entities such as > menu, by use of a 'red button' may be deployed. Emergency Calls may be > supported without a dedicated authentication device or procedure being > present for this session. > > Note: It will be left to the national authorities to decide whether the > network should accept emergency calls without the dedicated > authentication device or procedure being present for this session. > > It may be possible to initiate emergency calls to different emergency > call centres, depending on the type of emergency. The following types of > emergency calls shall be possible: > - Police > - Ambulance > - Fire Brigade > - Marine Guard > - Mountain Rescue > - Common emergency answering point > - Spare, at least [three] different types > > The Man Machine Interface (MMI) on specific NGN Terminal may be > specified by the regulatory authority in which the customer's service > contract is agreed. This interface is then stored on this NGN Terminal > and this shall be deployed whenever an emergency call/session is > attempted. > > It maybe possible to tie any emergency call number, specified in the > preferred emergency call MMI(s) above, to any single emergency call type > or to any combination of emergency types. The association between > emergency numbers and emergency call type maybe able to be programmed on > the NGN Terminal by the regulatory authority where the customer's > service contract is agreed. > > Considering the "Directive 2002/21/EC on a common regulatory framework > for electronic communications and services (the "Framework Directive"), > and in particular Article 19". European Law [1] requires that 112 > Emergency Voice services are available across the European Union, It is > noted that in some countries (e.g. Germany) this code does not translate > to the Police, where as in other counties (e.g. Italy) this is always > delivered to the Police who include other Emergency services. In other > countries 112 is delivered to a PSAP that offer a number of services. > > .... > > Note: if the NGN Terminal does not recognise the emergency call number > but the serving network recognises the dialled number as an emergency > call number used in the country. Then a normal call set up takes place > and after the serving network has recognised the emergency number the > call is routed as an emergency call. > > A user friendly MMI that specifies the type of emergency directly (e.g. > via a menu) may be supported for use in any (i.e. home or visited) > network to avoid the miss-connection in the nomadic case. This shall be > allowed both with and without authentication procedures taken place. > > The serving network may download additional emergency numbers to the NGN > Terminal in order to ensure that local emergency numbers are known to > the NGN Terminal. The NGN Terminal shall regard these emergency numbers > as valid in that country only and shall discard them when a new country > is entered. > > 4.1.1 Identification of emergency numbers > > To handle nomadicity, the NGN Terminal shall be able to place calls on a > locally supported Emergency number, it should be able store Emergency > numbers, and in the case of a SIP Terminal, to store Emergency SIP URIs. > When an Emergency call or session is required, the correct Number/URI is > presented to the network on the basis of national knowledge and > information made available at the Access to the network. In Europe, this > shall be 112, and optionally a national possibly service specific > number.) > > Additional the NGN Terminal may store emergency numbers that may have > been downloaded by the serving network. > > 4.1.2 Location information derivation and handling. > > The location information shall [2] be derived from the known information > available in the network, to the extent technically feasible. Upon > initiating the emergency session any location information shall be sent > with the set-up of the session. > > If all location information is not available at the time of the set-up > of the emergency session then what is available is sent and the network > may use other positioning means to obtain other location information > > This location information shall be identified as its to the origin, such > that all the NGN Terminal derived location information is indicated to > the emergency authority. The NGN Terminal provided Location Information > is indicated such that the origin of the information can be verified. > > The location information shall be stored until the emergency authority > no longer requires it. This location information is sent to appropriate > emergency authority upon a request from this authority. > > The location information shall be treated as private information [3] and > as such it is subject to the privacy regulation of data as specified by > the regulatory authority where the session is initiated. This may > include any authorisation and security procedures and obligations of the > customer, NGN Terminal and emergency authority. > > 4.1.3 Domains priority and selection for NGN Terminal attempts to > emergency call > > A PSTN/ISDN emulation subsystem and IMS subsystem capable NGN Terminal > attempting an emergency call shall give priority to the PSTN/ISDN > emulation subsystem domain. > > In case where the call attempt in the PSTN/ISDN emulation subsystem > domain fails, the NGN Terminal should automatically make a second > attempt in the IMS subsystem domain, where the NGN Terminal is > facilitated and attached to both domains. > > In the case where the NGN Terminal cannot support the IMS subsystem > capabilities but is able to support the PSTN/ISDN emulation subsystem > and the emergency call attempt in this domain fails the call is rejected > and an indication to try again given to the caller. > > 4.2 Requirements for a PSTN/ISDN Emulation Subsystem and Simulation > services in the IMS providing Emergency calls > > A PSTN/ISDN emulation subsystem and simulation services in the IMS shall > support the emergency communication service as defined in SR 002 180 > [4]. > This clause deals with Emergency Voice services as mandated [1] hence > the PSAP/ECC is assumed to be either in the PSTN/ISDN network or at > least inter-worked to by a Media and boarder gateways. > > 4.3 Requirements for an IMS Subsystem Emergency Sessions > > This clause deals with Evolutionary services where Emergency sessions > are established from a SIP Enabled terminal to a SIP enabled Emergency > Control Centre, via a SIP enabled PSAP. Where the SIP enabled PSAP is > viewed as a SIP Application Server in the IMS; the PSAP may select the > appropriate ECC on the bases on the service requested in the Session > Request (e.g. the SDP payload in the SIP INVITE). Where the PSAP is an > enhanced termination Similar-forwarding capabilities may be provided > before any optimally routed streaming media is established. > > The solution for emergency sessions in the IMS subsystem shall fulfil > the following capability requirements: > > 1. It should be independent from the underlying IP connectivity > network in respect to the detection and routing of emergency sessions. > > 2. All emergency contact identifiers, (e.g. emergency numbers, SIP > emergency URIs) and any special indications for emergency sessions > within the SIP signalling must be supported specifically IETF proposals > on addressing should be taken into consideration. > > 3. Emergency sessions should have priority access to resources, > when the network resources are under load, over "ordinary" sessions by > the network. > > 4. Set-up of IMS emergency sessions shall be possible for users > with a barred public user identity. > > 5. The primary solution shall be that the NGN Terminal will detect > an initiation of an emergency session (e.g. by evaluating the SIP-URI or > the dialled number) by itself and then indicates the emergency session > to the network. > > However the NGN shall also support the scenario where the NGN Terminal > cannot detect an initiation of an emergency session, then the NGN shall > be able to detect and indicate an emergency session in progress. > > 6. The NGN must be able to support the scenario where the > authorisation of the NGN Terminal to the network is accomplished with > the aid of an ISIM module. In this case the NGN shall be able to set-up > an emergency session if this identification module is not present. > > 7. An Emergency Service shall not be a subscription service and > will therefore be supported in a visited network and provided without > interaction with a "Home" network for the nomadic case. > > 8. For the nomadicity scenario where an emergency session request > is routed via the home network, the home network shall be able to detect > that the session is for emergency service (whether indicated or not) and > respond to the NGN Terminal indicating that the NGN Terminal should > initiate an emergency session in the visited network. > > Alternatively the visited network may be able to detect that the session > request is for an emergency session (whether indicated or not)and route > to session to the appropriate PSAP/ECC. > > 9. The Location of the caller to the session establishment shall be > supported according to clause 4.1.2 above in accordance with the EU > Directives [2] and [3]. > > 10. PSAPs/Emergency control centres shall be connected to the > PSTN/ISDN emulation domain, however the emergency centre may also be > connected to the IMS domain or any other packet network. > > 11. PSAPs/Emergency control centres shall be able to call back the > user, if a CLI is provided or ISIM is used to authenticate the user. In > the ISIM-less Simulation Case this may not be possible. > > 12. The visited network shall be able to download emergency numbers > to the NGN Terminal using procedures as described in TS 24.008 [5], in > order to ensure that local emergency numbers are known to the NGN > Terminal. > > .... > > 4.6 Architecture requirements > > The solution for emergency sessions shall also fulfil the following > architectural requirements: > > 1. The architecture for Emergency Service should be driven by the > specific capabilities requirements. Specification should minimise the > changes to existing 3GPP IMS architecture and procedures, and re-use > existing 3GPP IMS functional entities. However the specification should > not be constrained by the existing functional entities. > > 2. The architecture should take into account that it may be > possible to make emergency calls on other media than voice. It needs to > take account support, for example, the deaf and hearing-impaired using a > text phone that might generate information, for example, using > procedures for Multimedia services or the 3GPP Instant Messaging Service > based on the 3GPP IMS or the F-MMS messaging procedures. There may also > be a need to work with phones that attempt the emergency call as a video > telephony call. > > 3. The architecture should support the evolution of PSAPs/Emergency > Control Centres from terminating access to the PSTN/ISDN, to direct > inter-working via Media and boarder gateways, to the case where they are > part of the SIP infrastructure. Allowing the case that not all PSAPs/ECC > will migrate at the same time. Legacy ECC with Enhanced ISDN access only > may persist for some time. > > 4. Service Inter-working is an important consideration if a SIP > aware terminal places a multimedia, MMS or Instant message Emergency > session to an PSAP/ECC that only supports ISDN voice. Rejection or > fallback considerations will be serious. > > 4.7 Protocol & Security requirements > > The following issues have been identified as requirements that need a > solution for the support of VoIP Technology. It has been identified that > the following possible limitations for the support of Emergency Voice > Services (e.g. E112 and SOS SIP URIs must be alleviated. These issues > include: > * Reliability of location information > * Authentication of caller id and location stored in a NGN > Terminal > * Monitor and validate (1) terminal syntatical behavoiur (2) and > network behabiour on denial of service attacks and mitigate against the > effects of aforementioned behaviour. > * VPN access problem: > o Globally accessible routing > o Secure routing globally > * Enterprise DHCP server for location information (private) > * Residential DHCP issues > * Overhead of organisations that provide access to public > Emergency Voice Services (e.g. E112) > * Global/international regulation > * PSAP reconnect capability > > > _______________________________________________ > 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 Mar 4 15:03:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26772; Fri, 4 Mar 2005 15:03:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7J2g-0004Yo-3f; Fri, 04 Mar 2005 15:04:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Izc-0007Cn-7w; Fri, 04 Mar 2005 15:01:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7ILc-00080I-V7 for ecrit@megatron.ietf.org; Fri, 04 Mar 2005 14:20:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22496 for ; Fri, 4 Mar 2005 14:20:28 -0500 (EST) 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.33) id 1D7INF-0003VH-ON for sipping-emergency@ietf.org; Fri, 04 Mar 2005 14:22:10 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 04 Mar 2005 11:34:52 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,135,1107763200"; d="scan'208"; a="617868820:sNHT28307848" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j24JK1q8008369; Fri, 4 Mar 2005 11:20:02 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA14605; Fri, 4 Mar 2005 11:20:06 -0800 (PST) Message-Id: <4.3.2.7.2.20050304130904.03d8f358@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 Mar 2005 13:20:16 -0600 To: "Marc Linsner" , "'Stastny Richard'" , From: "James M. Polk" Subject: RE: [Ecrit] ETSI EMTEL Emergency Requirements In-Reply-To: <200503041418.GAA17412@malone.cisco.com> References: <32755D354E6B65498C3BD9FD496C7D4601D878@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 1df8e4abc9851cb4adb45bd64d8514ae X-Mailman-Approved-At: Fri, 04 Mar 2005 15:01:47 -0500 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 X-Spam-Score: 1.1 (+) X-Scan-Signature: 2bcdb6f0ba9636bf286b7e28ccb8bd9b Richard Yes, I it good to read ETSI's proposal. I agree the short list is rather extreme, but when reading the individual sections, I am not reading most accounting for the Internet Protocol. There is text, for example with respect to priority in 4.1.3, that only references ISDN. I'm confused by this and wouldn't know where to go next in the IETF to address that (and other) requirements that don't talk (perhaps enough) to IP. Do you have any suggestions or more information? I'd also be curious to read the list of references within the text. At 09:18 AM 3/4/2005 -0500, Marc Linsner wrote: >Richard, > >Thanks for submitting this....it's great to see other organizations working >on emergency calling issues. > >I'll contact EMTEL to see if someone can formalize these into a draft. > >-Marc Linsner- > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > > Stastny Richard > > Sent: Friday, March 04, 2005 7:34 AM > > To: sipping-emergency@ietf.org > > Subject: [Ecrit] ETSI EMTEL Emergency Requirements > > > > Dear all, > > > > we have now quite a collection of requirements together. > > > > To complicate the issue further and complete the global view, > > I want to add the (approved) requirements from Europe > > submitted from EMTEL to ETSI TISPAN WG1 this week (05bTD017): > > > > 05bTD182r1 DES01019 _Requirements of the NGN network to support > > the emergency service for communication from citizen to authority_ > > > > The requirements where also checked against the requirements for 3GPP > > IMS as outlined in the draft TR 23 867. IT was then agreed that this > > document is approved at the project level ... > > > > Best regards > > Richard Stastny > > > > Citations from the document: > > > > 1 Scope > > > > The present document contains the requirements of a NGN to support > > emergency communications (EMTEL) from the citizen to the authority. The > > requirements are independent of the NGN subsystem and transport layer > > unless specifically referred to. > > > > ..... > > > > 4 Emergency Sessions Requirements > > > > The following is a list of very high level requirements for an emergency > > call/session between a user and the PSAP/ECC when an 112 type service is > > requested. > > > > *Provide a voice link, maintained throughout the call > > *Receive immediate priority treatment over other calls > > *Must not be subject to restrictive network management practices > > *Must be subject to normal call records, charging and accounting (even > > though the call is free) > > *Must provide a unique ID to enable a callback (eg CLI) and Network > > Operator ID > > *Originating geographic location must be automatically provided to > > determine > > - correct PSAP operator to route the call to > > - appropriate local emergency service centre > > - location to accurately despatch assistance. > > *Location information must be automatically available at the PSAP centre > > *Must be migrated to multi-party calls under the control of the PSAP > > operator > > *Shall be subject to "last party clear", or other method for handling > > false calls > > *Shall be restored with priority over normal calls. > > *Need IP and PSTN Emergency Call Centre solution > > > > Note by Richard: this seems quite extreme, but is softened in the > > further > > text > > > > 4.1 General Requirements > > > > It shall be possible to establish a session for an emergency speech > > call. These Emergency calls shall be routed to the emergency services in > > accordance with the national regulations of where the caller is located > > which may require that these calls receive a higher level of priority > > than a normal communication.. An emergency call may be allowed to be > > establish without the need to 'dial' a dedicated number to avoid a > > mis-connection in the nomadic case, e.g. the use of entities such as > > menu, by use of a 'red button' may be deployed. Emergency Calls may be > > supported without a dedicated authentication device or procedure being > > present for this session. > > > > Note: It will be left to the national authorities to decide whether the > > network should accept emergency calls without the dedicated > > authentication device or procedure being present for this session. > > > > It may be possible to initiate emergency calls to different emergency > > call centres, depending on the type of emergency. The following types of > > emergency calls shall be possible: > > - Police > > - Ambulance > > - Fire Brigade > > - Marine Guard > > - Mountain Rescue > > - Common emergency answering point > > - Spare, at least [three] different types > > > > The Man Machine Interface (MMI) on specific NGN Terminal may be > > specified by the regulatory authority in which the customer's service > > contract is agreed. This interface is then stored on this NGN Terminal > > and this shall be deployed whenever an emergency call/session is > > attempted. > > > > It maybe possible to tie any emergency call number, specified in the > > preferred emergency call MMI(s) above, to any single emergency call type > > or to any combination of emergency types. The association between > > emergency numbers and emergency call type maybe able to be programmed on > > the NGN Terminal by the regulatory authority where the customer's > > service contract is agreed. > > > > Considering the "Directive 2002/21/EC on a common regulatory framework > > for electronic communications and services (the "Framework Directive"), > > and in particular Article 19". European Law [1] requires that 112 > > Emergency Voice services are available across the European Union, It is > > noted that in some countries (e.g. Germany) this code does not translate > > to the Police, where as in other counties (e.g. Italy) this is always > > delivered to the Police who include other Emergency services. In other > > countries 112 is delivered to a PSAP that offer a number of services. > > > > .... > > > > Note: if the NGN Terminal does not recognise the emergency call number > > but the serving network recognises the dialled number as an emergency > > call number used in the country. Then a normal call set up takes place > > and after the serving network has recognised the emergency number the > > call is routed as an emergency call. > > > > A user friendly MMI that specifies the type of emergency directly (e.g. > > via a menu) may be supported for use in any (i.e. home or visited) > > network to avoid the miss-connection in the nomadic case. This shall be > > allowed both with and without authentication procedures taken place. > > > > The serving network may download additional emergency numbers to the NGN > > Terminal in order to ensure that local emergency numbers are known to > > the NGN Terminal. The NGN Terminal shall regard these emergency numbers > > as valid in that country only and shall discard them when a new country > > is entered. > > > > 4.1.1 Identification of emergency numbers > > > > To handle nomadicity, the NGN Terminal shall be able to place calls on a > > locally supported Emergency number, it should be able store Emergency > > numbers, and in the case of a SIP Terminal, to store Emergency SIP URIs. > > When an Emergency call or session is required, the correct Number/URI is > > presented to the network on the basis of national knowledge and > > information made available at the Access to the network. In Europe, this > > shall be 112, and optionally a national possibly service specific > > number.) > > > > Additional the NGN Terminal may store emergency numbers that may have > > been downloaded by the serving network. > > > > 4.1.2 Location information derivation and handling. > > > > The location information shall [2] be derived from the known information > > available in the network, to the extent technically feasible. Upon > > initiating the emergency session any location information shall be sent > > with the set-up of the session. > > > > If all location information is not available at the time of the set-up > > of the emergency session then what is available is sent and the network > > may use other positioning means to obtain other location information > > > > This location information shall be identified as its to the origin, such > > that all the NGN Terminal derived location information is indicated to > > the emergency authority. The NGN Terminal provided Location Information > > is indicated such that the origin of the information can be verified. > > > > The location information shall be stored until the emergency authority > > no longer requires it. This location information is sent to appropriate > > emergency authority upon a request from this authority. > > > > The location information shall be treated as private information [3] and > > as such it is subject to the privacy regulation of data as specified by > > the regulatory authority where the session is initiated. This may > > include any authorisation and security procedures and obligations of the > > customer, NGN Terminal and emergency authority. > > > > 4.1.3 Domains priority and selection for NGN Terminal attempts to > > emergency call > > > > A PSTN/ISDN emulation subsystem and IMS subsystem capable NGN Terminal > > attempting an emergency call shall give priority to the PSTN/ISDN > > emulation subsystem domain. > > > > In case where the call attempt in the PSTN/ISDN emulation subsystem > > domain fails, the NGN Terminal should automatically make a second > > attempt in the IMS subsystem domain, where the NGN Terminal is > > facilitated and attached to both domains. > > > > In the case where the NGN Terminal cannot support the IMS subsystem > > capabilities but is able to support the PSTN/ISDN emulation subsystem > > and the emergency call attempt in this domain fails the call is rejected > > and an indication to try again given to the caller. > > > > 4.2 Requirements for a PSTN/ISDN Emulation Subsystem and Simulation > > services in the IMS providing Emergency calls > > > > A PSTN/ISDN emulation subsystem and simulation services in the IMS shall > > support the emergency communication service as defined in SR 002 180 > > [4]. > > This clause deals with Emergency Voice services as mandated [1] hence > > the PSAP/ECC is assumed to be either in the PSTN/ISDN network or at > > least inter-worked to by a Media and boarder gateways. > > > > 4.3 Requirements for an IMS Subsystem Emergency Sessions > > > > This clause deals with Evolutionary services where Emergency sessions > > are established from a SIP Enabled terminal to a SIP enabled Emergency > > Control Centre, via a SIP enabled PSAP. Where the SIP enabled PSAP is > > viewed as a SIP Application Server in the IMS; the PSAP may select the > > appropriate ECC on the bases on the service requested in the Session > > Request (e.g. the SDP payload in the SIP INVITE). Where the PSAP is an > > enhanced termination Similar-forwarding capabilities may be provided > > before any optimally routed streaming media is established. > > > > The solution for emergency sessions in the IMS subsystem shall fulfil > > the following capability requirements: > > > > 1. It should be independent from the underlying IP connectivity > > network in respect to the detection and routing of emergency sessions. > > > > 2. All emergency contact identifiers, (e.g. emergency numbers, SIP > > emergency URIs) and any special indications for emergency sessions > > within the SIP signalling must be supported specifically IETF proposals > > on addressing should be taken into consideration. > > > > 3. Emergency sessions should have priority access to resources, > > when the network resources are under load, over "ordinary" sessions by > > the network. > > > > 4. Set-up of IMS emergency sessions shall be possible for users > > with a barred public user identity. > > > > 5. The primary solution shall be that the NGN Terminal will detect > > an initiation of an emergency session (e.g. by evaluating the SIP-URI or > > the dialled number) by itself and then indicates the emergency session > > to the network. > > > > However the NGN shall also support the scenario where the NGN Terminal > > cannot detect an initiation of an emergency session, then the NGN shall > > be able to detect and indicate an emergency session in progress. > > > > 6. The NGN must be able to support the scenario where the > > authorisation of the NGN Terminal to the network is accomplished with > > the aid of an ISIM module. In this case the NGN shall be able to set-up > > an emergency session if this identification module is not present. > > > > 7. An Emergency Service shall not be a subscription service and > > will therefore be supported in a visited network and provided without > > interaction with a "Home" network for the nomadic case. > > > > 8. For the nomadicity scenario where an emergency session request > > is routed via the home network, the home network shall be able to detect > > that the session is for emergency service (whether indicated or not) and > > respond to the NGN Terminal indicating that the NGN Terminal should > > initiate an emergency session in the visited network. > > > > Alternatively the visited network may be able to detect that the session > > request is for an emergency session (whether indicated or not)and route > > to session to the appropriate PSAP/ECC. > > > > 9. The Location of the caller to the session establishment shall be > > supported according to clause 4.1.2 above in accordance with the EU > > Directives [2] and [3]. > > > > 10. PSAPs/Emergency control centres shall be connected to the > > PSTN/ISDN emulation domain, however the emergency centre may also be > > connected to the IMS domain or any other packet network. > > > > 11. PSAPs/Emergency control centres shall be able to call back the > > user, if a CLI is provided or ISIM is used to authenticate the user. In > > the ISIM-less Simulation Case this may not be possible. > > > > 12. The visited network shall be able to download emergency numbers > > to the NGN Terminal using procedures as described in TS 24.008 [5], in > > order to ensure that local emergency numbers are known to the NGN > > Terminal. > > > > .... > > > > 4.6 Architecture requirements > > > > The solution for emergency sessions shall also fulfil the following > > architectural requirements: > > > > 1. The architecture for Emergency Service should be driven by the > > specific capabilities requirements. Specification should minimise the > > changes to existing 3GPP IMS architecture and procedures, and re-use > > existing 3GPP IMS functional entities. However the specification should > > not be constrained by the existing functional entities. > > > > 2. The architecture should take into account that it may be > > possible to make emergency calls on other media than voice. It needs to > > take account support, for example, the deaf and hearing-impaired using a > > text phone that might generate information, for example, using > > procedures for Multimedia services or the 3GPP Instant Messaging Service > > based on the 3GPP IMS or the F-MMS messaging procedures. There may also > > be a need to work with phones that attempt the emergency call as a video > > telephony call. > > > > 3. The architecture should support the evolution of PSAPs/Emergency > > Control Centres from terminating access to the PSTN/ISDN, to direct > > inter-working via Media and boarder gateways, to the case where they are > > part of the SIP infrastructure. Allowing the case that not all PSAPs/ECC > > will migrate at the same time. Legacy ECC with Enhanced ISDN access only > > may persist for some time. > > > > 4. Service Inter-working is an important consideration if a SIP > > aware terminal places a multimedia, MMS or Instant message Emergency > > session to an PSAP/ECC that only supports ISDN voice. Rejection or > > fallback considerations will be serious. > > > > 4.7 Protocol & Security requirements > > > > The following issues have been identified as requirements that need a > > solution for the support of VoIP Technology. It has been identified that > > the following possible limitations for the support of Emergency Voice > > Services (e.g. E112 and SOS SIP URIs must be alleviated. These issues > > include: > > * Reliability of location information > > * Authentication of caller id and location stored in a NGN > > Terminal > > * Monitor and validate (1) terminal syntatical behavoiur (2) and > > network behabiour on denial of service attacks and mitigate against the > > effects of aforementioned behaviour. > > * VPN access problem: > > o Globally accessible routing > > o Secure routing globally > > * Enterprise DHCP server for location information (private) > > * Residential DHCP issues > > * Overhead of organisations that provide access to public > > Emergency Voice Services (e.g. E112) > > * Global/international regulation > > * PSAP reconnect capability > > > > > > _______________________________________________ > > 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 Fri Mar 4 16:01:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03401; Fri, 4 Mar 2005 16:01:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7JxB-00060e-Dq; Fri, 04 Mar 2005 16:03:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7JvG-0001ha-Os; Fri, 04 Mar 2005 16:01:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Jri-0000w7-Pd for ecrit@megatron.ietf.org; Fri, 04 Mar 2005 15:57:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02934 for ; Fri, 4 Mar 2005 15:57:40 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D7JtL-0005lo-1U for sipping-emergency@ietf.org; Fri, 04 Mar 2005 15:59:24 -0500 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] ETSI EMTEL Emergency Requirements Date: Fri, 4 Mar 2005 21:59:50 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D46FBD3@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] ETSI EMTEL Emergency Requirements Thread-Index: AcUg743r/CNnHJooQ2Kq57OHtN92EwACoPjr From: "Stastny Richard" To: "James M. Polk" , "Marc Linsner" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 04 Mar 2005 16:01:20 -0500 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable James, =20 I agree that Section 4.1.3 (and also 4.2) is confusing for IETF folks, (I have to admit that I also do not understand them to full extent), but these sections are not talking about ISDN, they are talking about PSTN/ISDN Emulation and Simulation Subsystems for NGN. =20 Both are within the scope of ecrit. =20 A short (and very vague) tutorial: ETSI TISPAN is standardizimg the NGN for fixed networks. TISPAN has decided to use as a basis the NGN IMS as standardized by 3GPP for mobile systems. 3GPP has decided to base the IMS on SIP. Since fixed networks are migrating from TDM to IP, even if they use IP in the core, the still wil have (and are obliged to = provide) PSTN/ISDN services to existing customers. To be able to do so, they need = to provide additional subsystems for ISDN/PSTN Enumlation/Simulation. =20 What is the difference between Emulation and Simulation? Here the official definition: =20 PSTN/ISDN Emulation: Mimicing a PSTN/ISDN network from the point of view = of a legacy terminal by an IP network, through a gateway. All PSTN/ISDN = services=20 remain available and identical (i.e. with the same ergonomics); such = that end users=20 are unaware that they are not connected to a TDM-based PSTN/ISDN. PSTN Simulation: The provision of PSTN/ISDN-like services to advanced = terminals=20 such as IP-phones. There is no strict requirement to make all PSTN/ ISDN = services=20 available or identical, although end users expect to have access to the = most popular=20 ones, possibly with different ergonomics. So PSTN/ISDN Simulation is pure IP/SIP from the terminal to the PSAP, so = it is definetely withn the scope of ecrit.=20 PSTN/ISDN Emulation uses POTS/ISDN Terminals, but is then converted to = IP at a gateway on from this point to the PSAP is is also pure IP/SIP. This = means it also within the scope of ecrit. Richard PS: the references I left out: [1] Directive 2002/21/EC on a common regulatory framework for = electronic communications=20 and services (the "Framework Directive"), and in particular Article 19 [2] Directive 2002/22/EC on universal service and users rights relating = to electronic=20 communications networks and services (the "Universal Service Directive") [3] Directive 2002/58/EC on a concerning the processing of personal = data and the=20 protection of privacy in the electronic communications sector (the = "Directive on=20 privacy and electronic communications") [4] SR 002 180 ETSI Special Report: EMTEL Requirements for = communication of=20 citizens with authorities/organizations in case of distress (emergency = call handling) [5] TS 24.008 Digital cellular telecommunications system (Phase2+); = Universal Mobile=20 Telecommunicatios System (UMTS); Mobile radio interface Layer 3 = specification;=20 Core network protocols; [TR 23 867] 3GPP TR 23 867: " Internet Protocol (IP) based IP = Multimedia Subsystem (IMS)=20 emergency sessions; Release 7". =20 =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 4 17:07:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10322; Fri, 4 Mar 2005 17:07:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7KzN-0007dC-Kr; Fri, 04 Mar 2005 17:09:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Kwm-0004mh-2v; Fri, 04 Mar 2005 17:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Kiw-0002J4-HO for ecrit@megatron.ietf.org; Fri, 04 Mar 2005 16:52:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09075 for ; Fri, 4 Mar 2005 16:52:40 -0500 (EST) 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.33) id 1D7Kka-0007GH-Jx for sipping-emergency@ietf.org; Fri, 04 Mar 2005 16:54:25 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 Mar 2005 14:05:57 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j24LqdZV003570 for ; Fri, 4 Mar 2005 13:52:40 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA08190 for ; Fri, 4 Mar 2005 13:52:38 -0800 (PST) Message-Id: <4.3.2.7.2.20050304155209.03ba95d0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 Mar 2005 15:52:48 -0600 To: From: "James M. Polk" Subject: Re: [Ecrit] ETSI EMTEL Emergency Requirements In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FBD3@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 386e0819b1192672467565a524848168 X-Mailman-Approved-At: Fri, 04 Mar 2005 17:06:58 -0500 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 X-Spam-Score: 1.1 (+) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Richard thanks for the clarification At 09:59 PM 3/4/2005 +0100, Stastny Richard wrote: >James, > >I agree that Section 4.1.3 (and also 4.2) is confusing for IETF folks, >(I have to admit that I also do not understand them to full extent), >but these sections are not talking about ISDN, they are talking about >PSTN/ISDN Emulation and Simulation Subsystems for NGN. > >Both are within the scope of ecrit. > >A short (and very vague) tutorial: >ETSI TISPAN is standardizimg the NGN for fixed networks. TISPAN has >decided to use as a basis the NGN IMS as standardized by 3GPP for >mobile systems. 3GPP has decided to base the IMS on SIP. >Since fixed networks are migrating from TDM to IP, >even if they use IP in the core, the still wil have (and are obliged to >provide) >PSTN/ISDN services to existing customers. To be able to do so, they need >to provide additional subsystems for ISDN/PSTN Enumlation/Simulation. > >What is the difference between Emulation and Simulation? >Here the official definition: > >PSTN/ISDN Emulation: Mimicing a PSTN/ISDN network from the point of view >of a legacy terminal by an IP network, through a gateway. All PSTN/ISDN >services >remain available and identical (i.e. with the same ergonomics); such that >end users >are unaware that they are not connected to a TDM-based PSTN/ISDN. > >PSTN Simulation: The provision of PSTN/ISDN-like services to advanced >terminals >such as IP-phones. There is no strict requirement to make all PSTN/ ISDN >services >available or identical, although end users expect to have access to the >most popular >ones, possibly with different ergonomics. > >So PSTN/ISDN Simulation is pure IP/SIP from the terminal to the PSAP, so it >is definetely withn the scope of ecrit. > >PSTN/ISDN Emulation uses POTS/ISDN Terminals, but is then converted to IP at >a gateway on from this point to the PSAP is is also pure IP/SIP. This >means it also >within the scope of ecrit. > >Richard > >PS: the references I left out: > >[1] Directive 2002/21/EC on a common regulatory framework for electronic >communications >and services (the "Framework Directive"), and in particular Article 19 > >[2] Directive 2002/22/EC on universal service and users rights relating >to electronic >communications networks and services (the "Universal Service Directive") > >[3] Directive 2002/58/EC on a concerning the processing of personal data >and the >protection of privacy in the electronic communications sector (the >"Directive on >privacy and electronic communications") > > [4] SR 002 180 ETSI Special Report: EMTEL Requirements for > communication of >citizens with authorities/organizations in case of distress (emergency >call handling) > >[5] TS 24.008 Digital cellular telecommunications system (Phase2+); >Universal Mobile >Telecommunicatios System (UMTS); Mobile radio interface Layer 3 >specification; >Core network protocols; >[TR 23 867] 3GPP TR 23 867: " Internet Protocol (IP) based IP Multimedia >Subsystem (IMS) >emergency sessions; Release 7". > > > > 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 Sat Mar 5 09:05:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16948; Sat, 5 Mar 2005 09:05:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Zvh-0003GK-Tt; Sat, 05 Mar 2005 09:06:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Zrv-00039n-Lh; Sat, 05 Mar 2005 09:02:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7MN3-0004Yt-VS for ecrit@megatron.ietf.org; Fri, 04 Mar 2005 18:38:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19871 for ; Fri, 4 Mar 2005 18:38:10 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D7MOi-0001Xm-Gy for sipping-emergency@ietf.org; Fri, 04 Mar 2005 18:39:57 -0500 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] ETSI EMTEL Emergency Requirements Date: Sat, 5 Mar 2005 00:40:22 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D46FBD5@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] ETSI EMTEL Emergency Requirements Thread-Index: AcUg743r/CNnHJooQ2Kq57OHtN92EwACoPjrAASdfjAAAX8WIw== From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "James Polk \(jmpolk\)" , "Marc Linsner \(mlinsner\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 05 Mar 2005 09:02:55 -0500 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: quoted-printable Mike, =20 First: I am not representing here the TISPAN IMS NGN, I only wanted that = the ecrit audience gets as much as possible a complete picture of the beasts = out there. =20 Second: PSTN Emulation in it simplest case is a POTS phone attached to a = terminal adaptor. If the a/b wire is 30 inches long or two miles does not matter. = So if you have a POTS phone and your telco decides to replace the linecard in a Nortel = switch with a "TA" and a gateway, you would not and should not notice. This is PSTN = Emulation. =20 But we both agree that a customer connected to Vonage with a TA is = within scope of ecrit? =20 Richard ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Gesendet: Sa 05.03.2005 00:12 An: Stastny Richard; James Polk (jmpolk); Marc Linsner (mlinsner); = sipping-emergency@ietf.org Betreff: RE: [Ecrit] ETSI EMTEL Emergency Requirements Richard, Two points: 1) I hope that PSTN Emulation as you have described it is limited to the small set of wireless features that wireless technologies chose to implement, not the wider set of 400-500 features that wireline PSTN switches implemented. 2) I thought that ECRIT was focusing on the ability of IP terminals to access IP-based PSAPs and legacy PSTN E911 service infrastructure, but not necessarily attempting to define services to be delivered to the legacy PSTN terminals. After all, those terminals already get the existing PSTN services, including E911. Is that a migration need? Note that your definitions do not cover IP access to the legacy PSAP infrastructure. Terminal Service PSTN----L---->PSTN L=3Dlegacy | ^ E=3Demulation +-----E-----+ | ?=3Dmissing | | S=3Dsimulation +------?-------+ | | | V IP------S---->IP I prefer priority work on PSTN Simulation, where the IP terminal gets IP service that is equivalent (not exactly equal?) to the PSTN service, since I think the all IP solution could end up cheaper, faster, cleaner (than legacy solution) to implement than some PSAP people think. Modulo politics =3D ... OK, nevermind. Mike >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Stastny Richard >Sent: Friday, March 04, 2005 4:00 PM >To: James Polk (jmpolk); Marc Linsner (mlinsner); >sipping-emergency@ietf.org >Subject: Re: [Ecrit] ETSI EMTEL Emergency Requirements > >James, > >I agree that Section 4.1.3 (and also 4.2) is confusing for >IETF folks, (I have to admit that I also do not understand >them to full extent), but these sections are not talking about >ISDN, they are talking about PSTN/ISDN Emulation and >Simulation Subsystems for NGN. > >Both are within the scope of ecrit. > >A short (and very vague) tutorial: >ETSI TISPAN is standardizimg the NGN for fixed networks. >TISPAN has decided to use as a basis the NGN IMS as >standardized by 3GPP for mobile systems. 3GPP has decided to >base the IMS on SIP. >Since fixed networks are migrating from TDM to IP, even if >they use IP in the core, the still wil have (and are obliged >to provide) PSTN/ISDN services to existing customers. To be >able to do so, they need to provide additional subsystems for >ISDN/PSTN Enumlation/Simulation. > >What is the difference between Emulation and Simulation? >Here the official definition: > >PSTN/ISDN Emulation: Mimicing a PSTN/ISDN network from the >point of view of a legacy terminal by an IP network, through a >gateway. All PSTN/ISDN services remain available and identical >(i.e. with the same ergonomics); such that end users are >unaware that they are not connected to a TDM-based PSTN/ISDN. > >PSTN Simulation: The provision of PSTN/ISDN-like services to >advanced terminals such as IP-phones. There is no strict >requirement to make all PSTN/ ISDN services available or >identical, although end users expect to have access to the >most popular ones, possibly with different ergonomics. > >So PSTN/ISDN Simulation is pure IP/SIP from the terminal to >the PSAP, so it is definetely withn the scope of ecrit. > >PSTN/ISDN Emulation uses POTS/ISDN Terminals, but is then >converted to IP at a gateway on from this point to the PSAP is >is also pure IP/SIP. This means it also within the scope of ecrit. > >Richard > >PS: the references I left out: > >[1] Directive 2002/21/EC on a common regulatory framework for >electronic communications and services (the "Framework >Directive"), and in particular Article 19 > >[2] Directive 2002/22/EC on universal service and users >rights relating to electronic communications networks and >services (the "Universal Service Directive") > >[3] Directive 2002/58/EC on a concerning the processing of >personal data and the >protection of privacy in the electronic communications sector >(the "Directive on privacy and electronic communications") > > [4] SR 002 180 ETSI Special Report: EMTEL Requirements for >communication of citizens with authorities/organizations in >case of distress (emergency call handling) > >[5] TS 24.008 Digital cellular telecommunications system >(Phase2+); Universal Mobile Telecommunicatios System (UMTS); >Mobile radio interface Layer 3 specification; Core network >protocols; [TR 23 867] 3GPP TR 23 867: " Internet Protocol >(IP) based IP Multimedia Subsystem (IMS) emergency sessions; >Release 7". > > > > > >_______________________________________________ >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 Mar 5 09:05:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16978; Sat, 5 Mar 2005 09:05:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Zvy-0003Gd-OM; Sat, 05 Mar 2005 09:07:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Zrv-00039i-E1; Sat, 05 Mar 2005 09:02:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Lyp-0006gs-Ir for ecrit@megatron.ietf.org; Fri, 04 Mar 2005 18:13:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15857 for ; Fri, 4 Mar 2005 18:13:08 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7M0R-0000aU-9h for sipping-emergency@ietf.org; Fri, 04 Mar 2005 18:14:54 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 04 Mar 2005 18:28:26 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,137,1107752400"; d="scan'208"; a="39340580:sNHT23019984" 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 j24NCo1j001674; Fri, 4 Mar 2005 18:12:56 -0500 (EST) 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); Fri, 4 Mar 2005 18:12:50 -0500 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] ETSI EMTEL Emergency Requirements Date: Fri, 4 Mar 2005 18:12:49 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E37B4A@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] ETSI EMTEL Emergency Requirements Thread-Index: AcUg743r/CNnHJooQ2Kq57OHtN92EwACoPjrAASdfjA= From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "James Polk \(jmpolk\)" , "Marc Linsner \(mlinsner\)" , X-OriginalArrivalTime: 04 Mar 2005 23:12:50.0518 (UTC) FILETIME=[AFA80F60:01C5210F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 05 Mar 2005 09:02:55 -0500 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: quoted-printable Richard, Two points: 1) I hope that PSTN Emulation as you have described it is limited to the small set of wireless features that wireless technologies chose to implement, not the wider set of 400-500 features that wireline PSTN switches implemented. 2) I thought that ECRIT was focusing on the ability of IP terminals to access IP-based PSAPs and legacy PSTN E911 service infrastructure, but not necessarily attempting to define services to be delivered to the legacy PSTN terminals. After all, those terminals already get the existing PSTN services, including E911. Is that a migration need? Note that your definitions do not cover IP access to the legacy PSAP infrastructure. Terminal Service PSTN----L---->PSTN L=3Dlegacy | ^ E=3Demulation +-----E-----+ | ?=3Dmissing | | S=3Dsimulation +------?-------+ | | | V IP------S---->IP I prefer priority work on PSTN Simulation, where the IP terminal gets IP service that is equivalent (not exactly equal?) to the PSTN service, since I think the all IP solution could end up cheaper, faster, cleaner (than legacy solution) to implement than some PSAP people think. Modulo politics =3D ... OK, nevermind. Mike >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Stastny Richard >Sent: Friday, March 04, 2005 4:00 PM >To: James Polk (jmpolk); Marc Linsner (mlinsner);=20 >sipping-emergency@ietf.org >Subject: Re: [Ecrit] ETSI EMTEL Emergency Requirements > >James, >=20 >I agree that Section 4.1.3 (and also 4.2) is confusing for=20 >IETF folks, (I have to admit that I also do not understand=20 >them to full extent), but these sections are not talking about=20 >ISDN, they are talking about PSTN/ISDN Emulation and=20 >Simulation Subsystems for NGN. >=20 >Both are within the scope of ecrit. >=20 >A short (and very vague) tutorial: >ETSI TISPAN is standardizimg the NGN for fixed networks.=20 >TISPAN has decided to use as a basis the NGN IMS as=20 >standardized by 3GPP for mobile systems. 3GPP has decided to=20 >base the IMS on SIP. >Since fixed networks are migrating from TDM to IP, even if=20 >they use IP in the core, the still wil have (and are obliged=20 >to provide) PSTN/ISDN services to existing customers. To be=20 >able to do so, they need to provide additional subsystems for=20 >ISDN/PSTN Enumlation/Simulation. >=20 >What is the difference between Emulation and Simulation? >Here the official definition: >=20 >PSTN/ISDN Emulation: Mimicing a PSTN/ISDN network from the=20 >point of view of a legacy terminal by an IP network, through a=20 >gateway. All PSTN/ISDN services remain available and identical=20 >(i.e. with the same ergonomics); such that end users are=20 >unaware that they are not connected to a TDM-based PSTN/ISDN. > >PSTN Simulation: The provision of PSTN/ISDN-like services to=20 >advanced terminals such as IP-phones. There is no strict=20 >requirement to make all PSTN/ ISDN services available or=20 >identical, although end users expect to have access to the=20 >most popular ones, possibly with different ergonomics. > >So PSTN/ISDN Simulation is pure IP/SIP from the terminal to=20 >the PSAP, so it is definetely withn the scope of ecrit.=20 > >PSTN/ISDN Emulation uses POTS/ISDN Terminals, but is then=20 >converted to IP at a gateway on from this point to the PSAP is=20 >is also pure IP/SIP. This means it also within the scope of ecrit. > >Richard > >PS: the references I left out: > >[1] Directive 2002/21/EC on a common regulatory framework for=20 >electronic communications and services (the "Framework=20 >Directive"), and in particular Article 19 > >[2] Directive 2002/22/EC on universal service and users=20 >rights relating to electronic communications networks and=20 >services (the "Universal Service Directive") > >[3] Directive 2002/58/EC on a concerning the processing of=20 >personal data and the=20 >protection of privacy in the electronic communications sector=20 >(the "Directive on privacy and electronic communications") > > [4] SR 002 180 ETSI Special Report: EMTEL Requirements for=20 >communication of citizens with authorities/organizations in=20 >case of distress (emergency call handling) > >[5] TS 24.008 Digital cellular telecommunications system=20 >(Phase2+); Universal Mobile Telecommunicatios System (UMTS);=20 >Mobile radio interface Layer 3 specification; Core network=20 >protocols; [TR 23 867] 3GPP TR 23 867: " Internet Protocol=20 >(IP) based IP Multimedia Subsystem (IMS) emergency sessions;=20 >Release 7". > >=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 Sat Mar 5 19:12:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29991; Sat, 5 Mar 2005 19:12:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7jQ6-0007hG-Sk; Sat, 05 Mar 2005 19:14:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7jMb-0008G2-8z; Sat, 05 Mar 2005 19:11:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7jMa-0008Fx-41 for ecrit@megatron.ietf.org; Sat, 05 Mar 2005 19:11:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29859 for ; Sat, 5 Mar 2005 19:11:12 -0500 (EST) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7jOR-0007eb-Is for ecrit@ietf.org; Sat, 05 Mar 2005 19:13:12 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j260BD65022783 for ; Sun, 6 Mar 2005 01:11:13 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j260BDI6022783 for ; Sun, 6 Mar 2005 01:11:13 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Sun, 6 Mar 2005 01:11:13 +0100 Message-ID: From: Tschofenig Hannes To: "'ecrit@ietf.org'" Date: Sun, 6 Mar 2005 01:09:29 +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: d6b246023072368de71562c0ab503126 Subject: [Ecrit] draft review 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 hi james, hi martin^2, i quickly read through your draft and here are a few high level comments: * reading brian's draft and your draft shows me that there is a different understanding of 'validation'. * the draft raises interestig aspects with regard to security. * it would be interesting to see other people's opinion on the discussed requirements and the additionally provided security properties. although we had a discussion about them already on the mailing list i have included some comments at: http://www.ietf-ecrit.org/comments/draft-winterbottom-ecrit-location-scope-r eq-00-hannes.txt ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Mar 5 19:14:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00077; Sat, 5 Mar 2005 19:14:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7jRi-0007jV-El; Sat, 05 Mar 2005 19:16:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7jPP-0000Dl-64; Sat, 05 Mar 2005 19:14:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7jPN-0000Dg-Mm for ecrit@megatron.ietf.org; Sat, 05 Mar 2005 19:14:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00052 for ; Sat, 5 Mar 2005 19:14:01 -0500 (EST) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7jRA-0007j2-9u for ecrit@ietf.org; Sat, 05 Mar 2005 19:16:00 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j260E2NC000761 for ; Sun, 6 Mar 2005 01:14:02 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j260E2ix023126 for ; Sun, 6 Mar 2005 01:14:02 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Sun, 6 Mar 2005 01:14:02 +0100 Message-ID: From: Tschofenig Hannes To: "'ecrit@ietf.org'" Date: Sun, 6 Mar 2005 01:12:17 +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: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ecrit] draft review 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 hi richard, i quickly read through your draft and here are a few high level comments: * short and focused requirements * thanks for pointing to the p2p aspect * looks good to me; have you compared your requirements with the requirements listed by other drafts? do you see some controversal issues? although we had a discussion about them already on the mailing list i have included some comments at: http://www.ietf-ecrit.org/comments/draft-stastny-ecrit-requirements-00_hanne s.txt ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Mar 5 19:15:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00157; Sat, 5 Mar 2005 19:15:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7jSi-0007kX-He; Sat, 05 Mar 2005 19:17:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7jQE-0000PA-CM; Sat, 05 Mar 2005 19:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7jQC-0000P3-K3 for ecrit@megatron.ietf.org; Sat, 05 Mar 2005 19:15:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00133 for ; Sat, 5 Mar 2005 19:14:57 -0500 (EST) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7jS4-0007kC-97 for ecrit@ietf.org; Sat, 05 Mar 2005 19:16:56 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j260EweR024312 for ; Sun, 6 Mar 2005 01:14:58 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j260EwBA023234 for ; Sun, 6 Mar 2005 01:14:58 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Sun, 6 Mar 2005 01:14:58 +0100 Message-ID: From: Tschofenig Hannes To: "'ecrit@ietf.org'" Date: Sun, 6 Mar 2005 01:13:15 +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: 93238566e09e6e262849b4f805833007 Subject: [Ecrit] draft review 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d hi henning, i quickly read through your draft and here are a few high level comments: * good document with an impressive list of requirements (also addresses security specific requirements) * i wonder whether the other draft authors have read this document. it would be good to know how their requirements relate to the requirements raised in this document. things to improve with this document: * a few sections address topics that are outside the scope of ecrit * terminology needs to be enhanced and fixed * a number of security related requirements have been addressed in the document but the security consideration section requires more work * some people might argue that the language in the document is a bit too sip focused some some very minor comments at : http://www.ietf-ecrit.org/comments/draft-schulzrinne-sipping-emergency-req-0 1_hannes.txt ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Mar 5 19:16:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00222; Sat, 5 Mar 2005 19:16:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7jTV-0007lu-Aa; Sat, 05 Mar 2005 19:18:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7jR0-0000W2-JR; Sat, 05 Mar 2005 19:15:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7jQz-0000Vx-0y for ecrit@megatron.ietf.org; Sat, 05 Mar 2005 19:15:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00162 for ; Sat, 5 Mar 2005 19:15:44 -0500 (EST) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7jSp-0007ke-AO for ecrit@ietf.org; Sat, 05 Mar 2005 19:17:43 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j260Fjfo001927 for ; Sun, 6 Mar 2005 01:15:45 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j260Fj5n023964 for ; Sun, 6 Mar 2005 01:15:45 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Sun, 6 Mar 2005 01:15:45 +0100 Message-ID: From: Tschofenig Hannes To: "'ecrit@ietf.org'" Date: Sun, 6 Mar 2005 01:14: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: ea4ac80f790299f943f0a53be7e1a21a Subject: [Ecrit] draft review 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 hi hideki, hi motoharu, i quickly read through your draft and here are a few high level comments: * thanks for providing us insights into the work in japan with regard to this topic * i had the impression that some parts of the document are focused too much on the pstn system * section 3.4 represents interesting information that has relevance for the geopriv work. it would be good to verify the work done in geopriv and pdif-lo in particular. * have you had a chance to look at the other requirements drafts (and in henning's draft in particular) to see whether your requirements are (at least partially) captured? * in section 1.2 you mention that a final report will be available in march 2005. maybe you can update us on the outcome of the work and the future plans. it would be good to have people from various parts of the world to verify work in the working group. please find some further comments in http://www.ietf-ecrit.org/comments/draft-arai-ecrit-japan-req-00-hannes.txt ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Mar 5 19:17:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00316; Sat, 5 Mar 2005 19:17:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7jUW-0007nZ-Dn; Sat, 05 Mar 2005 19:19:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7jS4-0000cE-34; Sat, 05 Mar 2005 19:16:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7jS3-0000c7-Df for ecrit@megatron.ietf.org; Sat, 05 Mar 2005 19:16:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00260 for ; Sat, 5 Mar 2005 19:16:52 -0500 (EST) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7jTv-0007mW-F1 for ecrit@ietf.org; Sat, 05 Mar 2005 19:18:51 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j260GreF002273 for ; Sun, 6 Mar 2005 01:16:53 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j260Gr9x024194 for ; Sun, 6 Mar 2005 01:16:53 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Sun, 6 Mar 2005 01:16:53 +0100 Message-ID: From: Tschofenig Hannes To: "'ecrit@ietf.org'" Date: Sun, 6 Mar 2005 01:15:09 +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: 79899194edc4f33a41f49410777972f8 Subject: [Ecrit] draft review 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 hi brian, hi nadine, i quickly read through your draft and here are a few high level comments: * interesting background information and a large number of detailed requirements (good!) * some requirements seem to be very specific to nena (which is ok for this document but within ecrit we need to make sure that we also capture the needs of other parts of the world). * with respect to some requirements i am not quite sure i understood them. please find some further comments in http://www.ietf-ecrit.org/comments/draft-rosen-nena-ecrit-requirements-00-ha nnes.txt ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Mar 5 20:26:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04334; Sat, 5 Mar 2005 20:26:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7kZ8-0000gJ-Kj; Sat, 05 Mar 2005 20:28:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7kWJ-0006sz-De; Sat, 05 Mar 2005 20:25:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7kWI-0006su-Gv for ecrit@megatron.ietf.org; Sat, 05 Mar 2005 20:25:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04295 for ; Sat, 5 Mar 2005 20:25:20 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7kYB-0000fp-27 for ecrit@ietf.org; Sat, 05 Mar 2005 20:27:19 -0500 Received: from [127.0.0.1] (IDENT:U2FsdGVkX1+pkpqbzyb+WjOXB8bHTT6i/g55r3MDAkY@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j261PHh3018737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 5 Mar 2005 20:25:18 -0500 (EST) Message-ID: <422A5BF1.9090809@cs.columbia.edu> Date: Sat, 05 Mar 2005 20:25:05 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes Subject: Re: [Ecrit] draft review 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_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Thanks for your comments. Some quick responses below: 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.) [hannes] why is this differentiation necessary? Tschofenig Hannes wrote: > hi henning, > > i quickly read through your draft and here are a few high level comments: > * good document with an impressive list of requirements > (also addresses security specific requirements) > * i wonder whether the other draft authors have read this document. it > would be good to know how their requirements relate to the requirements > raised in this document. > > things to improve with this document: > * a few sections address topics that are outside the scope of ecrit Those will be deleted. > * terminology needs to be enhanced and fixed > * a number of security related requirements have been addressed in the > document but the > security consideration section requires more work > * some people might argue that the language in the document is a bit too > sip focused Well, this started as a SIPPING document... One high-level decision to be made is whether we assume that calls reach PSAPs via SIP, even if after translation. Clearly, some parts will be independent of the signaling protocol, but I don't think there's much point in having PSAPs support some smorgasbord of signaling protocols since that would only work if everybody supported everything. > > some some very minor comments at : > http://www.ietf-ecrit.org/comments/draft-schulzrinne-sipping-emergency-req-0 > 1_hannes.txt > > ciao > hannes > > _______________________________________________ > 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 Sun Mar 6 00:29:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17602; Sun, 6 Mar 2005 00:29:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7oMA-0005L0-0D; Sun, 06 Mar 2005 00:31:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7oJ3-0004OK-8B; Sun, 06 Mar 2005 00:27:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7oIn-0004Nx-0Y for ecrit@megatron.ietf.org; Sun, 06 Mar 2005 00:27:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17532 for ; Sun, 6 Mar 2005 00:27:37 -0500 (EST) Received: from okigate.oki.co.jp ([202.226.91.194] helo=iscan3.intra.oki.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7oKh-0005Im-I8 for ecrit@ietf.org; Sun, 06 Mar 2005 00:29:40 -0500 Received: from s24c3.dm1.oii.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan3.intra.oki.co.jp (8.11.6/8.11.6) with ESMTP id j265ROF15219; Sun, 6 Mar 2005 14:27:24 +0900 Received: from act3377 ([10.4.108.44]) by s24c3.dm1.oii.oki.co.jp (8.11.6/8.11.2) with ESMTP id j265RNO20225; Sun, 6 Mar 2005 14:27:23 +0900 From: =?iso-2022-jp?B?TW90b2hhcnUgS2F3YW5pc2hpLxskQkBuQD5BRz1VGyhC?= To: "'Tschofenig Hannes'" , Subject: RE: [Ecrit] draft review Date: Sun, 6 Mar 2005 14:27:15 +0900 Organization: IPTPC Message-ID: <000001c5220d$28aa0f00$2c6c040a@power.oki.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 1.9 (+) X-Scan-Signature: 386e0819b1192672467565a524848168 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 X-Spam-Score: 1.9 (+) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Hi Hannes, Thank you for your comments. > * i had the impression that some parts of the document are focused > too much on the pstn system You are correct. They are currently in a phase where the aim is securing current PSTN functions in IP network. But their scope includes more broader communication services and I expect that such requirements will be discussed in their future study. > * section 3.4 represents interesting information that has relevance for the geopriv > work. it would be good to verify the work done in geopriv and > pdif-lo in particular. We recognize the work being done in geopriv. However, Japan's current requirements on Section 3.4 is defined for the communication using individual http session and is separated from call control, and therefore I did not submit this draft to geopriv. However it is good to aline the semantics with LO so I will talk to geopriv persons in Minneapolis. > * have you had a chance to look at the other requirements drafts (and in henning's draft > in particular) to see whether your requirements are (at least > partially) captured? We are working on. > * in section 1.2 you mention that a final report will be available in march 2005. > maybe you can update us on the outcome of the work and the future > plans. Yes we continue this work and will update when necessary. By the way at the ecrit session Mr. Hideki Arai instead of myself will make a presentation for the Japan requirement. Thanks for your help. --- Motoharu Kawanishi [Oki IPTPC] kawanishi381@oki.com tel: 03-3454-2111 (ex.37005) -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig Hannes Sent: Sunday, March 06, 2005 9:14 AM To: 'ecrit@ietf.org' Subject: [Ecrit] draft review hi hideki, hi motoharu, i quickly read through your draft and here are a few high level comments: * thanks for providing us insights into the work in japan with regard to this topic * i had the impression that some parts of the document are focused too much on the pstn system * section 3.4 represents interesting information that has relevance for the geopriv work. it would be good to verify the work done in geopriv and pdif-lo in particular. * have you had a chance to look at the other requirements drafts (and in henning's draft in particular) to see whether your requirements are (at least partially) captured? * in section 1.2 you mention that a final report will be available in march 2005. maybe you can update us on the outcome of the work and the future plans. it would be good to have people from various parts of the world to verify work in the working group. please find some further comments in http://www.ietf-ecrit.org/comments/draft-arai-ecrit-japan-req-00-hannes.txt ciao hannes _______________________________________________ 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 Mon Mar 7 07:20:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06242; Mon, 7 Mar 2005 07:20:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8HGG-0001CF-9K; Mon, 07 Mar 2005 07:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8HDA-0003s0-1O; Mon, 07 Mar 2005 07:19:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8HD8-0003rv-Cx for ecrit@megatron.ietf.org; Mon, 07 Mar 2005 07:19:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06091 for ; Mon, 7 Mar 2005 07:19:43 -0500 (EST) Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8HFJ-00019a-LG for ecrit@ietf.org; Mon, 07 Mar 2005 07:22:01 -0500 Received: from rrc-its-ieg01.cc.telcordia.com (rrc-its-ieg01.cc.telcordia.com [128.96.109.78]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j27CIn401384; Mon, 7 Mar 2005 07:18:49 -0500 (EST) Received: from rrc-its-exbh01.mail.saic.com ([128.96.109.61]) by rrc-its-ieg01.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005030707184615941 ; Mon, 07 Mar 2005 07:18:46 -0500 Received: by rrc-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 7 Mar 2005 07:18:46 -0500 Message-ID: From: "Abbott, Nadine B." To: "'Henning Schulzrinne'" , Tschofenig Hannes Subject: RE: [Ecrit] draft review Date: Mon, 7 Mar 2005 07:18:46 -0500 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: b280b4db656c3ca28dd62e5e0b03daa8 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 In addition, in North America, the term "Enhanced" is used to indicate that the emergency call is routed to an appropriate answering point based on the caller's location. Nadine -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Saturday, March 05, 2005 8:25 PM To: Tschofenig Hannes Cc: 'ecrit@ietf.org' Subject: Re: [Ecrit] draft review Thanks for your comments. Some quick responses below: 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.) [hannes] why is this differentiation necessary? Tschofenig Hannes wrote: > hi henning, > > i quickly read through your draft and here are a few high level comments: > * good document with an impressive list of requirements > (also addresses security specific requirements) > * i wonder whether the other draft authors have read this document. > it would be good to know how their requirements relate to the > requirements raised in this document. > > things to improve with this document: > * a few sections address topics that are outside the scope of ecrit Those will be deleted. > * terminology needs to be enhanced and fixed > * a number of security related requirements have been addressed in > the document but the > security consideration section requires more work > * some people might argue that the language in the document is a bit > too sip focused Well, this started as a SIPPING document... One high-level decision to be made is whether we assume that calls reach PSAPs via SIP, even if after translation. Clearly, some parts will be independent of the signaling protocol, but I don't think there's much point in having PSAPs support some smorgasbord of signaling protocols since that would only work if everybody supported everything. > > some some very minor comments at : > http://www.ietf-ecrit.org/comments/draft-schulzrinne-sipping-emergency > -req-0 > 1_hannes.txt > > ciao > hannes > > _______________________________________________ > 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 Mon Mar 7 13:37:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19340; Mon, 7 Mar 2005 13:37:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8N8Q-0002wj-Vs; Mon, 07 Mar 2005 13:39:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8N5a-0007E1-3c; Mon, 07 Mar 2005 13:36:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8M6Q-0000Rz-Sw for ecrit@megatron.ietf.org; Mon, 07 Mar 2005 12:33:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12561 for ; Mon, 7 Mar 2005 12:33:07 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8M8c-0001Fy-Rj for sipping-emergency@ietf.org; Mon, 07 Mar 2005 12:35:29 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 07 Mar 2005 12:48:57 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,143,1107752400"; d="scan'208"; a="39530645:sNHT23503796" 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 j27HWujI000448; Mon, 7 Mar 2005 12:32:57 -0500 (EST) 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); Mon, 7 Mar 2005 12:32:56 -0500 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] ETSI EMTEL Emergency Requirements Date: Mon, 7 Mar 2005 12:32:54 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E37B63@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] ETSI EMTEL Emergency Requirements Thread-Index: AcUg743r/CNnHJooQ2Kq57OHtN92EwACoPjrAASdfjAAAX8WIwCKJNaA From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "James Polk \(jmpolk\)" , "Marc Linsner \(mlinsner\)" , X-OriginalArrivalTime: 07 Mar 2005 17:32:56.0233 (UTC) FILETIME=[B2F46190:01C5233B] X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 07 Mar 2005 13:36:21 -0500 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Content-Transfer-Encoding: quoted-printable Richard, I read the ambiguity differently. I view a black phone connected to a TA as simply an IP endpoint as far as the network is concerned. It just has a funny user interface. The other possibility would be if a black phone goes through a PSTN switch and somehow gets emergency services that are IP based. I didn't think that useful, since the legacy 911 infrastructure will probably be around till the last black phone is retired. That was another interpretation of what you said, but apparently not what you intended. Mike =20 >-----Original Message----- >From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 >Sent: Friday, March 04, 2005 6:40 PM >To: Michael Hammer (mhammer); James Polk (jmpolk); Marc=20 >Linsner (mlinsner); sipping-emergency@ietf.org >Subject: Re: [Ecrit] ETSI EMTEL Emergency Requirements > >Mike, >=20 >First: I am not representing here the TISPAN IMS NGN, I only=20 >wanted that the ecrit audience gets as much as possible a=20 >complete picture of the beasts out there. >=20 >Second: PSTN Emulation in it simplest case is a POTS phone=20 >attached to a terminal adaptor. If the a/b wire is 30 inches=20 >long or two miles does not matter. So if you have a POTS phone=20 >and your telco decides to replace the linecard in a Nortel=20 >switch with a "TA" and a gateway, you would not and should not=20 >notice. This is PSTN Emulation. >=20 >But we both agree that a customer connected to Vonage with a=20 >TA is within scope of ecrit? >=20 >Richard > >________________________________ > >Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >Gesendet: Sa 05.03.2005 00:12 >An: Stastny Richard; James Polk (jmpolk); Marc Linsner=20 >(mlinsner); sipping-emergency@ietf.org >Betreff: RE: [Ecrit] ETSI EMTEL Emergency Requirements > > > >Richard, > >Two points: > >1) I hope that PSTN Emulation as you have described it is=20 >limited to the small set of wireless features that wireless=20 >technologies chose to implement, not the wider set of 400-500=20 >features that wireline PSTN switches implemented. > >2) I thought that ECRIT was focusing on the ability of IP=20 >terminals to access IP-based PSAPs and legacy PSTN E911=20 >service infrastructure, but not necessarily attempting to=20 >define services to be delivered to the legacy PSTN terminals. =20 >After all, those terminals already get the existing PSTN=20 >services, including E911. Is that a migration need? Note=20 >that your definitions do not cover IP access to the legacy=20 >PSAP infrastructure. > >Terminal Service > >PSTN----L---->PSTN L=3Dlegacy > | ^ E=3Demulation > +-----E-----+ | ?=3Dmissing > | | S=3Dsimulation > +------?-------+ > | | > | V >IP------S---->IP > >I prefer priority work on PSTN Simulation, where the IP=20 >terminal gets IP service that is equivalent (not exactly=20 >equal?) to the PSTN service, since I think the all IP solution=20 >could end up cheaper, faster, cleaner (than legacy solution)=20 >to implement than some PSAP people think. Modulo politics =3D=20 >... OK, nevermind. > >Mike > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >>Of Stastny Richard >>Sent: Friday, March 04, 2005 4:00 PM >>To: James Polk (jmpolk); Marc Linsner (mlinsner);=20 >>sipping-emergency@ietf.org >>Subject: Re: [Ecrit] ETSI EMTEL Emergency Requirements >> >>James, >> >>I agree that Section 4.1.3 (and also 4.2) is confusing for=20 >IETF folks,=20 >>(I have to admit that I also do not understand them to full extent),=20 >>but these sections are not talking about ISDN, they are talking about=20 >>PSTN/ISDN Emulation and Simulation Subsystems for NGN. >> >>Both are within the scope of ecrit. >> >>A short (and very vague) tutorial: >>ETSI TISPAN is standardizimg the NGN for fixed networks. >>TISPAN has decided to use as a basis the NGN IMS as standardized by=20 >>3GPP for mobile systems. 3GPP has decided to base the IMS on SIP. >>Since fixed networks are migrating from TDM to IP, even if=20 >they use IP=20 >>in the core, the still wil have (and are obliged to provide)=20 >PSTN/ISDN=20 >>services to existing customers. To be able to do so, they need to=20 >>provide additional subsystems for ISDN/PSTN Enumlation/Simulation. >> >>What is the difference between Emulation and Simulation? >>Here the official definition: >> >>PSTN/ISDN Emulation: Mimicing a PSTN/ISDN network from the point of=20 >>view of a legacy terminal by an IP network, through a gateway. All=20 >>PSTN/ISDN services remain available and identical (i.e. with the same=20 >>ergonomics); such that end users are unaware that they are not=20 >>connected to a TDM-based PSTN/ISDN. >> >>PSTN Simulation: The provision of PSTN/ISDN-like services to advanced=20 >>terminals such as IP-phones. There is no strict requirement=20 >to make all=20 >>PSTN/ ISDN services available or identical, although end users expect=20 >>to have access to the most popular ones, possibly with different=20 >>ergonomics. >> >>So PSTN/ISDN Simulation is pure IP/SIP from the terminal to the PSAP,=20 >>so it is definetely withn the scope of ecrit. >> >>PSTN/ISDN Emulation uses POTS/ISDN Terminals, but is then=20 >converted to=20 >>IP at a gateway on from this point to the PSAP is is also=20 >pure IP/SIP.=20 >>This means it also within the scope of ecrit. >> >>Richard >> >>PS: the references I left out: >> >>[1] Directive 2002/21/EC on a common regulatory framework for=20 >>electronic communications and services (the "Framework=20 >Directive"), and=20 >>in particular Article 19 >> >>[2] Directive 2002/22/EC on universal service and users rights=20 >>relating to electronic communications networks and services (the=20 >>"Universal Service Directive") >> >>[3] Directive 2002/58/EC on a concerning the processing of >>personal data and the >>protection of privacy in the electronic communications sector (the=20 >>"Directive on privacy and electronic communications") >> >> [4] SR 002 180 ETSI Special Report: EMTEL Requirements for=20 >>communication of citizens with authorities/organizations in case of=20 >>distress (emergency call handling) >> >>[5] TS 24.008 Digital cellular telecommunications system (Phase2+);=20 >>Universal Mobile Telecommunicatios System (UMTS); Mobile radio=20 >>interface Layer 3 specification; Core network protocols; [TR 23 867] =20 >>3GPP TR 23 867: " Internet Protocol >>(IP) based IP Multimedia Subsystem (IMS) emergency sessions; Release=20 >>7". >> >> >> >> >> >>_______________________________________________ >>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 Mar 8 12:37:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23472; Tue, 8 Mar 2005 12:37:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8igM-0002hi-NX; Tue, 08 Mar 2005 12:39:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8iZu-0006n3-Re; Tue, 08 Mar 2005 12:33:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8iZs-0006mx-Uq for ecrit@megatron.ietf.org; Tue, 08 Mar 2005 12:33:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22400 for ; Tue, 8 Mar 2005 12:33:01 -0500 (EST) Received: from mail.easycgi.com ([66.245.177.160] helo=easycgi.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8ibz-0002Vh-CP for ecrit@ietf.org; Tue, 08 Mar 2005 12:35:35 -0500 Received: from [68.57.138.9] (account marks@maximtsc.com) by easycgi.com (CommuniGate Pro WebUser 4.2.3) with HTTP id 40689007 for ecrit@ietf.org; Tue, 08 Mar 2005 12:34:44 -0500 From: "Mark Scharaga" To: ecrit@ietf.org X-Mailer: CommuniGate Pro WebUser Interface v.4.2.3 Date: Tue, 08 Mar 2005 12:34:44 -0500 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 8bit Subject: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 7 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 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 8bit >I prefer priority work on PSTN Simulation, where the IP >terminal gets IP service that is equivalent (not exactly >equal?) to the PSTN service, since I think the all IP solution could end up cheaper, faster, cleaner (than legacy solution) to implement than some PSAP people think. Modulo politics = ... OK, nevermind. >Mike I agree with this completely. The main PSAP issue is funding IP technologies. But that is another issue for another committee. Mark Scharaga President- Maxim Technology Solutions www.maximtsc.com 888-288-3059 X101 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 8 14:08:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02840; Tue, 8 Mar 2005 14:08:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8k6G-0004q2-E1; Tue, 08 Mar 2005 14:10:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8jwL-0006rQ-2n; Tue, 08 Mar 2005 14:00:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8jwK-0006rL-LF for ecrit@megatron.ietf.org; Tue, 08 Mar 2005 14:00:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02200 for ; Tue, 8 Mar 2005 14:00:19 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8jyl-0004g5-7M for ecrit@ietf.org; Tue, 08 Mar 2005 14:02:52 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 08 Mar 2005 11:03:34 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,147,1107763200"; d="scan'208,217"; a="165839287:sNHT49414984" Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j28J05YO012430 for ; Tue, 8 Mar 2005 11:00:06 -0800 (PST) Received: from MLINSNER (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA22387 for ; Tue, 8 Mar 2005 11:00:05 -0800 (PST) Message-Id: <200503081900.LAA22387@malone.cisco.com> From: "Marc Linsner" To: Date: Tue, 8 Mar 2005 13:59:56 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Thread-Index: AcUkEQN9Aj6DQBtPTtGNFXel6Wn5Bg== X-Spam-Score: 1.2 (+) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Subject: [Ecrit] No more sipping-emergency list 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="===============1112926020==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 This is a multi-part message in MIME format. --===============1112926020== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A5_01C523E7.1C795B60" This is a multi-part message in MIME format. ------=_NextPart_000_00A5_01C523E7.1C795B60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We've now got the ecrit list up and running, so please use ecrit@ietf.org and don't use sipping-emergency. Everyone on the old list should be on the new one, or at least that was the plan. If you find something broken, please advise Hannes or myself. Thanks, -Marc Linsner- co-chair ecrit ------=_NextPart_000_00A5_01C523E7.1C795B60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We’ve now got the ecrit list up and running, so = please use ecrit@ietf.org and don’t = use sipping-emergency.  Everyone on the old list should be on the new = one, or at least that was the plan.

 

If you find something broken, please advise Hannes or myself.

 

Thanks,

 

-Marc Linsner-

co-chair ecrit

------=_NextPart_000_00A5_01C523E7.1C795B60-- --===============1112926020== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1112926020==-- From ecrit-bounces@ietf.org Tue Mar 8 16:37:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22566; Tue, 8 Mar 2005 16:37:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mQd-0001mo-CI; Tue, 08 Mar 2005 16:39:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mLo-0001LF-PB; Tue, 08 Mar 2005 16:34:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mBt-0008RR-6T for ecrit@megatron.ietf.org; Tue, 08 Mar 2005 16:24:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21293 for ; Tue, 8 Mar 2005 16:24:30 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mEK-0001Tq-Nw for ecrit@ietf.org; Tue, 08 Mar 2005 16:27:06 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.4) with ESMTP id for ; Tue, 8 Mar 2005 16:24:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Mar 2005 13:24:16 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657501E3C302@SEA-EXCHVS-2.telecomsys.com> Thread-Index: AcUkJS7lhPTUctnxTpik00CuisPfPQ== From: "Roger Marshall" To: X-Spam-Score: 0.7 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Tue, 08 Mar 2005 16:34:46 -0500 Subject: [Ecrit] (no subject) 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="===============0254277865==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 This is a multi-part message in MIME format. --===============0254277865== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52425.2F992024" This is a multi-part message in MIME format. ------_=_NextPart_001_01C52425.2F992024 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable subscribe ------_=_NextPart_001_01C52425.2F992024 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

subscribe

------_=_NextPart_001_01C52425.2F992024-- --===============0254277865== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0254277865==-- From ecrit-bounces@ietf.org Tue Mar 8 16:37:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22606; Tue, 8 Mar 2005 16:37:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mR7-0001nd-H1; Tue, 08 Mar 2005 16:40:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mLo-0001LK-Uw; Tue, 08 Mar 2005 16:34:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mCi-0008UW-Lg for ecrit@megatron.ietf.org; Tue, 08 Mar 2005 16:25:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21363 for ; Tue, 8 Mar 2005 16:25:22 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mFA-0001VD-In for ecrit@ietf.org; Tue, 08 Mar 2005 16:27:57 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.4) with ESMTP id for ; Tue, 8 Mar 2005 16:25:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Mar 2005 13:25:12 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657501E3C305@SEA-EXCHVS-2.telecomsys.com> Thread-Index: AcUkJVBAFxEvN+2aQFuOQm2NKZfGPw== From: "Roger Marshall" To: X-Spam-Score: 0.7 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Tue, 08 Mar 2005 16:34:46 -0500 Subject: [Ecrit] (no subject) 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="===============1242300636==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 This is a multi-part message in MIME format. --===============1242300636== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52425.50B9F21F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C52425.50B9F21F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable subscribe ------_=_NextPart_001_01C52425.50B9F21F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

subscribe

------_=_NextPart_001_01C52425.50B9F21F-- --===============1242300636== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1242300636==-- From ecrit-bounces@ietf.org Wed Mar 9 00:36:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29917; Wed, 9 Mar 2005 00:36:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8tuB-0002eb-9C; Wed, 09 Mar 2005 00:38:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8tqB-0006FS-Bo; Wed, 09 Mar 2005 00:34:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8tq9-0006FJ-3d for ecrit@megatron.ietf.org; Wed, 09 Mar 2005 00:34:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29721 for ; Wed, 9 Mar 2005 00:34:33 -0500 (EST) 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.33) id 1D8tsg-0002bU-5W for ecrit@ietf.org; Wed, 09 Mar 2005 00:37:14 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2005 21:48:42 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j295YYuC010238 for ; Tue, 8 Mar 2005 21:34:34 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id VAA13212 for ; Tue, 8 Mar 2005 21:34:27 -0800 (PST) Message-Id: <4.3.2.7.2.20050308222121.025827e8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Mar 2005 22:45:27 -0600 To: "'ecrit@ietf.org'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.2 (++) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: [Ecrit] draft-stastny-ecrit-requirements-00 review 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 X-Spam-Score: 2.2 (++) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Richard I have a few comments about certain requirements within your ID: M2. The possibility to make contact to the proper ECC has to be verified and indicated to the user and/or the User Agent. Any indication (tone, flashing light, display icon visible) will be gradually ignored by most humans soon after becoming available to them. Thus, this requirement doesn't really accomplish much. Technically, how does the UA (the phone) know which PSAP/ECC is the "right" PSAP/ECC? For example, I live outside of Fort Worth, Texas - when I power my phone back up when I land in a lovely place such as Minneapolis, how does my phone contact and then know it contacted the Minneapolis PSAP/ECC without a PSAP Certificate authority and my UA having access to verify the key sent back in the reply was the Minneapolis PSAP/ECC and not my home Fort Worth PSAP/ECC? This seems like a great impersonation attack opportunity waiting to happen, while providing a true false sense of security to the UA owner. M3. The communication may be established on user request or by external events. External events.... smoke signals? seriously, what do you mean by "external events"? M4. To achieve this, the device MUST be able to retrieve its current location from the access provider, from the infrastructure, via GPS, ... or as last resort, from the user itself. I think the user will have quite a say in whether they are indeed a "last resort". With residential services, it will be often that the user will type in their home address and have that be their PIDF-LO civic address used from any phone in that home. M5. The capability to locate the responsible ECC must be available in the public Infrastructure without the additional need for a service provider. this means the IP address of each and every PSAP/ECC in the world is public knowledge. Is this really desired? M6. For a transient time the device and the UA may use the help of servers (e.g. ESRP) to provide the connectivity to ECC, especially for ECC not yet connected to the Internet. what's a transient time to you? What's an ESRP? you didn't explode the acronym in a terms and definitions section. Why would a UA care how its message got routed as long as it got routed to a PSAP/ECC? S1. Transmission of the current location of the contacting device to the ECC Why is this a SHOULD? Isn't this a MUST to do any routing? And if location from the INVITE is used to route the call, and Proxies are not don't delete message bodies, then why wouldn't it be logical to conclude that if the PSAP/ECC received the message, it also received the Location of the UA? S3. Identification of the contacting person or device If my AOR is jp3520@yahoo.com with no display name, then the PSAP/ECC isn't going to get any more than that. But I guess this is why it's a SHOULD... S4. Safeguards to protect the emergency infrastructure and ECC facilities against malicious attacks, especially to prevent DoS attacks. I don't believe this is in scope of the WG or the IETF, so this requirement should be removed S5. Provide all possible means of communication, not only speech, but also text (IM), Video, etc., (for disabled persons and better display of the situation) I don't believe this is in scope of the WG or the IETF, so this requirement should be removed S6. Capabilities to contact ECC by automatic means and for the transfer of additional information (alarm equipment, cars, buses, trucks with dangerous loads, ...) I don't believe this is in scope of the WG or the IETF, so this requirement should be removed 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 Wed Mar 9 00:38:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00066; Wed, 9 Mar 2005 00:38:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8twW-0002hA-Vj; Wed, 09 Mar 2005 00:41:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8tqW-0006Fy-O6; Wed, 09 Mar 2005 00:35:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8tqU-0006Fm-D0 for ecrit@megatron.ietf.org; Wed, 09 Mar 2005 00:34:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29780 for ; Wed, 9 Mar 2005 00:34:55 -0500 (EST) 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.33) id 1D8tt1-0002bz-HC for ecrit@ietf.org; Wed, 09 Mar 2005 00:37:35 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2005 21:48:55 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j295YlZV029984 for ; Tue, 8 Mar 2005 21:34:47 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id VAA13447 for ; Tue, 8 Mar 2005 21:34:39 -0800 (PST) Message-Id: <4.3.2.7.2.20050308224930.03474110@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Mar 2005 23:33:41 -0600 To: "'ecrit@ietf.org'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: [Ecrit] draft-winterbottom-ecrit-location-scope-req-00 review 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 X-Spam-Score: 1.1 (+) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 James I have a few comments regarding your ID: In the abstract: "An example of such a service is the emergency services network, where the location of a caller is known with in the domain of the telephone network, while the name or true identity of the caller is not intrinsically known." In not sure I understand the relevance of "...within the domain of the telephone network..." as we're talking about VoIP in which there cannot be an assumed provider, therefore no assumed domain (much less telephone based). Additionally, what's the significance of you statement that the location of the phone is known but the user isn't? That's true in the PSTN today, so it isn't special here. In the Introduction: "In the interests of continuous improvement, it is desirable that incidences of erroneous location information being provided can be traced back to an answerable access provider and corrected. " This seems to be the main thrust of your introduction, and I do not believe it is chartered by ECRIT to be addressed, however valuable this is. in section 2 "Terminology", you define domain as a service. At my home, I have a telephone service from SBC over my landline. I have VoIP access through Comcast (by BB over HFC Cable provider) and SBC (via DSL) - both of which I connect to Cisco's internal network over a VPN for telephony connectivity inside Cisco's corporate network. I have cellular service through AT&T Wireless (which is merging with SBC). My wife has cellular service from Verizon. All this is at the same legal and postal address. Is this the same jurisdiction as you define a domain? If this is not clear to everyone, perhaps there is a need to modify the definition of domain to an "administrative domain", generally meaning within a specific provider or federation of providers. "Domain Authentication and Validation Entity" doesn't need to be defined because it is not within the scope of the ECRIT WG or the IETF. This WG will route a message based on the location provided. The message doesn't have the ability to reliably indicate a location is "validated" - without a global PKI and a global Certificate Authority for all PSAPs and ECCs with the root key installed in every multimedia device that could communicate with a PSAP or ECC. 3.1 "A certain level of authentication and validation around the source of the location is required for the domain in which the information is to be used." I don't believe this is within the charter of ECRIT, and therefore should be removed from work being considered in this WG. 3.2"...the location used for routing and which is reported to the emergency services operator, must be the actual location of the caller at the time of making the call." I don't know how it is possible for the system to convey the "right" location the caller, although this is the goal always, because in IP, there cannot be a physical location dependency of the end-system ubiquitously. 3.3 "... The location information MUST be attributed to a specific End-User." If I use your cellphone to call 911, will I be in violation of this requirement (aside from the fact that your cellphone isn't IP based yet)? If I can make such a call in the future, this requirement is unachievable, and should be modified or removed. 3.4 "it must be possible for an End-User to discover and utilize an answerable source of location in the access network they are using." how can this be accomplished without the user entering a trusted token the PSAP/ECC will identify itself with during a 911 call? This breaks for mobility and nomadic endsystems, which IP devices must all be considered here (because they can be moved and still access the same services). Requirements 5, 6 all seem to invalidate the use of DHCP and GPS and manual entry. Requirements 6, 7 - "certified location" - does that mean integrity protected, cryptographically signed location? Req 8 (end-users may not be able to get location) seems to contradict Req 5 (end-users must be able to get location) 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 Wed Mar 9 00:39:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00105; Wed, 9 Mar 2005 00:39:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8tx3-0002hf-0s; Wed, 09 Mar 2005 00:41:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8tq9-0006FI-3n; Wed, 09 Mar 2005 00:34:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8tq7-0006FD-M0 for ecrit@megatron.ietf.org; Wed, 09 Mar 2005 00:34:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29718 for ; Wed, 9 Mar 2005 00:34:32 -0500 (EST) 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.33) id 1D8tse-0002bU-Fj for ecrit@ietf.org; Wed, 09 Mar 2005 00:37:13 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2005 21:48:32 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j295YOuC010187 for ; Tue, 8 Mar 2005 21:34:24 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id VAA13114 for ; Tue, 8 Mar 2005 21:34:22 -0800 (PST) Message-Id: <4.3.2.7.2.20050308221933.0281e998@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Mar 2005 22:19:56 -0600 To: "'ecrit@ietf.org'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.1 (+) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] draft-rosen-nena-ecrit-requirements-00 Review 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 X-Spam-Score: 1.1 (+) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Content-Transfer-Encoding: quoted-printable Brian/Nadine In reviewing your ID, I was impressed with the North American=20 history/background on 911. A few comments about the scope and appropriateness of certain requirements= =20 in the ID: Req 3.1-1 "Tracking and Tracing Facilities for all calls must be provided." I don't understand how you're defining "Tracking" and "Tracing" and=20 "Facilities"; plus I don't know who any of this is to be provided to? "Tracking" is defined using the following: #1 - To follow the tracks of... #2 - To move over or along... #3 - To observe or monitor the course of... #4 - To observe the progress of... "Tracing" is defined using the following: #1 - A path or trail that has been beaten out by the passage of animals or= =20 people #2 - To locate or discover by searching or researching evidence #3 - To draw (a line or figure) #4 - To follow the course or trail of... so, you want a requirement that follows or moves or observes the path of or= =20 discovers by searching one or more "facilities". I'm confused. Please help.= =20 Especially with your next line: "This include all routing entities as well as all signaling entities." By "Routing entities" I assume you mean packet routers (L3 Routers)? By "signaling entities" I assume you mean packet directors (like SIP= Proxies)? Req 3.1-2 "Each element in the signaling and routing paths solution shall=20 maintain call detail records that can be accessed by mgmt systems to=20 develop call statistics in real time." From this I assume you saying all SIP Proxies have to be dialog stateful=20 *and* have an open TCP socket to communication mgmt information to some=20 centralized server. Do you think that a Cisco, a Boeing or a Ford Motor=20 company IT department is going to open up this pinhole from their servers=20 to a local safety authority "in real time" no less? Real time in voice is 50 packets a second. Do you need this level of=20 communicate to CDR records from *every* server? BTW - what's the definition of an "element"? Is it limited to a SIP (or=20 v/v/im based) element, or does this include access to a CLI or network mgmt= =20 platform of all routers the packet happened to traverse? Req 3.1-5 define what a congestion control is. Is it at layer 1,2,3,5=20 and/or 7? In signaling or media packets? Layer 7 congestion controls can be= =20 done with redirects and automated session forwards, but at layer 3 you'll=20 probably run into some problems without an interface being down. Req 3.1-7 - what's an MSC? You don't have an acronym section in this doc=20 prior to this acronym. And, this req isn't an IETF issue other than to specify that a GW of=20 whatever type converts an inbound call set-up to the appropriate signaling= =20 protocol to meet the other requirements. So this req should be removed. Req 3.1-8 talks about peak load call set-up time and the use of CAMA=20 circuits. Are you considering the peak load of every signaling element in=20 the path all at once or individually? Specifying anything about CAMA=20 circuits is out of scope. Req 3.2-5 how does a UA determine which LO it transmits is the most=20 accurate? Doesn't it take whatever is currently available as is and=20 transmit it? Req 3.2-8 and 3.2-9 Please define what "default location" is. A UA likely=20 has *a* location. How can that be determined to be default or not by the UA? Req 3.3-1 Is (or can) this call back URI a AOR, a GRUU or a tel:uri? And if= =20 it is one of these, what do you want done with it (i.e. any special= handling)? Req 3.4.1 This doesn't have anything to do with identification of an=20 emergency call or the routing of that call, therefore this is out of scope= =20 of this WG. Req 3.4-2 This doesn't have anything to do with identification of an=20 emergency call or the routing of that call, therefore this is out of scope= =20 of this WG. Req 3.4-3 This doesn't have anything to do with identification of an=20 emergency call or the routing of that call, therefore this is out of scope= =20 of this WG. Req 3.4-4 This doesn't have anything to do with identification of an=20 emergency call or the routing of that call, therefore this is out of scope= =20 of this WG. Req 3.4-5 This doesn't have anything to do with identification of an=20 emergency call or the routing of that call, therefore this is out of scope= =20 of this WG. Req 3.4-6 This doesn't have anything to do with identification of an=20 emergency call or the routing of that call, therefore this is out of scope= =20 of this WG. Req 3.4-7 This doesn't have anything to do with identification of an=20 emergency call or the routing of that call, therefore this is out of scope= =20 of this WG. Section 3.5 "Validation of Civic Location" This doesn't have anything to do= =20 with identification of an emergency call or the routing of that call,=20 therefore this is out of scope of this WG. This is good information to=20 determine, but it has no place here. Req 3.6-2 and 3.6-3 should be combined, as one if the follow-on of the= other. Req 3.6-4 "It must be possible for a designated 9-1-1 authority for a PSAP= =20 to approve of any geo-coding database used to assist in determining routing= =20 of calls to that PSAP." An authority validating a database? This is out of scope of this WG. Req 3.6-5 "It must be possible for the designated 9-1-1 authority to=20 supply, maintain, or approve of databases used for civic routing. " An authority supplying a database? maintaining a database? approving a=20 database? This is out of scope of this WG. BTW - what's the difference between an authority validating a database and= =20 approving a database? These are in 2 consecutive requirements. Req 3.6-6 'conversion of geo formats' is out of scope of this WG Req 3.6-9 doesn't make sense. Each element is going to use what needs. Req 3.6.11 assumes the UA has the key only. This doesn't seem like it will= =20 create interoperability (having two routing systems), it seems like this=20 will create interoperability problems (where one element uses one method=20 and another uses the other). 3.6-13: "It must be possible for a given PSAP to decide where its calls=20 should be routed." Where is this done, in DNS? or is this req referring to= =20 the PSAP having the ability to do with the inbound call what it wants (when= =20 it arrives)? I'm getting tired is seeing references to "req ?". Do I the read have to=20 figure this out? Also, there are a lot of Bill-characters. That needs to be fixed. 3.6-15: "Routing as specified in Req ? may change on short notice due to=20 local conditions, traffic, failures, schedule, etc." This isn't a=20 requirement, so it should be removed. 3.6-17: "Routing information must be secured against unauthorized=20 modification." Is this req referring to the routing database? Is that an IP= =20 problem? If not, this is out of scope for this WG and should be removed. Req 3.6-18 through 6-201 talk about "contingency routing". Adding more than= =20 one URI destination for a PSAP, and then complicating that with a different= =20 URI per failure scenario within a proxy is making the Proxy's routing=20 database (per proxy, that is) fairly complicated; perhaps unnecessarily so.= =20 I'm wondering how this can be maintain "only by higher level civic=20 authorities" from Req 3.6-14 and expect to scale and be true all the time=20 (3600x24x7)? 3.6-21: "A procedure must be specified to handle =F4default route=F6= capability=20 when no location is available or the location information is corrupted."=20 How exactly does my UA (which just called 911) know what its default route= =20 is? Or for that matter, how does a proxy know how to route the call is the= =20 location data has been corrupted? The UA doesn't do anything other than=20 indicate the session is an emergency call (with sos@ perhaps) and include a= =20 PIDF-LO. The UA doesn't do anything else except wait for the 200 OK (best=20 case), right? 3.6-22: "Location available at the time the call is routed may not be=20 accurate. Updates to location may result in a different route and the=20 system must accommodate this." I don't know how a system can determine if a location is or is not=20 accurate, so this req should be removed. Further, the INVITE will be routed= =20 how the routing database says it should be routed, regardless of how long=20 ago the database was updated. 3.6-24: "Access Infrastructure providers must provide a location object=20 that is as accurate as possible when location measurement or lookup=20 mechanisms fail." This is calling for "adding a (location) message body to a message", and is= =20 illegal in SIP at this time. 3.6-25: "Entities routing emergency calls shall retain information used to= =20 choose a route for subsequent error resolution." Is this asking that=20 Proxies be transaction or dialog stateful? Req 3.7-1 If there is connectivity and a path, why wouldn't the message be= =20 routed appropriately? This req should be removed. Req 3.8-1 "There shall be no single point of failure" this is unattainable,= =20 therefore it should be removed 3.8-2: "Each subsystem in the i3 solution shall be designed such that the=20 system survives major disruption including disaster, deliberate attack, and= =20 massive element failure." This is an architectural requirement, which is not per of the charter of=20 this WG, therefore this req should be removed. 3.8-3: "Special consideration should be given to =F4Distributed Denial of=20 Service=F6 attacks" This is an architectural requirement, which is not per of the charter of=20 this WG, therefore this req should be removed. 3.8-5: "Mechanisms must be provided to provide constant verification of=20 service availability to the PSAP." Meaning my phone has to maintain TCP connectivity to a PSAP at all times?=20 Is this expected to scale? And, is this expected to matter to Joe Citizen? 3.8-6: "Mechansism must be provided to provide automatically generated=20 misroute and location error reports." From where to where? 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 Wed Mar 9 01:12:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03569; Wed, 9 Mar 2005 01:12:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8uT7-0003h8-Lb; Wed, 09 Mar 2005 01:14:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8uNa-00015p-Pu; Wed, 09 Mar 2005 01:09:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8uNZ-00015h-Qk for ecrit@megatron.ietf.org; Wed, 09 Mar 2005 01:09:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02994 for ; Wed, 9 Mar 2005 01:09:06 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D8uQ4-0003Vl-56 for ecrit@ietf.org; Wed, 09 Mar 2005 01:11:44 -0500 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] draft-stastny-ecrit-requirements-00 review Date: Wed, 9 Mar 2005 07:11:21 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D46FC05@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] draft-stastny-ecrit-requirements-00 review Thread-Index: AcUkanjIwpgQ+GdEQ8ilMKm5M9RGigAAXLAL From: "Stastny Richard" To: "James M. Polk" , X-Spam-Score: 1.1 (+) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb 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 X-Spam-Score: 1.1 (+) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Content-Transfer-Encoding: quoted-printable James wrote: >I have a few comments about certain requirements within your ID: =20 a few? ;-) > M2. The possibility to make contact to the proper ECC has to be > verified and indicated to the user and/or the User Agent. >Any indication (tone, flashing light, display icon visible) will be >gradually ignored by most humans soon after becoming available to them. >Thus, this requirement doesn't really accomplish much. =20 That people may ignore things is IMHO outside the scope of the WG Nevertheless i think the indication is required >Technically, how does the UA (the phone) know which PSAP/ECC is the = "right" >PSAP/ECC? >For example, I live outside of Fort Worth, Texas - when I power my = phone >back up when I land in a lovely place such as Minneapolis, how does my >phone contact and then know it contacted the Minneapolis PSAP/ECC = without a >PSAP Certificate authority and my UA having access to verify the key = sent >back in the reply was the Minneapolis PSAP/ECC and not my home Fort = Worth >PSAP/ECC? >This seems like a great impersonation attack opportunity waiting to = happen, >while providing a true false sense of security to the UA owner. =20 Good question, but I am doing requirements here and not solutions > M3. The communication may be established on user request or by > external events. >External events.... smoke signals? seriously, what do you mean by = "external >events"? =20 e.g. an exploding airbag But Hannes already proposed to remove this as out of scope > M4. To achieve this, the device MUST be able to retrieve its = current > location from the access provider, from the infrastructure, = via > GPS, ... or as last resort, from the user itself. I think the user will have quite a say in whether they are indeed a = "last resort". With residential services, it will be often that the user will type in their home address and have that be their PIDF-LO civic address used from any phone in that home. =20 No, especially with resitential devices the location must come from the=20 infrastructure. Since humans are very unreliable, especially on the road they are only a last resort > M5. The capability to locate the responsible ECC must be available > in the public Infrastructure without the additional need for a > service provider. >this means the IP address of each and every PSAP/ECC in the world is = public >knowledge. Is this really desired? =20 Where is the problem here? > M6. For a transient time the device and the UA may use the help of > servers (e.g. ESRP) to provide the connectivity to ECC, > especially for ECC not yet connected to the Internet. >what's a transient time to you? When the last PSAP is reachable directly via the Internet >What's an ESRP? you didn't explode the acronym in a terms and = definitions >section. =20 Sorry for this , this is from Hennings drafts and I assumed it is common = knowlegde Emergency Service Routing Proxy >Why would a UA care how its message got routed as long as it got routed = to >a PSAP/ECC? =20 It does not care whether it is routed dirrect to a PSAP or via an ESRP > S1. Transmission of the current location of the contacting device = to > the ECC >Why is this a SHOULD? Isn't this a MUST to do any routing? And if = location >from the INVITE is used to route the call, and Proxies are not don't = delete >message bodies, then why wouldn't it be logical to conclude that if the >PSAP/ECC received the message, it also received the Location of the UA? =20 I am not talking here about routing. Routing is already done and you may = route the call to the correct proxy direct from the device to the PSAP without = diclosing=20 your location be evaluation the route at the device. =20 I am talking here if=20 1 you have your location (the location required fro routing may not be as exact as the one needed for dispathing - you may route to = a national emergency center per default. =20 2. you do not want to diclose your location Some countries may allow you to do so, some won't. =20 3. You may nor have a location at all, but you still are able to make an emergency call. > S3. Identification of the contacting person or device >If my AOR is jp3520@yahoo.com with no display name, then the PSAP/ECC = isn't >going to get any more than that. But I guess this is why it's a = SHOULD... =20 exactly > S4. Safeguards to protect the emergency infrastructure and ECC > facilities against malicious attacks, especially to prevent = DoS > attacks. >I don't believe this is in scope of the WG or the IETF, so this = requirement >should be removed =20 Some, e.g. Hannes thinks otherwise I personally was not sure =20 I did this input basically to be able to decide on a high level what is = within the scope, and what is must and should. =20 Before the WG goes into detail, this should be made transparent. and rough consensus reached So bring this up tomorrow =20 > S5. Provide all possible means of communication, not only speech, > but also text (IM), Video, etc., (for disabled persons and > better display of the situation) >I don't believe this is in scope of the WG or the IETF, so this = requirement >should be removed =20 Same as above > S6. Capabilities to contact ECC by automatic means and for the > transfer of additional information (alarm equipment, cars, > buses, trucks with dangerous loads, ...) >I don't believe this is in scope of the WG or the IETF, so this = requirement >should be removed =20 Automatic emergency calls is a big project in Europe within the EC. =20 But again, see above Richard >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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 9 10:45:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17513; Wed, 9 Mar 2005 10:45:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D93Q3-0002oQ-41; Wed, 09 Mar 2005 10:48:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D93Lh-0000lr-TB; Wed, 09 Mar 2005 10:43:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D93Lf-0000lm-Po for ecrit@megatron.ietf.org; Wed, 09 Mar 2005 10:43:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17382 for ; Wed, 9 Mar 2005 10:43:45 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D93OG-0002lj-Vk for ecrit@ietf.org; Wed, 09 Mar 2005 10:46:30 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j29FXPvn009796 for ; Wed, 9 Mar 2005 10:33:25 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j29FXNvn009765 for ; Wed, 9 Mar 2005 10:33:24 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Mar 2005 17:42:50 +0200 Message-ID: Thread-Topic: airport 802.11 example Thread-index: AcUkvpRS+rHqEB0DTOeR55uwr/WRaQ== From: "Romascanu, Dan \(Dan\)" To: X-Spam-Score: 0.5 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [Ecrit] airport 802.11 example 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="===============0587392287==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 This is a multi-part message in MIME format. --===============0587392287== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C524BE.A6454FEB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C524BE.A6454FEB Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Just wanted to mention that the example that James gave with location = determination in a multiple 802.11 AP environments is solved by using = LLDP-MED. In roaming situations, at registration of a mobile IP phone = with a new AP the LLDP-MED location TLV will transfer the new location = info from the AP to the IP phone. The reason the 802.11 folks may have = not mentioned the solution is that LLDP-MED is higher than the MAC layer = (their scope) but yet below the IP layer.=20 Still, the requirements document has an important role in translating = the regulatory requirements for accuracy and timing into component = requirements for ecrit. =20 Regards, Dan ------_=_NextPart_001_01C524BE.A6454FEB Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable airport 802.11 example

Just wanted to mention that = the example that James gave with location determination in a multiple = 802.11 AP environments is solved by using LLDP-MED.  In roaming = situations, at registration of a mobile IP phone with a new AP the = LLDP-MED location TLV will transfer the new location info from the AP to = the IP phone. The reason the 802.11 folks may have not mentioned the = solution is that LLDP-MED is higher than the MAC layer (their scope) but = yet below the IP layer.

Still, the requirements = document has an important role in translating the regulatory = requirements for accuracy and timing into component requirements for = ecrit. 

Regards,

Dan

------_=_NextPart_001_01C524BE.A6454FEB-- --===============0587392287== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0587392287==-- From ecrit-bounces@ietf.org Wed Mar 9 11:14:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20283; Wed, 9 Mar 2005 11:14:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D93s6-0003Vo-Vv; Wed, 09 Mar 2005 11:17:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D93ou-0004DT-SE; Wed, 09 Mar 2005 11:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D93or-0004DE-Hm for ecrit@megatron.ietf.org; Wed, 09 Mar 2005 11:13:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20202 for ; Wed, 9 Mar 2005 11:13:54 -0500 (EST) Message-Id: <200503091613.LAA20202@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D93rQ-0003U7-VZ for ecrit@ietf.org; Wed, 09 Mar 2005 11:16:39 -0500 Received: from wireless-130-129-132-22.ietf62.ietf.org ([130.129.132.22] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1D93oX-00009g-Je; Wed, 09 Mar 2005 10:13:37 -0600 From: "Brian Rosen" To: "'James M. Polk'" , Subject: RE: [Ecrit] draft-rosen-nena-ecrit-requirements-00 Review Date: Wed, 9 Mar 2005 11:13:33 -0500 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.2180 Thread-Index: AcUkak74k0EKd90sQ0is/PG4658zYQAQWCAQ In-Reply-To: <4.3.2.7.2.20050308221933.0281e998@localhost> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: c40ff0c70161549dbde2f89c7946385a 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 X-Spam-Score: 0.8 (/) X-Scan-Signature: 1e47b908cbd1247f22e7953a41f1c4c6 Content-Transfer-Encoding: quoted-printable Thanks for all the comments James. Comments inline > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of > James M. Polk > Sent: Tuesday, March 08, 2005 11:20 PM > To: 'ecrit@ietf.org' > Subject: [Ecrit] draft-rosen-nena-ecrit-requirements-00 Review >=20 > Brian/Nadine >=20 > In reviewing your ID, I was impressed with the North American > history/background on 911. >=20 > A few comments about the scope and appropriateness of certain = requirements > in the ID: >=20 > Req 3.1-1 "Tracking and Tracing Facilities for all calls must be > provided." > I don't understand how you're defining "Tracking" and "Tracing" and > "Facilities"; plus I don't know who any of this is to be provided to? >=20 ....snip... It means that you need to know what elements the call traversed, and you need to know what they did with them. It needs to go with the call, so = that if something goes wrong, the PSAP can call on the right parties to = figure out what happened and how to fix it. Part of this could be something like SIP Via headers. Part of this could be the History header. >=20 > By "Routing entities" I assume you mean packet routers (L3 Routers)? No, we mean call routing entities. They may or may not be in the call signaling path. > By "signaling entities" I assume you mean packet directors (like SIP > Proxies)? Yes >=20 > Req 3.1-2 "Each element in the signaling and routing paths solution = shall > maintain call detail records that can be accessed by mgmt systems to > develop call statistics in real time." >=20 > From this I assume you saying all SIP Proxies have to be dialog = stateful > *and* have an open TCP socket to communication mgmt information to = some > centralized server. Do you think that a Cisco, a Boeing or a Ford = Motor > company IT department is going to open up this pinhole from their = servers > to a local safety authority "in real time" no less? It isn't necessary to be dialog stateful, since you have dialog = identifiers that can correlate separate actions taken by a signaling element. It doesn't say who has the management system, and in particular doesn't = say that the management system is in the public safety system. If a carrier = or enterprise is in the path, and we can determine that they are in the = path, then we can communicate with them. Don't need interconnection of = management systems. >=20 > Real time in voice is 50 packets a second. Do you need this level of > communicate to CDR records from *every* server? No >=20 > BTW - what's the definition of an "element"? Is it limited to a SIP = (or > v/v/im based) element, or does this include access to a CLI or network > mgmt > platform of all routers the packet happened to traverse? SIP level is what we are thinking, not routers >=20 > Req 3.1-5 define what a congestion control is. Is it at layer 1,2,3,5 > and/or 7? In signaling or media packets? Layer 7 congestion controls = can > be > done with redirects and automated session forwards, but at layer 3 = you'll > probably run into some problems without an interface being down. Yeah, need more work here. I think we're thinking this is all SIP level = or equivalent >=20 > Req 3.1-7 - what's an MSC? You don't have an acronym section in this = doc > prior to this acronym. Okay, sorry. "Mobile Switching Center" >=20 > And, this req isn't an IETF issue other than to specify that a GW of > whatever type converts an inbound call set-up to the appropriate = signaling > protocol to meet the other requirements. So this req should be = removed. Nope, it says you have to make this work when calls originate on = gateways. That means there has to be A WAY to handle the location related data, = and the routing data, when calls originate in the PSTN (or a mobile = network). It may have implications on how routing is done. >=20 > Req 3.1-8 talks about peak load call set-up time and the use of CAMA > circuits. Are you considering the peak load of every signaling element = in > the path all at once or individually? Specifying anything about CAMA > circuits is out of scope. May need more discussion. I personally think you consider peak load = within a domain. The CAMA discussion was to forestall anyone objecting that if there is a CAMA link in the path, you can't meet it. Probably true that ecrit can only consider the IP part of the path. >=20 > Req 3.2-5 how does a UA determine which LO it transmits is the most > accurate? Doesn't it take whatever is currently available as is and > transmit it? This is part of a complex problem we have also raised in geopriv. We need a very well defined solution so that routing elements can decide what to do. If it gets two locations, it needs to have a really simple = way to decide what to base routing decisions are. If multiple location = transit the system, we need to know what they mean in a way that lets the PSAP = make quick, appropriate decisions. There ARE reasonable circumstances where there are multiple locations, as well as multiple representations of the same location. We have to have ways of keeping these things straight, = and not ask elements to have complex logic to figure it out. >=20 > Req 3.2-8 and 3.2-9 Please define what "default location" is. A UA = likely > has *a* location. How can that be determined to be default or not by = the > UA? Use a cablemodem as an example. We need mechanisms that would locate a specific cablemodem to a specific street address. Suppose something = fails, and we can't figure out what the address is. We know the service area = the CMTS serves. We can route based on that; say to resolution of a city. The "default location" is the area served by the CMTS. >=20 > Req 3.3-1 Is (or can) this call back URI a AOR, a GRUU or a tel:uri? = And > if > it is one of these, what do you want done with it (i.e. any special > handling)? I think this is somewhat system dependent. It's a URI of some form, and = it has to get to the device that called. So, a GRUU may be appropriate in = some circumstances. In others, an AoR or a tel would be appropriate. What = you care about is if the call is terminated, and you want to call back the party, a call placed to that URI will get the guy who called back. =20 >=20 > Req 3.4.1 This doesn't have anything to do with identification of an > emergency call or the routing of that call, therefore this is out of = scope > of this WG. ECRIT is going to have to deal with databases that provide routing and validation of locations. We need hooks in those databases for = additional information. That makes it in scope. If it's out of scope, where is it in scope? ...snip of similar questions and responses... > Section 3.5 "Validation of Civic Location" This doesn't have anything = to > do > with identification of an emergency call or the routing of that call, > therefore this is out of scope of this WG. This is good information to > determine, but it has no place here. Nope. It has to do with routing of the call. You MUST validate location = BEFORE you route. This is a fundamental requirement we have for processing of emergency = calls. You cannot route a location that is not in the routing database. You = need to know that before you are called upon to route. >=20 > Req 3.6-2 and 3.6-3 should be combined, as one if the follow-on of the > other. I hadn't realized this was a requirement of requirements documents. There are two ideas here. One is that you can route on either. The other is that you must not require conversion. Happy to reword if the current wording confused you. > Req 3.6-4 "It must be possible for a designated 9-1-1 authority for a = PSAP > to approve of any geo-coding database used to assist in determining > routing > of calls to that PSAP." >=20 > An authority validating a database? This is out of scope of this WG. Nope. We're defining this database here. We need to provide mechanisms = to make the database accurate. Might need signatures, for example. >=20 > Req 3.6-5 "It must be possible for the designated 9-1-1 authority to > supply, maintain, or approve of databases used for civic routing. " >=20 > An authority supplying a database? maintaining a database? approving a > database? This is out of scope of this WG. Maybe; depends on how the database is organized and who does it. >=20 > BTW - what's the difference between an authority validating a database = and > approving a database? These are in 2 consecutive requirements. Two different databases. One is a geocoding database, the other is a routing database. We probably could tighten up the wording tho, since validate/approve is the same thing. >=20 > Req 3.6-6 'conversion of geo formats' is out of scope of this WG Well, it=92s the formats that we need standardized. If its out of scope = here. where is it in scope? >=20 > Req 3.6-9 doesn't make sense. Each element is going to use what needs. The issue here is that in Sweden, you route based on county code. In = some parts of the U.S, which side of the street you are on matters. This requirement says you can't assume that routing granularities are the = same everywhere. I think that is a valid requirement. >=20 > Req 3.6.11 assumes the UA has the key only. This doesn't seem like it = will > create interoperability (having two routing systems), it seems like = this > will create interoperability problems (where one element uses one = method > and another uses the other). No, it says that all routing elements must have access to both, and must = be able to route on either. It's not possible to have one, unless we bite a very large bullet and = demand accurate geocode databases be created everywhere. >=20 > 3.6-13: "It must be possible for a given PSAP to decide where its = calls > should be routed." Where is this done, in DNS? or is this req = referring to > the PSAP having the ability to do with the inbound call what it wants > (when > it arrives)? No, it means it must have the ability to specify the route (that which = is retrieved from the database). It's a data ownership and authority = issue. I think it turns into what Request URI is pulled out of the database. >=20 > I'm getting tired is seeing references to "req ?". Do I the read have = to > figure this out? Sorry, my fault. I'll fix this. >=20 > Also, there are a lot of Bill-characters. That needs to be fixed. Yes. Don't know how I got them. >=20 > 3.6-15: "Routing as specified in Req ? may change on short notice due = to > local conditions, traffic, failures, schedule, etc." This isn't a > requirement, so it should be removed. I can reword it, but the point is that you can't determine a route at, = say, boot time, if you assume systems can stay up for months. >=20 > 3.6-17: "Routing information must be secured against unauthorized > modification." Is this req referring to the routing database? Is that = an > IP > problem? If not, this is out of scope for this WG and should be = removed. The routing database is going to get specified here. It needs controls = on unauthorized modification. What part of that is controversial? >=20 > Req 3.6-18 through 6-201 talk about "contingency routing". Adding more > than > one URI destination for a PSAP, and then complicating that with a > different > URI per failure scenario within a proxy is making the Proxy's routing > database (per proxy, that is) fairly complicated; perhaps = unnecessarily > so. > I'm wondering how this can be maintain "only by higher level civic > authorities" from Req 3.6-14 and expect to scale and be true all the = time > (3600x24x7)? When you have more than one contingency route intended for the same circumstances, you try them one at a time until you get through. Having different contingencies for different circumstances implies we need some kind of labeling. I don't think its more complex than that. >=20 > 3.6-21: "A procedure must be specified to handle =F4default route=F6 > capability > when no location is available or the location information is = corrupted." > How exactly does my UA (which just called 911) know what its default = route > is? Or for that matter, how does a proxy know how to route the call is = the > location data has been corrupted? The UA doesn't do anything other = than > indicate the session is an emergency call (with sos@ perhaps) and = include > a > PIDF-LO. The UA doesn't do anything else except wait for the 200 OK = (best > case), right? Well this gets to the possibility of multiple locations (a default and = an actual). If the location has some integrity protection, or when you = look it up in the routing database you don't find it (despite validation), you = need a default route. >=20 > 3.6-22: "Location available at the time the call is routed may not be > accurate. Updates to location may result in a different route and the > system must accommodate this." >=20 > I don't know how a system can determine if a location is or is not > accurate, so this req should be removed. Further, the INVITE will be > routed > how the routing database says it should be routed, regardless of how = long > ago the database was updated. We need to be able to do this. It may be trivial as long as the = destination can reroute. >=20 > 3.6-24: "Access Infrastructure providers must provide a location = object > that is as accurate as possible when location measurement or lookup > mechanisms fail." >=20 > This is calling for "adding a (location) message body to a message", = and > is > illegal in SIP at this time. No, this means that operationally, you always get a location, even if = your primary location determination mechanism fails. The AIP is at the = beginning of the process, not in the middle. >=20 > 3.6-25: "Entities routing emergency calls shall retain information = used to > choose a route for subsequent error resolution." Is this asking that > Proxies be transaction or dialog stateful? Nope. It means they retain the info they had when they routed, and what they did. >=20 > Req 3.7-1 If there is connectivity and a path, why wouldn't the = message be > routed appropriately? This req should be removed. This depends on how the system is designed. This says you should not = depend on intermediaries that can fail. >=20 > Req 3.8-1 "There shall be no single point of failure" this is > unattainable, > therefore it should be removed Disagree. Within the scope of the work, the system should be designed = so that every element can be redundant. That is reasonable. As an = example, we need to have multiple copies of databases. >=20 > 3.8-2: "Each subsystem in the i3 solution shall be designed such that = the > system survives major disruption including disaster, deliberate = attack, > and > massive element failure." >=20 > This is an architectural requirement, which is not per of the charter = of > this WG, therefore this req should be removed. I disagree strongly. This says we should have a bias to choose solutions that are known to be very reliable in the face of massive failure. We have experience with = many subsystems in the Internet that have this characteristic. We should use them, rather than design new ones that might or might not have such characteristics. This says that DoS is a certainty, and we have to = design systems to be very resilient to such attacks. This says that we really = care about the integrity of data used in the system, and it must be hardened against deliberate forgery or attempts to misroute calls. >=20 > 3.8-3: "Special consideration should be given to =F4Distributed Denial = of > Service=F6 attacks" >=20 > This is an architectural requirement, which is not per of the charter = of > this WG, therefore this req should be removed. Huh? This system is going to be a prime DoS target. Having a requirement = that highlights that fact is pretty reasonable I think. While every system should be hardened against DDoS, this system is particularly vulnerable. I expect exhaustive analysis of this issue in = the security session of the resulting work. >=20 > 3.8-5: "Mechanisms must be provided to provide constant verification = of > service availability to the PSAP." >=20 > Meaning my phone has to maintain TCP connectivity to a PSAP at all = times? > Is this expected to scale? And, is this expected to matter to Joe = Citizen? No, it means that we need ways to determine that the system is working. = You want that to be proactive; before calls fail. The mechanisms must = support ways to do that. It might be trivial, it might be hard. Depends on = what the solution looks like. >=20 > 3.8-6: "Mechansism must be provided to provide automatically generated > misroute and location error reports." From where to where? >From the routing elements. To is an area that needs some work. = Ultimately, the PSAP, but it might need some structure to get it there. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 9 16:31:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22390; Wed, 9 Mar 2005 16:31:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D98os-0003PT-NJ; Wed, 09 Mar 2005 16:34:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D98kI-0008S3-Tf; Wed, 09 Mar 2005 16:29:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D98kH-0008Ry-LD for ecrit@megatron.ietf.org; Wed, 09 Mar 2005 16:29:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22101 for ; Wed, 9 Mar 2005 16:29:31 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D98mv-0003LT-Vk for ecrit@ietf.org; Wed, 09 Mar 2005 16:32:19 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.4) with ESMTP id for ; Wed, 9 Mar 2005 16:09:28 -0500 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, 9 Mar 2005 13:09:25 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657501E3CC99@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: contact info for editor Thread-Index: AcUkakcj9uH0gljmQjedZXYHnt+nYQAgUxDw From: "Roger Marshall" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] contact info for editor 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable For those on the hook to send me their existing requirements, my contact info is as follows: Roger Marshall (206)792-2424 w. rmarshall@telecomsys.com _______________________________________________ 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 Mar 9 17:23:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26772; Wed, 9 Mar 2005 17:23:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D99cv-0004c5-3Y; Wed, 09 Mar 2005 17:26:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D99XP-0007Za-4u; Wed, 09 Mar 2005 17:20:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D99XO-0007ZT-5G for ecrit@megatron.ietf.org; Wed, 09 Mar 2005 17:20:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26513 for ; Wed, 9 Mar 2005 17:20:15 -0500 (EST) From: steve.norreys@bt.com Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D99a2-0004Z6-Uw for ecrit@ietf.org; Wed, 09 Mar 2005 17:23:04 -0500 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Wed, 9 Mar 2005 22:20:07 +0000 Received: from i2km08-ukbr.domain1.systemhost.net ([193.113.197.82]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 9 Mar 2005 22:20:06 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C524F6.25A6DABC" Date: Wed, 9 Mar 2005 22:20:06 -0000 Message-ID: <9D598A34672DF24F89FF4F851A416195450E78@i2km08-ukbr.domain1.systemhost.net> X-MS-Has-Attach: yes Thread-Topic: ETSI TISPAN EMTEL requirements Thread-Index: AcUk9P5vbeWQQR7oTdSBE4GfjVkQrQ== To: X-OriginalArrivalTime: 09 Mar 2005 22:20:06.0856 (UTC) FILETIME=[26084C80:01C524F6] X-Spam-Score: 0.3 (/) X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 Subject: [Ecrit] ETSI TISPAN EMTEL 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 X-Spam-Score: 0.3 (/) X-Scan-Signature: 715d0e6950aaebd45af78ef9318d0186 This is a multi-part message in MIME format. ------_=_NextPart_001_01C524F6.25A6DABC Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsDQogDQpBcyBzYWlkIHRvZGF5IEkgaGF2ZSBhdHRhY2hlZCB0aGUgdGhlIGRyYWZ0IEVTVEkg U3RhbmRhcmQgZm9yIFRJU1BBTiBFTVRFTCByZXF1aXJlbWVudHMgdGhhdCB3YXMgYXBwcm92ZWQg YXQgdGhlIG1lZXRpbmcgbGFzdCB3ZWVrLiBZb3Ugc2hvdWxkIGJlIGF3YXJlIHRoYXQgdGhpcyBk b2N1bWVudCBpcyBub3cgb3V0IG9uIHRoZSBlbWFpbCBleHBsb2RlciBmb3IgY29tbWVudHMgYnkg dGhlIHdpZGVyIGNvbW11bml0eSBhbmQgdGhpcyBzaG91bGQgdGhlbiBiZSBhcHByb3ZlZCBieSB0 aGUgV0cgb24gdGhlIDIzcmQgTWFyY2guDQogDQpSZWdhcmRzDQogDQpTdGV2ZSBOb3JyZXlzDQo= ------_=_NextPart_001_01C524F6.25A6DABC Content-Type: text/plain; name="ETSI NGN EMTEL requirements.txt" Content-Description: ETSI NGN EMTEL requirements.txt Content-Disposition: attachment; filename="ETSI NGN EMTEL requirements.txt" Content-Transfer-Encoding: base64 RHJhZnQgRVRTSSBERVMgMDEwMTkgVjAuMi4xICgyMDA0LTA5KQ0KDQpSZXF1aXJlbWVudHMgb2Yg dGhlIE5HTiBuZXR3b3JrIHRvIHN1cHBvcnQgdGhlIGVtZXJnZW5jeSBzZXJ2aWNlIGZvciBjb21t dW5pY2F0aW9uIGZyb20gY2l0aXplbiB0byBhdXRob3JpdHk7DQoNCkVUU0kNCjY1MCBSb3V0ZSBk ZXMgTHVjaW9sZXMNCkYtMDY5MjEgU29waGlhIEFudGlwb2xpcyBDZWRleCAtIEZSQU5DRQ0KDQpU ZWwuOiArMzMgNCA5MiA5NCA0MiAwMCAgIEZheDogKzMzIDQgOTMgNjUgNDcgMTYNCg0KU2lyZXQg TrAgMzQ4IDYyMyA1NjIgMDAwMTcgLSBOQUYgNzQyIEMNCkFzc29jaWF0aW9uIOAgYnV0IG5vbiBs dWNyYXRpZiBlbnJlZ2lzdHLpZSDgIGxhDQpTb3VzLVBy6WZlY3R1cmUgZGUgR3Jhc3NlICgwNikg TrAgNzgwMy84OA0KDQoNCg0KSW1wb3J0YW50IG5vdGljZQ0KSW5kaXZpZHVhbCBjb3BpZXMgb2Yg dGhlIHByZXNlbnQgZG9jdW1lbnQgY2FuIGJlIGRvd25sb2FkZWQgZnJvbToNCmh0dHA6Ly93d3cu ZXRzaS5vcmcNCg0KVGhlIHByZXNlbnQgZG9jdW1lbnQgbWF5IGJlIG1hZGUgYXZhaWxhYmxlIGlu IG1vcmUgdGhhbiBvbmUgZWxlY3Ryb25pYyB2ZXJzaW9uIG9yIGluIHByaW50LiBJbiBhbnkgY2Fz ZSBvZiBleGlzdGluZyBvciBwZXJjZWl2ZWQgZGlmZmVyZW5jZSBpbiBjb250ZW50cyBiZXR3ZWVu IHN1Y2ggdmVyc2lvbnMsIHRoZSByZWZlcmVuY2UgdmVyc2lvbiBpcyB0aGUgUG9ydGFibGUgRG9j dW1lbnQgRm9ybWF0IChQREYpLiBJbiBjYXNlIG9mIGRpc3B1dGUsIHRoZSByZWZlcmVuY2Ugc2hh bGwgYmUgdGhlIHByaW50aW5nIG9uIEVUU0kgcHJpbnRlcnMgb2YgdGhlIFBERiB2ZXJzaW9uIGtl cHQgb24gYSBzcGVjaWZpYyBuZXR3b3JrIGRyaXZlIHdpdGhpbiBFVFNJIFNlY3JldGFyaWF0Lg0K DQpVc2VycyBvZiB0aGUgcHJlc2VudCBkb2N1bWVudCBzaG91bGQgYmUgYXdhcmUgdGhhdCB0aGUg ZG9jdW1lbnQgbWF5IGJlIHN1YmplY3QgdG8gcmV2aXNpb24gb3IgY2hhbmdlIG9mIHN0YXR1cy4g SW5mb3JtYXRpb24gb24gdGhlIGN1cnJlbnQgc3RhdHVzIG9mIHRoaXMgYW5kIG90aGVyIEVUU0kg ZG9jdW1lbnRzIGlzIGF2YWlsYWJsZSBhdCBodHRwOi8vcG9ydGFsLmV0c2kub3JnL3RiL3N0YXR1 cy9zdGF0dXMuYXNwDQoNCklmIHlvdSBmaW5kIGVycm9ycyBpbiB0aGUgcHJlc2VudCBkb2N1bWVu dCwgcGxlYXNlIHNlbmQgeW91ciBjb21tZW50IHRvIG9uZSBvZiB0aGUgZm9sbG93aW5nIHNlcnZp Y2VzOg0KaHR0cDovL3BvcnRhbC5ldHNpLm9yZy9jaGFpcmNvci9FVFNJX3N1cHBvcnQuYXNwDQoN CkNvcHlyaWdodCBOb3RpZmljYXRpb24NCk5vIHBhcnQgbWF5IGJlIHJlcHJvZHVjZWQgZXhjZXB0 IGFzIGF1dGhvcml6ZWQgYnkgd3JpdHRlbiBwZXJtaXNzaW9uLg0KVGhlIGNvcHlyaWdodCBhbmQg dGhlIGZvcmVnb2luZyByZXN0cmljdGlvbiBleHRlbmQgdG8gcmVwcm9kdWN0aW9uIGluIGFsbCBt ZWRpYS4NCg0KKGMpIEV1cm9wZWFuIFRlbGVjb21tdW5pY2F0aW9ucyBTdGFuZGFyZHMgSW5zdGl0 dXRlIHl5eXkuDQpBbGwgcmlnaHRzIHJlc2VydmVkLg0KDQpERUNUVE0sIFBMVUdURVNUU1RNIGFu ZCBVTVRTVE0gYXJlIFRyYWRlIE1hcmtzIG9mIEVUU0kgcmVnaXN0ZXJlZCBmb3IgdGhlIGJlbmVm aXQgb2YgaXRzIE1lbWJlcnMuDQpUSVBIT05UTSBhbmQgdGhlIFRJUEhPTiBsb2dvIGFyZSBUcmFk ZSBNYXJrcyBjdXJyZW50bHkgYmVpbmcgcmVnaXN0ZXJlZCBieSBFVFNJIGZvciB0aGUgYmVuZWZp dCBvZiBpdHMgTWVtYmVycy4gM0dQUFRNIGlzIGEgVHJhZGUgTWFyayBvZiBFVFNJIHJlZ2lzdGVy ZWQgZm9yIHRoZSBiZW5lZml0IG9mIGl0cyBNZW1iZXJzIGFuZCBvZiB0aGUgM0dQUCBPcmdhbml6 YXRpb25hbCBQYXJ0bmVycy4NCg0KQ29udGVudHMNCkludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdo dHMJCQkJCQk0DQpGb3Jld29yZAkJCQkJCQkJCTQNCkludHJvZHVjdGlvbgkJCQkJCQkJNA0KMQlT Y29wZQkJCQkJCQkJCTUNCjIJUmVmZXJlbmNlcwkJCQkJCQkJNQ0KTnVtYmVyZWQgcmVmZXJlbmNl IGZvcm1hdAkJCQkJCTUNClVubnVtYmVyZWQgcmVmZXJlbmNlIGZvcm1hdAkJCQkJCTUNCjMJRGVm aW5pdGlvbnMsIHN5bWJvbHMgYW5kIGFiYnJldmlhdGlvbnMJCQk2DQozLjEJRGVmaW5pdGlvbnMJ CQkJCQkJCTYNCkRlZmluaXRpb24gZm9ybWF0CQkJCQkJCQk2DQozLjIJU3ltYm9scwkJCQkJCQkJ Ng0KU3ltYm9sIGZvcm1hdAkJCQkJCQkJNg0KMy4zCUFiYnJldmlhdGlvbnMJCQkJCQkJNg0KQWJi cmV2aWF0aW9uIGZvcm1hdAkJCQkJCQk2DQo0CUVtZXJnZW5jeSBTZXNzaW9ucyBSZXF1aXJlbWVu dHMJCQkJNw0KNC4xCUdlbmVyYWwgUmVxdWlyZW1lbnRzCQkJCQkJNw0KNC4xLjEJSWRlbnRpZmlj YXRpb24gb2YgZW1lcmdlbmN5IG51bWJlcnMJCQkJOA0KNC4xLjIJTG9jYXRpb24gaW5mb3JtYXRp b24gZGVyaXZhdGlvbiBhbmQgaGFuZGxpbmcuCQk4DQo0LjEuMwlEb21haW5zIHByaW9yaXR5IGFu ZCBzZWxlY3Rpb24gZm9yIE5HTiBUZXJtaW5hbCBhdHRlbXB0cyB0byBlbWVyZ2VuY3kgY2FsbAkJ CQkJCQkJOA0KNC4yCVJlcXVpcmVtZW50cyBmb3IgYW4gUFNUTi9JU0ROIEVtdWxhdGlvbiBTdWJz eXN0ZW0gYW5kIFNpbXVsYXRpb24gc2VydmljZXMgaW4gdGhlIElNUyBwcm92aWRpbmcgRW1lcmdl bmN5IGNhbGxzCTkNCjQuMwlSZXF1aXJlbWVudHMgZm9yIGFuIElNUyBTdWJzeXN0ZW0gRW1lcmdl bmN5IFNlc3Npb25zCTkNCjQuNAlFbWVyZ2VuY3kgQ2FsbHMgaW4gdGhlIFBTIENOIERvbWFpbgkJ CQkxMA0KNC41CUVtZXJnZW5jeSBDYWxscyB3aGVuIEF0dGFjaGVkIHZpYSBhbiBJLVdMQU4JCTEw DQo0LjYJQXJjaGl0ZWN0dXJlIHJlcXVpcmVtZW50cwkJCQkJMTANCjQuNwlQcm90b2NvbCAmIFNl Y3VyaXR5IHJlcXVpcmVtZW50cwkJCQkxMA0KDQoNCkludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdo dHMNCklQUnMgZXNzZW50aWFsIG9yIHBvdGVudGlhbGx5IGVzc2VudGlhbCB0byB0aGUgcHJlc2Vu dCBkb2N1bWVudCBtYXkgaGF2ZSBiZWVuIGRlY2xhcmVkIHRvIEVUU0kuIFRoZSBpbmZvcm1hdGlv biBwZXJ0YWluaW5nIHRvIHRoZXNlIGVzc2VudGlhbCBJUFJzLCBpZiBhbnksIGlzIHB1YmxpY2x5 IGF2YWlsYWJsZSBmb3IgRVRTSSBtZW1iZXJzIGFuZCBub24tbWVtYmVycywgYW5kIGNhbiBiZSBm b3VuZCBpbiBFVFNJIFNSIDAwMCAzMTQ6ICJJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIChJ UFJzKTsgRXNzZW50aWFsLCBvciBwb3RlbnRpYWxseSBFc3NlbnRpYWwsIElQUnMgbm90aWZpZWQg dG8gRVRTSSBpbiByZXNwZWN0IG9mIEVUU0kgc3RhbmRhcmRzIiwgd2hpY2ggaXMgYXZhaWxhYmxl IGZyb20gdGhlIEVUU0kgU2VjcmV0YXJpYXQuIExhdGVzdCB1cGRhdGVzIGFyZSBhdmFpbGFibGUg b24gdGhlIEVUU0kgV2ViIHNlcnZlciAoaHR0cDovL3dlYmFwcC5ldHNpLm9yZy9JUFIvaG9tZS5h c3ApLg0KDQpQdXJzdWFudCB0byB0aGUgRVRTSSBJUFIgUG9saWN5LCBubyBpbnZlc3RpZ2F0aW9u LCBpbmNsdWRpbmcgSVBSIHNlYXJjaGVzLCBoYXMgYmVlbiBjYXJyaWVkIG91dCBieSBFVFNJLiBO byBndWFyYW50ZWUgY2FuIGJlIGdpdmVuIGFzIHRvIHRoZSBleGlzdGVuY2Ugb2Ygb3RoZXIgSVBS cyBub3QgcmVmZXJlbmNlZCBpbiBFVFNJIFNSIDAwMCAzMTQgKG9yIHRoZSB1cGRhdGVzIG9uIHRo ZSBFVFNJIFdlYiBzZXJ2ZXIpIHdoaWNoIGFyZSwgb3IgbWF5IGJlLCBvciBtYXkgYmVjb21lLCBl c3NlbnRpYWwgdG8gdGhlIHByZXNlbnQgZG9jdW1lbnQuDQoNCkZvcmV3b3JkDQoNClRoaXMgRVRT SSBTdGFuZGFyZCAoRVMpIGhhcyBiZWVuIHByb2R1Y2VkIGJ5IEVUU0kgVGVjaG5pY2FsIENvbW1p dHRlZSBUSVNQQU4gV0cxIE5HTiBzZXJ2aWNlcywgYW5kIGlzIG5vdyBzdWJtaXR0ZWQgZm9yIHRo ZSBFVFNJIHN0YW5kYXJkcyBNZW1iZXJzaGlwIEFwcHJvdmFsIFByb2NlZHVyZS4NCg0KMQlTY29w ZQ0KDQpUaGUgcHJlc2VudCBkb2N1bWVudCBjb250YWlucyB0aGUgcmVxdWlyZW1lbnRzIG9mIGEg TkdOIHRvIHN1cHBvcnQgZW1lcmdlbmN5IGNvbW11bmljYXRpb25zIChFTVRFTCkgZnJvbSB0aGUg Y2l0aXplbiB0byB0aGUgYXV0aG9yaXR5LiAgVGhlIHJlcXVpcmVtZW50cyBhcmUgaW5kZXBlbmRl bnQgb2YgdGhlIE5HTiBzdWJzeXN0ZW0gYW5kIHRyYW5zcG9ydCBsYXllciB1bmxlc3Mgc3BlY2lm aWNhbGx5IHJlZmVycmVkIHRvLiANCg0KMglSZWZlcmVuY2VzDQoNClsxXQlEaXJlY3RpdmUgMjAw Mi8yMS9FQyBvbiBhIGNvbW1vbiByZWd1bGF0b3J5IGZyYW1ld29yayBmb3IgZWxlY3Ryb25pYyBj b21tdW5pY2F0aW9ucyBhbmQgc2VydmljZXMgKHRoZSAiRnJhbWV3b3JrIERpcmVjdGl2ZSIpLCBh bmQgaW4gcGFydGljdWxhciBBcnRpY2xlIDE5DQoNClsyXQlEaXJlY3RpdmUgMjAwMi8yMi9FQyBv biB1bml2ZXJzYWwgc2VydmljZSBhbmQgdXNlcnMgcmlnaHRzIHJlbGF0aW5nIHRvIGVsZWN0cm9u aWMgY29tbXVuaWNhdGlvbnMgbmV0d29ya3MgYW5kIHNlcnZpY2VzICh0aGUgIlVuaXZlcnNhbCBT ZXJ2aWNlIERpcmVjdGl2ZSIpDQoNClszXQlEaXJlY3RpdmUgMjAwMi81OC9FQyBvbiBhIGNvbmNl cm5pbmcgdGhlIHByb2Nlc3Npbmcgb2YgcGVyc29uYWwgZGF0YSBhbmQgdGhlIHByb3RlY3Rpb24g b2YgcHJpdmFjeSBpbiB0aGUgZWxlY3Ryb25pYyBjb21tdW5pY2F0aW9ucyBzZWN0b3IgKHRoZSAi RGlyZWN0aXZlIG9uIHByaXZhY3kgYW5kIGVsZWN0cm9uaWMgY29tbXVuaWNhdGlvbnMiKQ0KDQpb NF0JU1IgMDAyIDE4MCBFVFNJIFNwZWNpYWwgUmVwb3J0OiBFTVRFTCBSZXF1aXJlbWVudHMgZm9y IGNvbW11bmljYXRpb24gb2YgY2l0aXplbnMgd2l0aCBhdXRob3JpdGllcy9vcmdhbml6YXRpb25z IGluIGNhc2Ugb2YgZGlzdHJlc3MgKGVtZXJnZW5jeSBjYWxsIGhhbmRsaW5nKQ0KDQpbNV0JVFMg MjQuMDA4IERpZ2l0YWwgY2VsbHVsYXIgdGVsZWNvbW11bmljYXRpb25zIHN5c3RlbSAoUGhhc2Uy Kyk7IFVuaXZlcnNhbCBNb2JpbGUgVGVsZWNvbW11bmljYXRpb3MgU3lzdGVtIChVTVRTKTsgTW9i aWxlIHJhZGlvIGludGVyZmFjZSBMYXllciAzIHNwZWNpZmljYXRpb247IENvcmUgbmV0d29yayBw cm90b2NvbHM7DQoNCltUUiAyMyA4NjddCTNHUFAgVFIgMjMgODY3OiAiIEludGVybmV0IFByb3Rv Y29sIChJUCkgYmFzZWQgSVAgTXVsdGltZWRpYSBTdWJzeXN0ZW0gKElNUykgZW1lcmdlbmN5IHNl c3Npb25zOyBSZWxlYXNlIDciLg0KDQozCURlZmluaXRpb25zLCBzeW1ib2xzIGFuZCBhYmJyZXZp YXRpb25zDQoNCjMuMQlEZWZpbml0aW9ucw0KDQozLjMJQWJicmV2aWF0aW9ucw0KDQozR1BQCTNy ZCBHZW5lcmF0aW9uIFBhcnRuZXJzaGlwIFByb2plY3QNCkNMSQlDYWxsaW5nIExpbmUgSWRlbnRp dHkNCkRIQ1AJRHluYW1pYyBIb3N0IENvbmZpZ3VyYXRpb24gUHJvdG9jb2wNCkVDQwlFbWVyZ2Vu Y3kgQ29udHJvbCBDZW50cmUgDQpGLU1NUwlGaXhlZCBsaW5lIE11bHRpbWVkaWEgTWVzc2FnaW5n IFNlcnZpY2UNCklNUyAJSVAgTXVsdGltZWRpYSBTdWJzeXN0ZW0NCklQCUludGVybmV0IFByb3Rv Y29sDQpJU0ROCUludGVyZ3JhdGVkIFNlcnZpY2VzIERpZ2l0YWwgTmV0d29yaw0KSVNJTQlJTSBT ZXJ2aWNlcyBJZGVudGl0eSBNb2R1bGUNCk1NSQlNYW4gTWFjaGluZSBJbnRlcmZhY2UNCk5HTglO ZXh0IEdlbmVyYXRpb24gTmV0d29yaw0KUFNBUAlQdWJsaWMgU2FmZXR5IEFuc3dlcmluZyBQb2lu dA0KUFNUTglQdWJsaWMgU3dpdGNoIFRlbGVwaG9uZSBOZXR3b3JrDQpTRFAJU2Vzc2lvbiBEZXNj cmlwdGlvbiBQcm90b2NvbA0KU0lQCVNlc3Npb24gSW5pdGlhdGVkIFByb3RvY29sDQpVUkkJVW5p Zm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyDQpWb0lQCVZvaWNlIG92ZXIgSVANClZQTglWaXJ0dWFs IFByaXZhdGUgTmV0d29yaw0KDQo0CUVtZXJnZW5jeSBTZXNzaW9ucyBSZXF1aXJlbWVudHMNCg0K VGhlIGZvbGxvd2luZyBpcyBhIGxpc3Qgb2YgdmVyeSBoaWdoIGxldmVsIHJlcXVpcmVtZW50cyBm b3IgYW4gZW1lcmdlbmN5IGNhbGwvc2Vzc2lvbiBiZXR3ZWVuIGEgdXNlciBhbmQgdGhlIFBTQVAv RUNDIHdoZW4gYW4gMTEyIHR5cGUgc2VydmljZSBpcyByZXF1ZXN0ZWQuIA0KDQoqIFByb3ZpZGUg YSB2b2ljZSBsaW5rLCBtYWludGFpbmVkIHRocm91Z2hvdXQgdGhlIGNhbGwNCiogUmVjZWl2ZSBp bW1lZGlhdGUgcHJpb3JpdHkgdHJlYXRtZW50IG92ZXIgb3RoZXIgY2FsbHMNCiogTXVzdCBub3Qg YmUgc3ViamVjdCB0byByZXN0cmljdGl2ZSBuZXR3b3JrIG1hbmFnZW1lbnQgcHJhY3RpY2VzDQoq IE11c3QgYmUgc3ViamVjdCB0byBub3JtYWwgY2FsbCByZWNvcmRzLCBjaGFyZ2luZyBhbmQgYWNj b3VudGluZyAoZXZlbiB0aG91Z2ggdGhlIGNhbGwgaXMgZnJlZSkNCiogTXVzdCBwcm92aWRlIGEg dW5pcXVlIElEICB0byBlbmFibGUgYSBjYWxsYmFjayAoZWcgQ0xJKSBhbmQgICAgICBOZXR3b3Jr IE9wZXJhdG9yIElEDQoqIE9yaWdpbmF0aW5nIGdlb2dyYXBoaWMgbG9jYXRpb24gbXVzdCBiZSBh dXRvbWF0aWNhbGx5IHByb3ZpZGVkIHRvIGRldGVybWluZSANCgktIGNvcnJlY3QgUFNBUCBvcGVy YXRvciB0byByb3V0ZSB0aGUgY2FsbCB0bw0KCS0gYXBwcm9wcmlhdGUgbG9jYWwgZW1lcmdlbmN5 IHNlcnZpY2UgY2VudHJlDQoJLSBsb2NhdGlvbiB0byBhY2N1cmF0ZWx5IGRlc3BhdGNoIGFzc2lz dGFuY2UuDQoqIExvY2F0aW9uIGluZm9ybWF0aW9uIG11c3QgYmUgYXV0b21hdGljYWxseSBhdmFp bGFibGUgYXQgdGhlIFBTQVAgY2VudHJlDQoqIE11c3QgYmUgbWlncmF0ZWQgdG8gbXVsdGktcGFy dHkgY2FsbHMgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlIFBTQVAgb3BlcmF0b3INCiogU2hhbGwg YmUgc3ViamVjdCB0byAibGFzdCBwYXJ0eSBjbGVhciIsIG9yIG90aGVyIG1ldGhvZCBmb3IgaGFu ZGxpbmcgZmFsc2UgY2FsbHMNCiogU2hhbGwgYmUgcmVzdG9yZWQgd2l0aCBwcmlvcml0eSBvdmVy IG5vcm1hbCBjYWxscy4NCiogTmVlZCBJUCBhbmQgUFNUTiBFbWVyZ2VuY3kgQ2FsbCBDZW50cmUg c29sdXRpb24NCg0KNC4xIEdlbmVyYWwgUmVxdWlyZW1lbnRzDQoNCkl0IHNoYWxsIGJlIHBvc3Np YmxlIHRvIGVzdGFibGlzaCBhIHNlc3Npb24gZm9yIGFuIGVtZXJnZW5jeSBzcGVlY2ggY2FsbC4g VGhlc2UgRW1lcmdlbmN5IGNhbGxzIHNoYWxsIGJlIHJvdXRlZCB0byB0aGUgZW1lcmdlbmN5IHNl cnZpY2VzIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgbmF0aW9uYWwgcmVndWxhdGlvbnMgb2Ygd2hl cmUgdGhlIGNhbGxlciBpcyBsb2NhdGVkIHdoaWNoIG1heSByZXF1aXJlIHRoYXQgdGhlc2UgY2Fs bHMgcmVjZWl2ZSBhIGhpZ2hlciBsZXZlbCBvZiBwcmlvcml0eSB0aGFuIGEgbm9ybWFsIGNvbW11 bmljYXRpb24uLiBBbiBlbWVyZ2VuY3kgY2FsbCBtYXkgYmUgYWxsb3dlZCB0byBiZSBlc3RhYmxp c2ggd2l0aG91dCB0aGUgbmVlZCB0byAnZGlhbCcgYSBkZWRpY2F0ZWQgbnVtYmVyIHRvIGF2b2lk IGEgbWlzLWNvbm5lY3Rpb24gaW4gdGhlIG5vbWFkaWMgY2FzZSwgZS5nLiB0aGUgdXNlIG9mIGVu dGl0aWVzIHN1Y2ggYXMgbWVudSwgYnkgdXNlIG9mIGEgJ3JlZCBidXR0b24nIG1heSBiZSBkZXBs b3llZC4gRW1lcmdlbmN5IENhbGxzIG1heSBiZSBzdXBwb3J0ZWQgd2l0aG91dCBhIGRlZGljYXRl ZCBhdXRoZW50aWNhdGlvbiBkZXZpY2Ugb3IgcHJvY2VkdXJlIGJlaW5nIHByZXNlbnQgZm9yIHRo aXMgc2Vzc2lvbi4gDQoNCk5vdGU6IAlJdCB3aWxsIGJlIGxlZnQgdG8gdGhlIG5hdGlvbmFsIGF1 dGhvcml0aWVzIHRvIGRlY2lkZSB3aGV0aGVyIHRoZSBuZXR3b3JrIHNob3VsZCBhY2NlcHQgZW1l cmdlbmN5IGNhbGxzIHdpdGhvdXQgdGhlIGRlZGljYXRlZCBhdXRoZW50aWNhdGlvbiBkZXZpY2Ug b3IgcHJvY2VkdXJlIGJlaW5nIHByZXNlbnQgZm9yIHRoaXMgc2Vzc2lvbi4NCg0KSXQgbWF5IGJl IHBvc3NpYmxlIHRvIGluaXRpYXRlIGVtZXJnZW5jeSBjYWxscyB0byBkaWZmZXJlbnQgZW1lcmdl bmN5IGNhbGwgY2VudHJlcywgZGVwZW5kaW5nIG9uIHRoZSB0eXBlIG9mIGVtZXJnZW5jeS4gVGhl IGZvbGxvd2luZyB0eXBlcyBvZiBlbWVyZ2VuY3kgY2FsbHMgc2hhbGwgYmUgcG9zc2libGU6DQoJ LSBQb2xpY2UNCgktIEFtYnVsYW5jZQ0KCS0gRmlyZSBCcmlnYWRlDQoJLSBNYXJpbmUgR3VhcmQN CgktIE1vdW50YWluIFJlc2N1ZQ0KCS0gQ29tbW9uIGVtZXJnZW5jeSBhbnN3ZXJpbmcgcG9pbnQN CgktIFNwYXJlLCBhdCBsZWFzdCBbdGhyZWVdIGRpZmZlcmVudCB0eXBlcw0KDQpUaGUgTWFuIE1h Y2hpbmUgSW50ZXJmYWNlIChNTUkpIG9uIHNwZWNpZmljIE5HTiBUZXJtaW5hbCBtYXkgYmUgc3Bl Y2lmaWVkIGJ5IHRoZSByZWd1bGF0b3J5IGF1dGhvcml0eSBpbiB3aGljaCB0aGUgY3VzdG9tZXIn cyBzZXJ2aWNlIGNvbnRyYWN0IGlzIGFncmVlZC4gVGhpcyBpbnRlcmZhY2UgaXMgdGhlbiBzdG9y ZWQgb24gdGhpcyBOR04gVGVybWluYWwgYW5kIHRoaXMgc2hhbGwgYmUgZGVwbG95ZWQgd2hlbmV2 ZXIgYW4gZW1lcmdlbmN5IGNhbGwvc2Vzc2lvbiBpcyBhdHRlbXB0ZWQuIA0KDQpJdCBtYXliZSBw b3NzaWJsZSB0byB0aWUgYW55IGVtZXJnZW5jeSBjYWxsIG51bWJlciwgc3BlY2lmaWVkIGluIHRo ZSBwcmVmZXJyZWQgZW1lcmdlbmN5IGNhbGwgTU1JKHMpIGFib3ZlLCB0byBhbnkgc2luZ2xlIGVt ZXJnZW5jeSBjYWxsIHR5cGUgb3IgdG8gYW55IGNvbWJpbmF0aW9uIG9mIGVtZXJnZW5jeSB0eXBl cy4gIFRoZSBhc3NvY2lhdGlvbiBiZXR3ZWVuIGVtZXJnZW5jeSBudW1iZXJzIGFuZCBlbWVyZ2Vu Y3kgY2FsbCB0eXBlIG1heWJlIGFibGUgdG8gYmUgcHJvZ3JhbW1lZCBvbiB0aGUgTkdOIFRlcm1p bmFsIGJ5IHRoZSByZWd1bGF0b3J5IGF1dGhvcml0eSB3aGVyZSB0aGUgY3VzdG9tZXIncyBzZXJ2 aWNlIGNvbnRyYWN0IGlzIGFncmVlZC4NCg0KQ29uc2lkZXJpbmcgdGhlICJEaXJlY3RpdmUgMjAw Mi8yMS9FQyBvbiBhIGNvbW1vbiByZWd1bGF0b3J5IGZyYW1ld29yayBmb3IgZWxlY3Ryb25pYyBj b21tdW5pY2F0aW9ucyBhbmQgc2VydmljZXMgKHRoZSAiRnJhbWV3b3JrIERpcmVjdGl2ZSIpLCBh bmQgaW4gcGFydGljdWxhciBBcnRpY2xlIDE5Ii4gRXVyb3BlYW4gTGF3IFsxXSByZXF1aXJlcyB0 aGF0IDExMiBFbWVyZ2VuY3kgVm9pY2Ugc2VydmljZXMgYXJlIGF2YWlsYWJsZSBhY3Jvc3MgdGhl IEV1cm9wZWFuIFVuaW9uLCBJdCBpcyBub3RlZCB0aGF0IGluIHNvbWUgY291bnRyaWVzIChlLmcu IEdlcm1hbnkpIHRoaXMgY29kZSBkb2VzIG5vdCB0cmFuc2xhdGUgdG8gdGhlIFBvbGljZSwgd2hl cmUgYXMgaW4gb3RoZXIgY291bnRpZXMgKGUuZy4gSXRhbHkpIHRoaXMgaXMgYWx3YXlzIGRlbGl2 ZXJlZCB0byB0aGUgUG9saWNlIHdobyBpbmNsdWRlIG90aGVyIEVtZXJnZW5jeSBzZXJ2aWNlcy4g SW4gb3RoZXIgY291bnRyaWVzIDExMiBpcyBkZWxpdmVyZWQgdG8gYSBQU0FQIHRoYXQgb2ZmZXIg YSBudW1iZXIgb2Ygc2VydmljZXMuDQoNCkV4YW1wbGU6DQoxOQkJUG9saWNlIChBbGJhbmlhKQ0K MTAwCQlQb2xpY2UgYW5kIEZpcmUgQnJpZ2FkZSAoR3JlZWsgY2l0aWVzKQ0KMTAwCQlBbWJ1bGFu Y2UgYW5kIEZpcmUgQnJpZ2FkZSAoQmVsZ2l1bSkNCjExMAkJUG9saWNlIChHZXJtYW55KQ0KMTEy CQlQb2xpY2UgYW5kIEFtYnVsYW5jZSAoSXRhbHkpDQoxMTIJCUdlbmVyYWwgZW1lcmdlbmN5IGNh bGwsIGFsbCBjYXRlZ29yaWVzIChTd2VkZW4pDQoxMTUJCUZpcmUgQnJpZ2FkZSAoSXRhbHkpDQox MTQgCQlBbWJ1bGFuY2UgKEF1c3RyaWEpDQo5MTEgCQlFbWVyZ2VuY3kgVm9pY2UgQWNjZXNzIChO b3J0aCBBbWVyaWNhKQ0KOTk5CQlFbWVyZ2VuY3kgVm9pY2UgU2VydmljZSAoVUsvRWlyZSkNCg0K Tm90ZToJaWYgdGhlIE5HTiBUZXJtaW5hbCBkb2VzIG5vdCByZWNvZ25pc2UgdGhlIGVtZXJnZW5j eSBjYWxsIG51bWJlciBidXQgdGhlIHNlcnZpbmcgbmV0d29yayByZWNvZ25pc2VzIHRoZSBkaWFs bGVkIG51bWJlciBhcyBhbiBlbWVyZ2VuY3kgY2FsbCBudW1iZXIgdXNlZCBpbiB0aGUgY291bnRy eS4gVGhlbiBhIG5vcm1hbCBjYWxsIHNldCB1cCB0YWtlcyBwbGFjZSBhbmQgYWZ0ZXIgdGhlIHNl cnZpbmcgbmV0d29yayBoYXMgcmVjb2duaXNlZCB0aGUgZW1lcmdlbmN5IG51bWJlciB0aGUgY2Fs bCBpcyByb3V0ZWQgYXMgYW4gZW1lcmdlbmN5IGNhbGwuDQoNCkEgdXNlciBmcmllbmRseSBNTUkg dGhhdCBzcGVjaWZpZXMgdGhlIHR5cGUgb2YgZW1lcmdlbmN5IGRpcmVjdGx5IChlLmcuIHZpYSBh IG1lbnUpIG1heSBiZSBzdXBwb3J0ZWQgZm9yIHVzZSBpbiBhbnkgKGkuZS4gaG9tZSBvciB2aXNp dGVkKSBuZXR3b3JrIHRvIGF2b2lkIHRoZSBtaXNzLWNvbm5lY3Rpb24gaW4gdGhlIG5vbWFkaWMg Y2FzZS4gIFRoaXMgc2hhbGwgYmUgYWxsb3dlZCBib3RoIHdpdGggYW5kIHdpdGhvdXQgYXV0aGVu dGljYXRpb24gcHJvY2VkdXJlcyB0YWtlbiBwbGFjZS4NCg0KVGhlIHNlcnZpbmcgbmV0d29yayBt YXkgZG93bmxvYWQgYWRkaXRpb25hbCBlbWVyZ2VuY3kgbnVtYmVycyB0byB0aGUgTkdOIFRlcm1p bmFsIGluIG9yZGVyIHRvIGVuc3VyZSB0aGF0IGxvY2FsIGVtZXJnZW5jeSBudW1iZXJzIGFyZSBr bm93biB0byB0aGUgTkdOIFRlcm1pbmFsLiAgVGhlIE5HTiBUZXJtaW5hbCBzaGFsbCByZWdhcmQg dGhlc2UgZW1lcmdlbmN5IG51bWJlcnMgYXMgdmFsaWQgaW4gdGhhdCBjb3VudHJ5IG9ubHkgYW5k IHNoYWxsIGRpc2NhcmQgdGhlbSB3aGVuIGEgbmV3IGNvdW50cnkgaXMgZW50ZXJlZC4NCg0KNC4x LjEgSWRlbnRpZmljYXRpb24gb2YgZW1lcmdlbmN5IG51bWJlcnMNCg0KVG8gaGFuZGxlIG5vbWFk aWNpdHksIHRoZSBOR04gVGVybWluYWwgc2hhbGwgYmUgYWJsZSB0byBwbGFjZSBjYWxscyBvbiBh IGxvY2FsbHkgc3VwcG9ydGVkIEVtZXJnZW5jeSBudW1iZXIsIGl0IHNob3VsZCBiZSBhYmxlIHN0 b3JlIEVtZXJnZW5jeSBudW1iZXJzLCBhbmQgaW4gdGhlIGNhc2Ugb2YgYSBTSVAgVGVybWluYWws IHRvIHN0b3JlIEVtZXJnZW5jeSBTSVAgVVJJcy4gV2hlbiBhbiBFbWVyZ2VuY3kgY2FsbCBvciBz ZXNzaW9uIGlzIHJlcXVpcmVkLCB0aGUgY29ycmVjdCBOdW1iZXIvVVJJIGlzIHByZXNlbnRlZCB0 byB0aGUgbmV0d29yayBvbiB0aGUgYmFzaXMgb2YgbmF0aW9uYWwga25vd2xlZGdlIGFuZCBpbmZv cm1hdGlvbiBtYWRlIGF2YWlsYWJsZSBhdCB0aGUgQWNjZXNzIHRvIHRoZSBuZXR3b3JrLiBJbiBF dXJvcGUsIHRoaXMgc2hhbGwgYmUgMTEyLCBhbmQgb3B0aW9uYWxseSBhIG5hdGlvbmFsIHBvc3Np Ymx5IHNlcnZpY2Ugc3BlY2lmaWMgbnVtYmVyLikJDQoNCkFkZGl0aW9uYWwgdGhlIE5HTiBUZXJt aW5hbCBtYXkgc3RvcmUgZW1lcmdlbmN5IG51bWJlcnMgdGhhdCBtYXkgaGF2ZSBiZWVuIGRvd25s b2FkZWQgYnkgdGhlIHNlcnZpbmcgbmV0d29yay4NCg0KNC4xLjIgTG9jYXRpb24gaW5mb3JtYXRp b24gZGVyaXZhdGlvbiBhbmQgaGFuZGxpbmcuDQoNClRoZSBsb2NhdGlvbiBpbmZvcm1hdGlvbiBz aGFsbCBbMl0gYmUgZGVyaXZlZCBmcm9tIHRoZSBrbm93biBpbmZvcm1hdGlvbiBhdmFpbGFibGUg aW4gdGhlIG5ldHdvcmssIHRvIHRoZSBleHRlbnQgdGVjaG5pY2FsbHkgZmVhc2libGUuIFVwb24g aW5pdGlhdGluZyB0aGUgZW1lcmdlbmN5IHNlc3Npb24gYW55IGxvY2F0aW9uIGluZm9ybWF0aW9u IHNoYWxsIGJlIHNlbnQgd2l0aCB0aGUgc2V0LXVwIG9mIHRoZSBzZXNzaW9uLiANCklmIGFsbCBs b2NhdGlvbiBpbmZvcm1hdGlvbiBpcyBub3QgYXZhaWxhYmxlIGF0IHRoZSB0aW1lIG9mIHRoZSBz ZXQtdXAgb2YgdGhlIGVtZXJnZW5jeSBzZXNzaW9uIHRoZW4gd2hhdCBpcyBhdmFpbGFibGUgaXMg c2VudCBhbmQgdGhlIG5ldHdvcmsgbWF5IHVzZSBvdGhlciBwb3NpdGlvbmluZyBtZWFucyB0byBv YnRhaW4gb3RoZXIgbG9jYXRpb24gaW5mb3JtYXRpb24NCg0KVGhpcyBsb2NhdGlvbiBpbmZvcm1h dGlvbiBzaGFsbCBiZSBpZGVudGlmaWVkIGFzIGl0cyB0byB0aGUgb3JpZ2luLCBzdWNoIHRoYXQg YWxsIHRoZSBOR04gVGVybWluYWwgZGVyaXZlZCBsb2NhdGlvbiBpbmZvcm1hdGlvbiBpcyBpbmRp Y2F0ZWQgdG8gdGhlIGVtZXJnZW5jeSBhdXRob3JpdHkuIFRoZSBOR04gVGVybWluYWwgcHJvdmlk ZWQgTG9jYXRpb24gSW5mb3JtYXRpb24gaXMgaW5kaWNhdGVkIHN1Y2ggdGhhdCB0aGUgb3JpZ2lu IG9mIHRoZSBpbmZvcm1hdGlvbiBjYW4gYmUgdmVyaWZpZWQuDQoNClRoZSBsb2NhdGlvbiBpbmZv cm1hdGlvbiBzaGFsbCBiZSBzdG9yZWQgdW50aWwgdGhlIGVtZXJnZW5jeSBhdXRob3JpdHkgbm8g bG9uZ2VyIHJlcXVpcmVzIGl0LiBUaGlzIGxvY2F0aW9uIGluZm9ybWF0aW9uIGlzIHNlbnQgdG8g YXBwcm9wcmlhdGUgZW1lcmdlbmN5IGF1dGhvcml0eSB1cG9uIGEgcmVxdWVzdCBmcm9tIHRoaXMg YXV0aG9yaXR5Lg0KDQpUaGUgbG9jYXRpb24gaW5mb3JtYXRpb24gc2hhbGwgYmUgdHJlYXRlZCBh cyBwcml2YXRlIGluZm9ybWF0aW9uIFszXSBhbmQgYXMgc3VjaCBpdCBpcyBzdWJqZWN0IHRvIHRo ZSBwcml2YWN5IHJlZ3VsYXRpb24gb2YgZGF0YSBhcyBzcGVjaWZpZWQgYnkgdGhlIHJlZ3VsYXRv cnkgYXV0aG9yaXR5IHdoZXJlIHRoZSBzZXNzaW9uIGlzIGluaXRpYXRlZC4gVGhpcyBtYXkgaW5j bHVkZSBhbnkgYXV0aG9yaXNhdGlvbiBhbmQgc2VjdXJpdHkgcHJvY2VkdXJlcyBhbmQgb2JsaWdh dGlvbnMgb2YgdGhlIGN1c3RvbWVyLCBOR04gVGVybWluYWwgYW5kIGVtZXJnZW5jeSBhdXRob3Jp dHkuDQoNCjQuMS4zIERvbWFpbnMgcHJpb3JpdHkgYW5kIHNlbGVjdGlvbiBmb3IgTkdOIFRlcm1p bmFsIGF0dGVtcHRzIHRvIGVtZXJnZW5jeSBjYWxsDQoNCkEgUFNUTi9JU0ROIGVtdWxhdGlvbiBz dWJzeXN0ZW0gYW5kIElNUyBzdWJzeXN0ZW0gY2FwYWJsZSBOR04gVGVybWluYWwgYXR0ZW1wdGlu ZyBhbiBlbWVyZ2VuY3kgY2FsbCBzaGFsbCBnaXZlIHByaW9yaXR5IHRvIHRoZSBQU1ROL0lTRE4g ZW11bGF0aW9uIHN1YnN5c3RlbSBkb21haW4uIA0KDQpJbiBjYXNlIHdoZXJlIHRoZSBjYWxsIGF0 dGVtcHQgaW4gdGhlIFBTVE4vSVNETiBlbXVsYXRpb24gc3Vic3lzdGVtIGRvbWFpbiBmYWlscywg dGhlIE5HTiBUZXJtaW5hbCBzaG91bGQgYXV0b21hdGljYWxseSBtYWtlIGEgc2Vjb25kIGF0dGVt cHQgaW4gdGhlIElNUyBzdWJzeXN0ZW0gZG9tYWluLCB3aGVyZSB0aGUgTkdOIFRlcm1pbmFsIGlz IGZhY2lsaXRhdGVkIGFuZCBhdHRhY2hlZCB0byBib3RoIGRvbWFpbnMuDQoNCkluIHRoZSBjYXNl IHdoZXJlIHRoZSBOR04gVGVybWluYWwgY2Fubm90IHN1cHBvcnQgdGhlIElNUyBzdWJzeXN0ZW0g Y2FwYWJpbGl0aWVzIGJ1dCBpcyBhYmxlIHRvIHN1cHBvcnQgdGhlIFBTVE4vSVNETiBlbXVsYXRp b24gc3Vic3lzdGVtIGFuZCB0aGUgZW1lcmdlbmN5IGNhbGwgYXR0ZW1wdCBpbiB0aGlzIGRvbWFp biBmYWlscyB0aGUgY2FsbCBpcyByZWplY3RlZCBhbmQgYW4gaW5kaWNhdGlvbiB0byB0cnkgYWdh aW4gZ2l2ZW4gdG8gdGhlIGNhbGxlci4NCg0KNC4yIFJlcXVpcmVtZW50cyBmb3IgYW4gUFNUTi9J U0ROIEVtdWxhdGlvbiBTdWJzeXN0ZW0gYW5kIFNpbXVsYXRpb24gc2VydmljZXMgaW4gdGhlIElN UyBwcm92aWRpbmcgRW1lcmdlbmN5IGNhbGxzDQoNCkEgUFNUTi9JU0ROIGVtdWxhdGlvbiBzdWJz eXN0ZW0gYW5kIHNpbXVsYXRpb24gc2VydmljZXMgaW4gdGhlIElNUyBzaGFsbCBzdXBwb3J0IHRo ZSBlbWVyZ2VuY3kgY29tbXVuaWNhdGlvbiBzZXJ2aWNlIGFzIGRlZmluZWQgaW4gU1IgMDAyIDE4 MCBbNF0uDQoNClRoaXMgY2xhdXNlIGRlYWxzIHdpdGggRW1lcmdlbmN5IFZvaWNlIHNlcnZpY2Vz IGFzIG1hbmRhdGVkIFsxXSBoZW5jZSB0aGUgUFNBUC9FQ0MgaXMgYXNzdW1lZCB0byBiZSBlaXRo ZXIgaW4gdGhlIFBTVE4vSVNETiBuZXR3b3JrIG9yIGF0IGxlYXN0IGludGVyLXdvcmtlZCB0byBi eSBhIE1lZGlhIGFuZCBib2FyZGVyIGdhdGV3YXlzLg0KDQo0LjMgUmVxdWlyZW1lbnRzIGZvciBh biBJTVMgU3Vic3lzdGVtIEVtZXJnZW5jeSBTZXNzaW9ucw0KDQpUaGlzIGNsYXVzZSBkZWFscyB3 aXRoIEV2b2x1dGlvbmFyeSBzZXJ2aWNlcyB3aGVyZSBFbWVyZ2VuY3kgc2Vzc2lvbnMgYXJlIGVz dGFibGlzaGVkIGZyb20gYSBTSVAgRW5hYmxlZCB0ZXJtaW5hbCB0byBhIFNJUCBlbmFibGVkIEVt ZXJnZW5jeSBDb250cm9sIENlbnRyZSwgdmlhIGEgU0lQIGVuYWJsZWQgUFNBUC4gV2hlcmUgdGhl IFNJUCBlbmFibGVkIFBTQVAgaXMgdmlld2VkIGFzIGEgU0lQIEFwcGxpY2F0aW9uIFNlcnZlciBp biB0aGUgSU1TOyB0aGUgUFNBUCBtYXkgc2VsZWN0IHRoZSBhcHByb3ByaWF0ZSBFQ0Mgb24gdGhl IGJhc2VzIG9uIHRoZSBzZXJ2aWNlIHJlcXVlc3RlZCBpbiB0aGUgU2Vzc2lvbiBSZXF1ZXN0IChl LmcuIHRoZSBTRFAgcGF5bG9hZCBpbiB0aGUgU0lQIElOVklURSkuIFdoZXJlIHRoZSBQU0FQIGlz IGFuIGVuaGFuY2VkIHRlcm1pbmF0aW9uIFNpbWlsYXItZm9yd2FyZGluZyBjYXBhYmlsaXRpZXMg bWF5IGJlIHByb3ZpZGVkIGJlZm9yZSBhbnkgb3B0aW1hbGx5IHJvdXRlZCBzdHJlYW1pbmcgbWVk aWEgaXMgZXN0YWJsaXNoZWQuDQoNClRoZSBzb2x1dGlvbiBmb3IgZW1lcmdlbmN5IHNlc3Npb25z IGluIHRoZSBJTVMgc3Vic3lzdGVtIHNoYWxsIGZ1bGZpbCB0aGUgZm9sbG93aW5nIGNhcGFiaWxp dHkgcmVxdWlyZW1lbnRzOg0KDQoxLiBJdCBzaG91bGQgYmUgaW5kZXBlbmRlbnQgZnJvbSB0aGUg dW5kZXJseWluZyBJUCBjb25uZWN0aXZpdHkgbmV0d29yayBpbiByZXNwZWN0IHRvIHRoZSBkZXRl Y3Rpb24gYW5kIHJvdXRpbmcgb2YgZW1lcmdlbmN5IHNlc3Npb25zLg0KDQoyLiBBbGwgZW1lcmdl bmN5IGNvbnRhY3QgaWRlbnRpZmllcnMsIChlLmcuIGVtZXJnZW5jeSBudW1iZXJzLCBTSVAgZW1l cmdlbmN5IFVSSXMpIGFuZCBhbnkgc3BlY2lhbCBpbmRpY2F0aW9ucyBmb3IgZW1lcmdlbmN5IHNl c3Npb25zIHdpdGhpbiB0aGUgU0lQIHNpZ25hbGxpbmcgbXVzdCBiZSBzdXBwb3J0ZWQgc3BlY2lm aWNhbGx5IElFVEYgcHJvcG9zYWxzIG9uIGFkZHJlc3Npbmcgc2hvdWxkIGJlIHRha2VuIGludG8g Y29uc2lkZXJhdGlvbi4NCg0KMy4gRW1lcmdlbmN5IHNlc3Npb25zIHNob3VsZCBoYXZlIHByaW9y aXR5IGFjY2VzcyB0byByZXNvdXJjZXMsIHdoZW4gdGhlIG5ldHdvcmsgcmVzb3VyY2VzIGFyZSB1 bmRlciBsb2FkLCBvdmVyICJvcmRpbmFyeSIgc2Vzc2lvbnMgYnkgdGhlIG5ldHdvcmsuDQoNCjQu IFNldC11cCBvZiBJTVMgZW1lcmdlbmN5IHNlc3Npb25zIHNoYWxsIGJlIHBvc3NpYmxlIGZvciB1 c2VycyB3aXRoIGEgYmFycmVkIHB1YmxpYyB1c2VyIGlkZW50aXR5Lg0KDQo1LiBUaGUgcHJpbWFy eSBzb2x1dGlvbiBzaGFsbCBiZSB0aGF0IHRoZSBOR04gVGVybWluYWwgd2lsbCBkZXRlY3QgYW4g aW5pdGlhdGlvbiBvZiBhbiBlbWVyZ2VuY3kgc2Vzc2lvbiAoZS5nLiBieSBldmFsdWF0aW5nIHRo ZSBTSVAtVVJJIG9yIHRoZSBkaWFsbGVkIG51bWJlcikgYnkgaXRzZWxmIGFuZCB0aGVuIGluZGlj YXRlcyB0aGUgZW1lcmdlbmN5IHNlc3Npb24gdG8gdGhlIG5ldHdvcmsuIA0KDQpIb3dldmVyIHRo ZSBOR04gc2hhbGwgYWxzbyBzdXBwb3J0IHRoZSBzY2VuYXJpbyB3aGVyZSB0aGUgTkdOIFRlcm1p bmFsIGNhbm5vdCBkZXRlY3QgYW4gaW5pdGlhdGlvbiBvZiBhbiBlbWVyZ2VuY3kgc2Vzc2lvbiwg dGhlbiB0aGUgTkdOIHNoYWxsIGJlIGFibGUgdG8gZGV0ZWN0IGFuZCBpbmRpY2F0ZSBhbiBlbWVy Z2VuY3kgc2Vzc2lvbiBpbiBwcm9ncmVzcy4NCg0KNi4gVGhlIE5HTiBtdXN0IGJlIGFibGUgdG8g c3VwcG9ydCB0aGUgc2NlbmFyaW8gd2hlcmUgdGhlIGF1dGhvcmlzYXRpb24gb2YgdGhlIE5HTiBU ZXJtaW5hbCB0byB0aGUgbmV0d29yayBpcyBhY2NvbXBsaXNoZWQgd2l0aCB0aGUgYWlkIG9mIGFu IElTSU0gbW9kdWxlLiBJbiB0aGlzIGNhc2UgdGhlIE5HTiBzaGFsbCBiZSBhYmxlIHRvIHNldC11 cCBhbiBlbWVyZ2VuY3kgc2Vzc2lvbiBpZiB0aGlzIGlkZW50aWZpY2F0aW9uIG1vZHVsZSBpcyBu b3QgcHJlc2VudC4gDQoNCjcuIEFuIEVtZXJnZW5jeSBTZXJ2aWNlIHNoYWxsIG5vdCBiZSBhIHN1 YnNjcmlwdGlvbiBzZXJ2aWNlIGFuZCB3aWxsIHRoZXJlZm9yZSBiZSBzdXBwb3J0ZWQgaW4gYSB2 aXNpdGVkIG5ldHdvcmsgYW5kIHByb3ZpZGVkIHdpdGhvdXQgaW50ZXJhY3Rpb24gd2l0aCBhICJI b21lIiBuZXR3b3JrIGZvciB0aGUgbm9tYWRpYyBjYXNlLiANCg0KOC4gRm9yIHRoZSBub21hZGlj aXR5IHNjZW5hcmlvIHdoZXJlIGFuIGVtZXJnZW5jeSBzZXNzaW9uIHJlcXVlc3QgaXMgcm91dGVk IHZpYSB0aGUgaG9tZSBuZXR3b3JrLCB0aGUgaG9tZSBuZXR3b3JrIHNoYWxsIGJlIGFibGUgdG8g ZGV0ZWN0IHRoYXQgdGhlIHNlc3Npb24gaXMgZm9yIGVtZXJnZW5jeSBzZXJ2aWNlICh3aGV0aGVy IGluZGljYXRlZCBvciBub3QpIGFuZCByZXNwb25kIHRvIHRoZSBOR04gVGVybWluYWwgaW5kaWNh dGluZyB0aGF0IHRoZSBOR04gVGVybWluYWwgc2hvdWxkIGluaXRpYXRlIGFuIGVtZXJnZW5jeSBz ZXNzaW9uIGluIHRoZSB2aXNpdGVkIG5ldHdvcmsuDQoNCkFsdGVybmF0aXZlbHkgdGhlIHZpc2l0 ZWQgbmV0d29yayBtYXkgYmUgYWJsZSB0byBkZXRlY3QgdGhhdCB0aGUgc2Vzc2lvbiByZXF1ZXN0 IGlzIGZvciBhbiBlbWVyZ2VuY3kgc2Vzc2lvbiAod2hldGhlciBpbmRpY2F0ZWQgb3Igbm90KWFu ZCByb3V0ZSB0byBzZXNzaW9uIHRvIHRoZSBhcHByb3ByaWF0ZSBQU0FQL0VDQy4NCg0KOS4gVGhl IExvY2F0aW9uIG9mIHRoZSBjYWxsZXIgdG8gdGhlIHNlc3Npb24gZXN0YWJsaXNobWVudCBzaGFs bCBiZSBzdXBwb3J0ZWQgYWNjb3JkaW5nIHRvIGNsYXVzZSA0LjEuMiBhYm92ZSBpbiBhY2NvcmRh bmNlIHdpdGggdGhlIEVVIERpcmVjdGl2ZXMgWzJdIGFuZCBbM10uDQoNCjEwLiBQU0FQcy9FbWVy Z2VuY3kgY29udHJvbCBjZW50cmVzIHNoYWxsIGJlIGNvbm5lY3RlZCB0byB0aGUgUFNUTi9JU0RO IGVtdWxhdGlvbiBkb21haW4sIGhvd2V2ZXIgdGhlIGVtZXJnZW5jeSBjZW50cmUgbWF5IGFsc28g YmUgY29ubmVjdGVkIHRvIHRoZSBJTVMgZG9tYWluIG9yIGFueSBvdGhlciBwYWNrZXQgbmV0d29y ay4NCg0KMTEuIFBTQVBzL0VtZXJnZW5jeSBjb250cm9sIGNlbnRyZXMgc2hhbGwgYmUgYWJsZSB0 byBjYWxsIGJhY2sgdGhlIHVzZXIsIGlmIGEgQ0xJIGlzIHByb3ZpZGVkIG9yIElTSU0gaXMgdXNl ZCB0byBhdXRoZW50aWNhdGUgdGhlIHVzZXIuIEluIHRoZSBJU0lNLWxlc3MgU2ltdWxhdGlvbiBD YXNlIHRoaXMgbWF5IG5vdCBiZSBwb3NzaWJsZS4NCg0KMTIuIFRoZSB2aXNpdGVkIG5ldHdvcmsg c2hhbGwgYmUgYWJsZSB0byBkb3dubG9hZCBlbWVyZ2VuY3kgbnVtYmVycyANCnRvIHRoZSBOR04g VGVybWluYWwgdXNpbmcgcHJvY2VkdXJlcyBhcyBkZXNjcmliZWQgaW4gVFMgMjQuMDA4IFs1XSwg aW4gb3JkZXIgdG8gZW5zdXJlIHRoYXQgbG9jYWwgZW1lcmdlbmN5IG51bWJlcnMgYXJlIGtub3du IHRvIHRoZSBOR04gVGVybWluYWwuICANCg0KNC40IEVtZXJnZW5jeSBDYWxscyBpbiB0aGUgUFMg Q04gRG9tYWluDQoNCldpdGhvdXQgdGhlIElNIENOIHN1YnN5c3RlbSwgZW1lcmdlbmN5IGNhbGxz IGFyZSBub3Qgc3VwcG9ydGVkIGluIHRoZSBQUyBDTiBkb21haW4uDQoNCjQuNSBFbWVyZ2VuY3kg Q2FsbHMgd2hlbiBBdHRhY2hlZCB2aWEgYW4gSS1XTEFODQoNCkFueSBhdHRlbXB0IHRvIG1ha2Ug YW4gZW1lcmdlbmN5IGNhbGwgc2hhbGwgYmUgaGFuZGxlZCBhcyBkZWZpbmVkIGZvciBhIFBTIENO IGRvbWFpbiBuZXR3b3JrIGluIGNsYXVzZSA0LjQgYWJvdmUuDQoNCjQuNglBcmNoaXRlY3R1cmUg cmVxdWlyZW1lbnRzDQoNClRoZSBzb2x1dGlvbiBmb3IgZW1lcmdlbmN5IHNlc3Npb25zIHNoYWxs IGFsc28gZnVsZmlsIHRoZSBmb2xsb3dpbmcgYXJjaGl0ZWN0dXJhbCByZXF1aXJlbWVudHM6DQoN CjEuCVRoZSBhcmNoaXRlY3R1cmUgZm9yIEVtZXJnZW5jeSBTZXJ2aWNlIHNob3VsZCBiZSBkcml2 ZW4gYnkgdGhlIHNwZWNpZmljIGNhcGFiaWxpdGllcyByZXF1aXJlbWVudHMuIFNwZWNpZmljYXRp b24gc2hvdWxkIG1pbmltaXNlIHRoZSBjaGFuZ2VzIHRvIGV4aXN0aW5nIDNHUFAgSU1TIGFyY2hp dGVjdHVyZSBhbmQgcHJvY2VkdXJlcywgYW5kIHJlLXVzZSBleGlzdGluZyAzR1BQIElNUyBmdW5j dGlvbmFsIGVudGl0aWVzLiBIb3dldmVyIHRoZSBzcGVjaWZpY2F0aW9uIHNob3VsZCBub3QgYmUg Y29uc3RyYWluZWQgYnkgdGhlIGV4aXN0aW5nIGZ1bmN0aW9uYWwgZW50aXRpZXMuDQoNCjIuIFRo ZSBhcmNoaXRlY3R1cmUgc2hvdWxkIHRha2UgaW50byBhY2NvdW50IHRoYXQgaXQgbWF5IGJlIHBv c3NpYmxlIHRvIG1ha2UgZW1lcmdlbmN5IGNhbGxzIG9uIG90aGVyIG1lZGlhIHRoYW4gdm9pY2Uu IEl0IG5lZWRzIHRvIHRha2UgYWNjb3VudCBzdXBwb3J0LCBmb3IgZXhhbXBsZSwgdGhlIGRlYWYg YW5kIGhlYXJpbmctaW1wYWlyZWQgdXNpbmcgYSB0ZXh0IHBob25lIHRoYXQgbWlnaHQgZ2VuZXJh dGUgaW5mb3JtYXRpb24sIGZvciBleGFtcGxlLCB1c2luZyBwcm9jZWR1cmVzIGZvciBNdWx0aW1l ZGlhIHNlcnZpY2VzIG9yIHRoZSAzR1BQIEluc3RhbnQgTWVzc2FnaW5nIFNlcnZpY2UgYmFzZWQg b24gdGhlIDNHUFAgSU1TIG9yIHRoZSBGLU1NUyBtZXNzYWdpbmcgcHJvY2VkdXJlcy4gVGhlcmUg bWF5IGFsc28gYmUgYSBuZWVkIHRvIHdvcmsgd2l0aCBwaG9uZXMgdGhhdCBhdHRlbXB0IHRoZSBl bWVyZ2VuY3kgY2FsbCBhcyBhIHZpZGVvIHRlbGVwaG9ueSBjYWxsLg0KDQozLiBUaGUgYXJjaGl0 ZWN0dXJlIHNob3VsZCBzdXBwb3J0IHRoZSBldm9sdXRpb24gb2YgUFNBUHMvRW1lcmdlbmN5IENv bnRyb2wgQ2VudHJlcyBmcm9tIHRlcm1pbmF0aW5nIGFjY2VzcyB0byB0aGUgUFNUTi9JU0ROLCB0 byBkaXJlY3QgaW50ZXItd29ya2luZyB2aWEgTWVkaWEgYW5kIGJvYXJkZXIgZ2F0ZXdheXMsIHRv IHRoZSBjYXNlIHdoZXJlIHRoZXkgYXJlIHBhcnQgb2YgdGhlIFNJUCBpbmZyYXN0cnVjdHVyZS4g QWxsb3dpbmcgdGhlIGNhc2UgdGhhdCBub3QgYWxsIFBTQVBzL0VDQyB3aWxsIG1pZ3JhdGUgYXQg dGhlIHNhbWUgdGltZS4gTGVnYWN5IEVDQyB3aXRoIEVuaGFuY2VkIElTRE4gYWNjZXNzIG9ubHkg bWF5IHBlcnNpc3QgZm9yIHNvbWUgdGltZS4NCg0KNC4gU2VydmljZSBJbnRlci13b3JraW5nIGlz IGFuIGltcG9ydGFudCBjb25zaWRlcmF0aW9uIGlmIGEgU0lQIGF3YXJlIHRlcm1pbmFsIHBsYWNl cyBhIG11bHRpbWVkaWEsIE1NUyBvciBJbnN0YW50IG1lc3NhZ2UgRW1lcmdlbmN5IHNlc3Npb24g dG8gYW4gUFNBUC9FQ0MgdGhhdCBvbmx5IHN1cHBvcnRzIElTRE4gdm9pY2UuIFJlamVjdGlvbiBv ciBmYWxsYmFjayBjb25zaWRlcmF0aW9ucyB3aWxsIGJlIHNlcmlvdXMuIC4gDQoNCjQuNwlQcm90 b2NvbCAmIFNlY3VyaXR5IHJlcXVpcmVtZW50cw0KDQpUaGUgZm9sbG93aW5nIGlzc3VlcyBoYXZl IGJlZW4gaWRlbnRpZmllZCBhcyByZXF1aXJlbWVudHMgdGhhdCBuZWVkIGEgc29sdXRpb24gZm9y IHRoZSBzdXBwb3J0IG9mIFZvSVAgVGVjaG5vbG9neS4gSXQgaGFzIGJlZW4gaWRlbnRpZmllZCB0 aGF0IHRoZSBmb2xsb3dpbmcgcG9zc2libGUgbGltaXRhdGlvbnMgZm9yIHRoZSBzdXBwb3J0IG9m IEVtZXJnZW5jeSBWb2ljZSBTZXJ2aWNlcyAoZS5nLiBFMTEyIGFuZCBTT1MgU0lQIFVSSXMgbXVz dCBiZSBhbGxldmlhdGVkLiBUaGVzZSBpc3N1ZXMgaW5jbHVkZToNCg0KKiBSZWxpYWJpbGl0eSBv ZiBsb2NhdGlvbiBpbmZvcm1hdGlvbg0KKiBBdXRoZW50aWNhdGlvbiBvZiBjYWxsZXIgaWQgYW5k IGxvY2F0aW9uIHN0b3JlZCBpbiBhIE5HTiBUZXJtaW5hbA0KKiBNb25pdG9yIGFuZCB2YWxpZGF0 ZSAoMSkgdGVybWluYWwgc3ludGF0aWNhbCBiZWhhdm9pdXIgKDIpIGFuZCBuZXR3b3JrIGJlaGFi aW91ciBvbiBkZW5pYWwgb2Ygc2VydmljZSBhdHRhY2tzIGFuZCBtaXRpZ2F0ZSBhZ2FpbnN0IHRo ZSBlZmZlY3RzIG9mIGFmb3JlbWVudGlvbmVkIGJlaGF2aW91ci4NCiogVlBOIGFjY2VzcyBwcm9i bGVtOg0KCW8gR2xvYmFsbHkgYWNjZXNzaWJsZSByb3V0aW5nDQoJbyBTZWN1cmUgcm91dGluZyBn bG9iYWxseQ0KKiBFbnRlcnByaXNlIERIQ1Agc2VydmVyIGZvciBsb2NhdGlvbiBpbmZvcm1hdGlv biAocHJpdmF0ZSkNCiogUmVzaWRlbnRpYWwgREhDUCBpc3N1ZXMNCiogT3ZlcmhlYWQgb2Ygb3Jn YW5pc2F0aW9ucyB0aGF0IHByb3ZpZGUgYWNjZXNzIHRvIHB1YmxpYyBFbWVyZ2VuY3kgVm9pY2Ug U2VydmljZXMgKGUuZy4gRTExMikNCiogR2xvYmFsL2ludGVybmF0aW9uYWwgcmVndWxhdGlvbg0K KiBQU0FQIHJlY29ubmVjdCBjYXBhYmlsaXR5DQoNCg== ------_=_NextPart_001_01C524F6.25A6DABC Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C524F6.25A6DABC-- From ecrit-bounces@ietf.org Mon Mar 21 04:40:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09686; Mon, 21 Mar 2005 04:40:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDJUC-0007hb-L8; Mon, 21 Mar 2005 04:46:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDJOo-0007wq-FH; Mon, 21 Mar 2005 04:40:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDJOm-0007wi-UN for ecrit@megatron.ietf.org; Mon, 21 Mar 2005 04:40:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09634 for ; Mon, 21 Mar 2005 04:40:34 -0500 (EST) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDJTn-0007gT-T0 for ecrit@ietf.org; Mon, 21 Mar 2005 04:45:49 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j2L9eX2C009928 for ; Mon, 21 Mar 2005 10:40:33 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j2L9eX4w007130 for ; Mon, 21 Mar 2005 10:40:33 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 21 Mar 2005 10:40:33 +0100 Message-ID: From: Tschofenig Hannes To: ecrit@ietf.org Date: Mon, 21 Mar 2005 10:38:35 +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: 7bac9cb154eb5790ae3b2913587a40de Subject: [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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c hi all, please find a first version of the meeting minutes at: http://www.ietf-ecrit.org/IETF62/ please let us know if you would like to see something changed, added or deleted. ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 22 13:21:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14450; Tue, 22 Mar 2005 13:21:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDo5h-0006MF-My; Tue, 22 Mar 2005 13:26:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDnyI-0004p0-9N; Tue, 22 Mar 2005 13:19:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDnyG-0004oo-Az for ecrit@megatron.ietf.org; Tue, 22 Mar 2005 13:19:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14207 for ; Tue, 22 Mar 2005 13:19:13 -0500 (EST) Message-Id: <200503221819.NAA14207@ietf.org> Received: from athena.hosts.co.uk ([212.84.175.19]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDo3V-0006FH-8r for ecrit@ietf.org; Tue, 22 Mar 2005 13:24:42 -0500 Received: from [69.138.71.61] (helo=albers) by athena.hosts.co.uk with esmtpa (Exim 4.44) id 1DDny2-0007oM-02 for ecrit@ietf.org; Tue, 22 Mar 2005 18:19:03 +0000 From: "Ken Carlberg" To: Date: Tue, 22 Mar 2005 13:18:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcUvC4oGrj1ZKKVjTmK/9QTG86TUnQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [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 X-Spam-Score: 0.9 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit At the minneapolis-IETF, there were several presentations on proposed requirements that pertain to the ECRIT charter. in addition, a person in the audience thought that prioritization should be part of the effort...at which point several people seemed to run to the microphone to say words to the effect of "no, that is definitely not going to be the case for ECRIT" since this subject of prioritization also came up at the washinton-ietf, I was wondering if it may be worthwhile advocating a statement in an ECRIT requirements document that *authorization* of the service by users is *not* a requirement. negative statements can be just as constructive as positive statements. the need for authorization is one way I tend distinguish efforts that fall within the scope of the IEPREP wg versus those that fall within ECRIT. perhaps stating this in the next version of a unified(?) requirements document may be helpful. -ken _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 22 16:16:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08099; Tue, 22 Mar 2005 16:16:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDqp1-0006QC-Cg; Tue, 22 Mar 2005 16:21:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDqWs-00018y-Vo; Tue, 22 Mar 2005 16:03:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDqWr-00018o-S1 for ecrit@megatron.ietf.org; Tue, 22 Mar 2005 16:03:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04098 for ; Tue, 22 Mar 2005 16:03:08 -0500 (EST) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDqcB-0004vL-KF for ecrit@ietf.org; Tue, 22 Mar 2005 16:08:41 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j2ML32b1032164; Tue, 22 Mar 2005 22:03:02 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j2ML32sC016038; Tue, 22 Mar 2005 22:03:02 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 22 Mar 2005 22:03:02 +0100 Message-ID: From: Tschofenig Hannes To: "'Ken Carlberg'" , ecrit@ietf.org Subject: AW: [Ecrit] requirements Date: Tue, 22 Mar 2005 22:01: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: e1e48a527f609d1be2bc8d8a70eb76cb 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa hi ken, > At the minneapolis-IETF, there were several presentations on proposed > requirements that pertain to the ECRIT charter. in addition, a person > in the audience thought that prioritization should be part of the > effort...at which point several people seemed to run to the microphone > to say words to the effect of "no, that is definitely not going to be > the case for ECRIT" > > since this subject of prioritization also came up at the > washinton-ietf, > I was wondering if it may be worthwhile advocating a statement in an > ECRIT requirements document that *authorization* of the > service by users > is *not* a requirement. negative statements can be just as > constructive > as positive statements. > > the need for authorization is one way I tend distinguish efforts that > fall within the scope of the IEPREP wg versus those that fall within > ECRIT. perhaps stating this in the next version of a unified(?) > requirements document may be helpful. authorization is a pretty broad term (and the same is true for "prioritization"). we came across a few authorization issues in our discussion at the ecrit working group meeting. maybe you can explain which requirement you would like to see being outside the scope of ecrit (or in scope for ieprep). ciao hannes > > -ken > > > _______________________________________________ > 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 Mar 23 08:57:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15668; Wed, 23 Mar 2005 08:57:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE6SG-0006lK-7h; Wed, 23 Mar 2005 09:03:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE6Lu-0008VB-QB; Wed, 23 Mar 2005 08:56:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE6Lt-0008Ux-4d for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 08:56:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15567 for ; Wed, 23 Mar 2005 08:56:51 -0500 (EST) Message-Id: <200503231356.IAA15567@ietf.org> Received: from athena.hosts.co.uk ([212.84.175.19]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE6RM-0006jA-2x for ecrit@ietf.org; Wed, 23 Mar 2005 09:02:33 -0500 Received: from [69.138.71.61] (helo=albers) by athena.hosts.co.uk with esmtpa (Exim 4.44) id 1DE6Lh-0000i5-Vu; Wed, 23 Mar 2005 13:56:43 +0000 From: "Ken Carlberg" To: "'Tschofenig Hannes'" , Subject: RE: [Ecrit] requirements Date: Wed, 23 Mar 2005 08:56:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUvIo9UTNrvMHMCTaa8FUzT8C96PgAhBMMQ In-Reply-To: X-Spam-Score: 0.1 (/) X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 X-Spam-Score: 0.9 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit > authorization is a pretty broad term (and the same is true for > "prioritization"). we came across a few authorization issues in our > discussion at the ecrit working group meeting. maybe you can explain which > requirement you would like to see being outside the scope of > ecrit (or in scope for ieprep). I would not agree that authorization is a broad term within the confines of the ietf, or for that matter the ecrit wg. authorization has specific meanings within the IETF (rfc-2906, AAA Authorization requirements is probably a good reference point). But the point is taken that *how* authorization is applied within ecrit should be more specific. I don't recall authorization issues being brought up at the last meeting. There were discussions about authentication and integrity with respect to location information, both those are different beasts. just to loosely recap from my previous message, I think it would be beneficial in one of the requirements documents to state something to the effect that "solutions must not require authorization by (end) users to access 911/999/112-type services". The keyword of "must" versus "should" is something I'd leave to the prospective author(s). -ken _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 23 09:33:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19372; Wed, 23 Mar 2005 09:33:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE70r-0007kT-6e; Wed, 23 Mar 2005 09:39:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE6uH-000685-NR; Wed, 23 Mar 2005 09:32:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE6uG-000680-Sd for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 09:32:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19221 for ; Wed, 23 Mar 2005 09:32:23 -0500 (EST) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE6zk-0007ia-SJ for ecrit@ietf.org; Wed, 23 Mar 2005 09:38:05 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j2NEWKY6029048; Wed, 23 Mar 2005 15:32:20 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j2NEWKqY010126; Wed, 23 Mar 2005 15:32:20 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Mar 2005 15:32:20 +0100 Message-ID: From: Tschofenig Hannes To: "'Ken Carlberg'" , ecrit@ietf.org Subject: AW: [Ecrit] requirements Date: Wed, 23 Mar 2005 15:30:18 +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: d8ae4fd88fcaf47c1a71c804d04f413d 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 hi ken, please see my comment inline: > > authorization is a pretty broad term (and the same is true for > > "prioritization"). we came across a few authorization issues in our > > discussion at the ecrit working group meeting. maybe you > can explain which > > requirement you would like to see being outside the scope of > > ecrit (or in scope for ieprep). > > I would not agree that authorization is a broad term within > the confines > of the ietf, or for that matter the ecrit wg. authorization > has specific > meanings within the IETF (rfc-2906, AAA Authorization requirements is > probably a good reference point). But the point is taken that *how* > authorization is applied within ecrit should be more specific. > > I don't recall authorization issues being brought up at the > last meeting. > There were discussions about authentication and integrity > with respect to > location information, both those are different beasts. i should have been more specific. you might remember the presentation by james about validation of location information. he pointed out that access network provides location information to the end host in such a way that the emergency response center is able to verify that a "trusted" access network created the object and (maybe that this network is indeed reponsible for the area). we had some further discussions about this issue in the geopriv working group. i also consider this as part of the authorization decision. there are still a number of issues that need to be investigated and discussed (and i am not sure that i understood all aspects; the same is probably true for other folks as well). > > just to loosely recap from my previous message, I think it would be > beneficial in one of the requirements documents to state something to > the effect that "solutions must not require authorization by (end) > users to access 911/999/112-type services". there will not be a 'must be authenticated' and 'must be authorized' requirement for 911/etc. calls (what we have heard so far in the discussions). we have also heard that the treatment of emergency calls will be different depending on the provided atttributes. some calls are better than others. if you receive a call that does not contain location information nor the identity of the calling party then you need to give it special treatment. some of these attributes, such as the assertion mentioned above, can be used to compute an authorization decision. we should also discuss what the meaning of the authorization decision in the context you mention (rfc 2906) is. do you think about 'user x is subscribed i.e. was successfully authenticated' or 'user x has sufficient funds' or 'user x is within a specific geographical area' etc. i think that most people do not make an assumption about authorization in this particular area. i would like to know what type of authorization the ieprep folks consider. The keyword of "must" > versus "should" is something I'd leave to the prospective author(s). > ciao \hannes > -ken > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 23 11:21:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02054; Wed, 23 Mar 2005 11:21:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE8hQ-0002Mx-BC; Wed, 23 Mar 2005 11:27:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE8Wd-0005vb-HE; Wed, 23 Mar 2005 11:16:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE8Wc-0005uC-7j for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 11:16:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01341 for ; Wed, 23 Mar 2005 11:16:03 -0500 (EST) Message-Id: <200503231616.LAA01341@ietf.org> Received: from athena.hosts.co.uk ([212.84.175.19]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE8c6-0002DX-Dx for ecrit@ietf.org; Wed, 23 Mar 2005 11:21:47 -0500 Received: from [69.138.71.61] (helo=albers) by athena.hosts.co.uk with esmtpa (Exim 4.44) id 1DE8WS-0004T3-T7; Wed, 23 Mar 2005 16:15:57 +0000 From: "Ken Carlberg" To: "'Tschofenig Hannes'" , Subject: RE: [Ecrit] requirements Date: Wed, 23 Mar 2005 11:15:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUvtSEMdBefsIsCRauVJ7J63SEP6wACmYFA In-Reply-To: X-Spam-Score: 0.1 (/) X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 X-Spam-Score: 0.9 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit > you might remember the presentation by james about validation of location > information. he pointed out that access network provides location > information to the end host in such a way that the emergency response center > is able to verify that a "trusted" access network created the object and > (maybe that this network is indeed reponsible for the area). James may correct me, but I would say that the scenario you paint above is one of authentication and integrity in the "validation of location information". I would not consider that a case of authorization, since I bind that security component with usage of a service. we may have to chalk this up as a case of agreeing to disagree. > we had some further discussions about this issue in the geopriv working > group. i also consider this as part of the authorization decision. > there are still a number of issues that need to be investigated and > discussed (and i am not sure that i understood all aspects; > the same is probably true for other folks as well). I have not been following geopriv as closely as I should have, so I can't comment on this. > there will not be a 'must be authenticated' and 'must be authorized' > requirement for 911/etc. calls (what we have heard so far in the > discussions). well, my personal feeling is that users and information should be authenticated to offer a measure confidence to others as to the validity of the user and/or the information (eg, location info) being provided. > we should also discuss what the meaning of the authorization decision in the > context you mention (rfc 2906) is. do you think about 'user x is subscribed > i.e. was successfully authenticated' or 'user x has sufficient funds' or > 'user x is within a specific geographical area' etc. > > i think that most people do not make an assumption about authorization in > this particular area. i would like to know what type of authorization the > ieprep folks consider. in my view, you are mixing components of security. a service is potentialy authorized and information in potentially authenticated -- I say potentially because the security portion may not be deployed. I'm probably being very picky in my terminology, but I would say that ieprep does not consider a "type of authentication" because that would correlate to a solution, which is not in the current charter of ieprep. rfc-3689 from ieprep provides some general requirements with respect to authorization/integrity/authentication, but the rfc is only a baseline starting point from which more specific requirements can be defined within that group. it can be debated how effective this approach was, but that was the direction we took at the time. -ken _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 23 11:30:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02906; Wed, 23 Mar 2005 11:30:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE8q6-0002Z7-O7; Wed, 23 Mar 2005 11:36:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE8im-0007ZO-RO; Wed, 23 Mar 2005 11:28:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE8ik-0007V8-Kr for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 11:28:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02553 for ; Wed, 23 Mar 2005 11:28:36 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE8oE-0002Vh-GX for ecrit@ietf.org; Wed, 23 Mar 2005 11:34:20 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j2NGSMV2011498; Wed, 23 Mar 2005 10:28:22 -0600 (CST) Received: from jrrosenberg-2.lucent.com (jrrosenberg-2.ih.lucent.com [135.185.234.35]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j2NGSLB22792; Wed, 23 Mar 2005 10:28:21 -0600 (CST) Message-Id: <6.2.1.2.0.20050323102243.03f7c290@ihmail.ih.lucent.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 23 Mar 2005 10:28:10 -0600 To: "Ken Carlberg" , "'Tschofenig Hannes'" , From: John Rosenberg Subject: RE: [Ecrit] requirements In-Reply-To: <200503231616.LAA01341@ietf.org> References: <200503231616.LAA01341@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 All - I think the basic question being asked deals with two (or more) different flavors under the umbrella of Emergency Services. Two existing examples are: o B/E911 in the US - does not require that the "caller" be authorized, or even identified (most 911 systems today are required to provide anonymous access); o GETS (Government Emergency Telecommunications Service) in the US, which can only be used by authorized users - uses PIN mechanism something like a calling card to allow the caller to authenticate. I think the original e-mail was asking for a specific requirement for ecrit (911 service domain) stating that "caller" MUST NOT be required to be pre-authorized or to have to authenticate in order to place an emergency service (e.g. 911-type) call. John ------------------------ John Rosenberg Lucent Technologies LSS Core Product Mgmt LSS Emergency Services, GETS, & Regulatory Features Product Mgmt 630-713-7162 jrrosenberg@lucent.com At 10:15 AM 3/23/2005, Ken Carlberg wrote: >> you might remember the presentation by james about validation of location >> information. he pointed out that access network provides location >> information to the end host in such a way that the emergency response center >> is able to verify that a "trusted" access network created the object and >> (maybe that this network is indeed reponsible for the area). > >James may correct me, but I would say that the scenario you paint above >is one of authentication and integrity in the "validation of location >information". I would not consider that a case of authorization, since >I bind that security component with usage of a service. we may have to >chalk this up as a case of agreeing to disagree. > >> we had some further discussions about this issue in the geopriv working >> group. i also consider this as part of the authorization decision. >> there are still a number of issues that need to be investigated and >> discussed (and i am not sure that i understood all aspects; >> the same is probably true for other folks as well). > >I have not been following geopriv as closely as I should have, so I can't >comment on this. > >> there will not be a 'must be authenticated' and 'must be authorized' >> requirement for 911/etc. calls (what we have heard so far in the >> discussions). > >well, my personal feeling is that users and information should be >authenticated to offer a measure confidence to others as to the >validity of the user and/or the information (eg, location info) >being provided. > >> we should also discuss what the meaning of the authorization decision in the >> context you mention (rfc 2906) is. do you think about 'user x is subscribed >> i.e. was successfully authenticated' or 'user x has sufficient funds' or >> 'user x is within a specific geographical area' etc. >> >> i think that most people do not make an assumption about authorization in >> this particular area. i would like to know what type of authorization the >> ieprep folks consider. > >in my view, you are mixing components of security. a service is >potentialy authorized and information in potentially authenticated >-- I say potentially because the security portion may not be deployed. > >I'm probably being very picky in my terminology, but I would say that >ieprep does not consider a "type of authentication" because that would >correlate to a solution, which is not in the current charter of ieprep. > >rfc-3689 from ieprep provides some general requirements with respect >to authorization/integrity/authentication, but the rfc is only a >baseline starting point from which more specific requirements can >be defined within that group. it can be debated how effective this >approach was, but that was the direction we took at the time. > >-ken > > > > >_______________________________________________ >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 Mar 23 11:55:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05980; Wed, 23 Mar 2005 11:55:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9Ec-0003M9-BX; Wed, 23 Mar 2005 12:01:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE98Z-0002xe-0o; Wed, 23 Mar 2005 11:55:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE8xI-0001Mj-4N for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 11:43:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04819 for ; Wed, 23 Mar 2005 11:43:37 -0500 (EST) Received: from ns2.sccx.com ([209.108.197.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE92m-00031Q-3m for ecrit@ietf.org; Wed, 23 Mar 2005 11:49:20 -0500 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] requirements X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 23 Mar 2005 10:38:57 -0600 Message-ID: <422D410BD61FC04185076AD99AA7207A4709CB@inilmx01.lgmt.trdo> Thread-Topic: [Ecrit] requirements Thread-Index: AcUvxWM/8n4FXFoiRyaudp6bFOlnXQAAWuAX From: "Ciesla, Larry" To: , , , X-OriginalArrivalTime: 23 Mar 2005 16:38:58.0548 (UTC) FILETIME=[CFC0DB40:01C52FC6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 23 Mar 2005 11:55:17 -0500 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: quoted-printable In fact, a user does not even need paid phone service for 911 to work = today. Both wireline and wireless phones will allow 911 to work for = unsubscribed phones. Perhaps the notion of authorization should be = viewed in the context that the entity assigning location information to = a phone should be authorized to do so.=20 Regards Larry Ciesla ***This message has been sent via the Intrado Wireless Information = Network.*** -----Original Message----- From: ecrit-bounces@ietf.org To: Ken Carlberg ; 'Tschofenig Hannes' = ; ecrit@ietf.org Sent: Wed Mar 23 09:28:10 2005 Subject: RE: [Ecrit] requirements All - I think the basic question being asked deals with two (or more) = different=20 flavors under the umbrella of Emergency Services. Two existing examples = are: o B/E911 in the US - does not require that the "caller" be authorized, = or=20 even identified (most 911 systems today are required to provide = anonymous=20 access); o GETS (Government Emergency Telecommunications Service) in the US, = which=20 can only be used by authorized users - uses PIN mechanism something like = a=20 calling card to allow the caller to authenticate. I think the original e-mail was asking for a specific requirement for = ecrit=20 (911 service domain) stating that "caller" MUST NOT be required to be=20 pre-authorized or to have to authenticate in order to place an emergency = service (e.g. 911-type) call. John ------------------------ John Rosenberg Lucent Technologies LSS Core Product Mgmt LSS Emergency Services, GETS, & Regulatory Features Product Mgmt 630-713-7162 jrrosenberg@lucent.com At 10:15 AM 3/23/2005, Ken Carlberg wrote: >> you might remember the presentation by james about validation of = location >> information. he pointed out that access network provides location >> information to the end host in such a way that the emergency = response=20 center >> is able to verify that a "trusted" access network created the object = and >> (maybe that this network is indeed reponsible for the area). > >James may correct me, but I would say that the scenario you paint = above >is one of authentication and integrity in the "validation of location >information". I would not consider that a case of authorization, = since >I bind that security component with usage of a service. we may have = to >chalk this up as a case of agreeing to disagree. > >> we had some further discussions about this issue in the geopriv = working >> group. i also consider this as part of the authorization decision. >> there are still a number of issues that need to be investigated and >> discussed (and i am not sure that i understood all aspects; >> the same is probably true for other folks as well). > >I have not been following geopriv as closely as I should have, so I = can't >comment on this. > >> there will not be a 'must be authenticated' and 'must be authorized' >> requirement for 911/etc. calls (what we have heard so far in the >> discussions). > >well, my personal feeling is that users and information should be >authenticated to offer a measure confidence to others as to the >validity of the user and/or the information (eg, location info) >being provided. > >> we should also discuss what the meaning of the authorization = decision=20 in the >> context you mention (rfc 2906) is. do you think about 'user x is = subscribed >> i.e. was successfully authenticated' or 'user x has sufficient = funds' or >> 'user x is within a specific geographical area' etc. >> >> i think that most people do not make an assumption about = authorization in >> this particular area. i would like to know what type of = authorization the >> ieprep folks consider. > >in my view, you are mixing components of security. a service is >potentialy authorized and information in potentially authenticated >-- I say potentially because the security portion may not be deployed. > >I'm probably being very picky in my terminology, but I would say that >ieprep does not consider a "type of authentication" because that would >correlate to a solution, which is not in the current charter of = ieprep. > >rfc-3689 from ieprep provides some general requirements with respect >to authorization/integrity/authentication, but the rfc is only a >baseline starting point from which more specific requirements can >be defined within that group. it can be debated how effective this >approach was, but that was the direction we took at the time. > >-ken > > > > >_______________________________________________ >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 Mar 23 12:17:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08492; Wed, 23 Mar 2005 12:17:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9Zf-00048B-Qc; Wed, 23 Mar 2005 12:23:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9TY-0006FA-9R; Wed, 23 Mar 2005 12:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9TX-0006Ez-Ro for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 12:16:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08367 for ; Wed, 23 Mar 2005 12:16:57 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9Z3-00044o-3Z for ecrit@ietf.org; Wed, 23 Mar 2005 12:22:41 -0500 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 j2NHGcP08782; Wed, 23 Mar 2005 11:16:39 -0600 (CST) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Mar 2005 04:16:38 +1100 Message-ID: From: "James Winterbottom" To: "Ciesla, Larry" , ecrit@ietf.org Subject: RE: [Ecrit] requirements Date: Thu, 24 Mar 2005 04:16:38 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c 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="===============0444740450==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b 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. --===============0444740450== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52FCC.1281357E" 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_01C52FCC.1281357E Content-Type: text/plain Larry, That is the definition that I have been using. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Ciesla, Larry Sent: Thursday, 24 March 2005 3:39 AM To: jrrosenberg@lucent.com; carlberg@g11.org.uk; hannes.tschofenig@siemens.com; ecrit@ietf.org Subject: Re: [Ecrit] requirements In fact, a user does not even need paid phone service for 911 to work today. Both wireline and wireless phones will allow 911 to work for unsubscribed phones. Perhaps the notion of authorization should be viewed in the context that the entity assigning location information to a phone should be authorized to do so. Regards Larry Ciesla ***This message has been sent via the Intrado Wireless Information Network.*** -----Original Message----- From: ecrit-bounces@ietf.org To: Ken Carlberg ; 'Tschofenig Hannes' ; ecrit@ietf.org Sent: Wed Mar 23 09:28:10 2005 Subject: RE: [Ecrit] requirements All - I think the basic question being asked deals with two (or more) different flavors under the umbrella of Emergency Services. Two existing examples are: o B/E911 in the US - does not require that the "caller" be authorized, or even identified (most 911 systems today are required to provide anonymous access); o GETS (Government Emergency Telecommunications Service) in the US, which can only be used by authorized users - uses PIN mechanism something like a calling card to allow the caller to authenticate. I think the original e-mail was asking for a specific requirement for ecrit (911 service domain) stating that "caller" MUST NOT be required to be pre-authorized or to have to authenticate in order to place an emergency service (e.g. 911-type) call. John ------------------------ John Rosenberg Lucent Technologies LSS Core Product Mgmt LSS Emergency Services, GETS, & Regulatory Features Product Mgmt 630-713-7162 jrrosenberg@lucent.com At 10:15 AM 3/23/2005, Ken Carlberg wrote: >> you might remember the presentation by james about validation of location >> information. he pointed out that access network provides location >> information to the end host in such a way that the emergency response center >> is able to verify that a "trusted" access network created the object and >> (maybe that this network is indeed reponsible for the area). > >James may correct me, but I would say that the scenario you paint above >is one of authentication and integrity in the "validation of location >information". I would not consider that a case of authorization, since >I bind that security component with usage of a service. we may have to >chalk this up as a case of agreeing to disagree. > >> we had some further discussions about this issue in the geopriv working >> group. i also consider this as part of the authorization decision. >> there are still a number of issues that need to be investigated and >> discussed (and i am not sure that i understood all aspects; >> the same is probably true for other folks as well). > >I have not been following geopriv as closely as I should have, so I can't >comment on this. > >> there will not be a 'must be authenticated' and 'must be authorized' >> requirement for 911/etc. calls (what we have heard so far in the >> discussions). > >well, my personal feeling is that users and information should be >authenticated to offer a measure confidence to others as to the >validity of the user and/or the information (eg, location info) >being provided. > >> we should also discuss what the meaning of the authorization decision in the >> context you mention (rfc 2906) is. do you think about 'user x is subscribed >> i.e. was successfully authenticated' or 'user x has sufficient funds' or >> 'user x is within a specific geographical area' etc. >> >> i think that most people do not make an assumption about authorization in >> this particular area. i would like to know what type of authorization the >> ieprep folks consider. > >in my view, you are mixing components of security. a service is >potentialy authorized and information in potentially authenticated >-- I say potentially because the security portion may not be deployed. > >I'm probably being very picky in my terminology, but I would say that >ieprep does not consider a "type of authentication" because that would >correlate to a solution, which is not in the current charter of ieprep. > >rfc-3689 from ieprep provides some general requirements with respect >to authorization/integrity/authentication, but the rfc is only a >baseline starting point from which more specific requirements can >be defined within that group. it can be debated how effective this >approach was, but that was the direction we took at the time. > >-ken > > > > >_______________________________________________ >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 ------_=_NextPart_001_01C52FCC.1281357E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Ecrit] requirements

Larry,

That is the definition that I have been using.

Cheers
James

-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf Of Ciesla, Larry
Sent: Thursday, 24 March 2005 3:39 AM
To: jrrosenberg@lucent.com; carlberg@g11.org.uk; = hannes.tschofenig@siemens.com; ecrit@ietf.org
Subject: Re: [Ecrit] requirements


In fact, a user does not even need paid phone service = for 911 to work today. Both wireline and wireless phones will allow 911 = to work for unsubscribed phones.  Perhaps the notion of = authorization should be viewed in the context that the entity assigning = location information to a phone should be authorized to do so. =

Regards

Larry Ciesla



***This message has been sent via the Intrado = Wireless Information Network.***

-----Original Message-----
From: ecrit-bounces@ietf.org = <ecrit-bounces@ietf.org>
To: Ken Carlberg <carlberg@g11.org.uk>; = 'Tschofenig Hannes' <hannes.tschofenig@siemens.com>; = ecrit@ietf.org <ecrit@ietf.org>

Sent: Wed Mar 23 09:28:10 2005
Subject: RE: [Ecrit] requirements

All -

I think the basic question being asked deals with two = (or more) different
flavors under the umbrella of Emergency Services. = Two existing examples are:

  o B/E911 in the US - does not require that the = "caller" be authorized, or
even identified (most 911 systems today are required = to provide anonymous
access);

  o GETS (Government Emergency = Telecommunications Service) in the US, which
can only be used by authorized users - uses PIN = mechanism something like a
calling card to allow the caller to = authenticate.

I think the original e-mail was asking for a specific = requirement for ecrit
(911 service domain) stating that "caller" = MUST NOT be required to be
pre-authorized or to have to authenticate in order = to place an emergency
service (e.g. 911-type) call.

John

------------------------
John Rosenberg
Lucent Technologies
LSS Core Product Mgmt
LSS Emergency Services, GETS, & Regulatory = Features Product Mgmt 630-713-7162 jrrosenberg@lucent.com


At 10:15 AM 3/23/2005, Ken Carlberg wrote:
 >> you might remember the presentation = by james about validation of location  >> information. he = pointed out that access network provides location  >> = information to the end host in such a way that the emergency response =

center
 >> is able to verify that a = "trusted" access network created the object and  = >> (maybe that this network is indeed reponsible for the = area).  >  >James may correct me, but I would say that = the scenario you paint above  >is one of authentication and = integrity in the "validation of location  = >information".  I would not consider that a case of = authorization, since  >I bind that security component with = usage of a service.  we may have to  >chalk this up as a = case of agreeing to disagree.  >  >> we had some = further discussions about this issue in the geopriv working  = >> group. i also consider this as part of the authorization = decision.  >> there are still a number of issues that need = to be investigated and  >> discussed (and i am not sure that = i understood all aspects;  >> the same is probably true for = other folks as well).  >  >I have not been following = geopriv as closely as I should have, so I can't  >comment on = this.  >  >> there will not be a 'must be = authenticated' and 'must be authorized'  >> requirement for = 911/etc. calls (what we have heard so far in the  >> = discussions).  >  >well, my personal feeling is that = users and information should be  >authenticated to offer a = measure confidence to others as to the  >validity of the user = and/or the information (eg, location info)  >being = provided.  >  >> we should also discuss what the = meaning of the authorization decision

in the
 >> context you mention (rfc 2906) is. do = you think about 'user x is subscribed  >> i.e. was = successfully authenticated' or 'user x has sufficient funds' or  = >> 'user x is within a specific geographical area' etc.  = >>  >> i think that most people do not make an = assumption about authorization in  >> this particular area. = i would like to know what type of authorization the  >> = ieprep folks consider.  >  >in my view, you are mixing = components of security.  a service is  >potentialy = authorized and information in potentially authenticated

 >-- I say potentially because the security = portion may not be deployed.  >  >I'm probably being = very picky in my terminology, but I would say that  >ieprep = does not consider a "type of authentication" because that = would  >correlate to a solution, which is not in the current = charter of ieprep.  >  >rfc-3689 from ieprep provides = some general requirements with respect  >to = authorization/integrity/authentication, but the rfc is only a  = >baseline starting point from which more specific requirements = can  >be defined within that group.  it can be debated how = effective this  >approach was, but that was the direction we = took at the time.  >  >-ken  >  >  = >  >  = >_______________________________________________

 >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

------_=_NextPart_001_01C52FCC.1281357E-- --===============0444740450== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0444740450==-- From ecrit-bounces@ietf.org Wed Mar 23 12:18:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08615; Wed, 23 Mar 2005 12:18:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9aC-0004As-H9; Wed, 23 Mar 2005 12:23:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9JW-0004Jt-M3; Wed, 23 Mar 2005 12:06:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9JV-0004JZ-4o for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 12:06:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06947 for ; Wed, 23 Mar 2005 12:06:34 -0500 (EST) Received: from dnsmx2pya.telcordia.com ([128.96.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9P0-0003di-Kg for ecrit@ietf.org; Wed, 23 Mar 2005 12:12:19 -0500 Received: from rrc-its-ieg02.cc.telcordia.com (rrc-its-ieg02.cc.telcordia.com [128.96.109.3]) by dnsmx2pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j2NH6EM15424; Wed, 23 Mar 2005 12:06:14 -0500 (EST) Received: from rrc-its-exig01.mail.saic.com ([128.96.103.57]) by rrc-its-ieg02.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005032312061204618 ; Wed, 23 Mar 2005 12:06:12 -0500 Received: by rrc-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Mar 2005 12:06:12 -0500 Message-ID: From: "Abbott, Nadine B." To: "'John Rosenberg'" Subject: RE: [Ecrit] requirements Date: Wed, 23 Mar 2005 12:06:10 -0500 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: 944ecb6e61f753561f559a497458fb4f 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a John, This may not be to the main point of your email, but I thought some clarification might be in order. In the US, uninitialized mobiles are allowed to initiate 9-1-1 calls without callback number identification, but this is not the norm. Caller identification may not be provided in a few other special instances (e.g., signaling failures, or left-in-service lines for which 9-1-1 calling is supported during the transition to new occupancy). But typically, even if a caller has calling identity privacy features, callback number is delivered to the PSAP on 9-1-1 calls in most jurisdictions. I think that "authentication" of location information relates mainly to accountability of the originating service provider responsible for populating the location information. Nadine -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of John Rosenberg Sent: Wednesday, March 23, 2005 11:28 AM To: Ken Carlberg; 'Tschofenig Hannes'; ecrit@ietf.org Subject: RE: [Ecrit] requirements All - I think the basic question being asked deals with two (or more) different flavors under the umbrella of Emergency Services. Two existing examples are: o B/E911 in the US - does not require that the "caller" be authorized, or even identified (most 911 systems today are required to provide anonymous access); o GETS (Government Emergency Telecommunications Service) in the US, which can only be used by authorized users - uses PIN mechanism something like a calling card to allow the caller to authenticate. I think the original e-mail was asking for a specific requirement for ecrit (911 service domain) stating that "caller" MUST NOT be required to be pre-authorized or to have to authenticate in order to place an emergency service (e.g. 911-type) call. John ------------------------ John Rosenberg Lucent Technologies LSS Core Product Mgmt LSS Emergency Services, GETS, & Regulatory Features Product Mgmt 630-713-7162 jrrosenberg@lucent.com At 10:15 AM 3/23/2005, Ken Carlberg wrote: >> you might remember the presentation by james about validation of location >> information. he pointed out that access network provides location >> information to the end host in such a way that the emergency response center >> is able to verify that a "trusted" access network created the object and >> (maybe that this network is indeed reponsible for the area). > >James may correct me, but I would say that the scenario you paint above >is one of authentication and integrity in the "validation of location >information". I would not consider that a case of authorization, since >I bind that security component with usage of a service. we may have to >chalk this up as a case of agreeing to disagree. > >> we had some further discussions about this issue in the geopriv working >> group. i also consider this as part of the authorization decision. >> there are still a number of issues that need to be investigated and >> discussed (and i am not sure that i understood all aspects; >> the same is probably true for other folks as well). > >I have not been following geopriv as closely as I should have, so I can't >comment on this. > >> there will not be a 'must be authenticated' and 'must be authorized' >> requirement for 911/etc. calls (what we have heard so far in the >> discussions). > >well, my personal feeling is that users and information should be >authenticated to offer a measure confidence to others as to the >validity of the user and/or the information (eg, location info) >being provided. > >> we should also discuss what the meaning of the authorization decision in the >> context you mention (rfc 2906) is. do you think about 'user x is subscribed >> i.e. was successfully authenticated' or 'user x has sufficient funds' or >> 'user x is within a specific geographical area' etc. >> >> i think that most people do not make an assumption about authorization in >> this particular area. i would like to know what type of authorization the >> ieprep folks consider. > >in my view, you are mixing components of security. a service is >potentialy authorized and information in potentially authenticated >-- I say potentially because the security portion may not be deployed. > >I'm probably being very picky in my terminology, but I would say that >ieprep does not consider a "type of authentication" because that would >correlate to a solution, which is not in the current charter of ieprep. > >rfc-3689 from ieprep provides some general requirements with respect >to authorization/integrity/authentication, but the rfc is only a >baseline starting point from which more specific requirements can >be defined within that group. it can be debated how effective this >approach was, but that was the direction we took at the time. > >-ken > > > > >_______________________________________________ >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 Mar 23 12:20:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09184; Wed, 23 Mar 2005 12:20:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9cu-0004Jq-Gk; Wed, 23 Mar 2005 12:26:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9X4-0007S8-7n; Wed, 23 Mar 2005 12:20:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9X2-0007Q8-PU for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 12:20:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09102 for ; Wed, 23 Mar 2005 12:20:34 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9cY-0004IU-FY for ecrit@ietf.org; Wed, 23 Mar 2005 12:26:18 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j2NHKPXZ005510; Wed, 23 Mar 2005 11:20:26 -0600 (CST) Received: from jrrosenberg-2.lucent.com (jrrosenberg-2.ih.lucent.com [135.185.234.35]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j2NHKOB22321; Wed, 23 Mar 2005 11:20:24 -0600 (CST) Message-Id: <6.2.1.2.0.20050323110844.040fbbc8@ihmail.ih.lucent.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 23 Mar 2005 11:20:15 -0600 To: "Abbott, Nadine B." From: John Rosenberg Subject: RE: [Ecrit] requirements In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Nadine - I agree absolutely with the validation and authentication of location info. What I was referring to about caller identity, though, was not uninitialized mobiles or trying to hide by blocking your caller ID. What I was referring to are direct-to-PSAP calls which provide anonymity to the caller - see GR-350 Section 4.1.2. Some jurisdictions require this type of access, and it's used for anonymous tip lines and the like. John At 11:06 AM 3/23/2005, Abbott, Nadine B. wrote: >John, > >This may not be to the main point of your email, but I thought some >clarification might be in order. >In the US, uninitialized mobiles are allowed to initiate 9-1-1 calls without >callback number identification, but this is not the norm. Caller >identification may not be provided in a few other special instances (e.g., >signaling failures, or left-in-service lines for which 9-1-1 calling is >supported during the transition to new occupancy). >But typically, even if a caller has calling identity privacy features, >callback number is delivered to the PSAP on 9-1-1 calls in most >jurisdictions. >I think that "authentication" of location information relates mainly to >accountability of the originating service provider responsible for >populating the location information. > >Nadine > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >John Rosenberg >Sent: Wednesday, March 23, 2005 11:28 AM >To: Ken Carlberg; 'Tschofenig Hannes'; ecrit@ietf.org >Subject: RE: [Ecrit] requirements > > >All - > >I think the basic question being asked deals with two (or more) different >flavors under the umbrella of Emergency Services. Two existing examples are: > > o B/E911 in the US - does not require that the "caller" be authorized, or >even identified (most 911 systems today are required to provide anonymous >access); > > o GETS (Government Emergency Telecommunications Service) in the US, which >can only be used by authorized users - uses PIN mechanism something like a >calling card to allow the caller to authenticate. > >I think the original e-mail was asking for a specific requirement for ecrit >(911 service domain) stating that "caller" MUST NOT be required to be >pre-authorized or to have to authenticate in order to place an emergency >service (e.g. 911-type) call. > >John > >------------------------ >John Rosenberg >Lucent Technologies >LSS Core Product Mgmt >LSS Emergency Services, GETS, & Regulatory Features Product Mgmt >630-713-7162 jrrosenberg@lucent.com > > >At 10:15 AM 3/23/2005, Ken Carlberg wrote: > >> you might remember the presentation by james about validation of >location >> information. he pointed out that access network provides >location >> information to the end host in such a way that the emergency >response >center > >> is able to verify that a "trusted" access network created the object and >>> (maybe that this network is indeed reponsible for the area). > >James >may correct me, but I would say that the scenario you paint above >is one >of authentication and integrity in the "validation of location >>information". I would not consider that a case of authorization, since >I >bind that security component with usage of a service. we may have to >>chalk this up as a case of agreeing to disagree. > >> we had some further >discussions about this issue in the geopriv working >> group. i also >consider this as part of the authorization decision. >> there are still a >number of issues that need to be investigated and >> discussed (and i am >not sure that i understood all aspects; >> the same is probably true for >other folks as well). > >I have not been following geopriv as closely as I >should have, so I can't >comment on this. > >> there will not be a 'must >be authenticated' and 'must be authorized' >> requirement for 911/etc. >calls (what we have heard so far in the >> discussions). > >well, my >personal feeling is that users and information should be >authenticated to >offer a measure confidence to others as to the >validity of the user and/or >the information (eg, location info) >being provided. > >> we should also >discuss what the meaning of the authorization decision >in the > >> context you mention (rfc 2906) is. do you think about 'user x is >subscribed >> i.e. was successfully authenticated' or 'user x has >sufficient funds' or >> 'user x is within a specific geographical area' >etc. >> >> i think that most people do not make an assumption about >authorization in >> this particular area. i would like to know what type of >authorization the >> ieprep folks consider. > >in my view, you are mixing >components of security. a service is >potentialy authorized and >information in potentially authenticated > >-- I say potentially because the security portion may not be deployed. > >>I'm probably being very picky in my terminology, but I would say that >>ieprep does not consider a "type of authentication" because that would >>correlate to a solution, which is not in the current charter of ieprep. > >>rfc-3689 from ieprep provides some general requirements with respect >to >authorization/integrity/authentication, but the rfc is only a >baseline >starting point from which more specific requirements can >be defined within >that group. it can be debated how effective this >approach was, but that >was the direction we took at the time. > >-ken > > > > >>_______________________________________________ > >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 Mar 23 12:28:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09985; Wed, 23 Mar 2005 12:28:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9kX-0004Yc-JL; Wed, 23 Mar 2005 12:34:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9ea-00026d-Sl; Wed, 23 Mar 2005 12:28:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9eY-00026V-LH for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 12:28:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09927 for ; Wed, 23 Mar 2005 12:28:19 -0500 (EST) Received: from dnsmx2pya.telcordia.com ([128.96.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9k4-0004Xz-El for ecrit@ietf.org; Wed, 23 Mar 2005 12:34:04 -0500 Received: from rrc-its-ieg02.cc.telcordia.com (rrc-its-ieg02.cc.telcordia.com [128.96.109.3]) by dnsmx2pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j2NHSAM20390; Wed, 23 Mar 2005 12:28:10 -0500 (EST) Received: from rrc-its-exig01.mail.saic.com ([128.96.103.57]) by rrc-its-ieg02.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005032312280805798 ; Wed, 23 Mar 2005 12:28:08 -0500 Received: by rrc-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Mar 2005 12:28:08 -0500 Message-ID: From: "Abbott, Nadine B." To: "'John Rosenberg'" Subject: RE: [Ecrit] requirements Date: Wed, 23 Mar 2005 12:28:07 -0500 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: b22590c27682ace61775ee7b453b40d3 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c John, True, but I believe that these are accessed not by dialing 9-1-1, but by dialing a special anonymous tip-line number; and when delivered, these calls are indicated with an "anonymous caller id" and are not treated the same as 9-1-1 calls by the call-taker. I don't believe that location information can even be delivered for such calls. Nadine -----Original Message----- From: John Rosenberg [mailto:jrrosenberg@lucent.com] Sent: Wednesday, March 23, 2005 12:20 PM To: Abbott, Nadine B. Cc: ecrit@ietf.org Subject: RE: [Ecrit] requirements Nadine - I agree absolutely with the validation and authentication of location info. What I was referring to about caller identity, though, was not uninitialized mobiles or trying to hide by blocking your caller ID. What I was referring to are direct-to-PSAP calls which provide anonymity to the caller - see GR-350 Section 4.1.2. Some jurisdictions require this type of access, and it's used for anonymous tip lines and the like. John At 11:06 AM 3/23/2005, Abbott, Nadine B. wrote: >John, > >This may not be to the main point of your email, but I thought some >clarification might be in order. >In the US, uninitialized mobiles are allowed to initiate 9-1-1 calls without >callback number identification, but this is not the norm. Caller >identification may not be provided in a few other special instances (e.g., >signaling failures, or left-in-service lines for which 9-1-1 calling is >supported during the transition to new occupancy). >But typically, even if a caller has calling identity privacy features, >callback number is delivered to the PSAP on 9-1-1 calls in most >jurisdictions. >I think that "authentication" of location information relates mainly to >accountability of the originating service provider responsible for >populating the location information. > >Nadine > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >John Rosenberg >Sent: Wednesday, March 23, 2005 11:28 AM >To: Ken Carlberg; 'Tschofenig Hannes'; ecrit@ietf.org >Subject: RE: [Ecrit] requirements > > >All - > >I think the basic question being asked deals with two (or more) different >flavors under the umbrella of Emergency Services. Two existing examples are: > > o B/E911 in the US - does not require that the "caller" be authorized, or >even identified (most 911 systems today are required to provide anonymous >access); > > o GETS (Government Emergency Telecommunications Service) in the US, which >can only be used by authorized users - uses PIN mechanism something like a >calling card to allow the caller to authenticate. > >I think the original e-mail was asking for a specific requirement for ecrit >(911 service domain) stating that "caller" MUST NOT be required to be >pre-authorized or to have to authenticate in order to place an emergency >service (e.g. 911-type) call. > >John > >------------------------ >John Rosenberg >Lucent Technologies >LSS Core Product Mgmt >LSS Emergency Services, GETS, & Regulatory Features Product Mgmt >630-713-7162 jrrosenberg@lucent.com > > >At 10:15 AM 3/23/2005, Ken Carlberg wrote: > >> you might remember the presentation by james about validation of >location >> information. he pointed out that access network provides >location >> information to the end host in such a way that the emergency >response >center > >> is able to verify that a "trusted" access network created the object and >>> (maybe that this network is indeed reponsible for the area). > >James >may correct me, but I would say that the scenario you paint above >is one >of authentication and integrity in the "validation of location >>information". I would not consider that a case of authorization, since >I >bind that security component with usage of a service. we may have to >>chalk this up as a case of agreeing to disagree. > >> we had some further >discussions about this issue in the geopriv working >> group. i also >consider this as part of the authorization decision. >> there are still a >number of issues that need to be investigated and >> discussed (and i am >not sure that i understood all aspects; >> the same is probably true for >other folks as well). > >I have not been following geopriv as closely as I >should have, so I can't >comment on this. > >> there will not be a 'must >be authenticated' and 'must be authorized' >> requirement for 911/etc. >calls (what we have heard so far in the >> discussions). > >well, my >personal feeling is that users and information should be >authenticated to >offer a measure confidence to others as to the >validity of the user and/or >the information (eg, location info) >being provided. > >> we should also >discuss what the meaning of the authorization decision >in the > >> context you mention (rfc 2906) is. do you think about 'user x is >subscribed >> i.e. was successfully authenticated' or 'user x has >sufficient funds' or >> 'user x is within a specific geographical area' >etc. >> >> i think that most people do not make an assumption about >authorization in >> this particular area. i would like to know what type of >authorization the >> ieprep folks consider. > >in my view, you are mixing >components of security. a service is >potentialy authorized and >information in potentially authenticated > >-- I say potentially because the security portion may not be deployed. > >>I'm probably being very picky in my terminology, but I would say that >>ieprep does not consider a "type of authentication" because that would >>correlate to a solution, which is not in the current charter of ieprep. > >>rfc-3689 from ieprep provides some general requirements with respect >to >authorization/integrity/authentication, but the rfc is only a >baseline >starting point from which more specific requirements can >be defined within >that group. it can be debated how effective this >approach was, but that >was the direction we took at the time. > >-ken > > > > >>_______________________________________________ > >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 Mar 23 12:35:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10603; Wed, 23 Mar 2005 12:35:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9rD-0004jn-3U; Wed, 23 Mar 2005 12:41:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9iV-0002nv-9L; Wed, 23 Mar 2005 12:32:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9iT-0002nk-Ru for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 12:32:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10239 for ; Wed, 23 Mar 2005 12:32:23 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9nz-0004dO-LH for ecrit@ietf.org; Wed, 23 Mar 2005 12:38:08 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j2NHWEOG013539; Wed, 23 Mar 2005 11:32:15 -0600 (CST) Received: from jrrosenberg-2.lucent.com (jrrosenberg-2.ih.lucent.com [135.185.234.35]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j2NHWEB05015; Wed, 23 Mar 2005 11:32:14 -0600 (CST) Message-Id: <6.2.1.2.0.20050323112942.04112e90@ihmail.ih.lucent.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 23 Mar 2005 11:32:03 -0600 To: "Abbott, Nadine B." From: John Rosenberg Subject: RE: [Ecrit] requirements In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Nadine - True, the caller dials the PSAP DN directly, and the ANI is 0-911-0000, but from that point on they are treated as normal 911 calls - analogous to ANI failure. How the call-taker treats the caller is outside our scope I think. John At 11:28 AM 3/23/2005, Abbott, Nadine B. wrote: >John, > >True, but I believe that these are accessed not by dialing 9-1-1, but by >dialing a special anonymous tip-line number; and when delivered, these calls >are indicated with an "anonymous caller id" and are not treated the same as >9-1-1 calls by the call-taker. I don't believe that location information >can even be delivered for such calls. > >Nadine > >-----Original Message----- >From: John Rosenberg [mailto:jrrosenberg@lucent.com] >Sent: Wednesday, March 23, 2005 12:20 PM >To: Abbott, Nadine B. >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] requirements > > >Nadine - > >I agree absolutely with the validation and authentication of location info. > >What I was referring to about caller identity, though, was not >uninitialized mobiles or trying to hide by blocking your caller ID. > >What I was referring to are direct-to-PSAP calls which provide anonymity to >the caller - see GR-350 Section 4.1.2. Some jurisdictions require this type >of access, and it's used for anonymous tip lines and the like. > >John > > > > > >At 11:06 AM 3/23/2005, Abbott, Nadine B. wrote: > >John, > > > >This may not be to the main point of your email, but I thought some >>clarification might be in order. >In the US, uninitialized mobiles are >allowed to initiate 9-1-1 calls without >callback number identification, >but this is not the norm. Caller >identification may not be provided in a >few other special instances (e.g., >signaling failures, or left-in-service >lines for which 9-1-1 calling is >supported during the transition to new >occupancy). >But typically, even if a caller has calling identity privacy >features, >callback number is delivered to the PSAP on 9-1-1 calls in most >>jurisdictions. >I think that "authentication" of location information >relates mainly to >accountability of the originating service provider >responsible for >populating the location information. > >Nadine > >>-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >>John Rosenberg > >Sent: Wednesday, March 23, 2005 11:28 AM > >To: Ken Carlberg; 'Tschofenig Hannes'; ecrit@ietf.org > >Subject: RE: [Ecrit] requirements > > > > > >All - > > > >I think the basic question being asked deals with two (or more) different >>flavors under the umbrella of Emergency Services. Two existing examples >are: > > o B/E911 in the US - does not require that the "caller" be >authorized, or >even identified (most 911 systems today are required to >provide anonymous >access); > > o GETS (Government Emergency >Telecommunications Service) in the US, which >can only be used by >authorized users - uses PIN mechanism something like a >calling card to >allow the caller to authenticate. > >I think the original e-mail was >asking for a specific requirement for ecrit >(911 service domain) stating >that "caller" MUST NOT be required to be >pre-authorized or to have to >authenticate in order to place an emergency >service (e.g. 911-type) call. >> >John > > >------------------------ > >John Rosenberg > >Lucent Technologies > >LSS Core Product Mgmt > >LSS Emergency Services, GETS, & Regulatory Features Product Mgmt >>630-713-7162 jrrosenberg@lucent.com > > >At 10:15 AM 3/23/2005, Ken >Carlberg wrote: > >> you might remember the presentation by james about >validation of >location >> information. he pointed out that access network >provides >location >> information to the end host in such a way that the >emergency >response >center > >> is able to verify that a "trusted" >access network created the object and >>> (maybe that this network is >indeed reponsible for the area). > >James >may correct me, but I would >say that the scenario you paint above >is one >of authentication and >integrity in the "validation of location >>information". I would not >consider that a case of authorization, since >I >bind that security >component with usage of a service. we may have to >>chalk this up as a >case of agreeing to disagree. > >> we had some further >discussions about >this issue in the geopriv working >> group. i also >consider this as part >of the authorization decision. >> there are still a >number of issues that >need to be investigated and >> discussed (and i am >not sure that i >understood all aspects; >> the same is probably true for >other folks as >well). > >I have not been following geopriv as closely as I >should have, >so I can't >comment on this. > >> there will not be a 'must >be >authenticated' and 'must be authorized' >> requirement for 911/etc. >calls >(what we have heard so far in the >> discussions). > >well, my >personal >feeling is that users and information should be >authenticated to >offer a >measure confidence to others as to the >validity of the user and/or >the >information (eg, location info) >being provided. > >> we should also >>discuss what the meaning of the authorization decision >in the > >> >context you mention (rfc 2906) is. do you think about 'user x is >>subscribed >> i.e. was successfully authenticated' or 'user x has >>sufficient funds' or >> 'user x is within a specific geographical area' >>etc. >> >> i think that most people do not make an assumption about >>authorization in >> this particular area. i would like to know what type >of >authorization the >> ieprep folks consider. > >in my view, you are >mixing >components of security. a service is >potentialy authorized and >>information in potentially authenticated > >-- I say potentially because >the security portion may not be deployed. > >>I'm probably being very >picky in my terminology, but I would say that >>ieprep does not consider a >"type of authentication" because that would >>correlate to a solution, >which is not in the current charter of ieprep. > >>rfc-3689 from ieprep >provides some general requirements with respect >to >>authorization/integrity/authentication, but the rfc is only a >baseline >>starting point from which more specific requirements can >be defined >within >that group. it can be debated how effective this >approach was, >but that >was the direction we took at the time. > >-ken > > > > >>>_______________________________________________ > > >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 Mar 23 12:37:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10913; Wed, 23 Mar 2005 12:37:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9sy-0004oa-DY; Wed, 23 Mar 2005 12:43:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9kM-00031G-Md; Wed, 23 Mar 2005 12:34:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9kL-000316-5w for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 12:34:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10492 for ; Wed, 23 Mar 2005 12:34:18 -0500 (EST) Received: from smtp.hsia.fairmont.com ([142.131.15.59] helo=torntsims03.hsia.fairmont.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9pq-0004hY-V8 for ecrit@ietf.org; Wed, 23 Mar 2005 12:40:03 -0500 Received: from localhost.localdomain (unverified [66.120.92.34]) by torntsims03.hsia.fairmont.com (Vircom SMTPRS 3.2.315.0) with ESMTP id for ; Wed, 23 Mar 2005 12:20:20 -0500 Received: from byron ([142.131.189.101]) by localhost.localdomain (8.11.6/8.11.6) with SMTP id j2NHXxO03897 for ; Wed, 23 Mar 2005 09:33:59 -0800 From: "Byron Smith" To: Date: Wed, 23 Mar 2005 12:35:08 -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.1441 In-Reply-To: <422D410BD61FC04185076AD99AA7207A4709CB@inilmx01.lgmt.trdo> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: 7bit Subject: [Ecrit] RE: [Ecru] 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: 7bit Actually many/most unsubscribed wireline phones may NOT dial 911. State law may apply. It depends on the policy (and sometimes, the equipment) of the local service provider. There are many problems with unsubscribed wireline 911, including incorrect routing and no associated ALI record. The FCC requires unsubscribed wireless phones be able to dial 911. However, this is also problematic, because, in general, the PSAP cannot call back the unsubscribed phone, and because there may be no way, in general, to trace the "owner" of the phone. Several PSAPs have been the victim of multiple/recurring "crank" 911 calls from unsubscribed (anonymous) wireless phones. It can be a serious problem. Byron > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of > Ciesla, Larry > Sent: Wednesday, March 23, 2005 11:39 AM > To: jrrosenberg@lucent.com; carlberg@g11.org.uk; > hannes.tschofenig@siemens.com; ecrit@ietf.org > Subject: Re: [Ecrit] requirements > > > In fact, a user does not even need paid phone service for 911 to > work today. Both wireline and wireless phones will allow 911 to > work for unsubscribed phones. Perhaps the notion of > authorization should be viewed in the context that the entity > assigning location information to a phone should be authorized to do so. > > Regards > > Larry Ciesla > > > > ***This message has been sent via the Intrado Wireless > Information Network.*** > > -----Original Message----- > From: ecrit-bounces@ietf.org > To: Ken Carlberg ; 'Tschofenig Hannes' > ; ecrit@ietf.org > Sent: Wed Mar 23 09:28:10 2005 > Subject: RE: [Ecrit] requirements > > All - > > I think the basic question being asked deals with two (or more) different > flavors under the umbrella of Emergency Services. Two existing > examples are: > > o B/E911 in the US - does not require that the "caller" be > authorized, or > even identified (most 911 systems today are required to provide anonymous > access); > > o GETS (Government Emergency Telecommunications Service) in the > US, which > can only be used by authorized users - uses PIN mechanism > something like a > calling card to allow the caller to authenticate. > > I think the original e-mail was asking for a specific requirement > for ecrit > (911 service domain) stating that "caller" MUST NOT be required to be > pre-authorized or to have to authenticate in order to place an emergency > service (e.g. 911-type) call. > > John > > ------------------------ > John Rosenberg > Lucent Technologies > LSS Core Product Mgmt > LSS Emergency Services, GETS, & Regulatory Features Product Mgmt > 630-713-7162 > jrrosenberg@lucent.com > > > At 10:15 AM 3/23/2005, Ken Carlberg wrote: > >> you might remember the presentation by james about validation > of location > >> information. he pointed out that access network provides location > >> information to the end host in such a way that the emergency response > center > >> is able to verify that a "trusted" access network created the > object and > >> (maybe that this network is indeed reponsible for the area). > > > >James may correct me, but I would say that the scenario you paint above > >is one of authentication and integrity in the "validation of location > >information". I would not consider that a case of authorization, since > >I bind that security component with usage of a service. we may have to > >chalk this up as a case of agreeing to disagree. > > > >> we had some further discussions about this issue in the > geopriv working > >> group. i also consider this as part of the authorization decision. > >> there are still a number of issues that need to be investigated and > >> discussed (and i am not sure that i understood all aspects; > >> the same is probably true for other folks as well). > > > >I have not been following geopriv as closely as I should have, > so I can't > >comment on this. > > > >> there will not be a 'must be authenticated' and 'must be authorized' > >> requirement for 911/etc. calls (what we have heard so far in the > >> discussions). > > > >well, my personal feeling is that users and information should be > >authenticated to offer a measure confidence to others as to the > >validity of the user and/or the information (eg, location info) > >being provided. > > > >> we should also discuss what the meaning of the authorization decision > in the > >> context you mention (rfc 2906) is. do you think about 'user x > is subscribed > >> i.e. was successfully authenticated' or 'user x has > sufficient funds' or > >> 'user x is within a specific geographical area' etc. > >> > >> i think that most people do not make an assumption about > authorization in > >> this particular area. i would like to know what type of > authorization the > >> ieprep folks consider. > > > >in my view, you are mixing components of security. a service is > >potentialy authorized and information in potentially authenticated > >-- I say potentially because the security portion may not be deployed. > > > >I'm probably being very picky in my terminology, but I would say that > >ieprep does not consider a "type of authentication" because that would > >correlate to a solution, which is not in the current charter of ieprep. > > > >rfc-3689 from ieprep provides some general requirements with respect > >to authorization/integrity/authentication, but the rfc is only a > >baseline starting point from which more specific requirements can > >be defined within that group. it can be debated how effective this > >approach was, but that was the direction we took at the time. > > > >-ken > > > > > > > > > >_______________________________________________ > >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 > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 3/21/2005 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 23 12:48:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11872; Wed, 23 Mar 2005 12:48:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEA3D-00052O-RI; Wed, 23 Mar 2005 12:53:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9sN-0004SS-9G; Wed, 23 Mar 2005 12:42:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9sL-0004SN-V0 for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 12:42:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11357 for ; Wed, 23 Mar 2005 12:42:35 -0500 (EST) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9xq-0004ur-Ml for ecrit@ietf.org; Wed, 23 Mar 2005 12:48:20 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j2NHgXTm010046; Wed, 23 Mar 2005 18:42:33 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j2NHgWPd012023; Wed, 23 Mar 2005 18:42:32 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Mar 2005 18:42:32 +0100 Message-ID: From: Tschofenig Hannes To: "'John Rosenberg'" , Ken Carlberg , ecrit@ietf.org Subject: AW: [Ecrit] requirements Date: Wed, 23 Mar 2005 18:40:31 +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: 789c141a303c09204b537a4078e2a63f 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 hi john, please see my comment inline: > All - > > I think the basic question being asked deals with two (or > more) different > flavors under the umbrella of Emergency Services. Two > existing examples are: > > o B/E911 in the US - does not require that the "caller" be > authorized, or > even identified (most 911 systems today are required to > provide anonymous > access); > > o GETS (Government Emergency Telecommunications Service) in > the US, which > can only be used by authorized users - uses PIN mechanism > something like a > calling card to allow the caller to authenticate. > right. > I think the original e-mail was asking for a specific > requirement for ecrit > (911 service domain) stating that "caller" MUST NOT be required to be > pre-authorized or to have to authenticate in order to place > an emergency > service (e.g. 911-type) call. we (the ietf) are not going to make a decision when to accept or reject emergency calls. in fact, most people tell us that they will never reject one. hence, i guess we can agree that we MUST NOT require that end users authenticate in order to place an emergency call. with the discussion around location, identification of the calling party, language, device properties, etc. we are describing what additional information we could provide to the emergency response centers to make their decision making easier. we are providing just a toolbox here. at the last ietf some people have proposed to provide additional guarantees for location obtained via the access network. the main question is what type of properties they these (and other to be discussed attributes) provide. ciao hannes > > John > > ------------------------ > John Rosenberg > Lucent Technologies > LSS Core Product Mgmt > LSS Emergency Services, GETS, & Regulatory Features Product Mgmt > 630-713-7162 > jrrosenberg@lucent.com > > > At 10:15 AM 3/23/2005, Ken Carlberg wrote: > >> you might remember the presentation by james about > validation of location > >> information. he pointed out that access network provides location > >> information to the end host in such a way that the > emergency response > center > >> is able to verify that a "trusted" access network created > the object and > >> (maybe that this network is indeed reponsible for the area). > > > >James may correct me, but I would say that the scenario you > paint above > >is one of authentication and integrity in the "validation > of location > >information". I would not consider that a case of > authorization, since > >I bind that security component with usage of a service. we > may have to > >chalk this up as a case of agreeing to disagree. > > > >> we had some further discussions about this issue in the > geopriv working > >> group. i also consider this as part of the authorization decision. > >> there are still a number of issues that need to be > investigated and > >> discussed (and i am not sure that i understood all aspects; > >> the same is probably true for other folks as well). > > > >I have not been following geopriv as closely as I should > have, so I can't > >comment on this. > > > >> there will not be a 'must be authenticated' and 'must be > authorized' > >> requirement for 911/etc. calls (what we have heard so far in the > >> discussions). > > > >well, my personal feeling is that users and information should be > >authenticated to offer a measure confidence to others as to the > >validity of the user and/or the information (eg, location info) > >being provided. > > > >> we should also discuss what the meaning of the > authorization decision > in the > >> context you mention (rfc 2906) is. do you think about > 'user x is subscribed > >> i.e. was successfully authenticated' or 'user x has > sufficient funds' or > >> 'user x is within a specific geographical area' etc. > >> > >> i think that most people do not make an assumption about > authorization in > >> this particular area. i would like to know what type of > authorization the > >> ieprep folks consider. > > > >in my view, you are mixing components of security. a service is > >potentialy authorized and information in potentially authenticated > >-- I say potentially because the security portion may not > be deployed. > > > >I'm probably being very picky in my terminology, but I > would say that > >ieprep does not consider a "type of authentication" because > that would > >correlate to a solution, which is not in the current > charter of ieprep. > > > >rfc-3689 from ieprep provides some general requirements with respect > >to authorization/integrity/authentication, but the rfc is only a > >baseline starting point from which more specific requirements can > >be defined within that group. it can be debated how effective this > >approach was, but that was the direction we took at the time. > > > >-ken > > > > > > > > > >_______________________________________________ > >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 Mar 23 12:54:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12618; Wed, 23 Mar 2005 12:54:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEA9d-0005Fx-2o; Wed, 23 Mar 2005 13:00:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9yb-00056Y-Hh; Wed, 23 Mar 2005 12:49:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9yZ-00056Q-1E for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 12:49:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11939 for ; Wed, 23 Mar 2005 12:49:00 -0500 (EST) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEA44-00054F-Lq for ecrit@ietf.org; Wed, 23 Mar 2005 12:54:45 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j2NHmxFe015899; Wed, 23 Mar 2005 18:48:59 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j2NHmxW1017061; Wed, 23 Mar 2005 18:48:59 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Mar 2005 18:48:59 +0100 Message-ID: From: Tschofenig Hannes To: "'James Winterbottom'" , "Ciesla, Larry" , ecrit@ietf.org Subject: AW: [Ecrit] requirements Date: Wed, 23 Mar 2005 18:46:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: quoted-printable hi james,=20 hi larry,=20 based on this definition i cannot write code.=20 how do you ensure that the entity that assigned location information to someone is allowed todo so?=20 do you assume that there is an access control list that says: "if identity(access network) =3D=3D "company x" then accept"?=20 ciao hannes -----Urspr=FCngliche Nachricht----- Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] Im Auftrag = von James Winterbottom Gesendet: Mittwoch, 23. M=E4rz 2005 18:17 An: Ciesla, Larry; ecrit@ietf.org Betreff: RE: [Ecrit] requirements Larry,=20 That is the definition that I have been using.=20 Cheers=20 James=20 -----Original Message-----=20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Ciesla, Larry=20 Sent: Thursday, 24 March 2005 3:39 AM=20 To: jrrosenberg@lucent.com; carlberg@g11.org.uk; hannes.tschofenig@siemens.com; ecrit@ietf.org=20 Subject: Re: [Ecrit] requirements=20 In fact, a user does not even need paid phone service for 911 to work = today. Both wireline and wireless phones will allow 911 to work for = unsubscribed phones. Perhaps the notion of authorization should be viewed in the = context that the entity assigning location information to a phone should be authorized to do so.=20 Regards=20 Larry Ciesla=20 ***This message has been sent via the Intrado Wireless Information Network.***=20 -----Original Message-----=20 From: ecrit-bounces@ietf.org =20 To: Ken Carlberg ; 'Tschofenig Hannes' ; ecrit@ietf.org Sent: Wed Mar 23 09:28:10 2005=20 Subject: RE: [Ecrit] requirements=20 All -=20 I think the basic question being asked deals with two (or more) = different=20 flavors under the umbrella of Emergency Services. Two existing examples = are: o B/E911 in the US - does not require that the "caller" be = authorized, or=20 even identified (most 911 systems today are required to provide = anonymous=20 access);=20 o GETS (Government Emergency Telecommunications Service) in the US, = which=20 can only be used by authorized users - uses PIN mechanism something = like a=20 calling card to allow the caller to authenticate.=20 I think the original e-mail was asking for a specific requirement for = ecrit=20 (911 service domain) stating that "caller" MUST NOT be required to be=20 pre-authorized or to have to authenticate in order to place an = emergency=20 service (e.g. 911-type) call.=20 John=20 ------------------------=20 John Rosenberg=20 Lucent Technologies=20 LSS Core Product Mgmt=20 LSS Emergency Services, GETS, & Regulatory Features Product Mgmt 630-713-7162 jrrosenberg@lucent.com=20 At 10:15 AM 3/23/2005, Ken Carlberg wrote:=20 >> you might remember the presentation by james about validation of location >> information. he pointed out that access network provides location >> information to the end host in such a way that the = emergency response=20 center=20 >> is able to verify that a "trusted" access network created the = object and >> (maybe that this network is indeed reponsible for the area). > = >James may correct me, but I would say that the scenario you paint above >is = one of authentication and integrity in the "validation of location >information". I would not consider that a case of authorization, = since >I bind that security component with usage of a service. we may have to >chalk this up as a case of agreeing to disagree. > >> we had some = further discussions about this issue in the geopriv working >> group. i also consider this as part of the authorization decision. >> there are = still a number of issues that need to be investigated and >> discussed (and i = am not sure that i understood all aspects; >> the same is probably true = for other folks as well). > >I have not been following geopriv as closely = as I should have, so I can't >comment on this. > >> there will not be a = 'must be authenticated' and 'must be authorized' >> requirement for 911/etc. calls (what we have heard so far in the >> discussions). > >well, my personal feeling is that users and information should be = >authenticated to offer a measure confidence to others as to the >validity of the user = and/or the information (eg, location info) >being provided. > >> we should = also discuss what the meaning of the authorization decision=20 in the=20 >> context you mention (rfc 2906) is. do you think about 'user x is subscribed >> i.e. was successfully authenticated' or 'user x has sufficient funds' or >> 'user x is within a specific geographical = area' etc. >> >> i think that most people do not make an assumption about authorization in >> this particular area. i would like to know what = type of authorization the >> ieprep folks consider. > >in my view, you are = mixing components of security. a service is >potentialy authorized and information in potentially authenticated >-- I say potentially because the security portion may not be = deployed. > >I'm probably being very picky in my terminology, but I would say that >ieprep does not consider a "type of authentication" because that would >correlate to a solution, which is not in the current charter of = ieprep. > >rfc-3689 from ieprep provides some general requirements with respect = >to authorization/integrity/authentication, but the rfc is only a = >baseline starting point from which more specific requirements can >be defined = within that group. it can be debated how effective this >approach was, but = that was the direction we took at the time. > >-ken > > > > >_______________________________________________ >Ecrit mailing list=20 >Ecrit@ietf.org=20 >https://www1.ietf.org/mailman/listinfo/ecrit=20 _______________________________________________=20 Ecrit mailing list=20 Ecrit@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ecrit=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 Mar 23 13:26:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16171; Wed, 23 Mar 2005 13:26:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEAeT-0006BB-4Z; Wed, 23 Mar 2005 13:32:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEAYN-0002vK-4M; Wed, 23 Mar 2005 13:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEAYL-0002uw-Nl for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 13:26:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16121 for ; Wed, 23 Mar 2005 13:25:57 -0500 (EST) Received: from leviathan.cnchost.com ([207.155.252.18]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEAdo-0006AB-J7 for ecrit@ietf.org; Wed, 23 Mar 2005 13:31:43 -0500 Received: from LT10356 ([209.125.86.115]) by leviathan.cnchost.com id NAA09455; Wed, 23 Mar 2005 13:25:46 -0500 (EST) [ConcentricHost SMTP Relay 1.17] Message-ID: <200503231825.NAA09455@leviathan.cnchost.com> From: "Medhavi Bhatia" To: "'Byron Smith'" , Subject: RE: [Ecrit] RE: [Ecru] requirements Date: Wed, 23 Mar 2005 13:25:23 -0500 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: Thread-Index: AcUvzv1WJ59P37Z4RT6b3ISUIQfC8QABgB7Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Content-Transfer-Encoding: 7bit I saw some discussion on one of the ETSI lists on requirements and work on handling calls from unauthorized callers (without valid USIM). I think they are looking at it as well. Your point of having to call the caller back is important to prevent something like a DoS attack on the emergency service provider. Will the ability to call the caller back (which means that the wireless SP should be able to call a phone not on its network...) and locate the origination be enough to deter attacks that authentication may not be necessary ? Not sure how this can be done. -Medhavi. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Byron Smith > Sent: Wednesday, March 23, 2005 12:35 PM > To: ecrit@ietf.org > Subject: [Ecrit] RE: [Ecru] requirements > > Actually many/most unsubscribed wireline phones may NOT dial 911. State law > may apply. It depends on the policy (and sometimes, the equipment) of the > local service provider. There are many problems with unsubscribed wireline > 911, including incorrect routing and no associated ALI record. > > The FCC requires unsubscribed wireless phones be able to dial 911. However, > this is also problematic, because, in general, the PSAP cannot call back the > unsubscribed phone, and because there may be no way, in general, to trace > the "owner" of the phone. Several PSAPs have been the victim of > multiple/recurring "crank" 911 calls from unsubscribed (anonymous) wireless > phones. It can be a serious problem. > > Byron > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of > > Ciesla, Larry > > Sent: Wednesday, March 23, 2005 11:39 AM > > To: jrrosenberg@lucent.com; carlberg@g11.org.uk; > > hannes.tschofenig@siemens.com; ecrit@ietf.org > > Subject: Re: [Ecrit] requirements > > > > > > In fact, a user does not even need paid phone service for 911 to > > work today. Both wireline and wireless phones will allow 911 to > > work for unsubscribed phones. Perhaps the notion of > > authorization should be viewed in the context that the entity > > assigning location information to a phone should be authorized to do so. > > > > Regards > > > > Larry Ciesla > > > > > > > > ***This message has been sent via the Intrado Wireless > > Information Network.*** > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > > To: Ken Carlberg ; 'Tschofenig Hannes' > > ; ecrit@ietf.org > > Sent: Wed Mar 23 09:28:10 2005 > > Subject: RE: [Ecrit] requirements > > > > All - > > > > I think the basic question being asked deals with two (or more) different > > flavors under the umbrella of Emergency Services. Two existing > > examples are: > > > > o B/E911 in the US - does not require that the "caller" be > > authorized, or > > even identified (most 911 systems today are required to provide anonymous > > access); > > > > o GETS (Government Emergency Telecommunications Service) in the > > US, which > > can only be used by authorized users - uses PIN mechanism > > something like a > > calling card to allow the caller to authenticate. > > > > I think the original e-mail was asking for a specific requirement > > for ecrit > > (911 service domain) stating that "caller" MUST NOT be required to be > > pre-authorized or to have to authenticate in order to place an emergency > > service (e.g. 911-type) call. > > > > John > > > > ------------------------ > > John Rosenberg > > Lucent Technologies > > LSS Core Product Mgmt > > LSS Emergency Services, GETS, & Regulatory Features Product Mgmt > > 630-713-7162 > > jrrosenberg@lucent.com > > > > > > At 10:15 AM 3/23/2005, Ken Carlberg wrote: > > >> you might remember the presentation by james about validation > > of location > > >> information. he pointed out that access network provides location > > >> information to the end host in such a way that the emergency response > > center > > >> is able to verify that a "trusted" access network created the > > object and > > >> (maybe that this network is indeed reponsible for the area). > > > > > >James may correct me, but I would say that the scenario you paint above > > >is one of authentication and integrity in the "validation of location > > >information". I would not consider that a case of authorization, since > > >I bind that security component with usage of a service. we may have to > > >chalk this up as a case of agreeing to disagree. > > > > > >> we had some further discussions about this issue in the > > geopriv working > > >> group. i also consider this as part of the authorization decision. > > >> there are still a number of issues that need to be investigated and > > >> discussed (and i am not sure that i understood all aspects; > > >> the same is probably true for other folks as well). > > > > > >I have not been following geopriv as closely as I should have, > > so I can't > > >comment on this. > > > > > >> there will not be a 'must be authenticated' and 'must be authorized' > > >> requirement for 911/etc. calls (what we have heard so far in the > > >> discussions). > > > > > >well, my personal feeling is that users and information should be > > >authenticated to offer a measure confidence to others as to the > > >validity of the user and/or the information (eg, location info) > > >being provided. > > > > > >> we should also discuss what the meaning of the authorization decision > > in the > > >> context you mention (rfc 2906) is. do you think about 'user x > > is subscribed > > >> i.e. was successfully authenticated' or 'user x has > > sufficient funds' or > > >> 'user x is within a specific geographical area' etc. > > >> > > >> i think that most people do not make an assumption about > > authorization in > > >> this particular area. i would like to know what type of > > authorization the > > >> ieprep folks consider. > > > > > >in my view, you are mixing components of security. a service is > > >potentialy authorized and information in potentially authenticated > > >-- I say potentially because the security portion may not be deployed. > > > > > >I'm probably being very picky in my terminology, but I would say that > > >ieprep does not consider a "type of authentication" because that would > > >correlate to a solution, which is not in the current charter of ieprep. > > > > > >rfc-3689 from ieprep provides some general requirements with respect > > >to authorization/integrity/authentication, but the rfc is only a > > >baseline starting point from which more specific requirements can > > >be defined within that group. it can be debated how effective this > > >approach was, but that was the direction we took at the time. > > > > > >-ken > > > > > > > > > > > > > > >_______________________________________________ > > >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 > > -- > > No virus found in this incoming message. > > Checked by AVG Anti-Virus. > > Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 3/21/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 Wed Mar 23 13:28:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16552; Wed, 23 Mar 2005 13:28:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEAgF-0006FE-Ek; Wed, 23 Mar 2005 13:34:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEAZK-00036M-CG; Wed, 23 Mar 2005 13:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEAZJ-000312-3d for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 13:27:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16228 for ; Wed, 23 Mar 2005 13:26:49 -0500 (EST) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEAeh-0006Be-1Y for ecrit@ietf.org; Wed, 23 Mar 2005 13:32:35 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j2NIQj74013142; Wed, 23 Mar 2005 19:26:45 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j2NIQjic008511; Wed, 23 Mar 2005 19:26:45 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Mar 2005 19:26:45 +0100 Message-ID: From: Tschofenig Hannes To: "'Ken Carlberg'" , ecrit@ietf.org Subject: AW: [Ecrit] requirements Date: Wed, 23 Mar 2005 19:24:43 +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: 287c806b254c6353fcb09ee0e53bbc5e 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 hi ken, please see my comments inline: > > you might remember the presentation by james about > validation of location > > information. he pointed out that access network provides location > > information to the end host in such a way that the > emergency response center > > is able to verify that a "trusted" access network created > the object and > > (maybe that this network is indeed reponsible for the area). > > James may correct me, but I would say that the scenario you > paint above > is one of authentication and integrity in the "validation of location > information". I would not consider that a case of > authorization, since > I bind that security component with usage of a service. we > may have to > chalk this up as a case of agreeing to disagree. maybe we just have a terminology problem here. i think that we need to provide authentication in order to provide authorization and accountability. in many cases authentication alone is insufficient. btw, i avoid using the term service since it has so many different meanings that it is quite like that we talk past each other. > > > we had some further discussions about this issue in the > geopriv working > > group. i also consider this as part of the authorization decision. > > there are still a number of issues that need to be investigated and > > discussed (and i am not sure that i understood all aspects; > > the same is probably true for other folks as well). > > I have not been following geopriv as closely as I should > have, so I can't > comment on this. that's fine. based on the history and the relationship with geopriv we will reuse their work. > > > there will not be a 'must be authenticated' and 'must be authorized' > > requirement for 911/etc. calls (what we have heard so far in the > > discussions). > > well, my personal feeling is that users and information should be > authenticated to offer a measure confidence to others as to the > validity of the user and/or the information (eg, location info) > being provided. i think we cannot mandate what decisions are made in emergency response centers (since this is not our business). what we can do is to provide solutions that they would be able to use, if they want. > > > we should also discuss what the meaning of the > authorization decision in the > > context you mention (rfc 2906) is. do you think about 'user > x is subscribed > > i.e. was successfully authenticated' or 'user x has > sufficient funds' or > > 'user x is within a specific geographical area' etc. > > > > i think that most people do not make an assumption about > authorization in > > this particular area. i would like to know what type of > authorization the > > ieprep folks consider. > > in my view, you are mixing components of security. a service is > potentialy authorized and information in potentially authenticated > -- I say potentially because the security portion may not be deployed. with regard to authorization i like to refer to rfc 2828 and with regard to authentication to the handbook of applied cryptography (since they differentiate entity and data origin authentication). > > I'm probably being very picky in my terminology, that's very good. i had the impression that we have a mess with regard to terminology. we need to get it fixed soon. >but I would say that > ieprep does not consider a "type of authentication" because that would > correlate to a solution, which is not in the current charter > of ieprep. > > rfc-3689 from ieprep provides some general requirements with respect > to authorization/integrity/authentication, but the rfc is only a > baseline starting point from which more specific requirements can > be defined within that group. it can be debated how effective this > approach was, but that was the direction we took at the time. i will certainly read your document. ciao hannes > > -ken > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 23 13:29:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16705; Wed, 23 Mar 2005 13:29:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEAh7-0006HW-Gd; Wed, 23 Mar 2005 13:35:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEAb8-0003LY-9g; Wed, 23 Mar 2005 13:28:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEAb6-0003K5-DK for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 13:28:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16658 for ; Wed, 23 Mar 2005 13:28:49 -0500 (EST) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEAgc-0006GI-Ic for ecrit@ietf.org; Wed, 23 Mar 2005 13:34:35 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j2NISopH020661; Wed, 23 Mar 2005 19:28:50 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j2NISoWP009975; Wed, 23 Mar 2005 19:28:50 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Mar 2005 19:28:50 +0100 Message-ID: From: Tschofenig Hannes To: "'Abbott, Nadine B.'" , "'John Rosenberg'" Subject: AW: [Ecrit] requirements Date: Wed, 23 Mar 2005 19:26:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: quoted-printable hi nadine,=20 thanks for your input. it is interesting to see that you see asserting = of location information mainly as accountability.=20 you would always authorize an emergency call but, if you encounter some problems, you want to hold someone liable for it.=20 is this a correct interpretation?=20 ciao hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > Im Auftrag von Abbott, Nadine B. > Gesendet: Mittwoch, 23. M=E4rz 2005 18:06 > An: 'John Rosenberg' > Cc: ecrit@ietf.org > Betreff: RE: [Ecrit] requirements >=20 >=20 > John,=20 >=20 > This may not be to the main point of your email, but I thought some > clarification might be in order. > In the US, uninitialized mobiles are allowed to initiate=20 > 9-1-1 calls without > callback number identification, but this is not the norm. Caller > identification may not be provided in a few other special=20 > instances (e.g., > signaling failures, or left-in-service lines for which 9-1-1=20 > calling is > supported during the transition to new occupancy).=20 > But typically, even if a caller has calling identity privacy = features, > callback number is delivered to the PSAP on 9-1-1 calls in most > jurisdictions. =20 > I think that "authentication" of location information relates=20 > mainly to > accountability of the originating service provider responsible for > populating the location information. =20 >=20 > Nadine=20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of > John Rosenberg > Sent: Wednesday, March 23, 2005 11:28 AM > To: Ken Carlberg; 'Tschofenig Hannes'; ecrit@ietf.org > Subject: RE: [Ecrit] requirements >=20 >=20 > All - >=20 > I think the basic question being asked deals with two (or=20 > more) different=20 > flavors under the umbrella of Emergency Services. Two=20 > existing examples are: >=20 > o B/E911 in the US - does not require that the "caller" be=20 > authorized, or=20 > even identified (most 911 systems today are required to=20 > provide anonymous=20 > access); >=20 > o GETS (Government Emergency Telecommunications Service) in=20 > the US, which=20 > can only be used by authorized users - uses PIN mechanism=20 > something like a=20 > calling card to allow the caller to authenticate. >=20 > I think the original e-mail was asking for a specific=20 > requirement for ecrit=20 > (911 service domain) stating that "caller" MUST NOT be required to be = > pre-authorized or to have to authenticate in order to place=20 > an emergency=20 > service (e.g. 911-type) call. >=20 > John >=20 > ------------------------ > John Rosenberg > Lucent Technologies > LSS Core Product Mgmt > LSS Emergency Services, GETS, & Regulatory Features Product Mgmt > 630-713-7162 jrrosenberg@lucent.com >=20 >=20 > At 10:15 AM 3/23/2005, Ken Carlberg wrote: > >> you might remember the presentation by james about validation of > location >> information. he pointed out that access network provides > location >> information to the end host in such a way that=20 > the emergency > response=20 > center > >> is able to verify that a "trusted" access network created=20 > the object and > >> (maybe that this network is indeed reponsible for the=20 > area). > >James > may correct me, but I would say that the scenario you paint=20 > above >is one > of authentication and integrity in the "validation of location > >information". I would not consider that a case of=20 > authorization, since >I > bind that security component with usage of a service. we may have to > >chalk this up as a case of agreeing to disagree. > >> we=20 > had some further > discussions about this issue in the geopriv working >> group. i also > consider this as part of the authorization decision. >>=20 > there are still a > number of issues that need to be investigated and >>=20 > discussed (and i am > not sure that i understood all aspects; >> the same is=20 > probably true for > other folks as well). > >I have not been following geopriv=20 > as closely as I > should have, so I can't >comment on this. > >> there will=20 > not be a 'must > be authenticated' and 'must be authorized' >> requirement=20 > for 911/etc. > calls (what we have heard so far in the >> discussions). > =20 > >well, my > personal feeling is that users and information should be =20 > >authenticated to > offer a measure confidence to others as to the >validity of=20 > the user and/or > the information (eg, location info) >being provided. > >>=20 > we should also > discuss what the meaning of the authorization decision=20 > in the > >> context you mention (rfc 2906) is. do you think about 'user x is > subscribed >> i.e. was successfully authenticated' or 'user x has > sufficient funds' or >> 'user x is within a specific=20 > geographical area' > etc. >> >> i think that most people do not make an assumption about > authorization in >> this particular area. i would like to=20 > know what type of > authorization the >> ieprep folks consider. > >in my view,=20 > you are mixing > components of security. a service is >potentialy authorized and > information in potentially authenticated > >-- I say potentially because the security portion may not=20 > be deployed. > > >I'm probably being very picky in my terminology, but I would say = that > >ieprep does not consider a "type of authentication" because=20 > that would > >correlate to a solution, which is not in the current charter=20 > of ieprep. > > >rfc-3689 from ieprep provides some general requirements with=20 > respect >to > authorization/integrity/authentication, but the rfc is only a=20 > >baseline > starting point from which more specific requirements can >be=20 > defined within > that group. it can be debated how effective this >approach=20 > was, but that > was the direction we took at the time. > >-ken > > > > > >_______________________________________________ > >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 > _______________________________________________ > 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 Wed Mar 23 13:37:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17519; Wed, 23 Mar 2005 13:37:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEAoa-0006XC-E1; Wed, 23 Mar 2005 13:42:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEAic-0004fO-P0; Wed, 23 Mar 2005 13:36:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEAia-0004fG-Ld for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 13:36:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17384 for ; Wed, 23 Mar 2005 13:36:33 -0500 (EST) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEAo6-0006V6-Oc for ecrit@ietf.org; Wed, 23 Mar 2005 13:42:19 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j2NIaYtn025781; Wed, 23 Mar 2005 19:36:34 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j2NIaYRn014289; Wed, 23 Mar 2005 19:36:34 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Mar 2005 19:36:34 +0100 Message-ID: From: Tschofenig Hannes To: "'Medhavi Bhatia'" , "'Byron Smith'" , ecrit@ietf.org Subject: AW: [Ecrit] RE: [Ecru] requirements Date: Wed, 23 Mar 2005 19:34:32 +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: 71f780ffdd80c541d3e75aa5f2710d3d 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb hi medhavi, thanks for providing this information. it is a good question whether a "return-routability check" at the sip layer provides a good replacement for authentication. depending on the identity used for the check you either verify "is the calling party reachable at the given ip address?" or "is the calling party indeed reachable at the given uri". ciao hannes > I saw some discussion on one of the ETSI lists on > requirements and work on > handling calls from unauthorized callers (without valid > USIM). I think they > are looking at it as well. Your point of having to call the > caller back is > important to prevent something like a DoS attack on the > emergency service > provider. Will the ability to call the caller back (which > means that the > wireless SP should be able to call a phone not on its > network...) and locate > the origination be enough to deter attacks that > authentication may not be > necessary ? Not sure how this can be done. > > > -Medhavi. > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf Of > Byron Smith > > Sent: Wednesday, March 23, 2005 12:35 PM > > To: ecrit@ietf.org > > Subject: [Ecrit] RE: [Ecru] requirements > > > > Actually many/most unsubscribed wireline phones may NOT > dial 911. State > law > > may apply. It depends on the policy (and sometimes, the > equipment) of the > > local service provider. There are many problems with > unsubscribed wireline > > 911, including incorrect routing and no associated ALI record. > > > > The FCC requires unsubscribed wireless phones be able to dial 911. > However, > > this is also problematic, because, in general, the PSAP > cannot call back > the > > unsubscribed phone, and because there may be no way, in > general, to trace > > the "owner" of the phone. Several PSAPs have been the victim of > > multiple/recurring "crank" 911 calls from unsubscribed (anonymous) > wireless > > phones. It can be a serious problem. > > > > Byron > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org]On Behalf Of > > > Ciesla, Larry > > > Sent: Wednesday, March 23, 2005 11:39 AM > > > To: jrrosenberg@lucent.com; carlberg@g11.org.uk; > > > hannes.tschofenig@siemens.com; ecrit@ietf.org > > > Subject: Re: [Ecrit] requirements > > > > > > > > > In fact, a user does not even need paid phone service for 911 to > > > work today. Both wireline and wireless phones will allow 911 to > > > work for unsubscribed phones. Perhaps the notion of > > > authorization should be viewed in the context that the entity > > > assigning location information to a phone should be > authorized to do so. > > > > > > Regards > > > > > > Larry Ciesla > > > > > > > > > > > > ***This message has been sent via the Intrado Wireless > > > Information Network.*** > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > > To: Ken Carlberg ; 'Tschofenig Hannes' > > > ; ecrit@ietf.org > > > Sent: Wed Mar 23 09:28:10 2005 > > > Subject: RE: [Ecrit] requirements > > > > > > All - > > > > > > I think the basic question being asked deals with two (or more) > different > > > flavors under the umbrella of Emergency Services. Two existing > > > examples are: > > > > > > o B/E911 in the US - does not require that the "caller" be > > > authorized, or > > > even identified (most 911 systems today are required to provide > anonymous > > > access); > > > > > > o GETS (Government Emergency Telecommunications Service) in the > > > US, which > > > can only be used by authorized users - uses PIN mechanism > > > something like a > > > calling card to allow the caller to authenticate. > > > > > > I think the original e-mail was asking for a specific requirement > > > for ecrit > > > (911 service domain) stating that "caller" MUST NOT be > required to be > > > pre-authorized or to have to authenticate in order to > place an emergency > > > service (e.g. 911-type) call. > > > > > > John > > > > > > ------------------------ > > > John Rosenberg > > > Lucent Technologies > > > LSS Core Product Mgmt > > > LSS Emergency Services, GETS, & Regulatory Features Product Mgmt > > > 630-713-7162 > > > jrrosenberg@lucent.com > > > > > > > > > At 10:15 AM 3/23/2005, Ken Carlberg wrote: > > > >> you might remember the presentation by james about validation > > > of location > > > >> information. he pointed out that access network > provides location > > > >> information to the end host in such a way that the emergency > response > > > center > > > >> is able to verify that a "trusted" access network created the > > > object and > > > >> (maybe that this network is indeed reponsible for the area). > > > > > > > >James may correct me, but I would say that the scenario > you paint > above > > > >is one of authentication and integrity in the > "validation of location > > > >information". I would not consider that a case of > authorization, > since > > > >I bind that security component with usage of a service. > we may have > to > > > >chalk this up as a case of agreeing to disagree. > > > > > > > >> we had some further discussions about this issue in the > > > geopriv working > > > >> group. i also consider this as part of the > authorization decision. > > > >> there are still a number of issues that need to be > investigated and > > > >> discussed (and i am not sure that i understood all aspects; > > > >> the same is probably true for other folks as well). > > > > > > > >I have not been following geopriv as closely as I should have, > > > so I can't > > > >comment on this. > > > > > > > >> there will not be a 'must be authenticated' and 'must > be authorized' > > > >> requirement for 911/etc. calls (what we have heard so > far in the > > > >> discussions). > > > > > > > >well, my personal feeling is that users and information > should be > > > >authenticated to offer a measure confidence to others as to the > > > >validity of the user and/or the information (eg, location info) > > > >being provided. > > > > > > > >> we should also discuss what the meaning of the authorization > decision > > > in the > > > >> context you mention (rfc 2906) is. do you think about 'user x > > > is subscribed > > > >> i.e. was successfully authenticated' or 'user x has > > > sufficient funds' or > > > >> 'user x is within a specific geographical area' etc. > > > >> > > > >> i think that most people do not make an assumption about > > > authorization in > > > >> this particular area. i would like to know what type of > > > authorization the > > > >> ieprep folks consider. > > > > > > > >in my view, you are mixing components of security. a service is > > > >potentialy authorized and information in potentially > authenticated > > > >-- I say potentially because the security portion may > not be deployed. > > > > > > > >I'm probably being very picky in my terminology, but I > would say that > > > >ieprep does not consider a "type of authentication" > because that would > > > >correlate to a solution, which is not in the current charter of > ieprep. > > > > > > > >rfc-3689 from ieprep provides some general requirements > with respect > > > >to authorization/integrity/authentication, but the rfc is only a > > > >baseline starting point from which more specific > requirements can > > > >be defined within that group. it can be debated how > effective this > > > >approach was, but that was the direction we took at the time. > > > > > > > >-ken > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > >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 > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Anti-Virus. > > > Version: 7.0.308 / Virus Database: 266.8.0 - Release > Date: 3/21/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 Wed Mar 23 13:56:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19419; Wed, 23 Mar 2005 13:56:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEB7R-000773-7g; Wed, 23 Mar 2005 14:02:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEAzK-0007Bi-7g; Wed, 23 Mar 2005 13:53:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEAzJ-0007Bd-Fi for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 13:53:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19147 for ; Wed, 23 Mar 2005 13:53:50 -0500 (EST) 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.33) id 1DEB4o-000701-Sk for ecrit@ietf.org; Wed, 23 Mar 2005 13:59:36 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 23 Mar 2005 10:53:42 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2NIrdZV024317; Wed, 23 Mar 2005 10:53:39 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA10105; Wed, 23 Mar 2005 10:53:38 -0800 (PST) Message-Id: <4.3.2.7.2.20050323124748.02577758@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Mar 2005 12:53:40 -0600 To: Tschofenig Hannes , "'Ken Carlberg'" , ecrit@ietf.org From: "James M. Polk" Subject: Re: AW: [Ecrit] requirements In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 X-Spam-Score: 1.1 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d At 07:24 PM 3/23/2005 +0100, Tschofenig Hannes wrote: >maybe we just have a terminology problem here. i think that we need to >provide authentication in order to provide authorization and accountability. Are you authorized to place a 911 call with your IP phone when you're in the US? How exactly is this going to be accomplished (even in general)? And what does that have to do with routing the set-up messages to the correct ECC (which is ECRIT's charter)? I do not believe these very useful attributes are within ECRIT's current charter, so they shouldn't be the focus of so many messages on this list. >ciao >hannes 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 Wed Mar 23 14:04:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20183; Wed, 23 Mar 2005 14:04:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEBFK-0007La-D3; Wed, 23 Mar 2005 14:10:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEB9g-00006u-EB; Wed, 23 Mar 2005 14:04:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEB9f-00006l-UY for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 14:04:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20174 for ; Wed, 23 Mar 2005 14:04:34 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DEBFA-0007Ka-9u for ecrit@ietf.org; Wed, 23 Mar 2005 14:10:18 -0500 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] requirements Date: Wed, 23 Mar 2005 20:02:42 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BD1D@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] requirements Thread-Index: AcUv2mROtBSdSV4iRzKJAKA7ZMyZrQAAH+cY From: "Stastny Richard" To: "James M. Polk" , "Tschofenig Hannes" , "Ken Carlberg" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable >Are you authorized to place a 911 call with your IP phone when you're = in >the US? This is the wrong question. You MUST be able to provide an emergency call in any case, or you will = get sued the first time something happens, as Brian always said: https://mail.oefeg.at/exchweb/bin/redir.asp?URL=3Dhttp://news.com.com/Tex= as%2Bsues%2BVonage%2Bover%2B911%2Bproblem/2100-7352_3-5630118.html?tag=3D= nefd.top Authorizazion, authentication. identification, etc is only a nice to = have Richard ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von James M. Polk Gesendet: Mi 23.03.2005 19:53 An: Tschofenig Hannes; 'Ken Carlberg'; ecrit@ietf.org Betreff: Re: AW: [Ecrit] requirements At 07:24 PM 3/23/2005 +0100, Tschofenig Hannes wrote: >maybe we just have a terminology problem here. i think that we need to >provide authentication in order to provide authorization and = accountability. Are you authorized to place a 911 call with your IP phone when you're in the US? How exactly is this going to be accomplished (even in general)? And what does that have to do with routing the set-up messages to the correct ECC (which is ECRIT's charter)? I do not believe these very useful attributes are within ECRIT's current charter, so they shouldn't be the focus of so many messages on this = list. >ciao >hannes 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 23 14:11:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21034; Wed, 23 Mar 2005 14:11:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEBMF-0007YH-Nk; Wed, 23 Mar 2005 14:17:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBGa-00013T-JK; Wed, 23 Mar 2005 14:11:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBGY-00013O-Ry for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 14:11:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21027 for ; Wed, 23 Mar 2005 14:11:40 -0500 (EST) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEBM3-0007Y2-GH for ecrit@ietf.org; Wed, 23 Mar 2005 14:17:24 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j2NJBUGB011549; Wed, 23 Mar 2005 20:11:30 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j2NJBUZY000360; Wed, 23 Mar 2005 20:11:30 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Mar 2005 20:11:30 +0100 Message-ID: From: Tschofenig Hannes To: "'James M. Polk'" , "'Ken Carlberg'" , ecrit@ietf.org Subject: AW: AW: [Ecrit] requirements Date: Wed, 23 Mar 2005 20:09:29 +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: cab78e1e39c4b328567edb48482b6a69 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 hi james, > > At 07:24 PM 3/23/2005 +0100, Tschofenig Hannes wrote: > > >maybe we just have a terminology problem here. i think that > we need to > >provide authentication in order to provide authorization and > accountability. i forgot to add: "if you want to provide this functionality at all." > > Are you authorized to place a 911 call with your IP phone > when you're in > the US? > > How exactly is this going to be accomplished (even in > general)? And what > does that have to do with routing the set-up messages to the > correct ECC > (which is ECRIT's charter)? > > I do not believe these very useful attributes are within > ECRIT's current > charter, so they shouldn't be the focus of so many messages > on this list. security requirements and threats are within the scope of the charter. ciao hannes > > >ciao > >hannes > > > 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 Wed Mar 23 14:18:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21579; Wed, 23 Mar 2005 14:18:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEBSD-0007i1-WC; Wed, 23 Mar 2005 14:23:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBLx-0001UP-Nz; Wed, 23 Mar 2005 14:17:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBLv-0001UK-Ov for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 14:17:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21534 for ; Wed, 23 Mar 2005 14:17:14 -0500 (EST) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEBRS-0007h2-Gg for ecrit@ietf.org; Wed, 23 Mar 2005 14:22:58 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j2NJH9sD012343; Wed, 23 Mar 2005 20:17:09 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j2NJH9uV003877; Wed, 23 Mar 2005 20:17:09 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Mar 2005 20:17:09 +0100 Message-ID: From: Tschofenig Hannes To: "'Stastny Richard'" , "James M. Polk" , Ken Carlberg , ecrit@ietf.org Subject: AW: [Ecrit] requirements Date: Wed, 23 Mar 2005 20:15:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable hi richard,=20 you are right with your observation.=20 the issue discussed here is: if you want to provide these properties = what is the consequence for us. we also consider the usage of location information being provided with = the call even if an emergency call will be accepted without location info. = the same is true with identity information about the calling party.=20 ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Gesendet: Mittwoch, 23. M=E4rz 2005 20:03 > An: James M. Polk; Tschofenig Hannes; Ken Carlberg; ecrit@ietf.org > Betreff: Re: [Ecrit] requirements >=20 >=20 > >Are you authorized to place a 911 call with your IP phone=20 > when you're in > >the US? >=20 > This is the wrong question. >=20 > You MUST be able to provide an emergency call in any case, or=20 > you will get > sued the first time something happens, as Brian always said: >=20 > https://mail.oefeg.at/exchweb/bin/redir.asp?URL=3Dhttp://news.co > m.com/Texas%2Bsues%2BVonage%2Bover%2B911%2Bproblem/2100-7352_3 > -5630118.html?tag=3Dnefd.top >=20 > Authorizazion, authentication. identification, etc is only a=20 > nice to have >=20 > Richard >=20 >=20 >=20 > ________________________________ >=20 > Von: ecrit-bounces@ietf.org im Auftrag von James M. Polk > Gesendet: Mi 23.03.2005 19:53 > An: Tschofenig Hannes; 'Ken Carlberg'; ecrit@ietf.org > Betreff: Re: AW: [Ecrit] requirements >=20 >=20 >=20 > At 07:24 PM 3/23/2005 +0100, Tschofenig Hannes wrote: >=20 > >maybe we just have a terminology problem here. i think that=20 > we need to > >provide authentication in order to provide authorization and=20 > accountability. >=20 > Are you authorized to place a 911 call with your IP phone=20 > when you're in > the US? >=20 > How exactly is this going to be accomplished (even in=20 > general)? And what > does that have to do with routing the set-up messages to the=20 > correct ECC > (which is ECRIT's charter)? >=20 > I do not believe these very useful attributes are within=20 > ECRIT's current > charter, so they shouldn't be the focus of so many messages=20 > on this list. >=20 > >ciao > >hannes >=20 >=20 > cheers, > James >=20 > ******************* > Truth is not to be argued... it is to be presented >=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 From ecrit-bounces@ietf.org Wed Mar 23 14:19:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21852; Wed, 23 Mar 2005 14:19:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEBTz-0007mE-3W; Wed, 23 Mar 2005 14:25:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBJI-0001IH-2I; Wed, 23 Mar 2005 14:14:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBJG-0001IC-FL for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 14:14:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21210 for ; Wed, 23 Mar 2005 14:14:29 -0500 (EST) 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.33) id 1DEBOm-0007bM-5J for ecrit@ietf.org; Wed, 23 Mar 2005 14:20:13 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 23 Mar 2005 11:13:46 -0800 X-IronPort-AV: i="3.91,115,1110182400"; d="scan'208"; a="239561430:sNHT1236960950" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2NJDgDr006343; Wed, 23 Mar 2005 11:13:42 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA18826; Wed, 23 Mar 2005 11:13:41 -0800 (PST) Message-Id: <4.3.2.7.2.20050323131241.02577ae0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Mar 2005 13:13:43 -0600 To: "Stastny Richard" , "Tschofenig Hannes" , "Ken Carlberg" , From: "James M. Polk" Subject: Re: [Ecrit] requirements In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BD1D@oefeg-s04.oefeg.loc > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 X-Spam-Score: 1.1 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a At 08:02 PM 3/23/2005 +0100, Stastny Richard wrote: >Authorizazion, authentication. identification, etc is only a nice to have thank you for making my point >Richard > > > >________________________________ > >Von: ecrit-bounces@ietf.org im Auftrag von James M. Polk >Gesendet: Mi 23.03.2005 19:53 >An: Tschofenig Hannes; 'Ken Carlberg'; ecrit@ietf.org >Betreff: Re: AW: [Ecrit] requirements > > > >At 07:24 PM 3/23/2005 +0100, Tschofenig Hannes wrote: > > >maybe we just have a terminology problem here. i think that we need to > >provide authentication in order to provide authorization and accountability. > >Are you authorized to place a 911 call with your IP phone when you're in >the US? > >How exactly is this going to be accomplished (even in general)? And what >does that have to do with routing the set-up messages to the correct ECC >(which is ECRIT's charter)? > >I do not believe these very useful attributes are within ECRIT's current >charter, so they shouldn't be the focus of so many messages on this list. > > >ciao > >hannes > > >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 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 Wed Mar 23 14:21:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22013; Wed, 23 Mar 2005 14:21:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEBV9-0007oD-TI; Wed, 23 Mar 2005 14:26:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBOy-0001wt-Iz; Wed, 23 Mar 2005 14:20:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBOx-0001wV-6m for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 14:20:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21926 for ; Wed, 23 Mar 2005 14:20:21 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEBUS-0007mu-4X for ecrit@ietf.org; Wed, 23 Mar 2005 14:26:06 -0500 Received: from lion.cs.columbia.edu (IDENT:4vsfGg0e1ZAXKnRTCiW2WKANCZxUQok5@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j2NJKHqt003725 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 23 Mar 2005 14:20:18 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id j2NJKGRn029163 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 23 Mar 2005 14:20:17 -0500 Message-ID: <4241C16B.7020105@cs.columbia.edu> Date: Wed, 23 Mar 2005 14:20:11 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Ecrit] requirements References: <32755D354E6B65498C3BD9FD496C7D4613BD1D@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BD1D@oefeg-s04.oefeg.loc> 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_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit I'm afraid that we're using the terms authentication, authorization and lcoation verification far too loosely. They encompass many different questions, such as, for identity: - Did the IP address (in the UDP-based SIP request) actually place this request, and, if not, which one did? - Did the SIP URI claimed in the From header actually place the call? - What is the legal name and address of the person using that SIP address (so that I can send a cop to that residence to arrest the prank caller)? - Did the domain in the SIP From header authorize the caller to use that user name? Similarly, location verification can mean several things, all useful, but increasingly hard: - Does this address or geo coordinate exist in real life or is a probable or possible calling location? - Who provided this particular location information? (Which does not, by the way, imply that the information was provided for this particular call. I could have gotten this information from a friend or another location that I'm logged in.) - Did the call originate from that particular geo or civic address and who says so and how do they know? This will all be in more detail in the next iteration of the requirements draft. I'm sure there are more such questions and it might be more helpful to state, say, authentication or verification requirements as such questions. Stastny Richard wrote: >>Are you authorized to place a 911 call with your IP phone when you're in >>the US? > > > This is the wrong question. > > You MUST be able to provide an emergency call in any case, or you will get > sued the first time something happens, as Brian always said: > > https://mail.oefeg.at/exchweb/bin/redir.asp?URL=http://news.com.com/Texas%2Bsues%2BVonage%2Bover%2B911%2Bproblem/2100-7352_3-5630118.html?tag=nefd.top > > Authorizazion, authentication. identification, etc is only a nice to have > > Richard > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 23 14:29:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22982; Wed, 23 Mar 2005 14:29:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEBdF-000841-V0; Wed, 23 Mar 2005 14:35:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBVy-0002wh-6b; Wed, 23 Mar 2005 14:27:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBVw-0002wc-Fb for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 14:27:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22681 for ; Wed, 23 Mar 2005 14:27:34 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEBbR-0007yz-Uy for ecrit@ietf.org; Wed, 23 Mar 2005 14:33:19 -0500 Received: from lion.cs.columbia.edu (IDENT:6WO7Mp2eCDrdKb8oSt0YEfTj0du2LNJA@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j2NJRTqt004723 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 23 Mar 2005 14:27:30 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id j2NJRSRn029508 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 23 Mar 2005 14:27:28 -0500 Message-ID: <4241C31B.4080603@cs.columbia.edu> Date: Wed, 23 Mar 2005 14:27:23 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes Subject: Re: AW: [Ecrit] requirements 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_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: "Ciesla, Larry" , 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Tschofenig Hannes wrote: > hi james, > hi larry, > > based on this definition i cannot write code. > how do you ensure that the entity that assigned location information to > someone is allowed todo so? Allowed by whom? Do we assume that one has to have a license to provide such services? Who would hand out such licenses? (As far as I know, nobody has licensed Columbia University to provide telecommunication services and I guess we thus would not be able to legally provide campus-level location information.) _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 23 14:40:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24110; Wed, 23 Mar 2005 14:40:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEBoS-0008Mj-2L; Wed, 23 Mar 2005 14:46:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBeh-0004RA-R7; Wed, 23 Mar 2005 14:36:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBeg-0004R5-Sx for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 14:36:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23752 for ; Wed, 23 Mar 2005 14:36:36 -0500 (EST) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEBkC-0008GE-Bt for ecrit@ietf.org; Wed, 23 Mar 2005 14:42:21 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j2NJaOu1029594; Wed, 23 Mar 2005 20:36:24 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j2NJaOlt014110; Wed, 23 Mar 2005 20:36:24 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Mar 2005 20:36:23 +0100 Message-ID: From: Tschofenig Hannes To: "'Henning Schulzrinne'" Subject: AW: AW: [Ecrit] requirements Date: Wed, 23 Mar 2005 20:34:22 +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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: "Ciesla, Larry" , 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 hi henning, > Tschofenig Hannes wrote: > > hi james, > > hi larry, > > > > based on this definition i cannot write code. > > how do you ensure that the entity that assigned location > information to > > someone is allowed todo so? > > Allowed by whom? Do we assume that one has to have a license > to provide > such services? Who would hand out such licenses? (As far as I know, > nobody has licensed Columbia University to provide telecommunication > services and I guess we thus would not be able to legally provide > campus-level location information.) that's exactly my point. if we dig deeper into the authorization issues then we encounter various problems. ciao hannes > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 23 14:53:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25854; Wed, 23 Mar 2005 14:53:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEC0z-0000Qe-K8; Wed, 23 Mar 2005 14:59:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBqh-0005r5-6W; Wed, 23 Mar 2005 14:49:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBqf-0005qx-SI for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 14:49:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25107 for ; Wed, 23 Mar 2005 14:49:00 -0500 (EST) 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.33) id 1DEBwB-0000BZ-NI for ecrit@ietf.org; Wed, 23 Mar 2005 14:54:45 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 23 Mar 2005 11:48:51 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2NJmmZV014994; Wed, 23 Mar 2005 11:48:48 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA23052; Wed, 23 Mar 2005 11:48:47 -0800 (PST) Message-Id: <4.3.2.7.2.20050323134723.059856d8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Mar 2005 13:48:48 -0600 To: Tschofenig Hannes , "'Henning Schulzrinne'" From: "James M. Polk" Subject: Re: AW: AW: [Ecrit] requirements In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: "Ciesla, Larry" , 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 X-Spam-Score: 1.1 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb At 08:34 PM 3/23/2005 +0100, Tschofenig Hannes wrote: > > > > Allowed by whom? Do we assume that one has to have a license > > to provide > > such services? Who would hand out such licenses? (As far as I know, > > nobody has licensed Columbia University to provide telecommunication > > services and I guess we thus would not be able to legally provide > > campus-level location information.) > >that's exactly my point. >if we dig deeper into the authorization issues then we encounter various >problems. Isn't "location validation" another form of "authorized location information for usage"? Is this part of our message routing charter? >ciao >hannes > > > > >_______________________________________________ >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 Wed Mar 23 15:01:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27468; Wed, 23 Mar 2005 15:01:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEC84-0000sn-SC; Wed, 23 Mar 2005 15:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBuV-0006Ky-DM; Wed, 23 Mar 2005 14:52:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBuT-0006Kq-5G for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 14:52:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25684 for ; Wed, 23 Mar 2005 14:52:55 -0500 (EST) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEC00-0000NM-6d for ecrit@ietf.org; Wed, 23 Mar 2005 14:58:40 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j2NJqqAl005680; Wed, 23 Mar 2005 20:52:52 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j2NJqqMI022966; Wed, 23 Mar 2005 20:52:52 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Mar 2005 20:52:52 +0100 Message-ID: From: Tschofenig Hannes To: "'Henning Schulzrinne'" , Stastny Richard Subject: AW: [Ecrit] requirements Date: Wed, 23 Mar 2005 20:50:51 +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: 10d3e4e3c32e363f129e380e644649be 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 hi henning, > I'm afraid that we're using the terms authentication, > authorization and > lcoation verification far too loosely. certainly true. > They encompass many different > questions, such as, for identity: > > - Did the IP address (in the UDP-based SIP request) actually > place this > request, and, if not, which one did? > > - Did the SIP URI claimed in the From header actually place the call? > > - What is the legal name and address of the person using that SIP > address (so that I can send a cop to that residence to arrest > the prank > caller)? > > - Did the domain in the SIP From header authorize the caller > to use that > user name? > > Similarly, location verification can mean several things, all useful, > but increasingly hard: > > - Does this address or geo coordinate exist in real life or is a > probable or possible calling location? > > - Who provided this particular location information? (Which > does not, by > the way, imply that the information was provided for this particular > call. I could have gotten this information from a friend or another > location that I'm logged in.) .. or eavesdropped another protocol exchange or reused from a previous network access authentication session. yes. binding the different context together is quite difficult. we noticed this in other places already. > > - Did the call originate from that particular geo or civic > address and > who says so and how do they know? > > This will all be in more detail in the next iteration of the > requirements draft. I'm sure there are more such questions > and it might > be more helpful to state, say, authentication or verification > requirements as such questions. i like this level of detail. ciao hannes > > > Stastny Richard wrote: > >>Are you authorized to place a 911 call with your IP phone > when you're in > >>the US? > > > > > > This is the wrong question. > > > > You MUST be able to provide an emergency call in any case, > or you will get > > sued the first time something happens, as Brian always said: > > > > > https://mail.oefeg.at/exchweb/bin/redir.asp?URL=http://news.co m.com/Texas%2Bsues%2BVonage%2Bover%2B911%2Bproblem/2100-7352_3-5630118.html? tag=nefd.top > > Authorizazion, authentication. identification, etc is only a nice to have > > 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 Wed Mar 23 15:02:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27668; Wed, 23 Mar 2005 15:02:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEC9a-0000wI-Pr; Wed, 23 Mar 2005 15:08:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEC3d-0000xP-Nu; Wed, 23 Mar 2005 15:02:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEC3c-0000xE-GK for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 15:02:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27597 for ; Wed, 23 Mar 2005 15:02:22 -0500 (EST) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEC98-0000vS-0X for ecrit@ietf.org; Wed, 23 Mar 2005 15:08:07 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j2NK1ExJ013609; Wed, 23 Mar 2005 21:01:14 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j2NK1EL6027232; Wed, 23 Mar 2005 21:01:14 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Mar 2005 21:01:14 +0100 Message-ID: From: Tschofenig Hannes To: "'James M. Polk'" , "'Henning Schulzrinne'" Subject: AW: AW: AW: [Ecrit] requirements Date: Wed, 23 Mar 2005 20:59:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: "Ciesla, Larry" , 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable hi james,=20 since our terminology on these issues i pretty messy it is difficult to = say what it is.=20 i like the detailed questions listed in henning's previous mail. they = do not focus on a particular term but instead they list certain properties. = looking on these properties makes everything simpler for us. =20 is this reasonable?=20 ciao hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: James M. Polk [mailto:jmpolk@cisco.com]=20 > Gesendet: Mittwoch, 23. M=E4rz 2005 20:49 > An: Tschofenig Hannes; 'Henning Schulzrinne' > Cc: Ciesla, Larry; ecrit@ietf.org > Betreff: Re: AW: AW: [Ecrit] requirements >=20 >=20 > At 08:34 PM 3/23/2005 +0100, Tschofenig Hannes wrote: >=20 > > > > > > Allowed by whom? Do we assume that one has to have a license > > > to provide > > > such services? Who would hand out such licenses? (As far=20 > as I know, > > > nobody has licensed Columbia University to provide=20 > telecommunication > > > services and I guess we thus would not be able to legally provide > > > campus-level location information.) > > > >that's exactly my point. > >if we dig deeper into the authorization issues then we=20 > encounter various > >problems. >=20 > Isn't "location validation" another form of "authorized location=20 > information for usage"? >=20 > Is this part of our message routing charter? >=20 >=20 > >ciao > >hannes > > > > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > cheers, > James >=20 > ******************* > Truth is not to be argued... it is to be presented >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 23 15:46:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02713; Wed, 23 Mar 2005 15:46:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DECpZ-00021k-MK; Wed, 23 Mar 2005 15:51:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DECi0-0006wf-Am; Wed, 23 Mar 2005 15:44:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEChv-0006wa-HJ for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 15:44:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02525 for ; Wed, 23 Mar 2005 15:44:00 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DECnR-0001xy-FO for ecrit@ietf.org; Wed, 23 Mar 2005 15:49:46 -0500 Received: from lion.cs.columbia.edu (IDENT:tolZwL/W6VuUzWgGaL/8PODdroC2FAV/@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j2NKhvqt017894 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 23 Mar 2005 15:43:58 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id j2NKhvRn002032 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 23 Mar 2005 15:43:57 -0500 Message-ID: <4241D508.9030906@cs.columbia.edu> Date: Wed, 23 Mar 2005 15:43:52 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Abbott, Nadine B." Subject: Re: [Ecrit] requirements 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_VERSION 0, __SANE_MSGID 0' 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit > I think that "authentication" of location information relates mainly to > accountability of the originating service provider responsible for > populating the location information. There may not be a service provider in the traditional sense, at least if you mean voice service provider. (Another instance where, I believe, we should try for more precise terminology in our discourse. Brian has suggested a few terms, something like VSP - voice service provider [which might be a cafe or a private residence] ISP - Internet service provider IAP - Internet access provider) _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 23 16:44:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15824; Wed, 23 Mar 2005 16:44:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEDkP-0006LT-3q; Wed, 23 Mar 2005 16:50:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEDeT-0007Jr-WE; Wed, 23 Mar 2005 16:44:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEDeN-0007GM-V3 for ecrit@megatron.ietf.org; Wed, 23 Mar 2005 16:44:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15502 for ; Wed, 23 Mar 2005 16:44:24 -0500 (EST) Received: from smtp.hsia.fairmont.com ([142.131.15.59] helo=torntsims03.hsia.fairmont.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEDjj-0006EU-Qw for ecrit@ietf.org; Wed, 23 Mar 2005 16:50:01 -0500 Received: from localhost.localdomain (unverified [66.120.92.34]) by torntsims03.hsia.fairmont.com (Vircom SMTPRS 3.2.315.0) with ESMTP id ; Wed, 23 Mar 2005 16:30:11 -0500 Received: from BROSENLT ([142.131.191.101]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id j2NLhnO16741; Wed, 23 Mar 2005 13:43:49 -0800 Message-Id: <200503232143.j2NLhnO16741@localhost.localdomain> From: "Brian Rosen" To: "'Tschofenig Hannes'" , "'James Winterbottom'" , "'Ciesla, Larry'" , Subject: RE: [Ecrit] requirements Date: Wed, 23 Mar 2005 16:43:44 -0500 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.2180 Thread-Index: AcUv0WY+0TzStJ5jR3CRexFKXXCTXgABa6mg In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Content-Transfer-Encoding: quoted-printable One interesting observation on that subject is that the LIS has to have = a "local" component; that is, a LIS that provides location for a part of Denmark has calls sent to the PSAP in Denmark. A LIS could cover a large area, but it is serving entities that are physically in the location where the PSAP that gets the calls are = located. This means that the PSAP could authorize a LIS. More reasonably, an organization, on a national or regional basis could authorize LIS's that serve that area. Authorize, I think, means giving them a cert. They use that cert to = sign the location object, which fills a couple of needs. Having said that, I think that it is very difficult to make the quality = of the cert be really good, because every enterprise above some size has to = run a LIS, and it's pretty hard to qualify enterprises. Not quite the same = as making a global PKI, but still pretty tough. I think that problem is there, but I still think the best approach is to give LIS's a cert and let them sign the location (and, BTW include a timestamp). Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of > Tschofenig Hannes > Sent: Wednesday, March 23, 2005 12:47 PM > To: 'James Winterbottom'; Ciesla, Larry; ecrit@ietf.org > Subject: AW: [Ecrit] requirements >=20 > hi james, > hi larry, >=20 > based on this definition i cannot write code. > how do you ensure that the entity that assigned location information = to > someone is allowed todo so? > do you assume that there is an access control list that says: "if > identity(access network) =3D=3D "company x" then accept"? >=20 > ciao > hannes >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] Im Auftrag = von > James Winterbottom > Gesendet: Mittwoch, 23. M=E4rz 2005 18:17 > An: Ciesla, Larry; ecrit@ietf.org > Betreff: RE: [Ecrit] requirements >=20 >=20 > Larry, > That is the definition that I have been using. > Cheers > James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of > Ciesla, Larry > Sent: Thursday, 24 March 2005 3:39 AM > To: jrrosenberg@lucent.com; carlberg@g11.org.uk; > hannes.tschofenig@siemens.com; ecrit@ietf.org > Subject: Re: [Ecrit] requirements >=20 >=20 > In fact, a user does not even need paid phone service for 911 to work > today. > Both wireline and wireless phones will allow 911 to work for = unsubscribed > phones. Perhaps the notion of authorization should be viewed in the > context > that the entity assigning location information to a phone should be > authorized to do so. > Regards > Larry Ciesla >=20 >=20 >=20 > ***This message has been sent via the Intrado Wireless Information > Network.*** > -----Original Message----- > From: ecrit-bounces@ietf.org > To: Ken Carlberg ; 'Tschofenig Hannes' > ; ecrit@ietf.org > Sent: Wed Mar 23 09:28:10 2005 > Subject: RE: [Ecrit] requirements > All - > I think the basic question being asked deals with two (or more) = different > flavors under the umbrella of Emergency Services. Two existing = examples > are: >=20 > o B/E911 in the US - does not require that the "caller" be = authorized, > or > even identified (most 911 systems today are required to provide = anonymous > access); > o GETS (Government Emergency Telecommunications Service) in the US, > which > can only be used by authorized users - uses PIN mechanism something = like a > calling card to allow the caller to authenticate. > I think the original e-mail was asking for a specific requirement for > ecrit > (911 service domain) stating that "caller" MUST NOT be required to be > pre-authorized or to have to authenticate in order to place an = emergency > service (e.g. 911-type) call. > John > ------------------------ > John Rosenberg > Lucent Technologies > LSS Core Product Mgmt > LSS Emergency Services, GETS, & Regulatory Features Product Mgmt > 630-713-7162 jrrosenberg@lucent.com >=20 >=20 > At 10:15 AM 3/23/2005, Ken Carlberg wrote: > >> you might remember the presentation by james about validation of > location >> information. he pointed out that access network provides > location >> information to the end host in such a way that the = emergency > response > center > >> is able to verify that a "trusted" access network created the = object > and > >> (maybe that this network is indeed reponsible for the area). > = >James > may correct me, but I would say that the scenario you paint above >is = one > of authentication and integrity in the "validation of location > >information". I would not consider that a case of authorization, = since > >I > bind that security component with usage of a service. we may have to > >chalk this up as a case of agreeing to disagree. > >> we had some > further > discussions about this issue in the geopriv working >> group. i also > consider this as part of the authorization decision. >> there are = still a > number of issues that need to be investigated and >> discussed (and i = am > not sure that i understood all aspects; >> the same is probably true = for > other folks as well). > >I have not been following geopriv as = closely as > I > should have, so I can't >comment on this. > >> there will not be a > 'must > be authenticated' and 'must be authorized' >> requirement for = 911/etc. > calls (what we have heard so far in the >> discussions). > >well, = my > personal feeling is that users and information should be = >authenticated > to > offer a measure confidence to others as to the >validity of the user > and/or > the information (eg, location info) >being provided. > >> we should > also > discuss what the meaning of the authorization decision > in the > >> context you mention (rfc 2906) is. do you think about 'user x is > subscribed >> i.e. was successfully authenticated' or 'user x has > sufficient funds' or >> 'user x is within a specific geographical = area' > etc. >> >> i think that most people do not make an assumption about > authorization in >> this particular area. i would like to know what = type > of > authorization the >> ieprep folks consider. > >in my view, you are > mixing > components of security. a service is >potentialy authorized and > information in potentially authenticated > >-- I say potentially because the security portion may not be = deployed. > > > >I'm probably being very picky in my terminology, but I would say that > >ieprep does not consider a "type of authentication" because that = would > >correlate to a solution, which is not in the current charter of = ieprep. > > > >rfc-3689 from ieprep provides some general requirements with respect = >to > authorization/integrity/authentication, but the rfc is only a = >baseline > starting point from which more specific requirements can >be defined > within > that group. it can be debated how effective this >approach was, but = that > was the direction we took at the time. > >-ken > > > > > >_______________________________________________ > >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 > _______________________________________________ > 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 Thu Mar 24 09:59:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18968; Thu, 24 Mar 2005 09:59:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DETtd-000607-18; Thu, 24 Mar 2005 10:05:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DETmI-0001uH-AE; Thu, 24 Mar 2005 09:57:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DETmG-0001u1-Q6 for ecrit@megatron.ietf.org; Thu, 24 Mar 2005 09:57:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18839 for ; Thu, 24 Mar 2005 09:57:39 -0500 (EST) 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.33) id 1DETrw-0005xr-TI for ecrit@ietf.org; Thu, 24 Mar 2005 10:03:34 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 24 Mar 2005 06:57:33 -0800 Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2OEvSDr026161; Thu, 24 Mar 2005 06:57:29 -0800 (PST) Received: from MLINSNER (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA16692; Thu, 24 Mar 2005 06:57:29 -0800 (PST) Message-Id: <200503241457.GAA16692@malone.cisco.com> From: "Marc Linsner" To: "'James M. Polk'" , Subject: RE: AW: AW: [Ecrit] requirements Date: Thu, 24 Mar 2005 09:57:19 -0500 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: <4.3.2.7.2.20050323134723.059856d8@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Thread-Index: AcUv4h1DI3ClEXwUSGu8s4/JSvmLTgAnQBjg X-Spam-Score: 1.1 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit > > Isn't "location validation" another form of "authorized location > information for usage"? No, location validation has nothing to do with authorization (don't read the words, understand the meaning). It's a simple process of verifying that the location I have is able to route to a psap. -Marc- > > Is this part of our message routing charter? > > > >ciao > >hannes > > > > > > > > >_______________________________________________ > >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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 24 10:00:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19084; Thu, 24 Mar 2005 10:00:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DETue-00063I-K3; Thu, 24 Mar 2005 10:06:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DETmG-0001tw-2q; Thu, 24 Mar 2005 09:57:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DETmF-0001tr-DZ for ecrit@megatron.ietf.org; Thu, 24 Mar 2005 09:57:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18834 for ; Thu, 24 Mar 2005 09:57:37 -0500 (EST) 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.33) id 1DETrv-0005xr-Ub for ecrit@ietf.org; Thu, 24 Mar 2005 10:03:32 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 24 Mar 2005 06:57:29 -0800 Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2OEvRZV006778 for ; Thu, 24 Mar 2005 06:57:27 -0800 (PST) Received: from MLINSNER (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA16647 for ; Thu, 24 Mar 2005 06:57:26 -0800 (PST) Message-Id: <200503241457.GAA16647@malone.cisco.com> From: "Marc Linsner" To: Subject: RE: [Ecrit] requirements Date: Thu, 24 Mar 2005 09:57:19 -0500 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: <200503232143.j2NLhnO16741@localhost.localdomain> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Thread-Index: AcUv0WY+0TzStJ5jR3CRexFKXXCTXgABa6mgACnIx4A= X-Spam-Score: 1.1 (+) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 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 X-Spam-Score: 1.1 (+) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f Content-Transfer-Encoding: quoted-printable So, for ecrit - we are going to work with the pidf-lo, signed or not. = It is not the responsibility of a protocol to enforce the 'lo must be signed' policy. When the call arrives at a psap that requires a signed lo, they = can do with it what they wish. A signed pidf-lo is geopriv's issue. Ecrit will figure out how to identify an emergency call, route the call = to the psap of choice and provide a mechanism for a client to 'validate' = that the/a location in their pidf-lo is capable of reaching a psap should = they so desire. Correct? -Marc- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of > Brian Rosen > Sent: Wednesday, March 23, 2005 4:44 PM > To: 'Tschofenig Hannes'; 'James Winterbottom'; 'Ciesla, Larry'; > ecrit@ietf.org > Subject: RE: [Ecrit] requirements >=20 > One interesting observation on that subject is that the LIS has to = have a > "local" component; that is, a LIS that provides location for a part of > Denmark has calls sent to the PSAP in Denmark. >=20 > A LIS could cover a large area, but it is serving entities that are > physically in the location where the PSAP that gets the calls are = located. >=20 > This means that the PSAP could authorize a LIS. > More reasonably, an organization, on a national or regional basis = could > authorize LIS's that serve that area. >=20 > Authorize, I think, means giving them a cert. They use that cert to = sign > the location object, which fills a couple of needs. >=20 > Having said that, I think that it is very difficult to make the = quality of > the cert be really good, because every enterprise above some size has = to > run > a LIS, and it's pretty hard to qualify enterprises. Not quite the = same as > making a global PKI, but still pretty tough. >=20 > I think that problem is there, but I still think the best approach is = to > give LIS's a cert and let them sign the location (and, BTW include a > timestamp). >=20 > Brian >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf > Of > > Tschofenig Hannes > > Sent: Wednesday, March 23, 2005 12:47 PM > > To: 'James Winterbottom'; Ciesla, Larry; ecrit@ietf.org > > Subject: AW: [Ecrit] requirements > > > > hi james, > > hi larry, > > > > based on this definition i cannot write code. > > how do you ensure that the entity that assigned location information = to > > someone is allowed todo so? > > do you assume that there is an access control list that says: "if > > identity(access network) =3D=3D "company x" then accept"? > > > > ciao > > hannes > > > > > > > > -----Urspr=FCngliche Nachricht----- > > Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] Im = Auftrag > von > > James Winterbottom > > Gesendet: Mittwoch, 23. M=E4rz 2005 18:17 > > An: Ciesla, Larry; ecrit@ietf.org > > Betreff: RE: [Ecrit] requirements > > > > > > Larry, > > That is the definition that I have been using. > > Cheers > > James > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf > Of > > Ciesla, Larry > > Sent: Thursday, 24 March 2005 3:39 AM > > To: jrrosenberg@lucent.com; carlberg@g11.org.uk; > > hannes.tschofenig@siemens.com; ecrit@ietf.org > > Subject: Re: [Ecrit] requirements > > > > > > In fact, a user does not even need paid phone service for 911 to = work > > today. > > Both wireline and wireless phones will allow 911 to work for > unsubscribed > > phones. Perhaps the notion of authorization should be viewed in the > > context > > that the entity assigning location information to a phone should be > > authorized to do so. > > Regards > > Larry Ciesla > > > > > > > > ***This message has been sent via the Intrado Wireless Information > > Network.*** > > -----Original Message----- > > From: ecrit-bounces@ietf.org > > To: Ken Carlberg ; 'Tschofenig Hannes' > > ; ecrit@ietf.org > > Sent: Wed Mar 23 09:28:10 2005 > > Subject: RE: [Ecrit] requirements > > All - > > I think the basic question being asked deals with two (or more) > different > > flavors under the umbrella of Emergency Services. Two existing = examples > > are: > > > > o B/E911 in the US - does not require that the "caller" be = authorized, > > or > > even identified (most 911 systems today are required to provide > anonymous > > access); > > o GETS (Government Emergency Telecommunications Service) in the = US, > > which > > can only be used by authorized users - uses PIN mechanism something = like > a > > calling card to allow the caller to authenticate. > > I think the original e-mail was asking for a specific requirement = for > > ecrit > > (911 service domain) stating that "caller" MUST NOT be required to = be > > pre-authorized or to have to authenticate in order to place an = emergency > > service (e.g. 911-type) call. > > John > > ------------------------ > > John Rosenberg > > Lucent Technologies > > LSS Core Product Mgmt > > LSS Emergency Services, GETS, & Regulatory Features Product Mgmt > > 630-713-7162 jrrosenberg@lucent.com > > > > > > At 10:15 AM 3/23/2005, Ken Carlberg wrote: > > >> you might remember the presentation by james about validation of > > location >> information. he pointed out that access network = provides > > location >> information to the end host in such a way that the > emergency > > response > > center > > >> is able to verify that a "trusted" access network created the = object > > and > > >> (maybe that this network is indeed reponsible for the area). > > >James > > may correct me, but I would say that the scenario you paint above = >is > one > > of authentication and integrity in the "validation of location > > >information". I would not consider that a case of authorization, = since > > >I > > bind that security component with usage of a service. we may have = to > > >chalk this up as a case of agreeing to disagree. > >> we had some > > further > > discussions about this issue in the geopriv working >> group. i = also > > consider this as part of the authorization decision. >> there are = still > a > > number of issues that need to be investigated and >> discussed (and = i > am > > not sure that i understood all aspects; >> the same is probably = true > for > > other folks as well). > >I have not been following geopriv as = closely > as > > I > > should have, so I can't >comment on this. > >> there will not be = a > > 'must > > be authenticated' and 'must be authorized' >> requirement for = 911/etc. > > calls (what we have heard so far in the >> discussions). > >well, = my > > personal feeling is that users and information should be = >authenticated > > to > > offer a measure confidence to others as to the >validity of the = user > > and/or > > the information (eg, location info) >being provided. > >> we = should > > also > > discuss what the meaning of the authorization decision > > in the > > >> context you mention (rfc 2906) is. do you think about 'user x is > > subscribed >> i.e. was successfully authenticated' or 'user x has > > sufficient funds' or >> 'user x is within a specific geographical = area' > > etc. >> >> i think that most people do not make an assumption = about > > authorization in >> this particular area. i would like to know what > type > > of > > authorization the >> ieprep folks consider. > >in my view, you = are > > mixing > > components of security. a service is >potentialy authorized and > > information in potentially authenticated > > >-- I say potentially because the security portion may not be = deployed. > > > > > >I'm probably being very picky in my terminology, but I would say = that > > >ieprep does not consider a "type of authentication" because that = would > > >correlate to a solution, which is not in the current charter of = ieprep. > > > > > >rfc-3689 from ieprep provides some general requirements with = respect > >to > > authorization/integrity/authentication, but the rfc is only a = >baseline > > starting point from which more specific requirements can >be = defined > > within > > that group. it can be debated how effective this >approach was, = but > that > > was the direction we took at the time. > >-ken > > > > > > >_______________________________________________ > > >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 > > >=20 >=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 Thu Mar 24 11:03:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26985; Thu, 24 Mar 2005 11:03:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEUu1-0008CX-D7; Thu, 24 Mar 2005 11:09:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEUmN-0002i2-Pr; Thu, 24 Mar 2005 11:01:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEUmM-0002ho-QC for ecrit@megatron.ietf.org; Thu, 24 Mar 2005 11:01:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26815 for ; Thu, 24 Mar 2005 11:01:47 -0500 (EST) Received: from [199.117.205.100] (helo=ns2.sccx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEUs1-00087y-2s for ecrit@ietf.org; Thu, 24 Mar 2005 11:07:43 -0500 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] RE: [Ecru] requirements X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 24 Mar 2005 09:51:35 -0600 Message-ID: <422D410BD61FC04185076AD99AA7207AB792E5@inilmx01.lgmt.trdo> Thread-Topic: [Ecrit] RE: [Ecru] requirements Thread-Index: AcUvzv1WJ59P37Z4RT6b3ISUIQfC8QABgB7QACxa0FA= From: "Ciesla, Larry" To: "Medhavi Bhatia" , "Byron Smith" , X-OriginalArrivalTime: 24 Mar 2005 15:51:38.0010 (UTC) FILETIME=[5D12E7A0:01C53089] X-Spam-Score: 0.0 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Content-Transfer-Encoding: quoted-printable It may help to understand three critical things happen when someone dials 911, and I believe most in public safety would agree that the criticality of each of these is in the order I show below: 1. A voice connection is established with a 9-1-1 call-taker responsible for emergency calls in the physical region in which the caller is located. The ability to communicate verbally is obviously the most critical aspect of dialing 911. 2. The location of the caller is displayed to the 9-1-1 call-taker. Call-takers are trained to always verify that the location presented is, in fact, the location of the emergency. =20 3. The telephone number of the phone that originated the call is presented to the call-taker. The latter is only used if the caller hangs up and the 9-1-1 call-taker needs to call back. I'm not sure that in the context of a DoS attack, attempting to call caller's back would only make the problem worse. The thing is, unlike a DoS attack on some computer where millions of attempts are necessary to render the computer useless, most PSAPs have two or three 9-1-1 call takers. By comparison, a tiny number of attacks on a PSAP could take it out of service. I sure hope the collective intelligence of all the smart people trying to figure this out can find a way to prevent this. Larry Ciesla Senior Technical Officer > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Medhavi Bhatia > Sent: Wednesday, March 23, 2005 1:25 PM > To: 'Byron Smith'; ecrit@ietf.org > Subject: RE: [Ecrit] RE: [Ecru] requirements >=20 > I saw some discussion on one of the ETSI lists on requirements and work on > handling calls from unauthorized callers (without valid USIM). I think > they > are looking at it as well. Your point of having to call the caller back is > important to prevent something like a DoS attack on the emergency service > provider. Will the ability to call the caller back (which means that the > wireless SP should be able to call a phone not on its network...) and > locate > the origination be enough to deter attacks that authentication may not be > necessary ? Not sure how this can be done. >=20 >=20 > -Medhavi. >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > Byron Smith > > Sent: Wednesday, March 23, 2005 12:35 PM > > To: ecrit@ietf.org > > Subject: [Ecrit] RE: [Ecru] requirements > > > > Actually many/most unsubscribed wireline phones may NOT dial 911. State > law > > may apply. It depends on the policy (and sometimes, the equipment) of > the > > local service provider. There are many problems with unsubscribed > wireline > > 911, including incorrect routing and no associated ALI record. > > > > The FCC requires unsubscribed wireless phones be able to dial 911. > However, > > this is also problematic, because, in general, the PSAP cannot call back > the > > unsubscribed phone, and because there may be no way, in general, to > trace > > the "owner" of the phone. Several PSAPs have been the victim of > > multiple/recurring "crank" 911 calls from unsubscribed (anonymous) > wireless > > phones. It can be a serious problem. > > > > Byron > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf > Of > > > Ciesla, Larry > > > Sent: Wednesday, March 23, 2005 11:39 AM > > > To: jrrosenberg@lucent.com; carlberg@g11.org.uk; > > > hannes.tschofenig@siemens.com; ecrit@ietf.org > > > Subject: Re: [Ecrit] requirements > > > > > > > > > In fact, a user does not even need paid phone service for 911 to > > > work today. Both wireline and wireless phones will allow 911 to > > > work for unsubscribed phones. Perhaps the notion of > > > authorization should be viewed in the context that the entity > > > assigning location information to a phone should be authorized to do > so. > > > > > > Regards > > > > > > Larry Ciesla > > > > > > > > > > > > ***This message has been sent via the Intrado Wireless > > > Information Network.*** > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > > To: Ken Carlberg ; 'Tschofenig Hannes' > > > ; ecrit@ietf.org > > > Sent: Wed Mar 23 09:28:10 2005 > > > Subject: RE: [Ecrit] requirements > > > > > > All - > > > > > > I think the basic question being asked deals with two (or more) > different > > > flavors under the umbrella of Emergency Services. Two existing > > > examples are: > > > > > > o B/E911 in the US - does not require that the "caller" be > > > authorized, or > > > even identified (most 911 systems today are required to provide > anonymous > > > access); > > > > > > o GETS (Government Emergency Telecommunications Service) in the > > > US, which > > > can only be used by authorized users - uses PIN mechanism > > > something like a > > > calling card to allow the caller to authenticate. > > > > > > I think the original e-mail was asking for a specific requirement > > > for ecrit > > > (911 service domain) stating that "caller" MUST NOT be required to be > > > pre-authorized or to have to authenticate in order to place an > emergency > > > service (e.g. 911-type) call. > > > > > > John > > > > > > ------------------------ > > > John Rosenberg > > > Lucent Technologies > > > LSS Core Product Mgmt > > > LSS Emergency Services, GETS, & Regulatory Features Product Mgmt > > > 630-713-7162 > > > jrrosenberg@lucent.com > > > > > > > > > At 10:15 AM 3/23/2005, Ken Carlberg wrote: > > > >> you might remember the presentation by james about validation > > > of location > > > >> information. he pointed out that access network provides location > > > >> information to the end host in such a way that the emergency > response > > > center > > > >> is able to verify that a "trusted" access network created the > > > object and > > > >> (maybe that this network is indeed reponsible for the area). > > > > > > > >James may correct me, but I would say that the scenario you paint > above > > > >is one of authentication and integrity in the "validation of > location > > > >information". I would not consider that a case of authorization, > since > > > >I bind that security component with usage of a service. we may have > to > > > >chalk this up as a case of agreeing to disagree. > > > > > > > >> we had some further discussions about this issue in the > > > geopriv working > > > >> group. i also consider this as part of the authorization decision. > > > >> there are still a number of issues that need to be investigated > and > > > >> discussed (and i am not sure that i understood all aspects; > > > >> the same is probably true for other folks as well). > > > > > > > >I have not been following geopriv as closely as I should have, > > > so I can't > > > >comment on this. > > > > > > > >> there will not be a 'must be authenticated' and 'must be > authorized' > > > >> requirement for 911/etc. calls (what we have heard so far in the > > > >> discussions). > > > > > > > >well, my personal feeling is that users and information should be > > > >authenticated to offer a measure confidence to others as to the > > > >validity of the user and/or the information (eg, location info) > > > >being provided. > > > > > > > >> we should also discuss what the meaning of the authorization > decision > > > in the > > > >> context you mention (rfc 2906) is. do you think about 'user x > > > is subscribed > > > >> i.e. was successfully authenticated' or 'user x has > > > sufficient funds' or > > > >> 'user x is within a specific geographical area' etc. > > > >> > > > >> i think that most people do not make an assumption about > > > authorization in > > > >> this particular area. i would like to know what type of > > > authorization the > > > >> ieprep folks consider. > > > > > > > >in my view, you are mixing components of security. a service is > > > >potentialy authorized and information in potentially authenticated > > > >-- I say potentially because the security portion may not be > deployed. > > > > > > > >I'm probably being very picky in my terminology, but I would say > that > > > >ieprep does not consider a "type of authentication" because that > would > > > >correlate to a solution, which is not in the current charter of > ieprep. > > > > > > > >rfc-3689 from ieprep provides some general requirements with respect > > > >to authorization/integrity/authentication, but the rfc is only a > > > >baseline starting point from which more specific requirements can > > > >be defined within that group. it can be debated how effective this > > > >approach was, but that was the direction we took at the time. > > > > > > > >-ken > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > >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 > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Anti-Virus. > > > Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 3/21/2005 > > > > > > > > > _______________________________________________ > > 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 24 11:45:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01996; Thu, 24 Mar 2005 11:45:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEVYI-0001Jw-87; Thu, 24 Mar 2005 11:51:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEVRV-0001I8-GG; Thu, 24 Mar 2005 11:44:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEVRT-0001I0-0Y for ecrit@megatron.ietf.org; Thu, 24 Mar 2005 11:44:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01914 for ; Thu, 24 Mar 2005 11:44:16 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEVXA-0001GL-CV for ecrit@ietf.org; Thu, 24 Mar 2005 11:50:13 -0500 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 j2OGhwp21913; Thu, 24 Mar 2005 10:43:58 -0600 (CST) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Mar 2005 03:43:58 +1100 Message-ID: From: "James Winterbottom" To: Marc Linsner , ecrit@ietf.org Subject: RE: [Ecrit] requirements Date: Fri, 25 Mar 2005 03:43:50 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: fc33afc280b74ce7916a8c9e6ab57db8 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="===============2079665503==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: cadb9ba0ba1c1ba4f99ac017158fabc3 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. --===============2079665503== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53090.A839BDEC" 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_01C53090.A839BDEC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hey Marc, Agree with the sentiment. Strongly recommend that we put BOTH a = definition for validated and a definition for authenticated in the document = though, so that this misunderstanding does not continue to propagate. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Marc Linsner Sent: Friday, 25 March 2005 1:57 AM To: ecrit@ietf.org Subject: RE: [Ecrit] requirements So, for ecrit - we are going to work with the pidf-lo, signed or not. = It is not the responsibility of a protocol to enforce the 'lo must be signed' policy. When the call arrives at a psap that requires a signed lo, = they can do with it what they wish. A signed pidf-lo is geopriv's issue. Ecrit will figure out how to identify an emergency call, route the call = to the psap of choice and provide a mechanism for a client to 'validate' = that the/a location in their pidf-lo is capable of reaching a psap should = they so desire. Correct? -Marc- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf=20 > Of Brian Rosen > Sent: Wednesday, March 23, 2005 4:44 PM > To: 'Tschofenig Hannes'; 'James Winterbottom'; 'Ciesla, Larry';=20 > ecrit@ietf.org > Subject: RE: [Ecrit] requirements >=20 > One interesting observation on that subject is that the LIS has to=20 > have a "local" component; that is, a LIS that provides location for a = > part of Denmark has calls sent to the PSAP in Denmark. >=20 > A LIS could cover a large area, but it is serving entities that are=20 > physically in the location where the PSAP that gets the calls are=20 > located. >=20 > This means that the PSAP could authorize a LIS. > More reasonably, an organization, on a national or regional basis=20 > could authorize LIS's that serve that area. >=20 > Authorize, I think, means giving them a cert. They use that cert to=20 > sign the location object, which fills a couple of needs. >=20 > Having said that, I think that it is very difficult to make the=20 > quality of the cert be really good, because every enterprise above=20 > some size has to run a LIS, and it's pretty hard to qualify=20 > enterprises. Not quite the same as making a global PKI, but still=20 > pretty tough. >=20 > I think that problem is there, but I still think the best approach is = > to give LIS's a cert and let them sign the location (and, BTW include = > a timestamp). >=20 > Brian >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > > Behalf > Of > > Tschofenig Hannes > > Sent: Wednesday, March 23, 2005 12:47 PM > > To: 'James Winterbottom'; Ciesla, Larry; ecrit@ietf.org > > Subject: AW: [Ecrit] requirements > > > > hi james, > > hi larry, > > > > based on this definition i cannot write code. > > how do you ensure that the entity that assigned location = information=20 > > to someone is allowed todo so? do you assume that there is an = access=20 > > control list that says: "if identity(access network) =3D=3D = "company x"=20 > > then accept"? > > > > ciao > > hannes > > > > > > > > -----Urspr=FCngliche Nachricht----- > > Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] Im=20 > > Auftrag > von > > James Winterbottom > > Gesendet: Mittwoch, 23. M=E4rz 2005 18:17 > > An: Ciesla, Larry; ecrit@ietf.org > > Betreff: RE: [Ecrit] requirements > > > > > > Larry, > > That is the definition that I have been using. > > Cheers > > James > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > > Behalf > Of > > Ciesla, Larry > > Sent: Thursday, 24 March 2005 3:39 AM > > To: jrrosenberg@lucent.com; carlberg@g11.org.uk;=20 > > hannes.tschofenig@siemens.com; ecrit@ietf.org > > Subject: Re: [Ecrit] requirements > > > > > > In fact, a user does not even need paid phone service for 911 to=20 > > work today. Both wireline and wireless phones will allow 911 to = work=20 > > for > unsubscribed > > phones. Perhaps the notion of authorization should be viewed in = the=20 > > context that the entity assigning location information to a phone=20 > > should be authorized to do so. > > Regards > > Larry Ciesla > > > > > > > > ***This message has been sent via the Intrado Wireless Information > > Network.*** > > -----Original Message----- > > From: ecrit-bounces@ietf.org > > To: Ken Carlberg ; 'Tschofenig Hannes'=20 > > ; ecrit@ietf.org > > Sent: Wed Mar 23 09:28:10 2005 > > Subject: RE: [Ecrit] requirements > > All - > > I think the basic question being asked deals with two (or more) > different > > flavors under the umbrella of Emergency Services. Two existing=20 > > examples > > are: > > > > o B/E911 in the US - does not require that the "caller" be=20 > > authorized, or even identified (most 911 systems today are required = > > to provide > anonymous > > access); > > o GETS (Government Emergency Telecommunications Service) in the=20 > > US, which can only be used by authorized users - uses PIN mechanism = > > something like > a > > calling card to allow the caller to authenticate. > > I think the original e-mail was asking for a specific requirement=20 > > for ecrit (911 service domain) stating that "caller" MUST NOT be=20 > > required to be pre-authorized or to have to authenticate in order = to=20 > > place an emergency service (e.g. 911-type) call. > > John > > ------------------------ > > John Rosenberg > > Lucent Technologies > > LSS Core Product Mgmt > > LSS Emergency Services, GETS, & Regulatory Features Product Mgmt > > 630-713-7162 jrrosenberg@lucent.com > > > > > > At 10:15 AM 3/23/2005, Ken Carlberg wrote: > > >> you might remember the presentation by james about validation = of=20 > > location >> information. he pointed out that access network=20 > > provides location >> information to the end host in such a way = that=20 > > the > emergency > > response > > center > > >> is able to verify that a "trusted" access network created the=20 > > object and > > >> (maybe that this network is indeed reponsible for the area). > > >James > > may correct me, but I would say that the scenario you paint above =20 > >>is > one > > of authentication and integrity in the "validation of location > > >information". I would not consider that a case of authorization,=20 > > >since I > > bind that security component with usage of a service. we may have=20 > > to > > >chalk this up as a case of agreeing to disagree. > >> we had = some > > further > > discussions about this issue in the geopriv working >> group. i=20 > > also consider this as part of the authorization decision. >> there = > > are still > a > > number of issues that need to be investigated and >> discussed = (and=20 > > i > am > > not sure that i understood all aspects; >> the same is probably=20 > > true > for > > other folks as well). > >I have not been following geopriv as=20 > > closely > as > > I > > should have, so I can't >comment on this. > >> there will not be = > > a 'must be authenticated' and 'must be authorized' >> requirement=20 > > for 911/etc. calls (what we have heard so far in the >>=20 > > discussions). > >well, my personal feeling is that users and=20 > > information should be >authenticated to > > offer a measure confidence to others as to the >validity of the = user > > and/or > > the information (eg, location info) >being provided. > >> we = should > > also > > discuss what the meaning of the authorization decision > > in the > > >> context you mention (rfc 2906) is. do you think about 'user x = is > > subscribed >> i.e. was successfully authenticated' or 'user x has > > sufficient funds' or >> 'user x is within a specific geographical = area' > > etc. >> >> i think that most people do not make an assumption = about > > authorization in >> this particular area. i would like to know = what > type > > of > > authorization the >> ieprep folks consider. > >in my view, you=20 > > are mixing components of security. a service is >potentialy=20 > > authorized and information in potentially authenticated > > >-- I say potentially because the security portion may not be = deployed. > > > > > >I'm probably being very picky in my terminology, but I would say=20 > > >that ieprep does not consider a "type of authentication" because=20 > > >that would correlate to a solution, which is not in the current=20 > > >charter of ieprep. > > > > > >rfc-3689 from ieprep provides some general requirements with=20 > > >respect > >to > > authorization/integrity/authentication, but the rfc is only a =20 > >>baseline starting point from which more specific requirements can = > >>be defined within that group. it can be debated how effective=20 > >this >approach was, but > that > > was the direction we took at the time. > >-ken > > > > > > >_______________________________________________ > > >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 > > >=20 >=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 ------_=_NextPart_001_01C53090.A839BDEC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Ecrit] requirements

Hey Marc,

Agree with the sentiment. Strongly recommend that we = put BOTH a definition for validated and a definition for authenticated = in the document though, so that this misunderstanding does not continue = to propagate.

Cheers
James

-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf Of Marc Linsner
Sent: Friday, 25 March 2005 1:57 AM
To: ecrit@ietf.org
Subject: RE: [Ecrit] requirements


So, for ecrit - we are going to work with the = pidf-lo, signed or not.  It is not the responsibility of a = protocol to enforce the 'lo must be signed' policy.  When the call = arrives at a psap that requires a signed lo, they can do with it what = they wish.

A signed pidf-lo is geopriv's issue.

Ecrit will figure out how to identify an emergency = call, route the call to the psap of choice and provide a mechanism for = a client to 'validate' that the/a location in their pidf-lo is capable = of reaching a psap should they so desire.

Correct?

-Marc-





> -----Original Message-----
> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf
> Of Brian Rosen
> Sent: Wednesday, March 23, 2005 4:44 PM
> To: 'Tschofenig Hannes'; 'James Winterbottom'; = 'Ciesla, Larry';
> ecrit@ietf.org
> Subject: RE: [Ecrit] requirements
>
> One interesting observation on that subject is = that the LIS has to
> have a "local" component; that is, a = LIS that provides location for a
> part of Denmark has calls sent to the PSAP in = Denmark.
>
> A LIS could cover a large area, but it is = serving entities that are
> physically in the location where the PSAP that = gets the calls are
> located.
>
> This means that the PSAP could authorize a = LIS.
> More reasonably, an organization, on a national = or regional basis
> could authorize LIS's that serve that = area.
>
> Authorize, I think, means giving them a = cert.  They use that cert to
> sign the location object, which fills a couple = of needs.
>
> Having said that, I think that it is very = difficult to make the
> quality of the cert be really good, because = every enterprise above
> some size has to run a LIS, and it's pretty = hard to qualify
> enterprises.  Not quite the same as making = a global PKI, but still
> pretty tough.
>
> I think that problem is there, but I still = think the best approach is
> to give LIS's a cert and let them sign the = location (and, BTW include
> a timestamp).
>
> Brian
>
> > -----Original Message-----
> > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On
> > Behalf
> Of
> > Tschofenig Hannes
> > Sent: Wednesday, March 23, 2005 12:47 = PM
> > To: 'James Winterbottom'; Ciesla, Larry; = ecrit@ietf.org
> > Subject: AW: [Ecrit] requirements
> >
> > hi james,
> > hi larry,
> >
> > based on this definition i cannot write = code.
> > how do you ensure that the entity that = assigned location information
> > to someone is allowed todo so? do you = assume that there is an access
> > control list that says: "if = identity(access network) =3D=3D "company x"
> > then accept"?
> >
> > ciao
> > hannes
> >
> >
> >
> > -----Urspr=FCngliche Nachricht-----
> > Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] Im
> > Auftrag
> von
> > James Winterbottom
> > Gesendet: Mittwoch, 23. M=E4rz 2005 = 18:17
> > An: Ciesla, Larry; ecrit@ietf.org
> > Betreff: RE: [Ecrit] requirements
> >
> >
> > Larry,
> > That is the definition that I have been = using.
> > Cheers
> > James
> > -----Original Message-----
> > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On
> > Behalf
> Of
> > Ciesla, Larry
> > Sent: Thursday, 24 March 2005 3:39 = AM
> > To: jrrosenberg@lucent.com; = carlberg@g11.org.uk;
> > hannes.tschofenig@siemens.com; = ecrit@ietf.org
> > Subject: Re: [Ecrit] requirements
> >
> >
> > In fact, a user does not even need paid = phone service for 911 to
> > work today. Both wireline and wireless = phones will allow 911 to work
> > for
> unsubscribed
> > phones.  Perhaps the notion of = authorization should be viewed in the
> > context that the entity assigning location = information to a phone
> > should be authorized to do so.
> > Regards
> > Larry Ciesla
> >
> >
> >
> > ***This message has been sent via the = Intrado Wireless Information
> > Network.***
> > -----Original Message-----
> > From: ecrit-bounces@ietf.org = <ecrit-bounces@ietf.org>
> > To: Ken Carlberg = <carlberg@g11.org.uk>; 'Tschofenig Hannes'
> > <hannes.tschofenig@siemens.com>; = ecrit@ietf.org <ecrit@ietf.org>
> > Sent: Wed Mar 23 09:28:10 2005
> > Subject: RE: [Ecrit] requirements
> > All -
> > I think the basic question being asked = deals with two (or more)
> different
> > flavors under the umbrella of Emergency = Services. Two existing
> > examples
> > are:
> >
> >   o B/E911 in the US - does not = require that the "caller" be
> > authorized, or even identified (most 911 = systems today are required
> > to provide
> anonymous
> > access);
> >   o GETS (Government Emergency = Telecommunications Service) in the
> > US, which can only be used by authorized = users - uses PIN mechanism
> > something like
> a
> > calling card to allow the caller to = authenticate.
> > I think the original e-mail was asking for = a specific requirement
> > for ecrit (911 service domain) stating = that "caller" MUST NOT be
> > required to be pre-authorized or to have = to authenticate in order to
> > place an emergency service (e.g. 911-type) = call.
> > John
> > ------------------------
> > John Rosenberg
> > Lucent Technologies
> > LSS Core Product Mgmt
> > LSS Emergency Services, GETS, & = Regulatory Features Product Mgmt
> > 630-713-7162 jrrosenberg@lucent.com
> >
> >
> > At 10:15 AM 3/23/2005, Ken Carlberg = wrote:
> >  >> you might remember the = presentation by james about validation of
> > location  >> information. he = pointed out that access network
> > provides location  >> = information to the end host in such a way that
> > the
> emergency
> > response
> > center
> >  >> is able to verify that a = "trusted" access network created the
> > object and
> > >> (maybe that this network is = indeed reponsible for the area).  >
> >James
> > may correct me, but I would say that the = scenario you paint above 
> >>is
> one
> > of authentication and integrity in the = "validation of location
> > >information".  I would not = consider that a case of authorization,
> > >since I
> > bind that security component with usage of = a service.  we may have
> > to
> > >chalk this up as a case of agreeing to = disagree.  >  >> we had some
> > further
> > discussions about this issue in the = geopriv working  >> group. i
> > also consider this as part of the = authorization decision.  >> there
> > are still
> a
> > number of issues that need to be = investigated and  >> discussed (and
> > i
> am
> > not sure that i understood all = aspects;  >> the same is probably
> > true
> for
> > other folks as well).  >  = >I have not been following geopriv as
> > closely
> as
> > I
> > should have, so I can't  >comment = on this.  >  >> there will not be
> > a 'must be authenticated' and 'must be = authorized'  >> requirement
> > for 911/etc. calls (what we have heard so = far in the  >>
> > discussions).  >  >well, = my personal feeling is that users and
> > information should be  = >authenticated to
> > offer a measure confidence to others as to = the  >validity of the user
> > and/or
> > the information (eg, location info)  = >being provided.  >  >> we should
> > also
> > discuss what the meaning of the = authorization decision
> > in the
> >  >> context you mention (rfc = 2906) is. do you think about 'user x is
> > subscribed  >> i.e. was = successfully authenticated' or 'user x has
> > sufficient funds' or  >> 'user = x is within a specific geographical area'
> > etc.  >>  >> i think = that most people do not make an assumption about
> > authorization in  >> this = particular area. i would like to know what
> type
> > of
> > authorization the  >> ieprep = folks consider.  >  >in my view, you
> > are mixing components of security.  a = service is  >potentialy
> > authorized and information in potentially = authenticated
> >  >-- I say potentially because the = security portion may not be deployed.
> > >
> > >I'm probably being very picky in my = terminology, but I would say
> > >that ieprep does not consider a = "type of authentication" because
> > >that would correlate to a solution, = which is not in the current
> > >charter of ieprep.
> > >
> > >rfc-3689 from ieprep provides some = general requirements with
> > >respect
> >to
> > authorization/integrity/authentication, = but the rfc is only a 
> >>baseline  starting point from = which more specific requirements can 
> >>be defined  within  that = group.  it can be debated how effective
> >this  >approach was, but
> that
> > was the direction we took at the = time.  >  >-ken  >  >  >  = >
> > = >_______________________________________________
> >  >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
> >
>
>
>
>
> = _______________________________________________
> 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_01C53090.A839BDEC-- --===============2079665503== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============2079665503==-- From ecrit-bounces@ietf.org Thu Mar 24 17:11:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11310; Thu, 24 Mar 2005 17:11:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEae3-0005kF-TX; Thu, 24 Mar 2005 17:17:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEaXu-0006Pf-NS; Thu, 24 Mar 2005 17:11:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEaXt-0006PX-Ab for ecrit@megatron.ietf.org; Thu, 24 Mar 2005 17:11:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11269 for ; Thu, 24 Mar 2005 17:11:12 -0500 (EST) Received: from mta3.prod1.dngr.net ([216.220.209.222] helo=mfe3.prod.danger.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEadb-0005jc-2d for ecrit@ietf.org; Thu, 24 Mar 2005 17:17:12 -0500 Received: from [10.253.5.251] (HELO localhost.localdomain) by mfe3.prod.danger.com (CommuniGate Pro SMTP 4.1.6) with ESMTP id 264720781; Thu, 24 Mar 2005 14:10:56 -0800 Date: Thu, 24 Mar 2005 17:10:49 -0500 Subject: Re: [Ecrit] requirements X-Mailer: Danger Service Content-Transfer-Encoding: 7bit In-Reply-To: <200503241457.GAA16647@malone.cisco.com> Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Marc Linsner , ecrit@ietf.org Mime-Version: 1.0 References: <200503241457.GAA16647@malone.cisco.com> From: Brian Rosen Message-Id: <1111702256.C34EC13@di11.dngr.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Excuse me, but in the security considerations we will have to discuss the effects of a fraudulant, modified, or replayed location used for emergency routing. I can't imagine not making a signed location a MUST, even with a general discussion of the difficulty of getting a good cert. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 24 17:44:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14389; Thu, 24 Mar 2005 17:44:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEb9P-0006fQ-H5; Thu, 24 Mar 2005 17:50:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEazE-0002Ct-H9; Thu, 24 Mar 2005 17:39:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEazC-0002Co-Q3 for ecrit@megatron.ietf.org; Thu, 24 Mar 2005 17:39:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14023 for ; Thu, 24 Mar 2005 17:39:28 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEb4w-0006WW-Iz for ecrit@ietf.org; Thu, 24 Mar 2005 17:45:28 -0500 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 j2OMc2F20562; Thu, 24 Mar 2005 16:38:02 -0600 (CST) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Mar 2005 09:38:02 +1100 Message-ID: From: "James Winterbottom" To: Brian Rosen , Marc Linsner , ecrit@ietf.org Subject: RE: [Ecrit] requirements Date: Fri, 25 Mar 2005 09:38:00 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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="===============0740756325==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab 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. --===============0740756325== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C530C2.226F6DA6" 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_01C530C2.226F6DA6 Content-Type: text/plain Hi Brian, Just so I am clear, and you know my feelings about authenticated location, ECRIT is concerned with the routing of a call to a PSAP. Are you saying that authenticated location would be a factor in routing decisions, or a call acceptance policy at the PSAP? If it is the latter, then its scope is border line, if it is the former then I see this as clearly in scope. At an absolute minimum we have a requirement that we can trust the source of the location, though how we ascertain that trust may be more of a GeoPriv thing. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, 25 March 2005 9:11 AM To: Marc Linsner; ecrit@ietf.org Subject: Re: [Ecrit] requirements Excuse me, but in the security considerations we will have to discuss the effects of a fraudulant, modified, or replayed location used for emergency routing. I can't imagine not making a signed location a MUST, even with a general discussion of the difficulty of getting a good cert. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C530C2.226F6DA6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Ecrit] requirements

Hi Brian,

Just so I am clear, and you know my feelings about = authenticated location, ECRIT is concerned with the routing of a call = to a PSAP. Are you saying that authenticated location would be a factor = in routing decisions, or a call acceptance policy at the PSAP? If it is = the latter, then its scope is border line, if it is the former then I = see this as clearly in scope. At an absolute minimum we have a = requirement that we can trust the source of the location, though how we = ascertain that trust may be more of a GeoPriv thing.

Cheers
James

 

-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf Of Brian Rosen
Sent: Friday, 25 March 2005 9:11 AM
To: Marc Linsner; ecrit@ietf.org
Subject: Re: [Ecrit] requirements


Excuse me, but in the security considerations we will = have to discuss
the effects of a fraudulant, modified, or replayed = location used for
emergency routing.  I can't imagine not making = a signed location a MUST,
even with a general discussion of the difficulty of = getting a good
cert.

Brian

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

------_=_NextPart_001_01C530C2.226F6DA6-- --===============0740756325== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0740756325==-- From ecrit-bounces@ietf.org Fri Mar 25 08:57:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28440; Fri, 25 Mar 2005 08:57:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEpP4-00009d-CP; Fri, 25 Mar 2005 09:03:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEpHL-0007zr-4v; Fri, 25 Mar 2005 08:55:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEpHH-0007z1-Oj for ecrit@megatron.ietf.org; Fri, 25 Mar 2005 08:55:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28150 for ; Fri, 25 Mar 2005 08:55:05 -0500 (EST) 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.33) id 1DEpN9-00006P-RN for ecrit@ietf.org; Fri, 25 Mar 2005 09:01:13 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 25 Mar 2005 05:54:56 -0800 X-IronPort-AV: i="3.91,123,1110182400"; d="scan'208"; a="240731003:sNHT24229860" Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2PDspDr019025; Fri, 25 Mar 2005 05:54:52 -0800 (PST) Received: from MLINSNER (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA23221; Fri, 25 Mar 2005 05:54:49 -0800 (PST) Message-Id: <200503251354.FAA23221@malone.cisco.com> From: "Marc Linsner" To: "'Brian Rosen'" , Subject: RE: [Ecrit] requirements Date: Fri, 25 Mar 2005 08:54:49 -0500 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: <1111702256.C34EC13@di11.dngr.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Thread-Index: AcUwvmSfpvVO1clCT2iNHPiBFX7+qQAg0osg X-Spam-Score: 1.1 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 X-Spam-Score: 1.1 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit > > Excuse me, but in the security considerations we will have to discuss > the effects of a fraudulant, modified, or replayed location used for > emergency routing. [[ml]] agreed I can't imagine not making a signed location a MUST, > even with a general discussion of the difficulty of getting a good > cert. [[ml]] What about the PSAP that will accept non-cert lo? -Marc- > > Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 25 09:10:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00257; Fri, 25 Mar 2005 09:10:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEpcQ-0000gm-Ge; Fri, 25 Mar 2005 09:16:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEpW6-0001MG-FY; Fri, 25 Mar 2005 09:10:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEpW5-0001M9-8v for ecrit@megatron.ietf.org; Fri, 25 Mar 2005 09:10:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00226 for ; Fri, 25 Mar 2005 09:10:23 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEpbx-0000g5-BJ for ecrit@ietf.org; Fri, 25 Mar 2005 09:16:30 -0500 Received: from [127.0.0.1] (IDENT:U2FsdGVkX1+ik1QgIGzUlMmyf13XFt7VdI6ng33t6tU@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j2PEA7h3029777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 Mar 2005 09:10:08 -0500 (EST) Message-ID: <42441BAC.5030909@cs.columbia.edu> Date: Fri, 25 Mar 2005 09:09:48 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Ecrit] requirements References: <200503251354.FAA23221@malone.cisco.com> In-Reply-To: <200503251354.FAA23221@malone.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_VERSION 0, __SANE_MSGID 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Marc Linsner wrote: >>Excuse me, but in the security considerations we will have to discuss >>the effects of a fraudulant, modified, or replayed location used for >>emergency routing. > > > [[ml]] agreed > > I can't imagine not making a signed location a MUST, > >>even with a general discussion of the difficulty of getting a good >>cert. > > > [[ml]] What about the PSAP that will accept non-cert lo? > Saying that PIDF-LO must be signed without specifying the trust model is the worst kind of self-delusional security specifically designed not to stymie black hats but rather fool the pointy-haired bosses. "Look at all the fancy crypto bits, and it's X.509 and uses the new-fangled government approved crypto standard, too - this must be really secure". See http://www.antioffline.com/pki.txt for additional reading. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 25 09:19:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00959; Fri, 25 Mar 2005 09:19:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEplB-0000x6-Ez; Fri, 25 Mar 2005 09:26:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEpbx-0002CV-GR; Fri, 25 Mar 2005 09:16:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEpbw-0002CQ-Vo for ecrit@megatron.ietf.org; Fri, 25 Mar 2005 09:16:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00723 for ; Fri, 25 Mar 2005 09:16:27 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEphq-0000qp-OL for ecrit@ietf.org; Fri, 25 Mar 2005 09:22:34 -0500 Received: from [127.0.0.1] (IDENT:U2FsdGVkX1/KUV7yIln1Lyb1ySWlOjXSeKm9rqAPVNM@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j2PEGMh3000043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 25 Mar 2005 09:16:24 -0500 (EST) Message-ID: <42441D23.3030903@cs.columbia.edu> Date: Fri, 25 Mar 2005 09:16:03 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Subject: Re: [Ecrit] requirements References: <200503251354.FAA23221@malone.cisco.com> <42441BAC.5030909@cs.columbia.edu> In-Reply-To: <42441BAC.5030909@cs.columbia.edu> 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_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit As a follow-up, you might enjoy the security services of http://fork.com/jjb/ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 25 09:57:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03794; Fri, 25 Mar 2005 09:57:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEqM3-00023C-8X; Fri, 25 Mar 2005 10:04:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEqF7-0007SZ-PU; Fri, 25 Mar 2005 09:56:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEqF6-0007SU-Dg for ecrit@megatron.ietf.org; Fri, 25 Mar 2005 09:56:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03623 for ; Fri, 25 Mar 2005 09:56:54 -0500 (EST) Message-Id: <200503251456.JAA03623@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEqKz-0001yJ-7f for ecrit@ietf.org; Fri, 25 Mar 2005 10:03:02 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DEqEm-0006FU-IL; Fri, 25 Mar 2005 08:56:36 -0600 From: "Brian Rosen" To: "'Marc Linsner'" , Subject: RE: [Ecrit] requirements Date: Fri, 25 Mar 2005 09:56:31 -0500 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.2180 Thread-Index: AcUwvmSfpvVO1clCT2iNHPiBFX7+qQAg0osgAAJFOVA= In-Reply-To: <200503251354.FAA23221@malone.cisco.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: e5ba305d0e64821bf3d8bc5d3bb07228 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 X-Spam-Score: 0.8 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit So it accepts them. There are no protocol police. Brian > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Friday, March 25, 2005 8:55 AM > To: 'Brian Rosen'; ecrit@ietf.org > Subject: RE: [Ecrit] requirements > > > > > Excuse me, but in the security considerations we will have to discuss > > the effects of a fraudulant, modified, or replayed location used for > > emergency routing. > > [[ml]] agreed > > I can't imagine not making a signed location a MUST, > > even with a general discussion of the difficulty of getting a good > > cert. > > [[ml]] What about the PSAP that will accept non-cert lo? > > > -Marc- > > > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 25 10:14:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05575; Fri, 25 Mar 2005 10:14:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEqbY-0002Tj-Iw; Fri, 25 Mar 2005 10:20:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEqVR-0000rA-Ra; Fri, 25 Mar 2005 10:13:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEqVP-0000r2-4W for ecrit@megatron.ietf.org; Fri, 25 Mar 2005 10:13:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05539 for ; Fri, 25 Mar 2005 10:13:45 -0500 (EST) Message-Id: <200503251513.KAA05539@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEqbJ-0002TB-93 for ecrit@ietf.org; Fri, 25 Mar 2005 10:19:53 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DEqVE-0006ow-Rl; Fri, 25 Mar 2005 09:13:37 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Marc Linsner'" Subject: RE: [Ecrit] requirements Date: Fri, 25 Mar 2005 10:13:30 -0500 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.2180 Thread-Index: AcUxRGC1ebMWbIFoTXOY7U2pD4V+EQABnjzQ In-Reply-To: <42441BAC.5030909@cs.columbia.edu> 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: 3e15cc4fdc61d7bce84032741d11c8e5 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 X-Spam-Score: 0.8 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit The trust model is that the PSAP, or some other "local" authority, issues a cert to the LIS, which is local. The same authority that issues the cert is the entity that checks the signature. That's a very reasonable trust model, with the caveat already mentioned: large enterprises will run LIS's and it's hard to verify the bona fides of every enterprise claiming to be large. One can have a couple of checks, but it's still not going to be really iron clad. I don't see that as a big enough problem that the value of the signature is lost, as long as the PSAPs are aware of the issues. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, March 25, 2005 9:10 AM > To: Marc Linsner > Cc: 'Brian Rosen'; ecrit@ietf.org > Subject: Re: [Ecrit] requirements > > Marc Linsner wrote: > >>Excuse me, but in the security considerations we will have to discuss > >>the effects of a fraudulant, modified, or replayed location used for > >>emergency routing. > > > > > > [[ml]] agreed > > > > I can't imagine not making a signed location a MUST, > > > >>even with a general discussion of the difficulty of getting a good > >>cert. > > > > > > [[ml]] What about the PSAP that will accept non-cert lo? > > > > Saying that PIDF-LO must be signed without specifying the trust model is > the worst kind of self-delusional security specifically designed not to > stymie black hats but rather fool the pointy-haired bosses. "Look at all > the fancy crypto bits, and it's X.509 and uses the new-fangled > government approved crypto standard, too - this must be really secure". > > See http://www.antioffline.com/pki.txt for additional reading. > Nope. I think this proposal has limited capacity to stop fraudulent locations, but it raises the bar considerably higher than no attempt at all. It's still subject to replay attack. It's subject to the issues raised in the paper about how the CA and the LIS are managed. I think it's a lot better than nothing. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 25 10:33:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07528; Fri, 25 Mar 2005 10:33:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEquN-000324-0j; Fri, 25 Mar 2005 10:39:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEqn2-00030q-LI; Fri, 25 Mar 2005 10:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEqn1-00030J-0a for ecrit@megatron.ietf.org; Fri, 25 Mar 2005 10:31:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07346 for ; Fri, 25 Mar 2005 10:31:56 -0500 (EST) 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.33) id 1DEqsu-0002yO-Ck for ecrit@ietf.org; Fri, 25 Mar 2005 10:38:05 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 25 Mar 2005 07:31:49 -0800 X-IronPort-AV: i="3.91,123,1110182400"; d="scan'208"; a="240773762:sNHT25286060" Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2PFVkgE020586; Fri, 25 Mar 2005 07:31:46 -0800 (PST) Received: from MLINSNER (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA02735; Fri, 25 Mar 2005 07:31:45 -0800 (PST) Message-Id: <200503251531.HAA02735@malone.cisco.com> From: "Marc Linsner" To: "'Brian Rosen'" , Subject: RE: [Ecrit] requirements Date: Fri, 25 Mar 2005 10:31:44 -0500 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: <3q2adc$1lis4l@sj-inbound-d.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Thread-Index: AcUwvmSfpvVO1clCT2iNHPiBFX7+qQAg0osgAAJFOVAAATjgMA== X-Spam-Score: 1.1 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 X-Spam-Score: 1.1 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit > > So it accepts them. There are no protocol police. > [[ml]] So there is no 'MUST'. -Marc- > Brian > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Friday, March 25, 2005 8:55 AM > > To: 'Brian Rosen'; ecrit@ietf.org > > Subject: RE: [Ecrit] requirements > > > > > > > > Excuse me, but in the security considerations we will have to discuss > > > the effects of a fraudulant, modified, or replayed location used for > > > emergency routing. > > > > [[ml]] agreed > > > > I can't imagine not making a signed location a MUST, > > > even with a general discussion of the difficulty of getting a good > > > cert. > > > > [[ml]] What about the PSAP that will accept non-cert lo? > > > > > > -Marc- > > > > > > Brian > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 25 10:35:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07879; Fri, 25 Mar 2005 10:35:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEqwl-00036P-47; Fri, 25 Mar 2005 10:42:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEqqh-0003Lw-3M; Fri, 25 Mar 2005 10:35:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEqqe-0003Lq-Pq for ecrit@megatron.ietf.org; Fri, 25 Mar 2005 10:35:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07867 for ; Fri, 25 Mar 2005 10:35:42 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEqwY-00036B-4u for ecrit@ietf.org; Fri, 25 Mar 2005 10:41:51 -0500 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j2PFZch3004401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 Mar 2005 10:35:39 -0500 (EST) Message-ID: <42442FC5.5000407@cs.columbia.edu> Date: Fri, 25 Mar 2005 10:35:33 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] requirements References: <200503251513.j2PFDhqt023143@cs.columbia.edu> In-Reply-To: <200503251513.j2PFDhqt023143@cs.columbia.edu> 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_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit As far as I know, the IETF does not specify operational issues like that, as they involve policy choices. Maybe that's a more appropriate topic for NENA or other bodies. There's agreement here, I believe, that signing should be possible in protocols we design (and that a compliant implementation should be able to receive such signed LOs). That's about as far as we can take it here without straying into policy, regulation or national laws. Brian Rosen wrote: > The trust model is that the PSAP, or some other "local" authority, issues a > cert to the LIS, which is local. The same authority that issues the cert is > the entity that checks the signature. > > That's a very reasonable trust model, with the caveat already mentioned: > large enterprises will run LIS's and it's hard to verify the bona fides of > every enterprise claiming to be large. One can have a couple of checks, but > it's still not going to be really iron clad. > > I don't see that as a big enough problem that the value of the signature is > lost, as long as the PSAPs are aware of the issues. > > Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 25 10:51:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09691; Fri, 25 Mar 2005 10:51:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DErBj-0003dD-Cu; Fri, 25 Mar 2005 10:57:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEr5C-0005JU-Km; Fri, 25 Mar 2005 10:50:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEr5A-0005JN-Qa for ecrit@megatron.ietf.org; Fri, 25 Mar 2005 10:50:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09658 for ; Fri, 25 Mar 2005 10:50:42 -0500 (EST) Message-Id: <200503251550.KAA09658@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DErB5-0003aq-FL for ecrit@ietf.org; Fri, 25 Mar 2005 10:56:51 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DEr50-00085L-In; Fri, 25 Mar 2005 09:50:34 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] requirements Date: Fri, 25 Mar 2005 10:50:29 -0500 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.2180 Thread-Index: AcUxUE0QbQP6AezYQb+7aWAKQqWCBgAAab6g In-Reply-To: <42442FC5.5000407@cs.columbia.edu> 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@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 X-Spam-Score: 0.8 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Okay, I'm actually content with making it possible. It is, after all, a local matter. The IETF does, in fact, often go way beyond possible in issues like this. There are "must implement" clauses in some protocols for security mechanisms. You can't say "must deploy". Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, March 25, 2005 10:36 AM > To: Brian Rosen > Cc: 'Marc Linsner'; ecrit@ietf.org > Subject: Re: [Ecrit] requirements > > As far as I know, the IETF does not specify operational issues like > that, as they involve policy choices. Maybe that's a more appropriate > topic for NENA or other bodies. There's agreement here, I believe, that > signing should be possible in protocols we design (and that a compliant > implementation should be able to receive such signed LOs). That's about > as far as we can take it here without straying into policy, regulation > or national laws. > > Brian Rosen wrote: > > The trust model is that the PSAP, or some other "local" authority, > issues a > > cert to the LIS, which is local. The same authority that issues the > cert is > > the entity that checks the signature. > > > > That's a very reasonable trust model, with the caveat already mentioned: > > large enterprises will run LIS's and it's hard to verify the bona fides > of > > every enterprise claiming to be large. One can have a couple of checks, > but > > it's still not going to be really iron clad. > > > > I don't see that as a big enough problem that the value of the signature > is > > lost, as long as the PSAPs are aware of the issues. > > > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 25 11:30:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15317; Fri, 25 Mar 2005 11:30:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DErnq-0005I0-0W; Fri, 25 Mar 2005 11:36:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DErhc-0003zV-72; Fri, 25 Mar 2005 11:30:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DErha-0003yl-EQ for ecrit@megatron.ietf.org; Fri, 25 Mar 2005 11:30:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15246 for ; Fri, 25 Mar 2005 11:30:24 -0500 (EST) 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.33) id 1DErnU-0005GB-8g for ecrit@ietf.org; Fri, 25 Mar 2005 11:36:33 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 25 Mar 2005 08:30:16 -0800 X-IronPort-AV: i="3.91,123,1110182400"; d="scan'208"; a="240800388:sNHT27312432" Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2PGUDgE008602 for ; Fri, 25 Mar 2005 08:30:14 -0800 (PST) Received: from MLINSNER (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA00228 for ; Fri, 25 Mar 2005 08:30:12 -0800 (PST) Message-Id: <200503251630.IAA00228@malone.cisco.com> From: "Marc Linsner" To: Subject: RE: [Ecrit] requirements Date: Fri, 25 Mar 2005 11:30:12 -0500 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: <3v4g60$1fljkk@sj-inbound-c.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Thread-Index: AcUxUE0QbQP6AezYQb+7aWAKQqWCBgAAab6gAAER6SA= X-Spam-Score: 1.1 (+) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 X-Spam-Score: 1.1 (+) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit OK, it sounds like I have misinterpreted your "MUST". I agree to: The 'mechanism' that ecrit is going to define "MUST" support a signed lo as well as an unsigned lo. User policy will dictate when/if a lo is signed. I also believe the security and threats section needs to discuss aspects of each user policy. -Marc- > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, March 25, 2005 10:50 AM > To: 'Henning Schulzrinne' > Cc: 'Marc Linsner'; ecrit@ietf.org > Subject: RE: [Ecrit] requirements > > Okay, I'm actually content with making it possible. > It is, after all, a local matter. > > The IETF does, in fact, often go way beyond possible in issues like this. > There are "must implement" clauses in some protocols for security > mechanisms. You can't say "must deploy". > > Brian > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Friday, March 25, 2005 10:36 AM > > To: Brian Rosen > > Cc: 'Marc Linsner'; ecrit@ietf.org > > Subject: Re: [Ecrit] requirements > > > > As far as I know, the IETF does not specify operational issues like > > that, as they involve policy choices. Maybe that's a more appropriate > > topic for NENA or other bodies. There's agreement here, I believe, that > > signing should be possible in protocols we design (and that a compliant > > implementation should be able to receive such signed LOs). That's about > > as far as we can take it here without straying into policy, regulation > > or national laws. > > > > Brian Rosen wrote: > > > The trust model is that the PSAP, or some other "local" authority, > > issues a > > > cert to the LIS, which is local. The same authority that issues the > > cert is > > > the entity that checks the signature. > > > > > > That's a very reasonable trust model, with the caveat already > mentioned: > > > large enterprises will run LIS's and it's hard to verify the bona > fides > > of > > > every enterprise claiming to be large. One can have a couple of > checks, > > but > > > it's still not going to be really iron clad. > > > > > > I don't see that as a big enough problem that the value of the > signature > > is > > > lost, as long as the PSAPs are aware of the issues. > > > > > > Brian > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 25 11:50:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16612; Fri, 25 Mar 2005 11:50:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEs6r-0005oB-6O; Fri, 25 Mar 2005 11:56:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DErz0-0006qX-Tp; Fri, 25 Mar 2005 11:48:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEryz-0006qS-MA for ecrit@megatron.ietf.org; Fri, 25 Mar 2005 11:48:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16498 for ; Fri, 25 Mar 2005 11:48:23 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEs4u-0005lU-LL for ecrit@ietf.org; Fri, 25 Mar 2005 11:54:33 -0500 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 j2PGmCC11306; Fri, 25 Mar 2005 10:48:12 -0600 (CST) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 26 Mar 2005 03:47:23 +1100 Message-ID: From: "James Winterbottom" To: Marc Linsner , ecrit@ietf.org Subject: RE: [Ecrit] requirements Date: Sat, 26 Mar 2005 03:47:20 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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="===============1371632035==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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. --===============1371632035== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5315A.4FC7FCB2" 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_01C5315A.4FC7FCB2 Content-Type: text/plain Can we be very specific about which "User" we are talking about then. Because the statement thus far has really been referring to this as being a "PSAP policy" and relates to call acceptance, rather than call routing/delivery. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Saturday, 26 March 2005 3:30 AM To: ecrit@ietf.org Subject: RE: [Ecrit] requirements OK, it sounds like I have misinterpreted your "MUST". I agree to: The 'mechanism' that ecrit is going to define "MUST" support a signed lo as well as an unsigned lo. User policy will dictate when/if a lo is signed. I also believe the security and threats section needs to discuss aspects of each user policy. -Marc- ------_=_NextPart_001_01C5315A.4FC7FCB2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Ecrit] requirements

Can we be very specific about which "User" = we are talking about then. Because the statement thus far has really = been referring to this as being a "PSAP policy" and relates = to call acceptance, rather than call routing/delivery.



-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf Of Marc Linsner
Sent: Saturday, 26 March 2005 3:30 AM
To: ecrit@ietf.org
Subject: RE: [Ecrit] requirements


OK, it sounds like I have misinterpreted your = "MUST".

I agree to: The 'mechanism' that ecrit is going to = define "MUST" support a signed lo as well as an unsigned = lo.  User policy will dictate when/if a lo is signed.

I also believe the security and threats section needs = to discuss aspects of each user policy.

-Marc-



------_=_NextPart_001_01C5315A.4FC7FCB2-- --===============1371632035== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1371632035==-- From ecrit-bounces@ietf.org Fri Mar 25 12:18:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19042; Fri, 25 Mar 2005 12:18:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEsY2-0006fD-TQ; Fri, 25 Mar 2005 12:24:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEsQC-0003C1-So; Fri, 25 Mar 2005 12:16:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEsQB-0003Bw-0N for ecrit@megatron.ietf.org; Fri, 25 Mar 2005 12:16:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18863 for ; Fri, 25 Mar 2005 12:16:28 -0500 (EST) Message-Id: <200503251716.MAA18863@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEsW6-0006bN-E3 for ecrit@ietf.org; Fri, 25 Mar 2005 12:22:38 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DEsQ0-0004CR-7Q; Fri, 25 Mar 2005 11:16:20 -0600 From: "Brian Rosen" To: "'James Winterbottom'" , "'Marc Linsner'" , Subject: RE: [Ecrit] requirements Date: Fri, 25 Mar 2005 12:16:15 -0500 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.2180 Thread-Index: AcUxXUnPuLhZdBihTF2L4VZdV2E+hQAANPPw 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: 9ed51c9d1356100bce94f1ae4ec616a9 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 X-Spam-Score: 0.8 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable There are two users, the operator of the User Agent Server and operator = of the User Agent Client. Each has a policy. It=92s possible that those policies will conflict, in which case calls may not go through. I hope that=92s pretty rare. Brian ________________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of James Winterbottom Sent: Friday, March 25, 2005 11:47 AM To: Marc Linsner; ecrit@ietf.org Subject: RE: [Ecrit] requirements Can we be very specific about which "User" we are talking about then. Because the statement thus far has really been referring to this as = being a "PSAP policy" and relates to call acceptance, rather than call routing/delivery. -----Original Message-----=20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Marc Linsner=20 Sent: Saturday, 26 March 2005 3:30 AM=20 To: ecrit@ietf.org=20 Subject: RE: [Ecrit] requirements=20 OK, it sounds like I have misinterpreted your "MUST".=20 I agree to: The 'mechanism' that ecrit is going to define "MUST" support = a signed lo as well as an unsigned lo.=A0 User policy will dictate when/if = a lo is signed. I also believe the security and threats section needs to discuss aspects = of each user policy.=20 -Marc-=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 25 12:23:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19708; Fri, 25 Mar 2005 12:23:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEscQ-0006qT-FI; Fri, 25 Mar 2005 12:29:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEsUw-00043C-Gj; Fri, 25 Mar 2005 12:21:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEsUv-000437-N1 for ecrit@megatron.ietf.org; Fri, 25 Mar 2005 12:21:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19466 for ; Fri, 25 Mar 2005 12:21:22 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEsaq-0006lz-KN for ecrit@ietf.org; Fri, 25 Mar 2005 12:27:33 -0500 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 j2PHL8K13717; Fri, 25 Mar 2005 11:21:08 -0600 (CST) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 26 Mar 2005 04:20:18 +1100 Message-ID: From: "James Winterbottom" To: Brian Rosen , "'Marc Linsner'" , ecrit@ietf.org Subject: RE: [Ecrit] requirements Date: Sat, 26 Mar 2005 04:20:16 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a 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="===============1104745057==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 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. --===============1104745057== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5315E.E9CFA5D6" 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_01C5315E.E9CFA5D6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree. My point was more that we specifically state as to which end-point the policy is applicable to. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Saturday, 26 March 2005 4:16 AM To: Winterbottom, James [WOLL:5500:EXCH]; 'Marc Linsner'; = ecrit@ietf.org Subject: RE: [Ecrit] requirements There are two users, the operator of the User Agent Server and operator = of the User Agent Client. Each has a policy. It's possible that those policies will conflict, in which case calls may not go through. I hope that's pretty rare. Brian ________________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of James Winterbottom Sent: Friday, March 25, 2005 11:47 AM To: Marc Linsner; ecrit@ietf.org Subject: RE: [Ecrit] requirements Can we be very specific about which "User" we are talking about then. Because the statement thus far has really been referring to this as = being a "PSAP policy" and relates to call acceptance, rather than call routing/delivery. -----Original Message-----=20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Marc Linsner=20 Sent: Saturday, 26 March 2005 3:30 AM=20 To: ecrit@ietf.org=20 Subject: RE: [Ecrit] requirements=20 OK, it sounds like I have misinterpreted your "MUST".=20 I agree to: The 'mechanism' that ecrit is going to define "MUST" = support a signed lo as well as an unsigned lo.=A0 User policy will dictate = when/if a lo is signed. I also believe the security and threats section needs to = discuss aspects of each user policy.=20 -Marc-=20 ------_=_NextPart_001_01C5315E.E9CFA5D6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Ecrit] requirements

I agree.

My point was more that we specifically state as to = which end-point the policy is applicable to.

-----Original Message-----
From: Brian Rosen [mailto:br@brianrosen.net]
Sent: Saturday, 26 March 2005 4:16 AM
To: Winterbottom, James [WOLL:5500:EXCH]; 'Marc = Linsner'; ecrit@ietf.org
Subject: RE: [Ecrit] requirements


There are two users, the operator of the User Agent = Server and operator of the User Agent Client.  Each has a = policy.  It's possible that those policies will conflict, in which = case calls may not go through.  I hope that's pretty = rare.

Brian

________________________________________
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf Of James Winterbottom
Sent: Friday, March 25, 2005 11:47 AM
To: Marc Linsner; ecrit@ietf.org
Subject: RE: [Ecrit] requirements

Can we be very specific about which "User" = we are talking about then. Because the statement thus far has really = been referring to this as being a "PSAP policy" and relates = to call acceptance, rather than call routing/delivery.

-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf Of Marc Linsner
Sent: Saturday, 26 March 2005 3:30 AM
To: ecrit@ietf.org
Subject: RE: [Ecrit] requirements

OK, it sounds like I have misinterpreted your = "MUST".
I agree to: The 'mechanism' that ecrit is going to = define "MUST" support a signed lo as well as an unsigned = lo.=A0 User policy will dictate when/if a lo is signed. I also believe = the security and threats section needs to discuss aspects of each user = policy.

-Marc-



------_=_NextPart_001_01C5315E.E9CFA5D6-- --===============1104745057== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1104745057==-- From ecrit-bounces@ietf.org Fri Mar 25 13:24:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27268; Fri, 25 Mar 2005 13:24:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEtaG-0000fS-Bb; Fri, 25 Mar 2005 13:31:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEtSD-0005lr-8Y; Fri, 25 Mar 2005 13:22:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEtSB-0005ji-Dj for ecrit@megatron.ietf.org; Fri, 25 Mar 2005 13:22:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26976 for ; Fri, 25 Mar 2005 13:22:18 -0500 (EST) Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEtXo-0000Zv-Pd for ecrit@ietf.org; Fri, 25 Mar 2005 13:28:29 -0500 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 j2PIM8M28708 for ; Fri, 25 Mar 2005 13:22:08 -0500 (EST) Received: from rrc-its-exig01.mail.saic.com ([128.96.103.57]) by rrc-its-ieg02.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005032513220631454 for ; Fri, 25 Mar 2005 13:22:06 -0500 Received: by rrc-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Fri, 25 Mar 2005 13:22:06 -0500 Message-ID: From: "Abbott, Nadine B." To: ecrit@ietf.org Subject: RE: AW: AW: [Ecrit] requirements Date: Fri, 25 Mar 2005 13:22:05 -0500 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: 92df29fa99cf13e554b84c8374345c17 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Hannes, At least as we have framed it in the Rosen contribution to ECRIT, "location validation" refers to capabilities necessary to ensure that a civic location object is routable and also useful for dispatch of emergency responders. Since there are so many different representations of civic location information, human user confusion can contribute to incorrect, unroutable information being provided. The "location validation" function is intended to allow for corrections of errors and confusion BEFORE there is an emergency. (We have been informed that the term "location validation" may cause confusion because of other connotations in other contexts, but have tried to qualify and explain the use of the term to alleviate this.) I think that if non-routable civic addresses were commonplace, it wouldn't really matter what mechanism ecrit specified for routing them--garbage in-->garbage out. "Location validation" is not the same as authenticating that any given location object has been provided by a particular entity. Thanks, Nadine -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James M. Polk Sent: Wednesday, March 23, 2005 2:49 PM To: Tschofenig Hannes; 'Henning Schulzrinne' Cc: Ciesla, Larry; ecrit@ietf.org Subject: Re: AW: AW: [Ecrit] requirements At 08:34 PM 3/23/2005 +0100, Tschofenig Hannes wrote: > > > > Allowed by whom? Do we assume that one has to have a license to > > provide such services? Who would hand out such licenses? (As far as > > I know, nobody has licensed Columbia University to provide > > telecommunication services and I guess we thus would not be able to > > legally provide campus-level location information.) > >that's exactly my point. >if we dig deeper into the authorization issues then we encounter >various problems. Isn't "location validation" another form of "authorized location information for usage"? Is this part of our message routing charter? >ciao >hannes > > > > >_______________________________________________ >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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 25 13:33:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27939; Fri, 25 Mar 2005 13:33:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEtj7-0000uQ-RV; Fri, 25 Mar 2005 13:40:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEtbf-0007UC-Oa; Fri, 25 Mar 2005 13:32:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEtbe-0007U1-Lq for ecrit@megatron.ietf.org; Fri, 25 Mar 2005 13:32:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27789 for ; Fri, 25 Mar 2005 13:32:23 -0500 (EST) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEthZ-0000q9-Ch for ecrit@ietf.org; Fri, 25 Mar 2005 13:38:34 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j2PIWJVP010955; Fri, 25 Mar 2005 19:32:19 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id j2PIWJTf003492; Fri, 25 Mar 2005 19:32:19 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Fri, 25 Mar 2005 19:32:19 +0100 Message-ID: From: Tschofenig Hannes To: "'Abbott, Nadine B.'" , ecrit@ietf.org Subject: AW: AW: AW: [Ecrit] requirements Date: Fri, 25 Mar 2005 19:30:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable hi nadine,=20 thanks for clarifying this issue. i think that the requirements = document should contain these terms to ensure that we do not talk past each = other. the current mailing list thread also shows that we need to be very = precise about other terms as well (related to security). this should help us to illustrate what functionality we would like to accomplish.=20 ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > Im Auftrag von Abbott, Nadine B. > Gesendet: Freitag, 25. M=E4rz 2005 19:22 > An: ecrit@ietf.org > Betreff: RE: AW: AW: [Ecrit] requirements >=20 >=20 > Hannes, >=20 > At least as we have framed it in the Rosen contribution to=20 > ECRIT, "location > validation" refers to capabilities necessary to ensure that a=20 > civic location > object is routable and also useful for dispatch of emergency=20 > responders. > Since there are so many different representations of civic location > information, human user confusion can contribute to=20 > incorrect, unroutable > information being provided. The "location validation"=20 > function is intended > to allow for corrections of errors and confusion BEFORE there is an > emergency. (We have been informed that the term "location=20 > validation" may > cause confusion because of other connotations in other=20 > contexts, but have > tried to qualify and explain the use of the term to alleviate this.) = > I think that if non-routable civic addresses were=20 > commonplace, it wouldn't > really matter what mechanism ecrit specified for routing = them--garbage > in-->garbage out. >=20 > "Location validation" is not the same as authenticating that any = given > location object has been provided by a particular entity. >=20 > Thanks, > Nadine >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of > James M. Polk > Sent: Wednesday, March 23, 2005 2:49 PM > To: Tschofenig Hannes; 'Henning Schulzrinne' > Cc: Ciesla, Larry; ecrit@ietf.org > Subject: Re: AW: AW: [Ecrit] requirements >=20 >=20 > At 08:34 PM 3/23/2005 +0100, Tschofenig Hannes wrote: >=20 > > > > > > Allowed by whom? Do we assume that one has to have a license to=20 > > > provide such services? Who would hand out such licenses?=20 > (As far as=20 > > > I know, nobody has licensed Columbia University to provide=20 > > > telecommunication services and I guess we thus would not=20 > be able to=20 > > > legally provide campus-level location information.) > > > >that's exactly my point. > >if we dig deeper into the authorization issues then we encounter=20 > >various problems. >=20 > Isn't "location validation" another form of "authorized location=20 > information for usage"? >=20 > Is this part of our message routing charter? >=20 >=20 > >ciao > >hannes > > > > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > cheers, > James >=20 > ******************* > Truth is not to be argued... it is to be presented >=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 Fri Mar 25 14:24:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02354; Fri, 25 Mar 2005 14:24:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEuVf-0002NI-V3; Fri, 25 Mar 2005 14:30:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEuP3-0005aV-NZ; Fri, 25 Mar 2005 14:23:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEuP2-0005aQ-4B for ecrit@megatron.ietf.org; Fri, 25 Mar 2005 14:23:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02324 for ; Fri, 25 Mar 2005 14:23:26 -0500 (EST) 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.33) id 1DEuUx-0002L8-6Y for ecrit@ietf.org; Fri, 25 Mar 2005 14:29:36 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 25 Mar 2005 11:23:15 -0800 Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2PJN6gE022261; Fri, 25 Mar 2005 11:23:06 -0800 (PST) Received: from MLINSNER (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA17920; Fri, 25 Mar 2005 11:23:12 -0800 (PST) Message-Id: <200503251923.LAA17920@malone.cisco.com> From: "Marc Linsner" To: "'James Winterbottom'" , Subject: RE: [Ecrit] requirements Date: Fri, 25 Mar 2005 14:23:10 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Thread-Index: AcUxWnkx4YxyLo3qT+WjN45VksRlWwADLkCg X-Spam-Score: 1.3 (+) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f 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="===============1727562806==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 1.4 (+) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d This is a multi-part message in MIME format. --===============1727562806== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0395_01C53146.2D1F60B0" This is a multi-part message in MIME format. ------=_NextPart_000_0395_01C53146.2D1F60B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit User can be either end of the context. -Marc- _____ From: James Winterbottom [mailto:winterb@nortel.com] Sent: Friday, March 25, 2005 11:47 AM To: Marc Linsner; ecrit@ietf.org Subject: RE: [Ecrit] requirements Can we be very specific about which "User" we are talking about then. Because the statement thus far has really been referring to this as being a "PSAP policy" and relates to call acceptance, rather than call routing/delivery. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Saturday, 26 March 2005 3:30 AM To: ecrit@ietf.org Subject: RE: [Ecrit] requirements OK, it sounds like I have misinterpreted your "MUST". I agree to: The 'mechanism' that ecrit is going to define "MUST" support a signed lo as well as an unsigned lo. User policy will dictate when/if a lo is signed. I also believe the security and threats section needs to discuss aspects of each user policy. -Marc- ------=_NextPart_000_0395_01C53146.2D1F60B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Ecrit] requirements

User can be either end of the = context.

 

-Marc-

 

From: James Winterbottom [mailto:winterb@nortel.com]
Sent: Friday, March 25, = 2005 11:47 AM
To: Marc Linsner; = ecrit@ietf.org
Subject: RE: [Ecrit] = requirements

 

Can we be very specific about which "User" we are talking about then. = Because the statement thus far has really been referring to this as being a = "PSAP policy" and relates to call acceptance, rather than call = routing/delivery.

 

-----Original Message-----
From: = ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]= On Behalf Of Marc Linsner
Sent: Saturday, 26 March = 2005 3:30 AM
To: = ecrit@ietf.org
Subject: RE: [Ecrit] = requirements

 

OK, it sounds like I have misinterpreted your "MUST". =

I agree to: The 'mechanism' that ecrit is going to define "MUST" = support a signed lo as well as an unsigned lo.  User policy will dictate = when/if a lo is signed.

I also believe the security and threats section needs to discuss aspects of = each user policy.

-Marc-

 

------=_NextPart_000_0395_01C53146.2D1F60B0-- --===============1727562806== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1727562806==-- From ecrit-bounces@ietf.org Fri Mar 25 14:59:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04766; Fri, 25 Mar 2005 14:59:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEv3t-0003Fl-P2; Fri, 25 Mar 2005 15:05:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEuw2-0001RW-Hp; Fri, 25 Mar 2005 14:57:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEuvz-0001RQ-UI for ecrit@megatron.ietf.org; Fri, 25 Mar 2005 14:57:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04640 for ; Fri, 25 Mar 2005 14:57:30 -0500 (EST) 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.33) id 1DEv1w-0003DY-6r for ecrit@ietf.org; Fri, 25 Mar 2005 15:03:40 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 25 Mar 2005 11:57:22 -0800 Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2PJvFgE022328; Fri, 25 Mar 2005 11:57:15 -0800 (PST) Received: from MLINSNER (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA25626; Fri, 25 Mar 2005 11:57:18 -0800 (PST) Message-Id: <200503251957.LAA25626@malone.cisco.com> From: "Marc Linsner" To: "'James Winterbottom'" , Subject: RE: [Ecrit] requirements Date: Fri, 25 Mar 2005 14:57:17 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Thread-Index: AcUxcZ3kqZcr7LHKRLqO9zdF3Gbo6wAAXfXg X-Spam-Score: 1.3 (+) X-Scan-Signature: 4a4195ffb11c7b0baf82f77b2a730aa9 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="===============0147569615==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: ba9cd4f9acda58dbe142afff7265daff This is a multi-part message in MIME format. --===============0147569615== Content-Type: multipart/alternative; boundary="----=_NextPart_000_03B1_01C5314A.F0DFB1E0" This is a multi-part message in MIME format. ------=_NextPart_000_03B1_01C5314A.F0DFB1E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I obviously typed before thinking below when I said, "I also believe the security and threats section needs to discuss aspects of each user policy." I believe the security and threats discussion needs to cover the aspects of sending a lo w/o signature and sending a lo with signature? It should not matter who owns the policy. Is that better? -Marc- _____ From: James Winterbottom [mailto:winterb@nortel.com] Sent: Friday, March 25, 2005 2:33 PM To: Marc Linsner Subject: RE: [Ecrit] requirements Hi Marc, If the policy is explicit to one end, or is used differently, then it is very useful to make sure that we say that, and don't just say "user". Cheers James -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Saturday, 26 March 2005 6:23 AM To: Winterbottom, James [WOLL:5500:EXCH]; ecrit@ietf.org Subject: RE: [Ecrit] requirements User can be either end of the context. -Marc- _____ From: James Winterbottom [mailto:winterb@nortel.com] Sent: Friday, March 25, 2005 11:47 AM To: Marc Linsner; ecrit@ietf.org Subject: RE: [Ecrit] requirements Can we be very specific about which "User" we are talking about then. Because the statement thus far has really been referring to this as being a "PSAP policy" and relates to call acceptance, rather than call routing/delivery. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Saturday, 26 March 2005 3:30 AM To: ecrit@ietf.org Subject: RE: [Ecrit] requirements OK, it sounds like I have misinterpreted your "MUST". I agree to: The 'mechanism' that ecrit is going to define "MUST" support a signed lo as well as an unsigned lo. User policy will dictate when/if a lo is signed. I also believe the security and threats section needs to discuss aspects of each user policy. -Marc- ------=_NextPart_000_03B1_01C5314A.F0DFB1E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

I obviously typed before thinking below when I said, = “I also believe the security = and threats section needs to discuss aspects of each user = policy.”

I believe the security and threats discussion needs to cover the aspects of sending a lo w/o signature and = sending a lo with signature?  It should not matter who owns the = policy.

 

Is that = better?

 

-Marc-

 

 

 

From: James Winterbottom [mailto:winterb@nortel.com]
Sent: Friday, March 25, = 2005 2:33 PM
To: Marc Linsner
Subject: RE: [Ecrit] = requirements

 

Hi = Marc,

 

If the policy is explicit to one = end, or is used differently, then it is very useful to make sure that we say = that, and don't just say "user".

 

Cheers

James

-----Original = Message-----
From: Marc Linsner [mailto:mlinsner@cisco.com]
Sent: Saturday, 26 March = 2005 6:23 AM
To: Winterbottom, James [WOLL:5500:EXCH]; ecrit@ietf.org
Subject: RE: [Ecrit] = requirements

User can be either end of the = context.

 

-Marc-

 

From: James Winterbottom [mailto:winterb@nortel.com]
Sent: Friday, March 25, = 2005 11:47 AM
To: Marc Linsner; = ecrit@ietf.org
Subject: RE: [Ecrit] = requirements

 

Can we be very specific about which "User" we are talking about then. = Because the statement thus far has really been referring to this as being a = "PSAP policy" and relates to call acceptance, rather than call = routing/delivery.

 

-----Original Message-----
From: = ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]= On Behalf Of Marc Linsner
Sent: Saturday, 26 March = 2005 3:30 AM
To: = ecrit@ietf.org
Subject: RE: [Ecrit] = requirements

 

OK, it sounds like I have misinterpreted your "MUST". =

I agree to: The 'mechanism' that ecrit is going to define "MUST" = support a signed lo as well as an unsigned lo.  User policy will dictate = when/if a lo is signed.

I also believe the security and threats section needs to discuss aspects of = each user policy.

-Marc-

 

------=_NextPart_000_03B1_01C5314A.F0DFB1E0-- --===============0147569615== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0147569615==-- From ecrit-bounces@ietf.org Fri Mar 25 15:01:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05021; Fri, 25 Mar 2005 15:01:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEv69-0003KL-W1; Fri, 25 Mar 2005 15:08:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEuyn-0001vS-S3; Fri, 25 Mar 2005 15:00:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEuym-0001vN-ON for ecrit@megatron.ietf.org; Fri, 25 Mar 2005 15:00:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04831 for ; Fri, 25 Mar 2005 15:00:22 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEv4j-0003GM-9M for ecrit@ietf.org; Fri, 25 Mar 2005 15:06:33 -0500 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 j2PK03k23908; Fri, 25 Mar 2005 14:00:03 -0600 (CST) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 26 Mar 2005 06:59:12 +1100 Message-ID: From: "James Winterbottom" To: Marc Linsner , ecrit@ietf.org Subject: RE: [Ecrit] requirements Date: Sat, 26 Mar 2005 06:59:08 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.3 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 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="===============1156066551==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b 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. --===============1156066551== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53175.1B4C0F12" 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_01C53175.1B4C0F12 Content-Type: text/plain Yup... *8) Thanx -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Saturday, 26 March 2005 6:57 AM To: Winterbottom, James [WOLL:5500:EXCH]; ecrit@ietf.org Subject: RE: [Ecrit] requirements I obviously typed before thinking below when I said, "I also believe the security and threats section needs to discuss aspects of each user policy." I believe the security and threats discussion needs to cover the aspects of sending a lo w/o signature and sending a lo with signature? It should not matter who owns the policy. Is that better? -Marc- ------_=_NextPart_001_01C53175.1B4C0F12 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
Yup...=20 *8)
 
Thanx
-----Original Message-----
From: = Marc Linsner=20 [mailto:mlinsner@cisco.com]
Sent: Saturday, 26 March 2005 = 6:57=20 AM
To: Winterbottom, James [WOLL:5500:EXCH];=20 ecrit@ietf.org
Subject: RE: [Ecrit]=20 requirements

I = obviously typed=20 before thinking below when I said, "I also believe the security and threats = section needs=20 to discuss aspects of each user policy."

I believe = the=20 security and threats discussion needs to cover the aspects of sending = a lo w/o=20 signature and sending a lo with signature?  It should not matter = who owns=20 the policy.

 

Is that=20 better?

 

-Marc-

 

 

 

 
------_=_NextPart_001_01C53175.1B4C0F12-- --===============1156066551== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1156066551==-- From ecrit-bounces@ietf.org Fri Mar 25 16:34:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19211; Fri, 25 Mar 2005 16:34:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEwXi-000799-BZ; Fri, 25 Mar 2005 16:40:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEwOm-0007ew-2C; Fri, 25 Mar 2005 16:31:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEwOk-0007en-L8 for ecrit@megatron.ietf.org; Fri, 25 Mar 2005 16:31:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18628 for ; Fri, 25 Mar 2005 16:31:16 -0500 (EST) 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.33) id 1DEwTR-0006pp-5p for ecrit@ietf.org; Fri, 25 Mar 2005 16:36:10 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 25 Mar 2005 13:29:50 -0800 X-IronPort-AV: i="3.91,123,1110182400"; d="scan'208,217"; a="240953269:sNHT55875644" Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2PLTmZV019641; Fri, 25 Mar 2005 13:29:48 -0800 (PST) Received: from MLINSNER (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA26857; Fri, 25 Mar 2005 13:29:46 -0800 (PST) Message-Id: <200503252129.NAA26857@malone.cisco.com> From: "Marc Linsner" To: "'James Winterbottom'" , Subject: RE: [Ecrit] requirements Date: Fri, 25 Mar 2005 16:29:44 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Thread-Index: AcUxdUp0xgB3JxdSQ/SX+r7097xXcwADFoIA X-Spam-Score: 1.3 (+) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 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="===============1243660775==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 This is a multi-part message in MIME format. --===============1243660775== Content-Type: multipart/alternative; boundary="----=_NextPart_000_03FE_01C53157.DB8D8D50" This is a multi-part message in MIME format. ------=_NextPart_000_03FE_01C53157.DB8D8D50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think I'm hearing a volunteer for the security doc.. -Marc- _____ From: James Winterbottom [mailto:winterb@nortel.com] Sent: Friday, March 25, 2005 2:59 PM To: Marc Linsner; ecrit@ietf.org Subject: RE: [Ecrit] requirements Yup... *8) Thanx -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Saturday, 26 March 2005 6:57 AM To: Winterbottom, James [WOLL:5500:EXCH]; ecrit@ietf.org Subject: RE: [Ecrit] requirements I obviously typed before thinking below when I said, "I also believe the security and threats section needs to discuss aspects of each user policy." I believe the security and threats discussion needs to cover the aspects of sending a lo w/o signature and sending a lo with signature? It should not matter who owns the policy. Is that better? -Marc- ------=_NextPart_000_03FE_01C53157.DB8D8D50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

I think I’m hearing a = volunteer for the security doc……

 

-Marc-

 

From: James Winterbottom [mailto:winterb@nortel.com]
Sent: Friday, March 25, = 2005 2:59 PM
To: Marc Linsner; = ecrit@ietf.org
Subject: RE: [Ecrit] = requirements

 

Yup... = *8)

 

Thanx

-----Original = Message-----
From: Marc Linsner [mailto:mlinsner@cisco.com]
Sent: Saturday, 26 March = 2005 6:57 AM
To: Winterbottom, James [WOLL:5500:EXCH]; ecrit@ietf.org
Subject: RE: [Ecrit] = requirements

I obviously typed before thinking below when I said, = "I also believe the security = and threats section needs to discuss aspects of each user = policy."

I believe the security and threats discussion needs to cover the aspects of sending a lo w/o signature and = sending a lo with signature?  It should not matter who owns the = policy.

 

Is that = better?

 

-Marc-

 

 

 

 

------=_NextPart_000_03FE_01C53157.DB8D8D50-- --===============1243660775== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1243660775==-- From ecrit-bounces@ietf.org Mon Mar 28 15:44:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10162; Mon, 28 Mar 2005 15:44:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG1CP-0006Me-SS; Mon, 28 Mar 2005 15:51:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG14x-0007l1-N8; Mon, 28 Mar 2005 15:43:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG14w-0007kw-DW for ecrit@megatron.ietf.org; Mon, 28 Mar 2005 15:43:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10018 for ; Mon, 28 Mar 2005 15:43:16 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG1BV-0006Kx-Qw for ecrit@ietf.org; Mon, 28 Mar 2005 15:50:06 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 28 Mar 2005 15:43:10 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2SKh6jI015663; Mon, 28 Mar 2005 15:43:06 -0500 (EST) 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); Mon, 28 Mar 2005 15:43:06 -0500 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: AW: AW: [Ecrit] requirements Date: Mon, 28 Mar 2005 15:43:05 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E304DBA3@xmb-rtp-20b.amer.cisco.com> Thread-Topic: AW: AW: [Ecrit] requirements Thread-Index: AcUxZ/+qrptJw0HYQxSRqMZJv4I/1wCbATAQ From: "Michael Hammer \(mhammer\)" To: "Abbott, Nadine B." , X-OriginalArrivalTime: 28 Mar 2005 20:43:06.0276 (UTC) FILETIME=[BE8B8640:01C533D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Nadine, As I understand it, location validation is not call-related, but is a process to ensure that each location to be used by the location service are registered with the PSAP system and assigned a specific PSAP to route to, i.e. the MSAG is up to date. My question is whether this maintenance of the MSAG involves a protocol that ECRIT is to define? A similar question relates to any database that maps from geographic coordinates to a civil space identified by a civil address. On a side note related to default to verbal confirmation of location by the caller, I know of a case where the police could not dispatch a car to a location even when the caller could identify they were near a particular type of store (only one within many miles) in a specific town because the PSAP person was in a different geographic area. These PSAPs need to be able to search (Google?) on landmarks to find street addresses. Asking the caller about street names and building numbers doesn't help when street signs and numbers are not visible, but marketing signs are. Mike >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Abbott, Nadine B. >Sent: Friday, March 25, 2005 1:22 PM >To: ecrit@ietf.org >Subject: RE: AW: AW: [Ecrit] requirements > >Hannes, > >At least as we have framed it in the Rosen contribution to=20 >ECRIT, "location validation" refers to capabilities necessary=20 >to ensure that a civic location object is routable and also=20 >useful for dispatch of emergency responders. >Since there are so many different representations of civic=20 >location information, human user confusion can contribute to=20 >incorrect, unroutable information being provided. The=20 >"location validation" function is intended to allow for=20 >corrections of errors and confusion BEFORE there is an >emergency. (We have been informed that the term "location=20 >validation" may >cause confusion because of other connotations in other=20 >contexts, but have tried to qualify and explain the use of the=20 >term to alleviate this.) I think that if non-routable civic=20 >addresses were commonplace, it wouldn't really matter what=20 >mechanism ecrit specified for routing them--garbage >in-->garbage out. > >"Location validation" is not the same as authenticating that=20 >any given location object has been provided by a particular entity. > >Thanks, >Nadine > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of James M. Polk >Sent: Wednesday, March 23, 2005 2:49 PM >To: Tschofenig Hannes; 'Henning Schulzrinne' >Cc: Ciesla, Larry; ecrit@ietf.org >Subject: Re: AW: AW: [Ecrit] requirements > > >At 08:34 PM 3/23/2005 +0100, Tschofenig Hannes wrote: > >> > >> > Allowed by whom? Do we assume that one has to have a license to=20 >> > provide such services? Who would hand out such licenses?=20 >(As far as=20 >> > I know, nobody has licensed Columbia University to provide=20 >> > telecommunication services and I guess we thus would not=20 >be able to=20 >> > legally provide campus-level location information.) >> >>that's exactly my point. >>if we dig deeper into the authorization issues then we encounter=20 >>various problems. > >Isn't "location validation" another form of "authorized=20 >location information for usage"? > >Is this part of our message routing charter? > > >>ciao >>hannes >> >> > >> >>_______________________________________________ >>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 > >_______________________________________________ >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 Mon Mar 28 16:48:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15633; Mon, 28 Mar 2005 16:48:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG2CC-0000Bi-P6; Mon, 28 Mar 2005 16:54:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG22D-0003DG-Eo; Mon, 28 Mar 2005 16:44:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG22A-0003D8-1M for ecrit@megatron.ietf.org; Mon, 28 Mar 2005 16:44:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15033 for ; Mon, 28 Mar 2005 16:44:27 -0500 (EST) Message-Id: <200503282144.QAA15033@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG28j-0008Rl-Og for ecrit@ietf.org; Mon, 28 Mar 2005 16:51:18 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DG21t-0004Xq-Io; Mon, 28 Mar 2005 15:44:13 -0600 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Abbott, Nadine B.'" , Subject: RE: AW: AW: [Ecrit] requirements Date: Mon, 28 Mar 2005 16:44:02 -0500 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.2180 Thread-Index: AcUxZ/+qrptJw0HYQxSRqMZJv4I/1wCbATAQAAKd8XA= In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E304DBA3@xmb-rtp-20b.amer.cisco.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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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 X-Spam-Score: 0.8 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: 7bit Maintenance of the database is not something I think ecrit would deal with. However, since the database that routes COULD be the database that is used for validation, indeed, the definition of valid could be that a route exists for that location, I think it's in scope to say that before you are called upon to route based on a location, that location must be a valid, i.e. a location that is routable. I think geocoding databases would be in scope if the routing solution worked only on one representation and required a conversion to accomplish it. The requirements document that I submitted on behalf of NENA says that you can't do that. The "local knowledge" argument is pretty compelling, and it's one of the reasons there are approximately 6,134 PSAPs in North America. The local governments make that argument when someone tries to suggest consolidation to fewer PSAPs. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Michael Hammer (mhammer) > Sent: Monday, March 28, 2005 3:43 PM > To: Abbott, Nadine B.; ecrit@ietf.org > Subject: RE: AW: AW: [Ecrit] requirements > > Nadine, > > As I understand it, location validation is not call-related, but is a > process to ensure that each location to be used by the location service > are registered with the PSAP system and assigned a specific PSAP to > route to, i.e. the MSAG is up to date. My question is whether this > maintenance of the MSAG involves a protocol that ECRIT is to define? > > A similar question relates to any database that maps from geographic > coordinates to a civil space identified by a civil address. > > On a side note related to default to verbal confirmation of location by > the caller, I know of a case where the police could not dispatch a car > to a location even when the caller could identify they were near a > particular type of store (only one within many miles) in a specific town > because the PSAP person was in a different geographic area. These PSAPs > need to be able to search (Google?) on landmarks to find street > addresses. Asking the caller about street names and building numbers > doesn't help when street signs and numbers are not visible, but > marketing signs are. > > Mike > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of Abbott, Nadine B. > >Sent: Friday, March 25, 2005 1:22 PM > >To: ecrit@ietf.org > >Subject: RE: AW: AW: [Ecrit] requirements > > > >Hannes, > > > >At least as we have framed it in the Rosen contribution to > >ECRIT, "location validation" refers to capabilities necessary > >to ensure that a civic location object is routable and also > >useful for dispatch of emergency responders. > >Since there are so many different representations of civic > >location information, human user confusion can contribute to > >incorrect, unroutable information being provided. The > >"location validation" function is intended to allow for > >corrections of errors and confusion BEFORE there is an > >emergency. (We have been informed that the term "location > >validation" may > >cause confusion because of other connotations in other > >contexts, but have tried to qualify and explain the use of the > >term to alleviate this.) I think that if non-routable civic > >addresses were commonplace, it wouldn't really matter what > >mechanism ecrit specified for routing them--garbage > >in-->garbage out. > > > >"Location validation" is not the same as authenticating that > >any given location object has been provided by a particular entity. > > > >Thanks, > >Nadine > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of James M. Polk > >Sent: Wednesday, March 23, 2005 2:49 PM > >To: Tschofenig Hannes; 'Henning Schulzrinne' > >Cc: Ciesla, Larry; ecrit@ietf.org > >Subject: Re: AW: AW: [Ecrit] requirements > > > > > >At 08:34 PM 3/23/2005 +0100, Tschofenig Hannes wrote: > > > >> > > >> > Allowed by whom? Do we assume that one has to have a license to > >> > provide such services? Who would hand out such licenses? > >(As far as > >> > I know, nobody has licensed Columbia University to provide > >> > telecommunication services and I guess we thus would not > >be able to > >> > legally provide campus-level location information.) > >> > >>that's exactly my point. > >>if we dig deeper into the authorization issues then we encounter > >>various problems. > > > >Isn't "location validation" another form of "authorized > >location information for usage"? > > > >Is this part of our message routing charter? > > > > > >>ciao > >>hannes > >> > >> > > >> > >>_______________________________________________ > >>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 > > > >_______________________________________________ > >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 Mon Mar 28 16:59:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16403; Mon, 28 Mar 2005 16:59:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG2NA-0000WK-Vv; Mon, 28 Mar 2005 17:06:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG2GZ-00050z-D4; Mon, 28 Mar 2005 16:59:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG2GY-00050u-Ie for ecrit@megatron.ietf.org; Mon, 28 Mar 2005 16:59:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16400 for ; Mon, 28 Mar 2005 16:59:20 -0500 (EST) Received: from dnsmx1pya.telcordia.com ([128.96.20.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG2N7-0000W6-Hd for ecrit@ietf.org; Mon, 28 Mar 2005 17:06:10 -0500 Received: from rrc-its-ieg02.cc.telcordia.com (rrc-its-ieg02.cc.telcordia.com [128.96.109.3]) by dnsmx1pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j2SLx8j13504 for ; Mon, 28 Mar 2005 16:59:08 -0500 (EST) Received: from rrc-its-exig01.mail.saic.com ([128.96.103.57]) by rrc-its-ieg02.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005032816590723270 for ; Mon, 28 Mar 2005 16:59:07 -0500 Received: by rrc-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 28 Mar 2005 16:59:07 -0500 Message-ID: From: "Abbott, Nadine B." To: ecrit@ietf.org Subject: RE: AW: AW: [Ecrit] requirements Date: Mon, 28 Mar 2005 16:59:07 -0500 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: cd3fc8e909678b38737fc606dec187f0 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Mike, I think that your understanding of location validation is basically correct. This function is particularly important for routing in environments that support routing to a PSAP based upon detailed location information. In other countries, there may be only one Emergency Call Center, and the location information is used primarily in dispatch of emergency responders. It's probably sufficient for the ecrit WG to require that location information be pre-validated to determine that it is useful for routing emergency calls. For the US and Canada, the National Emergency Number Association has been discussing proposals for an interface for location validation in relation to the MSAG, including consideration of addressing abbreviation conventions specific to those countries. At this time, a Web Services-like query approach is being investigated to support this interface. The specification of this interface may have value for other countries that support location-based routing, but the usefulness of the underlying data of course is probably local in nature. Nothing is final or approved at this time, but I think we'd be happy to share what we have been thinking about, if it is deemed useful for discussion by the rest of the ecrit WG. I think that data exchange interfaces to support the maintenance/upkeep of [MSAG-based] location validation data is probably out of scope for ecrit. With respect to "A similar question relates to any database that maps from geographic coordinates to a civil space identified by a civil address"--are you asking if there are interfaces for data exchanges or data conversions of routing data that should be addressed by the ecrit WG? I personally think that this is perhaps outside the expertise, as well as the scope, of the ecrit WG? With respect to the interesting side note that you raised, in the US some PSAP call-takers do have access to geo-coded landmark data to assist in locating callers, at least within their local serving areas. When it is available, shared PSAP access to such data is not typical today. I think that an alternative may be more accurate/specific default routing and/or location-based call transfer capabilities to get the call closer to a knowledgable PSAP? Nadine Abbott -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Monday, March 28, 2005 3:43 PM To: Abbott, Nadine B.; ecrit@ietf.org Subject: RE: AW: AW: [Ecrit] requirements Nadine, As I understand it, location validation is not call-related, but is a process to ensure that each location to be used by the location service are registered with the PSAP system and assigned a specific PSAP to route to, i.e. the MSAG is up to date. My question is whether this maintenance of the MSAG involves a protocol that ECRIT is to define? A similar question relates to any database that maps from geographic coordinates to a civil space identified by a civil address. On a side note related to default to verbal confirmation of location by the caller, I know of a case where the police could not dispatch a car to a location even when the caller could identify they were near a particular type of store (only one within many miles) in a specific town because the PSAP person was in a different geographic area. These PSAPs need to be able to search (Google?) on landmarks to find street addresses. Asking the caller about street names and building numbers doesn't help when street signs and numbers are not visible, but marketing signs are. Mike >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Abbott, Nadine B. >Sent: Friday, March 25, 2005 1:22 PM >To: ecrit@ietf.org >Subject: RE: AW: AW: [Ecrit] requirements > >Hannes, > >At least as we have framed it in the Rosen contribution to >ECRIT, "location validation" refers to capabilities necessary >to ensure that a civic location object is routable and also >useful for dispatch of emergency responders. >Since there are so many different representations of civic >location information, human user confusion can contribute to >incorrect, unroutable information being provided. The >"location validation" function is intended to allow for >corrections of errors and confusion BEFORE there is an >emergency. (We have been informed that the term "location >validation" may >cause confusion because of other connotations in other >contexts, but have tried to qualify and explain the use of the >term to alleviate this.) I think that if non-routable civic >addresses were commonplace, it wouldn't really matter what >mechanism ecrit specified for routing them--garbage >in-->garbage out. > >"Location validation" is not the same as authenticating that >any given location object has been provided by a particular entity. > >Thanks, >Nadine > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of James M. Polk >Sent: Wednesday, March 23, 2005 2:49 PM >To: Tschofenig Hannes; 'Henning Schulzrinne' >Cc: Ciesla, Larry; ecrit@ietf.org >Subject: Re: AW: AW: [Ecrit] requirements > > >At 08:34 PM 3/23/2005 +0100, Tschofenig Hannes wrote: > >> > >> > Allowed by whom? Do we assume that one has to have a license to >> > provide such services? Who would hand out such licenses? >(As far as >> > I know, nobody has licensed Columbia University to provide >> > telecommunication services and I guess we thus would not >be able to >> > legally provide campus-level location information.) >> >>that's exactly my point. >>if we dig deeper into the authorization issues then we encounter >>various problems. > >Isn't "location validation" another form of "authorized >location information for usage"? > >Is this part of our message routing charter? > > >>ciao >>hannes >> >> > >> >>_______________________________________________ >>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 > >_______________________________________________ >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 Mon Mar 28 17:14:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17482; Mon, 28 Mar 2005 17:14:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG2bU-00011U-UO; Mon, 28 Mar 2005 17:21:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG2U1-0000QJ-20; Mon, 28 Mar 2005 17:13:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG2Tz-0000QE-6t for ecrit@megatron.ietf.org; Mon, 28 Mar 2005 17:13:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17437 for ; Mon, 28 Mar 2005 17:13:12 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG2aZ-00010T-GD for ecrit@ietf.org; Mon, 28 Mar 2005 17:20:03 -0500 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j2SMD6h3017395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Mar 2005 17:13:07 -0500 (EST) Message-ID: <4248816D.4060400@cs.columbia.edu> Date: Mon, 28 Mar 2005 17:13:01 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Abbott, Nadine B." Subject: Re: AW: AW: [Ecrit] requirements 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, __KNOWN_SPAMMER_ADDRESS_5 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Before having some dauntingly large number of protocols, it would be nice to have some idea as to what the ECRIT lookup protocol might be. There has been one fairly concrete proposal (DNS) and one fairly vague proposal (IRIS, which I mentioned in a few slides). I believe the issue raised for DNS was the lack of detailed error feedback. Abbott, Nadine B. wrote: > Mike, > > I think that your understanding of location validation is basically correct. > This function is particularly important for routing in environments that > support routing to a PSAP based upon detailed location information. In other > countries, there may be only one Emergency Call Center, and the location > information is used primarily in dispatch of emergency responders. > > It's probably sufficient for the ecrit WG to require that location > information be pre-validated to determine that it is useful for routing > emergency calls. For the US and Canada, the National Emergency Number > Association has been discussing proposals for an interface for location > validation in relation to the MSAG, including consideration of addressing > abbreviation conventions specific to those countries. At this time, a Web > Services-like query approach is being investigated to support this > interface. The specification of this interface may have value for other > countries that support location-based routing, but the usefulness of the > underlying data of course is probably local in nature. Nothing is final or > approved at this time, but I think we'd be happy to share what we have been > thinking about, if it is deemed useful for discussion by the rest of the > ecrit WG. I think that data exchange interfaces to support the > maintenance/upkeep of [MSAG-based] location validation data is probably out > of scope for ecrit. > > With respect to "A similar question relates to any database that maps from > geographic coordinates to a civil space identified by a civil address"--are > you asking if there are interfaces for data exchanges or data conversions of > routing data that should be addressed by the ecrit WG? I personally think > that this is perhaps outside the expertise, as well as the scope, of the > ecrit WG? > > With respect to the interesting side note that you raised, in the US some > PSAP call-takers do have access to geo-coded landmark data to assist in > locating callers, at least within their local serving areas. When it is > available, shared PSAP access to such data is not typical today. I think > that an alternative may be more accurate/specific default routing and/or > location-based call transfer capabilities to get the call closer to a > knowledgable PSAP? > > Nadine Abbott _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 28 17:26:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18731; Mon, 28 Mar 2005 17:26:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG2nm-0001UU-DF; Mon, 28 Mar 2005 17:33:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG2fG-0002Lp-Vr; Mon, 28 Mar 2005 17:24:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG2fF-0002L0-TH for ecrit@megatron.ietf.org; Mon, 28 Mar 2005 17:24:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18590 for ; Mon, 28 Mar 2005 17:24:51 -0500 (EST) Received: from dnsmx1pya.telcordia.com ([128.96.20.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG2lq-0001Rn-9d for ecrit@ietf.org; Mon, 28 Mar 2005 17:31:42 -0500 Received: from rrc-its-ieg02.cc.telcordia.com (rrc-its-ieg02.cc.telcordia.com [128.96.109.3]) by dnsmx1pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j2SMOhj17735 for ; Mon, 28 Mar 2005 17:24:43 -0500 (EST) Received: from rrc-its-exig01.mail.saic.com ([128.96.103.57]) by rrc-its-ieg02.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005032817244224357 for ; Mon, 28 Mar 2005 17:24:42 -0500 Received: by rrc-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 28 Mar 2005 17:24:42 -0500 Message-ID: From: "Abbott, Nadine B." To: ecrit@ietf.org Subject: RE: AW: AW: [Ecrit] requirements Date: Mon, 28 Mar 2005 17:24:39 -0500 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: 082a9cbf4d599f360ac7f815372a6a15 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 I think that having civic location information (street addresses) pre-validated should reduce the need for detailed error feedback during emergency call routing (or test calling), should it not? -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, March 28, 2005 5:13 PM To: Abbott, Nadine B. Cc: ecrit@ietf.org Subject: Re: AW: AW: [Ecrit] requirements Before having some dauntingly large number of protocols, it would be nice to have some idea as to what the ECRIT lookup protocol might be. There has been one fairly concrete proposal (DNS) and one fairly vague proposal (IRIS, which I mentioned in a few slides). I believe the issue raised for DNS was the lack of detailed error feedback. Abbott, Nadine B. wrote: > Mike, > > I think that your understanding of location validation is basically > correct. This function is particularly important for routing in > environments that support routing to a PSAP based upon detailed > location information. In other countries, there may be only one > Emergency Call Center, and the location information is used primarily > in dispatch of emergency responders. > > It's probably sufficient for the ecrit WG to require that location > information be pre-validated to determine that it is useful for > routing emergency calls. For the US and Canada, the National > Emergency Number Association has been discussing proposals for an > interface for location validation in relation to the MSAG, including > consideration of addressing abbreviation conventions specific to those > countries. At this time, a Web Services-like query approach is being > investigated to support this interface. The specification of this > interface may have value for other countries that support > location-based routing, but the usefulness of the underlying data of > course is probably local in nature. Nothing is final or approved at > this time, but I think we'd be happy to share what we have been thinking about, if it is deemed useful for discussion by the rest of the > ecrit WG. I think that data exchange interfaces to support the > maintenance/upkeep of [MSAG-based] location validation data is > probably out of scope for ecrit. > > With respect to "A similar question relates to any database that maps > from geographic coordinates to a civil space identified by a civil > address"--are you asking if there are interfaces for data exchanges or > data conversions of routing data that should be addressed by the ecrit > WG? I personally think that this is perhaps outside the expertise, as > well as the scope, of the ecrit WG? > > With respect to the interesting side note that you raised, in the US > some PSAP call-takers do have access to geo-coded landmark data to > assist in locating callers, at least within their local serving areas. > When it is available, shared PSAP access to such data is not typical > today. I think that an alternative may be more accurate/specific > default routing and/or location-based call transfer capabilities to > get the call closer to a knowledgable PSAP? > > Nadine Abbott _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 28 17:56:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20850; Mon, 28 Mar 2005 17:56:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG3Gt-0002Vg-1W; Mon, 28 Mar 2005 18:03:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG394-00081N-HZ; Mon, 28 Mar 2005 17:55:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG393-00080P-KP for ecrit@megatron.ietf.org; Mon, 28 Mar 2005 17:55:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20721 for ; Mon, 28 Mar 2005 17:55:38 -0500 (EST) Message-Id: <200503282255.RAA20721@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG3Fe-0002S3-90 for ecrit@ietf.org; Mon, 28 Mar 2005 18:02:30 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DG38t-0001Ax-LR; Mon, 28 Mar 2005 16:55:31 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Abbott, Nadine B.'" Subject: RE: AW: AW: [Ecrit] requirements Date: Mon, 28 Mar 2005 17:55:20 -0500 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.2180 Thread-Index: AcUz43hecrM6DBvWT8aknxVGlnCV0wABLqmQ In-Reply-To: <4248816D.4060400@cs.columbia.edu> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 X-Spam-Score: 0.8 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit I think we figured out a simple way to do detailed error resolution with the DNS proposal. Of course, I'm in favor of the DNS idea. My major reason is that we know that the DNS is very reliable in the face of failure. That's a very nice property for something used to route emergency calls when disasters strike. No new protocol with limited deployment can make such a claim. The current proposal is a by-the-book DDDS application, but following recent guidance, I'm happy to propose some new RRs specifically for the purpose. BTW I'm aware of a couple of cases of folks trying the DNS idea; we have some running code. It's pretty trivial, so if we want to organize some demos, it's pretty easy to do. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Henning Schulzrinne > Sent: Monday, March 28, 2005 5:13 PM > To: Abbott, Nadine B. > Cc: ecrit@ietf.org > Subject: Re: AW: AW: [Ecrit] requirements > > Before having some dauntingly large number of protocols, it would be > nice to have some idea as to what the ECRIT lookup protocol might be. > There has been one fairly concrete proposal (DNS) and one fairly vague > proposal (IRIS, which I mentioned in a few slides). I believe the issue > raised for DNS was the lack of detailed error feedback. > > Abbott, Nadine B. wrote: > > Mike, > > > > I think that your understanding of location validation is basically > correct. > > This function is particularly important for routing in environments that > > support routing to a PSAP based upon detailed location information. In > other > > countries, there may be only one Emergency Call Center, and the location > > information is used primarily in dispatch of emergency responders. > > > > It's probably sufficient for the ecrit WG to require that location > > information be pre-validated to determine that it is useful for routing > > emergency calls. For the US and Canada, the National Emergency Number > > Association has been discussing proposals for an interface for location > > validation in relation to the MSAG, including consideration of > addressing > > abbreviation conventions specific to those countries. At this time, a > Web > > Services-like query approach is being investigated to support this > > interface. The specification of this interface may have value for other > > countries that support location-based routing, but the usefulness of the > > underlying data of course is probably local in nature. Nothing is final > or > > approved at this time, but I think we'd be happy to share what we have > been > > thinking about, if it is deemed useful for discussion by the rest of the > > ecrit WG. I think that data exchange interfaces to support the > > maintenance/upkeep of [MSAG-based] location validation data is probably > out > > of scope for ecrit. > > > > With respect to "A similar question relates to any database that maps > from > > geographic coordinates to a civil space identified by a civil address"-- > are > > you asking if there are interfaces for data exchanges or data > conversions of > > routing data that should be addressed by the ecrit WG? I personally > think > > that this is perhaps outside the expertise, as well as the scope, of the > > ecrit WG? > > > > With respect to the interesting side note that you raised, in the US > some > > PSAP call-takers do have access to geo-coded landmark data to assist in > > locating callers, at least within their local serving areas. When it is > > available, shared PSAP access to such data is not typical today. I > think > > that an alternative may be more accurate/specific default routing and/or > > location-based call transfer capabilities to get the call closer to a > > knowledgable PSAP? > > > > Nadine Abbott > > _______________________________________________ > 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 Mon Mar 28 18:20:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24158; Mon, 28 Mar 2005 18:20:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG3dc-0003KW-Fw; Mon, 28 Mar 2005 18:27:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG3Wk-0004lW-62; Mon, 28 Mar 2005 18:20:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG3Wh-0004kw-VC for ecrit@megatron.ietf.org; Mon, 28 Mar 2005 18:20:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24124 for ; Mon, 28 Mar 2005 18:20:04 -0500 (EST) Received: from mail.easycgi.com ([66.245.177.160] helo=easycgi.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG3dH-0003Jx-NT for ecrit@ietf.org; Mon, 28 Mar 2005 18:26:56 -0500 Received: from [70.16.239.176] (account marks@maximtsc.com) by easycgi.com (CommuniGate Pro WebUser 4.2.3) with HTTP id 45219537 for ecrit@ietf.org; Mon, 28 Mar 2005 18:22:59 -0500 From: "Mark Scharaga" To: ecrit@ietf.org X-Mailer: CommuniGate Pro WebUser Interface v.4.2.3 Date: Mon, 28 Mar 2005 18:22:59 -0500 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 8bit Subject: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 23 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 8bit I see some interesting points being made here and felt I may be able to add some comments that may offer some insight. I've spent the better part of 12 years working in the PSAP environment. Most PSAPs are using Computer Aided Dispatch software applications which allow them to build response scenarios for beats,patrol areas, and/or zones. This is built using a few different ways, depending upon the CAD system, some systems are geo based and can use coordinates (the drawback is the County/City must have solid map data) while others are more tabular and use the msag. One function within many CAD and newer E-911 systems is the ability to build common place and location files. If this is integrated with mapping, the dispatcher can do a variety of searches on location types. One issue that stands out to me is the variety of technology in use amongst the PSAPs and there are many degress to which it was implemented. My view is if nothing else is delivered to the PSAP it should be the basic location address for the caller. Anything beyond that should be a state defined issue. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 28 18:24:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24586; Mon, 28 Mar 2005 18:24:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG3hY-0003T7-AD; Mon, 28 Mar 2005 18:31:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG3af-0005Sm-98; Mon, 28 Mar 2005 18:24:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG3ad-0005Sh-J8 for ecrit@megatron.ietf.org; Mon, 28 Mar 2005 18:24:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24573 for ; Mon, 28 Mar 2005 18:24:08 -0500 (EST) Message-Id: <200503282324.SAA24573@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG3hE-0003Sl-H0 for ecrit@ietf.org; Mon, 28 Mar 2005 18:31:00 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DG3aT-0003hL-O1; Mon, 28 Mar 2005 17:24:01 -0600 From: "Brian Rosen" To: "'Mark Scharaga'" , Subject: RE: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 23 Date: Mon, 28 Mar 2005 18:23:50 -0500 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.2180 Thread-Index: AcUz7LkP+38DGSlqSYiT5tiX507XdAAAB5AQ 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 X-Spam-Score: 0.8 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit At the moment, this working group is only concerned with how to route a call to the right PSAP, and not what the PSAP gets. I suspect that you are wrong that standardization is not appropriate for what, beyond location, is sent to PSAPs, but that is not in scope for this list. Please join us at the i3 discussion in NENA. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Mark Scharaga > Sent: Monday, March 28, 2005 6:23 PM > To: ecrit@ietf.org > Subject: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 23 > > I see some interesting points being made here and felt I > may be able to add some comments that may offer some > insight. I've spent the better part of 12 years working in > the PSAP environment. > > Most PSAPs are using Computer Aided Dispatch software > applications which allow them to build response scenarios > for beats,patrol areas, and/or zones. This is built using > a few different ways, depending upon the CAD system, some > systems are geo based and can use coordinates (the > drawback is the County/City must have solid map data) > while others are more tabular and use the msag. > > One function within many CAD and newer E-911 systems is > the ability to build common place and location files. If > this is integrated with mapping, the dispatcher can do a > variety of searches on location types. > > One issue that stands out to me is the variety of > technology in use amongst the PSAPs and there are many > degress to which it was implemented. > > My view is if nothing else is delivered to the PSAP it > should be the basic location address for the caller. > Anything beyond that should be a state defined issue. > > _______________________________________________ > 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 Mar 30 14:37:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02398; Wed, 30 Mar 2005 14:37:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGj70-0000Mr-Ge; Wed, 30 Mar 2005 14:44:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGiyS-0007Iv-UW; Wed, 30 Mar 2005 14:35:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGiyR-0007Ip-6s for ecrit@megatron.ietf.org; Wed, 30 Mar 2005 14:35:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02259 for ; Wed, 30 Mar 2005 14:35:28 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DGj5M-0000L2-Ps for ecrit@ietf.org; Wed, 30 Mar 2005 14:42:42 -0500 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] requirements Date: Wed, 30 Mar 2005 21:37:54 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BD32@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] requirements Thread-Index: AcUxZ/+qrptJw0HYQxSRqMZJv4I/1wCbATAQAGK7f6U= From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: quoted-printable >As I understand it, location validation is not call-related, but is a >process to ensure that each location to be used by the location service >are registered with the PSAP system and assigned a specific PSAP to >route to, i.e. the MSAG is up to date. =20 =20 >A similar question relates to any database that maps from geographic >coordinates to a civil space identified by a civil address. Maybe I am wrong, but during this discussion I got the impression that location validation means the mapping to a valid street address to = determine the correct PSAP. But what about emergancy calls coming from "outdoors". Many calls from = mobile phones are coming people trecking or skiing, and here you normally do not have a street address (sos.mountain, sos.coast) How are these locations "validated"? Richard ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) Gesendet: Mo 28.03.2005 22:43 An: Abbott, Nadine B.; ecrit@ietf.org Betreff: RE: AW: AW: [Ecrit] requirements Nadine, As I understand it, location validation is not call-related, but is a process to ensure that each location to be used by the location service are registered with the PSAP system and assigned a specific PSAP to route to, i.e. the MSAG is up to date. My question is whether this maintenance of the MSAG involves a protocol that ECRIT is to define? A similar question relates to any database that maps from geographic coordinates to a civil space identified by a civil address. On a side note related to default to verbal confirmation of location by the caller, I know of a case where the police could not dispatch a car to a location even when the caller could identify they were near a particular type of store (only one within many miles) in a specific town because the PSAP person was in a different geographic area. These PSAPs need to be able to search (Google?) on landmarks to find street addresses. Asking the caller about street names and building numbers doesn't help when street signs and numbers are not visible, but marketing signs are. Mike >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Abbott, Nadine B. >Sent: Friday, March 25, 2005 1:22 PM >To: ecrit@ietf.org >Subject: RE: AW: AW: [Ecrit] requirements > >Hannes, > >At least as we have framed it in the Rosen contribution to >ECRIT, "location validation" refers to capabilities necessary >to ensure that a civic location object is routable and also >useful for dispatch of emergency responders. >Since there are so many different representations of civic >location information, human user confusion can contribute to >incorrect, unroutable information being provided. The >"location validation" function is intended to allow for >corrections of errors and confusion BEFORE there is an >emergency. (We have been informed that the term "location >validation" may >cause confusion because of other connotations in other >contexts, but have tried to qualify and explain the use of the >term to alleviate this.) I think that if non-routable civic >addresses were commonplace, it wouldn't really matter what >mechanism ecrit specified for routing them--garbage >in-->garbage out. > >"Location validation" is not the same as authenticating that >any given location object has been provided by a particular entity. > >Thanks, >Nadine > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of James M. Polk >Sent: Wednesday, March 23, 2005 2:49 PM >To: Tschofenig Hannes; 'Henning Schulzrinne' >Cc: Ciesla, Larry; ecrit@ietf.org >Subject: Re: AW: AW: [Ecrit] requirements > > >At 08:34 PM 3/23/2005 +0100, Tschofenig Hannes wrote: > >> > >> > Allowed by whom? Do we assume that one has to have a license to >> > provide such services? Who would hand out such licenses? >(As far as >> > I know, nobody has licensed Columbia University to provide >> > telecommunication services and I guess we thus would not >be able to >> > legally provide campus-level location information.) >> >>that's exactly my point. >>if we dig deeper into the authorization issues then we encounter >>various problems. > >Isn't "location validation" another form of "authorized >location information for usage"? > >Is this part of our message routing charter? > > >>ciao >>hannes >> >> > >> >>_______________________________________________ >>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 > >_______________________________________________ >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 Mar 30 15:43:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08739; Wed, 30 Mar 2005 15:43:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGk8k-0001l2-LM; Wed, 30 Mar 2005 15:50:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGjxU-00080e-IS; Wed, 30 Mar 2005 15:38:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGjxQ-0007x9-LV for ecrit@megatron.ietf.org; Wed, 30 Mar 2005 15:38:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07772 for ; Wed, 30 Mar 2005 15:38:19 -0500 (EST) Received: from dnsmx2pya.telcordia.com ([128.96.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGk4B-0001V8-7V for ecrit@ietf.org; Wed, 30 Mar 2005 15:45:33 -0500 Received: from rrc-its-ieg02.cc.telcordia.com (rrc-its-ieg02.cc.telcordia.com [128.96.109.3]) by dnsmx2pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j2UKaqa28278; Wed, 30 Mar 2005 15:36:54 -0500 (EST) Received: from rrc-its-exig01.mail.saic.com ([128.96.103.57]) by rrc-its-ieg02.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005033015364921818 ; Wed, 30 Mar 2005 15:36:49 -0500 Received: by rrc-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Wed, 30 Mar 2005 15:36:50 -0500 Message-ID: From: "Abbott, Nadine B." To: "'Stastny Richard'" , "Michael Hammer (mhammer)" , ecrit@ietf.org Subject: RE: [Ecrit] requirements Date: Wed, 30 Mar 2005 15:36:49 -0500 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: 156eddb66af16eef49a76ae923b15b92 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Richard, In the context in which it was proposed in the Rosen contribution from NENA, it applies only to civic location information. Geo-location doesn't have all the complexity. "Validating" it should be much simpler. Nadine -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Stastny Richard Sent: Wednesday, March 30, 2005 2:38 PM To: Michael Hammer (mhammer); ecrit@ietf.org Subject: Re: [Ecrit] requirements >As I understand it, location validation is not call-related, but is a >process to ensure that each location to be used by the location service >are registered with the PSAP system and assigned a specific PSAP to >route to, i.e. the MSAG is up to date. >A similar question relates to any database that maps from geographic >coordinates to a civil space identified by a civil address. Maybe I am wrong, but during this discussion I got the impression that location validation means the mapping to a valid street address to determine the correct PSAP. But what about emergancy calls coming from "outdoors". Many calls from mobile phones are coming people trecking or skiing, and here you normally do not have a street address (sos.mountain, sos.coast) How are these locations "validated"? Richard ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) Gesendet: Mo 28.03.2005 22:43 An: Abbott, Nadine B.; ecrit@ietf.org Betreff: RE: AW: AW: [Ecrit] requirements Nadine, As I understand it, location validation is not call-related, but is a process to ensure that each location to be used by the location service are registered with the PSAP system and assigned a specific PSAP to route to, i.e. the MSAG is up to date. My question is whether this maintenance of the MSAG involves a protocol that ECRIT is to define? A similar question relates to any database that maps from geographic coordinates to a civil space identified by a civil address. On a side note related to default to verbal confirmation of location by the caller, I know of a case where the police could not dispatch a car to a location even when the caller could identify they were near a particular type of store (only one within many miles) in a specific town because the PSAP person was in a different geographic area. These PSAPs need to be able to search (Google?) on landmarks to find street addresses. Asking the caller about street names and building numbers doesn't help when street signs and numbers are not visible, but marketing signs are. Mike >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of Abbott, Nadine B. >Sent: Friday, March 25, 2005 1:22 PM >To: ecrit@ietf.org >Subject: RE: AW: AW: [Ecrit] requirements > >Hannes, > >At least as we have framed it in the Rosen contribution to ECRIT, >"location validation" refers to capabilities necessary to ensure that a >civic location object is routable and also useful for dispatch of >emergency responders. Since there are so many different representations >of civic location information, human user confusion can contribute to >incorrect, unroutable information being provided. The >"location validation" function is intended to allow for >corrections of errors and confusion BEFORE there is an >emergency. (We have been informed that the term "location >validation" may >cause confusion because of other connotations in other >contexts, but have tried to qualify and explain the use of the >term to alleviate this.) I think that if non-routable civic >addresses were commonplace, it wouldn't really matter what >mechanism ecrit specified for routing them--garbage >in-->garbage out. > >"Location validation" is not the same as authenticating that any given >location object has been provided by a particular entity. > >Thanks, >Nadine > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of James M. Polk >Sent: Wednesday, March 23, 2005 2:49 PM >To: Tschofenig Hannes; 'Henning Schulzrinne' >Cc: Ciesla, Larry; ecrit@ietf.org >Subject: Re: AW: AW: [Ecrit] requirements > > >At 08:34 PM 3/23/2005 +0100, Tschofenig Hannes wrote: > >> > >> > Allowed by whom? Do we assume that one has to have a license to >> > provide such services? Who would hand out such licenses? >(As far as >> > I know, nobody has licensed Columbia University to provide >> > telecommunication services and I guess we thus would not >be able to >> > legally provide campus-level location information.) >> >>that's exactly my point. >>if we dig deeper into the authorization issues then we encounter >>various problems. > >Isn't "location validation" another form of "authorized location >information for usage"? > >Is this part of our message routing charter? > > >>ciao >>hannes >> >> > >> >>_______________________________________________ >>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 > >_______________________________________________ >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 Mar 30 15:54:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12370; Wed, 30 Mar 2005 15:54:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGkKH-000376-K8; Wed, 30 Mar 2005 16:02:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGk5r-0001oT-RN; Wed, 30 Mar 2005 15:47:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGk5q-0001mH-8l for ecrit@megatron.ietf.org; Wed, 30 Mar 2005 15:47:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09878 for ; Wed, 30 Mar 2005 15:47:12 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGkCn-000286-Pj for ecrit@ietf.org; Wed, 30 Mar 2005 15:54:27 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 30 Mar 2005 16:07:10 -0500 X-IronPort-AV: i="3.91,135,1110171600"; d="scan'208"; a="42535082:sNHT35370120" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2UKku1n026601; Wed, 30 Mar 2005 15:47:01 -0500 (EST) 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, 30 Mar 2005 15:47:00 -0500 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] requirements Date: Wed, 30 Mar 2005 15:46:59 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E304DC29@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] requirements Thread-Index: AcU1aGBU2mb2d3bYRF6MUhMp5D/tNAAALgjg From: "Michael Hammer \(mhammer\)" To: "Abbott, Nadine B." , "Stastny Richard" , X-OriginalArrivalTime: 30 Mar 2005 20:47:00.0526 (UTC) FILETIME=[9EFEBCE0:01C53569] X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Content-Transfer-Encoding: quoted-printable Nadine, Validation simply means it is in the database. For geographic that would mean that all points on the globe will result in a PSAP result, no? Or in other words, all the PSAPs in the worlds have mutully-exclusive global coverage assigned. Mike >-----Original Message----- >From: Abbott, Nadine B. [mailto:nabbott@telcordia.com]=20 >Sent: Wednesday, March 30, 2005 3:37 PM >To: 'Stastny Richard'; Michael Hammer (mhammer); ecrit@ietf.org >Subject: RE: [Ecrit] requirements > >Richard, >In the context in which it was proposed in the Rosen=20 >contribution from NENA, it applies only to civic location information. >Geo-location doesn't have all the complexity. "Validating" it=20 >should be much simpler. >Nadine > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Stastny Richard >Sent: Wednesday, March 30, 2005 2:38 PM >To: Michael Hammer (mhammer); ecrit@ietf.org >Subject: Re: [Ecrit] requirements > > >>As I understand it, location validation is not call-related, but is a=20 >>process to ensure that each location to be used by the=20 >location service=20 >>are registered with the PSAP system and assigned a specific PSAP to=20 >>route to, i.e. the MSAG is up to date. >=20 >>A similar question relates to any database that maps from geographic=20 >>coordinates to a civil space identified by a civil address. > >Maybe I am wrong, but during this discussion I got the=20 >impression that location validation means the mapping to a=20 >valid street address to determine the correct PSAP. > >But what about emergancy calls coming from "outdoors". Many=20 >calls from mobile phones are coming people trecking or skiing,=20 >and here you normally do not have a street address=20 >(sos.mountain, sos.coast) > >How are these locations "validated"? > >Richard > > > >________________________________ > >Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) >Gesendet: Mo 28.03.2005 22:43 >An: Abbott, Nadine B.; ecrit@ietf.org >Betreff: RE: AW: AW: [Ecrit] requirements > > > >Nadine, > >As I understand it, location validation is not call-related,=20 >but is a process to ensure that each location to be used by=20 >the location service are registered with the PSAP system and=20 >assigned a specific PSAP to route to, i.e. the MSAG is up to=20 >date. My question is whether this maintenance of the MSAG=20 >involves a protocol that ECRIT is to define? > >A similar question relates to any database that maps from=20 >geographic coordinates to a civil space identified by a civil address. > >On a side note related to default to verbal confirmation of=20 >location by the caller, I know of a case where the police=20 >could not dispatch a car to a location even when the caller=20 >could identify they were near a particular type of store (only=20 >one within many miles) in a specific town because the PSAP=20 >person was in a different geographic area. These PSAPs need=20 >to be able to search (Google?) on landmarks to find street=20 >addresses. Asking the caller about street names and building=20 >numbers doesn't help when street signs and numbers are not=20 >visible, but marketing signs are. > >Mike > > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >>Of Abbott, Nadine B. >>Sent: Friday, March 25, 2005 1:22 PM >>To: ecrit@ietf.org >>Subject: RE: AW: AW: [Ecrit] requirements >> >>Hannes, >> >>At least as we have framed it in the Rosen contribution to ECRIT,=20 >>"location validation" refers to capabilities necessary to=20 >ensure that a=20 >>civic location object is routable and also useful for dispatch of=20 >>emergency responders. Since there are so many different=20 >representations=20 >>of civic location information, human user confusion can contribute to=20 >>incorrect, unroutable information being provided. The "location=20 >>validation" function is intended to allow for corrections of=20 >errors and=20 >>confusion BEFORE there is an >>emergency. (We have been informed that the term "location >>validation" may >>cause confusion because of other connotations in other contexts, but=20 >>have tried to qualify and explain the use of the term to alleviate=20 >>this.) I think that if non-routable civic addresses were commonplace,=20 >>it wouldn't really matter what mechanism ecrit specified for routing=20 >>them--garbage >>in-->garbage out. >> >>"Location validation" is not the same as authenticating that=20 >any given=20 >>location object has been provided by a particular entity. >> >>Thanks, >>Nadine >> >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >>Of James M. Polk >>Sent: Wednesday, March 23, 2005 2:49 PM >>To: Tschofenig Hannes; 'Henning Schulzrinne' >>Cc: Ciesla, Larry; ecrit@ietf.org >>Subject: Re: AW: AW: [Ecrit] requirements >> >> >>At 08:34 PM 3/23/2005 +0100, Tschofenig Hannes wrote: >> >>> > >>> > Allowed by whom? Do we assume that one has to have a license to=20 >>> > provide such services? Who would hand out such licenses? >>(As far as >>> > I know, nobody has licensed Columbia University to provide=20 >>> > telecommunication services and I guess we thus would not >>be able to >>> > legally provide campus-level location information.) >>> >>>that's exactly my point. >>>if we dig deeper into the authorization issues then we encounter=20 >>>various problems. >> >>Isn't "location validation" another form of "authorized location=20 >>information for usage"? >> >>Is this part of our message routing charter? >> >> >>>ciao >>>hannes >>> >>> > >>> >>>_______________________________________________ >>>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 >> >>_______________________________________________ >>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 Mar 30 16:10:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17842; Wed, 30 Mar 2005 16:10:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGkZc-0004s1-Fn; Wed, 30 Mar 2005 16:18:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGkGq-0006xM-K7; Wed, 30 Mar 2005 15:58:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGkGp-0006wy-24 for ecrit@megatron.ietf.org; Wed, 30 Mar 2005 15:58:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13626 for ; Wed, 30 Mar 2005 15:58:32 -0500 (EST) Message-Id: <200503302058.PAA13626@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGkNn-0003UE-15 for ecrit@ietf.org; Wed, 30 Mar 2005 16:05:47 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DGkGK-0004LQ-Ke; Wed, 30 Mar 2005 14:58:04 -0600 From: "Brian Rosen" To: "'Abbott, Nadine B.'" , "'Stastny Richard'" , "'Michael Hammer \(mhammer\)'" , Subject: RE: [Ecrit] requirements Date: Wed, 30 Mar 2005 15:57:50 -0500 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.2180 Thread-Index: AcU1aQ+hX+85i2sZTraZ1jWFhAaKpwAAYH5g 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 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 X-Spam-Score: 0.8 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Content-Transfer-Encoding: 7bit Ya, I don't think a geo needs to be validated in the sense we are talking about. Every geo within a PSAP service area is a good geo, and routing and well as dispatch is possible. As a point of information, you can't dispatch to a geo; you can only dispatch to civic, at least presently. Thus, PSAPs have to build and maintain Geographic Information Systems that do "reverse geocoding"; they put a lat/lon in, and get a civic address out, that they use to confirm location with the caller and to dispatch to. That's local to the PSAP, and thus not an issue for ecrit. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Abbott, Nadine B. > Sent: Wednesday, March 30, 2005 3:37 PM > To: 'Stastny Richard'; Michael Hammer (mhammer); ecrit@ietf.org > Subject: RE: [Ecrit] requirements > > Richard, > In the context in which it was proposed in the Rosen contribution from > NENA, > it applies only to civic location information. > Geo-location doesn't have all the complexity. "Validating" it should be > much simpler. > Nadine > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Stastny Richard > Sent: Wednesday, March 30, 2005 2:38 PM > To: Michael Hammer (mhammer); ecrit@ietf.org > Subject: Re: [Ecrit] requirements > > > >As I understand it, location validation is not call-related, but is a > >process to ensure that each location to be used by the location service > >are registered with the PSAP system and assigned a specific PSAP to > >route to, i.e. the MSAG is up to date. > > >A similar question relates to any database that maps from geographic > >coordinates to a civil space identified by a civil address. > > Maybe I am wrong, but during this discussion I got the impression that > location validation means the mapping to a valid street address to > determine > the correct PSAP. > > But what about emergancy calls coming from "outdoors". Many calls from > mobile phones are coming people trecking or skiing, and here you normally > do > not have a street address (sos.mountain, sos.coast) > > How are these locations "validated"? > > Richard > > > > ________________________________ > > Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) > Gesendet: Mo 28.03.2005 22:43 > An: Abbott, Nadine B.; ecrit@ietf.org > Betreff: RE: AW: AW: [Ecrit] requirements > > > > Nadine, > > As I understand it, location validation is not call-related, but is a > process to ensure that each location to be used by the location service > are > registered with the PSAP system and assigned a specific PSAP to route to, > i.e. the MSAG is up to date. My question is whether this maintenance of > the > MSAG involves a protocol that ECRIT is to define? > > A similar question relates to any database that maps from geographic > coordinates to a civil space identified by a civil address. > > On a side note related to default to verbal confirmation of location by > the > caller, I know of a case where the police could not dispatch a car to a > location even when the caller could identify they were near a particular > type of store (only one within many miles) in a specific town because the > PSAP person was in a different geographic area. These PSAPs need to be > able > to search (Google?) on landmarks to find street addresses. Asking the > caller about street names and building numbers doesn't help when street > signs and numbers are not visible, but marketing signs are. > > Mike > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >Of Abbott, Nadine B. > >Sent: Friday, March 25, 2005 1:22 PM > >To: ecrit@ietf.org > >Subject: RE: AW: AW: [Ecrit] requirements > > > >Hannes, > > > >At least as we have framed it in the Rosen contribution to ECRIT, > >"location validation" refers to capabilities necessary to ensure that a > >civic location object is routable and also useful for dispatch of > >emergency responders. Since there are so many different representations > >of civic location information, human user confusion can contribute to > >incorrect, unroutable information being provided. The > >"location validation" function is intended to allow for > >corrections of errors and confusion BEFORE there is an > >emergency. (We have been informed that the term "location > >validation" may > >cause confusion because of other connotations in other > >contexts, but have tried to qualify and explain the use of the > >term to alleviate this.) I think that if non-routable civic > >addresses were commonplace, it wouldn't really matter what > >mechanism ecrit specified for routing them--garbage > >in-->garbage out. > > > >"Location validation" is not the same as authenticating that any given > >location object has been provided by a particular entity. > > > >Thanks, > >Nadine > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >Of James M. Polk > >Sent: Wednesday, March 23, 2005 2:49 PM > >To: Tschofenig Hannes; 'Henning Schulzrinne' > >Cc: Ciesla, Larry; ecrit@ietf.org > >Subject: Re: AW: AW: [Ecrit] requirements > > > > > >At 08:34 PM 3/23/2005 +0100, Tschofenig Hannes wrote: > > > >> > > >> > Allowed by whom? Do we assume that one has to have a license to > >> > provide such services? Who would hand out such licenses? > >(As far as > >> > I know, nobody has licensed Columbia University to provide > >> > telecommunication services and I guess we thus would not > >be able to > >> > legally provide campus-level location information.) > >> > >>that's exactly my point. > >>if we dig deeper into the authorization issues then we encounter > >>various problems. > > > >Isn't "location validation" another form of "authorized location > >information for usage"? > > > >Is this part of our message routing charter? > > > > > >>ciao > >>hannes > >> > >> > > >> > >>_______________________________________________ > >>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 > > > >_______________________________________________ > >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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 30 16:15:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19847; Wed, 30 Mar 2005 16:15:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGkeB-0005W6-7z; Wed, 30 Mar 2005 16:22:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGkDI-00058j-E5; Wed, 30 Mar 2005 15:54:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGkDH-00058a-Sw for ecrit@megatron.ietf.org; Wed, 30 Mar 2005 15:54:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12367 for ; Wed, 30 Mar 2005 15:54:54 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DGkKG-00036C-Hb for ecrit@ietf.org; Wed, 30 Mar 2005 16:02:09 -0500 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] requirements Date: Wed, 30 Mar 2005 22:57:26 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BD36@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] requirements Thread-Index: AcUxZ/+qrptJw0HYQxSRqMZJv4I/1wCbATAQAGK7f6UAAlADAAAAaaQZ From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Content-Transfer-Encoding: quoted-printable Mike, =20 you forgot the 7th red buoy ;-) =20 I talked to mountain rescue people and they told me that more 90% of their calls are coming via mobile phones, and locating the access road is not the problem (there is only one in most cases). =20 But in some cases they cannot rely on the data they get from the mobile operators (too large an area, only one cell) so the need not so readily availabe additional radio equipment to find the person. So they would love to have a GPS-location. =20 Validation can be done also by comparing the different=20 information sources (I understand that for routing to the PSAP the cell information is of course sufficient) =20 Richard ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Gesendet: Mi 30.03.2005 22:41 An: Stastny Richard; ecrit@ietf.org Betreff: RE: [Ecrit] requirements Richard, Ski-resort-X; Geronimo Black Diamond Run; 54th mogul from the top? :) Also, from a car: I-495 (outer-loop), Exit 12, mile marker 6? Excellent point. I assume geographic plus nearest road marker is needed by the PSAP. Mike >-----Original Message----- >From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >Sent: Wednesday, March 30, 2005 2:38 PM >To: Michael Hammer (mhammer); ecrit@ietf.org >Subject: Re: [Ecrit] requirements > >>As I understand it, location validation is not call-related, but is a >>process to ensure that each location to be used by the >location service >>are registered with the PSAP system and assigned a specific PSAP to >>route to, i.e. the MSAG is up to date. > >>A similar question relates to any database that maps from geographic >>coordinates to a civil space identified by a civil address. > >Maybe I am wrong, but during this discussion I got the >impression that location validation means the mapping to a >valid street address to determine the correct PSAP. > >But what about emergancy calls coming from "outdoors". Many >calls from mobile phones are coming people trecking or skiing, >and here you normally do not have a street address >(sos.mountain, sos.coast) > >How are these locations "validated"? > >Richard > > > >________________________________ > >Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) >Gesendet: Mo 28.03.2005 22:43 >An: Abbott, Nadine B.; ecrit@ietf.org >Betreff: RE: AW: AW: [Ecrit] requirements > > > >Nadine, > >As I understand it, location validation is not call-related, >but is a process to ensure that each location to be used by >the location service are registered with the PSAP system and >assigned a specific PSAP to route to, i.e. the MSAG is up to >date. My question is whether this maintenance of the MSAG >involves a protocol that ECRIT is to define? > >A similar question relates to any database that maps from >geographic coordinates to a civil space identified by a civil address. > >On a side note related to default to verbal confirmation of >location by the caller, I know of a case where the police >could not dispatch a car to a location even when the caller >could identify they were near a particular type of store (only >one within many miles) in a specific town because the PSAP >person was in a different geographic area. These PSAPs need >to be able to search (Google?) on landmarks to find street >addresses. Asking the caller about street names and building >numbers doesn't help when street signs and numbers are not >visible, but marketing signs are. > >Mike > > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >>Of Abbott, Nadine B. >>Sent: Friday, March 25, 2005 1:22 PM >>To: ecrit@ietf.org >>Subject: RE: AW: AW: [Ecrit] requirements >> >>Hannes, >> >>At least as we have framed it in the Rosen contribution to ECRIT, >>"location validation" refers to capabilities necessary to >ensure that a >>civic location object is routable and also useful for dispatch of >>emergency responders. >>Since there are so many different representations of civic location >>information, human user confusion can contribute to incorrect, >>unroutable information being provided. The "location validation" >>function is intended to allow for corrections of errors and confusion >>BEFORE there is an >>emergency. (We have been informed that the term "location >>validation" may >>cause confusion because of other connotations in other contexts, but >>have tried to qualify and explain the use of the term to alleviate >>this.) I think that if non-routable civic addresses were commonplace, >>it wouldn't really matter what mechanism ecrit specified for routing >>them--garbage >>in-->garbage out. >> >>"Location validation" is not the same as authenticating that >any given >>location object has been provided by a particular entity. >> >>Thanks, >>Nadine >> >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >>Of James M. Polk >>Sent: Wednesday, March 23, 2005 2:49 PM >>To: Tschofenig Hannes; 'Henning Schulzrinne' >>Cc: Ciesla, Larry; ecrit@ietf.org >>Subject: Re: AW: AW: [Ecrit] requirements >> >> >>At 08:34 PM 3/23/2005 +0100, Tschofenig Hannes wrote: >> >>> > >>> > Allowed by whom? Do we assume that one has to have a license to >>> > provide such services? Who would hand out such licenses? >>(As far as >>> > I know, nobody has licensed Columbia University to provide >>> > telecommunication services and I guess we thus would not >>be able to >>> > legally provide campus-level location information.) >>> >>>that's exactly my point. >>>if we dig deeper into the authorization issues then we encounter >>>various problems. >> >>Isn't "location validation" another form of "authorized location >>information for usage"? >> >>Is this part of our message routing charter? >> >> >>>ciao >>>hannes >>> >>> > >>> >>>_______________________________________________ >>>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 >> >>_______________________________________________ >>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 Mar 30 16:21:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22289; Wed, 30 Mar 2005 16:21:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGkjz-0006Im-7I; Wed, 30 Mar 2005 16:28:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGkOM-0002bj-R0; Wed, 30 Mar 2005 16:06:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGkOJ-0002Yj-BE for ecrit@megatron.ietf.org; Wed, 30 Mar 2005 16:06:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16364 for ; Wed, 30 Mar 2005 16:06:17 -0500 (EST) Message-Id: <200503302106.QAA16364@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGkVI-0004Lu-38 for ecrit@ietf.org; Wed, 30 Mar 2005 16:13:32 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DGkO8-0004j8-Ar; Wed, 30 Mar 2005 15:06:08 -0600 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Abbott, Nadine B.'" , "'Stastny Richard'" , Subject: RE: [Ecrit] requirements Date: Wed, 30 Mar 2005 16:05:54 -0500 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.2180 Thread-Index: AcU1aGBU2mb2d3bYRF6MUhMp5D/tNAAALgjgAACD9lA= In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E304DC29@xmb-rtp-20b.amer.cisco.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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f 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 X-Spam-Score: 0.8 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Content-Transfer-Encoding: 7bit Haha, not quite. There are areas of the world that do not have a PSAP. There are areas of the world that have conflicting coverage. An example of the latter is a disputed part of the world. Think about, for example, Jerusalem. If you ask Israel, they would say that their PSAP covers the city. If you ask Palestine, they would say that their PSAP covers the city. As a practical matter, the routing database will have two countries claiming the same service area. The system MUST deal with this, even if it is relatively uncommon. One suggestion I made some time ago was that the source of a geo location should also state what country it believed the location was in. This would work quite well in nearly every case; the customer of an Isreali wireless provider is likely to want the services of an Isreali PSAP, and a customer of a Palestinian service provider is likely to want a Palestinian PSAP. It works especially well when the on-the-ground reality is very clear, even when the nations dispute the reality. Of course, since wireless signals don't respect national boundaries, it won't always be accurate; a French wireless network provider very near the German border may be used while the subscriber is in fact in Germany. That is not a disputed territory, and this would not have overlapping service boundaries. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Michael Hammer (mhammer) > Sent: Wednesday, March 30, 2005 3:47 PM > To: Abbott, Nadine B.; Stastny Richard; ecrit@ietf.org > Subject: RE: [Ecrit] requirements > > Nadine, > > Validation simply means it is in the database. For geographic that > would mean that all points on the globe will result in a PSAP result, > no? Or in other words, all the PSAPs in the worlds have > mutully-exclusive global coverage assigned. > > Mike > > >-----Original Message----- > >From: Abbott, Nadine B. [mailto:nabbott@telcordia.com] > >Sent: Wednesday, March 30, 2005 3:37 PM > >To: 'Stastny Richard'; Michael Hammer (mhammer); ecrit@ietf.org > >Subject: RE: [Ecrit] requirements > > > >Richard, > >In the context in which it was proposed in the Rosen > >contribution from NENA, it applies only to civic location information. > >Geo-location doesn't have all the complexity. "Validating" it > >should be much simpler. > >Nadine > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of Stastny Richard > >Sent: Wednesday, March 30, 2005 2:38 PM > >To: Michael Hammer (mhammer); ecrit@ietf.org > >Subject: Re: [Ecrit] requirements > > > > > >>As I understand it, location validation is not call-related, but is a > >>process to ensure that each location to be used by the > >location service > >>are registered with the PSAP system and assigned a specific PSAP to > >>route to, i.e. the MSAG is up to date. > > > >>A similar question relates to any database that maps from geographic > >>coordinates to a civil space identified by a civil address. > > > >Maybe I am wrong, but during this discussion I got the > >impression that location validation means the mapping to a > >valid street address to determine the correct PSAP. > > > >But what about emergancy calls coming from "outdoors". Many > >calls from mobile phones are coming people trecking or skiing, > >and here you normally do not have a street address > >(sos.mountain, sos.coast) > > > >How are these locations "validated"? > > > >Richard > > > > > > > >________________________________ > > > >Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) > >Gesendet: Mo 28.03.2005 22:43 > >An: Abbott, Nadine B.; ecrit@ietf.org > >Betreff: RE: AW: AW: [Ecrit] requirements > > > > > > > >Nadine, > > > >As I understand it, location validation is not call-related, > >but is a process to ensure that each location to be used by > >the location service are registered with the PSAP system and > >assigned a specific PSAP to route to, i.e. the MSAG is up to > >date. My question is whether this maintenance of the MSAG > >involves a protocol that ECRIT is to define? > > > >A similar question relates to any database that maps from > >geographic coordinates to a civil space identified by a civil address. > > > >On a side note related to default to verbal confirmation of > >location by the caller, I know of a case where the police > >could not dispatch a car to a location even when the caller > >could identify they were near a particular type of store (only > >one within many miles) in a specific town because the PSAP > >person was in a different geographic area. These PSAPs need > >to be able to search (Google?) on landmarks to find street > >addresses. Asking the caller about street names and building > >numbers doesn't help when street signs and numbers are not > >visible, but marketing signs are. > > > >Mike > > > > > >>-----Original Message----- > >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf > >>Of Abbott, Nadine B. > >>Sent: Friday, March 25, 2005 1:22 PM > >>To: ecrit@ietf.org > >>Subject: RE: AW: AW: [Ecrit] requirements > >> > >>Hannes, > >> > >>At least as we have framed it in the Rosen contribution to ECRIT, > >>"location validation" refers to capabilities necessary to > >ensure that a > >>civic location object is routable and also useful for dispatch of > >>emergency responders. Since there are so many different > >representations > >>of civic location information, human user confusion can contribute to > >>incorrect, unroutable information being provided. The "location > >>validation" function is intended to allow for corrections of > >errors and > >>confusion BEFORE there is an > >>emergency. (We have been informed that the term "location > >>validation" may > >>cause confusion because of other connotations in other contexts, but > >>have tried to qualify and explain the use of the term to alleviate > >>this.) I think that if non-routable civic addresses were commonplace, > >>it wouldn't really matter what mechanism ecrit specified for routing > >>them--garbage > >>in-->garbage out. > >> > >>"Location validation" is not the same as authenticating that > >any given > >>location object has been provided by a particular entity. > >> > >>Thanks, > >>Nadine > >> > >>-----Original Message----- > >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf > >>Of James M. Polk > >>Sent: Wednesday, March 23, 2005 2:49 PM > >>To: Tschofenig Hannes; 'Henning Schulzrinne' > >>Cc: Ciesla, Larry; ecrit@ietf.org > >>Subject: Re: AW: AW: [Ecrit] requirements > >> > >> > >>At 08:34 PM 3/23/2005 +0100, Tschofenig Hannes wrote: > >> > >>> > > >>> > Allowed by whom? Do we assume that one has to have a license to > >>> > provide such services? Who would hand out such licenses? > >>(As far as > >>> > I know, nobody has licensed Columbia University to provide > >>> > telecommunication services and I guess we thus would not > >>be able to > >>> > legally provide campus-level location information.) > >>> > >>>that's exactly my point. > >>>if we dig deeper into the authorization issues then we encounter > >>>various problems. > >> > >>Isn't "location validation" another form of "authorized location > >>information for usage"? > >> > >>Is this part of our message routing charter? > >> > >> > >>>ciao > >>>hannes > >>> > >>> > > >>> > >>>_______________________________________________ > >>>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 > >> > >>_______________________________________________ > >>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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 30 16:26:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24230; Wed, 30 Mar 2005 16:26:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGkog-0006vB-77; Wed, 30 Mar 2005 16:33:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGkeQ-0003nw-SG; Wed, 30 Mar 2005 16:22:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGkeP-0003nX-9c for ecrit@megatron.ietf.org; Wed, 30 Mar 2005 16:22:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22997 for ; Wed, 30 Mar 2005 16:22:53 -0500 (EST) From: wilcox@e911.psd.state.vt.us Received: from static-64-222-94-65.burl.east.verizon.net ([64.222.94.65] helo=artemis.vt911.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGklM-0006U4-7u for ecrit@ietf.org; Wed, 30 Mar 2005 16:30:08 -0500 content-class: urn:content-classes:message Subject: RE: [Ecrit] requirements MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Wed, 30 Mar 2005 16:25:25 -0500 Message-ID: Thread-Topic: [Ecrit] requirements Thread-Index: AcUxZ/+qrptJw0HYQxSRqMZJv4I/1wCbATAQAGK7f6UAAlADAAAAaaQZAAELbwA= To: "Stastny Richard" , "Michael Hammer (mhammer)" , X-Spam-Score: 0.3 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 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 X-Spam-Score: 0.3 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Content-Transfer-Encoding: quoted-printable Well, for routing to the PSAP the cell information (site or sector) is not appropriate in a lot of cases. Many cell site straddle not only borders between states that obviously are served by two PSAP's but also boundaries between countries. We suffer both here in Vermont.=20 A good background read would be the FCC report and order 94-102 outlining the requirements for wireless carriers in providing location information for 9-1-1 services.=20 Nate Wilcox -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Wednesday, March 30, 2005 3:57 PM To: Michael Hammer (mhammer); ecrit@ietf.org Subject: Re: [Ecrit] requirements Mike, =20 you forgot the 7th red buoy ;-) =20 I talked to mountain rescue people and they told me that more 90% of their calls are coming via mobile phones, and locating the access road is not the problem (there is only one in most cases). =20 But in some cases they cannot rely on the data they get from the mobile operators (too large an area, only one cell) so the need not so readily availabe additional radio equipment to find the person. So they would love to have a GPS-location. =20 Validation can be done also by comparing the different=20 information sources (I understand that for routing to the PSAP the cell information is of course sufficient) =20 Richard ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Gesendet: Mi 30.03.2005 22:41 An: Stastny Richard; ecrit@ietf.org Betreff: RE: [Ecrit] requirements Richard, Ski-resort-X; Geronimo Black Diamond Run; 54th mogul from the top? :) Also, from a car: I-495 (outer-loop), Exit 12, mile marker 6? Excellent point. I assume geographic plus nearest road marker is needed by the PSAP. Mike >-----Original Message----- >From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >Sent: Wednesday, March 30, 2005 2:38 PM >To: Michael Hammer (mhammer); ecrit@ietf.org >Subject: Re: [Ecrit] requirements > >>As I understand it, location validation is not call-related, but is a >>process to ensure that each location to be used by the >location service >>are registered with the PSAP system and assigned a specific PSAP to >>route to, i.e. the MSAG is up to date. > >>A similar question relates to any database that maps from geographic >>coordinates to a civil space identified by a civil address. > >Maybe I am wrong, but during this discussion I got the >impression that location validation means the mapping to a >valid street address to determine the correct PSAP. > >But what about emergancy calls coming from "outdoors". Many >calls from mobile phones are coming people trecking or skiing, >and here you normally do not have a street address >(sos.mountain, sos.coast) > >How are these locations "validated"? > >Richard > > > >________________________________ > >Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) >Gesendet: Mo 28.03.2005 22:43 >An: Abbott, Nadine B.; ecrit@ietf.org >Betreff: RE: AW: AW: [Ecrit] requirements > > > >Nadine, > >As I understand it, location validation is not call-related, >but is a process to ensure that each location to be used by >the location service are registered with the PSAP system and >assigned a specific PSAP to route to, i.e. the MSAG is up to >date. My question is whether this maintenance of the MSAG >involves a protocol that ECRIT is to define? > >A similar question relates to any database that maps from >geographic coordinates to a civil space identified by a civil address. > >On a side note related to default to verbal confirmation of >location by the caller, I know of a case where the police >could not dispatch a car to a location even when the caller >could identify they were near a particular type of store (only >one within many miles) in a specific town because the PSAP >person was in a different geographic area. These PSAPs need >to be able to search (Google?) on landmarks to find street >addresses. Asking the caller about street names and building >numbers doesn't help when street signs and numbers are not >visible, but marketing signs are. > >Mike > > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >>Of Abbott, Nadine B. >>Sent: Friday, March 25, 2005 1:22 PM >>To: ecrit@ietf.org >>Subject: RE: AW: AW: [Ecrit] requirements >> >>Hannes, >> >>At least as we have framed it in the Rosen contribution to ECRIT, >>"location validation" refers to capabilities necessary to >ensure that a >>civic location object is routable and also useful for dispatch of >>emergency responders. >>Since there are so many different representations of civic location >>information, human user confusion can contribute to incorrect, >>unroutable information being provided. The "location validation" >>function is intended to allow for corrections of errors and confusion >>BEFORE there is an >>emergency. (We have been informed that the term "location >>validation" may >>cause confusion because of other connotations in other contexts, but >>have tried to qualify and explain the use of the term to alleviate >>this.) I think that if non-routable civic addresses were commonplace, >>it wouldn't really matter what mechanism ecrit specified for routing >>them--garbage >>in-->garbage out. >> >>"Location validation" is not the same as authenticating that >any given >>location object has been provided by a particular entity. >> >>Thanks, >>Nadine >> >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >>Of James M. Polk >>Sent: Wednesday, March 23, 2005 2:49 PM >>To: Tschofenig Hannes; 'Henning Schulzrinne' >>Cc: Ciesla, Larry; ecrit@ietf.org >>Subject: Re: AW: AW: [Ecrit] requirements >> >> >>At 08:34 PM 3/23/2005 +0100, Tschofenig Hannes wrote: >> >>> > >>> > Allowed by whom? Do we assume that one has to have a license to >>> > provide such services? Who would hand out such licenses? >>(As far as >>> > I know, nobody has licensed Columbia University to provide >>> > telecommunication services and I guess we thus would not >>be able to >>> > legally provide campus-level location information.) >>> >>>that's exactly my point. >>>if we dig deeper into the authorization issues then we encounter >>>various problems. >> >>Isn't "location validation" another form of "authorized location >>information for usage"? >> >>Is this part of our message routing charter? >> >> >>>ciao >>>hannes >>> >>> > >>> >>>_______________________________________________ >>>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 >> >>_______________________________________________ >>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 Mar 30 16:28:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24758; Wed, 30 Mar 2005 16:28:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGkqL-00074R-Qp; Wed, 30 Mar 2005 16:35:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGkZ9-0000U3-Oq; Wed, 30 Mar 2005 16:17:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGkZ8-0000TP-MT for ecrit@megatron.ietf.org; Wed, 30 Mar 2005 16:17:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20605 for ; Wed, 30 Mar 2005 16:17:24 -0500 (EST) Received: from mail.easycgi.com ([66.245.177.160] helo=easycgi.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGkg3-0005jp-JN for ecrit@ietf.org; Wed, 30 Mar 2005 16:24:39 -0500 Received: from [70.16.239.176] (account marks@maximtsc.com) by easycgi.com (CommuniGate Pro WebUser 4.2.3) with HTTP id 45708062 for ecrit@ietf.org; Wed, 30 Mar 2005 16:20:16 -0500 From: "Mark Scharaga" To: ecrit@ietf.org X-Mailer: CommuniGate Pro WebUser Interface v.4.2.3 Date: Wed, 30 Mar 2005 16:20:16 -0500 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 8bit Subject: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 25 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 8bit Richard, Wireless carriers are assigned P-ANIs (these are handed out by the LEC) for each tower sector. THat is used to determine the correct PSAP location for response. THe wireless carriers use one of two technologies- Time Distance of Arrival or GPS to provide a X/Y coordinate for the callers location. I am oversimplfying the way this occurs. A recurring issue with mobile callers is getting a valid location for them. THe accuracy is all over the place. Also, these users are typically driving and may roam into a PSAP's area of responsibility for a brief moment and calls are often misrouted. However, in most cases the ability to do a "Tandem Transfer" ensures the caller is not hung up and that their location record is availabe to proper PSAP. Mark Scharaga President- Maxim Technology Solutions www.maximtsc.com 888-288-3059 X101 As I understand it, location validation is not call-related, but is a process to ensure that each location to be used by the location service are registered with the PSAP system and assigned a specific PSAP to route to, i.e. the MSAG is up to date. A similar question relates to any database that maps from geographic coordinates to a civil space identified by a civil address. Maybe I am wrong, but during this discussion I got the impression that location validation means the mapping to a valid street address to determine the correct PSAP. But what about emergancy calls coming from "outdoors". Many calls from mobile phones are coming people trecking or skiing, and here you normally do not have a street address (sos.mountain, sos.coast) How are these locations "validated"? Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 30 16:30:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25407; Wed, 30 Mar 2005 16:30:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGksL-0007HQ-7q; Wed, 30 Mar 2005 16:37:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGk0Y-0000Ag-Fa; Wed, 30 Mar 2005 15:41:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGk0X-0000Ab-05 for ecrit@megatron.ietf.org; Wed, 30 Mar 2005 15:41:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08413 for ; Wed, 30 Mar 2005 15:41:43 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGk7V-0001gz-Q8 for ecrit@ietf.org; Wed, 30 Mar 2005 15:48:58 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 30 Mar 2005 15:41:36 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2UKfR1j024956; Wed, 30 Mar 2005 15:41:33 -0500 (EST) 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, 30 Mar 2005 15:41:27 -0500 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] requirements Date: Wed, 30 Mar 2005 15:41:26 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E304DC28@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] requirements Thread-Index: AcUxZ/+qrptJw0HYQxSRqMZJv4I/1wCbATAQAGK7f6UAAlADAA== From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , X-OriginalArrivalTime: 30 Mar 2005 20:41:27.0264 (UTC) FILETIME=[D85AFE00:01C53568] X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Content-Transfer-Encoding: quoted-printable Richard, Ski-resort-X; Geronimo Black Diamond Run; 54th mogul from the top? :) Also, from a car: I-495 (outer-loop), Exit 12, mile marker 6? Excellent point. I assume geographic plus nearest road marker is needed by the PSAP. Mike >-----Original Message----- >From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 >Sent: Wednesday, March 30, 2005 2:38 PM >To: Michael Hammer (mhammer); ecrit@ietf.org >Subject: Re: [Ecrit] requirements > >>As I understand it, location validation is not call-related, but is a=20 >>process to ensure that each location to be used by the=20 >location service=20 >>are registered with the PSAP system and assigned a specific PSAP to=20 >>route to, i.e. the MSAG is up to date. >=20 >>A similar question relates to any database that maps from geographic=20 >>coordinates to a civil space identified by a civil address. > >Maybe I am wrong, but during this discussion I got the=20 >impression that location validation means the mapping to a=20 >valid street address to determine the correct PSAP. > >But what about emergancy calls coming from "outdoors". Many=20 >calls from mobile phones are coming people trecking or skiing,=20 >and here you normally do not have a street address=20 >(sos.mountain, sos.coast) > >How are these locations "validated"? > >Richard > > > >________________________________ > >Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) >Gesendet: Mo 28.03.2005 22:43 >An: Abbott, Nadine B.; ecrit@ietf.org >Betreff: RE: AW: AW: [Ecrit] requirements > > > >Nadine, > >As I understand it, location validation is not call-related,=20 >but is a process to ensure that each location to be used by=20 >the location service are registered with the PSAP system and=20 >assigned a specific PSAP to route to, i.e. the MSAG is up to=20 >date. My question is whether this maintenance of the MSAG=20 >involves a protocol that ECRIT is to define? > >A similar question relates to any database that maps from=20 >geographic coordinates to a civil space identified by a civil address. > >On a side note related to default to verbal confirmation of=20 >location by the caller, I know of a case where the police=20 >could not dispatch a car to a location even when the caller=20 >could identify they were near a particular type of store (only=20 >one within many miles) in a specific town because the PSAP=20 >person was in a different geographic area. These PSAPs need=20 >to be able to search (Google?) on landmarks to find street=20 >addresses. Asking the caller about street names and building=20 >numbers doesn't help when street signs and numbers are not=20 >visible, but marketing signs are. > >Mike > > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >>Of Abbott, Nadine B. >>Sent: Friday, March 25, 2005 1:22 PM >>To: ecrit@ietf.org >>Subject: RE: AW: AW: [Ecrit] requirements >> >>Hannes, >> >>At least as we have framed it in the Rosen contribution to ECRIT,=20 >>"location validation" refers to capabilities necessary to=20 >ensure that a=20 >>civic location object is routable and also useful for dispatch of=20 >>emergency responders. >>Since there are so many different representations of civic location=20 >>information, human user confusion can contribute to incorrect,=20 >>unroutable information being provided. The "location validation"=20 >>function is intended to allow for corrections of errors and confusion=20 >>BEFORE there is an >>emergency. (We have been informed that the term "location >>validation" may >>cause confusion because of other connotations in other contexts, but=20 >>have tried to qualify and explain the use of the term to alleviate=20 >>this.) I think that if non-routable civic addresses were commonplace,=20 >>it wouldn't really matter what mechanism ecrit specified for routing=20 >>them--garbage >>in-->garbage out. >> >>"Location validation" is not the same as authenticating that=20 >any given=20 >>location object has been provided by a particular entity. >> >>Thanks, >>Nadine >> >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >>Of James M. Polk >>Sent: Wednesday, March 23, 2005 2:49 PM >>To: Tschofenig Hannes; 'Henning Schulzrinne' >>Cc: Ciesla, Larry; ecrit@ietf.org >>Subject: Re: AW: AW: [Ecrit] requirements >> >> >>At 08:34 PM 3/23/2005 +0100, Tschofenig Hannes wrote: >> >>> > >>> > Allowed by whom? Do we assume that one has to have a license to=20 >>> > provide such services? Who would hand out such licenses? >>(As far as >>> > I know, nobody has licensed Columbia University to provide=20 >>> > telecommunication services and I guess we thus would not >>be able to >>> > legally provide campus-level location information.) >>> >>>that's exactly my point. >>>if we dig deeper into the authorization issues then we encounter=20 >>>various problems. >> >>Isn't "location validation" another form of "authorized location=20 >>information for usage"? >> >>Is this part of our message routing charter? >> >> >>>ciao >>>hannes >>> >>> > >>> >>>_______________________________________________ >>>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 >> >>_______________________________________________ >>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 Mar 30 16:45:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29751; Wed, 30 Mar 2005 16:45:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGl7N-0000AT-1v; Wed, 30 Mar 2005 16:52:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGkyS-0001R0-3q; Wed, 30 Mar 2005 16:43:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGkyQ-0001Py-JH for ecrit@megatron.ietf.org; Wed, 30 Mar 2005 16:43:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29381 for ; Wed, 30 Mar 2005 16:43:36 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DGl5P-0008VD-0V for ecrit@ietf.org; Wed, 30 Mar 2005 16:50:51 -0500 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] requirements Date: Wed, 30 Mar 2005 23:46:10 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BD38@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] requirements Thread-Index: AcUxZ/+qrptJw0HYQxSRqMZJv4I/1wCbATAQAGK7f6UAAlADAAAAaaQZAAELbwAAALM51g== From: "Stastny Richard" To: , "Michael Hammer \(mhammer\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Content-Transfer-Encoding: quoted-printable Nate, =20 you are of course correct, finally additional (terminal based) location information is needed.=20 =20 The requirement (for routing) is that the best available location = information should also be used for routing, but this information may not always be available. = The terminal may not be equipped or capable, or the location information may not be = retrievable (no satellite in vision). =20 This means that PSAPs need also to have as a MUST a functionality to = recognize and deal with misrouted calls. =20 Richard ________________________________ Von: wilcox@e911.psd.state.vt.us [mailto:wilcox@e911.psd.state.vt.us] Gesendet: Mi 30.03.2005 23:25 An: Stastny Richard; Michael Hammer (mhammer); ecrit@ietf.org Betreff: RE: [Ecrit] requirements Well, for routing to the PSAP the cell information (site or sector) is not appropriate in a lot of cases. Many cell site straddle not only borders between states that obviously are served by two PSAP's but also boundaries between countries. We suffer both here in Vermont. A good background read would be the FCC report and order 94-102 outlining the requirements for wireless carriers in providing location information for 9-1-1 services. Nate Wilcox -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Wednesday, March 30, 2005 3:57 PM To: Michael Hammer (mhammer); ecrit@ietf.org Subject: Re: [Ecrit] requirements Mike, you forgot the 7th red buoy ;-) I talked to mountain rescue people and they told me that more 90% of their calls are coming via mobile phones, and locating the access road is not the problem (there is only one in most cases). But in some cases they cannot rely on the data they get from the mobile operators (too large an area, only one cell) so the need not so readily availabe additional radio equipment to find the person. So they would love to have a GPS-location. Validation can be done also by comparing the different information sources (I understand that for routing to the PSAP the cell information is of course sufficient) Richard ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Gesendet: Mi 30.03.2005 22:41 An: Stastny Richard; ecrit@ietf.org Betreff: RE: [Ecrit] requirements Richard, Ski-resort-X; Geronimo Black Diamond Run; 54th mogul from the top? :) Also, from a car: I-495 (outer-loop), Exit 12, mile marker 6? Excellent point. I assume geographic plus nearest road marker is needed by the PSAP. Mike >-----Original Message----- >From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >Sent: Wednesday, March 30, 2005 2:38 PM >To: Michael Hammer (mhammer); ecrit@ietf.org >Subject: Re: [Ecrit] requirements > >>As I understand it, location validation is not call-related, but is a >>process to ensure that each location to be used by the >location service >>are registered with the PSAP system and assigned a specific PSAP to >>route to, i.e. the MSAG is up to date. > >>A similar question relates to any database that maps from geographic >>coordinates to a civil space identified by a civil address. > >Maybe I am wrong, but during this discussion I got the >impression that location validation means the mapping to a >valid street address to determine the correct PSAP. > >But what about emergancy calls coming from "outdoors". Many >calls from mobile phones are coming people trecking or skiing, >and here you normally do not have a street address >(sos.mountain, sos.coast) > >How are these locations "validated"? > >Richard > > > >________________________________ > >Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) >Gesendet: Mo 28.03.2005 22:43 >An: Abbott, Nadine B.; ecrit@ietf.org >Betreff: RE: AW: AW: [Ecrit] requirements > > > >Nadine, > >As I understand it, location validation is not call-related, >but is a process to ensure that each location to be used by >the location service are registered with the PSAP system and >assigned a specific PSAP to route to, i.e. the MSAG is up to >date. My question is whether this maintenance of the MSAG >involves a protocol that ECRIT is to define? > >A similar question relates to any database that maps from >geographic coordinates to a civil space identified by a civil address. > >On a side note related to default to verbal confirmation of >location by the caller, I know of a case where the police >could not dispatch a car to a location even when the caller >could identify they were near a particular type of store (only >one within many miles) in a specific town because the PSAP >person was in a different geographic area. These PSAPs need >to be able to search (Google?) on landmarks to find street >addresses. Asking the caller about street names and building >numbers doesn't help when street signs and numbers are not >visible, but marketing signs are. > >Mike > > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >>Of Abbott, Nadine B. >>Sent: Friday, March 25, 2005 1:22 PM >>To: ecrit@ietf.org >>Subject: RE: AW: AW: [Ecrit] requirements >> >>Hannes, >> >>At least as we have framed it in the Rosen contribution to ECRIT, >>"location validation" refers to capabilities necessary to >ensure that a >>civic location object is routable and also useful for dispatch of >>emergency responders. >>Since there are so many different representations of civic location >>information, human user confusion can contribute to incorrect, >>unroutable information being provided. The "location validation" >>function is intended to allow for corrections of errors and confusion >>BEFORE there is an >>emergency. (We have been informed that the term "location >>validation" may >>cause confusion because of other connotations in other contexts, but >>have tried to qualify and explain the use of the term to alleviate >>this.) I think that if non-routable civic addresses were commonplace, >>it wouldn't really matter what mechanism ecrit specified for routing >>them--garbage >>in-->garbage out. >> >>"Location validation" is not the same as authenticating that >any given >>location object has been provided by a particular entity. >> >>Thanks, >>Nadine >> >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >>Of James M. Polk >>Sent: Wednesday, March 23, 2005 2:49 PM >>To: Tschofenig Hannes; 'Henning Schulzrinne' >>Cc: Ciesla, Larry; ecrit@ietf.org >>Subject: Re: AW: AW: [Ecrit] requirements >> >> >>At 08:34 PM 3/23/2005 +0100, Tschofenig Hannes wrote: >> >>> > >>> > Allowed by whom? Do we assume that one has to have a license to >>> > provide such services? Who would hand out such licenses? >>(As far as >>> > I know, nobody has licensed Columbia University to provide >>> > telecommunication services and I guess we thus would not >>be able to >>> > legally provide campus-level location information.) >>> >>>that's exactly my point. >>>if we dig deeper into the authorization issues then we encounter >>>various problems. >> >>Isn't "location validation" another form of "authorized location >>information for usage"? >> >>Is this part of our message routing charter? >> >> >>>ciao >>>hannes >>> >>> > >>> >>>_______________________________________________ >>>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 >> >>_______________________________________________ >>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 Mar 30 17:52:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05053; Wed, 30 Mar 2005 17:52:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGmAS-0001XX-FF; Wed, 30 Mar 2005 18:00:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGm2r-00029h-5G; Wed, 30 Mar 2005 17:52:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGm2p-00028f-MQ for ecrit@megatron.ietf.org; Wed, 30 Mar 2005 17:52:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04981 for ; Wed, 30 Mar 2005 17:52:13 -0500 (EST) Received: from mail.easycgi.com ([66.245.177.160] helo=easycgi.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGm9o-0001WB-Nv for ecrit@ietf.org; Wed, 30 Mar 2005 17:59:29 -0500 Received: from [70.16.239.176] (account marks@maximtsc.com) by easycgi.com (CommuniGate Pro WebUser 4.2.3) with HTTP id 45724819 for ecrit@ietf.org; Wed, 30 Mar 2005 17:55:07 -0500 From: "Mark Scharaga" To: ecrit@ietf.org X-Mailer: CommuniGate Pro WebUser Interface v.4.2.3 Date: Wed, 30 Mar 2005 17:55:07 -0500 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 8bit Subject: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 26 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 8bit Folks, A large number of PSAPs use mapping and CAD systems to display closest route and streets to a location. THe dispatcher has to make the determination if that information is correct, as there are times (more often in rural areas) where the actual caller maybe on a lake or river and the closest road could be miles away. THe coordinates of the caller are actually more important than the physical street address. However, in the traditional landline call scenario the PSAP uses the street address and whatever info they can get from the caller to make the proper unit responses occur. With mobile callers most mapping systems display the actual location of the caller, not resolved to the closest location. There are some systems that do try to resolve the coordinates to an actual street address. During my career I strongly advised against any system that did this due to probability of error. Mark _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 30 18:46:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11194; Wed, 30 Mar 2005 18:46:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGn0N-0002pN-UX; Wed, 30 Mar 2005 18:53:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGmsK-0008Bh-To; Wed, 30 Mar 2005 18:45:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGmsJ-0008BX-Fp for ecrit@megatron.ietf.org; Wed, 30 Mar 2005 18:45:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11135 for ; Wed, 30 Mar 2005 18:45:24 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGmzI-0002o8-LR for ecrit@ietf.org; Wed, 30 Mar 2005 18:52:42 -0500 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 j2UNjC727402 for ; Wed, 30 Mar 2005 17:45:13 -0600 (CST) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Mar 2005 09:44:23 +1000 Message-ID: From: "James Winterbottom" To: ecrit@ietf.org Date: Thu, 31 Mar 2005 09:44:20 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Subject: [Ecrit] Geodetic interpretations 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="===============0373645314==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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. --===============0373645314== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53582.653267F0" 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_01C53582.653267F0 Content-Type: text/plain Hi All, I am going to change the subject a bit here from what has been going around the list to date about "validated locations". I want to ask some opinions about geodetic information, and how we should seek to interpret this. For IETF-62 I presented a paper in the GeoPriv working group that was authored by me, Hannes Tschofenig and Martin Thomson on, amongst other things, what might be a required minimal set of GML to implement to support routing applications. (http://www.ietf.org/internet-drafts/draft-winterbottom-geopriv-pdif-lo-prof ile-00.txt) In the presentation I indicated that we were going to look at uncertainty in more detail in the next edition, and confidence. The difference being that an uncertainty is usually defined as being with X metres of a provided Latitude/Longitude, and a confidence factor is a percentage chance that you will reside in that area. PIDF-LO does not support the notion of a confidence factor today, but this is something that we plan to look at in the next iteration of the above draft in the form of suggestions. The wireless standards, at least those used in North America, generally provide both. And the FCC for regulations are really only interested in 2 confidence factors, the 67% and the 90%. This tends to lead to the location representations as being closed shapes, circles, polygons, arcbands etc, rather than single points. While a circle with uncertainty can be expressed a s point with radius, neither a polygon or an arcband can. So where is this leading? 1) Do we care about confidence in location for routing? 2) If so, what is our minimal confidence level? 3) Do we have preferences in how location is to specified (see draft above)? While these points may be lower level requirements, they are things that we must start considering if we want an implementable solution. Cheers James ------_=_NextPart_001_01C53582.653267F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Geodetic interpretations

Hi All,

I am going to change the subject a bit here from what = has been going around the list to date about "validated = locations".

I want to ask some opinions about geodetic = information, and how we should seek to interpret this. For IETF-62 I = presented a paper in the GeoPriv working group that was authored by me, = Hannes Tschofenig and Martin Thomson on, amongst other things, what = might be a required minimal set of GML to implement to support routing = applications. (http://www.ietf.org/internet-drafts/draft-winterbottom= -geopriv-pdif-lo-profile-00.txt)

In the presentation I indicated that we were going to = look at uncertainty in more detail in the next edition, and confidence. = The difference being that an uncertainty is usually defined as being = with X metres of a provided Latitude/Longitude, and a confidence factor = is a percentage chance that you will reside in that area. PIDF-LO does = not support the notion of a confidence factor today, but this is = something that we plan to look at in the next iteration of the above = draft in the form of suggestions.

The wireless standards, at least those used in North = America, generally provide both. And the FCC for regulations are really = only interested in 2 confidence factors, the 67% and the 90%. This = tends to lead to the location representations as being closed shapes, = circles, polygons, arcbands etc, rather than single points. While a = circle with uncertainty can be expressed a s point with radius, neither = a polygon or an arcband can.

So where is this leading?
1) Do we care about confidence in location for = routing?
2) If so, what is our minimal confidence = level?
3) Do we have preferences in how location is to = specified (see draft above)?

While these points may be lower level requirements, = they are things that we must start considering if we want an = implementable solution.

Cheers
James

------_=_NextPart_001_01C53582.653267F0-- --===============0373645314== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0373645314==-- From ecrit-bounces@ietf.org Wed Mar 30 20:47:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22009; Wed, 30 Mar 2005 20:47:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGotF-0005D2-5B; Wed, 30 Mar 2005 20:54:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGolM-0008LK-SW; Wed, 30 Mar 2005 20:46:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGolK-0008LF-Mj for ecrit@megatron.ietf.org; Wed, 30 Mar 2005 20:46:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21948 for ; Wed, 30 Mar 2005 20:46:21 -0500 (EST) Message-Id: <200503310146.UAA21948@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGosM-0005Bc-2w for ecrit@ietf.org; Wed, 30 Mar 2005 20:53:38 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DGol5-0003xJ-PK; Wed, 30 Mar 2005 19:46:07 -0600 From: "Brian Rosen" To: "'Mark Scharaga'" , Subject: RE: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 26 Date: Wed, 30 Mar 2005 20:45:53 -0500 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.2180 Thread-Index: AcU1ezSeLkcB3aC+SLWIhEKO0/uXIwAFrhaQ 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 X-Spam-Score: 0.8 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Chairs may decide this thread is no longer in scope. Mark Please tell me how you expect a fire truck to be dispatched to a lat/lon. It's possible to tell them to go to 1/2 mile north of some cross street on some other street, but you don't give them a lat/lon. When a call taker answers a call, one of the first things they ask you, besides what is wrong, is where you are. You don't read off your GPS coordinates. They don't insist on a street number, but they are looking at a map that has street numbers marked on it, and they often have software that is showing the "closest" address to the reported lat/lon. They have to enter a street address into their systems in one way or another. The coordinates are not "more important". They are probably more accurate than any conversion from lat/lon to civic, because you can't add accuracy with a conversion, you can only decrease accuracy. This is why I don't like conversion. Sometimes, as with dispatch, you need to convert. The rule I like is "send whatever the original data was determined". If the data was originally measured, as with GPS, then send geo. If the data was originally entered as a street address, send a civic. If you have some converted data also, send that, but mark it as converted from the other form and send the original first. NEVER convert, and send only the converted data. Don't assume you know what the other end needs. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Mark Scharaga > Sent: Wednesday, March 30, 2005 5:55 PM > To: ecrit@ietf.org > Subject: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 26 > > Folks, > > A large number of PSAPs use mapping and CAD systems to > display closest route and streets to a location. THe > dispatcher has to make the determination if that > information is correct, as there are times (more often in > rural areas) where the actual caller maybe on a lake or > river and the closest road could be miles away. > > THe coordinates of the caller are actually more important > than the physical street address. However, in the > traditional landline call scenario the PSAP uses the > street address and whatever info they can get from the > caller to make the proper unit responses occur. With > mobile callers most mapping systems display the actual > location of the caller, not resolved to the closest > location. There are some systems that do try to resolve > the coordinates to an actual street address. During my > career I strongly advised against any system that did this > due to probability of error. > > Mark > > > _______________________________________________ > 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 Mar 30 20:49:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22160; Wed, 30 Mar 2005 20:49:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGov9-0005FO-A2; Wed, 30 Mar 2005 20:56:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGonO-0000CU-8X; Wed, 30 Mar 2005 20:48:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGonM-0000CB-S1 for ecrit@megatron.ietf.org; Wed, 30 Mar 2005 20:48:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22096 for ; Wed, 30 Mar 2005 20:48:27 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGouO-0005EW-Dp for ecrit@ietf.org; Wed, 30 Mar 2005 20:55:44 -0500 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j2V1mEh3005650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Mar 2005 20:48:25 -0500 (EST) Message-ID: <424B56D9.8090408@cs.columbia.edu> Date: Wed, 30 Mar 2005 20:48:09 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Winterbottom Subject: Re: [Ecrit] Geodetic interpretations 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_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit I'm not sure what you would do differently for routing if you knew the confidence interval (which this is, roughly). You'd presumably always route on the center of circle or other geometric shape. Clearly, the dispatcher might find this useful to guess whether to send one squad car or a search party. I'll repeat my rant from earlier: elaborate confidence measures are, in my view, largely bogus for dispatch and routing. (They are useful to characterize the performance of a technology.) They are usually based on not much more than "measured across thousands of points across the country, 90% of measurements fell within 100 m of true location", which says very little about the GPS satellite shading or the number and relative location of cell towers (for TOA-style measurements), say, at the corner of Main and 5th in Podunk, NY. Thus, if you were to repeatedly measure location at that point, you might only be off by 10 m, or maybe it's a bad spot and it's always off by 200 m. This would be useful if you could bound the technology resolution in all cases, i.e., that it is extremely unlikely to be wrong by more than X meters. Thus, worrying too much about accuracy is like providing pound-to-kilogram conversions on noodle packages to 7 digits. James Winterbottom wrote: > Hi All, > > I am going to change the subject a bit here from what has been going > around the list to date about "validated locations". > > I want to ask some opinions about geodetic information, and how we > should seek to interpret this. For IETF-62 I presented a paper in the > GeoPriv working group that was authored by me, Hannes Tschofenig and > Martin Thomson on, amongst other things, what might be a required > minimal set of GML to implement to support routing applications. > (http://www.ietf.org/internet-drafts/draft-winterbottom-geopriv-pdif-lo-profile-00.txt) > > In the presentation I indicated that we were going to look at > uncertainty in more detail in the next edition, and confidence. The > difference being that an uncertainty is usually defined as being with X > metres of a provided Latitude/Longitude, and a confidence factor is a > percentage chance that you will reside in that area. PIDF-LO does not > support the notion of a confidence factor today, but this is something > that we plan to look at in the next iteration of the above draft in the > form of suggestions. > > The wireless standards, at least those used in North America, generally > provide both. And the FCC for regulations are really only interested in > 2 confidence factors, the 67% and the 90%. This tends to lead to the > location representations as being closed shapes, circles, polygons, > arcbands etc, rather than single points. While a circle with uncertainty > can be expressed a s point with radius, neither a polygon or an arcband > can. > > So where is this leading? > 1) Do we care about confidence in location for routing? > 2) If so, what is our minimal confidence level? > 3) Do we have preferences in how location is to specified (see draft > above)? > > While these points may be lower level requirements, they are things that > we must start considering if we want an implementable solution. > > Cheers > James > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Mar 30 21:12:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24348; Wed, 30 Mar 2005 21:12:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGpI8-0005ki-8R; Wed, 30 Mar 2005 21:20:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGp8c-0004uR-Mv; Wed, 30 Mar 2005 21:10:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGp8b-0004uM-HA for ecrit@megatron.ietf.org; Wed, 30 Mar 2005 21:10:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23993 for ; Wed, 30 Mar 2005 21:10:23 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGpFc-0005gC-Qy for ecrit@ietf.org; Wed, 30 Mar 2005 21:17:41 -0500 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 j2V2A1s16377; Wed, 30 Mar 2005 20:10:01 -0600 (CST) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Mar 2005 12:09:11 +1000 Message-ID: From: "James Winterbottom" To: Henning Schulzrinne Subject: RE: [Ecrit] Geodetic interpretations Date: Thu, 31 Mar 2005 12:09:11 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 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="===============0329026349==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 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. --===============0329026349== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53596.A0F166CE" 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_01C53596.A0F166CE Content-Type: text/plain I am not sure that I agree with you entirely here as I stated, for polygons and arcbands (both of which are used today for cellular), they either do not specify a centre point, or the point that is specified is not in the closed shape (arcband), so what would you do in these cases? You probably need to do some sort of polygon inclusion or intersection mapping anyway. I also don't think that you are right about this not having an impact on routing. If a point resides in one boundary, but 90% of the closed uncertainty shape resides in a different boundary, a point only routing solution will misroute the call. This is analogous to simply using cell-sector for cellular routing which, according to some sources, results in about 30% of calls being misrouted. I am not saying that we would not route on point only, but we could specify preferences and indicate why these have been chosen. I think that restricting ourselves to a single point solution only does not lend itself so well to network determined location techniques (particularly for wireless) as the points represent boundaries or references rather than client/device specific location. -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, 31 March 2005 11:48 AM To: Winterbottom, James [WOLL:5500:EXCH] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Geodetic interpretations I'm not sure what you would do differently for routing if you knew the confidence interval (which this is, roughly). You'd presumably always route on the center of circle or other geometric shape. Clearly, the dispatcher might find this useful to guess whether to send one squad car or a search party. I'll repeat my rant from earlier: elaborate confidence measures are, in my view, largely bogus for dispatch and routing. (They are useful to characterize the performance of a technology.) They are usually based on not much more than "measured across thousands of points across the country, 90% of measurements fell within 100 m of true location", which says very little about the GPS satellite shading or the number and relative location of cell towers (for TOA-style measurements), say, at the corner of Main and 5th in Podunk, NY. Thus, if you were to repeatedly measure location at that point, you might only be off by 10 m, or maybe it's a bad spot and it's always off by 200 m. This would be useful if you could bound the technology resolution in all cases, i.e., that it is extremely unlikely to be wrong by more than X meters. Thus, worrying too much about accuracy is like providing pound-to-kilogram conversions on noodle packages to 7 digits. James Winterbottom wrote: > Hi All, > > I am going to change the subject a bit here from what has been going > around the list to date about "validated locations". > > I want to ask some opinions about geodetic information, and how we > should seek to interpret this. For IETF-62 I presented a paper in the > GeoPriv working group that was authored by me, Hannes Tschofenig and > Martin Thomson on, amongst other things, what might be a required > minimal set of GML to implement to support routing applications. > (http://www.ietf.org/internet-drafts/draft-winterbottom-geopriv-pdif-lo-prof ile-00.txt) > > In the presentation I indicated that we were going to look at > uncertainty in more detail in the next edition, and confidence. The > difference being that an uncertainty is usually defined as being with X > metres of a provided Latitude/Longitude, and a confidence factor is a > percentage chance that you will reside in that area. PIDF-LO does not > support the notion of a confidence factor today, but this is something > that we plan to look at in the next iteration of the above draft in the > form of suggestions. > > The wireless standards, at least those used in North America, > generally > provide both. And the FCC for regulations are really only interested in > 2 confidence factors, the 67% and the 90%. This tends to lead to the > location representations as being closed shapes, circles, polygons, > arcbands etc, rather than single points. While a circle with uncertainty > can be expressed a s point with radius, neither a polygon or an arcband > can. > > So where is this leading? > 1) Do we care about confidence in location for routing? > 2) If so, what is our minimal confidence level? > 3) Do we have preferences in how location is to specified (see draft > above)? > > While these points may be lower level requirements, they are things > that > we must start considering if we want an implementable solution. > > Cheers > James > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C53596.A0F166CE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Ecrit] Geodetic interpretations

I am not sure that I agree with you entirely here as = I stated, for polygons and arcbands (both of which are used today for = cellular), they either do not specify a centre point, or the point that = is specified is not in the closed shape (arcband), so what would you do = in these cases? You probably need to do some sort of polygon inclusion = or intersection mapping anyway.

I also don't think that you are right about this not = having an impact on routing. If a point resides in one boundary, but = 90% of the closed uncertainty shape resides in a different boundary, a = point only routing solution will misroute the call. This is analogous = to simply using cell-sector for cellular routing which, according to = some sources, results in about 30% of calls being misrouted.

I am not saying that we would not route on point = only, but we could specify preferences and indicate why these have been = chosen. I think that restricting ourselves to a single point solution = only does not lend itself so well to network determined location = techniques (particularly for wireless) as the points represent = boundaries or references rather than client/device specific = location.

 



-----Original Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] =
Sent: Thursday, 31 March 2005 11:48 AM
To: Winterbottom, James [WOLL:5500:EXCH]
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] Geodetic interpretations


I'm not sure what you would do differently for = routing if you knew the
confidence interval (which this is, roughly). You'd = presumably always
route on the center of circle or other geometric = shape. Clearly, the
dispatcher might find this useful to guess whether = to send one squad car
or a search party.

I'll repeat my rant from earlier: elaborate = confidence measures are, in
my view, largely bogus for dispatch and routing. = (They are useful to
characterize the performance of a technology.) They = are usually based on
not much more than "measured across thousands = of points across the
country, 90% of measurements fell within 100 m of = true location", which
says very little about the GPS satellite shading or = the number and
relative location of cell towers (for TOA-style = measurements), say, at
the corner of Main and 5th in Podunk, NY. Thus, if = you were to
repeatedly measure location at that point, you might = only be off by 10
m, or maybe it's a bad spot and it's always off by = 200 m.

This would be useful if you could bound the = technology resolution in all
cases, i.e., that it is extremely unlikely to be = wrong by more than X
meters.

Thus, worrying too much about accuracy is like = providing
pound-to-kilogram conversions on noodle packages to = 7 digits.

James Winterbottom wrote:
> Hi All,
>
> I am going to change the subject a bit here = from what has been going
> around the list to date about "validated = locations".
>
> I want to ask some opinions about geodetic = information, and how we
> should seek to interpret this. For IETF-62 I = presented a paper in the
> GeoPriv working group that was authored by me, = Hannes Tschofenig and
> Martin Thomson on, amongst other things, what = might be a required
> minimal set of GML to implement to support = routing applications.
> (http://www.ietf.org/internet-drafts/draft-winterbottom= -geopriv-pdif-lo-profile-00.txt)
>
> In the presentation I indicated that we were = going to look at
> uncertainty in more detail in the next edition, = and confidence. The
> difference being that an uncertainty is usually = defined as being with X
> metres of a provided Latitude/Longitude, and a = confidence factor is a
> percentage chance that you will reside in that = area. PIDF-LO does not
> support the notion of a confidence factor = today, but this is something
> that we plan to look at in the next iteration = of the above draft in the
> form of suggestions.
>
> The wireless standards, at least those used in = North America,
> generally
> provide both. And the FCC for regulations are = really only interested in
> 2 confidence factors, the 67% and the 90%. This = tends to lead to the
> location representations as being closed = shapes, circles, polygons,
> arcbands etc, rather than single points. While = a circle with uncertainty
> can be expressed a s point with radius, neither = a polygon or an arcband
> can.
>
> So where is this leading?
> 1) Do we care about confidence in location for = routing?
> 2) If so, what is our minimal confidence = level?
> 3) Do we have preferences in how location is to = specified (see draft
> above)?
>
> While these points may be lower level = requirements, they are things
> that
> we must start considering if we want an = implementable solution.
>
> Cheers
> James
>
>
> = ----------------------------------------------------------------------
> --
>
> = _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit

------_=_NextPart_001_01C53596.A0F166CE-- --===============0329026349== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0329026349==-- From ecrit-bounces@ietf.org Wed Mar 30 21:40:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26495; Wed, 30 Mar 2005 21:40:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGpiV-0006Ei-Lu; Wed, 30 Mar 2005 21:47:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGpao-0002JC-9S; Wed, 30 Mar 2005 21:39:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGpam-0002J7-UI for ecrit@megatron.ietf.org; Wed, 30 Mar 2005 21:39:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26370 for ; Wed, 30 Mar 2005 21:39:31 -0500 (EST) Received: from mail.easycgi.com ([66.245.177.160] helo=easycgi.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGphp-0006DE-5S for ecrit@ietf.org; Wed, 30 Mar 2005 21:46:49 -0500 Received: from [70.16.239.176] (account marks@maximtsc.com) by easycgi.com (CommuniGate Pro WebUser 4.2.3) with HTTP id 45752576 for ecrit@ietf.org; Wed, 30 Mar 2005 21:42:14 -0500 From: "Mark Scharaga" To: ecrit@ietf.org X-Mailer: CommuniGate Pro WebUser Interface v.4.2.3 Date: Wed, 30 Mar 2005 21:42:14 -0500 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 8bit Subject: [Ecrit] LAT/LON and dispatching 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 8bit Brian, I do not expect a fire truck to be dispatched to a LAT/LON as you should know the dispatcher has already resolved it to a specific location and/or transmitted to the unit's mobile computer. The responders are given a location and directions for arriving. Sometimes these are items faxed along with a map and notes to the fire station and in some cases to a mobile data unit. Really depends on the amount of funding and commitment to technology by the agency. I was heavily involved in the deployment of wireless phase I and II in Virginia and in several other areas in the US. I'm telling you for a fact that the trend is for the dispatchers to have tools to locate a caller no matter what data they are given. I'll concede that not all PSAPs are equipped that way YET but with wireless Phase II mapping is a KEY component. Infact the state of VA fully funded mapping systems. So they are able to locate the caller by coordinates if that information is provided. I think you're missing the point I'm trying to present. I know 911 in the traditional form have been VERY active with wireless phase I and II deployments. I'm presenting information from that view and addressing some specific concerns I saw in some other posts in this forum. Mark _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 30 22:02:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28338; Wed, 30 Mar 2005 22:02:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGq3z-0006ln-UF; Wed, 30 Mar 2005 22:09:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGpvb-0006xW-SB; Wed, 30 Mar 2005 22:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGpva-0006xJ-35 for ecrit@megatron.ietf.org; Wed, 30 Mar 2005 22:01:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28295 for ; Wed, 30 Mar 2005 22:01:00 -0500 (EST) Message-Id: <200503310301.WAA28295@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGq2c-0006kZ-Aq for ecrit@ietf.org; Wed, 30 Mar 2005 22:08:18 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DGpvP-0006i5-7L; Wed, 30 Mar 2005 21:00:51 -0600 From: "Brian Rosen" To: "'Mark Scharaga'" , Subject: RE: [Ecrit] LAT/LON and dispatching Date: Wed, 30 Mar 2005 22:00:36 -0500 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.2180 Thread-Index: AcU1mvpFbQ9QKMIQRZuIUe2oiU8XDQAAglTw 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 X-Spam-Score: 0.8 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit But what is the point? The requirements NENA presented to ecrit say that you must route on EITHER a geo or a civic and you cannot REQUIRE a conversion. It says you can use conversions if the data is acceptably accurate (to the PSAP). It says you can send geo or civic or both, but there has to be a way to know which the routing element should use (which I argue is ALWAYS the original, not the converted data). Do you agree with those requirements? There is no doubt that the technical direction for PSAPs is to make more use of GIS systems. What does that mean to presenting location or to routing calls to the PSAP? Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Mark Scharaga > Sent: Wednesday, March 30, 2005 9:42 PM > To: ecrit@ietf.org > Subject: [Ecrit] LAT/LON and dispatching > > Brian, > > I do not expect a fire truck to be dispatched to a LAT/LON > as you should know the dispatcher has already resolved it > to a specific location and/or transmitted to the unit's > mobile computer. The responders are given a location and > directions for arriving. Sometimes these are items faxed > along with a map and notes to the fire station and in some > cases to a mobile data unit. Really depends on the amount > of funding and commitment to technology by the agency. > > I was heavily involved in the deployment of wireless phase > I and II in Virginia and in several other areas in the US. > I'm telling you for a fact that the trend is for the > dispatchers to have tools to locate a caller no matter > what data they are given. > > I'll concede that not all PSAPs are equipped that way YET > but with wireless Phase II mapping is a KEY component. > Infact the state of VA fully funded mapping systems. So > they are able to locate the caller by coordinates if that > information is provided. > > I think you're missing the point I'm trying to present. I > know 911 in the traditional form have been VERY active > with wireless phase I and II deployments. I'm presenting > information from that view and addressing some specific > concerns I saw in some other posts in this forum. > > Mark > > _______________________________________________ > 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 Thu Mar 31 09:52:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28203; Thu, 31 Mar 2005 09:52:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH18y-00017R-3Y; Thu, 31 Mar 2005 09:59:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH0zi-0000XD-8U; Thu, 31 Mar 2005 09:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH0zf-0000WL-LX for ecrit@megatron.ietf.org; Thu, 31 Mar 2005 09:50:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28052 for ; Thu, 31 Mar 2005 09:49:57 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH16m-0000yQ-R6 for ecrit@ietf.org; Thu, 31 Mar 2005 09:57:21 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-4.cisco.com with ESMTP; 31 Mar 2005 06:49:48 -0800 Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2VEnkZV028307; Thu, 31 Mar 2005 06:49:46 -0800 (PST) Received: from MLINSNER (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA12131; Thu, 31 Mar 2005 06:49:44 -0800 (PST) Message-Id: <200503311449.GAA12131@malone.cisco.com> From: "Marc Linsner" To: "'James Winterbottom'" Subject: RE: [Ecrit] Geodetic interpretations Date: Thu, 31 Mar 2005 09:49:39 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Thread-Index: AcU1lxbfNXmILot2RSiJq01gWJD9MwAZzAfQ X-Spam-Score: 1.7 (+) X-Scan-Signature: fc231bf912a450f71747fa7a4e3e2f5a 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="===============1258855762==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org X-Spam-Score: 1.7 (+) X-Scan-Signature: 0c3d807a9e67fb2ae2b97f891ffd2e4e This is a multi-part message in MIME format. --===============1258855762== Content-Type: multipart/alternative; boundary="----=_NextPart_000_090D_01C535D6.F56BE6D0" This is a multi-part message in MIME format. ------=_NextPart_000_090D_01C535D6.F56BE6D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Question: If the technology that determines location can't figure out where you're at, how can the protocol that carries the data and/or the using application figure it out? Location determination is a hard problem, but I don't believe it's an IETF problem, and certainly not an ecrit problem. I believe, but I may be convinced otherwise, that ecrit will require a location point to use for routing. This would require the location determination mechanism to make its best guess at determining that point. And, if it's routed wrong, that is what selective transfer is all about, which is what happens with the 30% miss-routes today. -Marc- _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James Winterbottom Sent: Wednesday, March 30, 2005 9:09 PM To: Henning Schulzrinne Cc: ecrit@ietf.org Subject: RE: [Ecrit] Geodetic interpretations I am not sure that I agree with you entirely here as I stated, for polygons and arcbands (both of which are used today for cellular), they either do not specify a centre point, or the point that is specified is not in the closed shape (arcband), so what would you do in these cases? You probably need to do some sort of polygon inclusion or intersection mapping anyway. I also don't think that you are right about this not having an impact on routing. If a point resides in one boundary, but 90% of the closed uncertainty shape resides in a different boundary, a point only routing solution will misroute the call. This is analogous to simply using cell-sector for cellular routing which, according to some sources, results in about 30% of calls being misrouted. I am not saying that we would not route on point only, but we could specify preferences and indicate why these have been chosen. I think that restricting ourselves to a single point solution only does not lend itself so well to network determined location techniques (particularly for wireless) as the points represent boundaries or references rather than client/device specific location. -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, 31 March 2005 11:48 AM To: Winterbottom, James [WOLL:5500:EXCH] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Geodetic interpretations I'm not sure what you would do differently for routing if you knew the confidence interval (which this is, roughly). You'd presumably always route on the center of circle or other geometric shape. Clearly, the dispatcher might find this useful to guess whether to send one squad car or a search party. I'll repeat my rant from earlier: elaborate confidence measures are, in my view, largely bogus for dispatch and routing. (They are useful to characterize the performance of a technology.) They are usually based on not much more than "measured across thousands of points across the country, 90% of measurements fell within 100 m of true location", which says very little about the GPS satellite shading or the number and relative location of cell towers (for TOA-style measurements), say, at the corner of Main and 5th in Podunk, NY. Thus, if you were to repeatedly measure location at that point, you might only be off by 10 m, or maybe it's a bad spot and it's always off by 200 m. This would be useful if you could bound the technology resolution in all cases, i.e., that it is extremely unlikely to be wrong by more than X meters. Thus, worrying too much about accuracy is like providing pound-to-kilogram conversions on noodle packages to 7 digits. James Winterbottom wrote: > Hi All, > > I am going to change the subject a bit here from what has been going > around the list to date about "validated locations". > > I want to ask some opinions about geodetic information, and how we > should seek to interpret this. For IETF-62 I presented a paper in the > GeoPriv working group that was authored by me, Hannes Tschofenig and > Martin Thomson on, amongst other things, what might be a required > minimal set of GML to implement to support routing applications. > (http://www.ietf.org/internet-drafts/draft-winterbottom-geopriv-pdif-lo-prof ile-00.txt) > > In the presentation I indicated that we were going to look at > uncertainty in more detail in the next edition, and confidence. The > difference being that an uncertainty is usually defined as being with X > metres of a provided Latitude/Longitude, and a confidence factor is a > percentage chance that you will reside in that area. PIDF-LO does not > support the notion of a confidence factor today, but this is something > that we plan to look at in the next iteration of the above draft in the > form of suggestions. > > The wireless standards, at least those used in North America, > generally > provide both. And the FCC for regulations are really only interested in > 2 confidence factors, the 67% and the 90%. This tends to lead to the > location representations as being closed shapes, circles, polygons, > arcbands etc, rather than single points. While a circle with uncertainty > can be expressed a s point with radius, neither a polygon or an arcband > can. > > So where is this leading? > 1) Do we care about confidence in location for routing? > 2) If so, what is our minimal confidence level? > 3) Do we have preferences in how location is to specified (see draft > above)? > > While these points may be lower level requirements, they are things > that > we must start considering if we want an implementable solution. > > Cheers > James > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ------=_NextPart_000_090D_01C535D6.F56BE6D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Ecrit] Geodetic interpretations

Question: If the technology that determines location can’t figure out where you’re at, how = can the protocol that carries the data and/or the using application figure it = out?

 

Location determination is a hard = problem, but I don’t believe it’s an IETF problem, and certainly not = an ecrit problem.  I believe, but I may be convinced otherwise, that = ecrit will require a location point to use for routing.  This would = require the location determination mechanism to make its best guess at determining = that point.  And, if it’s routed wrong, that is what selective = transfer is all about, which is what happens with the 30% miss-routes = today.

 

-Marc-

 

 

 

 

 

From: = ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of James Winterbottom
Sent: Wednesday, March = 30, 2005 9:09 PM
To: Henning = Schulzrinne
Cc: ecrit@ietf.org
Subject: RE: [Ecrit] = Geodetic interpretations

 

I am not sure that I agree with you entirely here as I stated, for polygons and = arcbands (both of which are used today for cellular), they either do not specify = a centre point, or the point that is specified is not in the closed shape (arcband), so what would you do in these cases? You probably need to do = some sort of polygon inclusion or intersection mapping = anyway.

I also don't think that you are right about this not having an impact on = routing. If a point resides in one boundary, but 90% of the closed uncertainty shape = resides in a different boundary, a point only routing solution will misroute the = call. This is analogous to simply using cell-sector for cellular routing = which, according to some sources, results in about 30% of calls being = misrouted.

I am not saying that we would not route on point only, but we could specify = preferences and indicate why these have been chosen. I think that restricting = ourselves to a single point solution only does not lend itself so well to network = determined location techniques (particularly for wireless) as the points represent boundaries or references rather than client/device specific = location.

 

 

-----Original Message-----
From: Henning = Schulzrinne [mailto:hgs@cs.columbia.edu] =
Sent: Thursday, 31 March = 2005 11:48 AM
To: Winterbottom, James [WOLL:5500:EXCH]
Cc: = ecrit@ietf.org
Subject: Re: [Ecrit] = Geodetic interpretations

 

I'm not sure what you would do differently for routing if you knew the =
confidence interval = (which this is, roughly). You'd presumably always
route on the center of = circle or other geometric shape. Clearly, the
dispatcher might find = this useful to guess whether to send one squad car
or a search = party.

I'll repeat my rant from earlier: elaborate confidence measures are, in =
my view, largely bogus = for dispatch and routing. (They are useful to
characterize the = performance of a technology.) They are usually based on
not much more than = "measured across thousands of points across the
country, 90% of = measurements fell within 100 m of true location", which
says very little about = the GPS satellite shading or the number and
relative location of = cell towers (for TOA-style measurements), say, at
the corner of Main and = 5th in Podunk, NY. Thus, if you were to
repeatedly measure = location at that point, you might only be off by 10
m, or maybe it's a bad = spot and it's always off by 200 m.

This would be useful if you could bound the technology resolution in all =
cases, i.e., that it is = extremely unlikely to be wrong by more than X
meters. =

Thus, worrying too much about accuracy is like providing
pound-to-kilogram = conversions on noodle packages to 7 digits.

James Winterbottom wrote:
> Hi = All,
>
> I am going to = change the subject a bit here from what has been going
> around the list to = date about "validated locations".
>
> I want to ask some = opinions about geodetic information, and how we
> should seek to = interpret this. For IETF-62 I presented a paper in the
> GeoPriv working = group that was authored by me, Hannes Tschofenig and
> Martin Thomson on, = amongst other things, what might be a required
> minimal set of GML = to implement to support routing applications.
> (http://www.ietf.org/internet-drafts/draft-winterbottom-= geopriv-pdif-lo-profile-00.txt)
>
> In the presentation = I indicated that we were going to look at
> uncertainty in more = detail in the next edition, and confidence. The
> difference being = that an uncertainty is usually defined as being with X
> metres of a = provided Latitude/Longitude, and a confidence factor is a
> percentage chance = that you will reside in that area. PIDF-LO does not
> support the notion = of a confidence factor today, but this is something
> that we plan to = look at in the next iteration of the above draft in the
> form of = suggestions.
>
> The wireless = standards, at least those used in North America, =
> = generally
> provide both. And = the FCC for regulations are really only interested in
> 2 confidence = factors, the 67% and the 90%. This tends to lead to the
> location = representations as being closed shapes, circles, polygons,
> arcbands etc, = rather than single points. While a circle with uncertainty
> can be expressed a = s point with radius, neither a polygon or an arcband
> can. =
>
> So where is this = leading?
> 1) Do we care about = confidence in location for routing?
> 2) If so, what is = our minimal confidence level?
> 3) Do we have = preferences in how location is to specified (see draft
> = above)?
>
> While these points = may be lower level requirements, they are things
> that =
> we must start = considering if we want an implementable solution.
>
> = Cheers
> James =
>
>
> ----------------------------------------------------------------------
> -- =
>
> = _______________________________________________
> Ecrit mailing = list
> = Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit=

------=_NextPart_000_090D_01C535D6.F56BE6D0-- --===============1258855762== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1258855762==-- From ecrit-bounces@ietf.org Thu Mar 31 12:50:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16033; Thu, 31 Mar 2005 12:50:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH3vL-0008Kp-MS; Thu, 31 Mar 2005 12:57:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH3mN-0006lw-G8; Thu, 31 Mar 2005 12:48:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH3mL-0006lr-QV for ecrit@megatron.ietf.org; Thu, 31 Mar 2005 12:48:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15848 for ; Thu, 31 Mar 2005 12:48:23 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH3tV-0008Bi-JI for ecrit@ietf.org; Thu, 31 Mar 2005 12:55:50 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 31 Mar 2005 13:08:32 -0500 X-IronPort-AV: i="3.91,138,1110171600"; d="scan'208"; a="42677248:sNHT28337884" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2VHlujK020501; Thu, 31 Mar 2005 12:48:09 -0500 (EST) 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); Thu, 31 Mar 2005 12:47:59 -0500 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] Re: Ecrit Digest, Vol 2, Issue 26 Date: Thu, 31 Mar 2005 12:47:57 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E304DC46@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 26 Thread-Index: AcU1ezSeLkcB3aC+SLWIhEKO0/uXIwAFrhaQACHpxzA= From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Mark Scharaga" , X-OriginalArrivalTime: 31 Mar 2005 17:47:59.0289 (UTC) FILETIME=[C721CA90:01C53619] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Brian, I agree with your no-conversion stance, but you need to take non-city situations into account. And there may also be various forms of emergency service, e.g. fire/rescue boat, that aren't constrained to streets. Mike=20 >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Brian Rosen >Sent: Wednesday, March 30, 2005 8:46 PM >To: 'Mark Scharaga'; ecrit@ietf.org >Subject: RE: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 26 > >Chairs may decide this thread is no longer in scope. > >Mark > >Please tell me how you expect a fire truck to be dispatched to=20 >a lat/lon. >It's possible to tell them to go to 1/2 mile north of some=20 >cross street on some other street, but you don't give them a lat/lon. > >When a call taker answers a call, one of the first things they=20 >ask you, besides what is wrong, is where you are. You don't=20 >read off your GPS coordinates. They don't insist on a street=20 >number, but they are looking at a map that has street numbers=20 >marked on it, and they often have software that is showing the=20 >"closest" address to the reported lat/lon. They have to enter=20 >a street address into their systems in one way or another. > >The coordinates are not "more important". They are probably=20 >more accurate than any conversion from lat/lon to civic,=20 >because you can't add accuracy with a conversion, you can only=20 >decrease accuracy. This is why I don't like conversion. =20 >Sometimes, as with dispatch, you need to convert. > >The rule I like is "send whatever the original data was=20 >determined". If the data was originally measured, as with=20 >GPS, then send geo. If the data was originally entered as a=20 >street address, send a civic. If you have some converted data=20 >also, send that, but mark it as converted from the other form=20 >and send the original first. NEVER convert, and send only the=20 >converted data. Don't assume you know what the other end needs. =20 > >Brian > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >> Of Mark Scharaga >> Sent: Wednesday, March 30, 2005 5:55 PM >> To: ecrit@ietf.org >> Subject: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 26 >>=20 >> Folks, >>=20 >> A large number of PSAPs use mapping and CAD systems to=20 >display closest=20 >> route and streets to a location. THe dispatcher has to make the=20 >> determination if that information is correct, as there are=20 >times (more=20 >> often in rural areas) where the actual caller maybe on a=20 >lake or river=20 >> and the closest road could be miles away. >>=20 >> THe coordinates of the caller are actually more important than the=20 >> physical street address. However, in the traditional landline call=20 >> scenario the PSAP uses the street address and whatever info they can=20 >> get from the caller to make the proper unit responses occur. With=20 >> mobile callers most mapping systems display the actual=20 >location of the=20 >> caller, not resolved to the closest location. There are some systems=20 >> that do try to resolve the coordinates to an actual street address.=20 >> During my career I strongly advised against any system that did this=20 >> due to probability of error. >>=20 >> Mark >>=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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 31 13:08:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18183; Thu, 31 Mar 2005 13:08:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH4D1-0000iN-PZ; Thu, 31 Mar 2005 13:16:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH42J-0001GY-RM; Thu, 31 Mar 2005 13:04:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH42J-0001GR-9S for ecrit@megatron.ietf.org; Thu, 31 Mar 2005 13:04:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17714 for ; Thu, 31 Mar 2005 13:04:52 -0500 (EST) Message-Id: <200503311804.NAA17714@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH49T-0000U9-He for ecrit@ietf.org; Thu, 31 Mar 2005 13:12:19 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DH424-0001En-7R; Thu, 31 Mar 2005 12:04:40 -0600 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Mark Scharaga'" , Subject: RE: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 26 Date: Thu, 31 Mar 2005 13:04:34 -0500 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.2180 Thread-Index: AcU1ezSeLkcB3aC+SLWIhEKO0/uXIwAFrhaQACHpxzAAAE9+EA== In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E304DC46@xmb-rtp-20b.amer.cisco.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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b 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 X-Spam-Score: 0.8 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit Yes. I have always thought that "responder" is a much wider group of agencies than police/fire/ems, and it's true that coast guard, and mountain rescue would be very happy to be dispatched to GPS coordinates. Fire/rescue boat is an interesting case. The boats undoubtedly have GPS. The systems that dispatch them can't, at present, deal with geo, but that is changing. "Non city" doesn't compute. Even in the most rural environment, police, fire and ems dispatch is to a civic address. This is all beyond the problem at hand, which is how do you route the call. I think we're agreeing that you route with the original (most accurate) form of the location, whatever that is. If you happen to have a converted version, and you want to send that, fine, as long as you mark it as such. The PSAP may have to be able to convert, both from geo to civic and from civic to geo, but that is beyond ecrit scope. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Thursday, March 31, 2005 12:48 PM > To: Brian Rosen; Mark Scharaga; ecrit@ietf.org > Subject: RE: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 26 > > Brian, > > I agree with your no-conversion stance, but you need to take non-city > situations into account. And there may also be various forms of > emergency service, e.g. fire/rescue boat, that aren't constrained to > streets. > > Mike > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of Brian Rosen > >Sent: Wednesday, March 30, 2005 8:46 PM > >To: 'Mark Scharaga'; ecrit@ietf.org > >Subject: RE: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 26 > > > >Chairs may decide this thread is no longer in scope. > > > >Mark > > > >Please tell me how you expect a fire truck to be dispatched to > >a lat/lon. > >It's possible to tell them to go to 1/2 mile north of some > >cross street on some other street, but you don't give them a lat/lon. > > > >When a call taker answers a call, one of the first things they > >ask you, besides what is wrong, is where you are. You don't > >read off your GPS coordinates. They don't insist on a street > >number, but they are looking at a map that has street numbers > >marked on it, and they often have software that is showing the > >"closest" address to the reported lat/lon. They have to enter > >a street address into their systems in one way or another. > > > >The coordinates are not "more important". They are probably > >more accurate than any conversion from lat/lon to civic, > >because you can't add accuracy with a conversion, you can only > >decrease accuracy. This is why I don't like conversion. > >Sometimes, as with dispatch, you need to convert. > > > >The rule I like is "send whatever the original data was > >determined". If the data was originally measured, as with > >GPS, then send geo. If the data was originally entered as a > >street address, send a civic. If you have some converted data > >also, send that, but mark it as converted from the other form > >and send the original first. NEVER convert, and send only the > >converted data. Don't assume you know what the other end needs. > > > >Brian > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf > >> Of Mark Scharaga > >> Sent: Wednesday, March 30, 2005 5:55 PM > >> To: ecrit@ietf.org > >> Subject: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 26 > >> > >> Folks, > >> > >> A large number of PSAPs use mapping and CAD systems to > >display closest > >> route and streets to a location. THe dispatcher has to make the > >> determination if that information is correct, as there are > >times (more > >> often in rural areas) where the actual caller maybe on a > >lake or river > >> and the closest road could be miles away. > >> > >> THe coordinates of the caller are actually more important than the > >> physical street address. However, in the traditional landline call > >> scenario the PSAP uses the street address and whatever info they can > >> get from the caller to make the proper unit responses occur. With > >> mobile callers most mapping systems display the actual > >location of the > >> caller, not resolved to the closest location. There are some systems > >> that do try to resolve the coordinates to an actual street address. > >> During my career I strongly advised against any system that did this > >> due to probability of error. > >> > >> Mark > >> > >> > >> _______________________________________________ > >> 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 Thu Mar 31 14:12:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24579; Thu, 31 Mar 2005 14:12:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH5Cg-0003Df-W0; Thu, 31 Mar 2005 14:19:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH54A-0008B2-S4; Thu, 31 Mar 2005 14:10:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH54A-0008Aw-2m for ecrit@megatron.ietf.org; Thu, 31 Mar 2005 14:10:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24356 for ; Thu, 31 Mar 2005 14:10:52 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH5BJ-0003AR-Jg for ecrit@ietf.org; Thu, 31 Mar 2005 14:18:19 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.4) with ESMTP id ; Thu, 31 Mar 2005 14:10:42 -0500 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] Re: Ecrit Digest, Vol 2, Issue 26 Date: Thu, 31 Mar 2005 11:10:41 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750207FE8A@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 26 Thread-Index: AcU1ezSeLkcB3aC+SLWIhEKO0/uXIwAFrhaQACHpxzAAAE9+EAABdZxA From: "Roger Marshall" To: "Brian Rosen" , "Michael Hammer \(mhammer\)" , "Mark Scharaga" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: quoted-printable Don't neglect other valid "non city" contexts, such as unplotted agricultural fields, roads, and out-buildings, mountain slopes, and desert expanses. Each of these could be modeled the same as open water, except the added component of elevation becomes more important. I agree that early (geo or reverse geo) conversion requires some sort of flag stating that one's a derivation, rather than a measurement. Both location systems (civic & geo) are not equivalent, geodetic is a general solution, whereas civic is only valid within a specific context (e.g. improved areas within North America). The bigger problem is as Brian stated, "how you route the call", especially in the context of mobility. If we can solve mobility, then static and nomadic solutions fall out more easily. =20 Here's an example use case: Let's say a caller is mobile, and initiates a call while in transit. Either one of two things is true, either the lat/lon used for routing is stale (was measured some prior point in time), or the call takes ~15s to initiate, since a "current" lat/lon must be generated. If I was drifting as sea, with nothing else to do, I may put up with a 15 second delay, although neither is optimal. Until GPS fixes are obtainable in the sub-second range, a more practical solution is required to support mobility - one in which routing is done quickly (sub-second), and is done based on context appropriate location information, such as an AP location (WiFi), serving tower location (2-3G), etc. To do this requires a location infrastructure, even for devices with GPS inside. Roger Marshall -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, March 31, 2005 10:05 AM To: 'Michael Hammer (mhammer)'; 'Mark Scharaga'; ecrit@ietf.org Subject: RE: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 26 Yes. I have always thought that "responder" is a much wider group of agencies than police/fire/ems, and it's true that coast guard, and mountain rescue would be very happy to be dispatched to GPS coordinates. Fire/rescue boat is an interesting case. The boats undoubtedly have GPS. The systems that dispatch them can't, at present, deal with geo, but that is changing. "Non city" doesn't compute. Even in the most rural environment, police, fire and ems dispatch is to a civic address. =20 This is all beyond the problem at hand, which is how do you route the call. I think we're agreeing that you route with the original (most accurate) form of the location, whatever that is. If you happen to have a converted version, and you want to send that, fine, as long as you mark it as such. The PSAP may have to be able to convert, both from geo to civic and from civic to geo, but that is beyond ecrit scope. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Thursday, March 31, 2005 12:48 PM > To: Brian Rosen; Mark Scharaga; ecrit@ietf.org > Subject: RE: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 26 >=20 > Brian, >=20 > I agree with your no-conversion stance, but you need to take non-city > situations into account. And there may also be various forms of > emergency service, e.g. fire/rescue boat, that aren't constrained to > streets. >=20 > Mike >=20 > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of Brian Rosen > >Sent: Wednesday, March 30, 2005 8:46 PM > >To: 'Mark Scharaga'; ecrit@ietf.org > >Subject: RE: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 26 > > > >Chairs may decide this thread is no longer in scope. > > > >Mark > > > >Please tell me how you expect a fire truck to be dispatched to > >a lat/lon. > >It's possible to tell them to go to 1/2 mile north of some > >cross street on some other street, but you don't give them a lat/lon. > > > >When a call taker answers a call, one of the first things they > >ask you, besides what is wrong, is where you are. You don't > >read off your GPS coordinates. They don't insist on a street > >number, but they are looking at a map that has street numbers > >marked on it, and they often have software that is showing the > >"closest" address to the reported lat/lon. They have to enter > >a street address into their systems in one way or another. > > > >The coordinates are not "more important". They are probably > >more accurate than any conversion from lat/lon to civic, > >because you can't add accuracy with a conversion, you can only > >decrease accuracy. This is why I don't like conversion. > >Sometimes, as with dispatch, you need to convert. > > > >The rule I like is "send whatever the original data was > >determined". If the data was originally measured, as with > >GPS, then send geo. If the data was originally entered as a > >street address, send a civic. If you have some converted data > >also, send that, but mark it as converted from the other form > >and send the original first. NEVER convert, and send only the > >converted data. Don't assume you know what the other end needs. > > > >Brian > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf > >> Of Mark Scharaga > >> Sent: Wednesday, March 30, 2005 5:55 PM > >> To: ecrit@ietf.org > >> Subject: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 26 > >> > >> Folks, > >> > >> A large number of PSAPs use mapping and CAD systems to > >display closest > >> route and streets to a location. THe dispatcher has to make the > >> determination if that information is correct, as there are > >times (more > >> often in rural areas) where the actual caller maybe on a > >lake or river > >> and the closest road could be miles away. > >> > >> THe coordinates of the caller are actually more important than the > >> physical street address. However, in the traditional landline call > >> scenario the PSAP uses the street address and whatever info they can > >> get from the caller to make the proper unit responses occur. With > >> mobile callers most mapping systems display the actual > >location of the > >> caller, not resolved to the closest location. There are some systems > >> that do try to resolve the coordinates to an actual street address. > >> During my career I strongly advised against any system that did this > >> due to probability of error. > >> > >> Mark > >> > >> > >> _______________________________________________ > >> 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 > > >=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 Thu Mar 31 14:42:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27011; Thu, 31 Mar 2005 14:42:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH5fi-0004Li-Pj; Thu, 31 Mar 2005 14:49:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH5UR-0004tC-N8; Thu, 31 Mar 2005 14:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH5UQ-0004t6-CU for ecrit@megatron.ietf.org; Thu, 31 Mar 2005 14:38:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26755 for ; Thu, 31 Mar 2005 14:38:00 -0500 (EST) Received: from mail.easycgi.com ([66.245.177.160] helo=easycgi.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH5bZ-0004Ay-P6 for ecrit@ietf.org; Thu, 31 Mar 2005 14:45:27 -0500 Received: from [70.16.239.176] (account marks@maximtsc.com) by easycgi.com (CommuniGate Pro WebUser 4.2.3) with HTTP id 45941293; Thu, 31 Mar 2005 14:40:48 -0500 From: "Mark Scharaga" To: "Roger Marshall" X-Mailer: CommuniGate Pro WebUser Interface v.4.2.3 Date: Thu, 31 Mar 2005 14:40:48 -0500 Message-ID: In-Reply-To: <8C837214C95C864C9F34F3635C2A65750207FE8A@SEA-EXCHVS-2.telecomsys.com> References: <8C837214C95C864C9F34F3635C2A65750207FE8A@SEA-EXCHVS-2.telecomsys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 8bit Cc: ecrit@ietf.org Subject: [Ecrit] Class of Service? 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 8bit In the current wireless call delivery structure the carriers use a class of service field to denote the service the PSAP is receiving on that call. This tells the dispatcher that the call is either phase 0, I or II and may or may not be "rebid" or "redipped" for the LAT/LON coordinates. Maybe there should be a similar method or action for GEO or Civic? Mark Scharaga President- Maxim Technology Solutions www.maximtsc.com 888-288-3059 X101 On Thu, 31 Mar 2005 11:10:41 -0800 "Roger Marshall" wrote: > Don't neglect other valid "non city" contexts, such as >unplotted agricultural fields, roads, and out-buildings, mountain >slopes, and desert expanses. Each of these could be modeled the >same as open water, except the added component of elevation becomes more important. I agree that early (geo or reverse geo) conversion requires some sort of flag stating that one's a derivation, rather than a measurement. Both location systems (civic & geo) are not equivalent, geodetic is a generalsolution, whereas civic is only valid within a specific context (e.g. improved areas within North America). The bigger problem is as Brian stated, "how you route the call", especially in the context of mobility. If we can solve mobility, then static and nomadic solutions fall out more easily. Here's an example use case: Let's say a caller is mobile, and initiates a call while in transit. Either one of two things is true, either the lat/lon used for routing is stale (was measured some prior point in time), or the call takes ~15s to initiate, since a "current" lat/lon must be generated. If I was drifting as sea, with nothing else to do, I may put up with a 15 second delay, although neither is optimal. Until GPS fixes are obtainable in the sub-second range, a more practical solution is required to support mobility - one in which routing is done quickly (sub-second), and is done based on context appropriate location information, such as an AP location (WiFi), serving tower location (2-3G), etc. To do this requires a location infrastructure, even for devices with GPS inside. Roger Marshall _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 31 15:06:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29512; Thu, 31 Mar 2005 15:06:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH62x-0005Ej-3J; Thu, 31 Mar 2005 15:13:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH5ue-00012e-NV; Thu, 31 Mar 2005 15:05:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH5ud-00012U-Ty for ecrit@megatron.ietf.org; Thu, 31 Mar 2005 15:05:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29287 for ; Thu, 31 Mar 2005 15:05:06 -0500 (EST) 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.33) id 1DH61p-0005Cl-73 for ecrit@ietf.org; Thu, 31 Mar 2005 15:12:33 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 31 Mar 2005 12:04:58 -0800 X-IronPort-AV: i="3.91,138,1110182400"; d="scan'208"; a="243724526:sNHT28604428" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2VK4pgE002087; Thu, 31 Mar 2005 12:04:51 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA12290; Thu, 31 Mar 2005 12:04:55 -0800 (PST) Message-Id: <4.3.2.7.2.20050331140217.043aef00@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 31 Mar 2005 14:04:54 -0600 To: "Mark Scharaga" , "Roger Marshall" From: "James M. Polk" Subject: Re: [Ecrit] Class of Service? In-Reply-To: References: <8C837214C95C864C9F34F3635C2A65750207FE8A@SEA-EXCHVS-2.telecomsys.com> <8C837214C95C864C9F34F3635C2A65750207FE8A@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 X-Spam-Score: 1.1 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Mark The CoS field is populated by "the network" in the wireless case, correct? This field would be in the PIDF-LO message body (part) in the SIP INVITE, which is not modified by "the network" in transit to the PSAP, so how/why would you trust the endpoint to enter the right field value? At 02:40 PM 3/31/2005 -0500, Mark Scharaga wrote: >In the current wireless call delivery structure the carriers use a class >of service field to denote the service the PSAP is receiving on that call. >This tells the dispatcher that the call is either phase 0, I or II and may >or may not be "rebid" or "redipped" for the LAT/LON coordinates. Maybe >there should be a similar method or action for GEO or Civic? > > >Mark Scharaga >President- Maxim Technology Solutions >www.maximtsc.com >888-288-3059 X101 > >On Thu, 31 Mar 2005 11:10:41 -0800 "Roger Marshall" > wrote: > >>Don't neglect other valid "non city" contexts, such as unplotted >>agricultural fields, roads, and out-buildings, mountain slopes, and >>desert expanses. Each of these could be modeled the same as open water, >>except the added component of elevation becomes more important. > >I agree that early (geo or reverse geo) conversion >requires some sort of flag stating that one's a derivation, rather than a >measurement. Both location systems (civic & geo) are not equivalent, >geodetic is a generalsolution, whereas civic is only valid within a >specific context (e.g. improved areas within North America). > > The bigger problem is as Brian stated, "how you route >the call", especially in the context of mobility. If we can solve >mobility, then static and nomadic solutions fall out more easily. >Here's an example use case: Let's say a caller is mobile, and initiates a >call while in transit. Either one of two things is true, either the >lat/lon used for routing is stale (was measured some prior point in time), >or the call takes ~15s to initiate, since a "current" lat/lon must be >generated. If I was drifting as sea, with nothing else to do, I may put >up with a 15 second delay, although neither is optimal. > >Until GPS fixes are obtainable in the sub-second range, >a more practical solution is required to support mobility - one in which >routing is done quickly (sub-second), and is done based on context >appropriate location information, such as an AP location (WiFi), serving >tower location (2-3G), etc. To do this requires a location >infrastructure, even for devices with GPS inside. > >Roger Marshall > >_______________________________________________ >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