From ecrit-bounces@ietf.org Sat Sep 03 07:52:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBWZP-0001u9-Vd; Sat, 03 Sep 2005 07:52:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBWZO-0001u4-MI for ecrit@megatron.ietf.org; Sat, 03 Sep 2005 07:52:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01262 for ; Sat, 3 Sep 2005 07:52:25 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBWbi-00061Q-Sx for ecrit@ietf.org; Sat, 03 Sep 2005 07:54:52 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j83BqA8f024733 for ; Sat, 3 Sep 2005 13:52:10 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j83BqAW6009797 for ; Sat, 3 Sep 2005 13:52:10 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 3 Sep 2005 13:52:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 3 Sep 2005 13:52:09 +0200 Message-ID: Thread-Topic: Updated Draft: "Requirements for Emergency Context Resolution with Internet Technologies" Thread-Index: AcWwCEKrM4MUIyKTTFiUAxrYLOVj3gAdWmIA From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 03 Sep 2005 11:52:10.0430 (UTC) FILETIME=[EAA96DE0:01C5B07D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Updated Draft: "Requirements for Emergency Context Resolution with Internet Technologies" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 please find an update of the 'Requirements for Emergency Context Resolution with Internet Technologies' draft at:=20 http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-00.txt ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 03 12:21:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBalK-0006I4-3i; Sat, 03 Sep 2005 12:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBalI-0006HW-VC for ecrit@megatron.ietf.org; Sat, 03 Sep 2005 12:21:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13517 for ; Sat, 3 Sep 2005 12:20:58 -0400 (EDT) Received: from pne-smtpout2-sn2.hy.skanova.net ([81.228.8.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBana-0005hF-JS for ecrit@ietf.org; Sat, 03 Sep 2005 12:23:29 -0400 Received: from MISAN (213.64.230.47) by pne-smtpout2-sn2.hy.skanova.net (7.2.060.1) id 42B94E2900C076E4; Sat, 3 Sep 2005 18:20:39 +0200 From: "Gunnar Hellstrom" To: , "Tschofenig, Hannes" Subject: SV: [Ecrit] Updated Draft: "Requirements for Emergency ContextResolution with Internet Technologies" Date: Sat, 3 Sep 2005 18:20:37 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: Gregg Vanderheiden , Arnoud van Wijk , Judy Harkins , Robert Hecht , Guido Gybels 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 Hannes, Thanks, the introduced accessibility related sections look fine. Gunnar ---------------------------------------------------------------------------- - Gunnar Hellstrom, Omnitor Mob: +46 708 204 288 Phone: +46 8 556 002 03 -----Ursprungligt meddelande----- Fran: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]For Tschofenig, Hannes Skickat: den 3 september 2005 13:52 Till: ecrit@ietf.org Amne: [Ecrit] Updated Draft: "Requirements for Emergency ContextResolution with Internet Technologies" hi all, please find an update of the 'Requirements for Emergency Context Resolution with Internet Technologies' draft at: http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-00.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 Sep 04 12:41:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBxYy-0007I5-5E; Sun, 04 Sep 2005 12:41:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBxYw-0007Hs-0q for ecrit@megatron.ietf.org; Sun, 04 Sep 2005 12:41:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13660 for ; Sun, 4 Sep 2005 12:41:43 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBxbV-0002Nm-ON for ecrit@ietf.org; Sun, 04 Sep 2005 12:44:27 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j84GfYLl024868 for ; Sun, 4 Sep 2005 18:41:34 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j84GfYmR004674 for ; Sun, 4 Sep 2005 18:41:34 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Sun, 4 Sep 2005 18:41:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 4 Sep 2005 18:41:34 +0200 Message-ID: Thread-Topic: Resolving open issues concerning draft-ietf-ecrit-requirements-00.txt Thread-Index: AcWxb2vShV6SkeLtQ92duGtfzZHTdw== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 04 Sep 2005 16:41:34.0725 (UTC) FILETIME=[83005350:01C5B16F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Resolving open issues concerning draft-ietf-ecrit-requirements-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 in order to move forward with the requirements draft=20 (see http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-00.txt) in a structured way we have created an issue tracker. it can be found at:=20 http://www.ietf-ecrit.org:8080/ecrit-req/ please review the draft and submit open issues as soon as possible.=20 ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 05 00:48:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EC8uT-0005lq-0u; Mon, 05 Sep 2005 00:48:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EC8uL-0005kt-Pb for ecrit@megatron.ietf.org; Mon, 05 Sep 2005 00:48:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11372 for ; Mon, 5 Sep 2005 00:48:34 -0400 (EDT) Received: from sv5.per.eftel.com ([203.24.100.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EC8wz-0001ky-Ng for ecrit@ietf.org; Mon, 05 Sep 2005 00:51:25 -0400 Received: from [127.0.0.1] (dialup-1-144.MelbournePwrtl2.dft.com.au [203.123.89.144]) by sv5.per.eftel.com (Postfix) with ESMTP id AB1B2BBC4B; Mon, 5 Sep 2005 12:48:01 +0800 (WST) Message-ID: <431BCDF5.7010808@bigfoot.com.au> Date: Mon, 05 Sep 2005 14:47:49 +1000 From: Barry Dingle User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: [Ecrit] Updated Draft: "Requirements for Emergency Context Resolution with Internet Technologies" References: In-Reply-To: X-Spam-Score: 1.0 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ecrit@ietf.org, Tracey Annear 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="===============0198996567==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============0198996567== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hannes,

The draft is looking very good.

One small comment - in Section 2 , the definition of "emergency address" should be more general than 'a VoIP emergency call' because this document relates to multiple services. I suggest that the last part of the definition read: " ....... which represents the network address of the PSAP useful for the completion of an emergency call."

Alternatively, it could be made more specific with the words " ....... which represents the network address of the PSAP useful for the completion of a VoIP or other general Internet multimedia emergency call." (Words taken from the Abstract.)

I prefer the first option.

Cheers,
/Barry

Barry DINGLE
Telecommunications Consultant
Fellow of the University of Melbourne
Chair - ACIF Customer Equipment and Cable Reference Panel (CECRP) 
    barry.dingle@bigfoot.com.au
  Mob:   +61 (0)41 911 7578
  Fixed: +61 (0)3 9725 3937
  ToIP:  barry.dingle@trysip.ingate.com


Tschofenig, Hannes wrote: 
hi all, 

please find an update of the 'Requirements for Emergency Context
Resolution with Internet Technologies' draft at: 
http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-00.txt

ciao
hannes

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit
--===============0198996567== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0198996567==-- From ecrit-bounces@ietf.org Mon Sep 05 04:54:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECCjz-0001Sb-SD; Mon, 05 Sep 2005 04:54:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECCjx-0001ST-Ae for ecrit@megatron.ietf.org; Mon, 05 Sep 2005 04:54:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04289 for ; Mon, 5 Sep 2005 04:54:06 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECCme-000847-Mq for ecrit@ietf.org; Mon, 05 Sep 2005 04:56:58 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j858rXCm017618; Mon, 5 Sep 2005 10:53:33 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j858rSPK002001; Mon, 5 Sep 2005 10:53:29 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Sep 2005 10:53:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Updated Draft: "Requirements for Emergency Context Resolution with Internet Technologies" Date: Mon, 5 Sep 2005 10:53:28 +0200 Message-ID: Thread-Topic: [Ecrit] Updated Draft: "Requirements for Emergency Context Resolution with Internet Technologies" Thread-Index: AcWx1R5J6nJnjfDBRyGwpDXKxW9jBgAIfM7w From: "Tschofenig, Hannes" To: "Barry Dingle" X-OriginalArrivalTime: 05 Sep 2005 08:53:28.0671 (UTC) FILETIME=[48D256F0:01C5B1F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org, Tracey Annear X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi barry, thanks for the comment. i have added it to the issue tracker.=20 here is the suggested change:=20 from: " emergency address: The sip:uri, sips:uri, or tel:uri which represents the network address of the PSAP useful for the completion of a VoIP emergency call. " to: " emergency address: The sip:uri, sips:uri, or tel:uri which represents the address of the PSAP useful for the completion of an emergency = call. " i also changed 'network address' to 'address' since the term "network = address" should not be misunderstood as network layer address (which = would then be wrong). ciao hannes -----Urspr=FCngliche Nachricht----- Von: Barry Dingle [mailto:barry.dingle@bigfoot.com.au]=20 Gesendet: Montag, 5. September 2005 06:48 An: Tschofenig, Hannes Cc: ecrit@ietf.org; Tracey Annear Betreff: Re: [Ecrit] Updated Draft: "Requirements for Emergency Context = Resolution with Internet Technologies" Hannes, The draft is looking very good. One small comment - in Section 2 , the definition of "emergency address" = should be more general than 'a VoIP emergency call' because this = document relates to multiple services. I suggest that the last part of = the definition read: " ....... which represents the network address of = the PSAP useful for the completion of an emergency call." Alternatively, it could be made more specific with the words " ....... = which represents the network address of the PSAP useful for the = completion of a VoIP or other general Internet multimedia emergency = call." (Words taken from the Abstract.) I prefer the first option.=20 Cheers, /Barry Barry DINGLE Telecommunications Consultant Fellow of the University of Melbourne Chair - ACIF Customer Equipment and Cable Reference Panel (CECRP)=20 barry.dingle@bigfoot.com.au Mob: +61 (0)41 911 7578 Fixed: +61 (0)3 9725 3937 ToIP: barry.dingle@trysip.ingate.com Tschofenig, Hannes wrote:=20 hi all,=20 please find an update of the 'Requirements for Emergency Context Resolution with Internet Technologies' draft at:=20 http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-00.txt ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 05 08:21:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECFyg-0005Ds-9v; Mon, 05 Sep 2005 08:21:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECFye-0005Bq-Ff for ecrit@megatron.ietf.org; Mon, 05 Sep 2005 08:21:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13890 for ; Mon, 5 Sep 2005 08:21:31 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECG1P-0005Kt-VQ for ecrit@ietf.org; Mon, 05 Sep 2005 08:24:24 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by mx2.foretec.com with smtp (Exim 4.24) id 1ECFyT-0007GY-5F for ecrit@ietf.org; Mon, 05 Sep 2005 08:21:23 -0400 Content-class: urn:content-classes:message Subject: RE: [Ecrit] Updated Draft: "Requirements for EmergencyContext Resolution with Internet Technologies" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Sep 2005 14:23:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B2104@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Updated Draft: "Requirements for EmergencyContext Resolution with Internet Technologies" thread-index: AcWx1R5J6nJnjfDBRyGwpDXKxW9jBgAIfM7wAAcelWA= From: "Stastny Richard" To: "Tschofenig, Hannes" , "Barry Dingle" X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, you cannot use the term address plain I still have a problem with the term address in the document. Address is used in 5 different contexts in the document: Address =3D location address (civil or geo) Emergency address =3D the SIP URI of the (network) address ... Network address =3D now reduced to address Authors address ;-) I propose for the avoidance of ambiguity even if it is clear what the context is, always to use the term address with the proper context in front e.g. location address -richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of > Tschofenig, Hannes > Sent: Monday, September 05, 2005 10:53 AM > To: Barry Dingle > Cc: ecrit@ietf.org; Tracey Annear > Subject: AW: [Ecrit] Updated Draft: "Requirements for EmergencyContext > Resolution with Internet Technologies" >=20 > hi barry, >=20 > thanks for the comment. i have added it to the issue tracker. >=20 > here is the suggested change: >=20 > from: >=20 > " > emergency address: The sip:uri, sips:uri, or tel:uri which = represents > the network address of the PSAP useful for the completion of a > VoIP emergency call. > " >=20 > to: >=20 > " > emergency address: The sip:uri, sips:uri, or tel:uri which = represents > the address of the PSAP useful for the completion of an = emergency > call. > " >=20 > i also changed 'network address' to 'address' since the term "network > address" should not be misunderstood as network layer address (which = would > then be wrong). >=20 > ciao > hannes >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Barry Dingle [mailto:barry.dingle@bigfoot.com.au] > Gesendet: Montag, 5. September 2005 06:48 > An: Tschofenig, Hannes > Cc: ecrit@ietf.org; Tracey Annear > Betreff: Re: [Ecrit] Updated Draft: "Requirements for Emergency = Context > Resolution with Internet Technologies" >=20 >=20 > Hannes, >=20 > The draft is looking very good. >=20 > One small comment - in Section 2 , the definition of "emergency = address" > should be more general than 'a VoIP emergency call' because this = document > relates to multiple services. I suggest that the last part of the > definition read: " ....... which represents the network address of the > PSAP useful for the completion of an emergency call." >=20 > Alternatively, it could be made more specific with the words " ....... > which represents the network address of the PSAP useful for the = completion > of a VoIP or other general Internet multimedia emergency call." (Words > taken from the Abstract.) >=20 > I prefer the first option. >=20 > Cheers, > /Barry >=20 >=20 > Barry DINGLE > Telecommunications Consultant > Fellow of the University of Melbourne > Chair - ACIF Customer Equipment and Cable Reference Panel (CECRP) > barry.dingle@bigfoot.com.au > Mob: +61 (0)41 911 7578 > Fixed: +61 (0)3 9725 3937 > ToIP: barry.dingle@trysip.ingate.com >=20 >=20 >=20 > Tschofenig, Hannes wrote: > hi all, >=20 > please find an update of the 'Requirements for Emergency Context > Resolution with Internet Technologies' draft at: > http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-00.txt >=20 > ciao > hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=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 Mon Sep 05 08:56:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECGWV-0001L6-8i; Mon, 05 Sep 2005 08:56:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECGWT-0001Kb-1D for ecrit@megatron.ietf.org; Mon, 05 Sep 2005 08:56:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15174 for ; Mon, 5 Sep 2005 08:56:27 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECGZE-00067i-Fg for ecrit@ietf.org; Mon, 05 Sep 2005 08:59:21 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j85Cu5XZ016412; Mon, 5 Sep 2005 14:56:05 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j85Cu4O7023885; Mon, 5 Sep 2005 14:56:04 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Sep 2005 14:56:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Updated Draft: "Requirements for EmergencyContext Resolution with Internet Technologies" Date: Mon, 5 Sep 2005 14:56:03 +0200 Message-ID: Thread-Topic: [Ecrit] Updated Draft: "Requirements for EmergencyContext Resolution with Internet Technologies" Thread-Index: AcWx1R5J6nJnjfDBRyGwpDXKxW9jBgAIfM7wAAcelWAAAMnVUA== From: "Tschofenig, Hannes" To: "Stastny Richard" , "Barry Dingle" X-OriginalArrivalTime: 05 Sep 2005 12:56:04.0364 (UTC) FILETIME=[2CB0D4C0:01C5B219] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi richard,=20 do you have a problem with the term 'emergency address' (as it is = defined or used in the document) or with the term 'address' (that is = also defined in the terminology section) or with the usage of address in = the definition of 'emergency address'?=20 ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Gesendet: Montag, 5. September 2005 14:24 > An: Tschofenig, Hannes; Barry Dingle > Cc: ecrit@ietf.org > Betreff: RE: [Ecrit] Updated Draft: "Requirements for=20 > EmergencyContext Resolution with Internet Technologies" >=20 >=20 > Hi all, >=20 > you cannot use the term address plain >=20 > I still have a problem with the term address in the document. >=20 > Address is used in 5 different contexts in the document: >=20 > Address =3D location address (civil or geo) > Emergency address =3D the SIP URI of the (network) address ... > Network address =3D now reduced to address > Authors address ;-) >=20 > I propose for the avoidance of ambiguity even if > it is clear what the context is, always to use > the term address with the proper context in front > e.g. location address >=20 > -richard >=20 >=20 > Richard Stastny > OeFEG > tel:+43 664 420 4100 > enum:+43 780 203 211 > callto://fordprefect > http://voipandenum.blogspot.com > =20 >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf Of > > Tschofenig, Hannes > > Sent: Monday, September 05, 2005 10:53 AM > > To: Barry Dingle > > Cc: ecrit@ietf.org; Tracey Annear > > Subject: AW: [Ecrit] Updated Draft: "Requirements for=20 > EmergencyContext > > Resolution with Internet Technologies" > >=20 > > hi barry, > >=20 > > thanks for the comment. i have added it to the issue tracker. > >=20 > > here is the suggested change: > >=20 > > from: > >=20 > > " > > emergency address: The sip:uri, sips:uri, or tel:uri=20 > which represents > > the network address of the PSAP useful for the completion of a > > VoIP emergency call. > > " > >=20 > > to: > >=20 > > " > > emergency address: The sip:uri, sips:uri, or tel:uri=20 > which represents > > the address of the PSAP useful for the completion of=20 > an emergency > > call. > > " > >=20 > > i also changed 'network address' to 'address' since the=20 > term "network > > address" should not be misunderstood as network layer=20 > address (which would > > then be wrong). > >=20 > > ciao > > hannes > >=20 > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Barry Dingle [mailto:barry.dingle@bigfoot.com.au] > > Gesendet: Montag, 5. September 2005 06:48 > > An: Tschofenig, Hannes > > Cc: ecrit@ietf.org; Tracey Annear > > Betreff: Re: [Ecrit] Updated Draft: "Requirements for=20 > Emergency Context > > Resolution with Internet Technologies" > >=20 > >=20 > > Hannes, > >=20 > > The draft is looking very good. > >=20 > > One small comment - in Section 2 , the definition of=20 > "emergency address" > > should be more general than 'a VoIP emergency call' because=20 > this document > > relates to multiple services. I suggest that the last part of the > > definition read: " ....... which represents the network=20 > address of the > > PSAP useful for the completion of an emergency call." > >=20 > > Alternatively, it could be made more specific with the=20 > words " ....... > > which represents the network address of the PSAP useful for=20 > the completion > > of a VoIP or other general Internet multimedia emergency=20 > call." (Words > > taken from the Abstract.) > >=20 > > I prefer the first option. > >=20 > > Cheers, > > /Barry > >=20 > >=20 > > Barry DINGLE > > Telecommunications Consultant > > Fellow of the University of Melbourne > > Chair - ACIF Customer Equipment and Cable Reference Panel (CECRP) > > barry.dingle@bigfoot.com.au > > Mob: +61 (0)41 911 7578 > > Fixed: +61 (0)3 9725 3937 > > ToIP: barry.dingle@trysip.ingate.com > >=20 > >=20 > >=20 > > Tschofenig, Hannes wrote: > > hi all, > >=20 > > please find an update of the 'Requirements for Emergency Context > > Resolution with Internet Technologies' draft at: > > http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-00.txt > >=20 > > ciao > > hannes > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 05 09:19:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECGt0-0004Lf-5C; Mon, 05 Sep 2005 09:19:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECGsy-0004Jv-20 for ecrit@megatron.ietf.org; Mon, 05 Sep 2005 09:19:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15936 for ; Mon, 5 Sep 2005 09:19:41 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ECGvj-0006at-1v for ecrit@ietf.org; Mon, 05 Sep 2005 09:22:35 -0400 Subject: Re: [Ecrit] Updated Draft: "Requirements for EmergencyContext Resolution with Internet Technologies" Date: Mon, 5 Sep 2005 15:23:04 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C44CC@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [Ecrit] Updated Draft: "Requirements for EmergencyContext Resolution with Internet Technologies" Thread-Index: AcWx1R5J6nJnjfDBRyGwpDXKxW9jBgAIfM7wAAcelWAAAMnVUAABAWlW From: "Stastny Richard" Content-class: urn:content-classes:message To: "Tschofenig, Hannes" , "Barry Dingle" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb 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 To be precise: I have a problem > with the term 'address' (that is also defined in the terminology = section)=20 =20 it should be location address (or something like that) to distuingish it = from emergency address and network address =20 >or with the usage of address in the definition of 'emergency address'? The term address here is ambiguos: so either we leave network address and define it in the definitions, or we come up with something else -richard ________________________________ Von: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] Gesendet: Mo 05.09.2005 14:56 An: Stastny Richard; Barry Dingle Cc: ecrit@ietf.org Betreff: AW: [Ecrit] Updated Draft: "Requirements for EmergencyContext = Resolution with Internet Technologies" hi richard, do you have a problem with the term 'emergency address' (as it is = defined or used in the document) or with the term 'address' (that is = also defined in the terminology section) or with the usage of address in = the definition of 'emergency address'? ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Gesendet: Montag, 5. September 2005 14:24 > An: Tschofenig, Hannes; Barry Dingle > Cc: ecrit@ietf.org > Betreff: RE: [Ecrit] Updated Draft: "Requirements for > EmergencyContext Resolution with Internet Technologies" > > > Hi all, > > you cannot use the term address plain > > I still have a problem with the term address in the document. > > Address is used in 5 different contexts in the document: > > Address =3D location address (civil or geo) > Emergency address =3D the SIP URI of the (network) address ... > Network address =3D now reduced to address > Authors address ;-) > > I propose for the avoidance of ambiguity even if > it is clear what the context is, always to use > the term address with the proper context in front > e.g. location address > > -richard > > > Richard Stastny > OeFEG > tel:+43 664 420 4100 > enum:+43 780 203 211 > callto://fordprefect > http://voipandenum.blogspot.com >=20 > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf Of > > Tschofenig, Hannes > > Sent: Monday, September 05, 2005 10:53 AM > > To: Barry Dingle > > Cc: ecrit@ietf.org; Tracey Annear > > Subject: AW: [Ecrit] Updated Draft: "Requirements for > EmergencyContext > > Resolution with Internet Technologies" > > > > hi barry, > > > > thanks for the comment. i have added it to the issue tracker. > > > > here is the suggested change: > > > > from: > > > > " > > emergency address: The sip:uri, sips:uri, or tel:uri > which represents > > the network address of the PSAP useful for the completion of a > > VoIP emergency call. > > " > > > > to: > > > > " > > emergency address: The sip:uri, sips:uri, or tel:uri > which represents > > the address of the PSAP useful for the completion of > an emergency > > call. > > " > > > > i also changed 'network address' to 'address' since the > term "network > > address" should not be misunderstood as network layer > address (which would > > then be wrong). > > > > ciao > > hannes > > > > > > -----Urspr=FCngliche Nachricht----- > > Von: Barry Dingle [mailto:barry.dingle@bigfoot.com.au] > > Gesendet: Montag, 5. September 2005 06:48 > > An: Tschofenig, Hannes > > Cc: ecrit@ietf.org; Tracey Annear > > Betreff: Re: [Ecrit] Updated Draft: "Requirements for > Emergency Context > > Resolution with Internet Technologies" > > > > > > Hannes, > > > > The draft is looking very good. > > > > One small comment - in Section 2 , the definition of > "emergency address" > > should be more general than 'a VoIP emergency call' because > this document > > relates to multiple services. I suggest that the last part of the > > definition read: " ....... which represents the network > address of the > > PSAP useful for the completion of an emergency call." > > > > Alternatively, it could be made more specific with the > words " ....... > > which represents the network address of the PSAP useful for > the completion > > of a VoIP or other general Internet multimedia emergency > call." (Words > > taken from the Abstract.) > > > > I prefer the first option. > > > > Cheers, > > /Barry > > > > > > Barry DINGLE > > Telecommunications Consultant > > Fellow of the University of Melbourne > > Chair - ACIF Customer Equipment and Cable Reference Panel (CECRP) > > barry.dingle@bigfoot.com.au > > Mob: +61 (0)41 911 7578 > > Fixed: +61 (0)3 9725 3937 > > ToIP: barry.dingle@trysip.ingate.com > > > > > > > > Tschofenig, Hannes wrote: > > hi all, > > > > please find an update of the 'Requirements for Emergency Context > > Resolution with Internet Technologies' draft at: > > http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-00.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 Tue Sep 06 10:03:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECe3B-0005LC-Ca; Tue, 06 Sep 2005 10:03:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECe38-0005Ky-Qd for ecrit@megatron.ietf.org; Tue, 06 Sep 2005 10:03:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28564 for ; Tue, 6 Sep 2005 10:03:45 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECe67-00065v-J9 for ecrit@ietf.org; Tue, 06 Sep 2005 10:06:52 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 06 Sep 2005 07:03:37 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,172,1122879600"; d="scan'208"; a="8597551:sNHT24964084" 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 j86E2lRP018202; Tue, 6 Sep 2005 10:03:32 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Sep 2005 10:03:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Updated Draft: "Requirements forEmergencyContext Resolution with Internet Technologies" Date: Tue, 6 Sep 2005 10:03:23 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E382E64E@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Updated Draft: "Requirements forEmergencyContext Resolution with Internet Technologies" Thread-Index: AcWx1R5J6nJnjfDBRyGwpDXKxW9jBgAIfM7wAAcelWAAAMnVUAABAWlWADQhUDA= From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "Tschofenig, Hannes" , "Barry Dingle" X-OriginalArrivalTime: 06 Sep 2005 14:03:24.0939 (UTC) FILETIME=[BF7965B0:01C5B2EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I have had a similar discussion on another thread where even the term = "network" can be taken two different ways, depending on whether you are = thinking data network or voice network. I support the notion of = avoiding using address without clear context. My suggestion: IP [network-layer] address SIP [application-layer] address civil address geo address location (civil/geo) address Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Stastny Richard > Sent: Monday, September 05, 2005 9:23 AM > To: Tschofenig, Hannes; Barry Dingle > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Updated Draft: "Requirements=20 > forEmergencyContext Resolution with Internet Technologies" >=20 > To be precise: I have a problem > > with the term 'address' (that is also defined in the terminology=20 > > section) > =20 > it should be location address (or something like that) to=20 > distuingish it from emergency address and network address > =20 > >or with the usage of address in the definition of 'emergency=20 > address'? >=20 > The term address here is ambiguos: so either we leave network=20 > address and define it in the definitions, or we come up with=20 > something else >=20 > -richard >=20 >=20 > ________________________________ >=20 > Von: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > Gesendet: Mo 05.09.2005 14:56 > An: Stastny Richard; Barry Dingle > Cc: ecrit@ietf.org > Betreff: AW: [Ecrit] Updated Draft: "Requirements for=20 > EmergencyContext Resolution with Internet Technologies" >=20 >=20 >=20 > hi richard, >=20 > do you have a problem with the term 'emergency address' (as=20 > it is defined or used in the document) or with the term=20 > 'address' (that is also defined in the terminology section)=20 > or with the usage of address in the definition of 'emergency address'? >=20 > ciao > hannes >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Gesendet: Montag, 5. September 2005 14:24 > > An: Tschofenig, Hannes; Barry Dingle > > Cc: ecrit@ietf.org > > Betreff: RE: [Ecrit] Updated Draft: "Requirements for=20 > EmergencyContext=20 > > Resolution with Internet Technologies" > > > > > > Hi all, > > > > you cannot use the term address plain > > > > I still have a problem with the term address in the document. > > > > Address is used in 5 different contexts in the document: > > > > Address =3D location address (civil or geo) Emergency address=20 > =3D the SIP=20 > > URI of the (network) address ... > > Network address =3D now reduced to address Authors address ;-) > > > > I propose for the avoidance of ambiguity even if it is=20 > clear what the=20 > > context is, always to use the term address with the proper=20 > context in=20 > > front e.g. location address > > > > -richard > > > > > > Richard Stastny > > OeFEG > > tel:+43 664 420 4100 > > enum:+43 780 203 211 > > callto://fordprefect > > http://voipandenum.blogspot.com > >=20 > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf Of > > > Tschofenig, Hannes > > > Sent: Monday, September 05, 2005 10:53 AM > > > To: Barry Dingle > > > Cc: ecrit@ietf.org; Tracey Annear > > > Subject: AW: [Ecrit] Updated Draft: "Requirements for > > EmergencyContext > > > Resolution with Internet Technologies" > > > > > > hi barry, > > > > > > thanks for the comment. i have added it to the issue tracker. > > > > > > here is the suggested change: > > > > > > from: > > > > > > " > > > emergency address: The sip:uri, sips:uri, or tel:uri > > which represents > > > the network address of the PSAP useful for the=20 > completion of a > > > VoIP emergency call. > > > " > > > > > > to: > > > > > > " > > > emergency address: The sip:uri, sips:uri, or tel:uri > > which represents > > > the address of the PSAP useful for the completion of > > an emergency > > > call. > > > " > > > > > > i also changed 'network address' to 'address' since the > > term "network > > > address" should not be misunderstood as network layer > > address (which would > > > then be wrong). > > > > > > ciao > > > hannes > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: Barry Dingle [mailto:barry.dingle@bigfoot.com.au] > > > Gesendet: Montag, 5. September 2005 06:48 > > > An: Tschofenig, Hannes > > > Cc: ecrit@ietf.org; Tracey Annear > > > Betreff: Re: [Ecrit] Updated Draft: "Requirements for > > Emergency Context > > > Resolution with Internet Technologies" > > > > > > > > > Hannes, > > > > > > The draft is looking very good. > > > > > > One small comment - in Section 2 , the definition of > > "emergency address" > > > should be more general than 'a VoIP emergency call' because > > this document > > > relates to multiple services. I suggest that the last part of the=20 > > > definition read: " ....... which represents the network > > address of the > > > PSAP useful for the completion of an emergency call." > > > > > > Alternatively, it could be made more specific with the > > words " ....... > > > which represents the network address of the PSAP useful for > > the completion > > > of a VoIP or other general Internet multimedia emergency > > call." (Words > > > taken from the Abstract.) > > > > > > I prefer the first option. > > > > > > Cheers, > > > /Barry > > > > > > > > > Barry DINGLE > > > Telecommunications Consultant > > > Fellow of the University of Melbourne Chair - ACIF Customer=20 > > > Equipment and Cable Reference Panel (CECRP) > > > barry.dingle@bigfoot.com.au > > > Mob: +61 (0)41 911 7578 > > > Fixed: +61 (0)3 9725 3937 > > > ToIP: barry.dingle@trysip.ingate.com > > > > > > > > > > > > Tschofenig, Hannes wrote: > > > hi all, > > > > > > please find an update of the 'Requirements for Emergency Context=20 > > > Resolution with Internet Technologies' draft at: > > >=20 > http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-00.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 > > >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 06 10:13:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECeCU-0007Ig-8u; Tue, 06 Sep 2005 10:13:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECeCS-0007GL-Eh for ecrit@megatron.ietf.org; Tue, 06 Sep 2005 10:13:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29638 for ; Tue, 6 Sep 2005 10:13:22 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ECeFQ-0006Ma-Vd for ecrit@ietf.org; Tue, 06 Sep 2005 10:16:29 -0400 Content-class: urn:content-classes:message Subject: RE: [Ecrit] Updated Draft: "Requirements forEmergencyContext Resolution with Internet Technologies" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Sep 2005 16:16:50 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B210D@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Ecrit] Updated Draft: "Requirements forEmergencyContext Resolution with Internet Technologies" Thread-Index: AcWx1R5J6nJnjfDBRyGwpDXKxW9jBgAIfM7wAAcelWAAAMnVUAABAWlWADQhUDAAAJUpMA== From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "Tschofenig, Hannes" , "Barry Dingle" X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 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 Works with me -richard > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Tuesday, September 06, 2005 4:03 PM > To: Stastny Richard; Tschofenig, Hannes; Barry Dingle > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Updated Draft: "Requirements forEmergencyContext > Resolution with Internet Technologies" >=20 > I have had a similar discussion on another thread where even the term > "network" can be taken two different ways, depending on whether you = are > thinking data network or voice network. I support the notion of = avoiding > using address without clear context. My suggestion: >=20 > IP [network-layer] address > SIP [application-layer] address > civil address > geo address > location (civil/geo) address >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of Stastny Richard > > Sent: Monday, September 05, 2005 9:23 AM > > To: Tschofenig, Hannes; Barry Dingle > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] Updated Draft: "Requirements > > forEmergencyContext Resolution with Internet Technologies" > > > > To be precise: I have a problem > > > with the term 'address' (that is also defined in the terminology > > > section) > > > > it should be location address (or something like that) to > > distuingish it from emergency address and network address > > > > >or with the usage of address in the definition of 'emergency > > address'? > > > > The term address here is ambiguos: so either we leave network > > address and define it in the definitions, or we come up with > > something else > > > > -richard > > > > > > ________________________________ > > > > Von: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > > Gesendet: Mo 05.09.2005 14:56 > > An: Stastny Richard; Barry Dingle > > Cc: ecrit@ietf.org > > Betreff: AW: [Ecrit] Updated Draft: "Requirements for > > EmergencyContext Resolution with Internet Technologies" > > > > > > > > hi richard, > > > > do you have a problem with the term 'emergency address' (as > > it is defined or used in the document) or with the term > > 'address' (that is also defined in the terminology section) > > or with the usage of address in the definition of 'emergency = address'? > > > > ciao > > hannes > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Gesendet: Montag, 5. September 2005 14:24 > > > An: Tschofenig, Hannes; Barry Dingle > > > Cc: ecrit@ietf.org > > > Betreff: RE: [Ecrit] Updated Draft: "Requirements for > > EmergencyContext > > > Resolution with Internet Technologies" > > > > > > > > > Hi all, > > > > > > you cannot use the term address plain > > > > > > I still have a problem with the term address in the document. > > > > > > Address is used in 5 different contexts in the document: > > > > > > Address =3D location address (civil or geo) Emergency address > > =3D the SIP > > > URI of the (network) address ... > > > Network address =3D now reduced to address Authors address ;-) > > > > > > I propose for the avoidance of ambiguity even if it is > > clear what the > > > context is, always to use the term address with the proper > > context in > > > front e.g. location address > > > > > > -richard > > > > > > > > > Richard Stastny > > > OeFEG > > > tel:+43 664 420 4100 > > > enum:+43 780 203 211 > > > callto://fordprefect > > > http://voipandenum.blogspot.com > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf Of > > > > Tschofenig, Hannes > > > > Sent: Monday, September 05, 2005 10:53 AM > > > > To: Barry Dingle > > > > Cc: ecrit@ietf.org; Tracey Annear > > > > Subject: AW: [Ecrit] Updated Draft: "Requirements for > > > EmergencyContext > > > > Resolution with Internet Technologies" > > > > > > > > hi barry, > > > > > > > > thanks for the comment. i have added it to the issue tracker. > > > > > > > > here is the suggested change: > > > > > > > > from: > > > > > > > > " > > > > emergency address: The sip:uri, sips:uri, or tel:uri > > > which represents > > > > the network address of the PSAP useful for the > > completion of a > > > > VoIP emergency call. > > > > " > > > > > > > > to: > > > > > > > > " > > > > emergency address: The sip:uri, sips:uri, or tel:uri > > > which represents > > > > the address of the PSAP useful for the completion of > > > an emergency > > > > call. > > > > " > > > > > > > > i also changed 'network address' to 'address' since the > > > term "network > > > > address" should not be misunderstood as network layer > > > address (which would > > > > then be wrong). > > > > > > > > ciao > > > > hannes > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: Barry Dingle [mailto:barry.dingle@bigfoot.com.au] > > > > Gesendet: Montag, 5. September 2005 06:48 > > > > An: Tschofenig, Hannes > > > > Cc: ecrit@ietf.org; Tracey Annear > > > > Betreff: Re: [Ecrit] Updated Draft: "Requirements for > > > Emergency Context > > > > Resolution with Internet Technologies" > > > > > > > > > > > > Hannes, > > > > > > > > The draft is looking very good. > > > > > > > > One small comment - in Section 2 , the definition of > > > "emergency address" > > > > should be more general than 'a VoIP emergency call' because > > > this document > > > > relates to multiple services. I suggest that the last part of = the > > > > definition read: " ....... which represents the network > > > address of the > > > > PSAP useful for the completion of an emergency call." > > > > > > > > Alternatively, it could be made more specific with the > > > words " ....... > > > > which represents the network address of the PSAP useful for > > > the completion > > > > of a VoIP or other general Internet multimedia emergency > > > call." (Words > > > > taken from the Abstract.) > > > > > > > > I prefer the first option. > > > > > > > > Cheers, > > > > /Barry > > > > > > > > > > > > Barry DINGLE > > > > Telecommunications Consultant > > > > Fellow of the University of Melbourne Chair - ACIF Customer > > > > Equipment and Cable Reference Panel (CECRP) > > > > barry.dingle@bigfoot.com.au > > > > Mob: +61 (0)41 911 7578 > > > > Fixed: +61 (0)3 9725 3937 > > > > ToIP: barry.dingle@trysip.ingate.com > > > > > > > > > > > > > > > > Tschofenig, Hannes wrote: > > > > hi all, > > > > > > > > please find an update of the 'Requirements for Emergency Context > > > > Resolution with Internet Technologies' draft at: > > > > > > http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-00.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 > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 06 10:19:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECeIH-0000C5-9g; Tue, 06 Sep 2005 10:19:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECeIF-0000C0-T0 for ecrit@megatron.ietf.org; Tue, 06 Sep 2005 10:19:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00141 for ; Tue, 6 Sep 2005 10:19:22 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECeLE-0006W6-4m for ecrit@ietf.org; Tue, 06 Sep 2005 10:22:29 -0400 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 j86EIqWk016661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Sep 2005 10:18:54 -0400 (EDT) Message-ID: <431DA535.4040709@cs.columbia.edu> Date: Tue, 06 Sep 2005 10:18:29 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Ecrit] Updated Draft: "Requirements forEmergencyContext Resolution with Internet Technologies" References: <32755D354E6B65498C3BD9FD496C7D461B210D@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B210D@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_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 >>civil address >>geo address Note that we now use civic, not civil, as it seems more common. Also, I'd prefer to avoid the term address where possible - i.e.., geographic location and civic location. This also conforms to conventions used in other (geopriv) drafts. For SIP, in many cases, it is more precise to say something like "the resolution steps returns a SIP URI". The only context where 'address' is really needed is 'IP address'. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 06 13:59:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EChjS-0002dX-99; Tue, 06 Sep 2005 13:59:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EChjR-0002dP-Dq for ecrit@megatron.ietf.org; Tue, 06 Sep 2005 13:59:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10453 for ; Tue, 6 Sep 2005 13:59:40 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EChmR-0003wl-Af for ecrit@ietf.org; Tue, 06 Sep 2005 14:02:48 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j86HxUuo027123 for ; Tue, 6 Sep 2005 19:59:30 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j86HxUEM026567 for ; Tue, 6 Sep 2005 19:59:30 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 6 Sep 2005 19:59:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Sep 2005 19:59:29 +0200 Message-ID: Thread-Topic: Emergency Context Routing of Internet Technologies - Architecture Considerations Thread-Index: AcWzDLiV1AdT9CjESNKUKI1twQLfgw== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 06 Sep 2005 17:59:30.0031 (UTC) FILETIME=[BA86E7F0:01C5B30C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Emergency Context Routing of Internet Technologies - Architecture Considerations X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 james and andy just submitted a draft with the following content: " This document discusses architectural considerations for emergency=20 context routing of Internet technologies. The purpose of this=20 document is to provide a systemic view of emergency context routing, discuss unresolved issues, and explain the relationship of some of=20 the proposals to these issues, while discussing potential directions=20 that might be still be necessary for the working group to=20 investigate. =20 " i have copied the draft to http://www.ietf-ecrit.org/cache/draft-polk-newton-ecrit-arch-considerati ons-00.txt thanks to both of them for touching a number of interesting discussion topics.=20 ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 06 18:01:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EClVp-0008ND-Cn; Tue, 06 Sep 2005 18:01:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EClVn-0008MX-6v for ecrit@megatron.ietf.org; Tue, 06 Sep 2005 18:01:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03140 for ; Tue, 6 Sep 2005 18:01:48 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EClYp-0004uC-A3 for ecrit@ietf.org; Tue, 06 Sep 2005 18:05:00 -0400 Content-class: urn:content-classes:message Subject: Re: [Ecrit] Emergency Context Routing of Internet Technologies -Architecture Considerations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Sep 2005 00:05:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C44D4@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Emergency Context Routing of Internet Technologies -Architecture Considerations Thread-Index: AcWzDLiV1AdT9CjESNKUKI1twQLfgwAIN/yf From: "Stastny Richard" To: "Tschofenig, Hannes" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James and Andy, =20 thank you very much for putting together this extremly useful and well structured document. =20 It will be very helpful for the future work in ECRIT, but also for introductory reading for a broader audience. It may also serve as input for tutorials on this issue ;-) =20 Of course I was not able yet to study the document in detail to provide feedback (will do ;-) =20 The only subject I am missing sofar is location validation e.g via a MSAG. This should also be included. =20 I may also mention location authentication and eventually=20 a VESA registry =20 best regards =20 -richard ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von Tschofenig, Hannes Gesendet: Di 06.09.2005 19:59 An: ecrit@ietf.org Betreff: [Ecrit] Emergency Context Routing of Internet Technologies = -Architecture Considerations hi all, james and andy just submitted a draft with the following content: " This document discusses architectural considerations for emergency context routing of Internet technologies. The purpose of this document is to provide a systemic view of emergency context routing, discuss unresolved issues, and explain the relationship of some of the proposals to these issues, while discussing potential directions that might be still be necessary for the working group to investigate.=20 " i have copied the draft to http://www.ietf-ecrit.org/cache/draft-polk-newton-ecrit-arch-considerati ons-00.txt thanks to both of them for touching a number of interesting discussion topics. 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 Tue Sep 06 19:19:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECmir-0000dW-2s; Tue, 06 Sep 2005 19:19:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECmGS-0001xa-J1; Tue, 06 Sep 2005 18:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06764; Tue, 6 Sep 2005 18:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECmJU-00068J-S9; Tue, 06 Sep 2005 18:53:13 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ECmGQ-0001DK-8g; Tue, 06 Sep 2005 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 06 Sep 2005 18:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-Mailman-Approved-At: Tue, 06 Sep 2005 19:19:23 -0400 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-requirements-00.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Requirements for Emergency Context Resolution with Internet Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-ietf-ecrit-requirements-00.txt Pages : 26 Date : 2005-9-6 This document enumerates requirements for emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-requirements-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-9-6162553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-6162553.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Tue Sep 06 19:20:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECmjR-0001eQ-E9; Tue, 06 Sep 2005 19:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECmjQ-0001dY-1K for ecrit@megatron.ietf.org; Tue, 06 Sep 2005 19:20:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14980 for ; Tue, 6 Sep 2005 19:19:57 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECmmT-0000wM-0l for ecrit@ietf.org; Tue, 06 Sep 2005 19:23:10 -0400 Received: from [10.0.1.5] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 06 Sep 2005 19:19:56 -0400 id 000C7E8F.431E241D.00007284 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C44D4@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C44D4@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <49E0FB6C-DCBE-4F75-A294-A89CBCC516C4@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Emergency Context Routing of Internet Technologies -Architecture Considerations Date: Tue, 6 Sep 2005 19:19:53 -0400 To: Stastny Richard X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 6, 2005, at 6:05 PM, Stastny Richard wrote: > thank you very much for putting together this extremly useful and > well structured document. Thanks. > The only subject I am missing sofar is location validation > e.g via a MSAG. This should also be included. Excellent point! I guess we just overlooked this issue, but it should be in the draft. > I may also mention location authentication and eventually > a VESA registry Location authentication is a topic of debate within GEOPRIV at the moment. But I see no reason not to touch on its issues in this document. And now for a simple question, what is a VESA registry? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 06 19:53:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECnGI-0003Wj-5n; Tue, 06 Sep 2005 19:53:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECnGG-0003W1-Lm for ecrit@megatron.ietf.org; Tue, 06 Sep 2005 19:53:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16621 for ; Tue, 6 Sep 2005 19:53:55 -0400 (EDT) Message-Id: <200509062353.TAA16621@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECnJK-0001tj-PC for ecrit@ietf.org; Tue, 06 Sep 2005 19:57:07 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.50) id 1ECnFw-0007oU-Kw; Tue, 06 Sep 2005 18:53:37 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Stastny Richard'" Subject: RE: [Ecrit] Emergency Context Routing of Internet Technologies-Architecture Considerations Date: Tue, 6 Sep 2005 19:52:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWzOZ95k9Z+fcGBQ9aORQLVUqR9mgAA3odg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <49E0FB6C-DCBE-4F75-A294-A89CBCC516C4@hxr.us> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org >And now for a simple question, what is a VESA registry? Valid Emergency Services Authority It's a term we coined in the NENA "i2" work for the certificate authority that issues x.509 certs for entities in the emergency calling system so that we could deploy TLS on the interfaces. Since the emergency service system in nearly every country is highly structured, it's something that at the country level is pretty straightforward to organize. For ecrit, I think we want a similar idea, with the obvious problem of the root CA, which would have to be international in scope. It wouldn't cover end users, enterprises, or possibly even carriers; just the emergency services entities. It gives you the start of a trust chain for things like the author of the mapping database, and the identity of the called party (PSAP). Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 06 20:04:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECnQ6-0006lP-4O; Tue, 06 Sep 2005 20:04:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECnQ4-0006lK-Mf for ecrit@megatron.ietf.org; Tue, 06 Sep 2005 20:04:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17007 for ; Tue, 6 Sep 2005 20:04:03 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECnT8-000285-17 for ecrit@ietf.org; Tue, 06 Sep 2005 20:07:15 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Sep 2005 19:03:42 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 06 Sep 2005 19:03:41 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Sep 2005 19:03:41 -0500 Message-ID: From: "Winterbottom, James" To: Date: Tue, 6 Sep 2005 19:03:38 -0500 Subject: RE: [Ecrit] Emergency Context Routing of Internet Technologies -Architecture Considerations MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 07 Sep 2005 00:03:41.0091 (UTC) FILETIME=[9AC60F30:01C5B33F] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Emergency Context Routing of Internet Technologies -Architecture Considerations Thread-Index: AcWzDLiV1AdT9CjESNKUKI1twQLfgwALRIxg X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 Hi Andy and James, In general a pretty good read. A few comments and questions below. The definitions you have between ISP and ASP seem to make the ASP a subset of ISP functionality, which I don't think is always the case. Furthermore I think that your definition of IAP is more in line with what I have considered to be an ISP. I think, that there is a Physical Access Provider (PAP if you like) that provides you with access to a network, an Internet service provider (ISP) that defines an associated domain that may be accessed from the physical access network, and an ASP whose services can be accessed from the domain. This is also more inline with how physical networks are actually built, and avoids the super-set definitions that are apparent in your document. Conversion or LCMS Mapping One of the most common problems that results in conversion being necessary is that the information is not provided in the format required by the recipient. If location is stored at the source in a variety of forms, then two clear options exist for reducing the need for conversion. 1) provide all forms when ever asked for location 2) provide a reference to the source, and allow the recipient to request the type that they need. LCMS Mapping Can you clarify something for me here, are you really expecting the SIP URI of the local PSAP to be provided directly to an end-point? This is certainly something that is likely to cause large gasps within the NENA community, and is one of the reasons for the ESRP functionality. Rerouting/Transfer could also address things like overflow, load sharing etc, which are also potential functions of an ESRP. Cheers James=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 06 21:11:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECoTV-00043t-2G; Tue, 06 Sep 2005 21:11:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECoTT-00043o-36 for ecrit@megatron.ietf.org; Tue, 06 Sep 2005 21:11:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18812 for ; Tue, 6 Sep 2005 21:11:37 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECoWV-0003PN-R7 for ecrit@ietf.org; Tue, 06 Sep 2005 21:14:50 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 06 Sep 2005 18:11:27 -0700 X-IronPort-AV: i="3.96,173,1122879600"; d="scan'208"; a="339327081:sNHT34464348" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j871AdKk011903; Tue, 6 Sep 2005 18:11:18 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Sep 2005 18:11:22 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.146.0]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Sep 2005 18:11:21 -0700 Message-Id: <4.3.2.7.2.20050906194147.02d44fa8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Sep 2005 20:11:20 -0500 To: "Winterbottom, James" , From: "James M. Polk" Subject: RE: [Ecrit] Emergency Context Routing of Internet Technologies -Architecture Considerations In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 07 Sep 2005 01:11:21.0847 (UTC) FILETIME=[0F2C4070:01C5B349] X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 07:03 PM 9/6/2005 -0500, Winterbottom, James wrote: >Hi Andy and James, > >In general a pretty good read. Thanks >A few comments and questions below. > >The definitions you have between ISP and ASP seem to make the ASP a >subset of ISP functionality, which I don't think is always the case. no, we didn't want that, but we wanted to define it as being a Service Provider for "an application" like voice, which differs from the more general ISP which is (generally) all data protocols, yet can be a separate company/organization. An ASP is more focused. >Furthermore I think that your definition of IAP is more in line with >what I have considered to be an ISP. To be clear, a "Vonage" is a ASP (they do voice) a "Comcast" or an "AOL" is an ISP - which isn't generally limited to an application or technology, but there typically are no guarantees other than best effort connectivity Comcast in the above example *can* also be the access provider because they own the HFC cable connectiving one to the Internet, but this does not have to be the case. >I think, that there is a Physical Access Provider (PAP if you like) that >provides you with access to a network, an Internet service provider >(ISP) that defines an associated domain that may be accessed from the >physical access network, and an ASP whose services can be accessed from >the domain. yeah - we just use IAP, ISP and ASP for your 3 terms above (in order BTW) >This is also more inline with how physical networks are >actually built, and avoids the super-set definitions that are apparent >in your document. again, we didn't intend to mean any subsets were involved, just separations, as each of the 3 layers could easily be 3 separate companies/organizations >Conversion or LCMS Mapping >One of the most common problems that results in conversion being >necessary is that the information is not provided in the format required >by the recipient. If location is stored at the source in a variety of >forms, then two clear options exist for reducing the need for >conversion. >1) provide all forms when ever asked for location >2) provide a reference to the source, and allow the recipient to request >the type that they need. #1 likely will not always be available to the endpoint, and the endpoint will likely get stuck with what the IAP gives them (ex RFC3825). #2 is also dependent on the sender of the information so, there is a need for format conversion sometimes we didn't mean all the time, just when it is important or necessary for example, with NENA's i2, there has been a recent movement to mandate the civic format as the only one sent to the ESRP. If the UA doesn't have this format, it may know how to convert GPS to civic ahead of time to send to the ESRP when the UA makes the 911 call. This conversion function will likely exist for many other reasons (outside of emergency calling). >LCMS Mapping >Can you clarify something for me here, are you really expecting the SIP >URI of the local PSAP to be provided directly to an end-point? This is one option, and one that is less error prone - as it doesn't occur during call set-up. Or the PSAP URI is provided to the Cable/DSL modem that has a DHCP server and client in it, to send to any requesting IP device within that dwelling when it boots up. This could also work for Commercial, SMBs and enterprise networks. This is seperable from Location, which we believe needs to be sent to the endpoint also. The URI staleness factor can be addressed by the DHCP refresh function, or can be pushed to endpoints whenever the server wants to. >This is >certainly something that is likely to cause large gasps within the NENA >community, and is one of the reasons for the ESRP functionality. ultimately we want the INVITE to get to the right PSAP. Mapping can be done before a user calls 911/112 or during the call set-up. This section of the document suggests how it can be done prior to a phone calling 911. >Rerouting/Transfer could also address things like overflow, load sharing >etc, which are also potential functions of an ESRP. I agree. Do you want more text stating these additional reasons/functions? >Cheers >James >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] > >_______________________________________________ >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 Tue Sep 06 22:58:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECq8W-0002H2-Jr; Tue, 06 Sep 2005 22:58:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECq8T-0002FG-G0 for ecrit@megatron.ietf.org; Tue, 06 Sep 2005 22:58:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23270 for ; Tue, 6 Sep 2005 22:58:03 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECqBX-0005oA-7v for ecrit@ietf.org; Tue, 06 Sep 2005 23:01:17 -0400 Received: from [10.0.1.5] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 06 Sep 2005 22:57:58 -0400 id 000C7E9B.431E5736.000014A4 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <71A0A77D-F9A3-466C-92AE-47096E69905B@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Emergency Context Routing of Internet Technologies-Architecture Considerations Date: Tue, 6 Sep 2005 22:57:56 -0400 To: br@brianrosen.net X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: 'Stastny Richard' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 6, 2005, at 7:52 PM, Brian Rosen wrote: > Valid Emergency Services Authority > > It's a term we coined in the NENA "i2" work for the certificate > authority > that issues x.509 certs for entities in the emergency calling > system so that > we could deploy TLS on the interfaces. Since the emergency service > system > in nearly every country is highly structured, it's something that > at the > country level is pretty straightforward to organize. For ecrit, I > think we > want a similar idea, with the obvious problem of the root CA, which > would > have to be international in scope. > > It wouldn't cover end users, enterprises, or possibly even > carriers; just > the emergency services entities. It gives you the start of a trust > chain > for things like the author of the mapping database, and the > identity of the > called party (PSAP). Well, I'd say the setup of international registries is certainly an issue and an architectural consideration that needs to be taken into account. But there is no need for just one root CA. Each country could just have their own. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 07 00:15:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECrHE-00012o-NN; Wed, 07 Sep 2005 00:11:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECrHD-00012Z-Eg for ecrit@megatron.ietf.org; Wed, 07 Sep 2005 00:11:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25849 for ; Wed, 7 Sep 2005 00:11:08 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECrKJ-0007SV-NQ for ecrit@ietf.org; Wed, 07 Sep 2005 00:14:24 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Sep 2005 23:11:00 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 06 Sep 2005 23:10:59 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Sep 2005 23:10:59 -0500 Message-ID: From: "Winterbottom, James" To: "James M. Polk" , Date: Tue, 6 Sep 2005 23:10:56 -0500 Subject: RE: [Ecrit] Emergency Context Routing of Internet Technologies -Architecture Considerations MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 07 Sep 2005 04:10:59.0067 (UTC) FILETIME=[26E584B0:01C5B362] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Emergency Context Routing of Internet Technologies -Architecture Considerations Thread-Index: AcWzSRORW/QtV3opSNq7TCAXPub+FQAEvdLQ X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Comments inline. > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Wednesday, 7 September 2005 11:11 AM > To: Winterbottom, James; ecrit@ietf.org > Subject: RE: [Ecrit] Emergency Context Routing of Internet Technologies - > Architecture Considerations >=20 > At 07:03 PM 9/6/2005 -0500, Winterbottom, James wrote: > >Hi Andy and James, > > > >In general a pretty good read. >=20 > Thanks >=20 > >A few comments and questions below. > > > >The definitions you have between ISP and ASP seem to make the ASP a > >subset of ISP functionality, which I don't think is always the case. >=20 > no, we didn't want that, but we wanted to define it as being a Service > Provider for "an application" like voice, which differs from the more > general ISP which is (generally) all data protocols, yet can be a separate > company/organization. >=20 > An ASP is more focused. >=20 > >Furthermore I think that your definition of IAP is more in line with > >what I have considered to be an ISP. >=20 > To be clear, a "Vonage" is a ASP (they do voice) >=20 > a "Comcast" or an "AOL" is an ISP - which isn't generally limited to an > application or technology, but there typically are no guarantees other > than > best effort connectivity >=20 > Comcast in the above example *can* also be the access provider because > they > own the HFC cable connectiving one to the Internet, but this does not have > to be the case. > >=20 > >I think, that there is a Physical Access Provider (PAP if you like) that > >provides you with access to a network, an Internet service provider > >(ISP) that defines an associated domain that may be accessed from the > >physical access network, and an ASP whose services can be accessed from > >the domain. >=20 > yeah - we just use IAP, ISP and ASP for your 3 terms above (in order BTW) >=20 > >This is also more inline with how physical networks are > >actually built, and avoids the super-set definitions that are apparent > >in your document. >=20 > again, we didn't intend to mean any subsets were involved, just > separations, as each of the 3 layers could easily be 3 separate > companies/organizations >=20 [AJW] Okay, but if you could make this more clear it would be good. Removing the I from IAP I think will help a lot here. Also removing the services provided by the ISP with the exception of giving you an IP address and access to the Internet. Anything else should be considered a service, and may or may not be tied to your ISP.=20 > >Conversion or LCMS Mapping > >One of the most common problems that results in conversion being > >necessary is that the information is not provided in the format required > >by the recipient. If location is stored at the source in a variety of > >forms, then two clear options exist for reducing the need for > >conversion. > >1) provide all forms when ever asked for location > >2) provide a reference to the source, and allow the recipient to request > >the type that they need. >=20 > #1 likely will not always be available to the endpoint, and the endpoint > will likely get stuck with what the IAP gives them (ex RFC3825). > #2 is also dependent on the sender of the information > [AJW] My point with #2 is that allowing the recipient to ask means that the sender does not need to presuppose. So as an end--point, rather than requesting option 123, and whatever the civic option ends up being, I can just send a location URI, and the LCMS can ask for my location in the format that it wants. So while yes, there may be a restriction on what the sender provides, not making that assumption clearly has its advantages. =20 > so, there is a need for format conversion sometimes >=20 > we didn't mean all the time, just when it is important or necessary >=20 > for example, with NENA's i2, there has been a recent movement to mandate > the civic format as the only one sent to the ESRP. If the UA doesn't have > this format, it may know how to convert GPS to civic ahead of time to send > to the ESRP when the UA makes the 911 call. > [AJW] I am not sure that I agree with this statement. If the end-point only has one format, then that is the form it should send for i2, no conversion is wanted, as there is no way to specify that this has occurred over the VE2 interface to the PSAP. Also i2 has a VPC, which is more like the LCMS. The ESRP is like a combination of ESGW and SR. > This conversion function will likely exist for many other reasons (outside > of emergency calling). >=20 >=20 > >LCMS Mapping > >Can you clarify something for me here, are you really expecting the SIP > >URI of the local PSAP to be provided directly to an end-point? >=20 > This is one option, and one that is less error prone - as it doesn't occur > during call set-up. >=20 [AJW] I think that this will not work well for mobile devices, and by the time we have RFCs and implementations for much of this stuff, I fully expect a significant proportion of IP devices to be mobile, so solutions need to factor this in. I would prefer to see a solution that build once now, than something that will need significant overhauling to accommodate a new class of access device. Why not just have one solution that will accommodate all classes of access device, and thereby simplifying the plethora of potential solutions. Note that NENA i2 takes this approach by performing the PSAP routing functionality in real time with the call setup, and not by bootstrapping. The result is that while NENA do not come out and say that i2 supports mobile devices, the fact is that it is capable of supporting mobile devices now. > Or the PSAP URI is provided to the Cable/DSL modem that has a DHCP server > and client in it, to send to any requesting IP device within that dwelling > when it boots up. This could also work for Commercial, SMBs and enterprise > networks. >=20 > This is seperable from Location, which we believe needs to be sent to the > endpoint also. >=20 > The URI staleness factor can be addressed by the DHCP refresh function, or > can be pushed to endpoints whenever the server wants to. >=20 > >This is > >certainly something that is likely to cause large gasps within the NENA > >community, and is one of the reasons for the ESRP functionality. >=20 > ultimately we want the INVITE to get to the right PSAP. Mapping can be > done > before a user calls 911/112 or during the call set-up. This section of the > document suggests how it can be done prior to a phone calling 911. [AJW] I think that this approach is at odds with NENA, which does not want every Tom, Dick and Harry having the ultimate address of the PSAP. I tend to agree with the NENA approach. It may be prudent to provide the address of the ESRP, but an ESRP is likely to service a number of PSAPs. This gives the flexibility within the emergency services network to determine how internal routing is performed, without revealing its internals to the rest of the world. >=20 > >Rerouting/Transfer could also address things like overflow, load sharing > >etc, which are also potential functions of an ESRP. >=20 > I agree. Do you want more text stating these additional reasons/functions? >=20 [AJW] I think that more statements here would be good, so that these functions can be described. If you still have access to the NENA website, Nadine Abbott put together a good set of functions that an ESRP might perform. Cheers James ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 07 03:13:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECu7M-0007Zf-Gs; Wed, 07 Sep 2005 03:13:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECu7K-0007Za-Ch for ecrit@megatron.ietf.org; Wed, 07 Sep 2005 03:13:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01836 for ; Wed, 7 Sep 2005 03:13:09 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECuAS-0003We-6t for ecrit@ietf.org; Wed, 07 Sep 2005 03:16:24 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j877D8o6003754 for ; Wed, 7 Sep 2005 09:13:08 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j877D8xI002560 for ; Wed, 7 Sep 2005 09:13:08 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Sep 2005 09:13:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5B37B.983F8297" Date: Wed, 7 Sep 2005 09:13:06 +0200 Message-ID: X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-ietf-ecrit-requirements-00.txt Thread-Index: AcWzN6uprPNN6Oi5SgKCvp0cFwgLjAAQ+Syw From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 07 Sep 2005 07:13:06.0954 (UTC) FILETIME=[986CBEA0:01C5B37B] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: [Ecrit] WG: I-D ACTION:draft-ietf-ecrit-requirements-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5B37B.983F8297 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable fyi, -----Urspr=FCngliche Nachricht----- Von: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] Im Auftrag von = Internet-Drafts@ietf.org Gesendet: Mittwoch, 7. September 2005 00:50 An: i-d-announce@ietf.org Cc: ecrit@ietf.org Betreff: I-D ACTION:draft-ietf-ecrit-requirements-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Emergency Context Resolution with = Internet Technologies Working Group of the IETF. Title : Requirements for Emergency Context Resolution with Internet = Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-ietf-ecrit-requirements-00.txt Pages : 26 Date : 2005-9-6 =09 This document enumerates requirements for emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-requirements-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C5B37B.983F8297 Content-Type: application/octet-stream; name="draft-ietf-ecrit-requirements-00.URL" Content-Description: draft-ietf-ecrit-requirements-00.URL Content-Disposition: attachment; filename="draft-ietf-ecrit-requirements-00.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLWVjcml0LXJlcXVpcmVtZW50cy0wMC50eHQNCg== ------_=_NextPart_001_01C5B37B.983F8297 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C5B37B.983F8297-- From ecrit-bounces@ietf.org Wed Sep 07 03:40:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECuXW-0004J2-KB; Wed, 07 Sep 2005 03:40:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECuXV-0004Ix-44 for ecrit@megatron.ietf.org; Wed, 07 Sep 2005 03:40:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02745 for ; Wed, 7 Sep 2005 03:40:11 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ECuac-0004DE-EG for ecrit@ietf.org; Wed, 07 Sep 2005 03:43:27 -0400 Content-class: urn:content-classes:message Subject: Re: [Ecrit] Emergency Context Routing of Internet Technologies-Architecture Considerations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Sep 2005 09:43:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C44D5@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Emergency Context Routing of Internet Technologies-Architecture Considerations Thread-Index: AcWzScquJcu8+xNbQm6zQ4QePleqJgANVn04 From: "Stastny Richard" To: "James M. Polk" , "Winterbottom, James" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org >for example, with NENA's i2, there has been a recent movement to = mandate >the civic format as the only one sent to the ESRP.=20 =20 This cannot be =20 >If the UA doesn't have >this format, it may know how to convert GPS to civic ahead of time to = send >to the ESRP when the UA makes the 911 call. I wonder, I thought we had this discussion already: =20 A UA cannot always provide a civic location anyway, e.g. on a lake, at sea, in the montains or in a desert. =20 As a PSAP I want to get the original information anyway and I also would like to convert geo to civic by myself 1. it is a no-brainer 2. I know what DB I am using, so I can trust it =20 -richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 07 03:51:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECui5-00066L-Hw; Wed, 07 Sep 2005 03:51:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECui4-000666-JU for ecrit@megatron.ietf.org; Wed, 07 Sep 2005 03:51:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03156 for ; Wed, 7 Sep 2005 03:51:07 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ECulC-0004XN-WB for ecrit@ietf.org; Wed, 07 Sep 2005 03:54:23 -0400 Content-class: urn:content-classes:message Subject: Re: [Ecrit] Emergency Context Routing of Internet Technologies-Architecture Considerations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Sep 2005 09:54:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C44D6@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Emergency Context Routing of Internet Technologies-Architecture Considerations Thread-Index: AcWzSRORW/QtV3opSNq7TCAXPub+FQAEvdLQAAkGorc= From: "Stastny Richard" To: "Winterbottom, James" , "James M. Polk" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org >[AJW] >I think that this approach is at odds with NENA, which does not want >every Tom, Dick and Harry having the ultimate address of the PSAP. I >tend to agree with the NENA approach. It may be prudent to provide the >address of the ESRP, but an ESRP is likely to service a number of = PSAPs. >This gives the flexibility within the emergency services network to >determine how internal routing is performed, without revealing its >internals to the rest of the world. Both approaches are valid and need to be supported. Basically it is a matter of the local authorities where the SIP URI for a given location points to. The ESRP is needed especially in the migration scenarios where you may point a whole country to one ESRP and do the whole mapping behind the scenes e.g. routing to an ESGW to access TDM PSAPs. I also cannot fully see the argument to provide Toms and Harrys not with the ultimate PSAP address, but the address of the ESRP instead. It is a single point of failure and may also be the easy focus of DoS attacks. This problem has to be solved anyway. -richard =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 07 08:02:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECyd5-0006ES-PT; Wed, 07 Sep 2005 08:02:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECyd3-0006EN-QK for ecrit@megatron.ietf.org; Wed, 07 Sep 2005 08:02:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14206 for ; Wed, 7 Sep 2005 08:02:13 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECygD-0003A8-F4 for ecrit@ietf.org; Wed, 07 Sep 2005 08:05:30 -0400 Received: from [10.0.1.5] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 07 Sep 2005 08:02:08 -0400 id 000C7E7D.431ED6C0.000075ED In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C44D6@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C44D6@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <23D715C8-CC23-4628-8B34-4214B0B4543D@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Emergency Context Routing of Internet Technologies-Architecture Considerations Date: Wed, 7 Sep 2005 08:02:06 -0400 To: Stastny Richard , ECRIT X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 7, 2005, at 3:54 AM, Stastny Richard wrote: >> [AJW] >> I think that this approach is at odds with NENA, which does not want >> every Tom, Dick and Harry having the ultimate address of the PSAP. I >> tend to agree with the NENA approach. It may be prudent to provide >> the >> address of the ESRP, but an ESRP is likely to service a number of >> PSAPs. >> This gives the flexibility within the emergency services network to >> determine how internal routing is performed, without revealing its >> internals to the rest of the world. >> > > Both approaches are valid and need to be supported. Basically > it is a matter of the local authorities where the SIP URI for > a given location points to. The ESRP is needed especially > in the migration scenarios where you may point a whole country > to one ESRP and do the whole mapping behind the scenes > e.g. routing to an ESGW to access TDM PSAPs. > > I also cannot fully see the argument to provide Toms and Harrys > not with the ultimate PSAP address, but the address of the ESRP > instead. It is a single point of failure and may also be the easy > focus > of DoS attacks. This problem has to be solved anyway. I agree with Richard on this. But I sense a recurring meta-issue here. Just how much information is to be considered publicly visible? Such as the PSAP URIs or the polygons of the PSAP coverage area... -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 07 08:16:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECyog-0000JG-GI; Wed, 07 Sep 2005 08:14:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECyof-0000J4-9u for ecrit@megatron.ietf.org; Wed, 07 Sep 2005 08:14:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15067 for ; Wed, 7 Sep 2005 08:14:12 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ECyrp-0003Wa-1F for ecrit@ietf.org; Wed, 07 Sep 2005 08:17:30 -0400 Content-class: urn:content-classes:message Subject: RE: [Ecrit] Emergency Context Routing of Internet Technologies-Architecture Considerations MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Sep 2005 14:17:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B211A@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Emergency Context Routing of Internet Technologies-Architecture Considerations Thread-Index: AcWzpIDllsf3HVJHRoyf9Fh1/LgeAQAAHrWQ From: "Stastny Richard" To: "Andrew Newton" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Andy writes: > I agree with Richard on this. But I sense a recurring meta-issue > here. Just how much information is to be considered publicly > visible? Such as the PSAP URIs or the polygons of the PSAP coverage > area... What is the problem with making the polygons publicly visible? Regarding the URIs: If you want the terminal to reach emergency services, you have to give them a URI. Providing them an indirect URI just shifts the problem, but does not solve it. There is a similar situation in ENUM: I want to peer on IP but do not want to give out the address, not to the public, but also not to the competitors - this is called a Catch 22 Providing security with information hiding is a bad idea: best example: cryptography Anybody trying to hide the algorithm failed - see Bruce Schneier - the only result is that the algorithm is not tested properly and therefore badly designed The secret is the key, not the algorithm -richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 07 09:49:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED0Ic-0005Bz-TW; Wed, 07 Sep 2005 09:49:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED0IY-0005Br-UQ for ecrit@megatron.ietf.org; Wed, 07 Sep 2005 09:49:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20228 for ; Wed, 7 Sep 2005 09:49:09 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED0Lh-0006B9-It for ecrit@ietf.org; Wed, 07 Sep 2005 09:52:28 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 07 Sep 2005 09:49:04 -0400 id 000C7E88.431EEFD0.00000B01 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B211A@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D461B211A@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0214234C-A2D5-45F6-AA78-351BB6F49739@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Emergency Context Routing of Internet Technologies-Architecture Considerations Date: Wed, 7 Sep 2005 09:49:02 -0400 To: Stastny Richard X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 7, 2005, at 8:17 AM, Stastny Richard wrote: > What is the problem with making the polygons publicly visible? It may be considered a security problem. Yes, trying to keep polygons out of sight is not a perfect or total security solution. But that doesn't mean you should make things easy for the bad actors. And if there is any one take away we should have learned from protocol design, it is that the perfect security solutions tend to be the ones that never get implemented. > Regarding the URIs: > If you want the terminal to reach emergency services, > you have to give them a URI. Providing them an indirect > URI just shifts the problem, but does not solve it. I agree. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 07 09:54:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED0O8-0006IG-PK; Wed, 07 Sep 2005 09:54:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED0O7-0006Hl-9G for ecrit@megatron.ietf.org; Wed, 07 Sep 2005 09:54:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20451 for ; Wed, 7 Sep 2005 09:54:53 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ED0RH-0006Iq-S3 for ecrit@ietf.org; Wed, 07 Sep 2005 09:58:13 -0400 Content-class: urn:content-classes:message Subject: RE: [Ecrit] Emergency Context Routing of Internet Technologies-Architecture Considerations MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Sep 2005 15:58:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B211D@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Emergency Context Routing of Internet Technologies-Architecture Considerations Thread-Index: AcWzs3CNM4iduo/2QQiFGP64Wm761wAADBtg From: "Stastny Richard" To: "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I still do not see why knowing the boundaries of a PSAP region poses a security problem at all. This is the same like knowing the boundaries of a district or state. Everybody can have access to this information (read-only). It is public knowledge anyway. Of course having R/W access is another issue, but this is not an ecrit problem Richard > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Wednesday, September 07, 2005 3:49 PM > To: Stastny Richard > Cc: ECRIT; Winterbottom, James; James M. Polk > Subject: Re: [Ecrit] Emergency Context Routing of Internet Technologies- > Architecture Considerations >=20 >=20 > On Sep 7, 2005, at 8:17 AM, Stastny Richard wrote: >=20 > > What is the problem with making the polygons publicly visible? >=20 > It may be considered a security problem. Yes, trying to keep > polygons out of sight is not a perfect or total security solution. > But that doesn't mean you should make things easy for the bad > actors. And if there is any one take away we should have learned > from protocol design, it is that the perfect security solutions tend > to be the ones that never get implemented. >=20 > > Regarding the URIs: > > If you want the terminal to reach emergency services, > > you have to give them a URI. Providing them an indirect > > URI just shifts the problem, but does not solve it. >=20 > I agree. >=20 > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 07 10:30:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED0we-00061t-TX; Wed, 07 Sep 2005 10:30:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED0wc-000617-TT for ecrit@megatron.ietf.org; Wed, 07 Sep 2005 10:30:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23335 for ; Wed, 7 Sep 2005 10:30:33 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED0zm-0007Gu-SX for ecrit@ietf.org; Wed, 07 Sep 2005 10:33:53 -0400 Received: from [160.39.251.85] (dyn-160-39-251-85.dyn.columbia.edu [160.39.251.85]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j87EUAVe024141 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 7 Sep 2005 10:30:15 -0400 (EDT) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B211D@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D461B211D@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <944F315E-6A26-4238-A400-4FACB4C75D1F@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Emergency Context Routing of Internet Technologies-Architecture Considerations Date: Wed, 7 Sep 2005 10:30:27 -0400 To: "Stastny Richard" X-Mailer: Apple Mail (2.733) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I agree with Richard. There is real cost in obscurity; as Richard points out, at least in the US, the information is essentially public anyway, so hiding this simply means that bugs won't be found, that systems are made more complicated and that there's more opportunity for various security consultants and contractors offering their snake- oil services to gauge PSAPs. We all pay the price for pseudo- security, even if it just confiscated nail clippers at the airport... I'm very afraid that this type of recommendation will be used to design closed, non-debuggable, expensive systems. Unless there is a strong engineering motivation that can be justified on technical grounds, we should not make such recommendations. On Sep 7, 2005, at 9:58 AM, Stastny Richard wrote: > I still do not see why knowing the boundaries > of a PSAP region poses a security problem at all. > > This is the same like knowing the boundaries of > a district or state. Everybody can have access > to this information (read-only). It is public > knowledge anyway. > > Of course having R/W access is another issue, > but this is not an ecrit problem > > Richard > > >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Wednesday, September 07, 2005 3:49 PM >> To: Stastny Richard >> Cc: ECRIT; Winterbottom, James; James M. Polk >> Subject: Re: [Ecrit] Emergency Context Routing of Internet >> > Technologies- > >> Architecture Considerations >> >> >> On Sep 7, 2005, at 8:17 AM, Stastny Richard wrote: >> >> >>> What is the problem with making the polygons publicly visible? >>> >> >> It may be considered a security problem. Yes, trying to keep >> polygons out of sight is not a perfect or total security solution. >> But that doesn't mean you should make things easy for the bad >> actors. And if there is any one take away we should have learned >> from protocol design, it is that the perfect security solutions tend >> to be the ones that never get implemented. >> >> >>> Regarding the URIs: >>> If you want the terminal to reach emergency services, >>> you have to give them a URI. Providing them an indirect >>> URI just shifts the problem, but does not solve it. >>> >> >> I agree. >> >> -andy >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 07 10:31:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED0xt-0006Fd-54; Wed, 07 Sep 2005 10:31:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED0xq-0006FR-UE for ecrit@megatron.ietf.org; Wed, 07 Sep 2005 10:31:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23413 for ; Wed, 7 Sep 2005 10:31:49 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED112-0007IT-Pr for ecrit@ietf.org; Wed, 07 Sep 2005 10:35:09 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 07 Sep 2005 07:31:41 -0700 X-IronPort-AV: i="3.96,176,1122879600"; d="scan'208"; a="339487108:sNHT31762916" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j87EVaKE028554; Wed, 7 Sep 2005 07:31:39 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Sep 2005 07:31:36 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Sep 2005 07:31:36 -0700 From: "Marc Linsner" To: "'Stastny Richard'" , "'Andrew Newton'" Subject: RE: [Ecrit] Emergency Context Routing of InternetTechnologies-Architecture Considerations Date: Wed, 7 Sep 2005 10:31:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWzs3CNM4iduo/2QQiFGP64Wm761wAADBtgAADFTSA= In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B211D@oefeg-s04.oefeg.loc> Message-ID: X-OriginalArrivalTime: 07 Sep 2005 14:31:36.0324 (UTC) FILETIME=[DA080440:01C5B3B8] X-Spam-Score: 1.1 (+) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Richard, NENA has expressed a requirement to have the ability to *hide* the PSAP boundaries from public view for security reasons. Ideas discussed to date have included having a single URI per state with finer-grain routing performed behind this state-level *demarc* in a private/protected Emergency Services Network (ESN). Imagine this as a large corporate network that has one/more Internet connections to their internal network(s). You don't know my actual email uri......@cisco.com is the 'public' view. So, all VoIP callers within (for example) the state of New York, may all use the same URI for emergency calling, accessing a b2bua/firewall at a single point into the private ESN. I realize this *could* be accomplished by having the user know the actual destination PSAP uri, but this *could* also be accomplished using a single uri for New York with eventual secondary routing. -Marc- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Stastny Richard > Sent: Wednesday, September 07, 2005 9:58 AM > To: Andrew Newton > Cc: ECRIT > Subject: RE: [Ecrit] Emergency Context Routing of > InternetTechnologies-Architecture Considerations > > I still do not see why knowing the boundaries of a PSAP > region poses a security problem at all. > > This is the same like knowing the boundaries of a district or > state. Everybody can have access to this information > (read-only). It is public knowledge anyway. > > Of course having R/W access is another issue, but this is not > an ecrit problem > > Richard > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Wednesday, September 07, 2005 3:49 PM > > To: Stastny Richard > > Cc: ECRIT; Winterbottom, James; James M. Polk > > Subject: Re: [Ecrit] Emergency Context Routing of Internet > Technologies- > > Architecture Considerations > > > > > > On Sep 7, 2005, at 8:17 AM, Stastny Richard wrote: > > > > > What is the problem with making the polygons publicly visible? > > > > It may be considered a security problem. Yes, trying to > keep polygons > > out of sight is not a perfect or total security solution. > > But that doesn't mean you should make things easy for the > bad actors. > > And if there is any one take away we should have learned > from protocol > > design, it is that the perfect security solutions tend to > be the ones > > that never get implemented. > > > > > Regarding the URIs: > > > If you want the terminal to reach emergency services, you have to > > > give them a URI. Providing them an indirect URI just shifts the > > > problem, but does not solve it. > > > > I agree. > > > > -andy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 07 10:37:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED13m-0007UE-JV; Wed, 07 Sep 2005 10:37:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED13l-0007TG-Kq for ecrit@megatron.ietf.org; Wed, 07 Sep 2005 10:37:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23747 for ; Wed, 7 Sep 2005 10:37:55 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED16w-0007Rh-3g for ecrit@ietf.org; Wed, 07 Sep 2005 10:41:15 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j87Ebkrr007095 for ; Wed, 7 Sep 2005 16:37:46 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j87Ebinp025518 for ; Wed, 7 Sep 2005 16:37:46 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Sep 2005 16:36:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Sep 2005 16:36:59 +0200 Message-ID: Thread-Topic: New Draft: "Security Threats and Requirements for Emergency Calling" Thread-Index: AcWzuQPXd3htESFCQJeti1npKjr2jwAAAOGQ From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 07 Sep 2005 14:36:59.0253 (UTC) FILETIME=[9A831250:01C5B3B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] New Draft: "Security Threats and Requirements for Emergency Calling" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 a new version of the "Security Threats and Requirements for Emergency Calling" has just been submitted. please find it at:=20 http://www.tschofenig.priv.at/drafts/draft-taylor-ecrit-security-threats-00. txt http://www.tschofenig.priv.at/drafts/draft-taylor-ecrit-security-threats-00. html this is a new and revised version of the draft.=20 tom volunteered to act as an editor of the document. thanks tom! please take a look at the document. we need to make progress with security threats and requirements as well.=20 the structure of the document has changed to reflect the discussions at the interim and at the last ietf meeting.=20 ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 07 10:44:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED1AR-0000NO-Uz; Wed, 07 Sep 2005 10:44:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED1AQ-0000NJ-G9 for ecrit@megatron.ietf.org; Wed, 07 Sep 2005 10:44:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23961 for ; Wed, 7 Sep 2005 10:44:48 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ED1Db-0007ao-CQ for ecrit@ietf.org; Wed, 07 Sep 2005 10:48:08 -0400 Content-class: urn:content-classes:message Subject: RE: [Ecrit] Emergency Context Routing of InternetTechnologies-Architecture Considerations MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Sep 2005 16:48:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B2120@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Emergency Context Routing of InternetTechnologies-Architecture Considerations Thread-Index: AcWzs3CNM4iduo/2QQiFGP64Wm761wAADBtgAADFTSAAAOaMgA== From: "Stastny Richard" To: "Marc Linsner" , "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > NENA has expressed a requirement to have the ability to *hide* the PSAP > boundaries from public view for security reasons. Ideas discussed to date > have included having a single URI per state with finer-grain routing > performed behind this state-level *demarc* in a private/protected > Emergency > Services Network (ESN). I have no problems with this approach, this is perfectly valid in the architecture und up to the national implementations.=20 This approach will be needed anyway as long as you need to have a local mapping to PSAPs connected via the PSTN or want to funnel the whole thing in a special private network. On the other hand, as Henning pointed out, designers of such special emergency networks should consider where the threats really are, what they gain and what they loose. I think there is still some work to do in tutorials and consulting Richard > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Wednesday, September 07, 2005 4:32 PM > To: Stastny Richard; 'Andrew Newton' > Cc: 'ECRIT' > Subject: RE: [Ecrit] Emergency Context Routing of InternetTechnologies- > Architecture Considerations >=20 > Richard, >=20 > NENA has expressed a requirement to have the ability to *hide* the PSAP > boundaries from public view for security reasons. Ideas discussed to date > have included having a single URI per state with finer-grain routing > performed behind this state-level *demarc* in a private/protected > Emergency > Services Network (ESN). >=20 > Imagine this as a large corporate network that has one/more Internet > connections to their internal network(s). You don't know my actual email > uri......@cisco.com is the 'public' view. >=20 > So, all VoIP callers within (for example) the state of New York, may all > use > the same URI for emergency calling, accessing a b2bua/firewall at a single > point into the private ESN. I realize this *could* be accomplished by > having the user know the actual destination PSAP uri, but this *could* > also > be accomplished using a single uri for New York with eventual secondary > routing. >=20 > -Marc- >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of Stastny Richard > > Sent: Wednesday, September 07, 2005 9:58 AM > > To: Andrew Newton > > Cc: ECRIT > > Subject: RE: [Ecrit] Emergency Context Routing of > > InternetTechnologies-Architecture Considerations > > > > I still do not see why knowing the boundaries of a PSAP > > region poses a security problem at all. > > > > This is the same like knowing the boundaries of a district or > > state. Everybody can have access to this information > > (read-only). It is public knowledge anyway. > > > > Of course having R/W access is another issue, but this is not > > an ecrit problem > > > > Richard > > > > > -----Original Message----- > > > From: Andrew Newton [mailto:andy@hxr.us] > > > Sent: Wednesday, September 07, 2005 3:49 PM > > > To: Stastny Richard > > > Cc: ECRIT; Winterbottom, James; James M. Polk > > > Subject: Re: [Ecrit] Emergency Context Routing of Internet > > Technologies- > > > Architecture Considerations > > > > > > > > > On Sep 7, 2005, at 8:17 AM, Stastny Richard wrote: > > > > > > > What is the problem with making the polygons publicly visible? > > > > > > It may be considered a security problem. Yes, trying to > > keep polygons > > > out of sight is not a perfect or total security solution. > > > But that doesn't mean you should make things easy for the > > bad actors. > > > And if there is any one take away we should have learned > > from protocol > > > design, it is that the perfect security solutions tend to > > be the ones > > > that never get implemented. > > > > > > > Regarding the URIs: > > > > If you want the terminal to reach emergency services, you have to > > > > give them a URI. Providing them an indirect URI just shifts the > > > > problem, but does not solve it. > > > > > > I agree. > > > > > > -andy > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 07 10:51:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED1HA-0001ei-Ue; Wed, 07 Sep 2005 10:51:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED1H9-0001eR-7C for ecrit@megatron.ietf.org; Wed, 07 Sep 2005 10:51:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24391 for ; Wed, 7 Sep 2005 10:51:45 -0400 (EDT) Message-Id: <200509071451.KAA24391@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED1KI-0007oN-A9 for ecrit@ietf.org; Wed, 07 Sep 2005 10:55:05 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.50) id 1ED1Gq-0001EH-PO; Wed, 07 Sep 2005 09:51:29 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Stastny Richard'" , "'ECRIT'" Subject: RE: [Ecrit] Emergency Context Routing of InternetTechnologies-Architecture Considerations Date: Wed, 7 Sep 2005 10:51:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <23D715C8-CC23-4628-8B34-4214B0B4543D@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcWzpDEe+nA4Z6u9TWSxfv586jshtwADtjsg 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: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org There is a piece of mythology at work here. There are VENDORS who believe that service boundaries of PSAPs are secret. There are VENDORS who believe that URIs of PSAPs are secret NENA has no position, to my knowledge, on this issue. I have asked, repeatedly, for any PSAPs who have such beliefs to please let me know. So far, no PSAPs have stepped up. From that I conclude that it's a myth, possibly a self serving myth, to claim that PSAPs believe service boundaries or URIs of PSAPs ought to be secret. PSAPs do have legitimate concerns about denial of service, and they want to understand the issues associated with widely publishing their URI, in the same sense anyone with an email address worries about their address being widely known. ESRPs are useful in this regard, as they provide a boundary where defenses may be mounted with more expertise than the average PSAP can muster. I do think however, that pittsburgh@psap.state.pa.us is a perfectly reasonable URI to get out of the mapping function. The domain, psap.state.pa.us, could provide an ESRP adequately protected, while the fact that the Pittsburgh PSAP is the ultimate destination is plain for all to see. There is a certain balance between making routing of emergency calls simple enough that it works when great parts of infrastructure die, and making it trivial to DoS attack a PSAP. I'm not sure I want to make the URI 911@psap.pittsburgh.allegheny.pa.us, because I really do worry about the ability of that domain to protect itself adequately. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Andrew Newton Sent: Wednesday, September 07, 2005 8:02 AM To: Stastny Richard; ECRIT Subject: Re: [Ecrit] Emergency Context Routing of InternetTechnologies-Architecture Considerations On Sep 7, 2005, at 3:54 AM, Stastny Richard wrote: >> [AJW] >> I think that this approach is at odds with NENA, which does not want >> every Tom, Dick and Harry having the ultimate address of the PSAP. I >> tend to agree with the NENA approach. It may be prudent to provide >> the >> address of the ESRP, but an ESRP is likely to service a number of >> PSAPs. >> This gives the flexibility within the emergency services network to >> determine how internal routing is performed, without revealing its >> internals to the rest of the world. >> > > Both approaches are valid and need to be supported. Basically > it is a matter of the local authorities where the SIP URI for > a given location points to. The ESRP is needed especially > in the migration scenarios where you may point a whole country > to one ESRP and do the whole mapping behind the scenes > e.g. routing to an ESGW to access TDM PSAPs. > > I also cannot fully see the argument to provide Toms and Harrys > not with the ultimate PSAP address, but the address of the ESRP > instead. It is a single point of failure and may also be the easy > focus > of DoS attacks. This problem has to be solved anyway. I agree with Richard on this. But I sense a recurring meta-issue here. Just how much information is to be considered publicly visible? Such as the PSAP URIs or the polygons of the PSAP coverage area... -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 07 11:07:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED1WC-0004yT-3F; Wed, 07 Sep 2005 11:07:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED1WA-0004yO-HY for ecrit@megatron.ietf.org; Wed, 07 Sep 2005 11:07:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25140 for ; Wed, 7 Sep 2005 11:07:16 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED1ZK-0008G6-Nx for ecrit@ietf.org; Wed, 07 Sep 2005 11:10:37 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 07 Sep 2005 11:07:11 -0400 id 000C7E8C.431F021F.00001BDF In-Reply-To: <944F315E-6A26-4238-A400-4FACB4C75D1F@cs.columbia.edu> References: <32755D354E6B65498C3BD9FD496C7D461B211D@oefeg-s04.oefeg.loc> <944F315E-6A26-4238-A400-4FACB4C75D1F@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <10CA7B5B-8A5A-45A9-8549-7B2F723DCB28@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Emergency Context Routing of Internet Technologies-Architecture Considerations Date: Wed, 7 Sep 2005 11:07:10 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: Stastny Richard , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 7, 2005, at 10:30 AM, Henning Schulzrinne wrote: > I agree with Richard. There is real cost in obscurity; as Richard > points out, at least in the US, the information is essentially > public anyway, so hiding this simply means that bugs won't be > found, that systems are made more complicated and that there's more > opportunity for various security consultants and contractors > offering their snake-oil services to gauge PSAPs. We all pay the > price for pseudo-security, even if it just confiscated nail > clippers at the airport... Henning, you've mischaracterized the technical aspect of this. Polygons are data, not algorithms. Do you expect of find a bug in a polygon that totally destroys the security of an ECRIT system? At worst, the polygon may have a bad point or two... something that I do not think will give an attacker any advantage and something that can be easily corrected once discovered. And this type of mistake seems most likely to be discovered by the PSAP and associated first responders and not the general public. > I'm very afraid that this type of recommendation will be used to > design closed, non-debuggable, expensive systems. Unless there is a > strong engineering motivation that can be justified on technical > grounds, we should not make such recommendations. Having the polygons stay server-side does not equate to a closed system. It is a design choice. The protocols can still be open. And if the PSAP operators wish, they can demand standards on the back- side to give them more choice (though, this is out of scope for ECRIT). Beyond the security aspect, there is also a deployment consideration in keeping the polygons server-side. What if vendor Acme distributes an ECRIT capable end-device that has a bug in its intersection algorithm caused by some "clever" code optimization. What if there are two such vendors with two different bugs. The compensation to deal with such bugs will be difficult. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 07 12:07:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED2S7-0002sx-Ga; Wed, 07 Sep 2005 12:07:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED2S6-0002ss-CA for ecrit@megatron.ietf.org; Wed, 07 Sep 2005 12:07:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29052 for ; Wed, 7 Sep 2005 12:07:08 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED2VG-0001sA-Mk for ecrit@ietf.org; Wed, 07 Sep 2005 12:10:29 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 07 Sep 2005 09:06:58 -0700 X-IronPort-AV: i="3.96,176,1122879600"; d="scan'208"; a="339520007:sNHT32767748" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j87G6s4u012091; Wed, 7 Sep 2005 09:06:56 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Sep 2005 12:06:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Emergency Context Routing of InternetTechnologies-Architecture Considerations Date: Wed, 7 Sep 2005 12:06:53 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E38A38AB@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Emergency Context Routing of InternetTechnologies-Architecture Considerations Thread-Index: AcWzvkhkXRaptp2QTfS90uqvHPwFTwAB5Txg From: "Michael Hammer \(mhammer\)" To: "Andrew Newton" , "Henning Schulzrinne" X-OriginalArrivalTime: 07 Sep 2005 16:06:54.0403 (UTC) FILETIME=[2A45A130:01C5B3C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: Stastny Richard , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hmmm.... Seems like we had a case very recently in Arlington, VA near Washington, D.C. where a man who called 911 died because the emergency responders couldn't figure out who had jurisdiction. Sounds like a bug in the data to me. And it sounds like the public discovered the bug first, i.e. the man died. Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Andrew Newton > Sent: Wednesday, September 07, 2005 11:07 AM > To: Henning Schulzrinne > Cc: Stastny Richard; ECRIT > Subject: Re: [Ecrit] Emergency Context Routing of=20 > InternetTechnologies-Architecture Considerations >=20 >=20 > On Sep 7, 2005, at 10:30 AM, Henning Schulzrinne wrote: >=20 > > I agree with Richard. There is real cost in obscurity; as Richard=20 > > points out, at least in the US, the information is=20 > essentially public=20 > > anyway, so hiding this simply means that bugs won't be found, that=20 > > systems are made more complicated and that there's more opportunity=20 > > for various security consultants and contractors offering their=20 > > snake-oil services to gauge PSAPs. We all pay the price for=20 > > pseudo-security, even if it just confiscated nail clippers at the=20 > > airport... >=20 > Henning, you've mischaracterized the technical aspect of this. =20 > Polygons are data, not algorithms. Do you expect of find a=20 > bug in a polygon that totally destroys the security of an=20 > ECRIT system? At worst, the polygon may have a bad point or=20 > two... something that I do not think will give an attacker=20 > any advantage and something that can be easily corrected once=20 > discovered. And this type of mistake seems most likely to be=20 > discovered by the PSAP and associated first responders and=20 > not the general public. >=20 > > I'm very afraid that this type of recommendation will be used to=20 > > design closed, non-debuggable, expensive systems. Unless there is a=20 > > strong engineering motivation that can be justified on technical=20 > > grounds, we should not make such recommendations. >=20 > Having the polygons stay server-side does not equate to a closed =20 > system. It is a design choice. The protocols can still be open. =20 > And if the PSAP operators wish, they can demand standards on=20 > the back- side to give them more choice (though, this is out=20 > of scope for ECRIT). >=20 > Beyond the security aspect, there is also a deployment=20 > consideration in keeping the polygons server-side. What if=20 > vendor Acme distributes an ECRIT capable end-device that has=20 > a bug in its intersection algorithm caused by some "clever"=20 > code optimization. What if there are two such vendors with=20 > two different bugs. The compensation to deal with such bugs=20 > will be difficult. >=20 > -andy >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 07 13:56:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED4A2-0007uP-Oi; Wed, 07 Sep 2005 13:56:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED4A0-0007uH-Pz for ecrit@megatron.ietf.org; Wed, 07 Sep 2005 13:56:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06004 for ; Wed, 7 Sep 2005 13:56:36 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED4DD-0005Wd-Jf for ecrit@ietf.org; Wed, 07 Sep 2005 13:59:56 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 07 Sep 2005 13:56:31 -0400 id 000C7E96.431F29CF.00003FFC In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E38A38AB@xmb-rtp-20b.amer.cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E38A38AB@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Emergency Context Routing of InternetTechnologies-Architecture Considerations Date: Wed, 7 Sep 2005 13:56:30 -0400 To: "Michael Hammer \"((mhammer))" X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: Stastny Richard , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 7, 2005, at 12:06 PM, Michael Hammer ((mhammer)) wrote: > Hmmm.... Seems like we had a case very recently in Arlington, VA near > Washington, D.C. where a man who called 911 died because the emergency > responders couldn't figure out who had jurisdiction. I often think that Arlington County would be a very interesting place to look at for this problem space, given that it has a few college campuses, many government offices, one of the most famous national parks (part of which is operated by the military), that huge DOD installation, two cities that overlap its borders, and a river belonging to another state. I tried to find this story to glean any details, but could not find it. > Sounds like a bug in the data to me. That's hard to tell without details. But if it was a bug in the data, I do not think this man's cell phone would have been any better at handling it than the PSAP's computers. > And it sounds like the public discovered the bug first, i.e. the man > died. I did use the words "seems most likely". In general, I do not imagine the public will be culling PSAP boundary data in non- emergency situations to inform a PSAP of incorrect polygons. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 07 14:42:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED4sQ-0003Gw-NT; Wed, 07 Sep 2005 14:42:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED4sP-0003Go-La for ecrit@megatron.ietf.org; Wed, 07 Sep 2005 14:42:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08411 for ; Wed, 7 Sep 2005 14:42:28 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED4vc-0006md-ND for ecrit@ietf.org; Wed, 07 Sep 2005 14:45:50 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 07 Sep 2005 11:42:19 -0700 X-IronPort-AV: i="3.96,177,1122879600"; d="scan'208"; a="658671881:sNHT32368142" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j87Ig6KK021210; Wed, 7 Sep 2005 11:42:16 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Sep 2005 14:42:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Emergency Context Routing of InternetTechnologies-Architecture Considerations Date: Wed, 7 Sep 2005 14:42:06 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E38A396E@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Emergency Context Routing of InternetTechnologies-Architecture Considerations Thread-Index: AcWz1YQHCzTn2z1mTTeWyYDR7EotZAABcJ1Q From: "Michael Hammer \(mhammer\)" To: "Andrew Newton" X-OriginalArrivalTime: 07 Sep 2005 18:42:07.0739 (UTC) FILETIME=[D973ECB0:01C5B3DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: Stastny Richard , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org As a matter of fact, when I moved into a newly built community, the insurance company wanted to know where the nearest fire station was. The local fire and police also needed to change their habits to occasionally drive through the community to learn the street addresses. (Taxi drivers and pizza delivery took a while to learn also.) Bottom line, if I was in a PSAP dead spot, as well as a cell coverage dead spot, shouldn't I know that? Arguing that we shouldn't be prepared for that possibility is as foolish as the lack of local planning for Katrina. Governments should be held accountable. This is just an extension of that. Mike > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us]=20 > Sent: Wednesday, September 07, 2005 1:57 PM > To: Michael Hammer (mhammer) > Cc: Henning Schulzrinne; Stastny Richard; ECRIT > Subject: Re: [Ecrit] Emergency Context Routing of=20 > InternetTechnologies-Architecture Considerations >=20 >=20 > On Sep 7, 2005, at 12:06 PM, Michael Hammer ((mhammer)) wrote: >=20 > > Hmmm.... Seems like we had a case very recently in=20 > Arlington, VA near=20 > > Washington, D.C. where a man who called 911 died because=20 > the emergency=20 > > responders couldn't figure out who had jurisdiction. >=20 > I often think that Arlington County would be a very=20 > interesting place to look at for this problem space, given=20 > that it has a few college campuses, many government offices,=20 > one of the most famous national parks (part of which is=20 > operated by the military), that huge DOD installation, two=20 > cities that overlap its borders, and a river belonging to=20 > another state. I tried to find this story to glean any=20 > details, but could not find it. >=20 > > Sounds like a bug in the data to me. >=20 > That's hard to tell without details. But if it was a bug in=20 > the data, I do not think this man's cell phone would have=20 > been any better at handling it than the PSAP's computers. >=20 > > And it sounds like the public discovered the bug first,=20 > i.e. the man=20 > > died. >=20 > I did use the words "seems most likely". In general, I do=20 > not imagine the public will be culling PSAP boundary data in=20 > non- emergency situations to inform a PSAP of incorrect polygons. >=20 > -andy >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 07 15:14:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED5NR-0002ad-GD; Wed, 07 Sep 2005 15:14:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED5NQ-0002aP-0p for ecrit@megatron.ietf.org; Wed, 07 Sep 2005 15:14:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10330 for ; Wed, 7 Sep 2005 15:14:30 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED5Qb-0007Yy-FL for ecrit@ietf.org; Wed, 07 Sep 2005 15:17:52 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 07 Sep 2005 15:14:22 -0400 id 000C7E96.431F3C0E.00005112 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E38A396E@xmb-rtp-20b.amer.cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E38A396E@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <36A1CACE-906D-43EE-9662-2BA75F549B7B@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Emergency Context Routing of InternetTechnologies-Architecture Considerations Date: Wed, 7 Sep 2005 15:14:21 -0400 To: "Michael Hammer \"((mhammer))" X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Stastny Richard , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 7, 2005, at 2:42 PM, Michael Hammer ((mhammer)) wrote: > As a matter of fact, when I moved into a newly built community, the > insurance company wanted to know where the nearest fire station was. That's fairly standard for purchasing homeowners insurance. > The local fire and police also needed to change their habits to > occasionally drive through the community to learn the street > addresses. I cannot speak to the habits and practices of Arlington County's fire and police services. Absent any details, I am hesitant to tell them how to do their job. > (Taxi drivers and pizza delivery took a while to learn also.) > > Bottom line, if I was in a PSAP dead spot, as well as a cell coverage > dead spot, shouldn't I know that? Sure. Though I have no idea what that has to do with this thread. Save any implementation boogs, I cannot understand how f(x) = 0 calculated in an end device is any more useful than f(x) = 0 calculated in an ESRP or mapping server. > Arguing that we shouldn't be prepared for that possibility is as > foolish > as the lack of local planning for Katrina. Governments should be held > accountable. This is just an extension of that. Who is arguing this? Because I said no such thing. However, making governments accountable is outside the scope of any IETF working group. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 07 15:41:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED5nl-0001AO-Jl; Wed, 07 Sep 2005 15:41:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED5nk-0001AJ-5F for ecrit@megatron.ietf.org; Wed, 07 Sep 2005 15:41:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12248 for ; Wed, 7 Sep 2005 15:41:42 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED5qx-0008JV-Ox for ecrit@ietf.org; Wed, 07 Sep 2005 15:45:05 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 07 Sep 2005 12:40:39 -0700 X-IronPort-AV: i="3.96,177,1122879600"; d="scan'208"; a="339592268:sNHT632173304" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j87JeS52020144; Wed, 7 Sep 2005 12:40:36 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Sep 2005 15:40:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Emergency Context Routing of InternetTechnologies-Architecture Considerations Date: Wed, 7 Sep 2005 15:40:25 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E38A39C8@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Emergency Context Routing of InternetTechnologies-Architecture Considerations Thread-Index: AcWz4HhO1NVo/YvrRuykjuNwY1lZtQAAqSRg From: "Michael Hammer \(mhammer\)" To: "Andrew Newton" X-OriginalArrivalTime: 07 Sep 2005 19:40:26.0889 (UTC) FILETIME=[FF1BD790:01C5B3E3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: Stastny Richard , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I am only suggesting that transparency in government operations is a good thing. The secrecy and security that was proposed earlier on this thread appeared to be focusing more on legal CYA than on real security. So, the threats need to be well specified, but keeping the public in the dark about how this service is provided is not one of them. Mike > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us]=20 > Sent: Wednesday, September 07, 2005 3:14 PM > To: Michael Hammer (mhammer) > Cc: Henning Schulzrinne; Stastny Richard; ECRIT > Subject: Re: [Ecrit] Emergency Context Routing of=20 > InternetTechnologies-Architecture Considerations >=20 >=20 > On Sep 7, 2005, at 2:42 PM, Michael Hammer ((mhammer)) wrote: >=20 > > As a matter of fact, when I moved into a newly built community, the=20 > > insurance company wanted to know where the nearest fire station was. >=20 > That's fairly standard for purchasing homeowners insurance. >=20 > > The local fire and police also needed to change their habits to=20 > > occasionally drive through the community to learn the street=20 > > addresses. >=20 > I cannot speak to the habits and practices of Arlington=20 > County's fire and police services. Absent any details, I am=20 > hesitant to tell them how to do their job. >=20 > > (Taxi drivers and pizza delivery took a while to learn also.) > > > > Bottom line, if I was in a PSAP dead spot, as well as a=20 > cell coverage=20 > > dead spot, shouldn't I know that? >=20 > Sure. Though I have no idea what that has to do with this thread. =20 > Save any implementation boogs, I cannot understand how f(x) =3D=20 > 0 calculated in an end device is any more useful than f(x) =3D=20 > 0 calculated in an ESRP or mapping server. >=20 > > Arguing that we shouldn't be prepared for that possibility is as=20 > > foolish as the lack of local planning for Katrina. =20 > Governments should=20 > > be held accountable. This is just an extension of that. >=20 > Who is arguing this? Because I said no such thing. However,=20 > making governments accountable is outside the scope of any=20 > IETF working group. >=20 > -andy >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 07 16:00:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED66A-00051F-3n; Wed, 07 Sep 2005 16:00:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED668-00050q-De for ecrit@megatron.ietf.org; Wed, 07 Sep 2005 16:00:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13988 for ; Wed, 7 Sep 2005 16:00:42 -0400 (EDT) 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.43) id 1ED69M-0000jq-37 for ecrit@ietf.org; Wed, 07 Sep 2005 16:04:05 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Emergency Context Routing ofInternetTechnologies-Architecture Considerations Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 7 Sep 2005 16:00:30 -0400 Message-ID: Thread-Topic: [Ecrit] Emergency Context Routing ofInternetTechnologies-Architecture Considerations Thread-Index: AcWzpDEe+nA4Z6u9TWSxfv586jshtwADtjsgAAYBp1A= To: , "Andrew Newton" , "Stastny Richard" , "ECRIT" X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org "There is a piece of mythology at work here. There are VENDORS who believe that service boundaries of PSAPs are secret. There are VENDORS who believe that URIs of PSAPs are secret NENA has no position, to my knowledge, on this issue." [NGW]=20 Here is the PSAP concern: An enterprising thief could figure out that a business (without an alarm system) in Backwater, Vermont is served by a PSAP located 25 miles away. If one creates an IP-based denial of service attack on that PSAP then it is safe to assume that the target of opportunity that the thief is looking at in Backwater will not be able to contact the PSAP to summon help. Using PSTN technologies, an enterprising thief could create a PSTN DoS on the PSAP by simply using an auto call generator from a pay phone located in the same proximity as the target of opportunity however, this would still create a response to the general area of the crime. If I know the URI of the PSAP, I can now distract it from another continent and do what I would need to do in Backwater and no response would be created in that direction - that is the new paradigm with IP. If I know the boundaries of the Derby PSAP, I could create a PSTN based DoS attack anywhere from within that boundary (potentially 50 miles from Island Pond). Would this happen? I don't know - I am pretty sure it hasn't yet but assigning a URI to a PSAP opens it up to whole new generation of "creative thinkers"..... Of course we can minimize the impact on the PSAP at a higher level gateway by throwing a huge amount of bandwidth at it and building in intelligent alternative routing on a robust firewall. But that does not help in the interim between here and there when someone gets their hands on the PSAP boundaries and realizes the attacks they can initiate using the PSTN DoS approach. Nate Wilcox Vermont Enhanced 9-1-1 802.828.4093 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 07 22:21:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDC2h-0005BQ-6K; Wed, 07 Sep 2005 22:21:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDC2e-0005BK-Mf for ecrit@megatron.ietf.org; Wed, 07 Sep 2005 22:21:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09088 for ; Wed, 7 Sep 2005 22:21:30 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDC5w-00043o-TT for ecrit@ietf.org; Wed, 07 Sep 2005 22:24:57 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j882LKUk024404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Sep 2005 22:21:20 -0400 (EDT) Message-ID: <431FA026.5050207@cs.columbia.edu> Date: Wed, 07 Sep 2005 22:21:26 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Emergency Context Routing of Internet Technologies-Architecture Considerations References: <32755D354E6B65498C3BD9FD496C7D461B211D@oefeg-s04.oefeg.loc> <944F315E-6A26-4238-A400-4FACB4C75D1F@cs.columbia.edu> <10CA7B5B-8A5A-45A9-8549-7B2F723DCB28@hxr.us> In-Reply-To: <10CA7B5B-8A5A-45A9-8549-7B2F723DCB28@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: Stastny Richard , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Andrew Newton wrote: > > On Sep 7, 2005, at 10:30 AM, Henning Schulzrinne wrote: > >> I agree with Richard. There is real cost in obscurity; as Richard >> points out, at least in the US, the information is essentially public >> anyway, so hiding this simply means that bugs won't be found, that >> systems are made more complicated and that there's more opportunity >> for various security consultants and contractors offering their >> snake-oil services to gauge PSAPs. We all pay the price for >> pseudo-security, even if it just confiscated nail clippers at the >> airport... > > > Henning, you've mischaracterized the technical aspect of this. > Polygons are data, not algorithms. Do you expect of find a bug in a > polygon that totally destroys the security of an ECRIT system? At > worst, the polygon may have a bad point or two... something that I do > not think will give an attacker any advantage and something that can be > easily corrected once discovered. And this type of mistake seems most > likely to be discovered by the PSAP and associated first responders and > not the general public. This has little to do with algorithms vs. data. Making polygons available, it allows third parties to aggregate data, for example, or to discover larger overlaps (and gaps). By the way, data hiding is largely futile, even if it made sense to begin with: Assuming that this was super-secret information, The Bad Guy can simply generate test calls probing the boundaries and get a very good idea on where the bounds are or who serves a particular point in space, at least to the precision that The Bad Guy cares about. > >> I'm very afraid that this type of recommendation will be used to >> design closed, non-debuggable, expensive systems. Unless there is a >> strong engineering motivation that can be justified on technical >> grounds, we should not make such recommendations. > > > Having the polygons stay server-side does not equate to a closed > system. It is a design choice. The protocols can still be open. And > if the PSAP operators wish, they can demand standards on the back- side > to give them more choice (though, this is out of scope for ECRIT). As ECRIT, we should take no position on this issue, as there is no technical advantage to hiding the information. Indeed, if anything, it prevents certain caching architectures that one might want to layer on top of the infrastructure for increased resiliency or verification. > > Beyond the security aspect, there is also a deployment consideration in > keeping the polygons server-side. What if vendor Acme distributes an > ECRIT capable end-device that has a bug in its intersection algorithm > caused by some "clever" code optimization. What if there are two such > vendors with two different bugs. The compensation to deal with such > bugs will be difficult. I am not advocating that end systems do polygon intersection. This is an orthogonal issue. However, in a multi-layered, hierarchical system, such as the one we've been discussing at the interim and elsewhere, access to polygon information is extremely helpful, and possibly necessary for efficiency, for other servers in the hierarchy. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 08 06:30:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDJff-0004Zs-Se; Thu, 08 Sep 2005 06:30:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDJfd-0004Zh-HZ for ecrit@megatron.ietf.org; Thu, 08 Sep 2005 06:30:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11276 for ; Thu, 8 Sep 2005 06:30:14 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDJiy-0007gn-TD for ecrit@ietf.org; Thu, 08 Sep 2005 06:33:46 -0400 Received: from [10.0.1.5] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 08 Sep 2005 06:30:12 -0400 id 000C7BE1.432012B4.000001C1 In-Reply-To: <431FA026.5050207@cs.columbia.edu> References: <32755D354E6B65498C3BD9FD496C7D461B211D@oefeg-s04.oefeg.loc> <944F315E-6A26-4238-A400-4FACB4C75D1F@cs.columbia.edu> <10CA7B5B-8A5A-45A9-8549-7B2F723DCB28@hxr.us> <431FA026.5050207@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Emergency Context Routing of Internet Technologies-Architecture Considerations Date: Thu, 8 Sep 2005 06:30:10 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Stastny Richard , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 7, 2005, at 10:21 PM, Henning Schulzrinne wrote: > As ECRIT, we should take no position on this issue, as there is no > technical advantage to hiding the information. Your perception of this being a technical advantage does not mean a real-world requirement should be ignored. If the ECRIT solution is to be deployed, PSAP operators will have to be comfortable with it. We should not forget the lessons of DNSSEC, where the real-world requirements of privacy laws were dismissed as having no technical advantage resulting in stalled deployments by many TLD operators. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 08 08:47:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDLoF-0000to-Ax; Thu, 08 Sep 2005 08:47:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDLoA-0000r5-L0 for ecrit@megatron.ietf.org; Thu, 08 Sep 2005 08:47:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17327 for ; Thu, 8 Sep 2005 08:47:12 -0400 (EDT) Message-Id: <200509081247.IAA17327@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDLrY-0002kS-BH for ecrit@ietf.org; Thu, 08 Sep 2005 08:50:44 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EDLns-0004FS-AY; Thu, 08 Sep 2005 07:46:56 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Emergency Context Routing of InternetTechnologies-Architecture Considerations Date: Thu, 8 Sep 2005 08:46:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW0YJiZ5fhL+e7oSUCrhvkTYyEcDgAEnDlQ 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: 'Stastny Richard' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Nate Wilcox is the only PSAP person here, and he told you what the issue is. The data isn't secret, there is a concern for how the data can be used for a DoS attack. The requirement is to avoid DoS attacks as much as possible, not to keep service areas secret. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Andrew Newton Sent: Thursday, September 08, 2005 6:30 AM To: Henning Schulzrinne Cc: Stastny Richard; ECRIT Subject: Re: [Ecrit] Emergency Context Routing of InternetTechnologies-Architecture Considerations On Sep 7, 2005, at 10:21 PM, Henning Schulzrinne wrote: > As ECRIT, we should take no position on this issue, as there is no > technical advantage to hiding the information. Your perception of this being a technical advantage does not mean a real-world requirement should be ignored. If the ECRIT solution is to be deployed, PSAP operators will have to be comfortable with it. We should not forget the lessons of DNSSEC, where the real-world requirements of privacy laws were dismissed as having no technical advantage resulting in stalled deployments by many TLD operators. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 08 08:54:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDLuz-00028l-M5; Thu, 08 Sep 2005 08:54:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDLuv-00027y-0r for ecrit@megatron.ietf.org; Thu, 08 Sep 2005 08:54:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17716 for ; Thu, 8 Sep 2005 08:54:11 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDLyH-0002w0-RU for ecrit@ietf.org; Thu, 08 Sep 2005 08:57:43 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j88CrpQ5027186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Sep 2005 08:53:52 -0400 (EDT) Message-ID: <43203462.3000806@cs.columbia.edu> Date: Thu, 08 Sep 2005 08:53:54 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Emergency Context Routing of Internet Technologies-Architecture Considerations References: <32755D354E6B65498C3BD9FD496C7D461B211D@oefeg-s04.oefeg.loc> <944F315E-6A26-4238-A400-4FACB4C75D1F@cs.columbia.edu> <10CA7B5B-8A5A-45A9-8549-7B2F723DCB28@hxr.us> <431FA026.5050207@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Stastny Richard , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I can only echo Brian's message. The only requirement I have heard so far is not directly making the *URI* for the PSAP itself visible, to make DOS attack prevention easier. This is a wholly separate and orthogonal issue. As far as I know, the only laws likely to apply here are open-records and freedom-of-information laws (which obviously state exactly the opposite of your implication). Andrew Newton wrote: > > On Sep 7, 2005, at 10:21 PM, Henning Schulzrinne wrote: > >> As ECRIT, we should take no position on this issue, as there is no >> technical advantage to hiding the information. > > > Your perception of this being a technical advantage does not mean a > real-world requirement should be ignored. If the ECRIT solution is to > be deployed, PSAP operators will have to be comfortable with it. We > should not forget the lessons of DNSSEC, where the real-world > requirements of privacy laws were dismissed as having no technical > advantage resulting in stalled deployments by many TLD operators. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 08 09:54:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDMqv-0008LB-JE; Thu, 08 Sep 2005 09:54:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDMqt-0008Km-Qw for ecrit@megatron.ietf.org; Thu, 08 Sep 2005 09:54:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20312 for ; Thu, 8 Sep 2005 09:54:05 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDMuH-0004VR-4h for ecrit@ietf.org; Thu, 08 Sep 2005 09:57:38 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 08 Sep 2005 09:54:01 -0400 id 000C7C64.4320427A.00002581 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <621B2130-D135-4314-8FB6-36E49EBD1628@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Emergency Context Routing of InternetTechnologies-Architecture Considerations Date: Thu, 8 Sep 2005 09:53:59 -0400 To: br@brianrosen.net X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 8, 2005, at 8:46 AM, Brian Rosen wrote: > Nate Wilcox is the only PSAP person here, and he told you what the > issue is. > The data isn't secret, there is a concern for how the data can be > used for a > DoS attack. The requirement is to avoid DoS attacks as much as > possible, > not to keep service areas secret. First, there is a difference between "secret" and "easily accessible". As I stated before, just because bad actors can figure out this information from other sources doesn't mean it should be given to them. From Nate's message: > If I know > the boundaries of the Derby PSAP, I could create a PSTN based DoS > attack > anywhere from within that boundary (potentially 50 miles from Island > Pond). and > But that does not > help in the interim between here and there when someone gets their > hands > on the PSAP boundaries and realizes the attacks they can initiate > using > the PSTN DoS approach. I did not read that as "there should be no concern for the dissemination of the PSAP's boundary information." Echoing back to something Henning said: > I am not advocating that end systems do polygon intersection. This > is an orthogonal issue. However, in a multi-layered, hierarchical > system, such as the one we've been discussing at the interim and > elsewhere, access to polygon information is extremely helpful, and > possibly necessary for efficiency, for other servers in the hierarchy. There is a difference between dissemination of the PSAP boundary information to a limited set of aggregators, mirrors, and/or responsible entities and dissemination of the PSAP boundary information to anybody with an Internet connection. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 08 13:55:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDQcO-00089o-4z; Thu, 08 Sep 2005 13:55:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDQcM-00088N-1z for ecrit@megatron.ietf.org; Thu, 08 Sep 2005 13:55:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05914 for ; Thu, 8 Sep 2005 13:55:20 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDQfh-0002tV-H8 for ecrit@ietf.org; Thu, 08 Sep 2005 13:58:54 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j88Hspr7002289; Thu, 8 Sep 2005 10:54:51 -0700 (PDT) Received: from [192.168.1.4] (vpn-10-50-16-87.qualcomm.com [10.50.16.87]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j88HsbS3003239; Thu, 8 Sep 2005 10:54:39 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 8 Sep 2005 10:54:31 -0700 To: wilcox@e911.psd.state.vt.us, , "Andrew Newton" , "Stastny Richard" , "ECRIT" From: Ted Hardie Subject: RE: [Ecrit] Emergency Context Routing ofInternetTechnologies-Architecture Considerations Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org After reading the thread, I wanted to come back to Nate's original concern and call something out: >Here is the PSAP concern: > >An enterprising thief could figure out that a business (without an alarm >system) in Backwater, Vermont is served by a PSAP located 25 miles away. >If one creates an IP-based denial of service attack on that PSAP then it >is safe to assume that the target of opportunity that the thief is >looking at in Backwater will not be able to contact the PSAP to summon >help. I'm assuming that the PSAP being 25 miles away means nothing about where the responders are. The responders in this instance might be sheriffs, for example, who are stationed nearby, even further than 25 miles away, or whose patrol routes mean that their distance from the target of opportunity is variable. So I think we should cut the distance from this description completely, and simply see the threat as "If the bad actor can determine which PSAP serves an area in which a target is present, a successful attack on the PSAP prevents responses to the target". Does that make sense? > Using PSTN technologies, an enterprising thief could create a PSTN >DoS on the PSAP by simply using an auto call generator from a pay phone >located in the same proximity as the target of opportunity however, this >would still create a response to the general area of the crime. There are lots of other kinds of PSTN attacks here--the most commonly portrayed being "cutting the line", which doesn't work quite as it seems in the movies, but does have some effect. To avoid the locality problem in this attack, the bad actor can use an accomplice, meat or mechanical, in any other area served by the PSAP to do the same thing. This avoids the response hitting the general area of the crime. It also has the same counter-measure; call-blocking of the attacking phone. This counter-measure is also relatively easy to accomplish with an IP-based service, provided the attack is coming from a single IP or block. I believe the problem is harder in the IP case not because the area from which the attack can originate is larger but because it is easier to create a Distributed Denial of Service, largely because of zombie networks and IP spoofing. That is, if the attack is coming from Europe while the attack is happening on Backwater, my response is the same as if it came from Nearwater, VT: block the attack source. But if it is coming from Europe, Asia, Nearwater, Backwater, and many other points as well, attempts to block the attack either requires effectively severing connectivity or maintaining a fair amount of information about who at the IP layer should be talking to this PSAP. We've discussed the effectiveness of that in the past. >If I >know the URI of the PSAP, I can now distract it from another continent >and do what I would need to do in Backwater and no response would be >created in that direction - that is the new paradigm with IP. If I know >the boundaries of the Derby PSAP, I could create a PSTN based DoS attack >anywhere from within that boundary (potentially 50 miles from Island >Pond). > >Would this happen? I don't know - I am pretty sure it hasn't yet but >assigning a URI to a PSAP opens it up to whole new generation of >"creative thinkers"..... > >Of course we can minimize the impact on the PSAP at a higher level >gateway by throwing a huge amount of bandwidth at it and building in >intelligent alternative routing on a robust firewall. But that does not >help in the interim between here and there when someone gets their hands >on the PSAP boundaries and realizes the attacks they can initiate using >the PSTN DoS approach. The problem with the proposed solution, I believe, is that aggregating the access to a back-to-back user agent or all-knowing gateway is that you have simply created a richer target for attack. If I can marshal a zombie group that takes out all of Vermont's PSAPs by eliminating the the gateway by DDoS, I have done far worse far more easily than I could by individually attacking the PSAPs at their URIs. If I did it in order to get at Backwater's target, I likely don't care that the general effect is larger--my purpose is met. Yes, it is easier to escalate the defenses at a single point and yes, it is easier to pay for fat pipes for that single point. But the bad actors here aren't using their own resources to attack you; they are stealing them before trying to steal from you. Getting into an arms race with someone who isn't spending their own money worries me. regards, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 08 15:12:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDRp0-00040k-Bz; Thu, 08 Sep 2005 15:12:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDRow-00040e-RK for ecrit@megatron.ietf.org; Thu, 08 Sep 2005 15:12:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12241 for ; Thu, 8 Sep 2005 15:12:24 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDRsN-0005M0-K2 for ecrit@ietf.org; Thu, 08 Sep 2005 15:16:00 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Sep 2005 12:12:17 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,179,1122879600"; d="scan'208"; a="8974038:sNHT24225484" 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 j88JBqTE010181; Thu, 8 Sep 2005 15:12:14 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Sep 2005 15:12:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Emergency Context Routing ofInternetTechnologies-Architecture Considerations Date: Thu, 8 Sep 2005 15:12:02 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E38A3CC8@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Emergency Context Routing ofInternetTechnologies-Architecture Considerations Thread-Index: AcW0nrEgg7FP1ZhNSGC2XzZaoHBB9wACdmtg From: "Michael Hammer \(mhammer\)" To: "Ted Hardie" , , , "Andrew Newton" , "Stastny Richard" , "ECRIT" X-OriginalArrivalTime: 08 Sep 2005 19:12:03.0557 (UTC) FILETIME=[3241C150:01C5B4A9] X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Ted, I'm confused. Are calls from Asia or Europe to the Vermont PSAP ever legitimate? Somehow, I can't picture the local sheriff being able to help someone in Berlin. I thought the point of i3 is to enable the call to go to the local Berlin Polizei. Put another way, is it possible to use the local nature of emergency service to protect agains DDoS? Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Ted Hardie > Sent: Thursday, September 08, 2005 1:55 PM > To: wilcox@e911.psd.state.vt.us; br@brianrosen.net; Andrew=20 > Newton; Stastny Richard; ECRIT > Subject: RE: [Ecrit] Emergency Context Routing=20 > ofInternetTechnologies-Architecture Considerations >=20 > After reading the thread, I wanted to come back to Nate's=20 > original concern and call something out: >=20 > >Here is the PSAP concern: > > > >An enterprising thief could figure out that a business (without an=20 > >alarm > >system) in Backwater, Vermont is served by a PSAP located 25=20 > miles away. > >If one creates an IP-based denial of service attack on that=20 > PSAP then=20 > >it is safe to assume that the target of opportunity that the=20 > thief is=20 > >looking at in Backwater will not be able to contact the PSAP=20 > to summon=20 > >help. >=20 > I'm assuming that the PSAP being 25 miles away means nothing=20 > about where the responders are. The responders in this=20 > instance might be sheriffs, for example, who are stationed=20 > nearby, even further than 25 miles away, or whose patrol=20 > routes mean that their distance from the target of=20 > opportunity is variable. So I think we should cut the=20 > distance from this description completely, and simply see the=20 > threat as "If the bad actor can determine which PSAP serves=20 > an area in which a target is present, a successful attack on=20 > the PSAP prevents responses to the target". >=20 > Does that make sense? >=20 >=20 > > Using PSTN technologies, an enterprising thief could create=20 > a PSTN DoS=20 > >on the PSAP by simply using an auto call generator from a pay phone=20 > >located in the same proximity as the target of opportunity however,=20 > >this would still create a response to the general area of the crime. >=20 > There are lots of other kinds of PSTN attacks here--the most=20 > commonly portrayed being "cutting the line", which doesn't=20 > work quite as it seems in the movies, but does have some effect.=20 >=20 > To avoid the locality problem in this attack, the bad actor=20 > can use an accomplice, meat or mechanical, in any other area=20 > served by the PSAP to do the same thing. This avoids the=20 > response hitting the general area of the crime. It also has=20 > the same counter-measure; call-blocking of the attacking=20 > phone. This counter-measure is also relatively easy to=20 > accomplish with an IP-based service, provided the attack is=20 > coming from a single IP or block. I believe the problem is=20 > harder in the IP case not because the area from which the=20 > attack can originate is larger but because it is easier to=20 > create a Distributed Denial of Service, largely because of=20 > zombie networks and IP spoofing. > That is, if the attack is coming from Europe while the attack=20 > is happening on Backwater, my response is the same as if it=20 > came from Nearwater, VT: > block the attack source. But if it is coming from Europe,=20 > Asia, Nearwater, Backwater, and many other points as well,=20 > attempts to block the attack either requires effectively=20 > severing connectivity or maintaining a fair amount of=20 > information about who at the IP layer should be talking to=20 > this PSAP. We've discussed the effectiveness of that in the past. >=20 > >If I > >know the URI of the PSAP, I can now distract it from another=20 > continent=20 > >and do what I would need to do in Backwater and no response would be=20 > >created in that direction - that is the new paradigm with=20 > IP. If I know=20 > >the boundaries of the Derby PSAP, I could create a PSTN based DoS=20 > >attack anywhere from within that boundary (potentially 50 miles from=20 > >Island Pond). > > > >Would this happen? I don't know - I am pretty sure it hasn't yet but=20 > >assigning a URI to a PSAP opens it up to whole new generation of=20 > >"creative thinkers"..... > > > >Of course we can minimize the impact on the PSAP at a higher level=20 > >gateway by throwing a huge amount of bandwidth at it and building in=20 > >intelligent alternative routing on a robust firewall. But=20 > that does not=20 > >help in the interim between here and there when someone gets their=20 > >hands on the PSAP boundaries and realizes the attacks they=20 > can initiate=20 > >using the PSTN DoS approach. >=20 > The problem with the proposed solution, I believe, is that=20 > aggregating the access to a back-to-back user agent or=20 > all-knowing gateway is that you have simply created a richer=20 > target for attack. If I can marshal a zombie group that=20 > takes out all of Vermont's PSAPs by eliminating the the=20 > gateway by DDoS, I have done far worse far more easily than I=20 > could by individually attacking the PSAPs at their URIs. If=20 > I did it in order to get at Backwater's target, I likely=20 > don't care that the general effect is larger--my purpose is met. >=20 > Yes, it is easier to escalate the defenses at a single point=20 > and yes, it is easier to pay for fat pipes for that single=20 > point. But the bad actors here aren't using their own=20 > resources to attack you; they are stealing them before trying=20 > to steal from you. Getting into an arms race with someone=20 > who isn't spending their own money worries me. >=20 > regards, > Ted >=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 Sep 08 15:21:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDRy7-0006jy-LY; Thu, 08 Sep 2005 15:21:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDRy5-0006jt-Ep for ecrit@megatron.ietf.org; Thu, 08 Sep 2005 15:21:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13175 for ; Thu, 8 Sep 2005 15:21:51 -0400 (EDT) Message-Id: <200509081921.PAA13175@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDS1W-0005Zy-CC for ecrit@ietf.org; Thu, 08 Sep 2005 15:25:26 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EDRxp-0007Yx-WA; Thu, 08 Sep 2005 14:21:38 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Ted Hardie'" , , "'Andrew Newton'" , "'Stastny Richard'" , "'ECRIT'" Subject: RE: [Ecrit] Emergency Context Routing ofInternetTechnologies-Architecture Considerations Date: Thu, 8 Sep 2005 15:21:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E38A3CC8@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW0nrEgg7FP1ZhNSGC2XzZaoHBB9wACdmtgAABWkdA= 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: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is starting to verge into geopriv territory, but the issue is that it's pretty hard to reliably authenticate a location or the source of the location. That means it's relatively easy to forge a location. So a bad guy in Singapore can send calls to a PSAP in Boise that appear to be from a location in Boise. Brian -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Thursday, September 08, 2005 3:12 PM To: Ted Hardie; wilcox@e911.psd.state.vt.us; br@brianrosen.net; Andrew Newton; Stastny Richard; ECRIT Subject: RE: [Ecrit] Emergency Context Routing ofInternetTechnologies-Architecture Considerations Ted, I'm confused. Are calls from Asia or Europe to the Vermont PSAP ever legitimate? Somehow, I can't picture the local sheriff being able to help someone in Berlin. I thought the point of i3 is to enable the call to go to the local Berlin Polizei. Put another way, is it possible to use the local nature of emergency service to protect agains DDoS? Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Ted Hardie > Sent: Thursday, September 08, 2005 1:55 PM > To: wilcox@e911.psd.state.vt.us; br@brianrosen.net; Andrew > Newton; Stastny Richard; ECRIT > Subject: RE: [Ecrit] Emergency Context Routing > ofInternetTechnologies-Architecture Considerations > > After reading the thread, I wanted to come back to Nate's > original concern and call something out: > > >Here is the PSAP concern: > > > >An enterprising thief could figure out that a business (without an > >alarm > >system) in Backwater, Vermont is served by a PSAP located 25 > miles away. > >If one creates an IP-based denial of service attack on that > PSAP then > >it is safe to assume that the target of opportunity that the > thief is > >looking at in Backwater will not be able to contact the PSAP > to summon > >help. > > I'm assuming that the PSAP being 25 miles away means nothing > about where the responders are. The responders in this > instance might be sheriffs, for example, who are stationed > nearby, even further than 25 miles away, or whose patrol > routes mean that their distance from the target of > opportunity is variable. So I think we should cut the > distance from this description completely, and simply see the > threat as "If the bad actor can determine which PSAP serves > an area in which a target is present, a successful attack on > the PSAP prevents responses to the target". > > Does that make sense? > > > > Using PSTN technologies, an enterprising thief could create > a PSTN DoS > >on the PSAP by simply using an auto call generator from a pay phone > >located in the same proximity as the target of opportunity however, > >this would still create a response to the general area of the crime. > > There are lots of other kinds of PSTN attacks here--the most > commonly portrayed being "cutting the line", which doesn't > work quite as it seems in the movies, but does have some effect. > > To avoid the locality problem in this attack, the bad actor > can use an accomplice, meat or mechanical, in any other area > served by the PSAP to do the same thing. This avoids the > response hitting the general area of the crime. It also has > the same counter-measure; call-blocking of the attacking > phone. This counter-measure is also relatively easy to > accomplish with an IP-based service, provided the attack is > coming from a single IP or block. I believe the problem is > harder in the IP case not because the area from which the > attack can originate is larger but because it is easier to > create a Distributed Denial of Service, largely because of > zombie networks and IP spoofing. > That is, if the attack is coming from Europe while the attack > is happening on Backwater, my response is the same as if it > came from Nearwater, VT: > block the attack source. But if it is coming from Europe, > Asia, Nearwater, Backwater, and many other points as well, > attempts to block the attack either requires effectively > severing connectivity or maintaining a fair amount of > information about who at the IP layer should be talking to > this PSAP. We've discussed the effectiveness of that in the past. > > >If I > >know the URI of the PSAP, I can now distract it from another > continent > >and do what I would need to do in Backwater and no response would be > >created in that direction - that is the new paradigm with > IP. If I know > >the boundaries of the Derby PSAP, I could create a PSTN based DoS > >attack anywhere from within that boundary (potentially 50 miles from > >Island Pond). > > > >Would this happen? I don't know - I am pretty sure it hasn't yet but > >assigning a URI to a PSAP opens it up to whole new generation of > >"creative thinkers"..... > > > >Of course we can minimize the impact on the PSAP at a higher level > >gateway by throwing a huge amount of bandwidth at it and building in > >intelligent alternative routing on a robust firewall. But > that does not > >help in the interim between here and there when someone gets their > >hands on the PSAP boundaries and realizes the attacks they > can initiate > >using the PSTN DoS approach. > > The problem with the proposed solution, I believe, is that > aggregating the access to a back-to-back user agent or > all-knowing gateway is that you have simply created a richer > target for attack. If I can marshal a zombie group that > takes out all of Vermont's PSAPs by eliminating the the > gateway by DDoS, I have done far worse far more easily than I > could by individually attacking the PSAPs at their URIs. If > I did it in order to get at Backwater's target, I likely > don't care that the general effect is larger--my purpose is met. > > Yes, it is easier to escalate the defenses at a single point > and yes, it is easier to pay for fat pipes for that single > point. But the bad actors here aren't using their own > resources to attack you; they are stealing them before trying > to steal from you. Getting into an arms race with someone > who isn't spending their own money worries me. > > regards, > Ted > > _______________________________________________ > 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 Sep 08 15:22:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDRyl-0006rH-2q; Thu, 08 Sep 2005 15:22:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDRyj-0006rC-OS for ecrit@megatron.ietf.org; Thu, 08 Sep 2005 15:22:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13216 for ; Thu, 8 Sep 2005 15:22:31 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDS28-0005aT-LM for ecrit@ietf.org; Thu, 08 Sep 2005 15:26:07 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j88JLOG6023597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Sep 2005 12:21:24 -0700 (PDT) Received: from [192.168.1.4] (vpn-10-50-16-87.qualcomm.com [10.50.16.87]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j88JLLkM010648; Thu, 8 Sep 2005 12:21:22 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E38A3CC8@xmb-rtp-20b.amer.cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E38A3CC8@xmb-rtp-20b.amer.cisco.com> Date: Thu, 8 Sep 2005 12:21:19 -0700 To: "Michael Hammer \(mhammer\)" , , , "Andrew Newton" , "Stastny Richard" , "ECRIT" From: Ted Hardie Subject: RE: [Ecrit] Emergency Context Routing ofInternetTechnologies-Architecture Considerations Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 3:12 PM -0400 9/8/05, Michael Hammer \(mhammer\) wrote: >Ted, > >I'm confused. Are calls from Asia or Europe to the Vermont PSAP ever >legitimate? > >Somehow, I can't picture the local sheriff being able to help someone in >Berlin. I thought the point of i3 is to enable the call to go to the >local Berlin Polizei. Put another way, is it possible to use the local >nature of emergency service to protect agains DDoS? > >Mike > How do you determine that a call came from Berlin in time to block its effect as a denial of service? regards, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 08 16:18:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDSqc-0003F1-LB; Thu, 08 Sep 2005 16:18:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDSqZ-0003Et-3k for ecrit@megatron.ietf.org; Thu, 08 Sep 2005 16:18:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15322 for ; Thu, 8 Sep 2005 16:18:08 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDSu0-0006tH-A4 for ecrit@ietf.org; Thu, 08 Sep 2005 16:21:44 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 08 Sep 2005 13:18:02 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j88KHaKU020019 for ; Thu, 8 Sep 2005 13:17:55 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Sep 2005 13:17:38 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Sep 2005 13:17:38 -0700 From: "Marc Linsner" To: "'Michael Hammer \(mhammer\)'" , "'ECRIT'" Subject: RE: [Ecrit] Emergency Context RoutingofInternetTechnologies-Architecture Considerations Date: Thu, 8 Sep 2005 16:17:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E38A3CC8@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcW0nrEgg7FP1ZhNSGC2XzZaoHBB9wACdmtgAAINYoA= Message-ID: X-OriginalArrivalTime: 08 Sep 2005 20:17:38.0340 (UTC) FILETIME=[5B91FE40:01C5B4B2] X-Spam-Score: 2.9 (++) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org How about an employee of Berlin Industries, Inc. sitting at the Backwater Inn with a full vpn up to their corp. hq and calling for help. Wouldn't they look like they were coming from Berlin (the .ru domain and IP address would probably be a hint)? Do you want to block them? I certainly think that it is reasonable to raise a flag to the calltaker in this situation, but I wouldn't think you want to build a state machine to simply block such calls. Replace Berlin with New Hampshire, New York, Mass........ -Marc- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Michael Hammer (mhammer) > Sent: Thursday, September 08, 2005 3:12 PM > To: Ted Hardie; wilcox@e911.psd.state.vt.us; > br@brianrosen.net; Andrew Newton; Stastny Richard; ECRIT > Subject: RE: [Ecrit] Emergency Context > RoutingofInternetTechnologies-Architecture Considerations > > Ted, > > I'm confused. Are calls from Asia or Europe to the Vermont > PSAP ever legitimate? > > Somehow, I can't picture the local sheriff being able to help > someone in Berlin. I thought the point of i3 is to enable > the call to go to the local Berlin Polizei. Put another way, > is it possible to use the local nature of emergency service > to protect agains DDoS? > > Mike > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Ted Hardie > > Sent: Thursday, September 08, 2005 1:55 PM > > To: wilcox@e911.psd.state.vt.us; br@brianrosen.net; Andrew Newton; > > Stastny Richard; ECRIT > > Subject: RE: [Ecrit] Emergency Context Routing > > ofInternetTechnologies-Architecture Considerations > > > > After reading the thread, I wanted to come back to Nate's original > > concern and call something out: > > > > >Here is the PSAP concern: > > > > > >An enterprising thief could figure out that a business (without an > > >alarm > > >system) in Backwater, Vermont is served by a PSAP located 25 > > miles away. > > >If one creates an IP-based denial of service attack on that > > PSAP then > > >it is safe to assume that the target of opportunity that the > > thief is > > >looking at in Backwater will not be able to contact the PSAP > > to summon > > >help. > > > > I'm assuming that the PSAP being 25 miles away means nothing about > > where the responders are. The responders in this instance might be > > sheriffs, for example, who are stationed nearby, even > further than 25 > > miles away, or whose patrol routes mean that their distance > from the > > target of opportunity is variable. So I think we should cut the > > distance from this description completely, and simply see > the threat > > as "If the bad actor can determine which PSAP serves an > area in which > > a target is present, a successful attack on the PSAP prevents > > responses to the target". > > > > Does that make sense? > > > > > > > Using PSTN technologies, an enterprising thief could create > > a PSTN DoS > > >on the PSAP by simply using an auto call generator from a > pay phone > > >located in the same proximity as the target of opportunity > however, > > >this would still create a response to the general area of > the crime. > > > > There are lots of other kinds of PSTN attacks here--the > most commonly > > portrayed being "cutting the line", which doesn't work quite as it > > seems in the movies, but does have some effect. > > > > To avoid the locality problem in this attack, the bad actor > can use an > > accomplice, meat or mechanical, in any other area served by > the PSAP > > to do the same thing. This avoids the response hitting the general > > area of the crime. It also has the same counter-measure; > > call-blocking of the attacking phone. This counter-measure > is also > > relatively easy to accomplish with an IP-based service, > provided the > > attack is coming from a single IP or block. I believe the > problem is > > harder in the IP case not because the area from which the > attack can > > originate is larger but because it is easier to create a > Distributed > > Denial of Service, largely because of zombie networks and > IP spoofing. > > That is, if the attack is coming from Europe while the attack is > > happening on Backwater, my response is the same as if it came from > > Nearwater, VT: > > block the attack source. But if it is coming from Europe, Asia, > > Nearwater, Backwater, and many other points as well, > attempts to block > > the attack either requires effectively severing connectivity or > > maintaining a fair amount of information about who at the IP layer > > should be talking to this PSAP. We've discussed the > effectiveness of > > that in the past. > > > > >If I > > >know the URI of the PSAP, I can now distract it from another > > continent > > >and do what I would need to do in Backwater and no > response would be > > >created in that direction - that is the new paradigm with > > IP. If I know > > >the boundaries of the Derby PSAP, I could create a PSTN based DoS > > >attack anywhere from within that boundary (potentially 50 > miles from > > >Island Pond). > > > > > >Would this happen? I don't know - I am pretty sure it > hasn't yet but > > >assigning a URI to a PSAP opens it up to whole new generation of > > >"creative thinkers"..... > > > > > >Of course we can minimize the impact on the PSAP at a higher level > > >gateway by throwing a huge amount of bandwidth at it and > building in > > >intelligent alternative routing on a robust firewall. But > > that does not > > >help in the interim between here and there when someone gets their > > >hands on the PSAP boundaries and realizes the attacks they > > can initiate > > >using the PSTN DoS approach. > > > > The problem with the proposed solution, I believe, is that > aggregating > > the access to a back-to-back user agent or all-knowing > gateway is that > > you have simply created a richer target for attack. If I > can marshal > > a zombie group that takes out all of Vermont's PSAPs by eliminating > > the the gateway by DDoS, I have done far worse far more > easily than I > > could by individually attacking the PSAPs at their URIs. > If I did it > > in order to get at Backwater's target, I likely don't care that the > > general effect is larger--my purpose is met. > > > > Yes, it is easier to escalate the defenses at a single > point and yes, > > it is easier to pay for fat pipes for that single point. > But the bad > > actors here aren't using their own resources to attack you; > they are > > stealing them before trying to steal from you. Getting > into an arms > > race with someone who isn't spending their own money worries me. > > > > regards, > > Ted > > > > _______________________________________________ > > 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 Sep 08 16:56:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDTRq-0004xQ-Ao; Thu, 08 Sep 2005 16:56:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDTRm-0004vd-1J for ecrit@megatron.ietf.org; Thu, 08 Sep 2005 16:56:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17105 for ; Thu, 8 Sep 2005 16:56:35 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDTVD-0007tX-HQ for ecrit@ietf.org; Thu, 08 Sep 2005 17:00:12 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Sep 2005 13:56:28 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,179,1122879600"; d="scan'208"; a="8991508:sNHT25455656" 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 j88Ku6TQ008016 for ; Thu, 8 Sep 2005 16:56:26 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Sep 2005 16:56:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Emergency Context RoutingofInternetTechnologies-Architecture Considerations Date: Thu, 8 Sep 2005 16:56:24 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E38A3D56@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Emergency Context RoutingofInternetTechnologies-Architecture Considerations Thread-Index: AcW0nrEgg7FP1ZhNSGC2XzZaoHBB9wACdmtgAAINYoAAAYSasA== From: "Michael Hammer \(mhammer\)" To: "Marc Linsner \(mlinsner\)" , "ECRIT" X-OriginalArrivalTime: 08 Sep 2005 20:56:25.0565 (UTC) FILETIME=[C6B458D0:01C5B4B7] X-Spam-Score: 1.8 (+) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org That is certainly possible. I'm trying to get an idea of the assumed topology models here. If the call gets dropped, does the PSAP make an "international call" to call back such subscribers? Could the call back number be a number in some Caribbean island that happens to be a 9xx equivalent? Could Berlin Ind. send a 3xx response and say drop out of this VPN to make the call? In any case, your example proves the exception, so likely mine was a dead end thought. Mike > -----Original Message----- > From: Marc Linsner (mlinsner)=20 > Sent: Thursday, September 08, 2005 4:18 PM > To: Michael Hammer (mhammer); 'ECRIT' > Subject: RE: [Ecrit] Emergency Context=20 > RoutingofInternetTechnologies-Architecture Considerations >=20 > How about an employee of Berlin Industries, Inc. sitting at=20 > the Backwater Inn with a full vpn up to their corp. hq and=20 > calling for help. Wouldn't they look like they were coming=20 > from Berlin (the .ru domain and IP address would probably be=20 > a hint)? Do you want to block them? >=20 > I certainly think that it is reasonable to raise a flag to=20 > the calltaker in this situation, but I wouldn't think you=20 > want to build a state machine to simply block such calls. >=20 > Replace Berlin with New Hampshire, New York, Mass........ >=20 > -Marc- >=20 >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > > Of Michael Hammer (mhammer) > > Sent: Thursday, September 08, 2005 3:12 PM > > To: Ted Hardie; wilcox@e911.psd.state.vt.us;=20 > br@brianrosen.net; Andrew=20 > > Newton; Stastny Richard; ECRIT > > Subject: RE: [Ecrit] Emergency Context=20 > > RoutingofInternetTechnologies-Architecture Considerations > >=20 > > Ted, > >=20 > > I'm confused. Are calls from Asia or Europe to the Vermont=20 > PSAP ever=20 > > legitimate? > >=20 > > Somehow, I can't picture the local sheriff being able to=20 > help someone=20 > > in Berlin. I thought the point of i3 is to enable the call=20 > to go to=20 > > the local Berlin Polizei. Put another way, is it possible=20 > to use the=20 > > local nature of emergency service to protect agains DDoS? > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Ted Hardie > > > Sent: Thursday, September 08, 2005 1:55 PM > > > To: wilcox@e911.psd.state.vt.us; br@brianrosen.net;=20 > Andrew Newton;=20 > > > Stastny Richard; ECRIT > > > Subject: RE: [Ecrit] Emergency Context Routing=20 > > > ofInternetTechnologies-Architecture Considerations > > >=20 > > > After reading the thread, I wanted to come back to Nate's=20 > original=20 > > > concern and call something out: > > >=20 > > > >Here is the PSAP concern: > > > > > > > >An enterprising thief could figure out that a business=20 > (without an=20 > > > >alarm > > > >system) in Backwater, Vermont is served by a PSAP located 25 > > > miles away. > > > >If one creates an IP-based denial of service attack on that > > > PSAP then > > > >it is safe to assume that the target of opportunity that the > > > thief is > > > >looking at in Backwater will not be able to contact the PSAP > > > to summon > > > >help. > > >=20 > > > I'm assuming that the PSAP being 25 miles away means=20 > nothing about=20 > > > where the responders are. The responders in this=20 > instance might be=20 > > > sheriffs, for example, who are stationed nearby, even > > further than 25 > > > miles away, or whose patrol routes mean that their distance > > from the > > > target of opportunity is variable. So I think we should cut the=20 > > > distance from this description completely, and simply see > > the threat > > > as "If the bad actor can determine which PSAP serves an > > area in which > > > a target is present, a successful attack on the PSAP prevents=20 > > > responses to the target". > > >=20 > > > Does that make sense? > > >=20 > > >=20 > > > > Using PSTN technologies, an enterprising thief could create > > > a PSTN DoS > > > >on the PSAP by simply using an auto call generator from a > > pay phone > > > >located in the same proximity as the target of opportunity > > however, > > > >this would still create a response to the general area of > > the crime. > > >=20 > > > There are lots of other kinds of PSTN attacks here--the > > most commonly > > > portrayed being "cutting the line", which doesn't work=20 > quite as it=20 > > > seems in the movies, but does have some effect. > > >=20 > > > To avoid the locality problem in this attack, the bad actor > > can use an > > > accomplice, meat or mechanical, in any other area served by > > the PSAP > > > to do the same thing. This avoids the response hitting=20 > the general=20 > > > area of the crime. It also has the same counter-measure;=20 > > > call-blocking of the attacking phone. This counter-measure > > is also > > > relatively easy to accomplish with an IP-based service, > > provided the > > > attack is coming from a single IP or block. I believe the > > problem is > > > harder in the IP case not because the area from which the > > attack can > > > originate is larger but because it is easier to create a > > Distributed > > > Denial of Service, largely because of zombie networks and > > IP spoofing. > > > That is, if the attack is coming from Europe while the attack is=20 > > > happening on Backwater, my response is the same as if it=20 > came from=20 > > > Nearwater, VT: > > > block the attack source. But if it is coming from Europe, Asia,=20 > > > Nearwater, Backwater, and many other points as well, > > attempts to block > > > the attack either requires effectively severing connectivity or=20 > > > maintaining a fair amount of information about who at the=20 > IP layer=20 > > > should be talking to this PSAP. We've discussed the > > effectiveness of > > > that in the past. > > >=20 > > > >If I > > > >know the URI of the PSAP, I can now distract it from another > > > continent > > > >and do what I would need to do in Backwater and no > > response would be > > > >created in that direction - that is the new paradigm with > > > IP. If I know > > > >the boundaries of the Derby PSAP, I could create a PSTN=20 > based DoS=20 > > > >attack anywhere from within that boundary (potentially 50 > > miles from > > > >Island Pond). > > > > > > > >Would this happen? I don't know - I am pretty sure it > > hasn't yet but > > > >assigning a URI to a PSAP opens it up to whole new generation of=20 > > > >"creative thinkers"..... > > > > > > > >Of course we can minimize the impact on the PSAP at a=20 > higher level=20 > > > >gateway by throwing a huge amount of bandwidth at it and > > building in > > > >intelligent alternative routing on a robust firewall. But > > > that does not > > > >help in the interim between here and there when someone=20 > gets their=20 > > > >hands on the PSAP boundaries and realizes the attacks they > > > can initiate > > > >using the PSTN DoS approach. > > >=20 > > > The problem with the proposed solution, I believe, is that > > aggregating > > > the access to a back-to-back user agent or all-knowing > > gateway is that > > > you have simply created a richer target for attack. If I > > can marshal > > > a zombie group that takes out all of Vermont's PSAPs by=20 > eliminating=20 > > > the the gateway by DDoS, I have done far worse far more > > easily than I > > > could by individually attacking the PSAPs at their URIs. =20 > > If I did it > > > in order to get at Backwater's target, I likely don't=20 > care that the=20 > > > general effect is larger--my purpose is met. > > >=20 > > > Yes, it is easier to escalate the defenses at a single > > point and yes, > > > it is easier to pay for fat pipes for that single point. =20 > > But the bad > > > actors here aren't using their own resources to attack you; > > they are > > > stealing them before trying to steal from you. Getting > > into an arms > > > race with someone who isn't spending their own money worries me. > > >=20 > > > regards, > > > Ted > > >=20 > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 08 17:54:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDULp-0004Te-Dw; Thu, 08 Sep 2005 17:54:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDULo-0004TW-F3 for ecrit@megatron.ietf.org; Thu, 08 Sep 2005 17:54:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20344 for ; Thu, 8 Sep 2005 17:54:29 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EDUPE-0001B4-Uy for ecrit@ietf.org; Thu, 08 Sep 2005 17:58:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: Re: [Ecrit] Emergency ContextRoutingofInternetTechnologies-Architecture Considerations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Sep 2005 23:58:01 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C44DC@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Emergency ContextRoutingofInternetTechnologies-Architecture Considerations Thread-Index: AcW0nrEgg7FP1ZhNSGC2XzZaoHBB9wACdmtgAAINYoAAAYSasAACMead From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "Marc Linsner \(mlinsner\)" , "ECRIT" X-Spam-Score: 1.8 (+) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Sorry, but I am confused with this examples: =20 Somebody sitting say in Chicago should get routed to a local PSAP in = Chicago, regardless where his provider or sip-server is located If he is using a VPN to say a network in Berlin, he may either also get routed by some magic we still have to work out also to a PSAP in = Chicago, or he is routed wrongly to a PSAP in Berlin. But, the PSAP in Berlin will at least get some location and also some identification from Berlin, at the network, so there is some local relationship =20 So what is the point? =20 -richard ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) Gesendet: Do 08.09.2005 22:56 An: Marc Linsner (mlinsner); ECRIT Betreff: RE: [Ecrit] Emergency = ContextRoutingofInternetTechnologies-Architecture Considerations That is certainly possible. I'm trying to get an idea of the assumed topology models here. If the call gets dropped, does the PSAP make an "international call" to call back such subscribers? Could the call back number be a number in some Caribbean island that happens to be a 9xx equivalent? Could Berlin Ind. send a 3xx response and say drop out of this VPN to make the call? In any case, your example proves the exception, so likely mine was a dead end thought. Mike > -----Original Message----- > From: Marc Linsner (mlinsner) > Sent: Thursday, September 08, 2005 4:18 PM > To: Michael Hammer (mhammer); 'ECRIT' > Subject: RE: [Ecrit] Emergency Context > RoutingofInternetTechnologies-Architecture Considerations > > How about an employee of Berlin Industries, Inc. sitting at > the Backwater Inn with a full vpn up to their corp. hq and > calling for help. Wouldn't they look like they were coming > from Berlin (the .ru domain and IP address would probably be > a hint)? Do you want to block them? > > I certainly think that it is reasonable to raise a flag to > the calltaker in this situation, but I wouldn't think you > want to build a state machine to simply block such calls. > > Replace Berlin with New Hampshire, New York, Mass........ > > -Marc- > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Michael Hammer (mhammer) > > Sent: Thursday, September 08, 2005 3:12 PM > > To: Ted Hardie; wilcox@e911.psd.state.vt.us; > br@brianrosen.net; Andrew > > Newton; Stastny Richard; ECRIT > > Subject: RE: [Ecrit] Emergency Context > > RoutingofInternetTechnologies-Architecture Considerations > > > > Ted, > > > > I'm confused. Are calls from Asia or Europe to the Vermont > PSAP ever > > legitimate? > > > > Somehow, I can't picture the local sheriff being able to > help someone > > in Berlin. I thought the point of i3 is to enable the call > to go to > > the local Berlin Polizei. Put another way, is it possible > to use the > > local nature of emergency service to protect agains DDoS? > > > > Mike > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Ted Hardie > > > Sent: Thursday, September 08, 2005 1:55 PM > > > To: wilcox@e911.psd.state.vt.us; br@brianrosen.net; > Andrew Newton; > > > Stastny Richard; ECRIT > > > Subject: RE: [Ecrit] Emergency Context Routing > > > ofInternetTechnologies-Architecture Considerations > > > > > > After reading the thread, I wanted to come back to Nate's > original > > > concern and call something out: > > > > > > >Here is the PSAP concern: > > > > > > > >An enterprising thief could figure out that a business > (without an > > > >alarm > > > >system) in Backwater, Vermont is served by a PSAP located 25 > > > miles away. > > > >If one creates an IP-based denial of service attack on that > > > PSAP then > > > >it is safe to assume that the target of opportunity that the > > > thief is > > > >looking at in Backwater will not be able to contact the PSAP > > > to summon > > > >help. > > > > > > I'm assuming that the PSAP being 25 miles away means > nothing about > > > where the responders are. The responders in this > instance might be > > > sheriffs, for example, who are stationed nearby, even > > further than 25 > > > miles away, or whose patrol routes mean that their distance > > from the > > > target of opportunity is variable. So I think we should cut the > > > distance from this description completely, and simply see > > the threat > > > as "If the bad actor can determine which PSAP serves an > > area in which > > > a target is present, a successful attack on the PSAP prevents > > > responses to the target". > > > > > > Does that make sense? > > > > > > > > > > Using PSTN technologies, an enterprising thief could create > > > a PSTN DoS > > > >on the PSAP by simply using an auto call generator from a > > pay phone > > > >located in the same proximity as the target of opportunity > > however, > > > >this would still create a response to the general area of > > the crime. > > > > > > There are lots of other kinds of PSTN attacks here--the > > most commonly > > > portrayed being "cutting the line", which doesn't work > quite as it > > > seems in the movies, but does have some effect. > > > > > > To avoid the locality problem in this attack, the bad actor > > can use an > > > accomplice, meat or mechanical, in any other area served by > > the PSAP > > > to do the same thing. This avoids the response hitting > the general > > > area of the crime. It also has the same counter-measure; > > > call-blocking of the attacking phone. This counter-measure > > is also > > > relatively easy to accomplish with an IP-based service, > > provided the > > > attack is coming from a single IP or block. I believe the > > problem is > > > harder in the IP case not because the area from which the > > attack can > > > originate is larger but because it is easier to create a > > Distributed > > > Denial of Service, largely because of zombie networks and > > IP spoofing. > > > That is, if the attack is coming from Europe while the attack is > > > happening on Backwater, my response is the same as if it > came from > > > Nearwater, VT: > > > block the attack source. But if it is coming from Europe, Asia, > > > Nearwater, Backwater, and many other points as well, > > attempts to block > > > the attack either requires effectively severing connectivity or > > > maintaining a fair amount of information about who at the > IP layer > > > should be talking to this PSAP. We've discussed the > > effectiveness of > > > that in the past. > > > > > > >If I > > > >know the URI of the PSAP, I can now distract it from another > > > continent > > > >and do what I would need to do in Backwater and no > > response would be > > > >created in that direction - that is the new paradigm with > > > IP. If I know > > > >the boundaries of the Derby PSAP, I could create a PSTN > based DoS > > > >attack anywhere from within that boundary (potentially 50 > > miles from > > > >Island Pond). > > > > > > > >Would this happen? I don't know - I am pretty sure it > > hasn't yet but > > > >assigning a URI to a PSAP opens it up to whole new generation of > > > >"creative thinkers"..... > > > > > > > >Of course we can minimize the impact on the PSAP at a > higher level > > > >gateway by throwing a huge amount of bandwidth at it and > > building in > > > >intelligent alternative routing on a robust firewall. But > > > that does not > > > >help in the interim between here and there when someone > gets their > > > >hands on the PSAP boundaries and realizes the attacks they > > > can initiate > > > >using the PSTN DoS approach. > > > > > > The problem with the proposed solution, I believe, is that > > aggregating > > > the access to a back-to-back user agent or all-knowing > > gateway is that > > > you have simply created a richer target for attack. If I > > can marshal > > > a zombie group that takes out all of Vermont's PSAPs by > eliminating > > > the the gateway by DDoS, I have done far worse far more > > easily than I > > > could by individually attacking the PSAPs at their URIs.=20 > > If I did it > > > in order to get at Backwater's target, I likely don't > care that the > > > general effect is larger--my purpose is met. > > > > > > Yes, it is easier to escalate the defenses at a single > > point and yes, > > > it is easier to pay for fat pipes for that single point.=20 > > But the bad > > > actors here aren't using their own resources to attack you; > > they are > > > stealing them before trying to steal from you. Getting > > into an arms > > > race with someone who isn't spending their own money worries me. > > > > > > regards, > > > Ted > > > > > > _______________________________________________ > > > 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 Thu Sep 08 18:26:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDUqU-0003Vd-0m; Thu, 08 Sep 2005 18:26:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDUqT-0003VU-9L for ecrit@megatron.ietf.org; Thu, 08 Sep 2005 18:26:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22586 for ; Thu, 8 Sep 2005 18:26:09 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDUtv-0001rm-CM for ecrit@ietf.org; Thu, 08 Sep 2005 18:29:47 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 08 Sep 2005 18:26:04 -0400 X-IronPort-AV: i="3.96,180,1122868800"; d="scan'208"; a="69539651:sNHT796310642" 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 j88MPbR9000049; Thu, 8 Sep 2005 18:26:01 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Sep 2005 18:26:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Emergency ContextRoutingofInternetTechnologies-Architecture Considerations Date: Thu, 8 Sep 2005 18:25:58 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E38A3DAA@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Emergency ContextRoutingofInternetTechnologies-Architecture Considerations Thread-Index: AcW0nrEgg7FP1ZhNSGC2XzZaoHBB9wACdmtgAAINYoAAAYSasAACMeadAAD+zbA= From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "Marc Linsner \(mlinsner\)" , "ECRIT" X-OriginalArrivalTime: 08 Sep 2005 22:26:00.0053 (UTC) FILETIME=[4A262250:01C5B4C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Richard, My original question was about whether a PSAP should expect calls (signaling and media) to originate from non-local destinations, e.g. international, and by inference the need for the PSAPs to be able to make call backs to those locations. If not, then perhaps it is a DDoS clue. Marc pointed out the VPN possibility. You seem to suggest that emergency calls should never go by VPN when dialed. So, is the VPN situation a possibility or precluded? Mike > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Thursday, September 08, 2005 5:58 PM > To: Michael Hammer (mhammer); Marc Linsner (mlinsner); ECRIT > Subject: Re: [Ecrit] Emergency=20 > ContextRoutingofInternetTechnologies-Architecture Considerations >=20 > Sorry, but I am confused with this examples: > =20 > Somebody sitting say in Chicago should get routed to a local=20 > PSAP in Chicago, regardless where his provider or sip-server=20 > is located >=20 > If he is using a VPN to say a network in Berlin, he may=20 > either also get routed by some magic we still have to work=20 > out also to a PSAP in Chicago, or he is routed wrongly to a=20 > PSAP in Berlin. >=20 > But, the PSAP in Berlin will at least get some location and=20 > also some identification from Berlin, at the network, so=20 > there is some local relationship > =20 > So what is the point? > =20 > -richard >=20 > ________________________________ >=20 > Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) > Gesendet: Do 08.09.2005 22:56 > An: Marc Linsner (mlinsner); ECRIT > Betreff: RE: [Ecrit] Emergency=20 > ContextRoutingofInternetTechnologies-Architecture Considerations >=20 >=20 >=20 > That is certainly possible. I'm trying to get an idea of the=20 > assumed topology models here. If the call gets dropped, does=20 > the PSAP make an "international call" to call back such=20 > subscribers? Could the call back number be a number in some=20 > Caribbean island that happens to be a 9xx equivalent? Could=20 > Berlin Ind. send a 3xx response and say drop out of this VPN=20 > to make the call? >=20 > In any case, your example proves the exception, so likely=20 > mine was a dead end thought. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Marc Linsner (mlinsner) > > Sent: Thursday, September 08, 2005 4:18 PM > > To: Michael Hammer (mhammer); 'ECRIT' > > Subject: RE: [Ecrit] Emergency Context=20 > > RoutingofInternetTechnologies-Architecture Considerations > > > > How about an employee of Berlin Industries, Inc. sitting at the=20 > > Backwater Inn with a full vpn up to their corp. hq and calling for=20 > > help. Wouldn't they look like they were coming from Berlin=20 > (the .ru=20 > > domain and IP address would probably be a hint)? Do you=20 > want to block=20 > > them? > > > > I certainly think that it is reasonable to raise a flag to the=20 > > calltaker in this situation, but I wouldn't think you want=20 > to build a=20 > > state machine to simply block such calls. > > > > Replace Berlin with New Hampshire, New York, Mass........ > > > > -Marc- > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Michael Hammer (mhammer) > > > Sent: Thursday, September 08, 2005 3:12 PM > > > To: Ted Hardie; wilcox@e911.psd.state.vt.us; > > br@brianrosen.net; Andrew > > > Newton; Stastny Richard; ECRIT > > > Subject: RE: [Ecrit] Emergency Context=20 > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > Ted, > > > > > > I'm confused. Are calls from Asia or Europe to the Vermont > > PSAP ever > > > legitimate? > > > > > > Somehow, I can't picture the local sheriff being able to > > help someone > > > in Berlin. I thought the point of i3 is to enable the call > > to go to > > > the local Berlin Polizei. Put another way, is it possible > > to use the > > > local nature of emergency service to protect agains DDoS? > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of Ted Hardie > > > > Sent: Thursday, September 08, 2005 1:55 PM > > > > To: wilcox@e911.psd.state.vt.us; br@brianrosen.net; > > Andrew Newton; > > > > Stastny Richard; ECRIT > > > > Subject: RE: [Ecrit] Emergency Context Routing=20 > > > > ofInternetTechnologies-Architecture Considerations > > > > > > > > After reading the thread, I wanted to come back to Nate's > > original > > > > concern and call something out: > > > > > > > > >Here is the PSAP concern: > > > > > > > > > >An enterprising thief could figure out that a business > > (without an > > > > >alarm > > > > >system) in Backwater, Vermont is served by a PSAP located 25 > > > > miles away. > > > > >If one creates an IP-based denial of service attack on that > > > > PSAP then > > > > >it is safe to assume that the target of opportunity that the > > > > thief is > > > > >looking at in Backwater will not be able to contact the PSAP > > > > to summon > > > > >help. > > > > > > > > I'm assuming that the PSAP being 25 miles away means > > nothing about > > > > where the responders are. The responders in this > > instance might be > > > > sheriffs, for example, who are stationed nearby, even > > > further than 25 > > > > miles away, or whose patrol routes mean that their distance > > > from the > > > > target of opportunity is variable. So I think we=20 > should cut the=20 > > > > distance from this description completely, and simply see > > > the threat > > > > as "If the bad actor can determine which PSAP serves an > > > area in which > > > > a target is present, a successful attack on the PSAP prevents=20 > > > > responses to the target". > > > > > > > > Does that make sense? > > > > > > > > > > > > > Using PSTN technologies, an enterprising thief could create > > > > a PSTN DoS > > > > >on the PSAP by simply using an auto call generator from a > > > pay phone > > > > >located in the same proximity as the target of opportunity > > > however, > > > > >this would still create a response to the general area of > > > the crime. > > > > > > > > There are lots of other kinds of PSTN attacks here--the > > > most commonly > > > > portrayed being "cutting the line", which doesn't work > > quite as it > > > > seems in the movies, but does have some effect. > > > > > > > > To avoid the locality problem in this attack, the bad actor > > > can use an > > > > accomplice, meat or mechanical, in any other area served by > > > the PSAP > > > > to do the same thing. This avoids the response hitting > > the general > > > > area of the crime. It also has the same counter-measure;=20 > > > > call-blocking of the attacking phone. This counter-measure > > > is also > > > > relatively easy to accomplish with an IP-based service, > > > provided the > > > > attack is coming from a single IP or block. I believe the > > > problem is > > > > harder in the IP case not because the area from which the > > > attack can > > > > originate is larger but because it is easier to create a > > > Distributed > > > > Denial of Service, largely because of zombie networks and > > > IP spoofing. > > > > That is, if the attack is coming from Europe while the=20 > attack is=20 > > > > happening on Backwater, my response is the same as if it > > came from > > > > Nearwater, VT: > > > > block the attack source. But if it is coming from=20 > Europe, Asia,=20 > > > > Nearwater, Backwater, and many other points as well, > > > attempts to block > > > > the attack either requires effectively severing connectivity or=20 > > > > maintaining a fair amount of information about who at the > > IP layer > > > > should be talking to this PSAP. We've discussed the > > > effectiveness of > > > > that in the past. > > > > > > > > >If I > > > > >know the URI of the PSAP, I can now distract it from another > > > > continent > > > > >and do what I would need to do in Backwater and no > > > response would be > > > > >created in that direction - that is the new paradigm with > > > > IP. If I know > > > > >the boundaries of the Derby PSAP, I could create a PSTN > > based DoS > > > > >attack anywhere from within that boundary (potentially 50 > > > miles from > > > > >Island Pond). > > > > > > > > > >Would this happen? I don't know - I am pretty sure it > > > hasn't yet but > > > > >assigning a URI to a PSAP opens it up to whole new=20 > generation of=20 > > > > >"creative thinkers"..... > > > > > > > > > >Of course we can minimize the impact on the PSAP at a > > higher level > > > > >gateway by throwing a huge amount of bandwidth at it and > > > building in > > > > >intelligent alternative routing on a robust firewall. But > > > > that does not > > > > >help in the interim between here and there when someone > > gets their > > > > >hands on the PSAP boundaries and realizes the attacks they > > > > can initiate > > > > >using the PSTN DoS approach. > > > > > > > > The problem with the proposed solution, I believe, is that > > > aggregating > > > > the access to a back-to-back user agent or all-knowing > > > gateway is that > > > > you have simply created a richer target for attack. If I > > > can marshal > > > > a zombie group that takes out all of Vermont's PSAPs by > > eliminating > > > > the the gateway by DDoS, I have done far worse far more > > > easily than I > > > > could by individually attacking the PSAPs at their URIs.=20 > > > If I did it > > > > in order to get at Backwater's target, I likely don't > > care that the > > > > general effect is larger--my purpose is met. > > > > > > > > Yes, it is easier to escalate the defenses at a single > > > point and yes, > > > > it is easier to pay for fat pipes for that single point.=20 > > > But the bad > > > > actors here aren't using their own resources to attack you; > > > they are > > > > stealing them before trying to steal from you. Getting > > > into an arms > > > > race with someone who isn't spending their own money worries me. > > > > > > > > regards, > > > > Ted > > > > > > > > _______________________________________________ > > > > 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 Sep 08 19:14:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDVal-0002vn-Ks; Thu, 08 Sep 2005 19:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDVaj-0002v3-AB for ecrit@megatron.ietf.org; Thu, 08 Sep 2005 19:14:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00619 for ; Thu, 8 Sep 2005 19:13:57 -0400 (EDT) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDVe8-00055V-Dh for ecrit@ietf.org; Thu, 08 Sep 2005 19:17:35 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j88NBD2f011052 for ; Thu, 8 Sep 2005 19:11:13 -0400 (EDT) Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j88NBC2f011030 for ; Thu, 8 Sep 2005 19:11:12 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies-Architecture Considerations Date: Thu, 8 Sep 2005 19:13:53 -0400 Message-ID: Thread-Topic: [Ecrit] EmergencyContextRoutingofInternetTechnologies-Architecture Considerations Thread-Index: AcW0nrEgg7FP1ZhNSGC2XzZaoHBB9wACdmtgAAINYoAAAYSasAACMeadAAD+zbAAAKghwA== From: "Rodrig, Benny \(Benny\)" To: "Michael Hammer \(mhammer\)" , "Stastny Richard" , "Marc Linsner \(mlinsner\)" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Not sure it's always possible for emergency calls to not go though the corporate VPN. For example, the endpoint may have no means (e.g. no TURN server) to establish a session directly through the NAT at the Backwater Inn, in the example below. Benny =20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Michael Hammer (mhammer) Sent: Thursday, September 08, 2005 6:26 PM To: Stastny Richard; Marc Linsner (mlinsner); ECRIT Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies-Architecture Considerations Richard, My original question was about whether a PSAP should expect calls (signaling and media) to originate from non-local destinations, e.g. international, and by inference the need for the PSAPs to be able to make call backs to those locations. If not, then perhaps it is a DDoS clue. Marc pointed out the VPN possibility. You seem to suggest that emergency calls should never go by VPN when dialed. So, is the VPN situation a possibility or precluded? Mike > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, September 08, 2005 5:58 PM > To: Michael Hammer (mhammer); Marc Linsner (mlinsner); ECRIT > Subject: Re: [Ecrit] Emergency > ContextRoutingofInternetTechnologies-Architecture Considerations >=20 > Sorry, but I am confused with this examples: > =20 > Somebody sitting say in Chicago should get routed to a local PSAP in=20 > Chicago, regardless where his provider or sip-server is located >=20 > If he is using a VPN to say a network in Berlin, he may either also=20 > get routed by some magic we still have to work out also to a PSAP in=20 > Chicago, or he is routed wrongly to a PSAP in Berlin. >=20 > But, the PSAP in Berlin will at least get some location and also some=20 > identification from Berlin, at the network, so there is some local=20 > relationship > =20 > So what is the point? > =20 > -richard >=20 > ________________________________ >=20 > Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) > Gesendet: Do 08.09.2005 22:56 > An: Marc Linsner (mlinsner); ECRIT > Betreff: RE: [Ecrit] Emergency > ContextRoutingofInternetTechnologies-Architecture Considerations >=20 >=20 >=20 > That is certainly possible. I'm trying to get an idea of the assumed=20 > topology models here. If the call gets dropped, does the PSAP make an > "international call" to call back such subscribers? Could the call=20 > back number be a number in some Caribbean island that happens to be a=20 > 9xx equivalent? Could Berlin Ind. send a 3xx response and say drop=20 > out of this VPN to make the call? >=20 > In any case, your example proves the exception, so likely mine was a=20 > dead end thought. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Marc Linsner (mlinsner) > > Sent: Thursday, September 08, 2005 4:18 PM > > To: Michael Hammer (mhammer); 'ECRIT' > > Subject: RE: [Ecrit] Emergency Context=20 > > RoutingofInternetTechnologies-Architecture Considerations > > > > How about an employee of Berlin Industries, Inc. sitting at the=20 > > Backwater Inn with a full vpn up to their corp. hq and calling for=20 > > help. Wouldn't they look like they were coming from Berlin > (the .ru > > domain and IP address would probably be a hint)? Do you > want to block > > them? > > > > I certainly think that it is reasonable to raise a flag to the=20 > > calltaker in this situation, but I wouldn't think you want > to build a > > state machine to simply block such calls. > > > > Replace Berlin with New Hampshire, New York, Mass........ > > > > -Marc- > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Michael Hammer (mhammer) > > > Sent: Thursday, September 08, 2005 3:12 PM > > > To: Ted Hardie; wilcox@e911.psd.state.vt.us; > > br@brianrosen.net; Andrew > > > Newton; Stastny Richard; ECRIT > > > Subject: RE: [Ecrit] Emergency Context=20 > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > Ted, > > > > > > I'm confused. Are calls from Asia or Europe to the Vermont > > PSAP ever > > > legitimate? > > > > > > Somehow, I can't picture the local sheriff being able to > > help someone > > > in Berlin. I thought the point of i3 is to enable the call > > to go to > > > the local Berlin Polizei. Put another way, is it possible > > to use the > > > local nature of emergency service to protect agains DDoS? > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of Ted Hardie > > > > Sent: Thursday, September 08, 2005 1:55 PM > > > > To: wilcox@e911.psd.state.vt.us; br@brianrosen.net; > > Andrew Newton; > > > > Stastny Richard; ECRIT > > > > Subject: RE: [Ecrit] Emergency Context Routing=20 > > > > ofInternetTechnologies-Architecture Considerations > > > > > > > > After reading the thread, I wanted to come back to Nate's > > original > > > > concern and call something out: > > > > > > > > >Here is the PSAP concern: > > > > > > > > > >An enterprising thief could figure out that a business > > (without an > > > > >alarm > > > > >system) in Backwater, Vermont is served by a PSAP located 25 > > > > miles away. > > > > >If one creates an IP-based denial of service attack on that > > > > PSAP then > > > > >it is safe to assume that the target of opportunity that the > > > > thief is > > > > >looking at in Backwater will not be able to contact the PSAP > > > > to summon > > > > >help. > > > > > > > > I'm assuming that the PSAP being 25 miles away means > > nothing about > > > > where the responders are. The responders in this > > instance might be > > > > sheriffs, for example, who are stationed nearby, even > > > further than 25 > > > > miles away, or whose patrol routes mean that their distance > > > from the > > > > target of opportunity is variable. So I think we > should cut the > > > > distance from this description completely, and simply see > > > the threat > > > > as "If the bad actor can determine which PSAP serves an > > > area in which > > > > a target is present, a successful attack on the PSAP prevents=20 > > > > responses to the target". > > > > > > > > Does that make sense? > > > > > > > > > > > > > Using PSTN technologies, an enterprising thief could create > > > > a PSTN DoS > > > > >on the PSAP by simply using an auto call generator from a > > > pay phone > > > > >located in the same proximity as the target of opportunity > > > however, > > > > >this would still create a response to the general area of > > > the crime. > > > > > > > > There are lots of other kinds of PSTN attacks here--the > > > most commonly > > > > portrayed being "cutting the line", which doesn't work > > quite as it > > > > seems in the movies, but does have some effect. > > > > > > > > To avoid the locality problem in this attack, the bad actor > > > can use an > > > > accomplice, meat or mechanical, in any other area served by > > > the PSAP > > > > to do the same thing. This avoids the response hitting > > the general > > > > area of the crime. It also has the same counter-measure;=20 > > > > call-blocking of the attacking phone. This counter-measure > > > is also > > > > relatively easy to accomplish with an IP-based service, > > > provided the > > > > attack is coming from a single IP or block. I believe the > > > problem is > > > > harder in the IP case not because the area from which the > > > attack can > > > > originate is larger but because it is easier to create a > > > Distributed > > > > Denial of Service, largely because of zombie networks and > > > IP spoofing. > > > > That is, if the attack is coming from Europe while the > attack is > > > > happening on Backwater, my response is the same as if it > > came from > > > > Nearwater, VT: > > > > block the attack source. But if it is coming from > Europe, Asia, > > > > Nearwater, Backwater, and many other points as well, > > > attempts to block > > > > the attack either requires effectively severing connectivity or=20 > > > > maintaining a fair amount of information about who at the > > IP layer > > > > should be talking to this PSAP. We've discussed the > > > effectiveness of > > > > that in the past. > > > > > > > > >If I > > > > >know the URI of the PSAP, I can now distract it from another > > > > continent > > > > >and do what I would need to do in Backwater and no > > > response would be > > > > >created in that direction - that is the new paradigm with > > > > IP. If I know > > > > >the boundaries of the Derby PSAP, I could create a PSTN > > based DoS > > > > >attack anywhere from within that boundary (potentially 50 > > > miles from > > > > >Island Pond). > > > > > > > > > >Would this happen? I don't know - I am pretty sure it > > > hasn't yet but > > > > >assigning a URI to a PSAP opens it up to whole new > generation of > > > > >"creative thinkers"..... > > > > > > > > > >Of course we can minimize the impact on the PSAP at a > > higher level > > > > >gateway by throwing a huge amount of bandwidth at it and > > > building in > > > > >intelligent alternative routing on a robust firewall. But > > > > that does not > > > > >help in the interim between here and there when someone > > gets their > > > > >hands on the PSAP boundaries and realizes the attacks they > > > > can initiate > > > > >using the PSTN DoS approach. > > > > > > > > The problem with the proposed solution, I believe, is that > > > aggregating > > > > the access to a back-to-back user agent or all-knowing > > > gateway is that > > > > you have simply created a richer target for attack. If I > > > can marshal > > > > a zombie group that takes out all of Vermont's PSAPs by > > eliminating > > > > the the gateway by DDoS, I have done far worse far more > > > easily than I > > > > could by individually attacking the PSAPs at their URIs.=20 > > > If I did it > > > > in order to get at Backwater's target, I likely don't > > care that the > > > > general effect is larger--my purpose is met. > > > > > > > > Yes, it is easier to escalate the defenses at a single > > > point and yes, > > > > it is easier to pay for fat pipes for that single point.=20 > > > But the bad > > > > actors here aren't using their own resources to attack you; > > > they are > > > > stealing them before trying to steal from you. Getting > > > into an arms > > > > race with someone who isn't spending their own money worries me. > > > > > > > > regards, > > > > Ted > > > > > > > > _______________________________________________ > > > > 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 08 19:29:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDVpw-00009d-VL; Thu, 08 Sep 2005 19:29:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDVpv-00009Y-EJ for ecrit@megatron.ietf.org; Thu, 08 Sep 2005 19:29:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05225 for ; Thu, 8 Sep 2005 19:29:39 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDVtO-0006pj-Cl for ecrit@ietf.org; Thu, 08 Sep 2005 19:33:18 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Sep 2005 18:29:27 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 08 Sep 2005 18:29:27 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Sep 2005 18:29:26 -0500 Message-ID: From: "Winterbottom, James" To: "Michael Hammer \(mhammer\)" , "Stastny Richard" , "Marc Linsner \(mlinsner\)" , "ECRIT" Date: Thu, 8 Sep 2005 18:29:24 -0500 Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies-ArchitectureConsiderations MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 08 Sep 2005 23:29:26.0784 (UTC) FILETIME=[27233000:01C5B4CD] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] EmergencyContextRoutingofInternetTechnologies-ArchitectureConsiderations Thread-Index: AcW0nrEgg7FP1ZhNSGC2XzZaoHBB9wACdmtgAAINYoAAAYSasAACMeadAAD+zbAAAKghwAABpFAw X-Spam-Score: 0.2 (/) X-Scan-Signature: 1a2f5df4c6f30e0d5df43748fb095119 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This issue has been discussed in NENA at quite some length. The consensus that is growing there, and I know that there are some people that still disagree, is that if an enterprise is prepared to allow this to occur, that the onus is on the enterprise to ensure that it works. This makes the problem a little easier to deal with. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Rodrig, Benny (Benny) > Sent: Friday, 9 September 2005 9:14 AM > To: Michael Hammer (mhammer); Stastny Richard; Marc Linsner (mlinsner); > ECRIT > Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies- > ArchitectureConsiderations >=20 > Not sure it's always possible for emergency calls to not go though the > corporate VPN. For example, the endpoint may have no means (e.g. no TURN > server) to establish a session directly through the NAT at the Backwater > Inn, in the example below. >=20 > Benny >=20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Michael Hammer (mhammer) > Sent: Thursday, September 08, 2005 6:26 PM > To: Stastny Richard; Marc Linsner (mlinsner); ECRIT > Subject: RE: [Ecrit] > EmergencyContextRoutingofInternetTechnologies-Architecture > Considerations >=20 > Richard, >=20 > My original question was about whether a PSAP should expect calls > (signaling and media) to originate from non-local destinations, e.g. > international, and by inference the need for the PSAPs to be able to > make call backs to those locations. If not, then perhaps it is a DDoS > clue. >=20 > Marc pointed out the VPN possibility. >=20 > You seem to suggest that emergency calls should never go by VPN when > dialed. >=20 > So, is the VPN situation a possibility or precluded? >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, September 08, 2005 5:58 PM > > To: Michael Hammer (mhammer); Marc Linsner (mlinsner); ECRIT > > Subject: Re: [Ecrit] Emergency > > ContextRoutingofInternetTechnologies-Architecture Considerations > > > > Sorry, but I am confused with this examples: > > > > Somebody sitting say in Chicago should get routed to a local PSAP in > > Chicago, regardless where his provider or sip-server is located > > > > If he is using a VPN to say a network in Berlin, he may either also > > get routed by some magic we still have to work out also to a PSAP in > > Chicago, or he is routed wrongly to a PSAP in Berlin. > > > > But, the PSAP in Berlin will at least get some location and also some > > identification from Berlin, at the network, so there is some local > > relationship > > > > So what is the point? > > > > -richard > > > > ________________________________ > > > > Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) > > Gesendet: Do 08.09.2005 22:56 > > An: Marc Linsner (mlinsner); ECRIT > > Betreff: RE: [Ecrit] Emergency > > ContextRoutingofInternetTechnologies-Architecture Considerations > > > > > > > > That is certainly possible. I'm trying to get an idea of the assumed > > topology models here. If the call gets dropped, does the PSAP make an >=20 > > "international call" to call back such subscribers? Could the call > > back number be a number in some Caribbean island that happens to be a > > 9xx equivalent? Could Berlin Ind. send a 3xx response and say drop > > out of this VPN to make the call? > > > > In any case, your example proves the exception, so likely mine was a > > dead end thought. > > > > Mike > > > > > > > -----Original Message----- > > > From: Marc Linsner (mlinsner) > > > Sent: Thursday, September 08, 2005 4:18 PM > > > To: Michael Hammer (mhammer); 'ECRIT' > > > Subject: RE: [Ecrit] Emergency Context > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > How about an employee of Berlin Industries, Inc. sitting at the > > > Backwater Inn with a full vpn up to their corp. hq and calling for > > > help. Wouldn't they look like they were coming from Berlin > > (the .ru > > > domain and IP address would probably be a hint)? Do you > > want to block > > > them? > > > > > > I certainly think that it is reasonable to raise a flag to the > > > calltaker in this situation, but I wouldn't think you want > > to build a > > > state machine to simply block such calls. > > > > > > Replace Berlin with New Hampshire, New York, Mass........ > > > > > > -Marc- > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of Michael Hammer (mhammer) > > > > Sent: Thursday, September 08, 2005 3:12 PM > > > > To: Ted Hardie; wilcox@e911.psd.state.vt.us; > > > br@brianrosen.net; Andrew > > > > Newton; Stastny Richard; ECRIT > > > > Subject: RE: [Ecrit] Emergency Context > > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > > > Ted, > > > > > > > > I'm confused. Are calls from Asia or Europe to the Vermont > > > PSAP ever > > > > legitimate? > > > > > > > > Somehow, I can't picture the local sheriff being able to > > > help someone > > > > in Berlin. I thought the point of i3 is to enable the call > > > to go to > > > > the local Berlin Polizei. Put another way, is it possible > > > to use the > > > > local nature of emergency service to protect agains DDoS? > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Ted Hardie > > > > > Sent: Thursday, September 08, 2005 1:55 PM > > > > > To: wilcox@e911.psd.state.vt.us; br@brianrosen.net; > > > Andrew Newton; > > > > > Stastny Richard; ECRIT > > > > > Subject: RE: [Ecrit] Emergency Context Routing > > > > > ofInternetTechnologies-Architecture Considerations > > > > > > > > > > After reading the thread, I wanted to come back to Nate's > > > original > > > > > concern and call something out: > > > > > > > > > > >Here is the PSAP concern: > > > > > > > > > > > >An enterprising thief could figure out that a business > > > (without an > > > > > >alarm > > > > > >system) in Backwater, Vermont is served by a PSAP located 25 > > > > > miles away. > > > > > >If one creates an IP-based denial of service attack on that > > > > > PSAP then > > > > > >it is safe to assume that the target of opportunity that the > > > > > thief is > > > > > >looking at in Backwater will not be able to contact the PSAP > > > > > to summon > > > > > >help. > > > > > > > > > > I'm assuming that the PSAP being 25 miles away means > > > nothing about > > > > > where the responders are. The responders in this > > > instance might be > > > > > sheriffs, for example, who are stationed nearby, even > > > > further than 25 > > > > > miles away, or whose patrol routes mean that their distance > > > > from the > > > > > target of opportunity is variable. So I think we > > should cut the > > > > > distance from this description completely, and simply see > > > > the threat > > > > > as "If the bad actor can determine which PSAP serves an > > > > area in which > > > > > a target is present, a successful attack on the PSAP prevents > > > > > responses to the target". > > > > > > > > > > Does that make sense? > > > > > > > > > > > > > > > > Using PSTN technologies, an enterprising thief could create > > > > > a PSTN DoS > > > > > >on the PSAP by simply using an auto call generator from a > > > > pay phone > > > > > >located in the same proximity as the target of opportunity > > > > however, > > > > > >this would still create a response to the general area of > > > > the crime. > > > > > > > > > > There are lots of other kinds of PSTN attacks here--the > > > > most commonly > > > > > portrayed being "cutting the line", which doesn't work > > > quite as it > > > > > seems in the movies, but does have some effect. > > > > > > > > > > To avoid the locality problem in this attack, the bad actor > > > > can use an > > > > > accomplice, meat or mechanical, in any other area served by > > > > the PSAP > > > > > to do the same thing. This avoids the response hitting > > > the general > > > > > area of the crime. It also has the same counter-measure; > > > > > call-blocking of the attacking phone. This counter-measure > > > > is also > > > > > relatively easy to accomplish with an IP-based service, > > > > provided the > > > > > attack is coming from a single IP or block. I believe the > > > > problem is > > > > > harder in the IP case not because the area from which the > > > > attack can > > > > > originate is larger but because it is easier to create a > > > > Distributed > > > > > Denial of Service, largely because of zombie networks and > > > > IP spoofing. > > > > > That is, if the attack is coming from Europe while the > > attack is > > > > > happening on Backwater, my response is the same as if it > > > came from > > > > > Nearwater, VT: > > > > > block the attack source. But if it is coming from > > Europe, Asia, > > > > > Nearwater, Backwater, and many other points as well, > > > > attempts to block > > > > > the attack either requires effectively severing connectivity or > > > > > maintaining a fair amount of information about who at the > > > IP layer > > > > > should be talking to this PSAP. We've discussed the > > > > effectiveness of > > > > > that in the past. > > > > > > > > > > >If I > > > > > >know the URI of the PSAP, I can now distract it from another > > > > > continent > > > > > >and do what I would need to do in Backwater and no > > > > response would be > > > > > >created in that direction - that is the new paradigm with > > > > > IP. If I know > > > > > >the boundaries of the Derby PSAP, I could create a PSTN > > > based DoS > > > > > >attack anywhere from within that boundary (potentially 50 > > > > miles from > > > > > >Island Pond). > > > > > > > > > > > >Would this happen? I don't know - I am pretty sure it > > > > hasn't yet but > > > > > >assigning a URI to a PSAP opens it up to whole new > > generation of > > > > > >"creative thinkers"..... > > > > > > > > > > > >Of course we can minimize the impact on the PSAP at a > > > higher level > > > > > >gateway by throwing a huge amount of bandwidth at it and > > > > building in > > > > > >intelligent alternative routing on a robust firewall. But > > > > > that does not > > > > > >help in the interim between here and there when someone > > > gets their > > > > > >hands on the PSAP boundaries and realizes the attacks they > > > > > can initiate > > > > > >using the PSTN DoS approach. > > > > > > > > > > The problem with the proposed solution, I believe, is that > > > > aggregating > > > > > the access to a back-to-back user agent or all-knowing > > > > gateway is that > > > > > you have simply created a richer target for attack. If I > > > > can marshal > > > > > a zombie group that takes out all of Vermont's PSAPs by > > > eliminating > > > > > the the gateway by DDoS, I have done far worse far more > > > > easily than I > > > > > could by individually attacking the PSAPs at their URIs. > > > > If I did it > > > > > in order to get at Backwater's target, I likely don't > > > care that the > > > > > general effect is larger--my purpose is met. > > > > > > > > > > Yes, it is easier to escalate the defenses at a single > > > > point and yes, > > > > > it is easier to pay for fat pipes for that single point. > > > > But the bad > > > > > actors here aren't using their own resources to attack you; > > > > they are > > > > > stealing them before trying to steal from you. Getting > > > > into an arms > > > > > race with someone who isn't spending their own money worries me. > > > > > > > > > > regards, > > > > > Ted > > > > > > > > > > _______________________________________________ > > > > > 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 > _______________________________________________ > 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 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 08 19:36:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDVwV-0002Kx-CV; Thu, 08 Sep 2005 19:36:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDVwT-0002Kn-R7 for ecrit@megatron.ietf.org; Thu, 08 Sep 2005 19:36:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05593 for ; Thu, 8 Sep 2005 19:36:26 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDVzx-00072L-2X for ecrit@ietf.org; Thu, 08 Sep 2005 19:40:05 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Sep 2005 18:36:20 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 08 Sep 2005 18:36:20 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Sep 2005 18:36:20 -0500 Message-ID: From: "Winterbottom, James" To: "Ted Hardie" , "ECRIT" Date: Thu, 8 Sep 2005 18:36:18 -0500 Subject: RE: [Ecrit] Emergency Context Routing ofInternetTechnologies-Architecture Considerations MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 08 Sep 2005 23:36:20.0121 (UTC) FILETIME=[1D816890:01C5B4CE] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Emergency Context Routing ofInternetTechnologies-Architecture Considerations Thread-Index: AcW0nqUl1UeWinQeRk+FLDvEKY+vAAALqhdA X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Ted, My assumption would be that a large gateway box that services 20 or 100 PSAPs will require any attacker to mass several orders of magnitude more zombies to launch a successful attack, than they would require to attack a single PSAP. Maybe this is easy, I don't know, but it does up the anti somewhat. All this aside, I think that there are economies of scale, and functionality reasons why including a gateway such an ESRP are desirable, but these are more implementation details. Somewhere, something has to have sufficient knowledge to use location to route the signal to the next hop. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Ted Hardie > Sent: Friday, 9 September 2005 3:55 AM > To: wilcox@e911.psd.state.vt.us; br@brianrosen.net; Andrew Newton; Stastny > Richard; ECRIT > Subject: RE: [Ecrit] Emergency Context Routing ofInternetTechnologies- > Architecture Considerations >=20 > After reading the thread, I wanted to come back to Nate's original concern > and call something out: >=20 > >Here is the PSAP concern: > > > >An enterprising thief could figure out that a business (without an alarm > >system) in Backwater, Vermont is served by a PSAP located 25 miles away. > >If one creates an IP-based denial of service attack on that PSAP then it > >is safe to assume that the target of opportunity that the thief is > >looking at in Backwater will not be able to contact the PSAP to summon > >help. >=20 > I'm assuming that the PSAP being 25 miles away means nothing about > where the responders are. The responders in this instance might be > sheriffs, for example, who are stationed nearby, even further than 25 > miles away, or whose patrol routes mean that their distance from the > target of opportunity is variable. So I think we should cut the distance > from this description completely, and simply see the threat as "If the > bad actor can determine which PSAP serves an area in which a target > is present, a successful attack on the PSAP prevents responses to the > target". >=20 > Does that make sense? >=20 >=20 > > Using PSTN technologies, an enterprising thief could create a PSTN > >DoS on the PSAP by simply using an auto call generator from a pay phone > >located in the same proximity as the target of opportunity however, this > >would still create a response to the general area of the crime. >=20 > There are lots of other kinds of PSTN attacks here--the most commonly > portrayed being "cutting the line", which doesn't work quite > as it seems in the movies, but does have some effect. >=20 > To avoid the locality problem in this attack, the bad actor can use an > accomplice, > meat or mechanical, in any other area served by the PSAP to do the > same thing. This avoids the response hitting the general area of > the crime. It also has the same counter-measure; call-blocking of the > attacking phone. This counter-measure is also relatively easy to > accomplish > with an IP-based service, provided the attack is coming from a single > IP or block. I believe the problem is harder in the IP case not because > the area > from which the attack can originate is larger but because it is easier to > create a > Distributed Denial of Service, largely because of zombie networks and IP > spoofing. > That is, if the attack is coming from Europe while the attack is happening > on > Backwater, my response is the same as if it came from Nearwater, VT: > block the attack source. But if it is coming from Europe, Asia, > Nearwater, > Backwater, and many other points as well, attempts to block the attack > either requires effectively severing connectivity or maintaining a fair > amount of information about who at the IP layer should be talking to > this PSAP. We've discussed the effectiveness of that in the past. >=20 > >If I > >know the URI of the PSAP, I can now distract it from another continent > >and do what I would need to do in Backwater and no response would be > >created in that direction - that is the new paradigm with IP. If I know > >the boundaries of the Derby PSAP, I could create a PSTN based DoS attack > >anywhere from within that boundary (potentially 50 miles from Island > >Pond). > > > >Would this happen? I don't know - I am pretty sure it hasn't yet but > >assigning a URI to a PSAP opens it up to whole new generation of > >"creative thinkers"..... > > > >Of course we can minimize the impact on the PSAP at a higher level > >gateway by throwing a huge amount of bandwidth at it and building in > >intelligent alternative routing on a robust firewall. But that does not > >help in the interim between here and there when someone gets their hands > >on the PSAP boundaries and realizes the attacks they can initiate using > >the PSTN DoS approach. >=20 > The problem with the proposed solution, I believe, is that aggregating > the access to a back-to-back user agent or all-knowing gateway > is that you have simply created a richer target for attack. If I can > marshal > a zombie group that takes out all of Vermont's PSAPs by eliminating the > the gateway by DDoS, I have done far worse far more easily than I could > by individually attacking the PSAPs at their URIs. If I did it in order > to > get at Backwater's target, I likely don't care that the general effect > is larger--my purpose is met. >=20 > Yes, it is easier to escalate the defenses at a single point and yes, it > is easier to > pay for fat pipes for that single point. But the bad actors here aren't > using their > own resources to attack you; they are stealing them before trying to > steal from you. Getting into an arms race with someone who isn't > spending their own money worries me. >=20 > regards, > Ted >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 08 20:04:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDWNf-0008Da-F7; Thu, 08 Sep 2005 20:04:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDWNd-0008DV-ET for ecrit@megatron.ietf.org; Thu, 08 Sep 2005 20:04:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06680 for ; Thu, 8 Sep 2005 20:04:31 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDWR4-0007dm-NV for ecrit@ietf.org; Thu, 08 Sep 2005 20:08:09 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j89028G6000572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Sep 2005 17:02:08 -0700 (PDT) Received: from [192.168.1.4] (vpn-10-50-16-69.qualcomm.com [10.50.16.69]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j89025oY007658; Thu, 8 Sep 2005 17:02:06 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 8 Sep 2005 17:02:03 -0700 To: "Winterbottom, James" , "ECRIT" From: Ted Hardie Subject: RE: [Ecrit] Emergency Context Routing ofInternetTechnologies-Architecture Considerations Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 6:36 PM -0500 9/8/05, Winterbottom, James wrote: >Hi Ted, > >My assumption would be that a large gateway box that services 20 or 100 >PSAPs will require any attacker to mass several orders of magnitude more >zombies to launch a successful attack, than they would require to attack >a single PSAP. Maybe this is easy, I don't know, but it does up the anti >somewhat. You may want to take a look at Christian Huitema's slides from the the most recent APPs area open meeting; they are at http://www3.ietf.org/proceedings/05aug/slides/apparea-4/sld4.htm. I'm not sure that the economics will hold over time or whether short-term rentals are cheaper/more expensive, but I would count on an attacker being able to rent zombies cheaply. Assuming the price per day is half the price per week, 10,000 zombies for a day will cost $500; 10k boxes attacking a gateway box are likely to be a big problem. >All this aside, I think that there are economies of scale, and >functionality reasons why including a gateway such an ESRP are >desirable, but these are more implementation details. Somewhere, >something has to have sufficient knowledge to use location to route the >signal to the next hop. > Perhaps I've drunk the Internet kool-aid way too long now, but I remain pretty convinced that giving the end-point the knowledge of who to route to gives us the most flexibility. If you give the end point the real contact URI, all of the underlying systems of the routing system can work as they are intended to; you don't need to force route every call through a single point of failure *and then route it onward*. That's the real kicker; if you aggregated the PSAPs themselves, you haven't done much harm--but by aggregating the PSAP contacts and then doing onward routing to distributed PSAPs, you seem to me to have increased the risk and added delay. There may be economies of scale to this strategy, but I still think the balance is wrong. In the case of a no-attack call, it is certain to add delay, and there are cases where its failure is catastrophic. Just my personal opinion, of course, regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 08 20:30:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDWn9-0005aV-42; Thu, 08 Sep 2005 20:30:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDWn7-0005aQ-Ef for ecrit@megatron.ietf.org; Thu, 08 Sep 2005 20:30:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07630 for ; Thu, 8 Sep 2005 20:30:51 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDWqZ-0008D8-9V for ecrit@ietf.org; Thu, 08 Sep 2005 20:34:29 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 08 Sep 2005 17:30:42 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j890UK5E003591; Thu, 8 Sep 2005 17:30:40 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Sep 2005 17:30:30 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Sep 2005 17:30:29 -0700 From: "Marc Linsner" To: "'Winterbottom, James'" , "'Michael Hammer \(mhammer\)'" , "'Stastny Richard'" , "'ECRIT'" Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies-ArchitectureConsiderations Date: Thu, 8 Sep 2005 20:30:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcW0nrEgg7FP1ZhNSGC2XzZaoHBB9wACdmtgAAINYoAAAYSasAACMeadAAD+zbAAAKghwAABpFAwAAISb5A= Message-ID: X-OriginalArrivalTime: 09 Sep 2005 00:30:30.0235 (UTC) FILETIME=[AEB972B0:01C5B4D5] X-Spam-Score: 1.3 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > > This issue has been discussed in NENA at quite some length. > The consensus that is growing there, and I know that there > are some people that still disagree, is that if an enterprise > is prepared to allow this to occur, that the onus is-Maqr on the > enterprise to ensure that it works. > This makes the problem a little easier to deal with. That's one way to eliminate difficult requirements.... :^) -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 08 20:36:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDWsk-0006w6-Fl; Thu, 08 Sep 2005 20:36:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDWsj-0006vx-7W for ecrit@megatron.ietf.org; Thu, 08 Sep 2005 20:36:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07866 for ; Thu, 8 Sep 2005 20:36:39 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDWwC-0008KS-68 for ecrit@ietf.org; Thu, 08 Sep 2005 20:40:17 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Sep 2005 19:36:27 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 08 Sep 2005 19:36:27 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Sep 2005 19:36:26 -0500 Message-ID: From: "Winterbottom, James" To: "Marc Linsner" , "Michael Hammer \(mhammer\)" , "Stastny Richard" , "ECRIT" Date: Thu, 8 Sep 2005 19:36:25 -0500 Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies-ArchitectureConsiderations MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 09 Sep 2005 00:36:26.0359 (UTC) FILETIME=[82FDA870:01C5B4D6] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] EmergencyContextRoutingofInternetTechnologies-ArchitectureConsiderations Thread-Index: AcW0nrEgg7FP1ZhNSGC2XzZaoHBB9wACdmtgAAINYoAAAYSasAACMeadAAD+zbAAAKghwAABpFAwAAISb5AAAFkosA== X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org It is also a way to eliminate draconian IS policies.. ;) > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Friday, 9 September 2005 10:30 AM > To: Winterbottom, James; 'Michael Hammer (mhammer)'; 'Stastny Richard'; > 'ECRIT' > Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies- > ArchitectureConsiderations >=20 >=20 > > > > This issue has been discussed in NENA at quite some length. > > The consensus that is growing there, and I know that there > > are some people that still disagree, is that if an enterprise > > is prepared to allow this to occur, that the onus is-Maqr on the > > enterprise to ensure that it works. > > This makes the problem a little easier to deal with. >=20 > That's one way to eliminate difficult requirements.... :^) >=20 > -Marc- >=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 09 02:49:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDchH-0000Wu-Be; Fri, 09 Sep 2005 02:49:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDchE-0000Wm-3b for ecrit@megatron.ietf.org; Fri, 09 Sep 2005 02:49:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13299 for ; Fri, 9 Sep 2005 02:49:10 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDckl-0007fe-4g for ecrit@ietf.org; Fri, 09 Sep 2005 02:52:51 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Sep 2005 08:49:02 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j896mUVj020759; Fri, 9 Sep 2005 08:48:59 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 9 Sep 2005 08:48:51 +0200 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 9 Sep 2005 08:48:51 +0200 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E38A3DAA@xmb-rtp-20b.amer.cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E38A3DAA@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7E21ABF2-7AFD-4CA0-98B2-667E6FBDB416@cisco.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Ecrit] Emergency ContextRoutingofInternetTechnologies-Architecture Considerations Date: Fri, 9 Sep 2005 08:48:48 +0200 To: Michael Hammer ((mhammer)) X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 09 Sep 2005 06:48:51.0610 (UTC) FILETIME=[89CC5FA0:01C5B50A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: Stastny Richard , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 9, 2005, at 00:25, Michael Hammer ((mhammer)) wrote: > My original question was about whether a PSAP should expect calls > (signaling and media) to originate from non-local destinations, e.g. > international, and by inference the need for the PSAPs to be able to > make call backs to those locations. If not, then perhaps it is a DDoS > clue. > Call blocking is needed for other reasons (pure plain ddos), and call forwarding (or similar) will also be needed in reality. It already exists today. The question is only HOW MUCH of this should be accepted, and I am pretty sure this is for example different between different countries/ cities etc. In Sweden today, the caller ID is needed (at the PSAP) for three reasons: - Calculate the origin of the caller by looking up the location in a database provided by the telcos - Be able to call back if the call is dropped - Be able to block ddos against the psap So, what is my point....? That no technical solution for VoIP emergency numbers will be able to "solve" the problem with ddos or wrong routing or blocking. This is something we have today. We should concentrate on giving the right tools needed so the PSAP can act. paf _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 09 08:15:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDhlY-0004m6-WB; Fri, 09 Sep 2005 08:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDhlX-0004lk-87 for ecrit@megatron.ietf.org; Fri, 09 Sep 2005 08:13:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27910 for ; Fri, 9 Sep 2005 08:13:58 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDhp4-0008DU-51 for ecrit@ietf.org; Fri, 09 Sep 2005 08:17:41 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 09 Sep 2005 05:13:44 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j89CDc4u009353; Fri, 9 Sep 2005 05:13:39 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Sep 2005 05:13:40 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Sep 2005 05:13:39 -0700 From: "Marc Linsner" To: "'Winterbottom, James'" , "'Michael Hammer \(mhammer\)'" , "'Stastny Richard'" , "'ECRIT'" Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies-ArchitectureConsiderations Date: Fri, 9 Sep 2005 08:13:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcW0nrEgg7FP1ZhNSGC2XzZaoHBB9wACdmtgAAINYoAAAYSasAACMeadAAD+zbAAAKghwAABpFAwAAISb5AAAFkosAAYT+Ag Message-ID: X-OriginalArrivalTime: 09 Sep 2005 12:13:40.0096 (UTC) FILETIME=[E9D75800:01C5B537] X-Spam-Score: 1.3 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm amused at the tayloring of requirements to meet solutions. :^) -Marc- > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Thursday, September 08, 2005 8:36 PM > To: Marc Linsner; Michael Hammer (mhammer); Stastny Richard; ECRIT > Subject: RE: [Ecrit] > EmergencyContextRoutingofInternetTechnologies-ArchitectureCons iderations > > It is also a way to eliminate draconian IS policies.. ;) > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Friday, 9 September 2005 10:30 AM > > To: Winterbottom, James; 'Michael Hammer (mhammer)'; 'Stastny > Richard'; > > 'ECRIT' > > Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies- > > ArchitectureConsiderations > > > > > > > > > > This issue has been discussed in NENA at quite some length. > > > The consensus that is growing there, and I know that > there are some > > > people that still disagree, is that if an enterprise is > prepared to > > > allow this to occur, that the onus is-Maqr on the enterprise to > > > ensure that it works. > > > This makes the problem a little easier to deal with. > > > > That's one way to eliminate difficult requirements.... :^) > > > > -Marc- > > > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 09 10:22:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDjlu-00078O-SC; Fri, 09 Sep 2005 10:22:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDjlt-00078J-GE for ecrit@megatron.ietf.org; Fri, 09 Sep 2005 10:22:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05721 for ; Fri, 9 Sep 2005 10:22:27 -0400 (EDT) Received: from dnsmx1pya.telcordia.com ([128.96.20.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDjpU-0003Br-Fm for ecrit@ietf.org; Fri, 09 Sep 2005 10:26:12 -0400 Received: from rrc-its-ieg01.cc.telcordia.com (rrc-its-ieg01.cc.telcordia.com [128.96.109.78]) by dnsmx1pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j89EMF601150 for ; Fri, 9 Sep 2005 10:22:15 -0400 (EDT) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-its-ieg01.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005090910165928525 for ; Fri, 09 Sep 2005 10:16:59 -0400 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 9 Sep 2005 10:22:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConsiderations Date: Fri, 9 Sep 2005 10:22:19 -0400 Message-ID: Thread-Topic: [Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConsiderations Thread-Index: AcW0nrEgg7FP1ZhNSGC2XzZaoHBB9wACdmtgAAINYoAAAYSasAACMeadAAD+zbAAAKghwAABpFAwAAISb5AAAFkosAAYT+AgAACktbA= From: "Abbott, Nadine B" To: "ECRIT" X-OriginalArrivalTime: 09 Sep 2005 14:22:12.0072 (UTC) FILETIME=[DE897E80:01C5B549] X-Spam-Score: 0.2 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab 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 I admit I am a bit confused about exactly which requirement is being debated/tailored...but if I'm not too far off... It seems to me that the proposed requirement could be stated: An emergency call should be able to be originated remotely via a VPN through an enterprise network, and accurate location information for the caller should be made available to route the call. If the caller's IP device is capable of supporting a method for acquiring its location (with or without the assistance of its local access network), and is capable of storing and passing its location information with call signaling in a PIDF-LO, then it is the responsibility of the enterprise to pass that location information along with the call. This makes it possible for an emergency call from an IP device remotely connected to the enterprise VPN to still have its call routed to the correct PSAP based on the caller's location. The point of greatest difficulty is when either the IP device or its local Internet access provider cannot support a method for the IP device to acquire its location. In this case, when the remote user originates a call using a VPN to the enterprise, the enterprise must somehow acquire location on-behalf-of the location-incapable/unaware device. This is of concern in the real world because there are lots of existing devices and networks that do not as yet support these capabilities. I believe there are existing enterprise solutions that use provisioning to support relatively static access via VPNs (e.g., the telecommuter with a fixed home address). But the problem of the road warrior is much more difficult.=20 If we assume that it is the Internet access provider that is aware of the remote IP device's location, then the road warrior problem requires the enterprise to not only discover the IP device's Internet access provider from among all possible Internet access providers, but also to be able to exchange information necessary to determine the caller's location with all such possible Internet access providers on-behalf-of the IP device. There is much discussion in North American forums about what it might take to make this possible. However, this IS a very complex problem, and the comments below seem to be a pragmatic recognition that it may be a lot simpler for the enterprise to supply its roaming members with IP devices that are capable of automatically acquiring and passing location, than to support the mechanisms necessary to acquire location information remotely on their behalf. (Not to mention how much simpler it would also make life for the Internet access providers.) If the requirement is that emergency calls should be able to be originated remotely via VPNs through an enterprise and that accurate location information must be available to route the call, then there are various solutions that can meet this requirement and these solutions place varying degrees of responsibility on the enterprise and its IP devices (with only a few possible examples sketched above). It seems to me that the enterprise that supports the VPN is the entity in the best position to take ownership of the problem. I think that maybe this is not so much tailoring the requirement as it is an acknowledgment that some solutions may be better than others in meeting the requirement?=20 I might suggest a clarification to the requirement, e.g., If an emergency call is originated remotely via a VPN through an enterprise network, the enterprise shall ensure that accurate location information for the caller is made available to route the call. I do not think that this tailors the requirement to a particular solution, but it does identify responsibility for the solution and makes use of a VPN for this purpose conditional upon implementation of a solution. Nadine -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Friday, September 09, 2005 8:14 AM To: 'Winterbottom, James'; 'Michael Hammer (mhammer)'; 'Stastny Richard'; 'ECRIT' Subject: RE: [Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConside rations I'm amused at the tayloring of requirements to meet solutions. :^) -Marc-=20 > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Thursday, September 08, 2005 8:36 PM > To: Marc Linsner; Michael Hammer (mhammer); Stastny Richard; ECRIT > Subject: RE: [Ecrit]=20 > EmergencyContextRoutingofInternetTechnologies-ArchitectureCons iderations >=20 > It is also a way to eliminate draconian IS policies.. ;) >=20 > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Friday, 9 September 2005 10:30 AM > > To: Winterbottom, James; 'Michael Hammer (mhammer)'; 'Stastny > Richard'; > > 'ECRIT' > > Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies- > > ArchitectureConsiderations > >=20 > >=20 > > > > > > This issue has been discussed in NENA at quite some length. The=20 > > > consensus that is growing there, and I know that > there are some > > > people that still disagree, is that if an enterprise is > prepared to > > > allow this to occur, that the onus is-Maqr on the enterprise to > > > ensure that it works. > > > This makes the problem a little easier to deal with. > >=20 > > That's one way to eliminate difficult requirements.... :^) > >=20 > > -Marc- > >=20 >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender=20 > immediately and delete the original. Any unauthorized use of=20 > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] _______________________________________________ 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 Sep 09 11:25:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDklK-00054J-RR; Fri, 09 Sep 2005 11:25:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDklE-00051f-C8 for ecrit@megatron.ietf.org; Fri, 09 Sep 2005 11:25:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09837 for ; Fri, 9 Sep 2005 11:25:50 -0400 (EDT) Received: from dnsmx1pya.telcordia.com ([128.96.20.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDkon-00058W-T5 for ecrit@ietf.org; Fri, 09 Sep 2005 11:29:36 -0400 Received: from rrc-its-ieg01.cc.telcordia.com (rrc-its-ieg01.cc.telcordia.com [128.96.109.78]) by dnsmx1pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j89FPe611388 for ; Fri, 9 Sep 2005 11:25:40 -0400 (EDT) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-its-ieg01.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005090911202431336 for ; Fri, 09 Sep 2005 11:20:24 -0400 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 9 Sep 2005 11:25:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Emergency Context Routing of Internet Technologies -Architecture Considerations Date: Fri, 9 Sep 2005 11:25:53 -0400 Message-ID: Thread-Topic: [Ecrit] Emergency Context Routing of Internet Technologies -Architecture Considerations Thread-Index: AcWzDLiV1AdT9CjESNKUKI1twQLfgwCPTcbA From: "Abbott, Nadine B" To: X-OriginalArrivalTime: 09 Sep 2005 15:25:37.0268 (UTC) FILETIME=[BA9C5340:01C5B552] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 James and Andy, I appreciate your contribution to additional discussion of architectural considerations that provide a context for the focus of on requirements for location-based mapping protocols in the ECRIT discussions. I think this is very helpful. I have a few observations and suggestions: In section 1, a suggested definition for Location Information Server (LIS) -- Provides a mapping function to relate unique identifiers for IP devices at physical network access points and the geographic descriptions of their location (e.g., civic location/street addresses or geographic coordinates). Responds to queries for location information. In Section 2, the list of methods for delivering configuration and location information to the client does not include the proposed HELD method for IP clients to acquire location information from an Internet access provider (described in HTTP Enabled Location Delivery [HELD], draft-winterbottom-http-location-delivery-01). This should be to be added to the list to address the needs of a number of potential Internet access providers that would be called upon to provide location information in North America. In Section 4, I suggest the addition of a paragraph with wording something like the following to include an example of an ESRP concept previously described in Section 6.1 of I-D: "Emergency Services for Internet Telephony Systems," Henning Schulzrinne, October 18, 2004, draft-schulzrinne-sipping-emergency-arch-02. =20 At the option of the PSAP, more than one ESRP function may be implemented in series,=20 to provide increasingly precise routing to the appropriate PSAP.=20 This allows for simplification of emergency call routing at the originating network,=20 and for decision-making at local jurisdictional or at aggregate levels for=20 real-time control of call routing. This might also allow for some additional jurisdictional=20 control of the visibility of emergency call routing information. Thanks again, Nadine Abbott =20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes Sent: Tuesday, September 06, 2005 1:59 PM To: ecrit@ietf.org Subject: [Ecrit] Emergency Context Routing of Internet Technologies -Architecture Considerations hi all,=20 james and andy just submitted a draft with the following content: " This document discusses architectural considerations for emergency=20 context routing of Internet technologies. The purpose of this=20 document is to provide a systemic view of emergency context routing, discuss unresolved issues, and explain the relationship of some of=20 the proposals to these issues, while discussing potential directions=20 that might be still be necessary for the working group to=20 investigate. =20 " i have copied the draft to http://www.ietf-ecrit.org/cache/draft-polk-newton-ecrit-arch-considerati ons-00.txt thanks to both of them for touching a number of interesting discussion topics.=20 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 Fri Sep 09 20:45:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDtUR-000604-PZ; Fri, 09 Sep 2005 20:45:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDtUL-0005yn-Kd for ecrit@megatron.ietf.org; Fri, 09 Sep 2005 20:45:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24765 for ; Fri, 9 Sep 2005 20:45:00 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDtY1-000849-8z for ecrit@ietf.org; Fri, 09 Sep 2005 20:48:50 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j8A0iueC019394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Sep 2005 20:44:57 -0400 (EDT) Message-ID: <43222C87.7050009@cs.columbia.edu> Date: Fri, 09 Sep 2005 20:44:55 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Abbott, Nadine B" Subject: Re: [Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConsiderations References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.4 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Abbott, Nadine B wrote: > However, this IS a very complex problem, and the comments below seem to > be a pragmatic recognition that it may be a lot simpler for the > enterprise to supply its roaming members with IP devices that are > capable of automatically acquiring and passing location, than to support > the mechanisms necessary to acquire location information remotely on > their behalf. (Not to mention how much simpler it would also make life > for the Internet access providers.) Not to mention issues of privacy - the Internet service provider has no clue that this is an emergency call and it seems rather difficult for some random hotel 802.11 provider to recognize hundreds of thousands of businesses, many of them in a different country than that provider, to make sure that this is indeed a legitimate request. > > If the requirement is that emergency calls should be able to be > originated remotely via VPNs through an enterprise and that accurate > location information must be available to route the call, then there are > various solutions that can meet this requirement and these solutions > place varying degrees of responsibility on the enterprise and its IP > devices (with only a few possible examples sketched above). It seems to > me that the enterprise that supports the VPN is the entity in the best > position to take ownership of the problem. I think that maybe this is > not so much tailoring the requirement as it is an acknowledgment that > some solutions may be better than others in meeting the requirement? At least some of the VPN software can be configured not to route "random" (non-corporate) Internet addresses via the VPN at all. This makes some sense - there is little benefit of visiting the web page of some outfit by tromboning or hairpinning (to use the PSTN equivalents) via the corporate campus. Maybe such configurations will become more common, given these difficulties (or OS will support the ability to select the non-VPN interface explicitly when opening a socket.) > > I might suggest a clarification to the requirement, e.g., > If an emergency call is originated remotely via a VPN through an > enterprise network, the enterprise shall ensure that accurate location > information for the caller is made available to route the call. > > I do not think that this tailors the requirement to a particular > solution, but it does identify responsibility for the solution and makes > use of a VPN for this purpose conditional upon implementation of a > solution. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 10 13:26:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EE97D-0001Zp-RC; Sat, 10 Sep 2005 13:26:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EE979-0001TB-WE for ecrit@megatron.ietf.org; Sat, 10 Sep 2005 13:26:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10808 for ; Sat, 10 Sep 2005 13:25:54 -0400 (EDT) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EE9An-0003AJ-6q for ecrit@ietf.org; Sat, 10 Sep 2005 13:29:55 -0400 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 j8AHCTEX020333 for ; Sat, 10 Sep 2005 13:12:29 -0400 (EDT) Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8AHCSEX020305 for ; Sat, 10 Sep 2005 13:12:28 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConsiderations Date: Sat, 10 Sep 2005 13:25:42 -0400 Message-ID: Thread-Topic: [Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConsiderations Thread-Index: AcW0nrEgg7FP1ZhNSGC2XzZaoHBB9wACdmtgAAINYoAAAYSasAACMeadAAD+zbAAAKghwAABpFAwAAISb5AAAFkosAAYT+AgAACktbAAO5IdIA== From: "Rodrig, Benny \(Benny\)" To: "Abbott, Nadine B" , "ECRIT" X-Spam-Score: 0.2 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The enterprise can supply its nomadic members with IP devices capable of automatically acquiring location e.g. via LLDP-MED or DHCP, but the Internet Access Provider is still the only entity that can provide the location information. If the Access Provider does not provide location, the enterprise can not ensure that accurate location info is available, can it?=20 The VPN only makes the call route around, but with respect to responsibility for determining caller location, is the enterprise different from an ASP that is divorced from the Access Provider?=20 Benny -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Abbott, Nadine B Sent: Friday, September 09, 2005 10:22 AM To: ECRIT Subject: RE: [Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConside rations I admit I am a bit confused about exactly which requirement is being debated/tailored...but if I'm not too far off... It seems to me that the proposed requirement could be stated: An emergency call should be able to be originated remotely via a VPN through an enterprise network, and accurate location information for the caller should be made available to route the call. If the caller's IP device is capable of supporting a method for acquiring its location (with or without the assistance of its local access network), and is capable of storing and passing its location information with call signaling in a PIDF-LO, then it is the responsibility of the enterprise to pass that location information along with the call. This makes it possible for an emergency call from an IP device remotely connected to the enterprise VPN to still have its call routed to the correct PSAP based on the caller's location. The point of greatest difficulty is when either the IP device or its local Internet access provider cannot support a method for the IP device to acquire its location. In this case, when the remote user originates a call using a VPN to the enterprise, the enterprise must somehow acquire location on-behalf-of the location-incapable/unaware device. This is of concern in the real world because there are lots of existing devices and networks that do not as yet support these capabilities. I believe there are existing enterprise solutions that use provisioning to support relatively static access via VPNs (e.g., the telecommuter with a fixed home address). But the problem of the road warrior is much more difficult.=20 If we assume that it is the Internet access provider that is aware of the remote IP device's location, then the road warrior problem requires the enterprise to not only discover the IP device's Internet access provider from among all possible Internet access providers, but also to be able to exchange information necessary to determine the caller's location with all such possible Internet access providers on-behalf-of the IP device. There is much discussion in North American forums about what it might take to make this possible. However, this IS a very complex problem, and the comments below seem to be a pragmatic recognition that it may be a lot simpler for the enterprise to supply its roaming members with IP devices that are capable of automatically acquiring and passing location, than to support the mechanisms necessary to acquire location information remotely on their behalf. (Not to mention how much simpler it would also make life for the Internet access providers.) If the requirement is that emergency calls should be able to be originated remotely via VPNs through an enterprise and that accurate location information must be available to route the call, then there are various solutions that can meet this requirement and these solutions place varying degrees of responsibility on the enterprise and its IP devices (with only a few possible examples sketched above). It seems to me that the enterprise that supports the VPN is the entity in the best position to take ownership of the problem. I think that maybe this is not so much tailoring the requirement as it is an acknowledgment that some solutions may be better than others in meeting the requirement?=20 I might suggest a clarification to the requirement, e.g., If an emergency call is originated remotely via a VPN through an enterprise network, the enterprise shall ensure that accurate location information for the caller is made available to route the call. I do not think that this tailors the requirement to a particular solution, but it does identify responsibility for the solution and makes use of a VPN for this purpose conditional upon implementation of a solution. Nadine -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Friday, September 09, 2005 8:14 AM To: 'Winterbottom, James'; 'Michael Hammer (mhammer)'; 'Stastny Richard'; 'ECRIT' Subject: RE: [Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConside rations I'm amused at the tayloring of requirements to meet solutions. :^) -Marc-=20 > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Thursday, September 08, 2005 8:36 PM > To: Marc Linsner; Michael Hammer (mhammer); Stastny Richard; ECRIT > Subject: RE: [Ecrit] > EmergencyContextRoutingofInternetTechnologies-ArchitectureCons iderations >=20 > It is also a way to eliminate draconian IS policies.. ;) >=20 > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Friday, 9 September 2005 10:30 AM > > To: Winterbottom, James; 'Michael Hammer (mhammer)'; 'Stastny > Richard'; > > 'ECRIT' > > Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies- > > ArchitectureConsiderations > >=20 > >=20 > > > > > > This issue has been discussed in NENA at quite some length. The=20 > > > consensus that is growing there, and I know that > there are some > > > people that still disagree, is that if an enterprise is > prepared to > > > allow this to occur, that the onus is-Maqr on the enterprise to=20 > > > ensure that it works. > > > This makes the problem a little easier to deal with. > >=20 > > That's one way to eliminate difficult requirements.... :^) > >=20 > > -Marc- > >=20 >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may contain=20 > privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender immediately > and delete the original. Any unauthorized use of this email is=20 > prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] _______________________________________________ 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 Sun Sep 11 18:45:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEaa4-00082W-Kj; Sun, 11 Sep 2005 18:45:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEaZE-0007tD-VY for ecrit@megatron.ietf.org; Sun, 11 Sep 2005 18:45:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27560 for ; Sun, 11 Sep 2005 18:44:45 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEadB-0007lk-9p for ecrit@ietf.org; Sun, 11 Sep 2005 18:49:02 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 11 Sep 2005 15:44:39 -0700 X-IronPort-AV: i="3.97,97,1125903600"; d="scan'208"; a="659195110:sNHT36236910" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8BMiV4u028742; Sun, 11 Sep 2005 15:44:33 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 11 Sep 2005 15:44:31 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.114.238]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 11 Sep 2005 15:44:30 -0700 Message-Id: <4.3.2.7.2.20050911174249.030020f8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 11 Sep 2005 17:44:29 -0500 To: "Winterbottom, James" , "Michael Hammer \(mhammer\)" , "Stastny Richard" , "Marc Linsner \(mlinsner\)" , "ECRIT" From: "James M. Polk" Subject: RE: [Ecrit] Emergency [VPN issue] In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 11 Sep 2005 22:44:30.0979 (UTC) FILETIME=[5F8D3D30:01C5B722] X-Spam-Score: 0.0 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James I don't understand the point you're making here. Are you suggesting NENA believes a VPNd phone should not communicate over the VPN when calling ? I don't believe this will be universally available At 06:29 PM 9/8/2005 -0500, Winterbottom, James wrote: >This issue has been discussed in NENA at quite some length. The >consensus that is growing there, and I know that there are some people >that still disagree, is that if an enterprise is prepared to allow this >to occur, that the onus is on the enterprise to ensure that it works. >This makes the problem a little easier to deal with. > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of > > Rodrig, Benny (Benny) > > Sent: Friday, 9 September 2005 9:14 AM > > To: Michael Hammer (mhammer); Stastny Richard; Marc Linsner >(mlinsner); > > ECRIT > > Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies- > > ArchitectureConsiderations > > > > Not sure it's always possible for emergency calls to not go though the > > corporate VPN. For example, the endpoint may have no means (e.g. no >TURN > > server) to establish a session directly through the NAT at the >Backwater > > Inn, in the example below. > > > > Benny > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Michael Hammer (mhammer) > > Sent: Thursday, September 08, 2005 6:26 PM > > To: Stastny Richard; Marc Linsner (mlinsner); ECRIT > > Subject: RE: [Ecrit] > > EmergencyContextRoutingofInternetTechnologies-Architecture > > Considerations > > > > Richard, > > > > My original question was about whether a PSAP should expect calls > > (signaling and media) to originate from non-local destinations, e.g. > > international, and by inference the need for the PSAPs to be able to > > make call backs to those locations. If not, then perhaps it is a DDoS > > clue. > > > > Marc pointed out the VPN possibility. > > > > You seem to suggest that emergency calls should never go by VPN when > > dialed. > > > > So, is the VPN situation a possibility or precluded? > > > > Mike > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, September 08, 2005 5:58 PM > > > To: Michael Hammer (mhammer); Marc Linsner (mlinsner); ECRIT > > > Subject: Re: [Ecrit] Emergency > > > ContextRoutingofInternetTechnologies-Architecture Considerations > > > > > > Sorry, but I am confused with this examples: > > > > > > Somebody sitting say in Chicago should get routed to a local PSAP in > > > Chicago, regardless where his provider or sip-server is located > > > > > > If he is using a VPN to say a network in Berlin, he may either also > > > get routed by some magic we still have to work out also to a PSAP in > > > Chicago, or he is routed wrongly to a PSAP in Berlin. > > > > > > But, the PSAP in Berlin will at least get some location and also >some > > > identification from Berlin, at the network, so there is some local > > > relationship > > > > > > So what is the point? > > > > > > -richard > > > > > > ________________________________ > > > > > > Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) > > > Gesendet: Do 08.09.2005 22:56 > > > An: Marc Linsner (mlinsner); ECRIT > > > Betreff: RE: [Ecrit] Emergency > > > ContextRoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > That is certainly possible. I'm trying to get an idea of the >assumed > > > topology models here. If the call gets dropped, does the PSAP make >an > > > > > "international call" to call back such subscribers? Could the call > > > back number be a number in some Caribbean island that happens to be >a > > > 9xx equivalent? Could Berlin Ind. send a 3xx response and say drop > > > out of this VPN to make the call? > > > > > > In any case, your example proves the exception, so likely mine was a > > > dead end thought. > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: Marc Linsner (mlinsner) > > > > Sent: Thursday, September 08, 2005 4:18 PM > > > > To: Michael Hammer (mhammer); 'ECRIT' > > > > Subject: RE: [Ecrit] Emergency Context > > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > > > How about an employee of Berlin Industries, Inc. sitting at the > > > > Backwater Inn with a full vpn up to their corp. hq and calling for > > > > help. Wouldn't they look like they were coming from Berlin > > > (the .ru > > > > domain and IP address would probably be a hint)? Do you > > > want to block > > > > them? > > > > > > > > I certainly think that it is reasonable to raise a flag to the > > > > calltaker in this situation, but I wouldn't think you want > > > to build a > > > > state machine to simply block such calls. > > > > > > > > Replace Berlin with New Hampshire, New York, Mass........ > > > > > > > > -Marc- > > > > > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Michael Hammer (mhammer) > > > > > Sent: Thursday, September 08, 2005 3:12 PM > > > > > To: Ted Hardie; wilcox@e911.psd.state.vt.us; > > > > br@brianrosen.net; Andrew > > > > > Newton; Stastny Richard; ECRIT > > > > > Subject: RE: [Ecrit] Emergency Context > > > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > Ted, > > > > > > > > > > I'm confused. Are calls from Asia or Europe to the Vermont > > > > PSAP ever > > > > > legitimate? > > > > > > > > > > Somehow, I can't picture the local sheriff being able to > > > > help someone > > > > > in Berlin. I thought the point of i3 is to enable the call > > > > to go to > > > > > the local Berlin Polizei. Put another way, is it possible > > > > to use the > > > > > local nature of emergency service to protect agains DDoS? > > > > > > > > > > Mike > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > Of Ted Hardie > > > > > > Sent: Thursday, September 08, 2005 1:55 PM > > > > > > To: wilcox@e911.psd.state.vt.us; br@brianrosen.net; > > > > Andrew Newton; > > > > > > Stastny Richard; ECRIT > > > > > > Subject: RE: [Ecrit] Emergency Context Routing > > > > > > ofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > After reading the thread, I wanted to come back to Nate's > > > > original > > > > > > concern and call something out: > > > > > > > > > > > > >Here is the PSAP concern: > > > > > > > > > > > > > >An enterprising thief could figure out that a business > > > > (without an > > > > > > >alarm > > > > > > >system) in Backwater, Vermont is served by a PSAP located 25 > > > > > > miles away. > > > > > > >If one creates an IP-based denial of service attack on that > > > > > > PSAP then > > > > > > >it is safe to assume that the target of opportunity that the > > > > > > thief is > > > > > > >looking at in Backwater will not be able to contact the PSAP > > > > > > to summon > > > > > > >help. > > > > > > > > > > > > I'm assuming that the PSAP being 25 miles away means > > > > nothing about > > > > > > where the responders are. The responders in this > > > > instance might be > > > > > > sheriffs, for example, who are stationed nearby, even > > > > > further than 25 > > > > > > miles away, or whose patrol routes mean that their distance > > > > > from the > > > > > > target of opportunity is variable. So I think we > > > should cut the > > > > > > distance from this description completely, and simply see > > > > > the threat > > > > > > as "If the bad actor can determine which PSAP serves an > > > > > area in which > > > > > > a target is present, a successful attack on the PSAP prevents > > > > > > responses to the target". > > > > > > > > > > > > Does that make sense? > > > > > > > > > > > > > > > > > > > Using PSTN technologies, an enterprising thief could create > > > > > > a PSTN DoS > > > > > > >on the PSAP by simply using an auto call generator from a > > > > > pay phone > > > > > > >located in the same proximity as the target of opportunity > > > > > however, > > > > > > >this would still create a response to the general area of > > > > > the crime. > > > > > > > > > > > > There are lots of other kinds of PSTN attacks here--the > > > > > most commonly > > > > > > portrayed being "cutting the line", which doesn't work > > > > quite as it > > > > > > seems in the movies, but does have some effect. > > > > > > > > > > > > To avoid the locality problem in this attack, the bad actor > > > > > can use an > > > > > > accomplice, meat or mechanical, in any other area served by > > > > > the PSAP > > > > > > to do the same thing. This avoids the response hitting > > > > the general > > > > > > area of the crime. It also has the same counter-measure; > > > > > > call-blocking of the attacking phone. This counter-measure > > > > > is also > > > > > > relatively easy to accomplish with an IP-based service, > > > > > provided the > > > > > > attack is coming from a single IP or block. I believe the > > > > > problem is > > > > > > harder in the IP case not because the area from which the > > > > > attack can > > > > > > originate is larger but because it is easier to create a > > > > > Distributed > > > > > > Denial of Service, largely because of zombie networks and > > > > > IP spoofing. > > > > > > That is, if the attack is coming from Europe while the > > > attack is > > > > > > happening on Backwater, my response is the same as if it > > > > came from > > > > > > Nearwater, VT: > > > > > > block the attack source. But if it is coming from > > > Europe, Asia, > > > > > > Nearwater, Backwater, and many other points as well, > > > > > attempts to block > > > > > > the attack either requires effectively severing connectivity >or > > > > > > maintaining a fair amount of information about who at the > > > > IP layer > > > > > > should be talking to this PSAP. We've discussed the > > > > > effectiveness of > > > > > > that in the past. > > > > > > > > > > > > >If I > > > > > > >know the URI of the PSAP, I can now distract it from another > > > > > > continent > > > > > > >and do what I would need to do in Backwater and no > > > > > response would be > > > > > > >created in that direction - that is the new paradigm with > > > > > > IP. If I know > > > > > > >the boundaries of the Derby PSAP, I could create a PSTN > > > > based DoS > > > > > > >attack anywhere from within that boundary (potentially 50 > > > > > miles from > > > > > > >Island Pond). > > > > > > > > > > > > > >Would this happen? I don't know - I am pretty sure it > > > > > hasn't yet but > > > > > > >assigning a URI to a PSAP opens it up to whole new > > > generation of > > > > > > >"creative thinkers"..... > > > > > > > > > > > > > >Of course we can minimize the impact on the PSAP at a > > > > higher level > > > > > > >gateway by throwing a huge amount of bandwidth at it and > > > > > building in > > > > > > >intelligent alternative routing on a robust firewall. But > > > > > > that does not > > > > > > >help in the interim between here and there when someone > > > > gets their > > > > > > >hands on the PSAP boundaries and realizes the attacks they > > > > > > can initiate > > > > > > >using the PSTN DoS approach. > > > > > > > > > > > > The problem with the proposed solution, I believe, is that > > > > > aggregating > > > > > > the access to a back-to-back user agent or all-knowing > > > > > gateway is that > > > > > > you have simply created a richer target for attack. If I > > > > > can marshal > > > > > > a zombie group that takes out all of Vermont's PSAPs by > > > > eliminating > > > > > > the the gateway by DDoS, I have done far worse far more > > > > > easily than I > > > > > > could by individually attacking the PSAPs at their URIs. > > > > > If I did it > > > > > > in order to get at Backwater's target, I likely don't > > > > care that the > > > > > > general effect is larger--my purpose is met. > > > > > > > > > > > > Yes, it is easier to escalate the defenses at a single > > > > > point and yes, > > > > > > it is easier to pay for fat pipes for that single point. > > > > > But the bad > > > > > > actors here aren't using their own resources to attack you; > > > > > they are > > > > > > stealing them before trying to steal from you. Getting > > > > > into an arms > > > > > > race with someone who isn't spending their own money worries >me. > > > > > > > > > > > > regards, > > > > > > Ted > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] > >_______________________________________________ >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 Sun Sep 11 18:50:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEaeX-0000NI-Fc; Sun, 11 Sep 2005 18:50:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEaeV-0000Md-9b for ecrit@megatron.ietf.org; Sun, 11 Sep 2005 18:50:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27810 for ; Sun, 11 Sep 2005 18:50:19 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEaiZ-0007sl-3e for ecrit@ietf.org; Sun, 11 Sep 2005 18:54:36 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 11 Sep 2005 15:50:13 -0700 X-IronPort-AV: i="3.97,97,1125903600"; d="scan'208"; a="659195332:sNHT31432352" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8BMo5KC003100; Sun, 11 Sep 2005 15:50:06 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 11 Sep 2005 15:50:08 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.114.238]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 11 Sep 2005 15:50:07 -0700 Message-Id: <4.3.2.7.2.20050911174548.0278b130@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 11 Sep 2005 17:50:06 -0500 To: "Winterbottom, James" , "Ted Hardie" , "ECRIT" From: "James M. Polk" Subject: RE: [Ecrit] Emergency [mapping still needed?] In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 11 Sep 2005 22:50:08.0167 (UTC) FILETIME=[28880B70:01C5B723] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 06:36 PM 9/8/2005 -0500, Winterbottom, James wrote: >All this aside, I think that there are economies of scale, and >functionality reasons why including a gateway such an ESRP are >desirable, but these are more implementation details. Somewhere, >something has to have sufficient knowledge to use location to route the >signal to the next hop. Not necessarily. If the UA has the URI of the PSAP, no further mapping operation is necessary, and you're done, point-to-point. How the UA got the URI *could* be from Layer 2/3 (DHCP) or a protocol at Layer 7, but prior to the emergency call. Either way, the mapping operation could already be done when the call is started. >Cheers >James 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 Sun Sep 11 19:13:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEb0t-0004VU-TR; Sun, 11 Sep 2005 19:13:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEb0s-0004V9-Fi for ecrit@megatron.ietf.org; Sun, 11 Sep 2005 19:13:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28754 for ; Sun, 11 Sep 2005 19:13:19 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEb4p-0008Ou-7d for ecrit@ietf.org; Sun, 11 Sep 2005 19:17:35 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 11 Sep 2005 18:13:00 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Sun, 11 Sep 2005 18:13:00 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 11 Sep 2005 18:12:59 -0500 Message-ID: From: "Winterbottom, James" To: "James M. Polk" , "ECRIT" Date: Sun, 11 Sep 2005 18:12:56 -0500 Subject: RE: [Ecrit] Emergency [VPN issue] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 11 Sep 2005 23:12:59.0910 (UTC) FILETIME=[5A276A60:01C5B726] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Emergency [VPN issue] Thread-Index: AcW3ImXxJWPwSm4aQ/OygmT03A/KHAAAqMAg X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d9aaf4f837d0910b987cb9188300fdd Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi James, Actually that is not really the point that I am making. The point I was making was that if the enterprise forces its remote staff to pass all traffic through the VPN, including emergency calls, then the enterprise is, for all intents and purposes the access provider, and is responsible to ensure that the call will get to where it needs to go. On the technology front I don't see why a solution shouldn't be universal either. Change to soft-phones in firmware or software are going to be required to get location, and if I understand the proposed solutions correctly then, determine that the call is an emergency one and provide location also. So I don't see that providing split tunneling to cater for this is such a big deal. If enterprises elect not to deploy or engage this functionality then the point of responsibility is clear. Cheers James > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Monday, 12 September 2005 8:44 AM > To: Winterbottom, James; Michael Hammer (mhammer); Stastny Richard; Marc > Linsner (mlinsner); ECRIT > Subject: RE: [Ecrit] Emergency [VPN issue] >=20 > James >=20 > I don't understand the point you're making here. >=20 > Are you suggesting NENA believes a VPNd phone should not communicate over > the VPN when calling ? >=20 > I don't believe this will be universally available >=20 > At 06:29 PM 9/8/2005 -0500, Winterbottom, James wrote: > >This issue has been discussed in NENA at quite some length. The > >consensus that is growing there, and I know that there are some people > >that still disagree, is that if an enterprise is prepared to allow this > >to occur, that the onus is on the enterprise to ensure that it works. > >This makes the problem a little easier to deal with. > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >Of > > > Rodrig, Benny (Benny) > > > Sent: Friday, 9 September 2005 9:14 AM > > > To: Michael Hammer (mhammer); Stastny Richard; Marc Linsner > >(mlinsner); > > > ECRIT > > > Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies- > > > ArchitectureConsiderations > > > > > > Not sure it's always possible for emergency calls to not go though the > > > corporate VPN. For example, the endpoint may have no means (e.g. no > >TURN > > > server) to establish a session directly through the NAT at the > >Backwater > > > Inn, in the example below. > > > > > > Benny > > > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Michael Hammer (mhammer) > > > Sent: Thursday, September 08, 2005 6:26 PM > > > To: Stastny Richard; Marc Linsner (mlinsner); ECRIT > > > Subject: RE: [Ecrit] > > > EmergencyContextRoutingofInternetTechnologies-Architecture > > > Considerations > > > > > > Richard, > > > > > > My original question was about whether a PSAP should expect calls > > > (signaling and media) to originate from non-local destinations, e.g. > > > international, and by inference the need for the PSAPs to be able to > > > make call backs to those locations. If not, then perhaps it is a DDoS > > > clue. > > > > > > Marc pointed out the VPN possibility. > > > > > > You seem to suggest that emergency calls should never go by VPN when > > > dialed. > > > > > > So, is the VPN situation a possibility or precluded? > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, September 08, 2005 5:58 PM > > > > To: Michael Hammer (mhammer); Marc Linsner (mlinsner); ECRIT > > > > Subject: Re: [Ecrit] Emergency > > > > ContextRoutingofInternetTechnologies-Architecture Considerations > > > > > > > > Sorry, but I am confused with this examples: > > > > > > > > Somebody sitting say in Chicago should get routed to a local PSAP in > > > > Chicago, regardless where his provider or sip-server is located > > > > > > > > If he is using a VPN to say a network in Berlin, he may either also > > > > get routed by some magic we still have to work out also to a PSAP in > > > > Chicago, or he is routed wrongly to a PSAP in Berlin. > > > > > > > > But, the PSAP in Berlin will at least get some location and also > >some > > > > identification from Berlin, at the network, so there is some local > > > > relationship > > > > > > > > So what is the point? > > > > > > > > -richard > > > > > > > > ________________________________ > > > > > > > > Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) > > > > Gesendet: Do 08.09.2005 22:56 > > > > An: Marc Linsner (mlinsner); ECRIT > > > > Betreff: RE: [Ecrit] Emergency > > > > ContextRoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > > > > > That is certainly possible. I'm trying to get an idea of the > >assumed > > > > topology models here. If the call gets dropped, does the PSAP make > >an > > > > > > > "international call" to call back such subscribers? Could the call > > > > back number be a number in some Caribbean island that happens to be > >a > > > > 9xx equivalent? Could Berlin Ind. send a 3xx response and say drop > > > > out of this VPN to make the call? > > > > > > > > In any case, your example proves the exception, so likely mine was a > > > > dead end thought. > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Marc Linsner (mlinsner) > > > > > Sent: Thursday, September 08, 2005 4:18 PM > > > > > To: Michael Hammer (mhammer); 'ECRIT' > > > > > Subject: RE: [Ecrit] Emergency Context > > > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > How about an employee of Berlin Industries, Inc. sitting at the > > > > > Backwater Inn with a full vpn up to their corp. hq and calling for > > > > > help. Wouldn't they look like they were coming from Berlin > > > > (the .ru > > > > > domain and IP address would probably be a hint)? Do you > > > > want to block > > > > > them? > > > > > > > > > > I certainly think that it is reasonable to raise a flag to the > > > > > calltaker in this situation, but I wouldn't think you want > > > > to build a > > > > > state machine to simply block such calls. > > > > > > > > > > Replace Berlin with New Hampshire, New York, Mass........ > > > > > > > > > > -Marc- > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > Of Michael Hammer (mhammer) > > > > > > Sent: Thursday, September 08, 2005 3:12 PM > > > > > > To: Ted Hardie; wilcox@e911.psd.state.vt.us; > > > > > br@brianrosen.net; Andrew > > > > > > Newton; Stastny Richard; ECRIT > > > > > > Subject: RE: [Ecrit] Emergency Context > > > > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > Ted, > > > > > > > > > > > > I'm confused. Are calls from Asia or Europe to the Vermont > > > > > PSAP ever > > > > > > legitimate? > > > > > > > > > > > > Somehow, I can't picture the local sheriff being able to > > > > > help someone > > > > > > in Berlin. I thought the point of i3 is to enable the call > > > > > to go to > > > > > > the local Berlin Polizei. Put another way, is it possible > > > > > to use the > > > > > > local nature of emergency service to protect agains DDoS? > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ecrit-bounces@ietf.org > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > Of Ted Hardie > > > > > > > Sent: Thursday, September 08, 2005 1:55 PM > > > > > > > To: wilcox@e911.psd.state.vt.us; br@brianrosen.net; > > > > > Andrew Newton; > > > > > > > Stastny Richard; ECRIT > > > > > > > Subject: RE: [Ecrit] Emergency Context Routing > > > > > > > ofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > > > After reading the thread, I wanted to come back to Nate's > > > > > original > > > > > > > concern and call something out: > > > > > > > > > > > > > > >Here is the PSAP concern: > > > > > > > > > > > > > > > >An enterprising thief could figure out that a business > > > > > (without an > > > > > > > >alarm > > > > > > > >system) in Backwater, Vermont is served by a PSAP located 25 > > > > > > > miles away. > > > > > > > >If one creates an IP-based denial of service attack on that > > > > > > > PSAP then > > > > > > > >it is safe to assume that the target of opportunity that the > > > > > > > thief is > > > > > > > >looking at in Backwater will not be able to contact the PSAP > > > > > > > to summon > > > > > > > >help. > > > > > > > > > > > > > > I'm assuming that the PSAP being 25 miles away means > > > > > nothing about > > > > > > > where the responders are. The responders in this > > > > > instance might be > > > > > > > sheriffs, for example, who are stationed nearby, even > > > > > > further than 25 > > > > > > > miles away, or whose patrol routes mean that their distance > > > > > > from the > > > > > > > target of opportunity is variable. So I think we > > > > should cut the > > > > > > > distance from this description completely, and simply see > > > > > > the threat > > > > > > > as "If the bad actor can determine which PSAP serves an > > > > > > area in which > > > > > > > a target is present, a successful attack on the PSAP prevents > > > > > > > responses to the target". > > > > > > > > > > > > > > Does that make sense? > > > > > > > > > > > > > > > > > > > > > > Using PSTN technologies, an enterprising thief could create > > > > > > > a PSTN DoS > > > > > > > >on the PSAP by simply using an auto call generator from a > > > > > > pay phone > > > > > > > >located in the same proximity as the target of opportunity > > > > > > however, > > > > > > > >this would still create a response to the general area of > > > > > > the crime. > > > > > > > > > > > > > > There are lots of other kinds of PSTN attacks here--the > > > > > > most commonly > > > > > > > portrayed being "cutting the line", which doesn't work > > > > > quite as it > > > > > > > seems in the movies, but does have some effect. > > > > > > > > > > > > > > To avoid the locality problem in this attack, the bad actor > > > > > > can use an > > > > > > > accomplice, meat or mechanical, in any other area served by > > > > > > the PSAP > > > > > > > to do the same thing. This avoids the response hitting > > > > > the general > > > > > > > area of the crime. It also has the same counter-measure; > > > > > > > call-blocking of the attacking phone. This counter-measure > > > > > > is also > > > > > > > relatively easy to accomplish with an IP-based service, > > > > > > provided the > > > > > > > attack is coming from a single IP or block. I believe the > > > > > > problem is > > > > > > > harder in the IP case not because the area from which the > > > > > > attack can > > > > > > > originate is larger but because it is easier to create a > > > > > > Distributed > > > > > > > Denial of Service, largely because of zombie networks and > > > > > > IP spoofing. > > > > > > > That is, if the attack is coming from Europe while the > > > > attack is > > > > > > > happening on Backwater, my response is the same as if it > > > > > came from > > > > > > > Nearwater, VT: > > > > > > > block the attack source. But if it is coming from > > > > Europe, Asia, > > > > > > > Nearwater, Backwater, and many other points as well, > > > > > > attempts to block > > > > > > > the attack either requires effectively severing connectivity > >or > > > > > > > maintaining a fair amount of information about who at the > > > > > IP layer > > > > > > > should be talking to this PSAP. We've discussed the > > > > > > effectiveness of > > > > > > > that in the past. > > > > > > > > > > > > > > >If I > > > > > > > >know the URI of the PSAP, I can now distract it from another > > > > > > > continent > > > > > > > >and do what I would need to do in Backwater and no > > > > > > response would be > > > > > > > >created in that direction - that is the new paradigm with > > > > > > > IP. If I know > > > > > > > >the boundaries of the Derby PSAP, I could create a PSTN > > > > > based DoS > > > > > > > >attack anywhere from within that boundary (potentially 50 > > > > > > miles from > > > > > > > >Island Pond). > > > > > > > > > > > > > > > >Would this happen? I don't know - I am pretty sure it > > > > > > hasn't yet but > > > > > > > >assigning a URI to a PSAP opens it up to whole new > > > > generation of > > > > > > > >"creative thinkers"..... > > > > > > > > > > > > > > > >Of course we can minimize the impact on the PSAP at a > > > > > higher level > > > > > > > >gateway by throwing a huge amount of bandwidth at it and > > > > > > building in > > > > > > > >intelligent alternative routing on a robust firewall. But > > > > > > > that does not > > > > > > > >help in the interim between here and there when someone > > > > > gets their > > > > > > > >hands on the PSAP boundaries and realizes the attacks they > > > > > > > can initiate > > > > > > > >using the PSTN DoS approach. > > > > > > > > > > > > > > The problem with the proposed solution, I believe, is that > > > > > > aggregating > > > > > > > the access to a back-to-back user agent or all-knowing > > > > > > gateway is that > > > > > > > you have simply created a richer target for attack. If I > > > > > > can marshal > > > > > > > a zombie group that takes out all of Vermont's PSAPs by > > > > > eliminating > > > > > > > the the gateway by DDoS, I have done far worse far more > > > > > > easily than I > > > > > > > could by individually attacking the PSAPs at their URIs. > > > > > > If I did it > > > > > > > in order to get at Backwater's target, I likely don't > > > > > care that the > > > > > > > general effect is larger--my purpose is met. > > > > > > > > > > > > > > Yes, it is easier to escalate the defenses at a single > > > > > > point and yes, > > > > > > > it is easier to pay for fat pipes for that single point. > > > > > > But the bad > > > > > > > actors here aren't using their own resources to attack you; > > > > > > they are > > > > > > > stealing them before trying to steal from you. Getting > > > > > > into an arms > > > > > > > race with someone who isn't spending their own money worries > >me. > > > > > > > > > > > > > > regards, > > > > > > > Ted > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 > > > >----------------------------------------------------------------------- -- > ----------------------- > >This message is for the designated recipient only and may > >contain privileged, proprietary, or otherwise private information. > >If you have received it in error, please notify the sender > >immediately and delete the original. Any unauthorized use of > >this email is prohibited. > >----------------------------------------------------------------------- -- > ----------------------- > >[mf2] > > > >_______________________________________________ > >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. ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 12 08:19:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEnHe-0001rR-42; Mon, 12 Sep 2005 08:19:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EE6EX-0008Vs-0I for ecrit@megatron.ietf.org; Sat, 10 Sep 2005 10:21:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04790 for ; Sat, 10 Sep 2005 10:21:22 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EE6IA-00081y-Rf for ecrit@ietf.org; Sat, 10 Sep 2005 10:25:21 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 10 Sep 2005 07:21:14 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,95,1125903600"; d="scan'208"; a="9192445:sNHT21159624" Received: from [68.50.138.194] (che-vpn-cluster-1-203.cisco.com [10.86.240.203]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8AELBT6011890; Sat, 10 Sep 2005 10:21:12 -0400 (EDT) In-Reply-To: <43222C87.7050009@cs.columbia.edu> References: <43222C87.7050009@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <308d8d835ca81c17ee80bcf6226fc8fb@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConsiderations Date: Sat, 10 Sep 2005 10:21:14 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 12 Sep 2005 08:19:37 -0400 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org A valid reason for organizations that deploy Internet VPNs to prohibit split tunneling, with some traffic through the VPN tunnel and some straight to Internet destinations, is control of the corporate network perimeter. A host with split tunneling is exposed to worms and other security threats through its access outside the VPN. Because it is also inside the VPN, this host is a disease vector between the outside and inside. It would be a serious mistake to force a choice between this valid deployment of VPN technology and location information access for emergency services. John On Sep 9, 2005, at 8:44 PM, Henning Schulzrinne wrote: > > At least some of the VPN software can be configured not to route > "random" (non-corporate) Internet addresses via the VPN at all. This > makes some sense - there is little benefit of visiting the web page of > some outfit by tromboning or hairpinning (to use the PSTN equivalents) > via the corporate campus. Maybe such configurations will become more > common, given these difficulties (or OS will support the ability to > select the non-VPN interface explicitly when opening a socket.) > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 12 10:30:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEpK4-0000og-PT; Mon, 12 Sep 2005 10:30:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEpK3-0000o4-AA for ecrit@megatron.ietf.org; Mon, 12 Sep 2005 10:30:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22388 for ; Mon, 12 Sep 2005 10:30:05 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEpO7-0005Or-BS for ecrit@ietf.org; Mon, 12 Sep 2005 10:34:28 -0400 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 j8CESnNN002132; Mon, 12 Sep 2005 09:28:49 -0500 (CDT) 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 j8CESm411920; Mon, 12 Sep 2005 09:28:48 -0500 (CDT) Message-Id: <6.2.1.2.0.20050912092604.03f6caa8@ihmail.ih.lucent.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 12 Sep 2005 09:28:47 -0500 To: John Schnizlein , Henning Schulzrinne From: John Rosenberg Subject: Re: [Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConsid erations In-Reply-To: <308d8d835ca81c17ee80bcf6226fc8fb@cisco.com> References: <43222C87.7050009@cs.columbia.edu> <308d8d835ca81c17ee80bcf6226fc8fb@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Have to agree with John here. As one data point, our own corporate VPN does not allow split tunneling, and our IT folks are *very* clear that even connecting a PC that's on the VPN to another network (e.g. the public internet) is prohibited. I would think that this is the rule rather than the exception. John At 09:21 AM 9/10/2005, John Schnizlein wrote: > >A valid reason for organizations that deploy Internet VPNs to prohibit >split tunneling, with some traffic through the VPN tunnel and some >straight to Internet destinations, is control of the corporate network >perimeter. A host with split tunneling is exposed to worms and other >security threats through its access outside the VPN. Because it is >also inside the VPN, this host is a disease vector between the outside >and inside. > >It would be a serious mistake to force a choice between this valid >deployment of VPN technology and location information access for >emergency services. > >John > >On Sep 9, 2005, at 8:44 PM, Henning Schulzrinne wrote: >> >> At least some of the VPN software can be configured not to route >> "random" (non-corporate) Internet addresses via the VPN at all. This >> makes some sense - there is little benefit of visiting the web page of >> some outfit by tromboning or hairpinning (to use the PSTN equivalents) >> via the corporate campus. Maybe such configurations will become more >> common, given these difficulties (or OS will support the ability to >> select the non-VPN interface explicitly when opening a socket.) >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 12 10:38:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEpS0-0002RN-0Q; Mon, 12 Sep 2005 10:38:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEpRy-0002PO-7h for ecrit@megatron.ietf.org; Mon, 12 Sep 2005 10:38:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22899 for ; Mon, 12 Sep 2005 10:38:24 -0400 (EDT) Message-Id: <200509121438.KAA22899@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEpWB-0005b7-DS for ecrit@ietf.org; Mon, 12 Sep 2005 10:42:47 -0400 Received: from kci-host48.cust.wifi.sprintpcs.com ([65.174.23.48] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EEpRY-0007pr-Ro; Mon, 12 Sep 2005 09:38:01 -0500 From: "Brian Rosen" To: "'James M. Polk'" , "'Winterbottom, James'" , "'Ted Hardie'" , "'ECRIT'" Subject: RE: [Ecrit] Emergency [mapping still needed?] Date: Mon, 12 Sep 2005 10:37:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4.3.2.7.2.20050911174548.0278b130@email.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW3I2XTpRQ5iwQ9TQWh91Yg4gZxJAAcPDAg 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: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think that the idea that a phone gets its own location, recognizes emergency calls itself, and does its own mapping is a Really Good Idea. It means fewer things have to work to get an emergency call through. I think doing a mapping and caching it during "boot", and periodically thereafter (that means both getting location, and mapping from time to time) is the way to do that. I'd prefer that the phone attempt mapping just before making an emergency call. If that works, using the result of that fresh mapping is best. If for some reason, that doesn't work, using the cached data is next best. While I expect that the PSAP side will use the tools it has available to turn a URI obtained from mapping to an IP address of an available destination (i.e. PSAP) even if the original intended target was unavailable (by, for example, having alternative records in the DNS, or even changing the DNS), it's hard to make that always work when the world starts falling apart. I would really, really, not like to rely on "stale" data when an emergency call occurs, so I would prefer that, if possible, the mapping be fresh. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James M. Polk Sent: Sunday, September 11, 2005 6:50 PM To: Winterbottom, James; Ted Hardie; ECRIT Subject: RE: [Ecrit] Emergency [mapping still needed?] At 06:36 PM 9/8/2005 -0500, Winterbottom, James wrote: >All this aside, I think that there are economies of scale, and >functionality reasons why including a gateway such an ESRP are >desirable, but these are more implementation details. Somewhere, >something has to have sufficient knowledge to use location to route the >signal to the next hop. Not necessarily. If the UA has the URI of the PSAP, no further mapping operation is necessary, and you're done, point-to-point. How the UA got the URI *could* be from Layer 2/3 (DHCP) or a protocol at Layer 7, but prior to the emergency call. Either way, the mapping operation could already be done when the call is started. >Cheers >James 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 Mon Sep 12 11:09:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEpwL-0007Nl-DN; Mon, 12 Sep 2005 11:09:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEpwJ-0007Nf-PT for ecrit@megatron.ietf.org; Mon, 12 Sep 2005 11:09:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24938 for ; Mon, 12 Sep 2005 11:09:45 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EEq0V-0006cw-Vy for ecrit@ietf.org; Mon, 12 Sep 2005 11:14:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: Re: [Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConsiderations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Sep 2005 17:13:09 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C44EE@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConsiderations Thread-Index: AcW3p4DPe4zyw7mLQsulAvT6CdkZ1QABBput From: "Stastny Richard" To: "John Rosenberg" , "John Schnizlein" , "Henning Schulzrinne" X-Spam-Score: 0.2 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Maybe I do not understand the problem with VPNs fully, but IMHO if you use a VPN you must first attach to the local network to get the local IP connection to set up the VPN. Doing so you get an IP address via DHCP and you also may get the location. Now you have the location stored somewhere=20 on the device. =20 If you now set up the VPN, you get a new IP address from home network, but you still have the location stored and can retrieve it. =20 There is only one requirement left for the home network: you need=20 an access to the mapping database and you also need to be able to set up a SIP connection to the PSAP, even if the home networks does not allow general access to the Internet. I do not see a security problem here. =20 Richard =20 =20 ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von John Rosenberg Gesendet: Mo 12.09.2005 16:28 An: John Schnizlein; Henning Schulzrinne Cc: ECRIT Betreff: = Re:[Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConsi= derations Have to agree with John here. As one data point, our own corporate VPN = does not allow split tunneling, and our IT folks are *very* clear that even connecting a PC that's on the VPN to another network (e.g. the public internet) is prohibited. I would think that this is the rule rather than the exception. John At 09:21 AM 9/10/2005, John Schnizlein wrote: > >A valid reason for organizations that deploy Internet VPNs to prohibit >split tunneling, with some traffic through the VPN tunnel and some >straight to Internet destinations, is control of the corporate network >perimeter. A host with split tunneling is exposed to worms and other >security threats through its access outside the VPN. Because it is >also inside the VPN, this host is a disease vector between the outside >and inside. > >It would be a serious mistake to force a choice between this valid >deployment of VPN technology and location information access for >emergency services. > >John > >On Sep 9, 2005, at 8:44 PM, Henning Schulzrinne wrote: >> >> At least some of the VPN software can be configured not to route >> "random" (non-corporate) Internet addresses via the VPN at all. This >> makes some sense - there is little benefit of visiting the web page = of >> some outfit by tromboning or hairpinning (to use the PSTN = equivalents) >> via the corporate campus. Maybe such configurations will become more >> common, given these difficulties (or OS will support the ability to >> select the non-VPN interface explicitly when opening a socket.) >> _______________________________________________ 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 Sep 12 11:27:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEqD6-0004mt-9l; Mon, 12 Sep 2005 11:27:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEqD2-0004lQ-Fb for ecrit@megatron.ietf.org; Mon, 12 Sep 2005 11:27:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26770 for ; Mon, 12 Sep 2005 11:26:52 -0400 (EDT) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEqH5-0007Vu-DS for ecrit@ietf.org; Mon, 12 Sep 2005 11:31:16 -0400 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 j8CFDaEX002497 for ; Mon, 12 Sep 2005 11:13:36 -0400 (EDT) Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8CDfFEX022034 for ; Mon, 12 Sep 2005 09:41:20 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Ecrit] Emergency [VPN issue] Date: Mon, 12 Sep 2005 09:54:13 -0400 Message-ID: Thread-Topic: [Ecrit] Emergency [VPN issue] Thread-Index: AcW3ImXxJWPwSm4aQ/OygmT03A/KHAAAqMAgAB59zEA= From: "Rodrig, Benny \(Benny\)" To: "Winterbottom, James" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb7a33d18683bf5063a44e640cf125f1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James, I don't see how the enterprise, even with a VPN policy, can be considered an access provider. The concept of the access provider, as opposed to the application service provider, implies some sort of locality and hence knowledge of user's location. These do not shift from the local Internet access provider to the remote enterprise headquarters just because the endpoint is connecting through a VPN.=20 Benny -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Sunday, September 11, 2005 7:13 PM To: James M. Polk; ECRIT Subject: RE: [Ecrit] Emergency [VPN issue] Hi James, Actually that is not really the point that I am making. The point I was making was that if the enterprise forces its remote staff to pass all traffic through the VPN, including emergency calls, then the enterprise is, for all intents and purposes the access provider, and is responsible to ensure that the call will get to where it needs to go. On the technology front I don't see why a solution shouldn't be universal either. Change to soft-phones in firmware or software are going to be required to get location, and if I understand the proposed solutions correctly then, determine that the call is an emergency one and provide location also. So I don't see that providing split tunneling to cater for this is such a big deal. If enterprises elect not to deploy or engage this functionality then the point of responsibility is clear. Cheers James > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Monday, 12 September 2005 8:44 AM > To: Winterbottom, James; Michael Hammer (mhammer); Stastny Richard; Marc > Linsner (mlinsner); ECRIT > Subject: RE: [Ecrit] Emergency [VPN issue] >=20 > James >=20 > I don't understand the point you're making here. >=20 > Are you suggesting NENA believes a VPNd phone should not communicate over > the VPN when calling ? >=20 > I don't believe this will be universally available >=20 > At 06:29 PM 9/8/2005 -0500, Winterbottom, James wrote: > >This issue has been discussed in NENA at quite some length. The=20 > >consensus that is growing there, and I know that there are some people > >that still disagree, is that if an enterprise is prepared to allow this > >to occur, that the onus is on the enterprise to ensure that it works. > >This makes the problem a little easier to deal with. > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >Of > > > Rodrig, Benny (Benny) > > > Sent: Friday, 9 September 2005 9:14 AM > > > To: Michael Hammer (mhammer); Stastny Richard; Marc Linsner > >(mlinsner); > > > ECRIT > > > Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies- > > > ArchitectureConsiderations > > > > > > Not sure it's always possible for emergency calls to not go though the > > > corporate VPN. For example, the endpoint may have no means (e.g. no > >TURN > > > server) to establish a session directly through the NAT at the > >Backwater > > > Inn, in the example below. > > > > > > Benny > > > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Michael Hammer (mhammer) > > > Sent: Thursday, September 08, 2005 6:26 PM > > > To: Stastny Richard; Marc Linsner (mlinsner); ECRIT > > > Subject: RE: [Ecrit] > > > EmergencyContextRoutingofInternetTechnologies-Architecture > > > Considerations > > > > > > Richard, > > > > > > My original question was about whether a PSAP should expect calls=20 > > > (signaling and media) to originate from non-local destinations, e.g. > > > international, and by inference the need for the PSAPs to be able to > > > make call backs to those locations. If not, then perhaps it is a DDoS > > > clue. > > > > > > Marc pointed out the VPN possibility. > > > > > > You seem to suggest that emergency calls should never go by VPN when > > > dialed. > > > > > > So, is the VPN situation a possibility or precluded? > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, September 08, 2005 5:58 PM > > > > To: Michael Hammer (mhammer); Marc Linsner (mlinsner); ECRIT > > > > Subject: Re: [Ecrit] Emergency > > > > ContextRoutingofInternetTechnologies-Architecture Considerations > > > > > > > > Sorry, but I am confused with this examples: > > > > > > > > Somebody sitting say in Chicago should get routed to a local PSAP in > > > > Chicago, regardless where his provider or sip-server is located > > > > > > > > If he is using a VPN to say a network in Berlin, he may either also > > > > get routed by some magic we still have to work out also to a PSAP in > > > > Chicago, or he is routed wrongly to a PSAP in Berlin. > > > > > > > > But, the PSAP in Berlin will at least get some location and also > >some > > > > identification from Berlin, at the network, so there is some local > > > > relationship > > > > > > > > So what is the point? > > > > > > > > -richard > > > > > > > > ________________________________ > > > > > > > > Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) > > > > Gesendet: Do 08.09.2005 22:56 > > > > An: Marc Linsner (mlinsner); ECRIT > > > > Betreff: RE: [Ecrit] Emergency > > > > ContextRoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > > > > > That is certainly possible. I'm trying to get an idea of the > >assumed > > > > topology models here. If the call gets dropped, does the PSAP make > >an > > > > > > > "international call" to call back such subscribers? Could the call > > > > back number be a number in some Caribbean island that happens to be > >a > > > > 9xx equivalent? Could Berlin Ind. send a 3xx response and say drop > > > > out of this VPN to make the call? > > > > > > > > In any case, your example proves the exception, so likely mine was a > > > > dead end thought. > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Marc Linsner (mlinsner) > > > > > Sent: Thursday, September 08, 2005 4:18 PM > > > > > To: Michael Hammer (mhammer); 'ECRIT' > > > > > Subject: RE: [Ecrit] Emergency Context=20 > > > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > How about an employee of Berlin Industries, Inc. sitting at the > > > > > Backwater Inn with a full vpn up to their corp. hq and calling for > > > > > help. Wouldn't they look like they were coming from Berlin > > > > (the .ru > > > > > domain and IP address would probably be a hint)? Do you > > > > want to block > > > > > them? > > > > > > > > > > I certainly think that it is reasonable to raise a flag to the > > > > > calltaker in this situation, but I wouldn't think you want > > > > to build a > > > > > state machine to simply block such calls. > > > > > > > > > > Replace Berlin with New Hampshire, New York, Mass........ > > > > > > > > > > -Marc- > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > Of Michael Hammer (mhammer) > > > > > > Sent: Thursday, September 08, 2005 3:12 PM > > > > > > To: Ted Hardie; wilcox@e911.psd.state.vt.us; > > > > > br@brianrosen.net; Andrew > > > > > > Newton; Stastny Richard; ECRIT > > > > > > Subject: RE: [Ecrit] Emergency Context=20 > > > > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > Ted, > > > > > > > > > > > > I'm confused. Are calls from Asia or Europe to the Vermont > > > > > PSAP ever > > > > > > legitimate? > > > > > > > > > > > > Somehow, I can't picture the local sheriff being able to > > > > > help someone > > > > > > in Berlin. I thought the point of i3 is to enable the call > > > > > to go to > > > > > > the local Berlin Polizei. Put another way, is it possible > > > > > to use the > > > > > > local nature of emergency service to protect agains DDoS? > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ecrit-bounces@ietf.org > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > Of Ted Hardie > > > > > > > Sent: Thursday, September 08, 2005 1:55 PM > > > > > > > To: wilcox@e911.psd.state.vt.us; br@brianrosen.net; > > > > > Andrew Newton; > > > > > > > Stastny Richard; ECRIT > > > > > > > Subject: RE: [Ecrit] Emergency Context Routing=20 > > > > > > > ofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > > > After reading the thread, I wanted to come back to Nate's > > > > > original > > > > > > > concern and call something out: > > > > > > > > > > > > > > >Here is the PSAP concern: > > > > > > > > > > > > > > > >An enterprising thief could figure out that a business > > > > > (without an > > > > > > > >alarm > > > > > > > >system) in Backwater, Vermont is served by a PSAP located 25 > > > > > > > miles away. > > > > > > > >If one creates an IP-based denial of service attack on that > > > > > > > PSAP then > > > > > > > >it is safe to assume that the target of opportunity that the > > > > > > > thief is > > > > > > > >looking at in Backwater will not be able to contact the PSAP > > > > > > > to summon > > > > > > > >help. > > > > > > > > > > > > > > I'm assuming that the PSAP being 25 miles away means > > > > > nothing about > > > > > > > where the responders are. The responders in this > > > > > instance might be > > > > > > > sheriffs, for example, who are stationed nearby, even > > > > > > further than 25 > > > > > > > miles away, or whose patrol routes mean that their distance > > > > > > from the > > > > > > > target of opportunity is variable. So I think we > > > > should cut the > > > > > > > distance from this description completely, and simply see > > > > > > the threat > > > > > > > as "If the bad actor can determine which PSAP serves an > > > > > > area in which > > > > > > > a target is present, a successful attack on the PSAP prevents > > > > > > > responses to the target". > > > > > > > > > > > > > > Does that make sense? > > > > > > > > > > > > > > > > > > > > > > Using PSTN technologies, an enterprising thief could create > > > > > > > a PSTN DoS > > > > > > > >on the PSAP by simply using an auto call generator from a > > > > > > pay phone > > > > > > > >located in the same proximity as the target of opportunity > > > > > > however, > > > > > > > >this would still create a response to the general area of > > > > > > the crime. > > > > > > > > > > > > > > There are lots of other kinds of PSTN attacks here--the > > > > > > most commonly > > > > > > > portrayed being "cutting the line", which doesn't work > > > > > quite as it > > > > > > > seems in the movies, but does have some effect. > > > > > > > > > > > > > > To avoid the locality problem in this attack, the bad actor > > > > > > can use an > > > > > > > accomplice, meat or mechanical, in any other area served by > > > > > > the PSAP > > > > > > > to do the same thing. This avoids the response hitting > > > > > the general > > > > > > > area of the crime. It also has the same counter-measure;=20 > > > > > > > call-blocking of the attacking phone. This counter-measure > > > > > > is also > > > > > > > relatively easy to accomplish with an IP-based service, > > > > > > provided the > > > > > > > attack is coming from a single IP or block. I believe the > > > > > > problem is > > > > > > > harder in the IP case not because the area from which the > > > > > > attack can > > > > > > > originate is larger but because it is easier to create a > > > > > > Distributed > > > > > > > Denial of Service, largely because of zombie networks and > > > > > > IP spoofing. > > > > > > > That is, if the attack is coming from Europe while the > > > > attack is > > > > > > > happening on Backwater, my response is the same as if it > > > > > came from > > > > > > > Nearwater, VT: > > > > > > > block the attack source. But if it is coming from > > > > Europe, Asia, > > > > > > > Nearwater, Backwater, and many other points as well, > > > > > > attempts to block > > > > > > > the attack either requires effectively severing connectivity > >or > > > > > > > maintaining a fair amount of information about who at the > > > > > IP layer > > > > > > > should be talking to this PSAP. We've discussed the > > > > > > effectiveness of > > > > > > > that in the past. > > > > > > > > > > > > > > >If I > > > > > > > >know the URI of the PSAP, I can now distract it from another > > > > > > > continent > > > > > > > >and do what I would need to do in Backwater and no > > > > > > response would be > > > > > > > >created in that direction - that is the new paradigm with > > > > > > > IP. If I know > > > > > > > >the boundaries of the Derby PSAP, I could create a PSTN > > > > > based DoS > > > > > > > >attack anywhere from within that boundary (potentially 50 > > > > > > miles from > > > > > > > >Island Pond). > > > > > > > > > > > > > > > >Would this happen? I don't know - I am pretty sure it > > > > > > hasn't yet but > > > > > > > >assigning a URI to a PSAP opens it up to whole new > > > > generation of > > > > > > > >"creative thinkers"..... > > > > > > > > > > > > > > > >Of course we can minimize the impact on the PSAP at a > > > > > higher level > > > > > > > >gateway by throwing a huge amount of bandwidth at it and > > > > > > building in > > > > > > > >intelligent alternative routing on a robust firewall. But > > > > > > > that does not > > > > > > > >help in the interim between here and there when someone > > > > > gets their > > > > > > > >hands on the PSAP boundaries and realizes the attacks they > > > > > > > can initiate > > > > > > > >using the PSTN DoS approach. > > > > > > > > > > > > > > The problem with the proposed solution, I believe, is that > > > > > > aggregating > > > > > > > the access to a back-to-back user agent or all-knowing > > > > > > gateway is that > > > > > > > you have simply created a richer target for attack. If I > > > > > > can marshal > > > > > > > a zombie group that takes out all of Vermont's PSAPs by > > > > > eliminating > > > > > > > the the gateway by DDoS, I have done far worse far more > > > > > > easily than I > > > > > > > could by individually attacking the PSAPs at their URIs. > > > > > > If I did it > > > > > > > in order to get at Backwater's target, I likely don't > > > > > care that the > > > > > > > general effect is larger--my purpose is met. > > > > > > > > > > > > > > Yes, it is easier to escalate the defenses at a single > > > > > > point and yes, > > > > > > > it is easier to pay for fat pipes for that single point. > > > > > > But the bad > > > > > > > actors here aren't using their own resources to attack you; > > > > > > they are > > > > > > > stealing them before trying to steal from you. Getting > > > > > > into an arms > > > > > > > race with someone who isn't spending their own money worries > >me. > > > > > > > > > > > > > > regards, > > > > > > > Ted > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 > > > >----------------------------------------------------------------------- -- > ----------------------- > >This message is for the designated recipient only and may contain=20 > >privileged, proprietary, or otherwise private information. > >If you have received it in error, please notify the sender=20 > >immediately and delete the original. Any unauthorized use of this=20 > >email is prohibited. > >----------------------------------------------------------------------- -- > ----------------------- > >[mf2] > > > >_______________________________________________ > >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. ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ------------------------ [mf2] _______________________________________________ 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 Sep 12 11:42:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEqRw-0007Ds-JU; Mon, 12 Sep 2005 11:42:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEqRv-0007Db-6k for ecrit@megatron.ietf.org; Mon, 12 Sep 2005 11:42:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27440 for ; Mon, 12 Sep 2005 11:42:25 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEqW6-0007tm-T9 for ecrit@ietf.org; Mon, 12 Sep 2005 11:46:49 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 12 Sep 2005 08:42:13 -0700 X-IronPort-AV: i="3.97,101,1125903600"; d="scan'208"; a="659290958:sNHT30609200" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8CFfsKO003882; Mon, 12 Sep 2005 08:42:09 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Sep 2005 08:42:06 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.122.166]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Sep 2005 08:42:06 -0700 Message-Id: <4.3.2.7.2.20050912103208.02e92130@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Sep 2005 10:42:04 -0500 To: "Winterbottom, James" , "ECRIT" From: "James M. Polk" Subject: RE: [Ecrit] Emergency [VPN issue] In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 12 Sep 2005 15:42:06.0353 (UTC) FILETIME=[8763F810:01C5B7B0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 06:12 PM 9/11/2005 -0500, Winterbottom, James wrote: >Hi James, > >Actually that is not really the point that I am making. that's why I asked for clarification ;-) >The point I was >making was that if the enterprise forces its remote staff to pass all >traffic through the VPN, including emergency calls, then the enterprise >is, for all intents and purposes the access provider, and is responsible >to ensure that the call will get to where it needs to go. my concern here is the situation in which the client doesn't know where they are because their pre-VPN access provider didn't provide that info to the UA. Almost no matter where the client is, they will be in a different PSAP jurisdiction than the corporation, meaning putting the burden on the corporation to provide location seems impossible to accomplish. That said, the call should still be routed to a PSAP. This is why I believe needs to work on the PSAP-to-PSAP call transfer scenario, as the VPNd client could be inadvertantly routed to the corporate's PSAP some of the time too. This PSAP will ask where the person is, and then need to know what to do with the call. International call tranfers between PSAPs will be trick though. This routing to the appropriate PSAP from a call transfer point of view should be addressed in ECRIT too, IMO, but it needs to be phase II of what we're doing here - and maybe nothing more than a short reqs ID and a separate short BCP. >Cheers >James cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 12 12:45:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EErR9-0003ee-67; Mon, 12 Sep 2005 12:45:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEr9Z-0005Yg-1D for ecrit@megatron.ietf.org; Mon, 12 Sep 2005 12:27:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29239 for ; Mon, 12 Sep 2005 12:27:30 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EErDm-0000Z5-6Z for ecrit@ietf.org; Mon, 12 Sep 2005 12:31:55 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 12 Sep 2005 12:27:22 -0400 X-IronPort-AV: i="3.97,101,1125892800"; d="scan'208"; a="69887054:sNHT31365176" Received: from [68.50.138.194] (che-vpn-cluster-1-121.cisco.com [10.86.240.121]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8CGRIT6001356; Mon, 12 Sep 2005 12:27:19 -0400 (EDT) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C44EE@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C44EE@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <82a8646d1539bd3bf6a1452c453ac2d7@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConsiderations Date: Mon, 12 Sep 2005 12:27:18 -0400 To: "Stastny Richard" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 12 Sep 2005 12:45:42 -0400 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Richard, If the design for obtaining and providing location information is as you summarized, there is no problem with VPNs. We should note that VPN clients should not disturb the location option that the client received from its initial DHCP request. I don't know if they are careful about that while they update options such as domain suffix and DNS-server addresses. The problem with VPNs is for designs such as HELD that assume the IP address of the host enables determination of the location. When it was pointed out that the host's IP address is assigned by the enterprise end of the VPN tunnel, which is potentially very far from the tele-worker, a proposal was made that the host use its original (not tunnel) address when attempting an emergency call. It is the implied need for split-tunnel that exposes the original IP source address that leads to the security problem: host both inside and outside the enterprise security perimeter. John On Sep 12, 2005, at 11:13 AM, Stastny Richard wrote: > Maybe I do not understand the problem with VPNs fully, > but IMHO if you use a VPN you must first attach to the local > network to get the local IP connection to set up the VPN. > Doing so you get an IP address via DHCP and you also may > get the location. Now you have the location stored somewhere > on the device. > > If you now set up the VPN, you get a new IP address from home > network, but you still have the location stored and can retrieve it. > > There is only one requirement left for the home network: you need > an access to the mapping database and you also need to be able to > set up a SIP connection to the PSAP, even if the home networks > does not allow general access to the Internet. > > I do not see a security problem here. > > Richard > ________________________________ > > Von: ecrit-bounces@ietf.org im Auftrag von John Rosenberg > > Have to agree with John here. As one data point, our own corporate VPN > does > not allow split tunneling, and our IT folks are *very* clear that even > connecting a PC that's on the VPN to another network (e.g. the public > internet) is prohibited. I would think that this is the rule rather > than > the exception. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 12 14:20:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEsuS-0003xs-3m; Mon, 12 Sep 2005 14:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEsuO-0003vW-6R for ecrit@megatron.ietf.org; Mon, 12 Sep 2005 14:20:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05788 for ; Mon, 12 Sep 2005 14:19:44 -0400 (EDT) Received: from [199.117.205.100] (helo=ns2.sccx.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEsyN-0004dQ-E5 for ecrit@ietf.org; Mon, 12 Sep 2005 14:24:09 -0400 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] Emergency [mapping still needed?] X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 12 Sep 2005 13:19:19 -0500 Message-ID: <422D410BD61FC04185076AD99AA7207A010EE800@inilmx01.lgmt.trdo> Thread-Topic: [Ecrit] Emergency [mapping still needed?] Thread-Index: AcW3I2XTpRQ5iwQ9TQWh91Yg4gZxJAAcPDAgAAhgD6A= From: "McCalmont, Patti" To: , "James M. Polk" , "ECRIT" X-OriginalArrivalTime: 12 Sep 2005 18:19:20.0528 (UTC) FILETIME=[7E98D500:01C5B7C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Below, Patti -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, September 12, 2005 9:37 AM To: 'James M. Polk'; 'Winterbottom, James'; 'Ted Hardie'; 'ECRIT' Subject: RE: [Ecrit] Emergency [mapping still needed?] I think that the idea that a phone gets its own location, recognizes emergency calls itself, and does its own mapping is a Really Good Idea. It means fewer things have to work to get an emergency call through. PLM - Now you have all the security issues with passing location through the network. You also have the issues around how to ensure the location is valid and hasn't been altered. For a very long time there will be phones out there that aren't capable of storing their own location, yet alone doing the mapping and addressing security. The hardest part to any requirements is to support the existing infrastructure along with what is coming out. I agree that if we all could just toss in all the old technology and could start out with a brand new slate that what Brian states is correct. HOWEVER.....that's not the real world. Location by reference seems a better path - IMO and HELD looks like it is attempting to address the new and old world. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James M. Polk Sent: Sunday, September 11, 2005 6:50 PM To: Winterbottom, James; Ted Hardie; ECRIT Subject: RE: [Ecrit] Emergency [mapping still needed?] At 06:36 PM 9/8/2005 -0500, Winterbottom, James wrote: >All this aside, I think that there are economies of scale, and >functionality reasons why including a gateway such an ESRP are >desirable, but these are more implementation details. Somewhere, >something has to have sufficient knowledge to use location to route the >signal to the next hop. Not necessarily. If the UA has the URI of the PSAP, no further mapping operation is=20 necessary, and you're done, point-to-point. How the UA got the URI *could* be from Layer 2/3 (DHCP) or a protocol at Layer 7, but prior to the emergency call. Either way, the mapping operation=20 could already be done when the call is started. >Cheers >James 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 Sep 12 15:33:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEu3w-0001Pt-0i; Mon, 12 Sep 2005 15:33:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEu3M-0001Jj-1L for ecrit@megatron.ietf.org; Mon, 12 Sep 2005 15:33:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10583 for ; Mon, 12 Sep 2005 15:33:10 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEu7T-0006ae-Rt for ecrit@ietf.org; Mon, 12 Sep 2005 15:37:36 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 Sep 2005 12:33:03 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,102,1125903600"; d="scan'208"; a="9380642:sNHT23568134" Received: from [68.50.138.194] (che-vpn-cluster-1-121.cisco.com [10.86.240.121]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8CJX0Ql025892; Mon, 12 Sep 2005 15:33:00 -0400 (EDT) In-Reply-To: <422D410BD61FC04185076AD99AA7207A010EE800@inilmx01.lgmt.trdo> References: <422D410BD61FC04185076AD99AA7207A010EE800@inilmx01.lgmt.trdo> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <44a162de35612e16403a4e6352778287@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit] Emergency [mapping still needed?] Date: Mon, 12 Sep 2005 15:32:59 -0400 To: "McCalmont, Patti" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Let's take these arguments one at a time: 1) "security issues with passing location through the network" At some point, the location information has to get from the user's access network to the emergency provider. If the user's phone includes its location in the call setup, it has exactly the same "security issues" as the emergency call - no more. 2) "ensure the location is valid and hasn't been altered" When examining the threat of altered location information, one has to consider which actors have what motivations. It seems to me that the actor least interested in altering location information is the user who is seeking emergency service. Consider what the emergency responder would do if the caller is recorded saying he/she is at a location other than where the system reports - would they not respond to that location? I don't think so; the legal liability is too great. The point that someone not seeking emergency service might make a fraudulent call is true today and not solvable in the general case by anything in the call process. It would be nice if the location-indicating function of VoIP could eliminate the existing nuisance of bogus emergency calls, but nice is not the same as necessary. 3) "For a very long time there will be phones out there that aren't capable of storing their own location" My experience with the rapid rate at which cell phones are voluntarily replaced by their owners suggests that this might be a mistaken forecast. I will keep my fallback wireline phone around, but it has the existing location mechanism. What fraction of the expected eventual deployment of IP phones do you think is now deployed? Wouldn't it be easier to provide some work-around for those legacy location-challenged phones than to make the entire system brittle because it is unnecessarily complex? What fraction of the now-deployed IP phones include the process of obtaining a HELD-type reference and including that in their emergency call setup? My alternative forecast is that widespread adoption of GPS and Galileo technology will make it likely that phones and other devices will have their own locations. The economics of large-scale microelectronics suggest that it will not take very long before the cost of including location capability will be such a small fraction of the price of the phone that it will be included as routinely as personal computers now include ethernet interfaces. http://www.useu.be/Galileo/ John On Sep 12, 2005, at 2:19 PM, McCalmont, Patti wrote: > > -----Original Message----- > From: ecrit-bounces@ietf.org On Behalf Of Brian Rosen > Sent: Monday, September 12, 2005 9:37 AM > >> I think that the idea that a phone gets its own location, recognizes >> emergency calls itself, and does its own mapping is a Really Good >> Idea. >> It means fewer things have to work to get an emergency call through. > > PLM - Now you have all the security issues with passing location > through > the network. You also have the issues around how to ensure the location > is valid and hasn't been altered. For a very long time there will be > phones out there that aren't capable of storing their own location, yet > alone doing the mapping and addressing security. The hardest part to > any > requirements is to support the existing infrastructure along with what > is coming out. I agree that if we all could just toss in all the old > technology and could start out with a brand new slate that what Brian > states is correct. HOWEVER.....that's not the real world. Location by > reference seems a better path - IMO and HELD looks like it is > attempting > to address the new and old world. > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 12 17:44:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEw67-0006PZ-8R; Mon, 12 Sep 2005 17:44:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEvop-0006SR-EL for ecrit@megatron.ietf.org; Mon, 12 Sep 2005 17:26:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00750 for ; Mon, 12 Sep 2005 17:26:07 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEvsm-0006H3-71 for ecrit@ietf.org; Mon, 12 Sep 2005 17:30:34 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Sep 2005 16:25:55 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 12 Sep 2005 16:25:54 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Sep 2005 16:25:54 -0500 Message-ID: From: "Winterbottom, James" To: "John Schnizlein" , "Stastny Richard" Date: Mon, 12 Sep 2005 16:25:51 -0500 Subject: RE: [Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConsiderations MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 12 Sep 2005 21:25:54.0273 (UTC) FILETIME=[8E96C510:01C5B7E0] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConsiderations Thread-Index: AcW3ud8nTyVku/bZSl2ey3PEp/CepgAJcbYQ X-Spam-Score: 0.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org John This is simply not true! The view was always that you got a location or a locationURI prior to tunnel establishment, if you have a location aware client. So I simply don't see your argument here. The split tunneling issue has nothing whatsoever to do with HELD, it is imply a statement that local traffic should be kept, where possible, local.=20 There are several other concerns I have with your arguments to Martin's response, and we will get to those later today. Cheers James >=20 > The problem with VPNs is for designs such as HELD that assume the IP > address of the host enables determination of the location. When it was > pointed out that the host's IP address is assigned by the enterprise > end of the VPN tunnel, which is potentially very far from the > tele-worker, a proposal was made that the host use its original (not > tunnel) address when attempting an emergency call. It is the implied > need for split-tunnel that exposes the original IP source address that > leads to the security problem: host both inside and outside the > enterprise security perimeter. >=20 > John >=20 > On Sep 12, 2005, at 11:13 AM, Stastny Richard wrote: >=20 > > Maybe I do not understand the problem with VPNs fully, > > but IMHO if you use a VPN you must first attach to the local > > network to get the local IP connection to set up the VPN. > > Doing so you get an IP address via DHCP and you also may > > get the location. Now you have the location stored somewhere > > on the device. > > > > If you now set up the VPN, you get a new IP address from home > > network, but you still have the location stored and can retrieve it. > > > > There is only one requirement left for the home network: you need > > an access to the mapping database and you also need to be able to > > set up a SIP connection to the PSAP, even if the home networks > > does not allow general access to the Internet. > > > > I do not see a security problem here. > > > > Richard > > ________________________________ > > > > Von: ecrit-bounces@ietf.org im Auftrag von John Rosenberg > > > > Have to agree with John here. As one data point, our own corporate VPN > > does > > not allow split tunneling, and our IT folks are *very* clear that even > > connecting a PC that's on the VPN to another network (e.g. the public > > internet) is prohibited. I would think that this is the rule rather > > than > > the exception. >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 12 23:36:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF1aX-0002uC-2O; Mon, 12 Sep 2005 23:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EExTv-0002b8-JD for ecrit@megatron.ietf.org; Mon, 12 Sep 2005 19:12:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07925 for ; Mon, 12 Sep 2005 19:12:48 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EExY4-0000pY-7u for ecrit@ietf.org; Mon, 12 Sep 2005 19:17:17 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 12 Sep 2005 16:12:42 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8CNCPKK020517 for ; Mon, 12 Sep 2005 16:12:34 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Sep 2005 16:12:23 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.122.166]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Sep 2005 16:12:22 -0700 Message-Id: <4.3.2.7.2.20050912172801.03247040@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Sep 2005 18:12:05 -0500 To: "'ecrit@ietf.org'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 12 Sep 2005 23:12:23.0143 (UTC) FILETIME=[6EA6F770:01C5B7EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Ecrit] New ID for downloading URIs via DHCP 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 ECRIT WG To let folks know One reference that is in the new Emergency Architecture Considerations ID regarding URIs being able to be downloaded (or requested for, then downloaded) to a DHC client is in the following ID just announced (which was delayed in its announcement for some reason I am not aware of): http://www.ietf.org/internet-drafts/draft-polk-dhc-uri-00.txt with this abstract This document defines a new Dynamic Host Configuration Protocol (DHC) Option to allow one or more URIs to be transmitted from a server to a client within one or more messages, and for one or more URIs, each with a unique purpose, to be specifically requested by a client of a server. Included in this Option is a purpose field to identify the type of URI being requested by the client, or the type of URI in the DHCP message from the server. There are 11 URIs currectly defined in this ID: Purpose = 1 (Primary PSAP URI) Purpose = 2 (Secondary PSAP URI) Purpose = 3 (Location By-Reference of Client) Purpose = 4 (ESGW URI of Client) Purpose = 5 (ESRP URI of Client) Purpose = 6 (Organization Providing Location for Client) Purpose = 7 (URI of Geocoding/Reverse Geocoding) Purpose = 8 (Primary URI of Geo Mapping Service) Purpose = 9 (Secondary URI of Geo Mapping Service) Purpose = 10 (Primary URI of Civic Mapping Service) Purpose = 11 (Secondary URI of Civic Mapping Service) Others can be added based on consensus discussion of this document I just spoke with the DHC Chair, and open discussion of this ID on the ECRIT list is fine with him. The formal syntax and encoding of the option proposal will be discussed on the DHC list for those interested there, but the general topic doesn't need to be limiting any of us discussing the ID there where they don't care about emergency calling, as ECRIT is the primary WG of interest for this effort initially. Review and comments are appreciated 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 Tue Sep 13 04:15:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF5wF-0006TQ-SX; Tue, 13 Sep 2005 04:14:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEyXA-00005T-EH for ecrit@megatron.ietf.org; Mon, 12 Sep 2005 20:20:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09937 for ; Mon, 12 Sep 2005 20:20:15 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEybK-00027H-Ns for ecrit@ietf.org; Mon, 12 Sep 2005 20:24:43 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Sep 2005 19:20:07 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 12 Sep 2005 19:20:06 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Sep 2005 19:20:05 -0500 Message-ID: From: "Winterbottom, James" To: "John Schnizlein" , "McCalmont, Patti" Date: Mon, 12 Sep 2005 19:20:04 -0500 Subject: RE: [Ecrit] Emergency [mapping still needed?] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 13 Sep 2005 00:20:05.0845 (UTC) FILETIME=[E4361850:01C5B7F8] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Emergency [mapping still needed?] Thread-Index: AcW30S5YJUrTkszzQrmcJNLmGFs+JAAHMvcg X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Comments inline. >=20 > 1) "security issues with passing location through the network" > At some point, the location information has to get from the user's > access network to the emergency provider. If the user's phone includes > its location in the call setup, it has exactly the same "security > issues" as the emergency call - no more. >=20 > 2) "ensure the location is valid and hasn't been altered" > When examining the threat of altered location information, one has to > consider which actors have what motivations. It seems to me that the > actor least interested in altering location information is the user who > is seeking emergency service. Consider what the emergency responder > would do if the caller is recorded saying he/she is at a location other > than where the system reports - would they not respond to that > location? I don't think so; the legal liability is too great. [[AJW] If the intent of the caller is that of an emergency this is probably true, it is the as ease at which someone other than a genuine caller can make this occur that frightens me. This is a real problem and needs collaboration to make it work. >=20 > The point that someone not seeking emergency service might make a > fraudulent call is true today and not solvable in the general case by > anything in the call process. It would be nice if the > location-indicating function of VoIP could eliminate the existing > nuisance of bogus emergency calls, but nice is not the same as > necessary. [AJW] This is a very narrow view of the problem, which I hope that you don't really believe that. The phone network today requires a presence within the PSAP collective boundary for this to occur. Further more it requires in most cases, one line per call. This is quite simply not the case with VoIP. I can originate quite a number of VoIP calls remotely from the same broadband connection each with a different location making the problem tantamount to intractable. This is a problem that requires solving, it is not good enough to say it can't be done so let's not bother! >=20 > 3) "For a very long time there will be phones out there that aren't > capable of storing their own location" > My experience with the rapid rate at which cell phones are voluntarily > replaced by their owners suggests that this might be a mistaken > forecast. I will keep my fallback wireline phone around, but it has > the existing location mechanism. What fraction of the expected > eventual deployment of IP phones do you think is now deployed? > Wouldn't it be easier to provide some work-around for those legacy > location-challenged phones than to make the entire system brittle > because it is unnecessarily complex? >=20 > What fraction of the now-deployed IP phones include the process of > obtaining a HELD-type reference and including that in their emergency > call setup? >=20 > My alternative forecast is that widespread adoption of GPS and Galileo > technology will make it likely that phones and other devices will have > their own locations. The economics of large-scale microelectronics > suggest that it will not take very long before the cost of including > location capability will be such a small fraction of the price of the > phone that it will be included as routinely as personal computers now > include ethernet interfaces. http://www.useu.be/Galileo/ >=20 > John >=20 > On Sep 12, 2005, at 2:19 PM, McCalmont, Patti wrote: > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org On Behalf Of Brian Rosen > > Sent: Monday, September 12, 2005 9:37 AM > > > >> I think that the idea that a phone gets its own location, recognizes > >> emergency calls itself, and does its own mapping is a Really Good > >> Idea. > >> It means fewer things have to work to get an emergency call through. > > > > PLM - Now you have all the security issues with passing location > > through > > the network. You also have the issues around how to ensure the location > > is valid and hasn't been altered. For a very long time there will be > > phones out there that aren't capable of storing their own location, yet > > alone doing the mapping and addressing security. The hardest part to > > any > > requirements is to support the existing infrastructure along with what > > is coming out. I agree that if we all could just toss in all the old > > technology and could start out with a brand new slate that what Brian > > states is correct. HOWEVER.....that's not the real world. Location by > > reference seems a better path - IMO and HELD looks like it is > > attempting > > to address the new and old world. > > > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 13 12:35:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFDka-0002fu-SB; Tue, 13 Sep 2005 12:35:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF1XE-0002Ni-9O for ecrit@megatron.ietf.org; Mon, 12 Sep 2005 23:32:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16920 for ; Mon, 12 Sep 2005 23:32:30 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EF1bN-0006Bd-8M for ecrit@ietf.org; Mon, 12 Sep 2005 23:37:00 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 12 Sep 2005 20:32:20 -0700 X-IronPort-AV: i="3.97,104,1125903600"; d="scan'208"; a="341066230:sNHT29426472" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8D3WIKC018359 for ; Mon, 12 Sep 2005 20:32:18 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Sep 2005 20:32:06 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.96.139]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Sep 2005 20:32:05 -0700 Message-Id: <4.3.2.7.2.20050912223202.03218808@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Sep 2005 22:32:04 -0500 To: "'ecrit@ietf.org'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 13 Sep 2005 03:32:05.0884 (UTC) FILETIME=[B6B08BC0:01C5B813] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Ecrit] New ID for downloading URIs via DHCP 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 ECRIT WG To let folks know One reference that is in the new Emergency Architecture Considerations ID regarding URIs being able to be downloaded (or requested for, then downloaded) to a DHC client is in the following ID just announced (which was delayed in its announcement for some reason I am not aware of): http://www.ietf.org/internet-drafts/draft-polk-dhc-uri-00.txt with this abstract This document defines a new Dynamic Host Configuration Protocol (DHC) Option to allow one or more URIs to be transmitted from a server to a client within one or more messages, and for one or more URIs, each with a unique purpose, to be specifically requested by a client of a server. Included in this Option is a purpose field to identify the type of URI being requested by the client, or the type of URI in the DHCP message from the server. There are 11 URIs currectly defined in this ID: Purpose = 1 (Primary PSAP URI) Purpose = 2 (Secondary PSAP URI) Purpose = 3 (Location By-Reference of Client) Purpose = 4 (ESGW URI of Client) Purpose = 5 (ESRP URI of Client) Purpose = 6 (Organization Providing Location for Client) Purpose = 7 (URI of Geocoding/Reverse Geocoding) Purpose = 8 (Primary URI of Geo Mapping Service) Purpose = 9 (Secondary URI of Geo Mapping Service) Purpose = 10 (Primary URI of Civic Mapping Service) Purpose = 11 (Secondary URI of Civic Mapping Service) Others can be added based on consensus discussion of this document I just spoke with the DHC Chair, and open discussion of this ID on the ECRIT list is fine with him. The formal syntax and encoding of the option proposal will be discussed on the DHC list for those interested there, but the general topic doesn't need to be limiting any of us discussing the ID there where they don't care about emergency calling, as ECRIT is the primary WG of interest for this effort initially. Review and comments are appreciated 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 Tue Sep 13 15:31:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGVY-0004A6-9P; Tue, 13 Sep 2005 15:31:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF8eV-0000GQ-Em for ecrit@megatron.ietf.org; Tue, 13 Sep 2005 07:08:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14566 for ; Tue, 13 Sep 2005 07:08:24 -0400 (EDT) Message-Id: <200509131108.HAA14566@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EF8ih-0007dG-9e for ecrit@ietf.org; Tue, 13 Sep 2005 07:13:00 -0400 Received: from acs-24-154-127-115.zoominternet.net ([24.154.127.115] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EF8e4-0006I7-QS; Tue, 13 Sep 2005 06:08:13 -0500 From: "Brian Rosen" To: "'Rodrig, Benny \(Benny\)'" , "'Winterbottom, James'" , "'ECRIT'" Subject: RE: [Ecrit] Emergency [VPN issue] Date: Tue, 13 Sep 2005 07:07:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW3ImXxJWPwSm4aQ/OygmT03A/KHAAAqMAgAB59zEAAEc9C8A== 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: 3d48d865303330c98a6e90d450cf2ff2 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Benny There are some authentication issues with who is the source of location information, but in general, I believe the enterprise IS the access provider, it simply has an upstream access provider to it. This is not unlike a tier 2 or tier 3 ISP. The point is that if an enterprise is large enough, we need it to supply room-level location, and the access network to it cannot do that. In very large enterprises, the access provider may only be at the headquarters location; remote sites may be served by private networks. In such cases we are wholly reliant on the enterprise to provide accurate location. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Rodrig, Benny (Benny) Sent: Monday, September 12, 2005 9:54 AM To: Winterbottom, James; ECRIT Subject: RE: [Ecrit] Emergency [VPN issue] James, I don't see how the enterprise, even with a VPN policy, can be considered an access provider. The concept of the access provider, as opposed to the application service provider, implies some sort of locality and hence knowledge of user's location. These do not shift from the local Internet access provider to the remote enterprise headquarters just because the endpoint is connecting through a VPN. Benny -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Sunday, September 11, 2005 7:13 PM To: James M. Polk; ECRIT Subject: RE: [Ecrit] Emergency [VPN issue] Hi James, Actually that is not really the point that I am making. The point I was making was that if the enterprise forces its remote staff to pass all traffic through the VPN, including emergency calls, then the enterprise is, for all intents and purposes the access provider, and is responsible to ensure that the call will get to where it needs to go. On the technology front I don't see why a solution shouldn't be universal either. Change to soft-phones in firmware or software are going to be required to get location, and if I understand the proposed solutions correctly then, determine that the call is an emergency one and provide location also. So I don't see that providing split tunneling to cater for this is such a big deal. If enterprises elect not to deploy or engage this functionality then the point of responsibility is clear. Cheers James > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Monday, 12 September 2005 8:44 AM > To: Winterbottom, James; Michael Hammer (mhammer); Stastny Richard; Marc > Linsner (mlinsner); ECRIT > Subject: RE: [Ecrit] Emergency [VPN issue] > > James > > I don't understand the point you're making here. > > Are you suggesting NENA believes a VPNd phone should not communicate over > the VPN when calling ? > > I don't believe this will be universally available > > At 06:29 PM 9/8/2005 -0500, Winterbottom, James wrote: > >This issue has been discussed in NENA at quite some length. The > >consensus that is growing there, and I know that there are some people > >that still disagree, is that if an enterprise is prepared to allow this > >to occur, that the onus is on the enterprise to ensure that it works. > >This makes the problem a little easier to deal with. > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >Of > > > Rodrig, Benny (Benny) > > > Sent: Friday, 9 September 2005 9:14 AM > > > To: Michael Hammer (mhammer); Stastny Richard; Marc Linsner > >(mlinsner); > > > ECRIT > > > Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies- > > > ArchitectureConsiderations > > > > > > Not sure it's always possible for emergency calls to not go though the > > > corporate VPN. For example, the endpoint may have no means (e.g. no > >TURN > > > server) to establish a session directly through the NAT at the > >Backwater > > > Inn, in the example below. > > > > > > Benny > > > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Michael Hammer (mhammer) > > > Sent: Thursday, September 08, 2005 6:26 PM > > > To: Stastny Richard; Marc Linsner (mlinsner); ECRIT > > > Subject: RE: [Ecrit] > > > EmergencyContextRoutingofInternetTechnologies-Architecture > > > Considerations > > > > > > Richard, > > > > > > My original question was about whether a PSAP should expect calls > > > (signaling and media) to originate from non-local destinations, e.g. > > > international, and by inference the need for the PSAPs to be able to > > > make call backs to those locations. If not, then perhaps it is a DDoS > > > clue. > > > > > > Marc pointed out the VPN possibility. > > > > > > You seem to suggest that emergency calls should never go by VPN when > > > dialed. > > > > > > So, is the VPN situation a possibility or precluded? > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, September 08, 2005 5:58 PM > > > > To: Michael Hammer (mhammer); Marc Linsner (mlinsner); ECRIT > > > > Subject: Re: [Ecrit] Emergency > > > > ContextRoutingofInternetTechnologies-Architecture Considerations > > > > > > > > Sorry, but I am confused with this examples: > > > > > > > > Somebody sitting say in Chicago should get routed to a local PSAP in > > > > Chicago, regardless where his provider or sip-server is located > > > > > > > > If he is using a VPN to say a network in Berlin, he may either also > > > > get routed by some magic we still have to work out also to a PSAP in > > > > Chicago, or he is routed wrongly to a PSAP in Berlin. > > > > > > > > But, the PSAP in Berlin will at least get some location and also > >some > > > > identification from Berlin, at the network, so there is some local > > > > relationship > > > > > > > > So what is the point? > > > > > > > > -richard > > > > > > > > ________________________________ > > > > > > > > Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) > > > > Gesendet: Do 08.09.2005 22:56 > > > > An: Marc Linsner (mlinsner); ECRIT > > > > Betreff: RE: [Ecrit] Emergency > > > > ContextRoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > > > > > That is certainly possible. I'm trying to get an idea of the > >assumed > > > > topology models here. If the call gets dropped, does the PSAP make > >an > > > > > > > "international call" to call back such subscribers? Could the call > > > > back number be a number in some Caribbean island that happens to be > >a > > > > 9xx equivalent? Could Berlin Ind. send a 3xx response and say drop > > > > out of this VPN to make the call? > > > > > > > > In any case, your example proves the exception, so likely mine was a > > > > dead end thought. > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Marc Linsner (mlinsner) > > > > > Sent: Thursday, September 08, 2005 4:18 PM > > > > > To: Michael Hammer (mhammer); 'ECRIT' > > > > > Subject: RE: [Ecrit] Emergency Context > > > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > How about an employee of Berlin Industries, Inc. sitting at the > > > > > Backwater Inn with a full vpn up to their corp. hq and calling for > > > > > help. Wouldn't they look like they were coming from Berlin > > > > (the .ru > > > > > domain and IP address would probably be a hint)? Do you > > > > want to block > > > > > them? > > > > > > > > > > I certainly think that it is reasonable to raise a flag to the > > > > > calltaker in this situation, but I wouldn't think you want > > > > to build a > > > > > state machine to simply block such calls. > > > > > > > > > > Replace Berlin with New Hampshire, New York, Mass........ > > > > > > > > > > -Marc- > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > Of Michael Hammer (mhammer) > > > > > > Sent: Thursday, September 08, 2005 3:12 PM > > > > > > To: Ted Hardie; wilcox@e911.psd.state.vt.us; > > > > > br@brianrosen.net; Andrew > > > > > > Newton; Stastny Richard; ECRIT > > > > > > Subject: RE: [Ecrit] Emergency Context > > > > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > Ted, > > > > > > > > > > > > I'm confused. Are calls from Asia or Europe to the Vermont > > > > > PSAP ever > > > > > > legitimate? > > > > > > > > > > > > Somehow, I can't picture the local sheriff being able to > > > > > help someone > > > > > > in Berlin. I thought the point of i3 is to enable the call > > > > > to go to > > > > > > the local Berlin Polizei. Put another way, is it possible > > > > > to use the > > > > > > local nature of emergency service to protect agains DDoS? > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ecrit-bounces@ietf.org > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > Of Ted Hardie > > > > > > > Sent: Thursday, September 08, 2005 1:55 PM > > > > > > > To: wilcox@e911.psd.state.vt.us; br@brianrosen.net; > > > > > Andrew Newton; > > > > > > > Stastny Richard; ECRIT > > > > > > > Subject: RE: [Ecrit] Emergency Context Routing > > > > > > > ofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > > > After reading the thread, I wanted to come back to Nate's > > > > > original > > > > > > > concern and call something out: > > > > > > > > > > > > > > >Here is the PSAP concern: > > > > > > > > > > > > > > > >An enterprising thief could figure out that a business > > > > > (without an > > > > > > > >alarm > > > > > > > >system) in Backwater, Vermont is served by a PSAP located 25 > > > > > > > miles away. > > > > > > > >If one creates an IP-based denial of service attack on that > > > > > > > PSAP then > > > > > > > >it is safe to assume that the target of opportunity that the > > > > > > > thief is > > > > > > > >looking at in Backwater will not be able to contact the PSAP > > > > > > > to summon > > > > > > > >help. > > > > > > > > > > > > > > I'm assuming that the PSAP being 25 miles away means > > > > > nothing about > > > > > > > where the responders are. The responders in this > > > > > instance might be > > > > > > > sheriffs, for example, who are stationed nearby, even > > > > > > further than 25 > > > > > > > miles away, or whose patrol routes mean that their distance > > > > > > from the > > > > > > > target of opportunity is variable. So I think we > > > > should cut the > > > > > > > distance from this description completely, and simply see > > > > > > the threat > > > > > > > as "If the bad actor can determine which PSAP serves an > > > > > > area in which > > > > > > > a target is present, a successful attack on the PSAP prevents > > > > > > > responses to the target". > > > > > > > > > > > > > > Does that make sense? > > > > > > > > > > > > > > > > > > > > > > Using PSTN technologies, an enterprising thief could create > > > > > > > a PSTN DoS > > > > > > > >on the PSAP by simply using an auto call generator from a > > > > > > pay phone > > > > > > > >located in the same proximity as the target of opportunity > > > > > > however, > > > > > > > >this would still create a response to the general area of > > > > > > the crime. > > > > > > > > > > > > > > There are lots of other kinds of PSTN attacks here--the > > > > > > most commonly > > > > > > > portrayed being "cutting the line", which doesn't work > > > > > quite as it > > > > > > > seems in the movies, but does have some effect. > > > > > > > > > > > > > > To avoid the locality problem in this attack, the bad actor > > > > > > can use an > > > > > > > accomplice, meat or mechanical, in any other area served by > > > > > > the PSAP > > > > > > > to do the same thing. This avoids the response hitting > > > > > the general > > > > > > > area of the crime. It also has the same counter-measure; > > > > > > > call-blocking of the attacking phone. This counter-measure > > > > > > is also > > > > > > > relatively easy to accomplish with an IP-based service, > > > > > > provided the > > > > > > > attack is coming from a single IP or block. I believe the > > > > > > problem is > > > > > > > harder in the IP case not because the area from which the > > > > > > attack can > > > > > > > originate is larger but because it is easier to create a > > > > > > Distributed > > > > > > > Denial of Service, largely because of zombie networks and > > > > > > IP spoofing. > > > > > > > That is, if the attack is coming from Europe while the > > > > attack is > > > > > > > happening on Backwater, my response is the same as if it > > > > > came from > > > > > > > Nearwater, VT: > > > > > > > block the attack source. But if it is coming from > > > > Europe, Asia, > > > > > > > Nearwater, Backwater, and many other points as well, > > > > > > attempts to block > > > > > > > the attack either requires effectively severing connectivity > >or > > > > > > > maintaining a fair amount of information about who at the > > > > > IP layer > > > > > > > should be talking to this PSAP. We've discussed the > > > > > > effectiveness of > > > > > > > that in the past. > > > > > > > > > > > > > > >If I > > > > > > > >know the URI of the PSAP, I can now distract it from another > > > > > > > continent > > > > > > > >and do what I would need to do in Backwater and no > > > > > > response would be > > > > > > > >created in that direction - that is the new paradigm with > > > > > > > IP. If I know > > > > > > > >the boundaries of the Derby PSAP, I could create a PSTN > > > > > based DoS > > > > > > > >attack anywhere from within that boundary (potentially 50 > > > > > > miles from > > > > > > > >Island Pond). > > > > > > > > > > > > > > > >Would this happen? I don't know - I am pretty sure it > > > > > > hasn't yet but > > > > > > > >assigning a URI to a PSAP opens it up to whole new > > > > generation of > > > > > > > >"creative thinkers"..... > > > > > > > > > > > > > > > >Of course we can minimize the impact on the PSAP at a > > > > > higher level > > > > > > > >gateway by throwing a huge amount of bandwidth at it and > > > > > > building in > > > > > > > >intelligent alternative routing on a robust firewall. But > > > > > > > that does not > > > > > > > >help in the interim between here and there when someone > > > > > gets their > > > > > > > >hands on the PSAP boundaries and realizes the attacks they > > > > > > > can initiate > > > > > > > >using the PSTN DoS approach. > > > > > > > > > > > > > > The problem with the proposed solution, I believe, is that > > > > > > aggregating > > > > > > > the access to a back-to-back user agent or all-knowing > > > > > > gateway is that > > > > > > > you have simply created a richer target for attack. If I > > > > > > can marshal > > > > > > > a zombie group that takes out all of Vermont's PSAPs by > > > > > eliminating > > > > > > > the the gateway by DDoS, I have done far worse far more > > > > > > easily than I > > > > > > > could by individually attacking the PSAPs at their URIs. > > > > > > If I did it > > > > > > > in order to get at Backwater's target, I likely don't > > > > > care that the > > > > > > > general effect is larger--my purpose is met. > > > > > > > > > > > > > > Yes, it is easier to escalate the defenses at a single > > > > > > point and yes, > > > > > > > it is easier to pay for fat pipes for that single point. > > > > > > But the bad > > > > > > > actors here aren't using their own resources to attack you; > > > > > > they are > > > > > > > stealing them before trying to steal from you. Getting > > > > > > into an arms > > > > > > > race with someone who isn't spending their own money worries > >me. > > > > > > > > > > > > > > regards, > > > > > > > Ted > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 > > > >----------------------------------------------------------------------- -- > ----------------------- > >This message is for the designated recipient only and may contain > >privileged, proprietary, or otherwise private information. > >If you have received it in error, please notify the sender > >immediately and delete the original. Any unauthorized use of this > >email is prohibited. > >----------------------------------------------------------------------- -- > ----------------------- > >[mf2] > > > >_______________________________________________ > >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. ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 13 15:31:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGVY-0004AV-HK; Tue, 13 Sep 2005 15:31:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF8eV-0000GP-DI for ecrit@megatron.ietf.org; Tue, 13 Sep 2005 07:08:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14564 for ; Tue, 13 Sep 2005 07:08:23 -0400 (EDT) Message-Id: <200509131108.HAA14564@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EF8ih-0007d7-7L for ecrit@ietf.org; Tue, 13 Sep 2005 07:12:59 -0400 Received: from acs-24-154-127-115.zoominternet.net ([24.154.127.115] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EF8e1-0006I7-6t; Tue, 13 Sep 2005 06:08:12 -0500 From: "Brian Rosen" To: "'McCalmont, Patti'" , "'James M. Polk'" , "'ECRIT'" Subject: RE: [Ecrit] Emergency [mapping still needed?] Date: Tue, 13 Sep 2005 07:07:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <422D410BD61FC04185076AD99AA7207A010EE800@inilmx01.lgmt.trdo> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW3I2XTpRQ5iwQ9TQWh91Yg4gZxJAAcPDAgAAhgD6AADGufcA== 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: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org You have security issues no matter what; this doesn't change them in any significant way. The endpoint is providing some kind of data, be it an actual location or something that can be exchanged for a location, and there is a variety of attacks on all forms of this kind of data. The location used for mapping can be signed by the access network, as has been discussed, and it can have a time stamp, which helps a little in replay attacks. The PSAP can verify that the location matches the mapping. There are no new issues. I am also in agreement with John that while we DO wish to put up reasonable defenses against location forgery, they are unlikely to be foolproof, we have the problem today in various forms, and making the system work reliably in disasters is more important than preventing location forgery. Simple systems ALWAYS work better than complex systems, and it's often the case that if you make the security systems too complex, they reduce the overall reliability of the system. I am reminded of several times where PSAP folks have insisted that we MUST have validated location and we MUST have authorization and we MUST to this, and we MUST do that, and I ask them what happens if they get a call without any of that. The answer is that they take the call, and go ask the questions of what failed later. I take from that that we should provide robust security mechanisms, but that if they fail, we send the calls anyway. Brian -----Original Message----- From: McCalmont, Patti [mailto:Patti.McCalmont@intrado.com] Sent: Monday, September 12, 2005 2:19 PM To: br@brianrosen.net; James M. Polk; ECRIT Subject: RE: [Ecrit] Emergency [mapping still needed?] Below, Patti -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, September 12, 2005 9:37 AM To: 'James M. Polk'; 'Winterbottom, James'; 'Ted Hardie'; 'ECRIT' Subject: RE: [Ecrit] Emergency [mapping still needed?] I think that the idea that a phone gets its own location, recognizes emergency calls itself, and does its own mapping is a Really Good Idea. It means fewer things have to work to get an emergency call through. PLM - Now you have all the security issues with passing location through the network. You also have the issues around how to ensure the location is valid and hasn't been altered. For a very long time there will be phones out there that aren't capable of storing their own location, yet alone doing the mapping and addressing security. The hardest part to any requirements is to support the existing infrastructure along with what is coming out. I agree that if we all could just toss in all the old technology and could start out with a brand new slate that what Brian states is correct. HOWEVER.....that's not the real world. Location by reference seems a better path - IMO and HELD looks like it is attempting to address the new and old world. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James M. Polk Sent: Sunday, September 11, 2005 6:50 PM To: Winterbottom, James; Ted Hardie; ECRIT Subject: RE: [Ecrit] Emergency [mapping still needed?] At 06:36 PM 9/8/2005 -0500, Winterbottom, James wrote: >All this aside, I think that there are economies of scale, and >functionality reasons why including a gateway such an ESRP are >desirable, but these are more implementation details. Somewhere, >something has to have sufficient knowledge to use location to route the >signal to the next hop. Not necessarily. If the UA has the URI of the PSAP, no further mapping operation is necessary, and you're done, point-to-point. How the UA got the URI *could* be from Layer 2/3 (DHCP) or a protocol at Layer 7, but prior to the emergency call. Either way, the mapping operation could already be done when the call is started. >Cheers >James 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 Tue Sep 13 15:32:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGW8-0004UR-1Z; Tue, 13 Sep 2005 15:32:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFAdT-00038P-A3 for ecrit@megatron.ietf.org; Tue, 13 Sep 2005 09:15:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20867 for ; Tue, 13 Sep 2005 09:15:39 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFAhp-0002Da-VS for ecrit@ietf.org; Tue, 13 Sep 2005 09:20:15 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j8DDEpBs011482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Sep 2005 09:14:51 -0400 (EDT) Message-ID: <4326D0E1.6030100@cs.columbia.edu> Date: Tue, 13 Sep 2005 09:15:13 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] New ID for downloading URIs via DHCP References: <4.3.2.7.2.20050912172801.03247040@email.cisco.com> In-Reply-To: <4.3.2.7.2.20050912172801.03247040@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Maybe it would be helpful to discuss how this work intersects with the (SIP) configuration work in SIPPING. I believe almost all of this information can (and probably should) be part of the configuration package, rather than DHCP. In particular, the SIP configuration package has three major advantages: - a much better security model (mutual authentication, encryption, etc.) - automatic notification of changes - the ability to use the same mechanism to retrieve this information for the local network and the service provider Henning James M. Polk wrote: > ECRIT WG > > To let folks know > > One reference that is in the new Emergency Architecture Considerations > ID regarding URIs being able to be downloaded (or requested for, then > downloaded) to a DHC client is in the following ID just announced (which > was delayed in its announcement for some reason I am not aware of): > > http://www.ietf.org/internet-drafts/draft-polk-dhc-uri-00.txt > > with this abstract > > This document defines a new Dynamic Host Configuration Protocol > (DHC) Option to allow one or more URIs to be transmitted from a > server to a client within one or more messages, and for one or more > URIs, each with a unique purpose, to be specifically requested by a > client of a server. Included in this Option is a purpose field to > identify the type of URI being requested by the client, or the type > of URI in the DHCP message from the server. > > There are 11 URIs currectly defined in this ID: > > Purpose = 1 (Primary PSAP URI) > Purpose = 2 (Secondary PSAP URI) > Purpose = 3 (Location By-Reference of Client) > Purpose = 4 (ESGW URI of Client) > Purpose = 5 (ESRP URI of Client) > Purpose = 6 (Organization Providing Location for Client) > Purpose = 7 (URI of Geocoding/Reverse Geocoding) > Purpose = 8 (Primary URI of Geo Mapping Service) > Purpose = 9 (Secondary URI of Geo Mapping Service) > Purpose = 10 (Primary URI of Civic Mapping Service) > Purpose = 11 (Secondary URI of Civic Mapping Service) > > Others can be added based on consensus discussion of this document > > I just spoke with the DHC Chair, and open discussion of this ID on the > ECRIT list is fine with him. The formal syntax and encoding of the > option proposal will be discussed on the DHC list for those interested > there, but the general topic doesn't need to be limiting any of us > discussing the ID there where they don't care about emergency calling, > as ECRIT is the primary WG of interest for this effort initially. > > Review and comments are appreciated > > 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 Tue Sep 13 15:32:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGWH-0004dj-Ts; Tue, 13 Sep 2005 15:32:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFBNl-0002LP-Pq for ecrit@megatron.ietf.org; Tue, 13 Sep 2005 10:03:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22455 for ; Tue, 13 Sep 2005 10:03:13 -0400 (EDT) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFBRq-0003Cf-M8 for ecrit@ietf.org; Tue, 13 Sep 2005 10:07:49 -0400 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 j8DDnoEX018313 for ; Tue, 13 Sep 2005 09:49:51 -0400 (EDT) Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8DDnjEX018172 for ; Tue, 13 Sep 2005 09:49:46 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Ecrit] Emergency [VPN issue] Date: Tue, 13 Sep 2005 10:03:00 -0400 Message-ID: Thread-Topic: [Ecrit] Emergency [VPN issue] Thread-Index: AcW3ImXxJWPwSm4aQ/OygmT03A/KHAAAqMAgAB59zEAAEc9C8AAgqJCA From: "Rodrig, Benny \(Benny\)" To: , "Winterbottom, James" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6f51ba5266426a53fc06c7d32a3c18b6 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, I guess you are referring to the enterprise sites, and I completely agree that for those the enterprise is the access provider and has to provide room-level location. My comment below was regarding the enterprise remote users connecting to the corporate network through a VPN from home or from e.g. some remote hotel. For that case, I was disagreeing with James's argument that the enterprise is the access provider if it requires all traffic to go through the VPN. It does not seem feasible for the enterprise to provide the user's location in this case. Benny -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, September 13, 2005 7:08 AM To: Rodrig, Benny (Benny); 'Winterbottom, James'; 'ECRIT' Subject: RE: [Ecrit] Emergency [VPN issue] Benny There are some authentication issues with who is the source of location information, but in general, I believe the enterprise IS the access provider, it simply has an upstream access provider to it. This is not unlike a tier 2 or tier 3 ISP. The point is that if an enterprise is large enough, we need it to supply room-level location, and the access network to it cannot do that. In very large enterprises, the access provider may only be at the headquarters location; remote sites may be served by private networks. In such cases we are wholly reliant on the enterprise to provide accurate location. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Rodrig, Benny (Benny) Sent: Monday, September 12, 2005 9:54 AM To: Winterbottom, James; ECRIT Subject: RE: [Ecrit] Emergency [VPN issue] James, I don't see how the enterprise, even with a VPN policy, can be considered an access provider. The concept of the access provider, as opposed to the application service provider, implies some sort of locality and hence knowledge of user's location. These do not shift from the local Internet access provider to the remote enterprise headquarters just because the endpoint is connecting through a VPN.=20 Benny -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Sunday, September 11, 2005 7:13 PM To: James M. Polk; ECRIT Subject: RE: [Ecrit] Emergency [VPN issue] Hi James, Actually that is not really the point that I am making. The point I was making was that if the enterprise forces its remote staff to pass all traffic through the VPN, including emergency calls, then the enterprise is, for all intents and purposes the access provider, and is responsible to ensure that the call will get to where it needs to go. On the technology front I don't see why a solution shouldn't be universal either. Change to soft-phones in firmware or software are going to be required to get location, and if I understand the proposed solutions correctly then, determine that the call is an emergency one and provide location also. So I don't see that providing split tunneling to cater for this is such a big deal. If enterprises elect not to deploy or engage this functionality then the point of responsibility is clear. Cheers James > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Monday, 12 September 2005 8:44 AM > To: Winterbottom, James; Michael Hammer (mhammer); Stastny Richard; Marc > Linsner (mlinsner); ECRIT > Subject: RE: [Ecrit] Emergency [VPN issue] >=20 > James >=20 > I don't understand the point you're making here. >=20 > Are you suggesting NENA believes a VPNd phone should not communicate over > the VPN when calling ? >=20 > I don't believe this will be universally available >=20 > At 06:29 PM 9/8/2005 -0500, Winterbottom, James wrote: > >This issue has been discussed in NENA at quite some length. The=20 > >consensus that is growing there, and I know that there are some people > >that still disagree, is that if an enterprise is prepared to allow this > >to occur, that the onus is on the enterprise to ensure that it works. > >This makes the problem a little easier to deal with. > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >Of > > > Rodrig, Benny (Benny) > > > Sent: Friday, 9 September 2005 9:14 AM > > > To: Michael Hammer (mhammer); Stastny Richard; Marc Linsner > >(mlinsner); > > > ECRIT > > > Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies- > > > ArchitectureConsiderations > > > > > > Not sure it's always possible for emergency calls to not go though the > > > corporate VPN. For example, the endpoint may have no means (e.g. no > >TURN > > > server) to establish a session directly through the NAT at the > >Backwater > > > Inn, in the example below. > > > > > > Benny > > > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Michael Hammer (mhammer) > > > Sent: Thursday, September 08, 2005 6:26 PM > > > To: Stastny Richard; Marc Linsner (mlinsner); ECRIT > > > Subject: RE: [Ecrit] > > > EmergencyContextRoutingofInternetTechnologies-Architecture > > > Considerations > > > > > > Richard, > > > > > > My original question was about whether a PSAP should expect calls=20 > > > (signaling and media) to originate from non-local destinations, e.g. > > > international, and by inference the need for the PSAPs to be able to > > > make call backs to those locations. If not, then perhaps it is a DDoS > > > clue. > > > > > > Marc pointed out the VPN possibility. > > > > > > You seem to suggest that emergency calls should never go by VPN when > > > dialed. > > > > > > So, is the VPN situation a possibility or precluded? > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, September 08, 2005 5:58 PM > > > > To: Michael Hammer (mhammer); Marc Linsner (mlinsner); ECRIT > > > > Subject: Re: [Ecrit] Emergency > > > > ContextRoutingofInternetTechnologies-Architecture Considerations > > > > > > > > Sorry, but I am confused with this examples: > > > > > > > > Somebody sitting say in Chicago should get routed to a local PSAP in > > > > Chicago, regardless where his provider or sip-server is located > > > > > > > > If he is using a VPN to say a network in Berlin, he may either also > > > > get routed by some magic we still have to work out also to a PSAP in > > > > Chicago, or he is routed wrongly to a PSAP in Berlin. > > > > > > > > But, the PSAP in Berlin will at least get some location and also > >some > > > > identification from Berlin, at the network, so there is some local > > > > relationship > > > > > > > > So what is the point? > > > > > > > > -richard > > > > > > > > ________________________________ > > > > > > > > Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) > > > > Gesendet: Do 08.09.2005 22:56 > > > > An: Marc Linsner (mlinsner); ECRIT > > > > Betreff: RE: [Ecrit] Emergency > > > > ContextRoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > > > > > That is certainly possible. I'm trying to get an idea of the > >assumed > > > > topology models here. If the call gets dropped, does the PSAP make > >an > > > > > > > "international call" to call back such subscribers? Could the call > > > > back number be a number in some Caribbean island that happens to be > >a > > > > 9xx equivalent? Could Berlin Ind. send a 3xx response and say drop > > > > out of this VPN to make the call? > > > > > > > > In any case, your example proves the exception, so likely mine was a > > > > dead end thought. > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Marc Linsner (mlinsner) > > > > > Sent: Thursday, September 08, 2005 4:18 PM > > > > > To: Michael Hammer (mhammer); 'ECRIT' > > > > > Subject: RE: [Ecrit] Emergency Context=20 > > > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > How about an employee of Berlin Industries, Inc. sitting at the > > > > > Backwater Inn with a full vpn up to their corp. hq and calling for > > > > > help. Wouldn't they look like they were coming from Berlin > > > > (the .ru > > > > > domain and IP address would probably be a hint)? Do you > > > > want to block > > > > > them? > > > > > > > > > > I certainly think that it is reasonable to raise a flag to the > > > > > calltaker in this situation, but I wouldn't think you want > > > > to build a > > > > > state machine to simply block such calls. > > > > > > > > > > Replace Berlin with New Hampshire, New York, Mass........ > > > > > > > > > > -Marc- > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > Of Michael Hammer (mhammer) > > > > > > Sent: Thursday, September 08, 2005 3:12 PM > > > > > > To: Ted Hardie; wilcox@e911.psd.state.vt.us; > > > > > br@brianrosen.net; Andrew > > > > > > Newton; Stastny Richard; ECRIT > > > > > > Subject: RE: [Ecrit] Emergency Context=20 > > > > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > Ted, > > > > > > > > > > > > I'm confused. Are calls from Asia or Europe to the Vermont > > > > > PSAP ever > > > > > > legitimate? > > > > > > > > > > > > Somehow, I can't picture the local sheriff being able to > > > > > help someone > > > > > > in Berlin. I thought the point of i3 is to enable the call > > > > > to go to > > > > > > the local Berlin Polizei. Put another way, is it possible > > > > > to use the > > > > > > local nature of emergency service to protect agains DDoS? > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ecrit-bounces@ietf.org > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > Of Ted Hardie > > > > > > > Sent: Thursday, September 08, 2005 1:55 PM > > > > > > > To: wilcox@e911.psd.state.vt.us; br@brianrosen.net; > > > > > Andrew Newton; > > > > > > > Stastny Richard; ECRIT > > > > > > > Subject: RE: [Ecrit] Emergency Context Routing=20 > > > > > > > ofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > > > After reading the thread, I wanted to come back to Nate's > > > > > original > > > > > > > concern and call something out: > > > > > > > > > > > > > > >Here is the PSAP concern: > > > > > > > > > > > > > > > >An enterprising thief could figure out that a business > > > > > (without an > > > > > > > >alarm > > > > > > > >system) in Backwater, Vermont is served by a PSAP located 25 > > > > > > > miles away. > > > > > > > >If one creates an IP-based denial of service attack on that > > > > > > > PSAP then > > > > > > > >it is safe to assume that the target of opportunity that the > > > > > > > thief is > > > > > > > >looking at in Backwater will not be able to contact the PSAP > > > > > > > to summon > > > > > > > >help. > > > > > > > > > > > > > > I'm assuming that the PSAP being 25 miles away means > > > > > nothing about > > > > > > > where the responders are. The responders in this > > > > > instance might be > > > > > > > sheriffs, for example, who are stationed nearby, even > > > > > > further than 25 > > > > > > > miles away, or whose patrol routes mean that their distance > > > > > > from the > > > > > > > target of opportunity is variable. So I think we > > > > should cut the > > > > > > > distance from this description completely, and simply see > > > > > > the threat > > > > > > > as "If the bad actor can determine which PSAP serves an > > > > > > area in which > > > > > > > a target is present, a successful attack on the PSAP prevents > > > > > > > responses to the target". > > > > > > > > > > > > > > Does that make sense? > > > > > > > > > > > > > > > > > > > > > > Using PSTN technologies, an enterprising thief could create > > > > > > > a PSTN DoS > > > > > > > >on the PSAP by simply using an auto call generator from a > > > > > > pay phone > > > > > > > >located in the same proximity as the target of opportunity > > > > > > however, > > > > > > > >this would still create a response to the general area of > > > > > > the crime. > > > > > > > > > > > > > > There are lots of other kinds of PSTN attacks here--the > > > > > > most commonly > > > > > > > portrayed being "cutting the line", which doesn't work > > > > > quite as it > > > > > > > seems in the movies, but does have some effect. > > > > > > > > > > > > > > To avoid the locality problem in this attack, the bad actor > > > > > > can use an > > > > > > > accomplice, meat or mechanical, in any other area served by > > > > > > the PSAP > > > > > > > to do the same thing. This avoids the response hitting > > > > > the general > > > > > > > area of the crime. It also has the same counter-measure;=20 > > > > > > > call-blocking of the attacking phone. This counter-measure > > > > > > is also > > > > > > > relatively easy to accomplish with an IP-based service, > > > > > > provided the > > > > > > > attack is coming from a single IP or block. I believe the > > > > > > problem is > > > > > > > harder in the IP case not because the area from which the > > > > > > attack can > > > > > > > originate is larger but because it is easier to create a > > > > > > Distributed > > > > > > > Denial of Service, largely because of zombie networks and > > > > > > IP spoofing. > > > > > > > That is, if the attack is coming from Europe while the > > > > attack is > > > > > > > happening on Backwater, my response is the same as if it > > > > > came from > > > > > > > Nearwater, VT: > > > > > > > block the attack source. But if it is coming from > > > > Europe, Asia, > > > > > > > Nearwater, Backwater, and many other points as well, > > > > > > attempts to block > > > > > > > the attack either requires effectively severing connectivity > >or > > > > > > > maintaining a fair amount of information about who at the > > > > > IP layer > > > > > > > should be talking to this PSAP. We've discussed the > > > > > > effectiveness of > > > > > > > that in the past. > > > > > > > > > > > > > > >If I > > > > > > > >know the URI of the PSAP, I can now distract it from another > > > > > > > continent > > > > > > > >and do what I would need to do in Backwater and no > > > > > > response would be > > > > > > > >created in that direction - that is the new paradigm with > > > > > > > IP. If I know > > > > > > > >the boundaries of the Derby PSAP, I could create a PSTN > > > > > based DoS > > > > > > > >attack anywhere from within that boundary (potentially 50 > > > > > > miles from > > > > > > > >Island Pond). > > > > > > > > > > > > > > > >Would this happen? I don't know - I am pretty sure it > > > > > > hasn't yet but > > > > > > > >assigning a URI to a PSAP opens it up to whole new > > > > generation of > > > > > > > >"creative thinkers"..... > > > > > > > > > > > > > > > >Of course we can minimize the impact on the PSAP at a > > > > > higher level > > > > > > > >gateway by throwing a huge amount of bandwidth at it and > > > > > > building in > > > > > > > >intelligent alternative routing on a robust firewall. But > > > > > > > that does not > > > > > > > >help in the interim between here and there when someone > > > > > gets their > > > > > > > >hands on the PSAP boundaries and realizes the attacks they > > > > > > > can initiate > > > > > > > >using the PSTN DoS approach. > > > > > > > > > > > > > > The problem with the proposed solution, I believe, is that > > > > > > aggregating > > > > > > > the access to a back-to-back user agent or all-knowing > > > > > > gateway is that > > > > > > > you have simply created a richer target for attack. If I > > > > > > can marshal > > > > > > > a zombie group that takes out all of Vermont's PSAPs by > > > > > eliminating > > > > > > > the the gateway by DDoS, I have done far worse far more > > > > > > easily than I > > > > > > > could by individually attacking the PSAPs at their URIs. > > > > > > If I did it > > > > > > > in order to get at Backwater's target, I likely don't > > > > > care that the > > > > > > > general effect is larger--my purpose is met. > > > > > > > > > > > > > > Yes, it is easier to escalate the defenses at a single > > > > > > point and yes, > > > > > > > it is easier to pay for fat pipes for that single point. > > > > > > But the bad > > > > > > > actors here aren't using their own resources to attack you; > > > > > > they are > > > > > > > stealing them before trying to steal from you. Getting > > > > > > into an arms > > > > > > > race with someone who isn't spending their own money worries > >me. > > > > > > > > > > > > > > regards, > > > > > > > Ted > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 > > > >----------------------------------------------------------------------- -- > ----------------------- > >This message is for the designated recipient only and may contain=20 > >privileged, proprietary, or otherwise private information. > >If you have received it in error, please notify the sender=20 > >immediately and delete the original. Any unauthorized use of this=20 > >email is prohibited. > >----------------------------------------------------------------------- -- > ----------------------- > >[mf2] > > > >_______________________________________________ > >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. ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 13 15:32:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGWO-0004iF-Tr; Tue, 13 Sep 2005 15:32:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFBkb-0006YQ-4W for ecrit@megatron.ietf.org; Tue, 13 Sep 2005 10:27:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24612 for ; Tue, 13 Sep 2005 10:26:50 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFBoi-0003jl-KT for ecrit@ietf.org; Tue, 13 Sep 2005 10:31:27 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j8DEQfFX013413 for ; Tue, 13 Sep 2005 16:26:41 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j8DEQd39009855 for ; Tue, 13 Sep 2005 16:26:40 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 Sep 2005 16:26:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Sep 2005 16:26:38 +0200 Message-ID: Thread-Topic: terminology Thread-Index: AcW4byhDC4sRLbKxTt+Rbcrs5UXwTA== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 13 Sep 2005 14:26:39.0036 (UTC) FILETIME=[274FF7C0:01C5B86F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] terminology X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 i have a question regarding the terminology used in:=20 http://www.ietf.org/internet-drafts/draft-polk-newton-ecrit-arch-conside rations-00.txt the requirements document defines a number of terms. they do not seem to be sufficient, as it seems. i think it would be useful to fix or to enhance the terms in the requirements document as soon as possible. ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 13 15:32:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGWU-0004ld-Mi; Tue, 13 Sep 2005 15:32:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFC9z-0001ul-Vb for ecrit@megatron.ietf.org; Tue, 13 Sep 2005 10:53:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25718 for ; Tue, 13 Sep 2005 10:53:21 -0400 (EDT) Message-Id: <200509131453.KAA25718@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFCEP-0004Kw-7x for ecrit@ietf.org; Tue, 13 Sep 2005 10:57:58 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EFC9j-0000Ee-8g; Tue, 13 Sep 2005 09:53:07 -0500 From: "Brian Rosen" To: "'Rodrig, Benny \(Benny\)'" , "'Winterbottom, James'" , "'ECRIT'" Subject: RE: [Ecrit] Emergency [VPN issue] Date: Tue, 13 Sep 2005 10:52:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW3ImXxJWPwSm4aQ/OygmT03A/KHAAAqMAgAB59zEAAEc9C8AAgqJCAAAJMIEA= 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: d4673ea769cc9931269061744af205ce Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Ah, well, I agree. If the actual access network is a broadband network provided to a teleworker or road warrier, then it is that access network that must provide location, and it has to survive multiple VPN and NAT mangling. The enterprise is responsible for forwarding the location (or a reference to it, but I dislike that alternative). One nit is that an enterprise has to deal with visitors to its network. If it, for example, allows a visitor to connect to its network and connect, say via a VPN, to another network, within which VoIP occurs, then the enterprise is the access network, and must provide location to the visitor. This means the enterprise cannot support a proprietary location mechanism if it allows visitors. Brian -----Original Message----- From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] Sent: Tuesday, September 13, 2005 10:03 AM To: br@brianrosen.net; Winterbottom, James; ECRIT Subject: RE: [Ecrit] Emergency [VPN issue] Brian, I guess you are referring to the enterprise sites, and I completely agree that for those the enterprise is the access provider and has to provide room-level location. My comment below was regarding the enterprise remote users connecting to the corporate network through a VPN from home or from e.g. some remote hotel. For that case, I was disagreeing with James's argument that the enterprise is the access provider if it requires all traffic to go through the VPN. It does not seem feasible for the enterprise to provide the user's location in this case. Benny -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, September 13, 2005 7:08 AM To: Rodrig, Benny (Benny); 'Winterbottom, James'; 'ECRIT' Subject: RE: [Ecrit] Emergency [VPN issue] Benny There are some authentication issues with who is the source of location information, but in general, I believe the enterprise IS the access provider, it simply has an upstream access provider to it. This is not unlike a tier 2 or tier 3 ISP. The point is that if an enterprise is large enough, we need it to supply room-level location, and the access network to it cannot do that. In very large enterprises, the access provider may only be at the headquarters location; remote sites may be served by private networks. In such cases we are wholly reliant on the enterprise to provide accurate location. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Rodrig, Benny (Benny) Sent: Monday, September 12, 2005 9:54 AM To: Winterbottom, James; ECRIT Subject: RE: [Ecrit] Emergency [VPN issue] James, I don't see how the enterprise, even with a VPN policy, can be considered an access provider. The concept of the access provider, as opposed to the application service provider, implies some sort of locality and hence knowledge of user's location. These do not shift from the local Internet access provider to the remote enterprise headquarters just because the endpoint is connecting through a VPN. Benny -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Sunday, September 11, 2005 7:13 PM To: James M. Polk; ECRIT Subject: RE: [Ecrit] Emergency [VPN issue] Hi James, Actually that is not really the point that I am making. The point I was making was that if the enterprise forces its remote staff to pass all traffic through the VPN, including emergency calls, then the enterprise is, for all intents and purposes the access provider, and is responsible to ensure that the call will get to where it needs to go. On the technology front I don't see why a solution shouldn't be universal either. Change to soft-phones in firmware or software are going to be required to get location, and if I understand the proposed solutions correctly then, determine that the call is an emergency one and provide location also. So I don't see that providing split tunneling to cater for this is such a big deal. If enterprises elect not to deploy or engage this functionality then the point of responsibility is clear. Cheers James > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Monday, 12 September 2005 8:44 AM > To: Winterbottom, James; Michael Hammer (mhammer); Stastny Richard; Marc > Linsner (mlinsner); ECRIT > Subject: RE: [Ecrit] Emergency [VPN issue] > > James > > I don't understand the point you're making here. > > Are you suggesting NENA believes a VPNd phone should not communicate over > the VPN when calling ? > > I don't believe this will be universally available > > At 06:29 PM 9/8/2005 -0500, Winterbottom, James wrote: > >This issue has been discussed in NENA at quite some length. The > >consensus that is growing there, and I know that there are some people > >that still disagree, is that if an enterprise is prepared to allow this > >to occur, that the onus is on the enterprise to ensure that it works. > >This makes the problem a little easier to deal with. > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >Of > > > Rodrig, Benny (Benny) > > > Sent: Friday, 9 September 2005 9:14 AM > > > To: Michael Hammer (mhammer); Stastny Richard; Marc Linsner > >(mlinsner); > > > ECRIT > > > Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies- > > > ArchitectureConsiderations > > > > > > Not sure it's always possible for emergency calls to not go though the > > > corporate VPN. For example, the endpoint may have no means (e.g. no > >TURN > > > server) to establish a session directly through the NAT at the > >Backwater > > > Inn, in the example below. > > > > > > Benny > > > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Michael Hammer (mhammer) > > > Sent: Thursday, September 08, 2005 6:26 PM > > > To: Stastny Richard; Marc Linsner (mlinsner); ECRIT > > > Subject: RE: [Ecrit] > > > EmergencyContextRoutingofInternetTechnologies-Architecture > > > Considerations > > > > > > Richard, > > > > > > My original question was about whether a PSAP should expect calls > > > (signaling and media) to originate from non-local destinations, e.g. > > > international, and by inference the need for the PSAPs to be able to > > > make call backs to those locations. If not, then perhaps it is a DDoS > > > clue. > > > > > > Marc pointed out the VPN possibility. > > > > > > You seem to suggest that emergency calls should never go by VPN when > > > dialed. > > > > > > So, is the VPN situation a possibility or precluded? > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, September 08, 2005 5:58 PM > > > > To: Michael Hammer (mhammer); Marc Linsner (mlinsner); ECRIT > > > > Subject: Re: [Ecrit] Emergency > > > > ContextRoutingofInternetTechnologies-Architecture Considerations > > > > > > > > Sorry, but I am confused with this examples: > > > > > > > > Somebody sitting say in Chicago should get routed to a local PSAP in > > > > Chicago, regardless where his provider or sip-server is located > > > > > > > > If he is using a VPN to say a network in Berlin, he may either also > > > > get routed by some magic we still have to work out also to a PSAP in > > > > Chicago, or he is routed wrongly to a PSAP in Berlin. > > > > > > > > But, the PSAP in Berlin will at least get some location and also > >some > > > > identification from Berlin, at the network, so there is some local > > > > relationship > > > > > > > > So what is the point? > > > > > > > > -richard > > > > > > > > ________________________________ > > > > > > > > Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) > > > > Gesendet: Do 08.09.2005 22:56 > > > > An: Marc Linsner (mlinsner); ECRIT > > > > Betreff: RE: [Ecrit] Emergency > > > > ContextRoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > > > > > That is certainly possible. I'm trying to get an idea of the > >assumed > > > > topology models here. If the call gets dropped, does the PSAP make > >an > > > > > > > "international call" to call back such subscribers? Could the call > > > > back number be a number in some Caribbean island that happens to be > >a > > > > 9xx equivalent? Could Berlin Ind. send a 3xx response and say drop > > > > out of this VPN to make the call? > > > > > > > > In any case, your example proves the exception, so likely mine was a > > > > dead end thought. > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Marc Linsner (mlinsner) > > > > > Sent: Thursday, September 08, 2005 4:18 PM > > > > > To: Michael Hammer (mhammer); 'ECRIT' > > > > > Subject: RE: [Ecrit] Emergency Context > > > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > How about an employee of Berlin Industries, Inc. sitting at the > > > > > Backwater Inn with a full vpn up to their corp. hq and calling for > > > > > help. Wouldn't they look like they were coming from Berlin > > > > (the .ru > > > > > domain and IP address would probably be a hint)? Do you > > > > want to block > > > > > them? > > > > > > > > > > I certainly think that it is reasonable to raise a flag to the > > > > > calltaker in this situation, but I wouldn't think you want > > > > to build a > > > > > state machine to simply block such calls. > > > > > > > > > > Replace Berlin with New Hampshire, New York, Mass........ > > > > > > > > > > -Marc- > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > Of Michael Hammer (mhammer) > > > > > > Sent: Thursday, September 08, 2005 3:12 PM > > > > > > To: Ted Hardie; wilcox@e911.psd.state.vt.us; > > > > > br@brianrosen.net; Andrew > > > > > > Newton; Stastny Richard; ECRIT > > > > > > Subject: RE: [Ecrit] Emergency Context > > > > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > Ted, > > > > > > > > > > > > I'm confused. Are calls from Asia or Europe to the Vermont > > > > > PSAP ever > > > > > > legitimate? > > > > > > > > > > > > Somehow, I can't picture the local sheriff being able to > > > > > help someone > > > > > > in Berlin. I thought the point of i3 is to enable the call > > > > > to go to > > > > > > the local Berlin Polizei. Put another way, is it possible > > > > > to use the > > > > > > local nature of emergency service to protect agains DDoS? > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ecrit-bounces@ietf.org > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > Of Ted Hardie > > > > > > > Sent: Thursday, September 08, 2005 1:55 PM > > > > > > > To: wilcox@e911.psd.state.vt.us; br@brianrosen.net; > > > > > Andrew Newton; > > > > > > > Stastny Richard; ECRIT > > > > > > > Subject: RE: [Ecrit] Emergency Context Routing > > > > > > > ofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > > > After reading the thread, I wanted to come back to Nate's > > > > > original > > > > > > > concern and call something out: > > > > > > > > > > > > > > >Here is the PSAP concern: > > > > > > > > > > > > > > > >An enterprising thief could figure out that a business > > > > > (without an > > > > > > > >alarm > > > > > > > >system) in Backwater, Vermont is served by a PSAP located 25 > > > > > > > miles away. > > > > > > > >If one creates an IP-based denial of service attack on that > > > > > > > PSAP then > > > > > > > >it is safe to assume that the target of opportunity that the > > > > > > > thief is > > > > > > > >looking at in Backwater will not be able to contact the PSAP > > > > > > > to summon > > > > > > > >help. > > > > > > > > > > > > > > I'm assuming that the PSAP being 25 miles away means > > > > > nothing about > > > > > > > where the responders are. The responders in this > > > > > instance might be > > > > > > > sheriffs, for example, who are stationed nearby, even > > > > > > further than 25 > > > > > > > miles away, or whose patrol routes mean that their distance > > > > > > from the > > > > > > > target of opportunity is variable. So I think we > > > > should cut the > > > > > > > distance from this description completely, and simply see > > > > > > the threat > > > > > > > as "If the bad actor can determine which PSAP serves an > > > > > > area in which > > > > > > > a target is present, a successful attack on the PSAP prevents > > > > > > > responses to the target". > > > > > > > > > > > > > > Does that make sense? > > > > > > > > > > > > > > > > > > > > > > Using PSTN technologies, an enterprising thief could create > > > > > > > a PSTN DoS > > > > > > > >on the PSAP by simply using an auto call generator from a > > > > > > pay phone > > > > > > > >located in the same proximity as the target of opportunity > > > > > > however, > > > > > > > >this would still create a response to the general area of > > > > > > the crime. > > > > > > > > > > > > > > There are lots of other kinds of PSTN attacks here--the > > > > > > most commonly > > > > > > > portrayed being "cutting the line", which doesn't work > > > > > quite as it > > > > > > > seems in the movies, but does have some effect. > > > > > > > > > > > > > > To avoid the locality problem in this attack, the bad actor > > > > > > can use an > > > > > > > accomplice, meat or mechanical, in any other area served by > > > > > > the PSAP > > > > > > > to do the same thing. This avoids the response hitting > > > > > the general > > > > > > > area of the crime. It also has the same counter-measure; > > > > > > > call-blocking of the attacking phone. This counter-measure > > > > > > is also > > > > > > > relatively easy to accomplish with an IP-based service, > > > > > > provided the > > > > > > > attack is coming from a single IP or block. I believe the > > > > > > problem is > > > > > > > harder in the IP case not because the area from which the > > > > > > attack can > > > > > > > originate is larger but because it is easier to create a > > > > > > Distributed > > > > > > > Denial of Service, largely because of zombie networks and > > > > > > IP spoofing. > > > > > > > That is, if the attack is coming from Europe while the > > > > attack is > > > > > > > happening on Backwater, my response is the same as if it > > > > > came from > > > > > > > Nearwater, VT: > > > > > > > block the attack source. But if it is coming from > > > > Europe, Asia, > > > > > > > Nearwater, Backwater, and many other points as well, > > > > > > attempts to block > > > > > > > the attack either requires effectively severing connectivity > >or > > > > > > > maintaining a fair amount of information about who at the > > > > > IP layer > > > > > > > should be talking to this PSAP. We've discussed the > > > > > > effectiveness of > > > > > > > that in the past. > > > > > > > > > > > > > > >If I > > > > > > > >know the URI of the PSAP, I can now distract it from another > > > > > > > continent > > > > > > > >and do what I would need to do in Backwater and no > > > > > > response would be > > > > > > > >created in that direction - that is the new paradigm with > > > > > > > IP. If I know > > > > > > > >the boundaries of the Derby PSAP, I could create a PSTN > > > > > based DoS > > > > > > > >attack anywhere from within that boundary (potentially 50 > > > > > > miles from > > > > > > > >Island Pond). > > > > > > > > > > > > > > > >Would this happen? I don't know - I am pretty sure it > > > > > > hasn't yet but > > > > > > > >assigning a URI to a PSAP opens it up to whole new > > > > generation of > > > > > > > >"creative thinkers"..... > > > > > > > > > > > > > > > >Of course we can minimize the impact on the PSAP at a > > > > > higher level > > > > > > > >gateway by throwing a huge amount of bandwidth at it and > > > > > > building in > > > > > > > >intelligent alternative routing on a robust firewall. But > > > > > > > that does not > > > > > > > >help in the interim between here and there when someone > > > > > gets their > > > > > > > >hands on the PSAP boundaries and realizes the attacks they > > > > > > > can initiate > > > > > > > >using the PSTN DoS approach. > > > > > > > > > > > > > > The problem with the proposed solution, I believe, is that > > > > > > aggregating > > > > > > > the access to a back-to-back user agent or all-knowing > > > > > > gateway is that > > > > > > > you have simply created a richer target for attack. If I > > > > > > can marshal > > > > > > > a zombie group that takes out all of Vermont's PSAPs by > > > > > eliminating > > > > > > > the the gateway by DDoS, I have done far worse far more > > > > > > easily than I > > > > > > > could by individually attacking the PSAPs at their URIs. > > > > > > If I did it > > > > > > > in order to get at Backwater's target, I likely don't > > > > > care that the > > > > > > > general effect is larger--my purpose is met. > > > > > > > > > > > > > > Yes, it is easier to escalate the defenses at a single > > > > > > point and yes, > > > > > > > it is easier to pay for fat pipes for that single point. > > > > > > But the bad > > > > > > > actors here aren't using their own resources to attack you; > > > > > > they are > > > > > > > stealing them before trying to steal from you. Getting > > > > > > into an arms > > > > > > > race with someone who isn't spending their own money worries > >me. > > > > > > > > > > > > > > regards, > > > > > > > Ted > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 > > > >----------------------------------------------------------------------- -- > ----------------------- > >This message is for the designated recipient only and may contain > >privileged, proprietary, or otherwise private information. > >If you have received it in error, please notify the sender > >immediately and delete the original. Any unauthorized use of this > >email is prohibited. > >----------------------------------------------------------------------- -- > ----------------------- > >[mf2] > > > >_______________________________________________ > >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. ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 13 15:33:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGX0-0004zv-8s; Tue, 13 Sep 2005 15:33:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFCyW-0001zi-9p for ecrit@megatron.ietf.org; Tue, 13 Sep 2005 11:45:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27913 for ; Tue, 13 Sep 2005 11:44:48 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFD2D-0005T7-41 for ecrit@ietf.org; Tue, 13 Sep 2005 11:49:26 -0400 Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j8DFhg622381; Tue, 13 Sep 2005 17:43:42 +0200 (MEST) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zharhxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Sep 2005 16:43:40 +0100 Received: from [127.0.0.1] ([47.130.16.233] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Sep 2005 11:43:38 -0400 Message-ID: <4326F3A5.6040902@nortel.com> Date: Tue, 13 Sep 2005 11:43:33 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Schnizlein Subject: Re: [Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConsiderations References: <43222C87.7050009@cs.columbia.edu> <308d8d835ca81c17ee80bcf6226fc8fb@cisco.com> In-Reply-To: <308d8d835ca81c17ee80bcf6226fc8fb@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Sep 2005 15:43:38.0588 (UTC) FILETIME=[E8C7A9C0:01C5B879] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I have a feeling this takes an overly optimistic view of the cleanliness of the corporate network. It's possible IT thinking has moved on from this position -- one I recognize -- to realize that every host has to be responsible for its own protection. John Schnizlein wrote: > > A valid reason for organizations that deploy Internet VPNs to prohibit > split tunneling, with some traffic through the VPN tunnel and some > straight to Internet destinations, is control of the corporate network > perimeter. A host with split tunneling is exposed to worms and other > security threats through its access outside the VPN. Because it is also > inside the VPN, this host is a disease vector between the outside and > inside. > > It would be a serious mistake to force a choice between this valid > deployment of VPN technology and location information access for > emergency services. > > John > ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 13 15:33:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGXW-0005GW-UC; Tue, 13 Sep 2005 15:33:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFDaZ-0000WE-Ev for ecrit@megatron.ietf.org; Tue, 13 Sep 2005 12:24:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00182 for ; Tue, 13 Sep 2005 12:24:52 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFDez-0006Zh-Vz for ecrit@ietf.org; Tue, 13 Sep 2005 12:29:30 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 13 Sep 2005 09:24:45 -0700 X-IronPort-AV: i="3.97,106,1125903600"; d="scan'208"; a="341251108:sNHT33411004" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8DGO5Ke029204; Tue, 13 Sep 2005 09:24:39 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Sep 2005 09:24:42 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.145.188]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Sep 2005 09:24:41 -0700 Message-Id: <4.3.2.7.2.20050913110428.02fb29f0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Sep 2005 11:24:40 -0500 To: Henning Schulzrinne From: "James M. Polk" Subject: Re: [Ecrit] New ID for downloading URIs via DHCP In-Reply-To: <4326D0E1.6030100@cs.columbia.edu> References: <4.3.2.7.2.20050912172801.03247040@email.cisco.com> <4.3.2.7.2.20050912172801.03247040@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 13 Sep 2005 16:24:41.0456 (UTC) FILETIME=[A4C37F00:01C5B87F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: "'ecrit@ietf.org'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 09:15 AM 9/13/2005 -0400, Henning Schulzrinne wrote: >Maybe it would be helpful to discuss how this work intersects with the >(SIP) configuration work in SIPPING. Jonathan and I have already been discussing this, and we see the two as complementary. If DHCP solves this function for the UA, it doesn't need to request the URIs within SIP messaging. If the UA doesn't get this from DHCP, the UA knows to request this within SIP messaging. I have another ID coming very soon about this using SIP, to focus the discussion for the config work in SIPPING, or to have it separate in ECRIT. I am not professing DHCP as the only solution to this problem space, just the best one at Layer 2/3. >I believe almost all of this information can (and probably should) be part >of the configuration package, rather than DHCP. "rather"? How about "in addition to"? OK, so how exactly is a Vonage-type organization to know where my UA is to give my UA its URI(s), and will a Vonage-type organization know or have the means to know each URI that can be learned via DHCP wherever a UA can be? The access provider will know this, and if this DHCP Option is supported just like the Location Option(s) need(s) to be, this knowledge *can* be learned at boot time. In the cases of a network that owns all 7 layers, DHCP is as good a delivery means as any - and arguably better in the wired/802.11 case of a home or enterprise/business. >In particular, the SIP configuration package has three major advantages: > >- a much better security model (mutual authentication, encryption, etc.) SIP travels much farther in the network, so increased security is necessary at this layer. But I am right now on a wired connection directly to my DHCP server in my house. I'm not worried about authentication or encryption. Enterprises are also in much tighter controlled network infrastructures, so DHCP messaging is much more limited in distances and exposure. >- automatic notification of changes DHCP needs to be refreshed at set, configurable intervals already - location and URIs can be refreshed at the same time, or more often. >- the ability to use the same mechanism to retrieve this information for >the local network and the service provider My SP provides DHCP to my home router/NAT/firewall/DHCP server/client, which all my home devices then talk to This document isn't saying DHCP is better than SIP, just saying this function can be accomplished at one of multiple layers up a stack in a device, and if DHCP addresses this, then SIP isn't needed for this UA (to learn the URIs). If DHCP doesn't address this, the UA seeks this info via SIP. >Henning > >James M. Polk wrote: >>ECRIT WG >>To let folks know >>One reference that is in the new Emergency Architecture Considerations ID >>regarding URIs being able to be downloaded (or requested for, then >>downloaded) to a DHC client is in the following ID just announced (which >>was delayed in its announcement for some reason I am not aware of): >>http://www.ietf.org/internet-drafts/draft-polk-dhc-uri-00.txt >>with this abstract >> This document defines a new Dynamic Host Configuration Protocol >> (DHC) Option to allow one or more URIs to be transmitted from a >> server to a client within one or more messages, and for one or more >> URIs, each with a unique purpose, to be specifically requested by a >> client of a server. Included in this Option is a purpose field to >> identify the type of URI being requested by the client, or the type >> of URI in the DHCP message from the server. >>There are 11 URIs currectly defined in this ID: >> Purpose = 1 (Primary PSAP URI) >> Purpose = 2 (Secondary PSAP URI) >> Purpose = 3 (Location By-Reference of Client) >> Purpose = 4 (ESGW URI of Client) >> Purpose = 5 (ESRP URI of Client) >> Purpose = 6 (Organization Providing Location for Client) >> Purpose = 7 (URI of Geocoding/Reverse Geocoding) >> Purpose = 8 (Primary URI of Geo Mapping Service) >> Purpose = 9 (Secondary URI of Geo Mapping Service) >> Purpose = 10 (Primary URI of Civic Mapping Service) >> Purpose = 11 (Secondary URI of Civic Mapping Service) >>Others can be added based on consensus discussion of this document >>I just spoke with the DHC Chair, and open discussion of this ID on the >>ECRIT list is fine with him. The formal syntax and encoding of the >>option proposal will be discussed on the DHC list for those interested >>there, but the general topic doesn't need to be limiting any of us >>discussing the ID there where they don't care about emergency calling, as >>ECRIT is the primary WG of interest for this effort initially. >>Review and comments are appreciated >>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 Tue Sep 13 16:25:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFHLb-0000Oq-J5; Tue, 13 Sep 2005 16:25:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFHLX-0000J2-Nf for ecrit@megatron.ietf.org; Tue, 13 Sep 2005 16:25:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21358 for ; Tue, 13 Sep 2005 16:25:36 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFHPy-0007Lf-O6 for ecrit@ietf.org; Tue, 13 Sep 2005 16:30:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] Emergency [VPN issue] Date: Tue, 13 Sep 2005 22:26:10 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4503@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Emergency [VPN issue] Thread-Index: AcW3ImXxJWPwSm4aQ/OygmT03A/KHAAAqMAgAB59zEAAEc9C8AAgqJCAAAJMIEAAC9RGxA== From: "Stastny Richard" To: , "Rodrig, Benny \(Benny\)" , "Winterbottom, James" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0634ec58aad05a6aa9ac7d4670be9c6c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I am not the expert here, and maybe I am naive, but I always thought that you need an access network FIRST before you may establish an VPN channel on top =20 And you need this access also during the VPN session. =20 So the first location you get is the one where you are. So what is here the problem? =20 -richard ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von Brian Rosen Gesendet: Di 13.09.2005 16:52 An: 'Rodrig, Benny (Benny)'; 'Winterbottom, James'; 'ECRIT' Betreff: RE: [Ecrit] Emergency [VPN issue] Ah, well, I agree. If the actual access network is a broadband network provided to a teleworker or road warrier, then it is that access network that must provide location, and it has to survive multiple VPN and NAT mangling. The enterprise is responsible for forwarding the location (or = a reference to it, but I dislike that alternative). One nit is that an enterprise has to deal with visitors to its network. = If it, for example, allows a visitor to connect to its network and connect, = say via a VPN, to another network, within which VoIP occurs, then the = enterprise is the access network, and must provide location to the visitor. This = means the enterprise cannot support a proprietary location mechanism if it = allows visitors. Brian -----Original Message----- From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] Sent: Tuesday, September 13, 2005 10:03 AM To: br@brianrosen.net; Winterbottom, James; ECRIT Subject: RE: [Ecrit] Emergency [VPN issue] Brian, I guess you are referring to the enterprise sites, and I completely agree that for those the enterprise is the access provider and has to provide room-level location. My comment below was regarding the enterprise remote users connecting to the corporate network through a VPN from home or from e.g. some remote hotel. For that case, I was disagreeing with James's argument that the enterprise is the access provider if it requires all traffic to go through the VPN. It does not seem feasible for the enterprise to provide the user's location in this case. Benny -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, September 13, 2005 7:08 AM To: Rodrig, Benny (Benny); 'Winterbottom, James'; 'ECRIT' Subject: RE: [Ecrit] Emergency [VPN issue] Benny There are some authentication issues with who is the source of location information, but in general, I believe the enterprise IS the access provider, it simply has an upstream access provider to it. This is not unlike a tier 2 or tier 3 ISP. The point is that if an enterprise is large enough, we need it to supply room-level location, and the access network to it cannot do that. In very large enterprises, the access provider may only be at the headquarters location; remote sites may be served by private networks. In such cases we are wholly reliant on the enterprise to provide accurate location. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Rodrig, Benny (Benny) Sent: Monday, September 12, 2005 9:54 AM To: Winterbottom, James; ECRIT Subject: RE: [Ecrit] Emergency [VPN issue] James, I don't see how the enterprise, even with a VPN policy, can be considered an access provider. The concept of the access provider, as opposed to the application service provider, implies some sort of locality and hence knowledge of user's location. These do not shift from the local Internet access provider to the remote enterprise headquarters just because the endpoint is connecting through a VPN. Benny -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Sunday, September 11, 2005 7:13 PM To: James M. Polk; ECRIT Subject: RE: [Ecrit] Emergency [VPN issue] Hi James, Actually that is not really the point that I am making. The point I was making was that if the enterprise forces its remote staff to pass all traffic through the VPN, including emergency calls, then the enterprise is, for all intents and purposes the access provider, and is responsible to ensure that the call will get to where it needs to go. On the technology front I don't see why a solution shouldn't be universal either. Change to soft-phones in firmware or software are going to be required to get location, and if I understand the proposed solutions correctly then, determine that the call is an emergency one and provide location also. So I don't see that providing split tunneling to cater for this is such a big deal. If enterprises elect not to deploy or engage this functionality then the point of responsibility is clear. Cheers James > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Monday, 12 September 2005 8:44 AM > To: Winterbottom, James; Michael Hammer (mhammer); Stastny Richard; Marc > Linsner (mlinsner); ECRIT > Subject: RE: [Ecrit] Emergency [VPN issue] > > James > > I don't understand the point you're making here. > > Are you suggesting NENA believes a VPNd phone should not communicate over > the VPN when calling ? > > I don't believe this will be universally available > > At 06:29 PM 9/8/2005 -0500, Winterbottom, James wrote: > >This issue has been discussed in NENA at quite some length. The > >consensus that is growing there, and I know that there are some people > >that still disagree, is that if an enterprise is prepared to allow this > >to occur, that the onus is on the enterprise to ensure that it works. > >This makes the problem a little easier to deal with. > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >Of > > > Rodrig, Benny (Benny) > > > Sent: Friday, 9 September 2005 9:14 AM > > > To: Michael Hammer (mhammer); Stastny Richard; Marc Linsner > >(mlinsner); > > > ECRIT > > > Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies- > > > ArchitectureConsiderations > > > > > > Not sure it's always possible for emergency calls to not go though the > > > corporate VPN. For example, the endpoint may have no means (e.g. no > >TURN > > > server) to establish a session directly through the NAT at the > >Backwater > > > Inn, in the example below. > > > > > > Benny > > > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Michael Hammer (mhammer) > > > Sent: Thursday, September 08, 2005 6:26 PM > > > To: Stastny Richard; Marc Linsner (mlinsner); ECRIT > > > Subject: RE: [Ecrit] > > > EmergencyContextRoutingofInternetTechnologies-Architecture > > > Considerations > > > > > > Richard, > > > > > > My original question was about whether a PSAP should expect calls > > > (signaling and media) to originate from non-local destinations, e.g. > > > international, and by inference the need for the PSAPs to be able to > > > make call backs to those locations. If not, then perhaps it is a DDoS > > > clue. > > > > > > Marc pointed out the VPN possibility. > > > > > > You seem to suggest that emergency calls should never go by VPN when > > > dialed. > > > > > > So, is the VPN situation a possibility or precluded? > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, September 08, 2005 5:58 PM > > > > To: Michael Hammer (mhammer); Marc Linsner (mlinsner); ECRIT > > > > Subject: Re: [Ecrit] Emergency > > > > ContextRoutingofInternetTechnologies-Architecture Considerations > > > > > > > > Sorry, but I am confused with this examples: > > > > > > > > Somebody sitting say in Chicago should get routed to a local PSAP in > > > > Chicago, regardless where his provider or sip-server is located > > > > > > > > If he is using a VPN to say a network in Berlin, he may either also > > > > get routed by some magic we still have to work out also to a PSAP in > > > > Chicago, or he is routed wrongly to a PSAP in Berlin. > > > > > > > > But, the PSAP in Berlin will at least get some location and also > >some > > > > identification from Berlin, at the network, so there is some local > > > > relationship > > > > > > > > So what is the point? > > > > > > > > -richard > > > > > > > > ________________________________ > > > > > > > > Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer (mhammer) > > > > Gesendet: Do 08.09.2005 22:56 > > > > An: Marc Linsner (mlinsner); ECRIT > > > > Betreff: RE: [Ecrit] Emergency > > > > ContextRoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > > > > > That is certainly possible. I'm trying to get an idea of the > >assumed > > > > topology models here. If the call gets dropped, does the PSAP make > >an > > > > > > > "international call" to call back such subscribers? Could the call > > > > back number be a number in some Caribbean island that happens to be > >a > > > > 9xx equivalent? Could Berlin Ind. send a 3xx response and say drop > > > > out of this VPN to make the call? > > > > > > > > In any case, your example proves the exception, so likely mine was a > > > > dead end thought. > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Marc Linsner (mlinsner) > > > > > Sent: Thursday, September 08, 2005 4:18 PM > > > > > To: Michael Hammer (mhammer); 'ECRIT' > > > > > Subject: RE: [Ecrit] Emergency Context > > > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > How about an employee of Berlin Industries, Inc. sitting at the > > > > > Backwater Inn with a full vpn up to their corp. hq and calling for > > > > > help. Wouldn't they look like they were coming from Berlin > > > > (the .ru > > > > > domain and IP address would probably be a hint)? Do you > > > > want to block > > > > > them? > > > > > > > > > > I certainly think that it is reasonable to raise a flag to the > > > > > calltaker in this situation, but I wouldn't think you want > > > > to build a > > > > > state machine to simply block such calls. > > > > > > > > > > Replace Berlin with New Hampshire, New York, Mass........ > > > > > > > > > > -Marc- > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > Of Michael Hammer (mhammer) > > > > > > Sent: Thursday, September 08, 2005 3:12 PM > > > > > > To: Ted Hardie; wilcox@e911.psd.state.vt.us; > > > > > br@brianrosen.net; Andrew > > > > > > Newton; Stastny Richard; ECRIT > > > > > > Subject: RE: [Ecrit] Emergency Context > > > > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > Ted, > > > > > > > > > > > > I'm confused. Are calls from Asia or Europe to the Vermont > > > > > PSAP ever > > > > > > legitimate? > > > > > > > > > > > > Somehow, I can't picture the local sheriff being able to > > > > > help someone > > > > > > in Berlin. I thought the point of i3 is to enable the call > > > > > to go to > > > > > > the local Berlin Polizei. Put another way, is it possible > > > > > to use the > > > > > > local nature of emergency service to protect agains DDoS? > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ecrit-bounces@ietf.org > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > Of Ted Hardie > > > > > > > Sent: Thursday, September 08, 2005 1:55 PM > > > > > > > To: wilcox@e911.psd.state.vt.us; br@brianrosen.net; > > > > > Andrew Newton; > > > > > > > Stastny Richard; ECRIT > > > > > > > Subject: RE: [Ecrit] Emergency Context Routing > > > > > > > ofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > > > After reading the thread, I wanted to come back to Nate's > > > > > original > > > > > > > concern and call something out: > > > > > > > > > > > > > > >Here is the PSAP concern: > > > > > > > > > > > > > > > >An enterprising thief could figure out that a business > > > > > (without an > > > > > > > >alarm > > > > > > > >system) in Backwater, Vermont is served by a PSAP located 25 > > > > > > > miles away. > > > > > > > >If one creates an IP-based denial of service attack on that > > > > > > > PSAP then > > > > > > > >it is safe to assume that the target of opportunity that the > > > > > > > thief is > > > > > > > >looking at in Backwater will not be able to contact the PSAP > > > > > > > to summon > > > > > > > >help. > > > > > > > > > > > > > > I'm assuming that the PSAP being 25 miles away means > > > > > nothing about > > > > > > > where the responders are. The responders in this > > > > > instance might be > > > > > > > sheriffs, for example, who are stationed nearby, even > > > > > > further than 25 > > > > > > > miles away, or whose patrol routes mean that their distance > > > > > > from the > > > > > > > target of opportunity is variable. So I think we > > > > should cut the > > > > > > > distance from this description completely, and simply see > > > > > > the threat > > > > > > > as "If the bad actor can determine which PSAP serves an > > > > > > area in which > > > > > > > a target is present, a successful attack on the PSAP prevents > > > > > > > responses to the target". > > > > > > > > > > > > > > Does that make sense? > > > > > > > > > > > > > > > > > > > > > > Using PSTN technologies, an enterprising thief could create > > > > > > > a PSTN DoS > > > > > > > >on the PSAP by simply using an auto call generator from a > > > > > > pay phone > > > > > > > >located in the same proximity as the target of opportunity > > > > > > however, > > > > > > > >this would still create a response to the general area of > > > > > > the crime. > > > > > > > > > > > > > > There are lots of other kinds of PSTN attacks here--the > > > > > > most commonly > > > > > > > portrayed being "cutting the line", which doesn't work > > > > > quite as it > > > > > > > seems in the movies, but does have some effect. > > > > > > > > > > > > > > To avoid the locality problem in this attack, the bad actor > > > > > > can use an > > > > > > > accomplice, meat or mechanical, in any other area served by > > > > > > the PSAP > > > > > > > to do the same thing. This avoids the response hitting > > > > > the general > > > > > > > area of the crime. It also has the same counter-measure; > > > > > > > call-blocking of the attacking phone. This counter-measure > > > > > > is also > > > > > > > relatively easy to accomplish with an IP-based service, > > > > > > provided the > > > > > > > attack is coming from a single IP or block. I believe the > > > > > > problem is > > > > > > > harder in the IP case not because the area from which the > > > > > > attack can > > > > > > > originate is larger but because it is easier to create a > > > > > > Distributed > > > > > > > Denial of Service, largely because of zombie networks and > > > > > > IP spoofing. > > > > > > > That is, if the attack is coming from Europe while the > > > > attack is > > > > > > > happening on Backwater, my response is the same as if it > > > > > came from > > > > > > > Nearwater, VT: > > > > > > > block the attack source. But if it is coming from > > > > Europe, Asia, > > > > > > > Nearwater, Backwater, and many other points as well, > > > > > > attempts to block > > > > > > > the attack either requires effectively severing connectivity > >or > > > > > > > maintaining a fair amount of information about who at the > > > > > IP layer > > > > > > > should be talking to this PSAP. We've discussed the > > > > > > effectiveness of > > > > > > > that in the past. > > > > > > > > > > > > > > >If I > > > > > > > >know the URI of the PSAP, I can now distract it from another > > > > > > > continent > > > > > > > >and do what I would need to do in Backwater and no > > > > > > response would be > > > > > > > >created in that direction - that is the new paradigm with > > > > > > > IP. If I know > > > > > > > >the boundaries of the Derby PSAP, I could create a PSTN > > > > > based DoS > > > > > > > >attack anywhere from within that boundary (potentially 50 > > > > > > miles from > > > > > > > >Island Pond). > > > > > > > > > > > > > > > >Would this happen? I don't know - I am pretty sure it > > > > > > hasn't yet but > > > > > > > >assigning a URI to a PSAP opens it up to whole new > > > > generation of > > > > > > > >"creative thinkers"..... > > > > > > > > > > > > > > > >Of course we can minimize the impact on the PSAP at a > > > > > higher level > > > > > > > >gateway by throwing a huge amount of bandwidth at it and > > > > > > building in > > > > > > > >intelligent alternative routing on a robust firewall. But > > > > > > > that does not > > > > > > > >help in the interim between here and there when someone > > > > > gets their > > > > > > > >hands on the PSAP boundaries and realizes the attacks they > > > > > > > can initiate > > > > > > > >using the PSTN DoS approach. > > > > > > > > > > > > > > The problem with the proposed solution, I believe, is that > > > > > > aggregating > > > > > > > the access to a back-to-back user agent or all-knowing > > > > > > gateway is that > > > > > > > you have simply created a richer target for attack. If I > > > > > > can marshal > > > > > > > a zombie group that takes out all of Vermont's PSAPs by > > > > > eliminating > > > > > > > the the gateway by DDoS, I have done far worse far more > > > > > > easily than I > > > > > > > could by individually attacking the PSAPs at their URIs. > > > > > > If I did it > > > > > > > in order to get at Backwater's target, I likely don't > > > > > care that the > > > > > > > general effect is larger--my purpose is met. > > > > > > > > > > > > > > Yes, it is easier to escalate the defenses at a single > > > > > > point and yes, > > > > > > > it is easier to pay for fat pipes for that single point. > > > > > > But the bad > > > > > > > actors here aren't using their own resources to attack you; > > > > > > they are > > > > > > > stealing them before trying to steal from you. Getting > > > > > > into an arms > > > > > > > race with someone who isn't spending their own money worries > >me. > > > > > > > > > > > > > > regards, > > > > > > > Ted > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 > > > >----------------------------------------------------------------------- -- > ----------------------- > >This message is for the designated recipient only and may contain > >privileged, proprietary, or otherwise private information. > >If you have received it in error, please notify the sender > >immediately and delete the original. Any unauthorized use of this > >email is prohibited. > >----------------------------------------------------------------------- -- > ----------------------- > >[mf2] > > > >_______________________________________________ > >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. ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information.=20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ------------------------ [mf2] _______________________________________________ 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 Tue Sep 13 17:02:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFHvc-0006KX-56; Tue, 13 Sep 2005 17:02:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFHvY-0006In-5U for ecrit@megatron.ietf.org; Tue, 13 Sep 2005 17:02:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26884 for ; Tue, 13 Sep 2005 17:02:48 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFHzy-0001Em-7q for ecrit@ietf.org; Tue, 13 Sep 2005 17:07:29 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 13 Sep 2005 17:02:40 -0400 X-IronPort-AV: i="3.97,106,1125892800"; d="scan'208"; a="70095393:sNHT38815490" 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 j8DL27RB018469; Tue, 13 Sep 2005 17:02:33 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Sep 2005 17:02:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Emergency [VPN issue] Date: Tue, 13 Sep 2005 17:02:32 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E38FA000@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Emergency [VPN issue] Thread-Index: AcW3ImXxJWPwSm4aQ/OygmT03A/KHAAAqMAgAB59zEAAEc9C8AAv2h/Q From: "Michael Hammer \(mhammer\)" To: , "Rodrig, Benny \(Benny\)" , "Winterbottom, James" , "ECRIT" X-OriginalArrivalTime: 13 Sep 2005 21:02:33.0631 (UTC) FILETIME=[762782F0:01C5B8A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2af167865907217f0b49c659e31a77f7 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think this terminology issue has been bounced around the ITU-T FGNGN quite a bit. I had thought that the discussion was starting to converge on the idea that there were access data transport (IP) networks and core data transport (IP) networks. All the hosts that sit on those networks, such as voice servers, should focus on using other terms, such as originating and terminating to describe their relationship to the user. Using "access" for a host far removed from the point where the user accesses the data network is both counter-intuitive and misleading. Better to keep the data and application related adjectives independent. my 2 cents, Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Brian Rosen > Sent: Tuesday, September 13, 2005 7:08 AM > To: 'Rodrig, Benny (Benny)'; 'Winterbottom, James'; 'ECRIT' > Subject: RE: [Ecrit] Emergency [VPN issue] >=20 > Benny >=20 > There are some authentication issues with who is the source=20 > of location information, but in general, I believe the=20 > enterprise IS the access provider, it simply has an upstream=20 > access provider to it. This is not unlike a tier 2 or tier 3=20 > ISP. The point is that if an enterprise is large enough, we=20 > need it to supply room-level location, and the access network=20 > to it cannot do that. In very large enterprises, the access=20 > provider may only be at the headquarters location; remote=20 > sites may be served by private networks. In such cases we=20 > are wholly reliant on the enterprise to provide accurate location. >=20 > Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Rodrig, Benny (Benny) > Sent: Monday, September 12, 2005 9:54 AM > To: Winterbottom, James; ECRIT > Subject: RE: [Ecrit] Emergency [VPN issue] >=20 > James, >=20 > I don't see how the enterprise, even with a VPN policy, can=20 > be considered an access provider. The concept of the access=20 > provider, as opposed to the application service provider,=20 > implies some sort of locality and hence knowledge of user's=20 > location. These do not shift from the local Internet access=20 > provider to the remote enterprise headquarters just because=20 > the endpoint is connecting through a VPN.=20 >=20 > Benny >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Winterbottom, James > Sent: Sunday, September 11, 2005 7:13 PM > To: James M. Polk; ECRIT > Subject: RE: [Ecrit] Emergency [VPN issue] >=20 > Hi James, >=20 > Actually that is not really the point that I am making. The=20 > point I was making was that if the enterprise forces its=20 > remote staff to pass all traffic through the VPN, including=20 > emergency calls, then the enterprise is, for all intents and=20 > purposes the access provider, and is responsible to ensure=20 > that the call will get to where it needs to go. >=20 > On the technology front I don't see why a solution shouldn't=20 > be universal either. Change to soft-phones in firmware or=20 > software are going to be required to get location, and if I=20 > understand the proposed solutions correctly then, determine=20 > that the call is an emergency one and provide location also.=20 > So I don't see that providing split tunneling to cater for=20 > this is such a big deal. If enterprises elect not to deploy=20 > or engage this functionality then the point of responsibility=20 > is clear. >=20 > Cheers > James >=20 > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Monday, 12 September 2005 8:44 AM > > To: Winterbottom, James; Michael Hammer (mhammer); Stastny Richard; > Marc > > Linsner (mlinsner); ECRIT > > Subject: RE: [Ecrit] Emergency [VPN issue] > >=20 > > James > >=20 > > I don't understand the point you're making here. > >=20 > > Are you suggesting NENA believes a VPNd phone should not communicate > over > > the VPN when calling ? > >=20 > > I don't believe this will be universally available > >=20 > > At 06:29 PM 9/8/2005 -0500, Winterbottom, James wrote: > > >This issue has been discussed in NENA at quite some length. The=20 > > >consensus that is growing there, and I know that there are some > people > > >that still disagree, is that if an enterprise is prepared to allow > this > > >to occur, that the onus is on the enterprise to ensure=20 > that it works. > > >This makes the problem a little easier to deal with. > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > > >Of > > > > Rodrig, Benny (Benny) > > > > Sent: Friday, 9 September 2005 9:14 AM > > > > To: Michael Hammer (mhammer); Stastny Richard; Marc Linsner > > >(mlinsner); > > > > ECRIT > > > > Subject: RE: [Ecrit] > EmergencyContextRoutingofInternetTechnologies- > > > > ArchitectureConsiderations > > > > > > > > Not sure it's always possible for emergency calls to=20 > not go though > the > > > > corporate VPN. For example, the endpoint may have no means (e.g. > no > > >TURN > > > > server) to establish a session directly through the NAT at the > > >Backwater > > > > Inn, in the example below. > > > > > > > > Benny > > > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > > > > Of Michael Hammer (mhammer) > > > > Sent: Thursday, September 08, 2005 6:26 PM > > > > To: Stastny Richard; Marc Linsner (mlinsner); ECRIT > > > > Subject: RE: [Ecrit] > > > > EmergencyContextRoutingofInternetTechnologies-Architecture > > > > Considerations > > > > > > > > Richard, > > > > > > > > My original question was about whether a PSAP should=20 > expect calls=20 > > > > (signaling and media) to originate from non-local destinations, > e.g. > > > > international, and by inference the need for the PSAPs=20 > to be able > to > > > > make call backs to those locations. If not, then=20 > perhaps it is a > DDoS > > > > clue. > > > > > > > > Marc pointed out the VPN possibility. > > > > > > > > You seem to suggest that emergency calls should never go by VPN > when > > > > dialed. > > > > > > > > So, is the VPN situation a possibility or precluded? > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Thursday, September 08, 2005 5:58 PM > > > > > To: Michael Hammer (mhammer); Marc Linsner (mlinsner); ECRIT > > > > > Subject: Re: [Ecrit] Emergency > > > > > ContextRoutingofInternetTechnologies-Architecture=20 > Considerations > > > > > > > > > > Sorry, but I am confused with this examples: > > > > > > > > > > Somebody sitting say in Chicago should get routed to a local > PSAP in > > > > > Chicago, regardless where his provider or sip-server=20 > is located > > > > > > > > > > If he is using a VPN to say a network in Berlin, he may either > also > > > > > get routed by some magic we still have to work out also to a > PSAP in > > > > > Chicago, or he is routed wrongly to a PSAP in Berlin. > > > > > > > > > > But, the PSAP in Berlin will at least get some=20 > location and also > > >some > > > > > identification from Berlin, at the network, so there is some > local > > > > > relationship > > > > > > > > > > So what is the point? > > > > > > > > > > -richard > > > > > > > > > > ________________________________ > > > > > > > > > > Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer > (mhammer) > > > > > Gesendet: Do 08.09.2005 22:56 > > > > > An: Marc Linsner (mlinsner); ECRIT > > > > > Betreff: RE: [Ecrit] Emergency > > > > > ContextRoutingofInternetTechnologies-Architecture=20 > Considerations > > > > > > > > > > > > > > > > > > > > That is certainly possible. I'm trying to get an idea of the > > >assumed > > > > > topology models here. If the call gets dropped, does the PSAP > make > > >an > > > > > > > > > "international call" to call back such subscribers? Could the > call > > > > > back number be a number in some Caribbean island that=20 > happens to > be > > >a > > > > > 9xx equivalent? Could Berlin Ind. send a 3xx response and say > drop > > > > > out of this VPN to make the call? > > > > > > > > > > In any case, your example proves the exception, so likely mine > was a > > > > > dead end thought. > > > > > > > > > > Mike > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Marc Linsner (mlinsner) > > > > > > Sent: Thursday, September 08, 2005 4:18 PM > > > > > > To: Michael Hammer (mhammer); 'ECRIT' > > > > > > Subject: RE: [Ecrit] Emergency Context=20 > > > > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > How about an employee of Berlin Industries, Inc. sitting at > the > > > > > > Backwater Inn with a full vpn up to their corp. hq=20 > and calling > for > > > > > > help. Wouldn't they look like they were coming from Berlin > > > > > (the .ru > > > > > > domain and IP address would probably be a hint)? Do you > > > > > want to block > > > > > > them? > > > > > > > > > > > > I certainly think that it is reasonable to raise a=20 > flag to the >=20 > > > > > > calltaker in this situation, but I wouldn't think you want > > > > > to build a > > > > > > state machine to simply block such calls. > > > > > > > > > > > > Replace Berlin with New Hampshire, New York, Mass........ > > > > > > > > > > > > -Marc- > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ecrit-bounces@ietf.org > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > Of Michael Hammer (mhammer) > > > > > > > Sent: Thursday, September 08, 2005 3:12 PM > > > > > > > To: Ted Hardie; wilcox@e911.psd.state.vt.us; > > > > > > br@brianrosen.net; Andrew > > > > > > > Newton; Stastny Richard; ECRIT > > > > > > > Subject: RE: [Ecrit] Emergency Context=20 > > > > > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > > > Ted, > > > > > > > > > > > > > > I'm confused. Are calls from Asia or Europe to=20 > the Vermont > > > > > > PSAP ever > > > > > > > legitimate? > > > > > > > > > > > > > > Somehow, I can't picture the local sheriff being able to > > > > > > help someone > > > > > > > in Berlin. I thought the point of i3 is to=20 > enable the call > > > > > > to go to > > > > > > > the local Berlin Polizei. Put another way, is it possible > > > > > > to use the > > > > > > > local nature of emergency service to protect agains DDoS? > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ecrit-bounces@ietf.org > > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > > Of Ted Hardie > > > > > > > > Sent: Thursday, September 08, 2005 1:55 PM > > > > > > > > To: wilcox@e911.psd.state.vt.us; br@brianrosen.net; > > > > > > Andrew Newton; > > > > > > > > Stastny Richard; ECRIT > > > > > > > > Subject: RE: [Ecrit] Emergency Context Routing=20 > > > > > > > > ofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > > > > > After reading the thread, I wanted to come back=20 > to Nate's > > > > > > original > > > > > > > > concern and call something out: > > > > > > > > > > > > > > > > >Here is the PSAP concern: > > > > > > > > > > > > > > > > > >An enterprising thief could figure out that a business > > > > > > (without an > > > > > > > > >alarm > > > > > > > > >system) in Backwater, Vermont is served by a=20 > PSAP located > 25 > > > > > > > > miles away. > > > > > > > > >If one creates an IP-based denial of service attack on > that > > > > > > > > PSAP then > > > > > > > > >it is safe to assume that the target of=20 > opportunity that > the > > > > > > > > thief is > > > > > > > > >looking at in Backwater will not be able to contact the > PSAP > > > > > > > > to summon > > > > > > > > >help. > > > > > > > > > > > > > > > > I'm assuming that the PSAP being 25 miles away means > > > > > > nothing about > > > > > > > > where the responders are. The responders in this > > > > > > instance might be > > > > > > > > sheriffs, for example, who are stationed nearby, even > > > > > > > further than 25 > > > > > > > > miles away, or whose patrol routes mean that their > distance > > > > > > > from the > > > > > > > > target of opportunity is variable. So I think we > > > > > should cut the > > > > > > > > distance from this description completely, and=20 > simply see > > > > > > > the threat > > > > > > > > as "If the bad actor can determine which PSAP serves an > > > > > > > area in which > > > > > > > > a target is present, a successful attack on the PSAP > prevents > > > > > > > > responses to the target". > > > > > > > > > > > > > > > > Does that make sense? > > > > > > > > > > > > > > > > > > > > > > > > > Using PSTN technologies, an enterprising thief could > create > > > > > > > > a PSTN DoS > > > > > > > > >on the PSAP by simply using an auto call=20 > generator from a > > > > > > > pay phone > > > > > > > > >located in the same proximity as the target of > opportunity > > > > > > > however, > > > > > > > > >this would still create a response to the=20 > general area of > > > > > > > the crime. > > > > > > > > > > > > > > > > There are lots of other kinds of PSTN attacks here--the > > > > > > > most commonly > > > > > > > > portrayed being "cutting the line", which doesn't work > > > > > > quite as it > > > > > > > > seems in the movies, but does have some effect. > > > > > > > > > > > > > > > > To avoid the locality problem in this attack, the bad > actor > > > > > > > can use an > > > > > > > > accomplice, meat or mechanical, in any other area served > by > > > > > > > the PSAP > > > > > > > > to do the same thing. This avoids the response hitting > > > > > > the general > > > > > > > > area of the crime. It also has the same=20 > counter-measure;=20 > > > > > > > > call-blocking of the attacking phone. This > counter-measure > > > > > > > is also > > > > > > > > relatively easy to accomplish with an IP-based service, > > > > > > > provided the > > > > > > > > attack is coming from a single IP or block. I=20 > believe the > > > > > > > problem is > > > > > > > > harder in the IP case not because the area from=20 > which the > > > > > > > attack can > > > > > > > > originate is larger but because it is easier to create a > > > > > > > Distributed > > > > > > > > Denial of Service, largely because of zombie=20 > networks and > > > > > > > IP spoofing. > > > > > > > > That is, if the attack is coming from Europe while the > > > > > attack is > > > > > > > > happening on Backwater, my response is the same as if it > > > > > > came from > > > > > > > > Nearwater, VT: > > > > > > > > block the attack source. But if it is coming from > > > > > Europe, Asia, > > > > > > > > Nearwater, Backwater, and many other points as well, > > > > > > > attempts to block > > > > > > > > the attack either requires effectively severing > connectivity > > >or > > > > > > > > maintaining a fair amount of information about=20 > who at the > > > > > > IP layer > > > > > > > > should be talking to this PSAP. We've discussed the > > > > > > > effectiveness of > > > > > > > > that in the past. > > > > > > > > > > > > > > > > >If I > > > > > > > > >know the URI of the PSAP, I can now distract it from > another > > > > > > > > continent > > > > > > > > >and do what I would need to do in Backwater and no > > > > > > > response would be > > > > > > > > >created in that direction - that is the new=20 > paradigm with > > > > > > > > IP. If I know > > > > > > > > >the boundaries of the Derby PSAP, I could create a PSTN > > > > > > based DoS > > > > > > > > >attack anywhere from within that boundary=20 > (potentially 50 > > > > > > > miles from > > > > > > > > >Island Pond). > > > > > > > > > > > > > > > > > >Would this happen? I don't know - I am pretty sure it > > > > > > > hasn't yet but > > > > > > > > >assigning a URI to a PSAP opens it up to whole new > > > > > generation of > > > > > > > > >"creative thinkers"..... > > > > > > > > > > > > > > > > > >Of course we can minimize the impact on the PSAP at a > > > > > > higher level > > > > > > > > >gateway by throwing a huge amount of bandwidth=20 > at it and > > > > > > > building in > > > > > > > > >intelligent alternative routing on a robust=20 > firewall. But > > > > > > > > that does not > > > > > > > > >help in the interim between here and there when someone > > > > > > gets their > > > > > > > > >hands on the PSAP boundaries and realizes the attacks > they > > > > > > > > can initiate > > > > > > > > >using the PSTN DoS approach. > > > > > > > > > > > > > > > > The problem with the proposed solution, I=20 > believe, is that > > > > > > > aggregating > > > > > > > > the access to a back-to-back user agent or all-knowing > > > > > > > gateway is that > > > > > > > > you have simply created a richer target for=20 > attack. If I > > > > > > > can marshal > > > > > > > > a zombie group that takes out all of Vermont's PSAPs by > > > > > > eliminating > > > > > > > > the the gateway by DDoS, I have done far worse far more > > > > > > > easily than I > > > > > > > > could by individually attacking the PSAPs at their URIs. > > > > > > > If I did it > > > > > > > > in order to get at Backwater's target, I likely don't > > > > > > care that the > > > > > > > > general effect is larger--my purpose is met. > > > > > > > > > > > > > > > > Yes, it is easier to escalate the defenses at a single > > > > > > > point and yes, > > > > > > > > it is easier to pay for fat pipes for that=20 > single point. > > > > > > > But the bad > > > > > > > > actors here aren't using their own resources to attack > you; > > > > > > > they are > > > > > > > > stealing them before trying to steal from you. Getting > > > > > > > into an arms > > > > > > > > race with someone who isn't spending their own money > worries > > >me. > > > > > > > > > > > > > > > > regards, > > > > > > > > Ted > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > 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 > > > > > > >------------------------------------------------------------- > ---------- > -- > > ----------------------- > > >This message is for the designated recipient only and may contain=20 > > >privileged, proprietary, or otherwise private information. > > >If you have received it in error, please notify the sender=20 > > >immediately and delete the original. Any unauthorized use of this=20 > > >email is prohibited. > > > >------------------------------------------------------------- > ---------- > -- > > ----------------------- > > >[mf2] > > > > > >_______________________________________________ > > >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 > -------------------------------------------------------------- > ---------- > ------------------------ > This message is for the designated recipient only and may=20 > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender=20 > immediately and delete the original. Any unauthorized use of=20 > this email is prohibited. > -------------------------------------------------------------- > ---------- > ------------------------ > [mf2] >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 13 17:31:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFINj-00065n-BA; Tue, 13 Sep 2005 17:31:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFINg-00065i-SO for ecrit@megatron.ietf.org; Tue, 13 Sep 2005 17:31:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27948 for ; Tue, 13 Sep 2005 17:31:53 -0400 (EDT) Message-Id: <200509132131.RAA27948@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFIS9-0001vP-Fe for ecrit@ietf.org; Tue, 13 Sep 2005 17:36:34 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EFINO-0003id-9P; Tue, 13 Sep 2005 16:31:39 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Rodrig, Benny \(Benny\)'" , "'Winterbottom, James'" , "'ECRIT'" Subject: RE: [Ecrit] Emergency [VPN issue] Date: Tue, 13 Sep 2005 17:31:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E38FA000@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW3ImXxJWPwSm4aQ/OygmT03A/KHAAAqMAgAB59zEAAEc9C8AAv2h/QAAEMGfA= 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: 835ad9b9deb0975ba747bfa9d7f1aef1 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org For the purposes of this discussion, the access data transport network is responsible for location. The way I look at it, it's the "last" (or "first" if you will) mile provider. If the length of the network from there is big enough, you need to add room level location. From a definition standpoint, it gets sticky. What is the conceptual and terminology difference from an enterprise with 3 levels of Ethernet switch, two levels of routing and a VPN, and Marc Linser's home with one switch, one "home router" and a VPN tunnel to it. We don't need room level location for the latter, although we would welcome it. We probably do need room level location from the former. But, who is the "access data transport" network in the former case? Is it the carrier that serves the HQ location, or the enterprise itself? Brian -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Tuesday, September 13, 2005 5:03 PM To: br@brianrosen.net; Rodrig, Benny (Benny); Winterbottom, James; ECRIT Subject: RE: [Ecrit] Emergency [VPN issue] I think this terminology issue has been bounced around the ITU-T FGNGN quite a bit. I had thought that the discussion was starting to converge on the idea that there were access data transport (IP) networks and core data transport (IP) networks. All the hosts that sit on those networks, such as voice servers, should focus on using other terms, such as originating and terminating to describe their relationship to the user. Using "access" for a host far removed from the point where the user accesses the data network is both counter-intuitive and misleading. Better to keep the data and application related adjectives independent. my 2 cents, Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Tuesday, September 13, 2005 7:08 AM > To: 'Rodrig, Benny (Benny)'; 'Winterbottom, James'; 'ECRIT' > Subject: RE: [Ecrit] Emergency [VPN issue] > > Benny > > There are some authentication issues with who is the source > of location information, but in general, I believe the > enterprise IS the access provider, it simply has an upstream > access provider to it. This is not unlike a tier 2 or tier 3 > ISP. The point is that if an enterprise is large enough, we > need it to supply room-level location, and the access network > to it cannot do that. In very large enterprises, the access > provider may only be at the headquarters location; remote > sites may be served by private networks. In such cases we > are wholly reliant on the enterprise to provide accurate location. > > Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Rodrig, Benny (Benny) > Sent: Monday, September 12, 2005 9:54 AM > To: Winterbottom, James; ECRIT > Subject: RE: [Ecrit] Emergency [VPN issue] > > James, > > I don't see how the enterprise, even with a VPN policy, can > be considered an access provider. The concept of the access > provider, as opposed to the application service provider, > implies some sort of locality and hence knowledge of user's > location. These do not shift from the local Internet access > provider to the remote enterprise headquarters just because > the endpoint is connecting through a VPN. > > Benny > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Winterbottom, James > Sent: Sunday, September 11, 2005 7:13 PM > To: James M. Polk; ECRIT > Subject: RE: [Ecrit] Emergency [VPN issue] > > Hi James, > > Actually that is not really the point that I am making. The > point I was making was that if the enterprise forces its > remote staff to pass all traffic through the VPN, including > emergency calls, then the enterprise is, for all intents and > purposes the access provider, and is responsible to ensure > that the call will get to where it needs to go. > > On the technology front I don't see why a solution shouldn't > be universal either. Change to soft-phones in firmware or > software are going to be required to get location, and if I > understand the proposed solutions correctly then, determine > that the call is an emergency one and provide location also. > So I don't see that providing split tunneling to cater for > this is such a big deal. If enterprises elect not to deploy > or engage this functionality then the point of responsibility > is clear. > > Cheers > James > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Monday, 12 September 2005 8:44 AM > > To: Winterbottom, James; Michael Hammer (mhammer); Stastny Richard; > Marc > > Linsner (mlinsner); ECRIT > > Subject: RE: [Ecrit] Emergency [VPN issue] > > > > James > > > > I don't understand the point you're making here. > > > > Are you suggesting NENA believes a VPNd phone should not communicate > over > > the VPN when calling ? > > > > I don't believe this will be universally available > > > > At 06:29 PM 9/8/2005 -0500, Winterbottom, James wrote: > > >This issue has been discussed in NENA at quite some length. The > > >consensus that is growing there, and I know that there are some > people > > >that still disagree, is that if an enterprise is prepared to allow > this > > >to occur, that the onus is on the enterprise to ensure > that it works. > > >This makes the problem a little easier to deal with. > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > > >Of > > > > Rodrig, Benny (Benny) > > > > Sent: Friday, 9 September 2005 9:14 AM > > > > To: Michael Hammer (mhammer); Stastny Richard; Marc Linsner > > >(mlinsner); > > > > ECRIT > > > > Subject: RE: [Ecrit] > EmergencyContextRoutingofInternetTechnologies- > > > > ArchitectureConsiderations > > > > > > > > Not sure it's always possible for emergency calls to > not go though > the > > > > corporate VPN. For example, the endpoint may have no means (e.g. > no > > >TURN > > > > server) to establish a session directly through the NAT at the > > >Backwater > > > > Inn, in the example below. > > > > > > > > Benny > > > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > > > > Of Michael Hammer (mhammer) > > > > Sent: Thursday, September 08, 2005 6:26 PM > > > > To: Stastny Richard; Marc Linsner (mlinsner); ECRIT > > > > Subject: RE: [Ecrit] > > > > EmergencyContextRoutingofInternetTechnologies-Architecture > > > > Considerations > > > > > > > > Richard, > > > > > > > > My original question was about whether a PSAP should > expect calls > > > > (signaling and media) to originate from non-local destinations, > e.g. > > > > international, and by inference the need for the PSAPs > to be able > to > > > > make call backs to those locations. If not, then > perhaps it is a > DDoS > > > > clue. > > > > > > > > Marc pointed out the VPN possibility. > > > > > > > > You seem to suggest that emergency calls should never go by VPN > when > > > > dialed. > > > > > > > > So, is the VPN situation a possibility or precluded? > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Thursday, September 08, 2005 5:58 PM > > > > > To: Michael Hammer (mhammer); Marc Linsner (mlinsner); ECRIT > > > > > Subject: Re: [Ecrit] Emergency > > > > > ContextRoutingofInternetTechnologies-Architecture > Considerations > > > > > > > > > > Sorry, but I am confused with this examples: > > > > > > > > > > Somebody sitting say in Chicago should get routed to a local > PSAP in > > > > > Chicago, regardless where his provider or sip-server > is located > > > > > > > > > > If he is using a VPN to say a network in Berlin, he may either > also > > > > > get routed by some magic we still have to work out also to a > PSAP in > > > > > Chicago, or he is routed wrongly to a PSAP in Berlin. > > > > > > > > > > But, the PSAP in Berlin will at least get some > location and also > > >some > > > > > identification from Berlin, at the network, so there is some > local > > > > > relationship > > > > > > > > > > So what is the point? > > > > > > > > > > -richard > > > > > > > > > > ________________________________ > > > > > > > > > > Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer > (mhammer) > > > > > Gesendet: Do 08.09.2005 22:56 > > > > > An: Marc Linsner (mlinsner); ECRIT > > > > > Betreff: RE: [Ecrit] Emergency > > > > > ContextRoutingofInternetTechnologies-Architecture > Considerations > > > > > > > > > > > > > > > > > > > > That is certainly possible. I'm trying to get an idea of the > > >assumed > > > > > topology models here. If the call gets dropped, does the PSAP > make > > >an > > > > > > > > > "international call" to call back such subscribers? Could the > call > > > > > back number be a number in some Caribbean island that > happens to > be > > >a > > > > > 9xx equivalent? Could Berlin Ind. send a 3xx response and say > drop > > > > > out of this VPN to make the call? > > > > > > > > > > In any case, your example proves the exception, so likely mine > was a > > > > > dead end thought. > > > > > > > > > > Mike > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Marc Linsner (mlinsner) > > > > > > Sent: Thursday, September 08, 2005 4:18 PM > > > > > > To: Michael Hammer (mhammer); 'ECRIT' > > > > > > Subject: RE: [Ecrit] Emergency Context > > > > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > How about an employee of Berlin Industries, Inc. sitting at > the > > > > > > Backwater Inn with a full vpn up to their corp. hq > and calling > for > > > > > > help. Wouldn't they look like they were coming from Berlin > > > > > (the .ru > > > > > > domain and IP address would probably be a hint)? Do you > > > > > want to block > > > > > > them? > > > > > > > > > > > > I certainly think that it is reasonable to raise a > flag to the > > > > > > > calltaker in this situation, but I wouldn't think you want > > > > > to build a > > > > > > state machine to simply block such calls. > > > > > > > > > > > > Replace Berlin with New Hampshire, New York, Mass........ > > > > > > > > > > > > -Marc- > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ecrit-bounces@ietf.org > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > Of Michael Hammer (mhammer) > > > > > > > Sent: Thursday, September 08, 2005 3:12 PM > > > > > > > To: Ted Hardie; wilcox@e911.psd.state.vt.us; > > > > > > br@brianrosen.net; Andrew > > > > > > > Newton; Stastny Richard; ECRIT > > > > > > > Subject: RE: [Ecrit] Emergency Context > > > > > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > > > Ted, > > > > > > > > > > > > > > I'm confused. Are calls from Asia or Europe to > the Vermont > > > > > > PSAP ever > > > > > > > legitimate? > > > > > > > > > > > > > > Somehow, I can't picture the local sheriff being able to > > > > > > help someone > > > > > > > in Berlin. I thought the point of i3 is to > enable the call > > > > > > to go to > > > > > > > the local Berlin Polizei. Put another way, is it possible > > > > > > to use the > > > > > > > local nature of emergency service to protect agains DDoS? > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ecrit-bounces@ietf.org > > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > > Of Ted Hardie > > > > > > > > Sent: Thursday, September 08, 2005 1:55 PM > > > > > > > > To: wilcox@e911.psd.state.vt.us; br@brianrosen.net; > > > > > > Andrew Newton; > > > > > > > > Stastny Richard; ECRIT > > > > > > > > Subject: RE: [Ecrit] Emergency Context Routing > > > > > > > > ofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > > > > > After reading the thread, I wanted to come back > to Nate's > > > > > > original > > > > > > > > concern and call something out: > > > > > > > > > > > > > > > > >Here is the PSAP concern: > > > > > > > > > > > > > > > > > >An enterprising thief could figure out that a business > > > > > > (without an > > > > > > > > >alarm > > > > > > > > >system) in Backwater, Vermont is served by a > PSAP located > 25 > > > > > > > > miles away. > > > > > > > > >If one creates an IP-based denial of service attack on > that > > > > > > > > PSAP then > > > > > > > > >it is safe to assume that the target of > opportunity that > the > > > > > > > > thief is > > > > > > > > >looking at in Backwater will not be able to contact the > PSAP > > > > > > > > to summon > > > > > > > > >help. > > > > > > > > > > > > > > > > I'm assuming that the PSAP being 25 miles away means > > > > > > nothing about > > > > > > > > where the responders are. The responders in this > > > > > > instance might be > > > > > > > > sheriffs, for example, who are stationed nearby, even > > > > > > > further than 25 > > > > > > > > miles away, or whose patrol routes mean that their > distance > > > > > > > from the > > > > > > > > target of opportunity is variable. So I think we > > > > > should cut the > > > > > > > > distance from this description completely, and > simply see > > > > > > > the threat > > > > > > > > as "If the bad actor can determine which PSAP serves an > > > > > > > area in which > > > > > > > > a target is present, a successful attack on the PSAP > prevents > > > > > > > > responses to the target". > > > > > > > > > > > > > > > > Does that make sense? > > > > > > > > > > > > > > > > > > > > > > > > > Using PSTN technologies, an enterprising thief could > create > > > > > > > > a PSTN DoS > > > > > > > > >on the PSAP by simply using an auto call > generator from a > > > > > > > pay phone > > > > > > > > >located in the same proximity as the target of > opportunity > > > > > > > however, > > > > > > > > >this would still create a response to the > general area of > > > > > > > the crime. > > > > > > > > > > > > > > > > There are lots of other kinds of PSTN attacks here--the > > > > > > > most commonly > > > > > > > > portrayed being "cutting the line", which doesn't work > > > > > > quite as it > > > > > > > > seems in the movies, but does have some effect. > > > > > > > > > > > > > > > > To avoid the locality problem in this attack, the bad > actor > > > > > > > can use an > > > > > > > > accomplice, meat or mechanical, in any other area served > by > > > > > > > the PSAP > > > > > > > > to do the same thing. This avoids the response hitting > > > > > > the general > > > > > > > > area of the crime. It also has the same > counter-measure; > > > > > > > > call-blocking of the attacking phone. This > counter-measure > > > > > > > is also > > > > > > > > relatively easy to accomplish with an IP-based service, > > > > > > > provided the > > > > > > > > attack is coming from a single IP or block. I > believe the > > > > > > > problem is > > > > > > > > harder in the IP case not because the area from > which the > > > > > > > attack can > > > > > > > > originate is larger but because it is easier to create a > > > > > > > Distributed > > > > > > > > Denial of Service, largely because of zombie > networks and > > > > > > > IP spoofing. > > > > > > > > That is, if the attack is coming from Europe while the > > > > > attack is > > > > > > > > happening on Backwater, my response is the same as if it > > > > > > came from > > > > > > > > Nearwater, VT: > > > > > > > > block the attack source. But if it is coming from > > > > > Europe, Asia, > > > > > > > > Nearwater, Backwater, and many other points as well, > > > > > > > attempts to block > > > > > > > > the attack either requires effectively severing > connectivity > > >or > > > > > > > > maintaining a fair amount of information about > who at the > > > > > > IP layer > > > > > > > > should be talking to this PSAP. We've discussed the > > > > > > > effectiveness of > > > > > > > > that in the past. > > > > > > > > > > > > > > > > >If I > > > > > > > > >know the URI of the PSAP, I can now distract it from > another > > > > > > > > continent > > > > > > > > >and do what I would need to do in Backwater and no > > > > > > > response would be > > > > > > > > >created in that direction - that is the new > paradigm with > > > > > > > > IP. If I know > > > > > > > > >the boundaries of the Derby PSAP, I could create a PSTN > > > > > > based DoS > > > > > > > > >attack anywhere from within that boundary > (potentially 50 > > > > > > > miles from > > > > > > > > >Island Pond). > > > > > > > > > > > > > > > > > >Would this happen? I don't know - I am pretty sure it > > > > > > > hasn't yet but > > > > > > > > >assigning a URI to a PSAP opens it up to whole new > > > > > generation of > > > > > > > > >"creative thinkers"..... > > > > > > > > > > > > > > > > > >Of course we can minimize the impact on the PSAP at a > > > > > > higher level > > > > > > > > >gateway by throwing a huge amount of bandwidth > at it and > > > > > > > building in > > > > > > > > >intelligent alternative routing on a robust > firewall. But > > > > > > > > that does not > > > > > > > > >help in the interim between here and there when someone > > > > > > gets their > > > > > > > > >hands on the PSAP boundaries and realizes the attacks > they > > > > > > > > can initiate > > > > > > > > >using the PSTN DoS approach. > > > > > > > > > > > > > > > > The problem with the proposed solution, I > believe, is that > > > > > > > aggregating > > > > > > > > the access to a back-to-back user agent or all-knowing > > > > > > > gateway is that > > > > > > > > you have simply created a richer target for > attack. If I > > > > > > > can marshal > > > > > > > > a zombie group that takes out all of Vermont's PSAPs by > > > > > > eliminating > > > > > > > > the the gateway by DDoS, I have done far worse far more > > > > > > > easily than I > > > > > > > > could by individually attacking the PSAPs at their URIs. > > > > > > > If I did it > > > > > > > > in order to get at Backwater's target, I likely don't > > > > > > care that the > > > > > > > > general effect is larger--my purpose is met. > > > > > > > > > > > > > > > > Yes, it is easier to escalate the defenses at a single > > > > > > > point and yes, > > > > > > > > it is easier to pay for fat pipes for that > single point. > > > > > > > But the bad > > > > > > > > actors here aren't using their own resources to attack > you; > > > > > > > they are > > > > > > > > stealing them before trying to steal from you. Getting > > > > > > > into an arms > > > > > > > > race with someone who isn't spending their own money > worries > > >me. > > > > > > > > > > > > > > > > regards, > > > > > > > > Ted > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > 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 > > > > > > >------------------------------------------------------------- > ---------- > -- > > ----------------------- > > >This message is for the designated recipient only and may contain > > >privileged, proprietary, or otherwise private information. > > >If you have received it in error, please notify the sender > > >immediately and delete the original. Any unauthorized use of this > > >email is prohibited. > > > >------------------------------------------------------------- > ---------- > -- > > ----------------------- > > >[mf2] > > > > > >_______________________________________________ > > >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. > > -------------------------------------------------------------- > ---------- > ------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------- > ------------------------ > [mf2] > > _______________________________________________ > 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 Tue Sep 13 18:17:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFJ65-0004rC-8p; Tue, 13 Sep 2005 18:17:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFJ63-0004qi-3R for ecrit@megatron.ietf.org; Tue, 13 Sep 2005 18:17:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02297 for ; Tue, 13 Sep 2005 18:17:43 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFJAV-0003WS-W4 for ecrit@ietf.org; Tue, 13 Sep 2005 18:22:25 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 13 Sep 2005 18:17:37 -0400 X-IronPort-AV: i="3.97,106,1125892800"; d="scan'208"; a="70105699:sNHT30982292" Received: from [68.50.138.194] (che-vpn-cluster-2-153.cisco.com [10.86.242.153]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8DMHVT6011842; Tue, 13 Sep 2005 18:17:33 -0400 (EDT) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4503@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C4503@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit] Emergency [VPN issue] Date: Tue, 13 Sep 2005 18:17:26 -0400 To: "Stastny Richard" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Richard, I think you got it exactly right (again). I think you stated it more succinctly than Brian did. What the first network is called does not matter. The host's first point of attachment determines its location] even though the host's IP address might change after that. As long as the location is captured at that first point, and not mangled (e.g. as a side-effect of address change), there is no problem. John On Sep 13, 2005, at 4:26 PM, Stastny Richard wrote: > I am not the expert here, and maybe I am naive, > but I always thought that you need an access network FIRST > before you may establish an VPN channel on top > > And you need this access also during the VPN session. > > So the first location you get is the one where you are. > > So what is here the problem? > > -richard > > ________________________________ > > Von: ecrit-bounces@ietf.org im Auftrag von Brian Rosen > Gesendet: Di 13.09.2005 16:52 > An: 'Rodrig, Benny (Benny)'; 'Winterbottom, James'; 'ECRIT' > Betreff: RE: [Ecrit] Emergency [VPN issue] > > > > Ah, well, I agree. If the actual access network is a broadband network > provided to a teleworker or road warrier, then it is that access > network > that must provide location, and it has to survive multiple VPN and NAT > mangling. The enterprise is responsible for forwarding the location > (or a > reference to it, but I dislike that alternative). > > One nit is that an enterprise has to deal with visitors to its > network. If > it, for example, allows a visitor to connect to its network and > connect, say > via a VPN, to another network, within which VoIP occurs, then the > enterprise > is the access network, and must provide location to the visitor. This > means > the enterprise cannot support a proprietary location mechanism if it > allows > visitors. > > Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 13 19:28:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFKCZ-0006Os-9n; Tue, 13 Sep 2005 19:28:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFKCX-0006On-SS for ecrit@megatron.ietf.org; Tue, 13 Sep 2005 19:28:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09868 for ; Tue, 13 Sep 2005 19:28:30 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFKH1-0006l9-Eh for ecrit@ietf.org; Tue, 13 Sep 2005 19:33:12 -0400 Received: from [10.0.1.100] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 13 Sep 2005 19:28:31 -0400 id 000C7E8D.4327609F.000005D6 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] terminology Date: Tue, 13 Sep 2005 19:28:22 -0400 To: "Tschofenig, Hannes" X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 13, 2005, at 10:26 AM, Tschofenig, Hannes wrote: > hi all, > > i have a question regarding the terminology used in: > http://www.ietf.org/internet-drafts/draft-polk-newton-ecrit-arch- > conside > rations-00.txt > > the requirements document defines a number of terms. they do not > seem to > be sufficient, as it seems. i think it would be useful to fix or to > enhance the terms in the requirements document as soon as possible. Hannes, What was your question? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 13 19:36:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFKJn-00080E-So; Tue, 13 Sep 2005 19:36:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFKJm-000800-0R for ecrit@megatron.ietf.org; Tue, 13 Sep 2005 19:36:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10050 for ; Tue, 13 Sep 2005 19:35:58 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFKOG-0006ty-L1 for ecrit@ietf.org; Tue, 13 Sep 2005 19:40:40 -0400 Received: from [10.0.1.100] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 13 Sep 2005 19:36:00 -0400 id 000C7E83.43276260.00000750 In-Reply-To: <4.3.2.7.2.20050913110428.02fb29f0@email.cisco.com> References: <4.3.2.7.2.20050912172801.03247040@email.cisco.com> <4.3.2.7.2.20050912172801.03247040@email.cisco.com> <4.3.2.7.2.20050913110428.02fb29f0@email.cisco.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] New ID for downloading URIs via DHCP Date: Tue, 13 Sep 2005 19:35:57 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 13, 2005, at 12:24 PM, James M. Polk wrote: >> - the ability to use the same mechanism to retrieve this >> information for the local network and the service provider >> > > My SP provides DHCP to my home router/NAT/firewall/DHCP server/ > client, which all my home devices then talk to > > This document isn't saying DHCP is better than SIP, just saying > this function can be accomplished at one of multiple layers up a > stack in a device, and if DHCP addresses this, then SIP isn't > needed for this UA (to learn the URIs). If DHCP doesn't address > this, the UA seeks this info via SIP. I believe that providing this information in DHCP has the same utility as providing location information in DHCP. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 13 19:43:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFKR2-00024s-JC; Tue, 13 Sep 2005 19:43:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFKR2-00024n-4F for ecrit@megatron.ietf.org; Tue, 13 Sep 2005 19:43:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10320 for ; Tue, 13 Sep 2005 19:43:28 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFKVV-00072o-Pr for ecrit@ietf.org; Tue, 13 Sep 2005 19:48:11 -0400 Received: from [10.0.1.100] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 13 Sep 2005 19:43:25 -0400 id 000C7E83.4327641D.00000897 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4503@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C4503@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <180B757E-DCA0-4D8C-B0C3-C23ACAB3D353@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Emergency [VPN issue] Date: Tue, 13 Sep 2005 19:43:23 -0400 To: Stastny Richard X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 13, 2005, at 4:26 PM, Stastny Richard wrote: > I am not the expert here, and maybe I am naive, Don't sell yourself short, Richard. I think you have it exactly right. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 13 19:47:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFKUi-00038a-Jg; Tue, 13 Sep 2005 19:47:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFKUh-00038U-PM for ecrit@megatron.ietf.org; Tue, 13 Sep 2005 19:47:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10428 for ; Tue, 13 Sep 2005 19:47:15 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFKZA-00076m-EB for ecrit@ietf.org; Tue, 13 Sep 2005 19:51:58 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Sep 2005 18:47:03 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 13 Sep 2005 18:47:03 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Sep 2005 18:47:01 -0500 Message-ID: From: "Winterbottom, James" To: "Andrew Newton" , "Tschofenig, Hannes" Date: Tue, 13 Sep 2005 18:47:00 -0500 Subject: RE: [Ecrit] terminology MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 13 Sep 2005 23:47:01.0802 (UTC) FILETIME=[700AE8A0:01C5B8BD] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] terminology Thread-Index: AcW4uvCWSOBJMrq5ROWxLcIfRBCiHQAAQjLg X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Andy, As I pointed out before I think that the definitions of IAP, ISP and ASP in your document are misleading. In deployments today an ISP is someone that gives you an IP address and may or may not provide additional services, they often do not provide you connectivity from your house to them, and this is not addressed in your document. The difference between your ASP and ISP definitions is not clear. So I think that I agree with Hannes that these definitions and that perhaps some thrashing out on the list might be appropriate to arrive at a common set of definitions, rather than opposing ones. Cheers James=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Andrew Newton > Sent: Wednesday, 14 September 2005 9:28 AM > To: Tschofenig, Hannes > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] terminology >=20 >=20 > On Sep 13, 2005, at 10:26 AM, Tschofenig, Hannes wrote: >=20 > > hi all, > > > > i have a question regarding the terminology used in: > > http://www.ietf.org/internet-drafts/draft-polk-newton-ecrit-arch- > > conside > > rations-00.txt > > > > the requirements document defines a number of terms. they do not > > seem to > > be sufficient, as it seems. i think it would be useful to fix or to > > enhance the terms in the requirements document as soon as possible. >=20 > Hannes, >=20 > What was your question? >=20 > -andy >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 13 20:32:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFLCl-0007RM-6d; Tue, 13 Sep 2005 20:32:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFLCk-0007RB-Bf for ecrit@megatron.ietf.org; Tue, 13 Sep 2005 20:32:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12041 for ; Tue, 13 Sep 2005 20:32:48 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFLHD-00089c-Dw for ecrit@ietf.org; Tue, 13 Sep 2005 20:37:29 -0400 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 j8E0WaWk028635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Sep 2005 20:32:37 -0400 (EDT) Message-ID: <43276F87.6050806@cs.columbia.edu> Date: Tue, 13 Sep 2005 20:32:07 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] New ID for downloading URIs via DHCP References: <4.3.2.7.2.20050912172801.03247040@email.cisco.com> <4.3.2.7.2.20050912172801.03247040@email.cisco.com> <4.3.2.7.2.20050913110428.02fb29f0@email.cisco.com> In-Reply-To: <4.3.2.7.2.20050913110428.02fb29f0@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 > If DHCP solves this function for the UA, it doesn't need to request the > URIs within SIP messaging. If the UA doesn't get this from DHCP, the UA > knows to request this within SIP messaging. In general, having several ways to do roughly the same thing doesn't seem too helpful. In particular, it isn't always clear what information takes precedence if they contradict each other. I agree that this is a borderline case, but it can also be seen as slippery slope. > OK, so how exactly is a Vonage-type organization to know where my UA is > to give my UA its URI(s), and will a Vonage-type organization know or > have the means to know each URI that can be learned via DHCP wherever a > UA can be? As far as I can tell, all the URIs are (or should be) location-independent. Thus, Vonage can provide those without having to know where the device is located. > In the cases of a network that owns all 7 layers, DHCP is as good a > delivery means as any - and arguably better in the wired/802.11 case of > a home or enterprise/business. In light of Christian Huitema's presentation in the APP area (http://www3.ietf.org/proceedings/05aug/slides/apparea-4/sld1.htm), 802.11 strikes me as particularly bad example. The risk exists for all information conveyed by DHCP, but some information seems particularly vulnerable. Some information pretty much has to be provided locally and, in some cases, can be verified by the user. For example, I would likely get suspicious if my address gets reported as another city, but I have no way of verifying the usefulness of any of the URLs provided by that DHCP server. Even with encrypted information, it then becomes trivial to forge location provisioning servers, mapping servers and the rest. There are clear trade-offs here. DHCP has well-known virtues, but also severe limitations. Burdening it further would seem to require a bit more discussion of the trade-offs and whether, in this case, this is a good one. > But I am right now on a wired connection directly to my DHCP server in > my house. I'm not worried about authentication or encryption. > Enterprises are also in much tighter controlled network infrastructures, > so DHCP messaging is much more limited in distances and exposure. You, as a network expert, can judge your local configuration, but your device is likely to travel (otherwise, the problem isn't too interesting). Do we expect non-expert users to make judgement calls about whether the rogue 802.11 AP and its attached DHCP server in your local Starbucks is trustworthy and flip some kind of switch to disable the DHCP-provided URLs? > This document isn't saying DHCP is better than SIP, just saying this > function can be accomplished at one of multiple layers up a stack in a > device, and if DHCP addresses this, then SIP isn't needed for this UA > (to learn the URIs). If DHCP doesn't address this, the UA seeks this > info via SIP. Among other things, I'm concerned that this ordering is not always appropriate. Another question is whether DHCP, as opposed to some of the zeroconf-style services, wouldn't be more appropriate for higher-level information. Thus, stepping back, this seems to be providing a solution without having fully specified the assumptions and requirements. DHCP may well have a role to play, but this seems like a pretty quick jump. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 14 04:50:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFSyV-0008Pl-97; Wed, 14 Sep 2005 04:50:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFSyT-0008Pg-E3 for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 04:50:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28886 for ; Wed, 14 Sep 2005 04:50:35 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFT32-0003VW-OF for ecrit@ietf.org; Wed, 14 Sep 2005 04:55:21 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j8E8oLKp005267; Wed, 14 Sep 2005 10:50:21 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j8E8oKUG017937; Wed, 14 Sep 2005 10:50:20 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Sep 2005 10:50:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] terminology Date: Wed, 14 Sep 2005 10:50:19 +0200 Message-ID: Thread-Topic: [Ecrit] terminology Thread-Index: AcW4ut1AWElDLlyeQLqCfogkLVqF2QATkokw From: "Tschofenig, Hannes" To: "Andrew Newton" X-OriginalArrivalTime: 14 Sep 2005 08:50:20.0197 (UTC) FILETIME=[56333D50:01C5B909] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi andy,=20 we should make sure that the requirements document contains the terms we = plan to use in the future.=20 as such, we should not introduce terms with a different meaning in = another document.=20 furthermore, if we think that new terms are needed then we should add = them to the requirements document.=20 ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: Andrew Newton [mailto:andy@hxr.us]=20 > Gesendet: Mittwoch, 14. September 2005 01:28 > An: Tschofenig, Hannes > Cc: ecrit@ietf.org > Betreff: Re: [Ecrit] terminology >=20 >=20 >=20 > On Sep 13, 2005, at 10:26 AM, Tschofenig, Hannes wrote: >=20 > > hi all, > > > > i have a question regarding the terminology used in: > > http://www.ietf.org/internet-drafts/draft-polk-newton-ecrit-arch-=20 > > conside > > rations-00.txt > > > > the requirements document defines a number of terms. they do not =20 > > seem to > > be sufficient, as it seems. i think it would be useful to fix or to > > enhance the terms in the requirements document as soon as possible. >=20 > Hannes, >=20 > What was your question? >=20 > -andy >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 14 04:55:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFT3T-0000xG-3z; Wed, 14 Sep 2005 04:55:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFT3R-0000x8-1D for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 04:55:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29007 for ; Wed, 14 Sep 2005 04:55:42 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFT7z-0003cW-DZ for ecrit@ietf.org; Wed, 14 Sep 2005 05:00:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Sep 2005 10:59:17 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4507@oefeg-s04.oefeg.loc> Thread-Topic: Proposal for a new requirement Thread-Index: AcW5CpZ3brve9OHlShKi/InhGJ5YPg== From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Proposal for a new requirement X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Dear all, =20 following the discussion on local access and VPN, I think a new requirement is needed in section 5 "Identifying the caller location" of the req I_D =20 It should go approx like this (the language may need work ;-) =20 Any device potentially be connected to the Internet and used for contacting emergency services MUST be able to store (multiple) retrieved location information and also MUST be able to = provide this location information at any time to requesting applications running n this device. (so it is a function of the OS of the device). The information stored should contain location (civic or geo), time retrieved, source, verification status, etc. The information stored may also contain URIs retrieved for different purposes ... =20 =20 Motivation: Location information may be retrieved by the device from different sources and at different times (e.g. via GPS, RFID, User Input, DHCP and similar protocols, etc.). Some of this information may be already retrieved at or shortly after power-on (without any=20 connection to the Internet yet) and/or at time of (first) connection to an IP-network e.g. retrieve an IP-address. Note: also at this time=20 no connection or no full connection to the Internet may be provided.=20 =20 The location information provided at this first contact at this IP layer MUST be kept, MUST NOT be updated by information provided by later additional IP-layers and may eventually (by mobile devices)=20 be updated underneath later. This location information MUST be = retrievable at any time, even if later an additional IP-layer is established LATER (e.g via an VPN), and the mapping database, the MSAG and also the PSAP in case of an emergency call is contacted via the VPN access. =20 I know this need work feedback welcome =20 Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 14 05:38:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFTih-0002QX-Cn; Wed, 14 Sep 2005 05:38:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFTig-0002QS-Gc for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 05:38:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01227 for ; Wed, 14 Sep 2005 05:38:20 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFTnF-0004px-B0 for ecrit@ietf.org; Wed, 14 Sep 2005 05:43:06 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 04:38:10 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 14 Sep 2005 04:38:10 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 04:38:09 -0500 Message-ID: From: "Winterbottom, James" To: "Stastny Richard" , Date: Wed, 14 Sep 2005 04:38:07 -0500 Subject: RE: [Ecrit] Proposal for a new requirement MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 14 Sep 2005 09:38:09.0421 (UTC) FILETIME=[046413D0:01C5B910] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Proposal for a new requirement Thread-Index: AcW5CpZ3brve9OHlShKi/InhGJ5YPgABQt0g X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Richard, I would prefer that it says that the device stores the location of the device, or a reference to the device's location. It must also stress that when the reference is accessed by an authorized entity that the device's location must be surrendered. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Stastny Richard > Sent: Wednesday, 14 September 2005 6:59 PM > To: ecrit@ietf.org > Subject: [Ecrit] Proposal for a new requirement >=20 > Dear all, >=20 >=20 >=20 > following the discussion on local access and VPN, I think >=20 > a new requirement is needed in section 5 "Identifying >=20 > the caller location" of the req I_D >=20 >=20 >=20 > It should go approx like this (the language may need work ;-) >=20 >=20 >=20 > Any device potentially be connected to the Internet and > used for contacting emergency services MUST be able to store >=20 > (multiple) retrieved location information and also MUST be able to provide > this location information at any time to requesting applications > running n this device. (so it is a function of the OS of the device). >=20 > The information stored should contain location (civic or geo), time > retrieved, source, verification status, etc. The information stored > may also contain URIs retrieved for different purposes ... >=20 >=20 >=20 >=20 >=20 > Motivation: Location information may be retrieved by the device > from different sources and at different times (e.g. via GPS, RFID, >=20 > User Input, DHCP and similar protocols, etc.). Some of this information > may be already retrieved at or shortly after power-on (without any >=20 > connection to the Internet yet) and/or at time of (first) connection >=20 > to an IP-network e.g. retrieve an IP-address. Note: also at this time >=20 > no connection or no full connection to the Internet may be provided. >=20 >=20 >=20 > The location information provided at this first contact at this IP > layer MUST be kept, MUST NOT be updated by information provided by > later additional IP-layers and may eventually (by mobile devices) >=20 > be updated underneath later. This location information MUST be retrievable > at any time, even if later an additional IP-layer is established LATER > (e.g via an VPN), and the mapping database, the MSAG and also the PSAP > in case of an emergency call is contacted via the VPN access. >=20 >=20 >=20 > I know this need work >=20 > feedback welcome >=20 >=20 >=20 > Richard >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 14 07:31:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFVUG-0000hP-H2; Wed, 14 Sep 2005 07:31:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFVUE-0000hK-UH for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 07:31:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04991 for ; Wed, 14 Sep 2005 07:31:33 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFVYn-0007UO-03 for ecrit@ietf.org; Wed, 14 Sep 2005 07:36:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] Proposal for a new requirement Date: Wed, 14 Sep 2005 13:34:58 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C450D@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Proposal for a new requirement Thread-Index: AcW5CpZ3brve9OHlShKi/InhGJ5YPgABQt0gAAPwQuE= From: "Stastny Richard" To: "Winterbottom, James" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi James, =20 so you think the requirement makes sense in principle? =20 >I would prefer that it says that the device stores the location of the >device, or a reference to the device's location =20 Agree, there is some better wording needed that all retrieved locatons, pointers to locations and also eventually retrieved URIs via DHCP (e.g = to mapping DB or PSAP ) need to be stored. =20 >It must also stress that when the reference is accessed by an = authorized entity that the device's location must be surrendered. I do not fully understand this You mean a pointer to location on the device? On the device directly? or via remote access? - I do not think so On the device you may retrieve the pointer as is and then use it to access the LIS if you are authorized so where is the problem? Richard ________________________________ Von: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Gesendet: Mi 14.09.2005 11:38 An: Stastny Richard; ecrit@ietf.org Betreff: RE: [Ecrit] Proposal for a new requirement Hi Richard, I would prefer that it says that the device stores the location of the device, or a reference to the device's location. It must also stress that when the reference is accessed by an authorized entity that the device's location must be surrendered. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Stastny Richard > Sent: Wednesday, 14 September 2005 6:59 PM > To: ecrit@ietf.org > Subject: [Ecrit] Proposal for a new requirement > > Dear all, > > > > following the discussion on local access and VPN, I think > > a new requirement is needed in section 5 "Identifying > > the caller location" of the req I_D > > > > It should go approx like this (the language may need work ;-) > > > > Any device potentially be connected to the Internet and > used for contacting emergency services MUST be able to store > > (multiple) retrieved location information and also MUST be able to provide > this location information at any time to requesting applications > running n this device. (so it is a function of the OS of the device). > > The information stored should contain location (civic or geo), time > retrieved, source, verification status, etc. The information stored > may also contain URIs retrieved for different purposes ... > > > > > > Motivation: Location information may be retrieved by the device > from different sources and at different times (e.g. via GPS, RFID, > > User Input, DHCP and similar protocols, etc.). Some of this information > may be already retrieved at or shortly after power-on (without any > > connection to the Internet yet) and/or at time of (first) connection > > to an IP-network e.g. retrieve an IP-address. Note: also at this time > > no connection or no full connection to the Internet may be provided. > > > > The location information provided at this first contact at this IP > layer MUST be kept, MUST NOT be updated by information provided by > later additional IP-layers and may eventually (by mobile devices) > > be updated underneath later. This location information MUST be retrievable > at any time, even if later an additional IP-layer is established LATER > (e.g via an VPN), and the mapping database, the MSAG and also the PSAP > in case of an emergency call is contacted via the VPN access. > > > > I know this need work > > feedback welcome > > > > Richard > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit -------------------------------------------------------------------------= ----------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information.=20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. -------------------------------------------------------------------------= ----------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 14 07:58:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFVtr-0006So-Nr; Wed, 14 Sep 2005 07:58:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFVtq-0006Si-K1 for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 07:58:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05957 for ; Wed, 14 Sep 2005 07:58:01 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFVyQ-0008CX-7t for ecrit@ietf.org; Wed, 14 Sep 2005 08:02:46 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 06:57:49 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 14 Sep 2005 06:57:49 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 06:57:49 -0500 Message-ID: From: "Winterbottom, James" To: "Stastny Richard" , Date: Wed, 14 Sep 2005 06:57:48 -0500 Subject: RE: [Ecrit] Proposal for a new requirement MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 14 Sep 2005 11:57:49.0827 (UTC) FILETIME=[87808D30:01C5B923] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Proposal for a new requirement Thread-Index: AcW5CpZ3brve9OHlShKi/InhGJ5YPgABQt0gAAPwQuEAAQOUIA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yes the last bit. If you are authorized to get the location form the LIS using a LIS then the LIS has to give it to you. I think that the requirement makes sense. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, 14 September 2005 9:35 PM > To: Winterbottom, James; ecrit@ietf.org > Subject: Re: [Ecrit] Proposal for a new requirement >=20 > Hi James, >=20 > so you think the requirement makes sense in principle? >=20 > >I would prefer that it says that the device stores the location of the > >device, or a reference to the device's location >=20 > Agree, there is some better wording needed that all retrieved locatons, > pointers to locations and also eventually retrieved URIs via DHCP (e.g to > mapping DB > or PSAP ) need to be stored. >=20 > >It must also stress that when the reference is accessed by an authorized > entity that the device's location must be surrendered. >=20 > I do not fully understand this >=20 > You mean a pointer to location on the device? > On the device directly? or via remote access? - I do not think so > On the device you may retrieve the pointer as is > and then use it to access the LIS if you are authorized > so where is the problem? >=20 > Richard >=20 >=20 > ________________________________ >=20 > Von: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Gesendet: Mi 14.09.2005 11:38 > An: Stastny Richard; ecrit@ietf.org > Betreff: RE: [Ecrit] Proposal for a new requirement >=20 >=20 >=20 > Hi Richard, >=20 > I would prefer that it says that the device stores the location of the > device, or a reference to the device's location. >=20 > It must also stress that when the reference is accessed by an authorized > entity that the device's location must be surrendered. >=20 > Cheers > James >=20 >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Stastny Richard > > Sent: Wednesday, 14 September 2005 6:59 PM > > To: ecrit@ietf.org > > Subject: [Ecrit] Proposal for a new requirement > > > > Dear all, > > > > > > > > following the discussion on local access and VPN, I think > > > > a new requirement is needed in section 5 "Identifying > > > > the caller location" of the req I_D > > > > > > > > It should go approx like this (the language may need work ;-) > > > > > > > > Any device potentially be connected to the Internet and > > used for contacting emergency services MUST be able to store > > > > (multiple) retrieved location information and also MUST be able to > provide > > this location information at any time to requesting applications > > running n this device. (so it is a function of the OS of the device). > > > > The information stored should contain location (civic or geo), time > > retrieved, source, verification status, etc. The information stored > > may also contain URIs retrieved for different purposes ... > > > > > > > > > > > > Motivation: Location information may be retrieved by the device > > from different sources and at different times (e.g. via GPS, RFID, > > > > User Input, DHCP and similar protocols, etc.). Some of this > information > > may be already retrieved at or shortly after power-on (without any > > > > connection to the Internet yet) and/or at time of (first) connection > > > > to an IP-network e.g. retrieve an IP-address. Note: also at this time > > > > no connection or no full connection to the Internet may be provided. > > > > > > > > The location information provided at this first contact at this IP > > layer MUST be kept, MUST NOT be updated by information provided by > > later additional IP-layers and may eventually (by mobile devices) > > > > be updated underneath later. This location information MUST be > retrievable > > at any time, even if later an additional IP-layer is established LATER > > (e.g via an VPN), and the mapping database, the MSAG and also the PSAP > > in case of an emergency call is contacted via the VPN access. > > > > > > > > I know this need work > > > > feedback welcome > > > > > > > > Richard > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 > ------------------------------------------------------------------------ -- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > ---------------------- > [mf2] >=20 >=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 14 08:05:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFW12-0000BG-Dz; Wed, 14 Sep 2005 08:05:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFW11-0000BB-0D for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 08:05:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06642 for ; Wed, 14 Sep 2005 08:05:25 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFW5b-0008Tn-7j for ecrit@ietf.org; Wed, 14 Sep 2005 08:10:12 -0400 Received: from [10.0.1.100] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 14 Sep 2005 08:05:21 -0400 id 000C7C27.43281201.00001E18 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <678D2B94-398B-4782-8BCD-386D9B3A9CB3@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: AW: [Ecrit] terminology Date: Wed, 14 Sep 2005 08:05:08 -0400 To: "Tschofenig, Hannes" X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 14, 2005, at 4:50 AM, Tschofenig, Hannes wrote: > we should make sure that the requirements document contains the > terms we plan to use in the future. > as such, we should not introduce terms with a different meaning in > another document. > furthermore, if we think that new terms are needed then we should > add them to the requirements document. Understood. I'll talk to James about it. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 14 08:48:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFWge-0000qL-4V; Wed, 14 Sep 2005 08:48:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFWgc-0000qD-BF; Wed, 14 Sep 2005 08:48:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08179; Wed, 14 Sep 2005 08:48:24 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFWlC-0000w1-PJ; Wed, 14 Sep 2005 08:53:12 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 14 Sep 2005 05:48:14 -0700 X-IronPort-AV: i="3.97,109,1125903600"; d="scan'208"; a="341558829:sNHT29746328" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8ECm450028764; Wed, 14 Sep 2005 05:48:11 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 05:48:08 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 05:48:08 -0700 From: "Marc Linsner" To: "'James M. Polk'" Date: Wed, 14 Sep 2005 08:48:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW5KorsmQH2Zt7mSeGHMUYjwmQSmw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 14 Sep 2005 12:48:08.0502 (UTC) FILETIME=[8EC5CD60:01C5B92A] X-Spam-Score: 1.1 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, 'ECRIT' Subject: [Ecrit] draft-polk-dhc-uri-00 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 James, Would you please provide the basis for your text below regarding the timing of psap determination, I can't seem to match it up with any of the requirements within ecrit or geopriv. "One example of this URI download would be one specifically for the SIP or SIPS URI of the appropriate Public Safety Answer Point (PSAP) for the client when the user of that client calls for emergency help (911 or 112-type of help). This is not a transaction that should take place when a voice application wants to make such a critical call set-up. It is more appropriate that this information be downloaded to the client when the voice (or other) application boots up in case it is needed at a later time." Thanks, -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 14 09:07:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFWyp-0005rs-HT; Wed, 14 Sep 2005 09:07:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFWyj-0005qX-IT; Wed, 14 Sep 2005 09:07:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09286; Wed, 14 Sep 2005 09:07:07 -0400 (EDT) Message-Id: <200509141307.JAA09286@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFX3K-0001Se-8V; Wed, 14 Sep 2005 09:11:55 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EFWyT-0005ii-SW; Wed, 14 Sep 2005 08:06:54 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , "'James M. Polk'" Subject: RE: [Ecrit] draft-polk-dhc-uri-00 Date: Wed, 14 Sep 2005 09:06:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW5KorsmQH2Zt7mSeGHMUYjwmQSmwAAZvCA 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: dhcwg@ietf.org, 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I've previously argued that while getting it when you boot (i.e. run DHCP) is a good idea, it would be best if you did the mapping from location to URI just before the call, because, due to failures or other disaster related effects, the mapping may have changed. It IS a transaction you want to do when you want to make a call setup, because you want the most recent data. You also want to make certain that you refresh this data periodically. Daily is probably the minimum, and you know that some DHCP lease times are on the order of weeks. So, I would like this wording significantly changed. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Wednesday, September 14, 2005 8:48 AM To: 'James M. Polk' Cc: dhcwg@ietf.org; 'ECRIT' Subject: [Ecrit] draft-polk-dhc-uri-00 James, Would you please provide the basis for your text below regarding the timing of psap determination, I can't seem to match it up with any of the requirements within ecrit or geopriv. "One example of this URI download would be one specifically for the SIP or SIPS URI of the appropriate Public Safety Answer Point (PSAP) for the client when the user of that client calls for emergency help (911 or 112-type of help). This is not a transaction that should take place when a voice application wants to make such a critical call set-up. It is more appropriate that this information be downloaded to the client when the voice (or other) application boots up in case it is needed at a later time." Thanks, -Marc- _______________________________________________ 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 Sep 14 09:46:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFXbG-0006b2-Kn; Wed, 14 Sep 2005 09:46:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFXbE-0006ao-Ib; Wed, 14 Sep 2005 09:46:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11377; Wed, 14 Sep 2005 09:46:53 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFXfn-0002Ou-F5; Wed, 14 Sep 2005 09:51:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] draft-polk-dhc-uri-00 Date: Wed, 14 Sep 2005 15:50:21 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B213B@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] draft-polk-dhc-uri-00 Thread-Index: AcW5KorsmQH2Zt7mSeGHMUYjwmQSmwAAZvCAAAFlANA= From: "Stastny Richard" To: , "Marc Linsner" , "James M. Polk" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, good you brought this up: > ...because, due to failures or other disaster related > effects, the mapping may have changed. It IS a transaction you want to do > when you want to make a call setup, because you want the most recent data. You may add organisational changes. This implies that there MUST be an authoritative source for the PSAP URI - and this can only be the mapping database (LCMS) and there MUST also be defined a TTL for the PSAP URI. 1. for the mapping database itself, if caches are used (e.g. if it is DNS-based) and=20 2. for all other "caches". Any PSAP URI for a given location out of the mapping database is in principle a "cached" information. If the URI is provided say by DHCP from the box responsible to provide the IP-address, the box itself has to go back and query the mapping database periodically to update his information. It then MUST set the TTL (lease-time) appropriately that the information is distributed further in a timely manner. Richard > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Wednesday, September 14, 2005 3:07 PM > To: 'Marc Linsner'; 'James M. Polk' > Cc: dhcwg@ietf.org; 'ECRIT' > Subject: RE: [Ecrit] draft-polk-dhc-uri-00 >=20 > I've previously argued that while getting it when you boot (i.e. run DHCP) > is a good idea, it would be best if you did the mapping from location to > URI > just before the call, because, due to failures or other disaster related > effects, the mapping may have changed. It IS a transaction you want to do > when you want to make a call setup, because you want the most recent data. >=20 > You also want to make certain that you refresh this data periodically. > Daily is probably the minimum, and you know that some DHCP lease times are > on the order of weeks. >=20 > So, I would like this wording significantly changed. >=20 > Brian >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Marc Linsner > Sent: Wednesday, September 14, 2005 8:48 AM > To: 'James M. Polk' > Cc: dhcwg@ietf.org; 'ECRIT' > Subject: [Ecrit] draft-polk-dhc-uri-00 >=20 > James, >=20 > Would you please provide the basis for your text below regarding the > timing > of psap determination, I can't seem to match it up with any of the > requirements within ecrit or geopriv. >=20 > "One example of this URI download would be one specifically for the SIP or > SIPS URI of the appropriate Public Safety Answer Point (PSAP) for the > client > when the user of that client calls for emergency help (911 or 112-type of > help). This is not a transaction that should take place when a voice > application wants to make such a critical call set-up. It is more > appropriate that this information be downloaded to the client when the > voice > (or other) application boots up in case it is needed at a later time." >=20 > Thanks, >=20 > -Marc- >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 14 11:11:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFYvR-0002Gw-Ix; Wed, 14 Sep 2005 11:11:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFYvQ-0002Go-W4; Wed, 14 Sep 2005 11:11:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16347; Wed, 14 Sep 2005 11:11:50 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFZ01-0004W2-Of; Wed, 14 Sep 2005 11:16:40 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 14 Sep 2005 11:11:42 -0400 X-IronPort-AV: i="3.97,110,1125892800"; d="scan'208"; a="70204832:sNHT30504116" 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 j8EFBARF006716; Wed, 14 Sep 2005 11:11:39 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 11:11:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] draft-polk-dhc-uri-00 Date: Wed, 14 Sep 2005 11:11:37 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E38FA176@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] draft-polk-dhc-uri-00 Thread-Index: AcW5KorsmQH2Zt7mSeGHMUYjwmQSmwAAZvCAAARarBA= From: "Michael Hammer \(mhammer\)" To: , "Marc Linsner \(mlinsner\)" , "James Polk \(jmpolk\)" X-OriginalArrivalTime: 14 Sep 2005 15:11:38.0508 (UTC) FILETIME=[9ABC74C0:01C5B93E] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, First, PSAPs should have operational constraints to migrate operations gracefully so they can not arbitrarily change mappings at a faster pace than say 24 hours. Second, disaster-related effects should be handled by proper high availability design. Non-respone from the primar PSAP URI should result in fail-over to an alternate IP address located in a different geographic area. What is invalid here is not the URI but the underlying PSAP network design. And yes, the client should have some maximum time beyond which it must refresh. But, it might also be more predictable for the voice system if the network managed when the refreshes occurred before the deadline such that there is no avalanche from clients. Thus, clients would always find themselves inside that (24 hour?) window. Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Brian Rosen > Sent: Wednesday, September 14, 2005 9:07 AM > To: Marc Linsner (mlinsner); James Polk (jmpolk) > Cc: dhcwg@ietf.org; 'ECRIT' > Subject: RE: [Ecrit] draft-polk-dhc-uri-00 >=20 > I've previously argued that while getting it when you boot=20 > (i.e. run DHCP) is a good idea, it would be best if you did=20 > the mapping from location to URI just before the call,=20 > because, due to failures or other disaster related effects,=20 > the mapping may have changed. It IS a transaction you want=20 > to do when you want to make a call setup, because you want=20 > the most recent data. >=20 > You also want to make certain that you refresh this data periodically. > Daily is probably the minimum, and you know that some DHCP=20 > lease times are on the order of weeks. >=20 > So, I would like this wording significantly changed. >=20 > Brian >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Marc Linsner > Sent: Wednesday, September 14, 2005 8:48 AM > To: 'James M. Polk' > Cc: dhcwg@ietf.org; 'ECRIT' > Subject: [Ecrit] draft-polk-dhc-uri-00 >=20 > James, >=20 > Would you please provide the basis for your text below=20 > regarding the timing of psap determination, I can't seem to=20 > match it up with any of the requirements within ecrit or geopriv. >=20 > "One example of this URI download would be one specifically=20 > for the SIP or SIPS URI of the appropriate Public Safety=20 > Answer Point (PSAP) for the client when the user of that=20 > client calls for emergency help (911 or 112-type of help). =20 > This is not a transaction that should take place when a voice=20 > application wants to make such a critical call set-up. It is=20 > more appropriate that this information be downloaded to the=20 > client when the voice (or other) application boots up in case=20 > it is needed at a later time." >=20 > Thanks, >=20 > -Marc- >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 14 11:18:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZ1o-0004La-JZ; Wed, 14 Sep 2005 11:18:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZ1l-0004LB-F3 for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 11:18:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16656 for ; Wed, 14 Sep 2005 11:18:22 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFZ6K-0004gq-DB for ecrit@ietf.org; Wed, 14 Sep 2005 11:23:09 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 14 Sep 2005 08:18:12 -0700 X-IronPort-AV: i="3.97,110,1125903600"; d="scan'208"; a="341603310:sNHT37865664" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8EFHo56020176; Wed, 14 Sep 2005 08:18:04 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 11:18:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Emergency [VPN issue] Date: Wed, 14 Sep 2005 11:18:01 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E38FA17F@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Emergency [VPN issue] Thread-Index: AcW3ImXxJWPwSm4aQ/OygmT03A/KHAAAqMAgAB59zEAAEc9C8AAv2h/QAAEMGfAAJVSBIA== From: "Michael Hammer \(mhammer\)" To: , "Rodrig, Benny \(Benny\)" , "Winterbottom, James" , "ECRIT" X-OriginalArrivalTime: 14 Sep 2005 15:18:02.0649 (UTC) FILETIME=[7FB3B890:01C5B93F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79668c4a0135b05f663aafe71bc273fd Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, The question is not "who", but "what". The who (carrier) can be playing a multiplicity of roles. The issue is "what" device is closest to the client terminal and can provide location. The "who" is secondary. Once you pinpoint the access device, who operates that falls out immediately. Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, September 13, 2005 5:32 PM > To: Michael Hammer (mhammer); 'Rodrig, Benny (Benny)';=20 > 'Winterbottom, James'; 'ECRIT' > Subject: RE: [Ecrit] Emergency [VPN issue] >=20 > For the purposes of this discussion, the access data=20 > transport network is responsible for location. The way I=20 > look at it, it's the "last" (or "first" > if you will) mile provider. >=20 > If the length of the network from there is big enough, you=20 > need to add room level location. From a definition=20 > standpoint, it gets sticky. What is the conceptual and=20 > terminology difference from an enterprise with 3 levels of=20 > Ethernet switch, two levels of routing and a VPN, and Marc=20 > Linser's home with one switch, one "home router" and a VPN=20 > tunnel to it. We don't need room level location for the=20 > latter, although we would welcome it. We probably do need=20 > room level location from the former. >=20 > But, who is the "access data transport" network in the former=20 > case? Is it the carrier that serves the HQ location, or the=20 > enterprise itself? >=20 > Brian >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Tuesday, September 13, 2005 5:03 PM > To: br@brianrosen.net; Rodrig, Benny (Benny); Winterbottom,=20 > James; ECRIT > Subject: RE: [Ecrit] Emergency [VPN issue] >=20 > I think this terminology issue has been bounced around the=20 > ITU-T FGNGN quite a bit. I had thought that the discussion=20 > was starting to converge on the idea that there were access=20 > data transport (IP) networks and core data transport (IP)=20 > networks. All the hosts that sit on those networks, such as=20 > voice servers, should focus on using other terms, such as=20 > originating and terminating to describe their relationship to=20 > the user. > Using "access" for a host far removed from the point where=20 > the user accesses the data network is both counter-intuitive=20 > and misleading. > Better to keep the data and application related adjectives=20 > independent. >=20 > my 2 cents, > Mike >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > > Of Brian Rosen > > Sent: Tuesday, September 13, 2005 7:08 AM > > To: 'Rodrig, Benny (Benny)'; 'Winterbottom, James'; 'ECRIT' > > Subject: RE: [Ecrit] Emergency [VPN issue] > >=20 > > Benny > >=20 > > There are some authentication issues with who is the source of=20 > > location information, but in general, I believe the=20 > enterprise IS the=20 > > access provider, it simply has an upstream access provider to it. =20 > > This is not unlike a tier 2 or tier 3 ISP. The point is that if an=20 > > enterprise is large enough, we need it to supply room-level=20 > location,=20 > > and the access network to it cannot do that. In very large=20 > > enterprises, the access provider may only be at the headquarters=20 > > location; remote sites may be served by private networks. In such=20 > > cases we are wholly reliant on the enterprise to provide accurate=20 > > location. > >=20 > > Brian > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > > Of Rodrig, Benny (Benny) > > Sent: Monday, September 12, 2005 9:54 AM > > To: Winterbottom, James; ECRIT > > Subject: RE: [Ecrit] Emergency [VPN issue] > >=20 > > James, > >=20 > > I don't see how the enterprise, even with a VPN policy, can be=20 > > considered an access provider. The concept of the access=20 > provider, as=20 > > opposed to the application service provider, implies some sort of=20 > > locality and hence knowledge of user's location. These do not shift=20 > > from the local Internet access provider to the remote enterprise=20 > > headquarters just because the endpoint is connecting through a VPN. > >=20 > > Benny > >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > > Of Winterbottom, James > > Sent: Sunday, September 11, 2005 7:13 PM > > To: James M. Polk; ECRIT > > Subject: RE: [Ecrit] Emergency [VPN issue] > >=20 > > Hi James, > >=20 > > Actually that is not really the point that I am making. The point I=20 > > was making was that if the enterprise forces its remote=20 > staff to pass=20 > > all traffic through the VPN, including emergency calls, then the=20 > > enterprise is, for all intents and purposes the access=20 > provider, and=20 > > is responsible to ensure that the call will get to where it=20 > needs to=20 > > go. > >=20 > > On the technology front I don't see why a solution shouldn't be=20 > > universal either. Change to soft-phones in firmware or software are=20 > > going to be required to get location, and if I understand=20 > the proposed=20 > > solutions correctly then, determine that the call is an=20 > emergency one=20 > > and provide location also. > > So I don't see that providing split tunneling to cater for this is=20 > > such a big deal. If enterprises elect not to deploy or engage this=20 > > functionality then the point of responsibility is clear. > >=20 > > Cheers > > James > >=20 > > > -----Original Message----- > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > Sent: Monday, 12 September 2005 8:44 AM > > > To: Winterbottom, James; Michael Hammer (mhammer);=20 > Stastny Richard; > > Marc > > > Linsner (mlinsner); ECRIT > > > Subject: RE: [Ecrit] Emergency [VPN issue] > > >=20 > > > James > > >=20 > > > I don't understand the point you're making here. > > >=20 > > > Are you suggesting NENA believes a VPNd phone should not=20 > communicate > > over > > > the VPN when calling ? > > >=20 > > > I don't believe this will be universally available > > >=20 > > > At 06:29 PM 9/8/2005 -0500, Winterbottom, James wrote: > > > >This issue has been discussed in NENA at quite some length. The=20 > > > >consensus that is growing there, and I know that there are some > > people > > > >that still disagree, is that if an enterprise is=20 > prepared to allow > > this > > > >to occur, that the onus is on the enterprise to ensure > > that it works. > > > >This makes the problem a little easier to deal with. > > > > > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On > > Behalf > > > >Of > > > > > Rodrig, Benny (Benny) > > > > > Sent: Friday, 9 September 2005 9:14 AM > > > > > To: Michael Hammer (mhammer); Stastny Richard; Marc Linsner > > > >(mlinsner); > > > > > ECRIT > > > > > Subject: RE: [Ecrit] > > EmergencyContextRoutingofInternetTechnologies- > > > > > ArchitectureConsiderations > > > > > > > > > > Not sure it's always possible for emergency calls to > > not go though > > the > > > > > corporate VPN. For example, the endpoint may have no=20 > means (e.g. > > no > > > >TURN > > > > > server) to establish a session directly through the NAT at the > > > >Backwater > > > > > Inn, in the example below. > > > > > > > > > > Benny > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On > > Behalf > > > > > Of Michael Hammer (mhammer) > > > > > Sent: Thursday, September 08, 2005 6:26 PM > > > > > To: Stastny Richard; Marc Linsner (mlinsner); ECRIT > > > > > Subject: RE: [Ecrit] > > > > > EmergencyContextRoutingofInternetTechnologies-Architecture > > > > > Considerations > > > > > > > > > > Richard, > > > > > > > > > > My original question was about whether a PSAP should > > expect calls > > > > > (signaling and media) to originate from non-local=20 > destinations, > > e.g. > > > > > international, and by inference the need for the PSAPs > > to be able > > to > > > > > make call backs to those locations. If not, then > > perhaps it is a > > DDoS > > > > > clue. > > > > > > > > > > Marc pointed out the VPN possibility. > > > > > > > > > > You seem to suggest that emergency calls should never=20 > go by VPN > > when > > > > > dialed. > > > > > > > > > > So, is the VPN situation a possibility or precluded? > > > > > > > > > > Mike > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > > Sent: Thursday, September 08, 2005 5:58 PM > > > > > > To: Michael Hammer (mhammer); Marc Linsner (mlinsner); ECRIT > > > > > > Subject: Re: [Ecrit] Emergency=20 > > > > > > ContextRoutingofInternetTechnologies-Architecture > > Considerations > > > > > > > > > > > > Sorry, but I am confused with this examples: > > > > > > > > > > > > Somebody sitting say in Chicago should get routed to a local > > PSAP in > > > > > > Chicago, regardless where his provider or sip-server > > is located > > > > > > > > > > > > If he is using a VPN to say a network in Berlin, he=20 > may either > > also > > > > > > get routed by some magic we still have to work out also to a > > PSAP in > > > > > > Chicago, or he is routed wrongly to a PSAP in Berlin. > > > > > > > > > > > > But, the PSAP in Berlin will at least get some > > location and also > > > >some > > > > > > identification from Berlin, at the network, so there is some > > local > > > > > > relationship > > > > > > > > > > > > So what is the point? > > > > > > > > > > > > -richard > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer > > (mhammer) > > > > > > Gesendet: Do 08.09.2005 22:56 > > > > > > An: Marc Linsner (mlinsner); ECRIT > > > > > > Betreff: RE: [Ecrit] Emergency=20 > > > > > > ContextRoutingofInternetTechnologies-Architecture > > Considerations > > > > > > > > > > > > > > > > > > > > > > > > That is certainly possible. I'm trying to get an=20 > idea of the > > > >assumed > > > > > > topology models here. If the call gets dropped,=20 > does the PSAP > > make > > > >an > > > > > > > > > > > "international call" to call back such subscribers?=20 > Could the > > call > > > > > > back number be a number in some Caribbean island that > > happens to > > be > > > >a > > > > > > 9xx equivalent? Could Berlin Ind. send a 3xx=20 > response and say > > drop > > > > > > out of this VPN to make the call? > > > > > > > > > > > > In any case, your example proves the exception, so=20 > likely mine > > was a > > > > > > dead end thought. > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Marc Linsner (mlinsner) > > > > > > > Sent: Thursday, September 08, 2005 4:18 PM > > > > > > > To: Michael Hammer (mhammer); 'ECRIT' > > > > > > > Subject: RE: [Ecrit] Emergency Context=20 > > > > > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > > > How about an employee of Berlin Industries, Inc.=20 > sitting at > > the > > > > > > > Backwater Inn with a full vpn up to their corp. hq > > and calling > > for > > > > > > > help. Wouldn't they look like they were coming=20 > from Berlin > > > > > > (the .ru > > > > > > > domain and IP address would probably be a hint)? Do you > > > > > > want to block > > > > > > > them? > > > > > > > > > > > > > > I certainly think that it is reasonable to raise a > > flag to the > >=20 > > > > > > > calltaker in this situation, but I wouldn't think you want > > > > > > to build a > > > > > > > state machine to simply block such calls. > > > > > > > > > > > > > > Replace Berlin with New Hampshire, New York, Mass........ > > > > > > > > > > > > > > -Marc- > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ecrit-bounces@ietf.org > > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > > Of Michael Hammer (mhammer) > > > > > > > > Sent: Thursday, September 08, 2005 3:12 PM > > > > > > > > To: Ted Hardie; wilcox@e911.psd.state.vt.us; > > > > > > > br@brianrosen.net; Andrew > > > > > > > > Newton; Stastny Richard; ECRIT > > > > > > > > Subject: RE: [Ecrit] Emergency Context=20 > > > > > > > > RoutingofInternetTechnologies-Architecture=20 > Considerations > > > > > > > > > > > > > > > > Ted, > > > > > > > > > > > > > > > > I'm confused. Are calls from Asia or Europe to > > the Vermont > > > > > > > PSAP ever > > > > > > > > legitimate? > > > > > > > > > > > > > > > > Somehow, I can't picture the local sheriff being able to > > > > > > > help someone > > > > > > > > in Berlin. I thought the point of i3 is to > > enable the call > > > > > > > to go to > > > > > > > > the local Berlin Polizei. Put another way, is=20 > it possible > > > > > > > to use the > > > > > > > > local nature of emergency service to protect=20 > agains DDoS? > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: ecrit-bounces@ietf.org > > > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > > > Of Ted Hardie > > > > > > > > > Sent: Thursday, September 08, 2005 1:55 PM > > > > > > > > > To: wilcox@e911.psd.state.vt.us; br@brianrosen.net; > > > > > > > Andrew Newton; > > > > > > > > > Stastny Richard; ECRIT > > > > > > > > > Subject: RE: [Ecrit] Emergency Context Routing=20 > > > > > > > > > ofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > > > > > > > After reading the thread, I wanted to come back > > to Nate's > > > > > > > original > > > > > > > > > concern and call something out: > > > > > > > > > > > > > > > > > > >Here is the PSAP concern: > > > > > > > > > > > > > > > > > > > >An enterprising thief could figure out that=20 > a business > > > > > > > (without an > > > > > > > > > >alarm > > > > > > > > > >system) in Backwater, Vermont is served by a > > PSAP located > > 25 > > > > > > > > > miles away. > > > > > > > > > >If one creates an IP-based denial of service=20 > attack on > > that > > > > > > > > > PSAP then > > > > > > > > > >it is safe to assume that the target of > > opportunity that > > the > > > > > > > > > thief is > > > > > > > > > >looking at in Backwater will not be able to=20 > contact the > > PSAP > > > > > > > > > to summon > > > > > > > > > >help. > > > > > > > > > > > > > > > > > > I'm assuming that the PSAP being 25 miles away means > > > > > > > nothing about > > > > > > > > > where the responders are. The responders in this > > > > > > > instance might be > > > > > > > > > sheriffs, for example, who are stationed nearby, even > > > > > > > > further than 25 > > > > > > > > > miles away, or whose patrol routes mean that their > > distance > > > > > > > > from the > > > > > > > > > target of opportunity is variable. So I think we > > > > > > should cut the > > > > > > > > > distance from this description completely, and > > simply see > > > > > > > > the threat > > > > > > > > > as "If the bad actor can determine which PSAP=20 > serves an > > > > > > > > area in which > > > > > > > > > a target is present, a successful attack on the PSAP > > prevents > > > > > > > > > responses to the target". > > > > > > > > > > > > > > > > > > Does that make sense? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Using PSTN technologies, an enterprising thief could > > create > > > > > > > > > a PSTN DoS > > > > > > > > > >on the PSAP by simply using an auto call > > generator from a > > > > > > > > pay phone > > > > > > > > > >located in the same proximity as the target of > > opportunity > > > > > > > > however, > > > > > > > > > >this would still create a response to the > > general area of > > > > > > > > the crime. > > > > > > > > > > > > > > > > > > There are lots of other kinds of PSTN attacks=20 > here--the > > > > > > > > most commonly > > > > > > > > > portrayed being "cutting the line", which doesn't work > > > > > > > quite as it > > > > > > > > > seems in the movies, but does have some effect. > > > > > > > > > > > > > > > > > > To avoid the locality problem in this attack, the bad > > actor > > > > > > > > can use an > > > > > > > > > accomplice, meat or mechanical, in any other=20 > area served > > by > > > > > > > > the PSAP > > > > > > > > > to do the same thing. This avoids the=20 > response hitting > > > > > > > the general > > > > > > > > > area of the crime. It also has the same > > counter-measure; > > > > > > > > > call-blocking of the attacking phone. This > > counter-measure > > > > > > > > is also > > > > > > > > > relatively easy to accomplish with an=20 > IP-based service, > > > > > > > > provided the > > > > > > > > > attack is coming from a single IP or block. I > > believe the > > > > > > > > problem is > > > > > > > > > harder in the IP case not because the area from > > which the > > > > > > > > attack can > > > > > > > > > originate is larger but because it is easier=20 > to create a > > > > > > > > Distributed > > > > > > > > > Denial of Service, largely because of zombie > > networks and > > > > > > > > IP spoofing. > > > > > > > > > That is, if the attack is coming from Europe while the > > > > > > attack is > > > > > > > > > happening on Backwater, my response is the=20 > same as if it > > > > > > > came from > > > > > > > > > Nearwater, VT: > > > > > > > > > block the attack source. But if it is coming from > > > > > > Europe, Asia, > > > > > > > > > Nearwater, Backwater, and many other points as well, > > > > > > > > attempts to block > > > > > > > > > the attack either requires effectively severing > > connectivity > > > >or > > > > > > > > > maintaining a fair amount of information about > > who at the > > > > > > > IP layer > > > > > > > > > should be talking to this PSAP. We've discussed the > > > > > > > > effectiveness of > > > > > > > > > that in the past. > > > > > > > > > > > > > > > > > > >If I > > > > > > > > > >know the URI of the PSAP, I can now distract it from > > another > > > > > > > > > continent > > > > > > > > > >and do what I would need to do in Backwater and no > > > > > > > > response would be > > > > > > > > > >created in that direction - that is the new > > paradigm with > > > > > > > > > IP. If I know > > > > > > > > > >the boundaries of the Derby PSAP, I could=20 > create a PSTN > > > > > > > based DoS > > > > > > > > > >attack anywhere from within that boundary > > (potentially 50 > > > > > > > > miles from > > > > > > > > > >Island Pond). > > > > > > > > > > > > > > > > > > > >Would this happen? I don't know - I am pretty sure it > > > > > > > > hasn't yet but > > > > > > > > > >assigning a URI to a PSAP opens it up to whole new > > > > > > generation of > > > > > > > > > >"creative thinkers"..... > > > > > > > > > > > > > > > > > > > >Of course we can minimize the impact on the PSAP at a > > > > > > > higher level > > > > > > > > > >gateway by throwing a huge amount of bandwidth > > at it and > > > > > > > > building in > > > > > > > > > >intelligent alternative routing on a robust > > firewall. But > > > > > > > > > that does not > > > > > > > > > >help in the interim between here and there=20 > when someone > > > > > > > gets their > > > > > > > > > >hands on the PSAP boundaries and realizes the attacks > > they > > > > > > > > > can initiate > > > > > > > > > >using the PSTN DoS approach. > > > > > > > > > > > > > > > > > > The problem with the proposed solution, I > > believe, is that > > > > > > > > aggregating > > > > > > > > > the access to a back-to-back user agent or all-knowing > > > > > > > > gateway is that > > > > > > > > > you have simply created a richer target for > > attack. If I > > > > > > > > can marshal > > > > > > > > > a zombie group that takes out all of=20 > Vermont's PSAPs by > > > > > > > eliminating > > > > > > > > > the the gateway by DDoS, I have done far=20 > worse far more > > > > > > > > easily than I > > > > > > > > > could by individually attacking the PSAPs at=20 > their URIs. > > > > > > > > If I did it > > > > > > > > > in order to get at Backwater's target, I likely don't > > > > > > > care that the > > > > > > > > > general effect is larger--my purpose is met. > > > > > > > > > > > > > > > > > > Yes, it is easier to escalate the defenses at a single > > > > > > > > point and yes, > > > > > > > > > it is easier to pay for fat pipes for that > > single point. > > > > > > > > But the bad > > > > > > > > > actors here aren't using their own resources to attack > > you; > > > > > > > > they are > > > > > > > > > stealing them before trying to steal from=20 > you. Getting > > > > > > > > into an arms > > > > > > > > > race with someone who isn't spending their own money > > worries > > > >me. > > > > > > > > > > > > > > > > > > regards, > > > > > > > > > Ted > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > 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 > > > > > > > > > >------------------------------------------------------------- > > ---------- > > -- > > > ----------------------- > > > >This message is for the designated recipient only and=20 > may contain=20 > > > >privileged, proprietary, or otherwise private information. > > > >If you have received it in error, please notify the sender=20 > > > >immediately and delete the original. Any unauthorized=20 > use of this=20 > > > >email is prohibited. > > > > > >------------------------------------------------------------- > > ---------- > > -- > > > ----------------------- > > > >[mf2] > > > > > > > >_______________________________________________ > > > >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=20 > presented. > >=20 > > -------------------------------------------------------------- > > ---------- > > ------------------------ > > This message is for the designated recipient only and may contain=20 > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender=20 > immediately=20 > > and delete the original. Any unauthorized use of this email is=20 > > prohibited. > > -------------------------------------------------------------- > > ---------- > > ------------------------ > > [mf2] > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 14 11:31:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZEf-0007gC-5i; Wed, 14 Sep 2005 11:31:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZEd-0007fr-9n; Wed, 14 Sep 2005 11:31:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17265; Wed, 14 Sep 2005 11:31:40 -0400 (EDT) Message-Id: <200509141531.LAA17265@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFZJG-00052q-0j; Wed, 14 Sep 2005 11:36:30 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EFZEQ-0004qx-BF; Wed, 14 Sep 2005 10:31:30 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Marc Linsner \(mlinsner\)'" , "'James Polk \(jmpolk\)'" Subject: RE: [Ecrit] draft-polk-dhc-uri-00 Date: Wed, 14 Sep 2005 11:29:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E38FA176@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW5KorsmQH2Zt7mSeGHMUYjwmQSmwAAZvCAAARarBAAAJRF8A== 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: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Michael I'm not sure what your experience is. Mine is that disasters don't go according to plan. You plan for disasters, and then you deal with what actually happens. Often, what you thought would work, doesn't. You are making an assumption that the URI you get from mapping is always good for, say, 24 hours, and any problems encountered can be solved by changing the resolution of the URI. I'm not so sure. Maybe we do want all calls that were going to a specific URI to go somewhere else. Maybe we want to change routing of some of them. Maybe we are unable, for some reason, to change the resolution of the URI. It's probably true that a 24 hour old mapping will work in most cases. I'm pretty unhappy with "probably" and "most", because of the consequences of getting wrong and the uncertainty of being able to manipulate a limited number of levers when lots of infrastructure is failing. This whole subject is about probabilities of getting the right thing to happen, and I think we should take every opportunity to improve the odds. Brian -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Wednesday, September 14, 2005 11:12 AM To: br@brianrosen.net; Marc Linsner (mlinsner); James Polk (jmpolk) Cc: dhcwg@ietf.org; ECRIT Subject: RE: [Ecrit] draft-polk-dhc-uri-00 Brian, First, PSAPs should have operational constraints to migrate operations gracefully so they can not arbitrarily change mappings at a faster pace than say 24 hours. Second, disaster-related effects should be handled by proper high availability design. Non-respone from the primar PSAP URI should result in fail-over to an alternate IP address located in a different geographic area. What is invalid here is not the URI but the underlying PSAP network design. And yes, the client should have some maximum time beyond which it must refresh. But, it might also be more predictable for the voice system if the network managed when the refreshes occurred before the deadline such that there is no avalanche from clients. Thus, clients would always find themselves inside that (24 hour?) window. Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Wednesday, September 14, 2005 9:07 AM > To: Marc Linsner (mlinsner); James Polk (jmpolk) > Cc: dhcwg@ietf.org; 'ECRIT' > Subject: RE: [Ecrit] draft-polk-dhc-uri-00 > > I've previously argued that while getting it when you boot > (i.e. run DHCP) is a good idea, it would be best if you did > the mapping from location to URI just before the call, > because, due to failures or other disaster related effects, > the mapping may have changed. It IS a transaction you want > to do when you want to make a call setup, because you want > the most recent data. > > You also want to make certain that you refresh this data periodically. > Daily is probably the minimum, and you know that some DHCP > lease times are on the order of weeks. > > So, I would like this wording significantly changed. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Marc Linsner > Sent: Wednesday, September 14, 2005 8:48 AM > To: 'James M. Polk' > Cc: dhcwg@ietf.org; 'ECRIT' > Subject: [Ecrit] draft-polk-dhc-uri-00 > > James, > > Would you please provide the basis for your text below > regarding the timing of psap determination, I can't seem to > match it up with any of the requirements within ecrit or geopriv. > > "One example of this URI download would be one specifically > for the SIP or SIPS URI of the appropriate Public Safety > Answer Point (PSAP) for the client when the user of that > client calls for emergency help (911 or 112-type of help). > This is not a transaction that should take place when a voice > application wants to make such a critical call set-up. It is > more appropriate that this information be downloaded to the > client when the voice (or other) application boots up in case > it is needed at a later time." > > Thanks, > > -Marc- > > > _______________________________________________ > 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 Sep 14 11:37:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZKQ-0000Xt-JJ; Wed, 14 Sep 2005 11:37:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZKO-0000VB-EJ for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 11:37:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17455 for ; Wed, 14 Sep 2005 11:37:37 -0400 (EDT) Message-Id: <200509141537.LAA17455@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFZP0-0005BG-ST for ecrit@ietf.org; Wed, 14 Sep 2005 11:42:27 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EFZK7-00056Y-Sk; Wed, 14 Sep 2005 10:37:25 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Rodrig, Benny \(Benny\)'" , "'Winterbottom, James'" , "'ECRIT'" Subject: RE: [Ecrit] Emergency [VPN issue] Date: Wed, 14 Sep 2005 11:35:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E38FA17F@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW3ImXxJWPwSm4aQ/OygmT03A/KHAAAqMAgAB59zEAAEc9C8AAv2h/QAAEMGfAAJVSBIAAAfvCg 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: d115f8e98afb84ba4860c5c6ee611921 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Okay, then: You look at the length of the "loop" (wire or radio). Starting at the end device, you look for the first one longer than some threshold. It's circa several thousand feet. The device on the far (with respect to the endpoint) device is responsible for location, unless the device contains some kind of measurement capability (GPS, triangulation,....) in which case it's the device who is responsible, OR there is some other measurement mechanism that the device does not control, in which case it's the device that does the mechanism which is responsible. How is that? Brian -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Wednesday, September 14, 2005 11:18 AM To: br@brianrosen.net; Rodrig, Benny (Benny); Winterbottom, James; ECRIT Subject: RE: [Ecrit] Emergency [VPN issue] Brian, The question is not "who", but "what". The who (carrier) can be playing a multiplicity of roles. The issue is "what" device is closest to the client terminal and can provide location. The "who" is secondary. Once you pinpoint the access device, who operates that falls out immediately. Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, September 13, 2005 5:32 PM > To: Michael Hammer (mhammer); 'Rodrig, Benny (Benny)'; > 'Winterbottom, James'; 'ECRIT' > Subject: RE: [Ecrit] Emergency [VPN issue] > > For the purposes of this discussion, the access data > transport network is responsible for location. The way I > look at it, it's the "last" (or "first" > if you will) mile provider. > > If the length of the network from there is big enough, you > need to add room level location. From a definition > standpoint, it gets sticky. What is the conceptual and > terminology difference from an enterprise with 3 levels of > Ethernet switch, two levels of routing and a VPN, and Marc > Linser's home with one switch, one "home router" and a VPN > tunnel to it. We don't need room level location for the > latter, although we would welcome it. We probably do need > room level location from the former. > > But, who is the "access data transport" network in the former > case? Is it the carrier that serves the HQ location, or the > enterprise itself? > > Brian > > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Tuesday, September 13, 2005 5:03 PM > To: br@brianrosen.net; Rodrig, Benny (Benny); Winterbottom, > James; ECRIT > Subject: RE: [Ecrit] Emergency [VPN issue] > > I think this terminology issue has been bounced around the > ITU-T FGNGN quite a bit. I had thought that the discussion > was starting to converge on the idea that there were access > data transport (IP) networks and core data transport (IP) > networks. All the hosts that sit on those networks, such as > voice servers, should focus on using other terms, such as > originating and terminating to describe their relationship to > the user. > Using "access" for a host far removed from the point where > the user accesses the data network is both counter-intuitive > and misleading. > Better to keep the data and application related adjectives > independent. > > my 2 cents, > Mike > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Brian Rosen > > Sent: Tuesday, September 13, 2005 7:08 AM > > To: 'Rodrig, Benny (Benny)'; 'Winterbottom, James'; 'ECRIT' > > Subject: RE: [Ecrit] Emergency [VPN issue] > > > > Benny > > > > There are some authentication issues with who is the source of > > location information, but in general, I believe the > enterprise IS the > > access provider, it simply has an upstream access provider to it. > > This is not unlike a tier 2 or tier 3 ISP. The point is that if an > > enterprise is large enough, we need it to supply room-level > location, > > and the access network to it cannot do that. In very large > > enterprises, the access provider may only be at the headquarters > > location; remote sites may be served by private networks. In such > > cases we are wholly reliant on the enterprise to provide accurate > > location. > > > > Brian > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Rodrig, Benny (Benny) > > Sent: Monday, September 12, 2005 9:54 AM > > To: Winterbottom, James; ECRIT > > Subject: RE: [Ecrit] Emergency [VPN issue] > > > > James, > > > > I don't see how the enterprise, even with a VPN policy, can be > > considered an access provider. The concept of the access > provider, as > > opposed to the application service provider, implies some sort of > > locality and hence knowledge of user's location. These do not shift > > from the local Internet access provider to the remote enterprise > > headquarters just because the endpoint is connecting through a VPN. > > > > Benny > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Winterbottom, James > > Sent: Sunday, September 11, 2005 7:13 PM > > To: James M. Polk; ECRIT > > Subject: RE: [Ecrit] Emergency [VPN issue] > > > > Hi James, > > > > Actually that is not really the point that I am making. The point I > > was making was that if the enterprise forces its remote > staff to pass > > all traffic through the VPN, including emergency calls, then the > > enterprise is, for all intents and purposes the access > provider, and > > is responsible to ensure that the call will get to where it > needs to > > go. > > > > On the technology front I don't see why a solution shouldn't be > > universal either. Change to soft-phones in firmware or software are > > going to be required to get location, and if I understand > the proposed > > solutions correctly then, determine that the call is an > emergency one > > and provide location also. > > So I don't see that providing split tunneling to cater for this is > > such a big deal. If enterprises elect not to deploy or engage this > > functionality then the point of responsibility is clear. > > > > Cheers > > James > > > > > -----Original Message----- > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > Sent: Monday, 12 September 2005 8:44 AM > > > To: Winterbottom, James; Michael Hammer (mhammer); > Stastny Richard; > > Marc > > > Linsner (mlinsner); ECRIT > > > Subject: RE: [Ecrit] Emergency [VPN issue] > > > > > > James > > > > > > I don't understand the point you're making here. > > > > > > Are you suggesting NENA believes a VPNd phone should not > communicate > > over > > > the VPN when calling ? > > > > > > I don't believe this will be universally available > > > > > > At 06:29 PM 9/8/2005 -0500, Winterbottom, James wrote: > > > >This issue has been discussed in NENA at quite some length. The > > > >consensus that is growing there, and I know that there are some > > people > > > >that still disagree, is that if an enterprise is > prepared to allow > > this > > > >to occur, that the onus is on the enterprise to ensure > > that it works. > > > >This makes the problem a little easier to deal with. > > > > > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On > > Behalf > > > >Of > > > > > Rodrig, Benny (Benny) > > > > > Sent: Friday, 9 September 2005 9:14 AM > > > > > To: Michael Hammer (mhammer); Stastny Richard; Marc Linsner > > > >(mlinsner); > > > > > ECRIT > > > > > Subject: RE: [Ecrit] > > EmergencyContextRoutingofInternetTechnologies- > > > > > ArchitectureConsiderations > > > > > > > > > > Not sure it's always possible for emergency calls to > > not go though > > the > > > > > corporate VPN. For example, the endpoint may have no > means (e.g. > > no > > > >TURN > > > > > server) to establish a session directly through the NAT at the > > > >Backwater > > > > > Inn, in the example below. > > > > > > > > > > Benny > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On > > Behalf > > > > > Of Michael Hammer (mhammer) > > > > > Sent: Thursday, September 08, 2005 6:26 PM > > > > > To: Stastny Richard; Marc Linsner (mlinsner); ECRIT > > > > > Subject: RE: [Ecrit] > > > > > EmergencyContextRoutingofInternetTechnologies-Architecture > > > > > Considerations > > > > > > > > > > Richard, > > > > > > > > > > My original question was about whether a PSAP should > > expect calls > > > > > (signaling and media) to originate from non-local > destinations, > > e.g. > > > > > international, and by inference the need for the PSAPs > > to be able > > to > > > > > make call backs to those locations. If not, then > > perhaps it is a > > DDoS > > > > > clue. > > > > > > > > > > Marc pointed out the VPN possibility. > > > > > > > > > > You seem to suggest that emergency calls should never > go by VPN > > when > > > > > dialed. > > > > > > > > > > So, is the VPN situation a possibility or precluded? > > > > > > > > > > Mike > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > > Sent: Thursday, September 08, 2005 5:58 PM > > > > > > To: Michael Hammer (mhammer); Marc Linsner (mlinsner); ECRIT > > > > > > Subject: Re: [Ecrit] Emergency > > > > > > ContextRoutingofInternetTechnologies-Architecture > > Considerations > > > > > > > > > > > > Sorry, but I am confused with this examples: > > > > > > > > > > > > Somebody sitting say in Chicago should get routed to a local > > PSAP in > > > > > > Chicago, regardless where his provider or sip-server > > is located > > > > > > > > > > > > If he is using a VPN to say a network in Berlin, he > may either > > also > > > > > > get routed by some magic we still have to work out also to a > > PSAP in > > > > > > Chicago, or he is routed wrongly to a PSAP in Berlin. > > > > > > > > > > > > But, the PSAP in Berlin will at least get some > > location and also > > > >some > > > > > > identification from Berlin, at the network, so there is some > > local > > > > > > relationship > > > > > > > > > > > > So what is the point? > > > > > > > > > > > > -richard > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > Von: ecrit-bounces@ietf.org im Auftrag von Michael Hammer > > (mhammer) > > > > > > Gesendet: Do 08.09.2005 22:56 > > > > > > An: Marc Linsner (mlinsner); ECRIT > > > > > > Betreff: RE: [Ecrit] Emergency > > > > > > ContextRoutingofInternetTechnologies-Architecture > > Considerations > > > > > > > > > > > > > > > > > > > > > > > > That is certainly possible. I'm trying to get an > idea of the > > > >assumed > > > > > > topology models here. If the call gets dropped, > does the PSAP > > make > > > >an > > > > > > > > > > > "international call" to call back such subscribers? > Could the > > call > > > > > > back number be a number in some Caribbean island that > > happens to > > be > > > >a > > > > > > 9xx equivalent? Could Berlin Ind. send a 3xx > response and say > > drop > > > > > > out of this VPN to make the call? > > > > > > > > > > > > In any case, your example proves the exception, so > likely mine > > was a > > > > > > dead end thought. > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Marc Linsner (mlinsner) > > > > > > > Sent: Thursday, September 08, 2005 4:18 PM > > > > > > > To: Michael Hammer (mhammer); 'ECRIT' > > > > > > > Subject: RE: [Ecrit] Emergency Context > > > > > > > RoutingofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > > > How about an employee of Berlin Industries, Inc. > sitting at > > the > > > > > > > Backwater Inn with a full vpn up to their corp. hq > > and calling > > for > > > > > > > help. Wouldn't they look like they were coming > from Berlin > > > > > > (the .ru > > > > > > > domain and IP address would probably be a hint)? Do you > > > > > > want to block > > > > > > > them? > > > > > > > > > > > > > > I certainly think that it is reasonable to raise a > > flag to the > > > > > > > > > calltaker in this situation, but I wouldn't think you want > > > > > > to build a > > > > > > > state machine to simply block such calls. > > > > > > > > > > > > > > Replace Berlin with New Hampshire, New York, Mass........ > > > > > > > > > > > > > > -Marc- > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ecrit-bounces@ietf.org > > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > > Of Michael Hammer (mhammer) > > > > > > > > Sent: Thursday, September 08, 2005 3:12 PM > > > > > > > > To: Ted Hardie; wilcox@e911.psd.state.vt.us; > > > > > > > br@brianrosen.net; Andrew > > > > > > > > Newton; Stastny Richard; ECRIT > > > > > > > > Subject: RE: [Ecrit] Emergency Context > > > > > > > > RoutingofInternetTechnologies-Architecture > Considerations > > > > > > > > > > > > > > > > Ted, > > > > > > > > > > > > > > > > I'm confused. Are calls from Asia or Europe to > > the Vermont > > > > > > > PSAP ever > > > > > > > > legitimate? > > > > > > > > > > > > > > > > Somehow, I can't picture the local sheriff being able to > > > > > > > help someone > > > > > > > > in Berlin. I thought the point of i3 is to > > enable the call > > > > > > > to go to > > > > > > > > the local Berlin Polizei. Put another way, is > it possible > > > > > > > to use the > > > > > > > > local nature of emergency service to protect > agains DDoS? > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: ecrit-bounces@ietf.org > > > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > > > Of Ted Hardie > > > > > > > > > Sent: Thursday, September 08, 2005 1:55 PM > > > > > > > > > To: wilcox@e911.psd.state.vt.us; br@brianrosen.net; > > > > > > > Andrew Newton; > > > > > > > > > Stastny Richard; ECRIT > > > > > > > > > Subject: RE: [Ecrit] Emergency Context Routing > > > > > > > > > ofInternetTechnologies-Architecture Considerations > > > > > > > > > > > > > > > > > > After reading the thread, I wanted to come back > > to Nate's > > > > > > > original > > > > > > > > > concern and call something out: > > > > > > > > > > > > > > > > > > >Here is the PSAP concern: > > > > > > > > > > > > > > > > > > > >An enterprising thief could figure out that > a business > > > > > > > (without an > > > > > > > > > >alarm > > > > > > > > > >system) in Backwater, Vermont is served by a > > PSAP located > > 25 > > > > > > > > > miles away. > > > > > > > > > >If one creates an IP-based denial of service > attack on > > that > > > > > > > > > PSAP then > > > > > > > > > >it is safe to assume that the target of > > opportunity that > > the > > > > > > > > > thief is > > > > > > > > > >looking at in Backwater will not be able to > contact the > > PSAP > > > > > > > > > to summon > > > > > > > > > >help. > > > > > > > > > > > > > > > > > > I'm assuming that the PSAP being 25 miles away means > > > > > > > nothing about > > > > > > > > > where the responders are. The responders in this > > > > > > > instance might be > > > > > > > > > sheriffs, for example, who are stationed nearby, even > > > > > > > > further than 25 > > > > > > > > > miles away, or whose patrol routes mean that their > > distance > > > > > > > > from the > > > > > > > > > target of opportunity is variable. So I think we > > > > > > should cut the > > > > > > > > > distance from this description completely, and > > simply see > > > > > > > > the threat > > > > > > > > > as "If the bad actor can determine which PSAP > serves an > > > > > > > > area in which > > > > > > > > > a target is present, a successful attack on the PSAP > > prevents > > > > > > > > > responses to the target". > > > > > > > > > > > > > > > > > > Does that make sense? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Using PSTN technologies, an enterprising thief could > > create > > > > > > > > > a PSTN DoS > > > > > > > > > >on the PSAP by simply using an auto call > > generator from a > > > > > > > > pay phone > > > > > > > > > >located in the same proximity as the target of > > opportunity > > > > > > > > however, > > > > > > > > > >this would still create a response to the > > general area of > > > > > > > > the crime. > > > > > > > > > > > > > > > > > > There are lots of other kinds of PSTN attacks > here--the > > > > > > > > most commonly > > > > > > > > > portrayed being "cutting the line", which doesn't work > > > > > > > quite as it > > > > > > > > > seems in the movies, but does have some effect. > > > > > > > > > > > > > > > > > > To avoid the locality problem in this attack, the bad > > actor > > > > > > > > can use an > > > > > > > > > accomplice, meat or mechanical, in any other > area served > > by > > > > > > > > the PSAP > > > > > > > > > to do the same thing. This avoids the > response hitting > > > > > > > the general > > > > > > > > > area of the crime. It also has the same > > counter-measure; > > > > > > > > > call-blocking of the attacking phone. This > > counter-measure > > > > > > > > is also > > > > > > > > > relatively easy to accomplish with an > IP-based service, > > > > > > > > provided the > > > > > > > > > attack is coming from a single IP or block. I > > believe the > > > > > > > > problem is > > > > > > > > > harder in the IP case not because the area from > > which the > > > > > > > > attack can > > > > > > > > > originate is larger but because it is easier > to create a > > > > > > > > Distributed > > > > > > > > > Denial of Service, largely because of zombie > > networks and > > > > > > > > IP spoofing. > > > > > > > > > That is, if the attack is coming from Europe while the > > > > > > attack is > > > > > > > > > happening on Backwater, my response is the > same as if it > > > > > > > came from > > > > > > > > > Nearwater, VT: > > > > > > > > > block the attack source. But if it is coming from > > > > > > Europe, Asia, > > > > > > > > > Nearwater, Backwater, and many other points as well, > > > > > > > > attempts to block > > > > > > > > > the attack either requires effectively severing > > connectivity > > > >or > > > > > > > > > maintaining a fair amount of information about > > who at the > > > > > > > IP layer > > > > > > > > > should be talking to this PSAP. We've discussed the > > > > > > > > effectiveness of > > > > > > > > > that in the past. > > > > > > > > > > > > > > > > > > >If I > > > > > > > > > >know the URI of the PSAP, I can now distract it from > > another > > > > > > > > > continent > > > > > > > > > >and do what I would need to do in Backwater and no > > > > > > > > response would be > > > > > > > > > >created in that direction - that is the new > > paradigm with > > > > > > > > > IP. If I know > > > > > > > > > >the boundaries of the Derby PSAP, I could > create a PSTN > > > > > > > based DoS > > > > > > > > > >attack anywhere from within that boundary > > (potentially 50 > > > > > > > > miles from > > > > > > > > > >Island Pond). > > > > > > > > > > > > > > > > > > > >Would this happen? I don't know - I am pretty sure it > > > > > > > > hasn't yet but > > > > > > > > > >assigning a URI to a PSAP opens it up to whole new > > > > > > generation of > > > > > > > > > >"creative thinkers"..... > > > > > > > > > > > > > > > > > > > >Of course we can minimize the impact on the PSAP at a > > > > > > > higher level > > > > > > > > > >gateway by throwing a huge amount of bandwidth > > at it and > > > > > > > > building in > > > > > > > > > >intelligent alternative routing on a robust > > firewall. But > > > > > > > > > that does not > > > > > > > > > >help in the interim between here and there > when someone > > > > > > > gets their > > > > > > > > > >hands on the PSAP boundaries and realizes the attacks > > they > > > > > > > > > can initiate > > > > > > > > > >using the PSTN DoS approach. > > > > > > > > > > > > > > > > > > The problem with the proposed solution, I > > believe, is that > > > > > > > > aggregating > > > > > > > > > the access to a back-to-back user agent or all-knowing > > > > > > > > gateway is that > > > > > > > > > you have simply created a richer target for > > attack. If I > > > > > > > > can marshal > > > > > > > > > a zombie group that takes out all of > Vermont's PSAPs by > > > > > > > eliminating > > > > > > > > > the the gateway by DDoS, I have done far > worse far more > > > > > > > > easily than I > > > > > > > > > could by individually attacking the PSAPs at > their URIs. > > > > > > > > If I did it > > > > > > > > > in order to get at Backwater's target, I likely don't > > > > > > > care that the > > > > > > > > > general effect is larger--my purpose is met. > > > > > > > > > > > > > > > > > > Yes, it is easier to escalate the defenses at a single > > > > > > > > point and yes, > > > > > > > > > it is easier to pay for fat pipes for that > > single point. > > > > > > > > But the bad > > > > > > > > > actors here aren't using their own resources to attack > > you; > > > > > > > > they are > > > > > > > > > stealing them before trying to steal from > you. Getting > > > > > > > > into an arms > > > > > > > > > race with someone who isn't spending their own money > > worries > > > >me. > > > > > > > > > > > > > > > > > > regards, > > > > > > > > > Ted > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > 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 > > > > > > > > > >------------------------------------------------------------- > > ---------- > > -- > > > ----------------------- > > > >This message is for the designated recipient only and > may contain > > > >privileged, proprietary, or otherwise private information. > > > >If you have received it in error, please notify the sender > > > >immediately and delete the original. Any unauthorized > use of this > > > >email is prohibited. > > > > > >------------------------------------------------------------- > > ---------- > > -- > > > ----------------------- > > > >[mf2] > > > > > > > >_______________________________________________ > > > >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. > > > > -------------------------------------------------------------- > > ---------- > > ------------------------ > > This message is for the designated recipient only and may contain > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > immediately > > and delete the original. Any unauthorized use of this email is > > prohibited. > > -------------------------------------------------------------- > > ---------- > > ------------------------ > > [mf2] > > > > _______________________________________________ > > 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 Sep 14 11:47:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZTj-0002qo-RA; Wed, 14 Sep 2005 11:47:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZTg-0002qb-Gy for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 11:47:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17972 for ; Wed, 14 Sep 2005 11:47:13 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFZYI-0005SP-Bh for ecrit@ietf.org; Wed, 14 Sep 2005 11:52:03 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 14 Sep 2005 08:47:05 -0700 X-IronPort-AV: i="3.97,110,1125903600"; d="scan'208"; a="341608579:sNHT30915090" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8EFkOKi020021; Wed, 14 Sep 2005 08:47:03 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 08:47:02 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 08:47:01 -0700 From: "Marc Linsner" To: "'McCalmont, Patti'" , "'ECRIT'" Subject: RE: [Ecrit] Emergency [mapping still needed?] Date: Wed, 14 Sep 2005 11:47:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW3I2XTpRQ5iwQ9TQWh91Yg4gZxJAAcPDAgAAhgD6AAYttJMA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <422D410BD61FC04185076AD99AA7207A010EE800@inilmx01.lgmt.trdo> Message-ID: X-OriginalArrivalTime: 14 Sep 2005 15:47:01.0948 (UTC) FILETIME=[8C67AFC0:01C5B943] X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Patti, > > PLM - Now you have all the security issues with passing > location through the network. You also have the issues around > how to ensure the location is valid and hasn't been altered. > For a very long time there will be phones out there that > aren't capable of storing their own location, yet alone doing > the mapping and addressing security. The hardest part to any > requirements is to support the existing infrastructure along > with what is coming out. I agree that if we all could just > toss in all the old technology and could start out with a > brand new slate that what Brian states is correct. > HOWEVER.....that's not the real world. Location by reference > seems a better path - IMO and HELD looks like it is > attempting to address the new and old world. > 1) There is support for the 'old world' today, location by reference. NENA i2 is based on it. There is no reason to expect that mechanism to disappear. 'Old world' devices have constraints due to architecture, so? Upgrade to a new device and lose constraints. 2) A large portion of 'toss in all the old technology' is simply a software upgrade. Not unsurmountable, it happens all the time. For those that can't upgrade a 'due to new emergency calling requirements, your device will not be supported after ??? date' message to the customer is not unreasonable. 3) The current installed based is no more than a rounding error to the forcasted number of devices. IMO, support of installed devices gets way to high of a priority, it should be a nice-to-have requirement. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 14 11:48:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZV9-0003EU-OT; Wed, 14 Sep 2005 11:48:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZV8-0003EJ-5k; Wed, 14 Sep 2005 11:48:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18114; Wed, 14 Sep 2005 11:48:43 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFZZl-0005WI-3Z; Wed, 14 Sep 2005 11:53:33 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 14 Sep 2005 08:48:36 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,110,1125903600"; d="scan'208"; a="9674554:sNHT25257788" 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 j8EFlxRJ017563; Wed, 14 Sep 2005 11:48:33 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 11:48:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] draft-polk-dhc-uri-00 Date: Wed, 14 Sep 2005 11:48:32 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E38FA1A9@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] draft-polk-dhc-uri-00 Thread-Index: AcW5KorsmQH2Zt7mSeGHMUYjwmQSmwAAZvCAAARarBAAAJRF8AAAlyWw From: "Michael Hammer \(mhammer\)" To: , "Marc Linsner \(mlinsner\)" , "James Polk \(jmpolk\)" X-OriginalArrivalTime: 14 Sep 2005 15:48:32.0913 (UTC) FILETIME=[C29FD810:01C5B943] X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, My early experience is military. You design networks with disaster in mind. You have a plan B... and C, and D, and ... We used to play war games where we would arbitrarily knock out communications sites, and then say, now what? We would do this for single and multiple points of failure. Of course, there is a cost to having backups, but having no plan or backups whatsoever is no plan at all, especially for emergency aid organizations. We have voice features that say, if you ring me in NY and don't get an answer, ring me at this alternate site in Boston, all without changing the called URI. Such capabilities exist at multiple layers of the protocols, we only need to use them. Why would you assume that a PSAP network would not be designed to take advantage of such capabilities? Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Wednesday, September 14, 2005 11:29 AM > To: Michael Hammer (mhammer); Marc Linsner (mlinsner); James=20 > Polk (jmpolk) > Cc: dhcwg@ietf.org; 'ECRIT' > Subject: RE: [Ecrit] draft-polk-dhc-uri-00 >=20 > Michael >=20 > I'm not sure what your experience is. Mine is that disasters=20 > don't go according to plan. You plan for disasters, and then=20 > you deal with what actually happens. Often, what you thought=20 > would work, doesn't. >=20 > You are making an assumption that the URI you get from=20 > mapping is always good for, say, 24 hours, and any problems=20 > encountered can be solved by changing the resolution of the=20 > URI. I'm not so sure. =20 >=20 > Maybe we do want all calls that were going to a specific URI=20 > to go somewhere else. Maybe we want to change routing of=20 > some of them. Maybe we are unable, for some reason, to=20 > change the resolution of the URI.=20 >=20 > It's probably true that a 24 hour old mapping will work in=20 > most cases. I'm pretty unhappy with "probably" and "most",=20 > because of the consequences of getting wrong and the=20 > uncertainty of being able to manipulate a limited number of=20 > levers when lots of infrastructure is failing. This whole=20 > subject is about probabilities of getting the right thing to=20 > happen, and I think we should take every opportunity to=20 > improve the odds. =20 >=20 > Brian >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, September 14, 2005 11:12 AM > To: br@brianrosen.net; Marc Linsner (mlinsner); James Polk (jmpolk) > Cc: dhcwg@ietf.org; ECRIT > Subject: RE: [Ecrit] draft-polk-dhc-uri-00 >=20 > Brian, >=20 > First, PSAPs should have operational constraints to migrate=20 > operations gracefully so they can not arbitrarily change=20 > mappings at a faster pace than say 24 hours. >=20 > Second, disaster-related effects should be handled by proper=20 > high availability design. Non-respone from the primar PSAP=20 > URI should result in fail-over to an alternate IP address=20 > located in a different geographic area. What is invalid here=20 > is not the URI but the underlying PSAP network design. >=20 > And yes, the client should have some maximum time beyond=20 > which it must refresh. But, it might also be more=20 > predictable for the voice system if the network managed when=20 > the refreshes occurred before the deadline such that there is=20 > no avalanche from clients. Thus, clients would always find=20 > themselves inside that (24 hour?) window. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > > Of Brian Rosen > > Sent: Wednesday, September 14, 2005 9:07 AM > > To: Marc Linsner (mlinsner); James Polk (jmpolk) > > Cc: dhcwg@ietf.org; 'ECRIT' > > Subject: RE: [Ecrit] draft-polk-dhc-uri-00 > >=20 > > I've previously argued that while getting it when you boot=20 > (i.e. run=20 > > DHCP) is a good idea, it would be best if you did the mapping from=20 > > location to URI just before the call, because, due to failures or=20 > > other disaster related effects, the mapping may have=20 > changed. It IS a=20 > > transaction you want to do when you want to make a call=20 > setup, because=20 > > you want the most recent data. > >=20 > > You also want to make certain that you refresh this data=20 > periodically. > > Daily is probably the minimum, and you know that some DHCP=20 > lease times=20 > > are on the order of weeks. > >=20 > > So, I would like this wording significantly changed. > >=20 > > Brian > >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > > Of Marc Linsner > > Sent: Wednesday, September 14, 2005 8:48 AM > > To: 'James M. Polk' > > Cc: dhcwg@ietf.org; 'ECRIT' > > Subject: [Ecrit] draft-polk-dhc-uri-00 > >=20 > > James, > >=20 > > Would you please provide the basis for your text below=20 > regarding the=20 > > timing of psap determination, I can't seem to match it up=20 > with any of=20 > > the requirements within ecrit or geopriv. > >=20 > > "One example of this URI download would be one specifically for the=20 > > SIP or SIPS URI of the appropriate Public Safety Answer=20 > Point (PSAP)=20 > > for the client when the user of that client calls for=20 > emergency help=20 > > (911 or 112-type of help). > > This is not a transaction that should take place when a voice=20 > > application wants to make such a critical call set-up. It is more=20 > > appropriate that this information be downloaded to the=20 > client when the=20 > > voice (or other) application boots up in case it is needed=20 > at a later=20 > > time." > >=20 > > Thanks, > >=20 > > -Marc- > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 14 12:18:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZwk-00035r-0e; Wed, 14 Sep 2005 12:17:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZwi-00035j-9P for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 12:17:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19560 for ; Wed, 14 Sep 2005 12:17:11 -0400 (EDT) Received: from aismt08p.bellsouth.com ([139.76.165.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFa1I-0006JZ-Gf for ecrit@ietf.org; Wed, 14 Sep 2005 12:22:01 -0400 Received: from ([90.152.53.183]) by aismt08p.bellsouth.com with SMTP id KP-AXPNC.69290234; Wed, 14 Sep 2005 12:10:33 -0400 Importance: normal Priority: normal Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01AL10015010163.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 14 Sep 2005 11:16:02 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 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] terminology Date: Wed, 14 Sep 2005 11:16:01 -0500 Message-ID: <9888E1AA13C3A1459D122996A58C0E1131BC2A@bre2k61p-55> Thread-Topic: [Ecrit] terminology Thread-Index: AcW4uvCWSOBJMrq5ROWxLcIfRBCiHQAAQjLgACEsseA= From: "Stark, Barbara" To: "Winterbottom, James" , "Andrew Newton" , "Tschofenig, Hannes" X-OriginalArrivalTime: 14 Sep 2005 16:16:02.0409 (UTC) FILETIME=[99CCF590:01C5B947] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm not really particular about which terminology is used (so long as everybody agrees what it means), but since there's some discussion, I thought it might be useful to point out how some of this terminology is defined and used in the DSL world. The following document defines (in sections 3.1 and 3.2) lots of provider and network terminology, from the perspective of DSL providers: http://www.dslforum.org/aboutdsl/Technical_Reports/TR-059.pdf Terms that may be of interest are: Access Network, Regional Network, Regional/Access Network, NSP (Network SP, can be ISP or Corporate SP -- note that some enterprises choose to purchase DSL service for remote sites/employees, and the enterprise has a direct Layer 2 connection to the Regional/Access Network, so the site/employee doesn't go over the Internet), ASP, loop provider, access network provider, and regional provider. In the pictures, the ASP is shown as connected directly to the Regional/Access Network. This doesn't have to be the case, and is just that way in this doc, since that was the only case of interest to the Regional/Access Network Providers who wrote it. The ASP could be connected to the ISP (NSP). Also note that in this doc, the role of the ISP (or NSP) is not the role of an access provider, although a single company could be taking on both roles. I would recommend considering these "providers" as distinct roles, and not as companies. Anyway, if you find this useful, please feel free to use what you like. If not, feel free to ignore. Naturally, I recognize that non-DSL providers may not want to use terminology from this doc. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of Winterbottom, James Sent: Tuesday, September 13, 2005 7:47 PM To: Andrew Newton; Tschofenig, Hannes Cc: ecrit@ietf.org Subject: RE: [Ecrit] terminology Andy, As I pointed out before I think that the definitions of IAP, ISP and ASP in your document are misleading. In deployments today an ISP is someone that gives you an IP address and may or may not provide additional services, they often do not provide you connectivity from your house to them, and this is not addressed in your document. The difference between your ASP and ISP definitions is not clear. So I think that I agree with Hannes that these definitions and that perhaps some thrashing out on the list might be appropriate to arrive at a common set of definitions, rather than opposing ones. Cheers James=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Andrew Newton > Sent: Wednesday, 14 September 2005 9:28 AM > To: Tschofenig, Hannes > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] terminology >=20 >=20 > On Sep 13, 2005, at 10:26 AM, Tschofenig, Hannes wrote: >=20 > > hi all, > > > > i have a question regarding the terminology used in: > > http://www.ietf.org/internet-drafts/draft-polk-newton-ecrit-arch- > > conside > > rations-00.txt > > > > the requirements document defines a number of terms. they do not > > seem to > > be sufficient, as it seems. i think it would be useful to fix or to > > enhance the terms in the requirements document as soon as possible. >=20 > Hannes, >=20 > What was your question? >=20 > -andy >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. 163 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 14 15:19:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFcma-0004uX-T3; Wed, 14 Sep 2005 15:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFcmZ-0004uO-U5 for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 15:19:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28122 for ; Wed, 14 Sep 2005 15:18:58 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFcrC-0002LC-Na for ecrit@ietf.org; Wed, 14 Sep 2005 15:23:49 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 14 Sep 2005 12:18:48 -0700 X-IronPort-AV: i="3.97,110,1125903600"; d="scan'208"; a="211902190:sNHT31530444" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j8EJIEvA025773; Wed, 14 Sep 2005 12:18:41 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 12:18:30 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.121.125]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 12:18:30 -0700 Message-Id: <4.3.2.7.2.20050914141519.0342af08@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Sep 2005 14:18:28 -0500 To: "Rodrig, Benny \(Benny\)" , , "Winterbottom, James" , "ECRIT" From: "James M. Polk" Subject: RE: [Ecrit] Emergency [VPN issue] In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Sep 2005 19:18:30.0408 (UTC) FILETIME=[17510880:01C5B961] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 10:03 AM 9/13/2005 -0400, Rodrig, Benny \(Benny\) wrote: >My comment below was regarding the enterprise remote users connecting to >the corporate network through a VPN from home or from e.g. some remote >hotel. For that case, I was disagreeing with James's argument that the >enterprise is the access provider if it requires all traffic to go >through the VPN. I don't believe I stated this, and if it read that way, I apologize because that is clearly not what I meant. The call will go through the enterprise, but the caller is not connected physically to the enterprise, therefore the enterprise cannot know where the caller is, thus not be on the hook for providing location during the emergency call (which is what I was arguing against). >It does not seem feasible for the enterprise to provide >the user's location in this case. > >Benny 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 Sep 14 15:45:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFdCf-0001jY-7v; Wed, 14 Sep 2005 15:45:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFdCe-0001jT-PH for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 15:45:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29334 for ; Wed, 14 Sep 2005 15:45:52 -0400 (EDT) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFdHF-0002wY-E5 for ecrit@ietf.org; Wed, 14 Sep 2005 15:50:44 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8EJh22f023759 for ; Wed, 14 Sep 2005 15:43:04 -0400 (EDT) Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8EJeX2f020402 for ; Wed, 14 Sep 2005 15:41:17 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] Emergency [VPN issue] Date: Wed, 14 Sep 2005 15:42:50 -0400 Message-ID: Thread-Topic: [Ecrit] Emergency [VPN issue] Thread-Index: AcW5YUUnsJ9kEcYDTuSHc22uMymGxwAAjZzw From: "Rodrig, Benny \(Benny\)" To: "James M. Polk" , , "Winterbottom, James" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James, I meant the other James. I completely agree with you. It was a message from James Winterbottom that seemed to suggest putting the enterprise on the hook for that. Benny=20 -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com]=20 Sent: Wednesday, September 14, 2005 3:18 PM To: Rodrig, Benny (Benny); br@brianrosen.net; Winterbottom, James; ECRIT Subject: RE: [Ecrit] Emergency [VPN issue] At 10:03 AM 9/13/2005 -0400, Rodrig, Benny \(Benny\) wrote: >My comment below was regarding the enterprise remote users connecting=20 >to the corporate network through a VPN from home or from e.g. some=20 >remote hotel. For that case, I was disagreeing with James's argument=20 >that the enterprise is the access provider if it requires all traffic=20 >to go through the VPN. I don't believe I stated this, and if it read that way, I apologize because that is clearly not what I meant. The call will go through the enterprise, but the caller is not connected physically to the enterprise, therefore the enterprise cannot know where the caller is, thus not be on the hook for providing location during the emergency call (which is what I was arguing against). >It does not seem feasible for the enterprise to provide the user's=20 >location in this case. > >Benny 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 Sep 14 15:53:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFdK1-0002oW-Tb; Wed, 14 Sep 2005 15:53:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFdJz-0002oR-Uo for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 15:53:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29946 for ; Wed, 14 Sep 2005 15:53:30 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFdOd-0003Eh-1Y for ecrit@ietf.org; Wed, 14 Sep 2005 15:58:21 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 14 Sep 2005 12:53:21 -0700 X-IronPort-AV: i="3.97,110,1125903600"; d="scan'208"; a="341705568:sNHT33048950" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8EJr458028752; Wed, 14 Sep 2005 12:53:18 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 12:53:16 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.121.125]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 12:53:16 -0700 Message-Id: <4.3.2.7.2.20050914143145.02933160@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Sep 2005 14:53:15 -0500 To: Andrew Newton , "Tschofenig, Hannes" From: "James M. Polk" Subject: Re: AW: [Ecrit] terminology In-Reply-To: <678D2B94-398B-4782-8BCD-386D9B3A9CB3@hxr.us> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Sep 2005 19:53:16.0370 (UTC) FILETIME=[F2A59320:01C5B965] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 08:05 AM 9/14/2005 -0400, Andrew Newton wrote: >On Sep 14, 2005, at 4:50 AM, Tschofenig, Hannes wrote: > >>we should make sure that the requirements document contains the >>terms we plan to use in the future. >>as such, we should not introduce terms with a different meaning in >>another document. >>furthermore, if we think that new terms are needed then we should >>add them to the requirements document. > >Understood. I'll talk to James about it. I believe we all need to agree on terminology, and use the same in each doc. The recent confusion (multiple opinions) on ISP vs. IAP and ISP vs. ASP tell me we don't agree yet on something fairly fundamental wrt architectures - definition of a network. John used a word that seemed totally clear to me, yet it is not used anywhere I know of in this context: "attachment". Barbara made the point that we need to maintain separate of the L2 provider and the L3 provider - and I agree. This used to be legally separated, at least in the US due to the L2 provider being regulated - and I'd like someone to tell me if this is still true. My opinion is that the acronym ISP is the one that is most out of place. Here's why: my ISP only gives me IP access the the wide open internet to any IP application I have the software to do. This enables Application specific (like only voice) SPs to become reachable. So, perhaps we need to move the traditional term "ISP" to just "Internet Provider", as that is all they need to do to qualify - provide Internet connectivity. I like John's "attachment" word to describe physical connectivity, we can use the word "link" too. Thus, the Attachment (or "Link") (radio or wireline) provider is at layer 2 The Internet Provider (no acronym!) is at Layer 3 providing IP addressing and a default gateway out to the world via the Internet Protocol, with no specific application access or communication. And the ASP provides application control and enablement of services like voice, video, IM, etc Each of these 3 SHOULD be considered separate organizations UNLESS the user is within the bounds of an Enterprise. This latter occurance necessitates L2 and L3 to be merged into a single organization, but DOES NOT mean L7 necessarily is within the Enterprise. As through my VPN to my corporate network I have access to an ASP such as Vonage for voice communications. Thus Link Provider Internet Provider Application (Service) Provider I think this makes none of the above a subset of any other How does this sound/read? >-andy > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 14 16:38:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFe14-0001cO-09; Wed, 14 Sep 2005 16:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFe13-0001cI-5D for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 16:38:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09788 for ; Wed, 14 Sep 2005 16:37:58 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFe5h-0007M7-5K for ecrit@ietf.org; Wed, 14 Sep 2005 16:42:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] terminology Date: Wed, 14 Sep 2005 22:41:20 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4513@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] terminology Thread-Index: AcW5Z/B0nQycooUURpyttyRs7i8LfAAAv8Dh From: "Stastny Richard" To: "James M. Polk" , "Andrew Newton" , "Tschofenig, Hannes" X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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 This discussion on terminology is very instructive, but I am feeling a bit uncomfortable, because it my not be very helpful for the real problem at hand. =20 We should consider: why do we need this definitions for the requirements? =20 We are not defining business models here. =20 The real reason why we need these definitions is the discussion we had in the other threat on L2, L3, VPNs and what box is providing finally the location information to the device, and where does this box get its location information and so on.=20 There exist many different scenarios, e.g. home users behind a NAT connected via DSL, Cable, etc.Users in WiFi hotspots, small enterprises, large enterprises, etc. The problem I have is that I do not have a solution either =20 regards Richard ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von James M. Polk Gesendet: Mi 14.09.2005 21:53 An: Andrew Newton; Tschofenig, Hannes Cc: ecrit@ietf.org Betreff: Re: AW: [Ecrit] terminology At 08:05 AM 9/14/2005 -0400, Andrew Newton wrote: >On Sep 14, 2005, at 4:50 AM, Tschofenig, Hannes wrote: > >>we should make sure that the requirements document contains the >>terms we plan to use in the future. >>as such, we should not introduce terms with a different meaning in >>another document. >>furthermore, if we think that new terms are needed then we should >>add them to the requirements document. > >Understood. I'll talk to James about it. I believe we all need to agree on terminology, and use the same in each = doc. The recent confusion (multiple opinions) on ISP vs. IAP and ISP vs. ASP tell me we don't agree yet on something fairly fundamental wrt architectures - definition of a network. John used a word that seemed totally clear to me, yet it is not used anywhere I know of in this context: "attachment". Barbara made the point that we need to maintain separate of the L2 = provider and the L3 provider - and I agree. This used to be legally separated, at least in the US due to the L2 provider being regulated - and I'd like someone to tell me if this is still true. My opinion is that the acronym ISP is the one that is most out of place. Here's why: my ISP only gives me IP access the the wide open internet to any IP application I have the software to do. This enables Application specific (like only voice) SPs to become reachable. So, perhaps we need to move the traditional term "ISP" to just "Internet Provider", as that is all they need to do to qualify - provide Internet connectivity. I like John's "attachment" word to describe physical connectivity, we = can use the word "link" too. Thus, the Attachment (or "Link") (radio or wireline) provider is at = layer 2 The Internet Provider (no acronym!) is at Layer 3 providing IP = addressing and a default gateway out to the world via the Internet Protocol, with = no specific application access or communication. And the ASP provides application control and enablement of services like voice, video, IM, etc Each of these 3 SHOULD be considered separate organizations UNLESS the = user is within the bounds of an Enterprise. This latter occurance = necessitates L2 and L3 to be merged into a single organization, but DOES NOT mean L7 necessarily is within the Enterprise. As through my VPN to my corporate network I have access to an ASP such as Vonage for voice communications. Thus Link Provider Internet Provider Application (Service) Provider I think this makes none of the above a subset of any other How does this sound/read? >-andy > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 14 16:47:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFeAJ-0004kF-Rd; Wed, 14 Sep 2005 16:47:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFeAG-0004jh-EA for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 16:47:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10496 for ; Wed, 14 Sep 2005 16:47:30 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFeEv-0007i9-QG for ecrit@ietf.org; Wed, 14 Sep 2005 16:52:22 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 14 Sep 2005 13:47:04 -0700 X-IronPort-AV: i="3.97,110,1125903600"; d="scan'208"; a="341722389:sNHT995838090" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8EKkYKY000516; Wed, 14 Sep 2005 13:47:00 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 13:47:01 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.121.125]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 13:47:01 -0700 Message-Id: <4.3.2.7.2.20050914153758.03471f08@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Sep 2005 15:47:00 -0500 To: "Stastny Richard" , From: "James M. Polk" Subject: Re: [Ecrit] Proposal for a new requirement In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4507@oefeg-s04.oefeg.loc > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Sep 2005 20:47:01.0292 (UTC) FILETIME=[74D99EC0:01C5B96D] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 10:59 AM 9/14/2005 +0200, Stastny Richard wrote: >Dear all, > >following the discussion on local access and VPN, I think >a new requirement is needed in section 5 "Identifying >the caller location" of the req I_D > >It should go approx like this (the language may need work ;-) > >Any device potentially be connected to the Internet and >used for contacting emergency services MUST be able to store >(multiple) retrieved location information and also MUST be able to provide >this location information at any time to requesting applications >running n this device. (so it is a function of the OS of the device). I do not have a problem with a requirement that more than one location format (civic, geo and URI) be stored. Are you suggesting there may be a problem with internal (to the device) retrieval of each form of location? Is this within the IETF's charter to mandate? I think we should recommend that an application running on a device have access to all forms of location stored within a device. >The information stored should contain location (civic or geo), time >retrieved, source, verification status, etc. verification status sounds like validation, something we want, but cannot mandate, and do not know how to reasonably do. This is not part of the PIDF-LO, this is not part of DHCP, this cannot be part of an internal GPS chip... >The information stored >may also contain URIs retrieved for different purposes ... > >Motivation: Location information may be retrieved by the device >from different sources and at different times (e.g. via GPS, RFID, >User Input, DHCP and similar protocols, etc.). Some of this information >may be already retrieved at or shortly after power-on (without any >connection to the Internet yet) and/or at time of (first) connection >to an IP-network e.g. retrieve an IP-address. Note: also at this time >no connection or no full connection to the Internet may be provided. > >The location information provided at this first contact at this IP >layer MUST be kept, MUST NOT be updated or replaced >by information provided by >later additional IP-layers and may eventually (by mobile devices) >be updated underneath later. This location information MUST be retrievable >at any time, even if later an additional IP-layer is established LATER >(e.g via an VPN), and the mapping database, the MSAG and also the PSAP >in case of an emergency call is contacted via the VPN access. > >I know this need work I still don't know exactly what you are driving at here (other than the requirement *not* to overwrite location learned by the Link layer when a VPN is brought on-line). >feedback welcome > > > >Richard > > >_______________________________________________ >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 Sep 14 16:48:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFeAx-0004sK-3I; Wed, 14 Sep 2005 16:48:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFeAv-0004rg-I9 for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 16:48:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10590 for ; Wed, 14 Sep 2005 16:48:11 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFeFa-0007kZ-9j for ecrit@ietf.org; Wed, 14 Sep 2005 16:53:03 -0400 Received: from [10.0.1.100] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 14 Sep 2005 16:48:06 -0400 id 000C7FC9.43288C87.00000C86 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4513@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C4513@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9E2283BB-1B6D-4A03-9306-96125A0C8365@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] terminology Date: Wed, 14 Sep 2005 16:48:01 -0400 To: Stastny Richard X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 14, 2005, at 4:41 PM, Stastny Richard wrote: > We should consider: why do we need this definitions > for the requirements? Perhaps we just need: Internet Attachment Provider - the entity that provides attachment to the Internet (layer 3) from a layer 2 network (i.e. this type of attachment is not considered of the same type as layer 3 tunneling). Voice Service Provider - the entity that provides Voice over IP service. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 14 16:51:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFeE4-0005G6-9t; Wed, 14 Sep 2005 16:51:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFeE0-0005Fv-BI for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 16:51:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10711 for ; Wed, 14 Sep 2005 16:51:21 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFeIf-0007p6-H5 for ecrit@ietf.org; Wed, 14 Sep 2005 16:56:14 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 14 Sep 2005 13:51:14 -0700 X-IronPort-AV: i="3.97,110,1125903600"; d="scan'208"; a="659808324:sNHT33329976" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8EKoXKg003732; Wed, 14 Sep 2005 13:51:10 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 13:51:09 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.121.125]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 13:51:09 -0700 Message-Id: <4.3.2.7.2.20050914154921.03f14008@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Sep 2005 15:51:07 -0500 To: "Stastny Richard" , "Andrew Newton" , "Tschofenig, Hannes" From: "James M. Polk" Subject: Re: [Ecrit] terminology In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4513@oefeg-s04.oefeg.loc > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Sep 2005 20:51:09.0173 (UTC) FILETIME=[08994250:01C5B96E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 10:41 PM 9/14/2005 +0200, Stastny Richard wrote: >This discussion on terminology is very instructive, >but I am feeling a bit uncomfortable, because it >my not be very helpful for the real problem at hand. well, I'm tired of us talking past each other from different definitions to the same terms. Hannes pointed out that the Arch doc uses slightly different definitions than the requirements doc - and this ought to be made consistent so we can all communicate more effectively and get to the problems you articulate below. > >We should consider: why do we need this definitions >for the requirements? > >We are not defining business models here. > >The real reason why we need these definitions is >the discussion we had in the other threat on L2, L3, VPNs >and what box is providing finally the location information to >the device, and where does this box get its location information >and so on. > >There exist many different scenarios, e.g. home users behind a NAT >connected via DSL, Cable, etc.Users in WiFi hotspots, small >enterprises, large enterprises, etc. > >The problem I have is that I do not have a solution either > >regards >Richard > >________________________________ > >Von: ecrit-bounces@ietf.org im Auftrag von James M. Polk >Gesendet: Mi 14.09.2005 21:53 >An: Andrew Newton; Tschofenig, Hannes >Cc: ecrit@ietf.org >Betreff: Re: AW: [Ecrit] terminology > > > >At 08:05 AM 9/14/2005 -0400, Andrew Newton wrote: > > >On Sep 14, 2005, at 4:50 AM, Tschofenig, Hannes wrote: > > > >>we should make sure that the requirements document contains the > >>terms we plan to use in the future. > >>as such, we should not introduce terms with a different meaning in > >>another document. > >>furthermore, if we think that new terms are needed then we should > >>add them to the requirements document. > > > >Understood. I'll talk to James about it. > >I believe we all need to agree on terminology, and use the same in each doc. > >The recent confusion (multiple opinions) on ISP vs. IAP and ISP vs. ASP >tell me we don't agree yet on something fairly fundamental wrt >architectures - definition of a network. > >John used a word that seemed totally clear to me, yet it is not used >anywhere I know of in this context: "attachment". > >Barbara made the point that we need to maintain separate of the L2 provider >and the L3 provider - and I agree. This used to be legally separated, at >least in the US due to the L2 provider being regulated - and I'd like >someone to tell me if this is still true. > >My opinion is that the acronym ISP is the one that is most out of place. >Here's why: > >my ISP only gives me IP access the the wide open internet to any IP >application I have the software to do. This enables Application specific >(like only voice) SPs to become reachable. > >So, perhaps we need to move the traditional term "ISP" to just "Internet >Provider", as that is all they need to do to qualify - provide Internet >connectivity. > >I like John's "attachment" word to describe physical connectivity, we can >use the word "link" too. > >Thus, the Attachment (or "Link") (radio or wireline) provider is at layer 2 > >The Internet Provider (no acronym!) is at Layer 3 providing IP addressing >and a default gateway out to the world via the Internet Protocol, with no >specific application access or communication. > >And the ASP provides application control and enablement of services like >voice, video, IM, etc > >Each of these 3 SHOULD be considered separate organizations UNLESS the user >is within the bounds of an Enterprise. This latter occurance necessitates >L2 and L3 to be merged into a single organization, but DOES NOT mean L7 >necessarily is within the Enterprise. As through my VPN to my corporate >network I have access to an ASP such as Vonage for voice communications. > >Thus > >Link Provider >Internet Provider >Application (Service) Provider > >I think this makes none of the above a subset of any other > >How does this sound/read? > > > >-andy > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit > > >cheers, >James > > ******************* > Truth is not to be argued... it is to be presented. > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit 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 Sep 14 17:05:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFeRu-0002Hp-GQ; Wed, 14 Sep 2005 17:05:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFeRn-0002Hj-MI for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 17:05:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11490 for ; Wed, 14 Sep 2005 17:05:36 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFeWS-0008Go-TQ for ecrit@ietf.org; Wed, 14 Sep 2005 17:10:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] Proposal for a new requirement Date: Wed, 14 Sep 2005 23:09:14 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4514@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Proposal for a new requirement Thread-Index: AcW5bgfrKau1neHuQbebYoe+cPsRwQAAcQ7d From: "Stastny Richard" To: "James M. Polk" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James Polk wrote: >Are you suggesting there may be a problem with internal (to the device) >retrieval of each form of location? >Is this within the IETF's charter to mandate? I think we should = recommend >that an application running on a device have access to all forms of >location stored within a device. Correct >verification status sounds like validation, something we want, but = cannot >mandate, and do not know how to reasonably do. This is not part of the >PIDF-LO, this is not part of DHCP, this cannot be part of an internal = GPS >chip... Sorry, I meant validation. What I meant here was simply that IF a civic location was validated e.g. via MSAG, this should be noted. =20 >I still don't know exactly what you are driving at here (other than the >requirement *not* to overwrite location learned by the Link layer when = a >VPN is brought on-line). yes Richard ________________________________ Von: James M. Polk [mailto:jmpolk@cisco.com] Gesendet: Mi 14.09.2005 22:47 An: Stastny Richard; ecrit@ietf.org Betreff: Re: [Ecrit] Proposal for a new requirement At 10:59 AM 9/14/2005 +0200, Stastny Richard wrote: >Dear all, > >following the discussion on local access and VPN, I think >a new requirement is needed in section 5 "Identifying >the caller location" of the req I_D > >It should go approx like this (the language may need work ;-) > >Any device potentially be connected to the Internet and >used for contacting emergency services MUST be able to store >(multiple) retrieved location information and also MUST be able to = provide >this location information at any time to requesting applications >running n this device. (so it is a function of the OS of the device). I do not have a problem with a requirement that more than one location format (civic, geo and URI) be stored. Are you suggesting there may be a problem with internal (to the device) retrieval of each form of location? Is this within the IETF's charter to mandate? I think we should = recommend that an application running on a device have access to all forms of location stored within a device. >The information stored should contain location (civic or geo), time >retrieved, source, verification status, etc. verification status sounds like validation, something we want, but = cannot mandate, and do not know how to reasonably do. This is not part of the PIDF-LO, this is not part of DHCP, this cannot be part of an internal = GPS chip... >The information stored >may also contain URIs retrieved for different purposes ... > >Motivation: Location information may be retrieved by the device >from different sources and at different times (e.g. via GPS, RFID, >User Input, DHCP and similar protocols, etc.). Some of this information >may be already retrieved at or shortly after power-on (without any >connection to the Internet yet) and/or at time of (first) connection >to an IP-network e.g. retrieve an IP-address. Note: also at this time >no connection or no full connection to the Internet may be provided. > >The location information provided at this first contact at this IP >layer MUST be kept, MUST NOT be updated or replaced >by information provided by >later additional IP-layers and may eventually (by mobile devices) >be updated underneath later. This location information MUST be = retrievable >at any time, even if later an additional IP-layer is established LATER >(e.g via an VPN), and the mapping database, the MSAG and also the PSAP >in case of an emergency call is contacted via the VPN access. > >I know this need work I still don't know exactly what you are driving at here (other than the requirement *not* to overwrite location learned by the Link layer when a VPN is brought on-line). >feedback welcome > > > >Richard > > >_______________________________________________ >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 Sep 14 17:17:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFedN-00062T-1V; Wed, 14 Sep 2005 17:17:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFedJ-00061R-CO for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 17:17:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12546 for ; Wed, 14 Sep 2005 17:17:30 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFehz-0000M7-C2 for ecrit@ietf.org; Wed, 14 Sep 2005 17:22:23 -0400 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 j8ELHRWk016246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Sep 2005 17:17:28 -0400 (EDT) Message-ID: <43289349.6080504@cs.columbia.edu> Date: Wed, 14 Sep 2005 17:16:57 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] terminology References: <32755D354E6B65498C3BD9FD496C7D462C4513@oefeg-s04.oefeg.loc> <9E2283BB-1B6D-4A03-9306-96125A0C8365@hxr.us> In-Reply-To: <9E2283BB-1B6D-4A03-9306-96125A0C8365@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: Stastny Richard , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think 3GPP and others get into trouble when they specify "boxes" where the interfaces are less-than-well-defined. In this particular case, our interfaces (protocols) are reasonably well defined: (1) photons or electrons or radio waves (2) cells or frames such as Ethernet or DSL (or other layer-2 mechanisms) (3) IP packets (4) DHCP (5) RTP packets (6) SIP signaling (7) location mapping In theory, we could have 7 different actors. For this particular discussion, we don't care about #7, but the question is whether we can reduce the number to something below 6 and whether a single user would simultaneously have multiple providers for each. With dark fiber and things like split coax cables, (1) and (2) do not have to be the same entity. For residential providers, (3) and (4) don't have to be same entity, but this depends a bit on the precise definition. As far as my 802.11 phone is concerned, is the coffee shop the provider of IP packets, even though it obviously buys that service from somebody else? If the coffee shop gets a fixed IP address (no DHCP) from its provider, the two are clearly not the same entities unless we also consider the coffee shop the Internet access/service provider as far as the phone is concerned. With separate IM and voice providers, (5) and (6) may not be unique. One way out of these philosophical discussions is to simply label this by protocol or layer. Thus, we'd have an "IP provider" or a "L1 provider". As was mentioned, we don't really care about the business relationships, but rather trust and management relationships, for example. My concern is that the term "X service provider" will be understood by most outside parties to refer to a commercial entity providing X for a fee, even though that entity may have no direct protocol relationship with the emergency caller. Example: Technically, most definitions would make universities ISP/IAPs, but if somebody were to ask "Is Columbia an ISP?", people would be somewhat surprised if you answered yes. Defining terms in contradiction to commonly understood usage is not a recipe for clarity. (And, yes, I've tried in the past to define various I*P terms, but am starting to doubt the payoff-to-effort ratio of such efforts.) Henning Andrew Newton wrote: > > On Sep 14, 2005, at 4:41 PM, Stastny Richard wrote: > >> We should consider: why do we need this definitions >> for the requirements? > > > Perhaps we just need: > > Internet Attachment Provider - the entity that provides attachment to > the Internet (layer 3) from a layer 2 network (i.e. this type of > attachment is not considered of the same type as layer 3 tunneling). > > Voice Service Provider - the entity that provides Voice over IP service. > > -andy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 14 17:39:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFeyF-0004iJ-8N; Wed, 14 Sep 2005 17:39:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFeyD-0004hj-Bk; Wed, 14 Sep 2005 17:39:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13560; Wed, 14 Sep 2005 17:39:06 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFf2t-0000wZ-BE; Wed, 14 Sep 2005 17:43:59 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 14 Sep 2005 14:39:01 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j8ELcJWT021330; Wed, 14 Sep 2005 14:38:55 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 14:38:56 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.121.125]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 14:38:55 -0700 Message-Id: <4.3.2.7.2.20050914160915.0301adc8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Sep 2005 16:38:54 -0500 To: "Marc Linsner" From: "James M. Polk" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Sep 2005 21:38:55.0963 (UTC) FILETIME=[B556B2B0:01C5B974] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: dhcwg@ietf.org, 'ECRIT' Subject: [Ecrit] Re: draft-polk-dhc-uri-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 08:48 AM 9/14/2005 -0400, Marc Linsner wrote: >James, > >Would you please provide the basis for your text below regarding the timing >of psap determination, I can't seem to match it up with any of the >requirements within ecrit or geopriv. When something is urgent, do you want to invoke more processing complexity or less processing complexity? More typically means "more prone to errors", less typically means "less prone to errors". Everyone hear is assuming that the UA providing location will get mapped to the appropriate PSAP within a reasonable call set-up timeframe. This document suggests an optimization - to do the "mapping" before time is wasted doing the mapping just to set-up the call. The ECRIT Charter says: (item #1) "Successful delivery of an emergency service call within those systems requires both an association of the physical location of the originator with an appropriate emergency service center and call routing to deliver the call to the center." and (item #2) "Calls placed using Internet technologies do not use the same systems to achieve those goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting them more challenging. There are, however, Internet technologies available to describe location and to manage call routing. This working group will describe when these may be appropriate and how they may be used." and (item #3) "The group will show how the availability of location data and call routing information at different steps in session setup would enable communication between a user and a relevant emergency response center. " Item # 1 talks the association of user location and the appropriate PSAP. - This ID describes this by using the same Link provider that knows the UA's location (and give the UA its location. Item #2 talks about describing location and managing call routing - specifically "when" these may be appropriate. - This ID describes accomplishing this mapping before call set-up. - I don't remember reading a requirement in either WG that says "this mapping function MUST take place *only* during call set-up". Item #3 talks about different information at different times in the session set-up. - This ID provides the Request-URI for the INVITE message, plus provides an alternate Request-URI, plus the URI of the ESGW and ESRP. SIP Proxies will determine if a route is available or not, and reroute around any problems if there are any. A URI is not an IP Address, of which there is one. The same URI can go to many difference locations in times of overload or error. Webservers have been doing this function for better than 5 years now. >"One example of this URI download would be one specifically for the SIP or >SIPS URI of the appropriate Public Safety Answer Point (PSAP) for the client >when the user of that client calls for emergency help (911 or 112-type of >help). This is not a transaction that should take place when a voice >application wants to make such a critical call set-up. It is more >appropriate that this information be downloaded to the client when the voice >(or other) application boots up in case it is needed at a later time." > >Thanks, > >-Marc- 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 Sep 14 17:50:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFf8r-0007KR-K3; Wed, 14 Sep 2005 17:50:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFf8n-0007Ji-PA for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 17:50:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14068 for ; Wed, 14 Sep 2005 17:50:03 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFfDS-0001D6-OG for ecrit@ietf.org; Wed, 14 Sep 2005 17:54:56 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 14 Sep 2005 14:49:55 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8ELnAKm019251; Wed, 14 Sep 2005 14:49:50 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 14:49:50 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.121.125]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 14:49:49 -0700 Message-Id: <4.3.2.7.2.20050914164019.0336a3e0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Sep 2005 16:49:48 -0500 To: "Stastny Richard" , From: "James M. Polk" Subject: Re: [Ecrit] Proposal for a new requirement In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4514@oefeg-s04.oefeg.loc > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Sep 2005 21:49:49.0704 (UTC) FILETIME=[3AFFA880:01C5B976] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 11:09 PM 9/14/2005 +0200, Stastny Richard wrote: >James Polk wrote: > >verification status sounds like validation, something we want, but cannot > >mandate, and do not know how to reasonably do. This is not part of the > >PIDF-LO, this is not part of DHCP, this cannot be part of an internal GPS > >chip... > >Sorry, I meant validation. What I meant here was simply >that IF a civic location was validated e.g. via MSAG, this >should be noted. While I fully agree that only civic addresses that are in the MSAG (or whatever alternative/future database is used) should be sent in the INVITE, one of several things will occur: #1 - the ESRP will error the message with a 424 (Bad Location Information) error if the lcoation is not in the database #2 - the ESRP will pass the location along (knowing or unknowing the validity of the information) and the PSAP will check this information to its database. Now, one of a few things will happen: A - The location information is good, the PSAP accepts the call; or B - The location information (in whichever format) is inaccurate/incorrect or otherwise bad, the PSAP will reject the INVITE because bad location information was in the INVITE (though not a likely scenario - so do we really need to keep discussing this topic?!) or C - the location information doesn't match up with the entry in the MSAG as a bad street name (or it's just not in the range of street addresses on a particular street in the database) and the PSAP operator is alerted to this as is forced to ask the person on the call "where are you?". Doesn't this happen anyway? > 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 From ecrit-bounces@ietf.org Wed Sep 14 17:58:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFfGS-00017o-CT; Wed, 14 Sep 2005 17:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFfGQ-00017j-W4 for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 17:57:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14306 for ; Wed, 14 Sep 2005 17:57:56 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFfL5-0001PE-8B for ecrit@ietf.org; Wed, 14 Sep 2005 18:02:49 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 14 Sep 2005 14:57:47 -0700 X-IronPort-AV: i="3.97,110,1125903600"; d="scan'208"; a="659829258:sNHT38801758" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8ELvZKG025011; Wed, 14 Sep 2005 14:57:40 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 14:57:36 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.121.125]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 14:57:35 -0700 Message-Id: <4.3.2.7.2.20050914165205.032365c8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Sep 2005 16:57:34 -0500 To: Henning Schulzrinne , Andrew Newton From: "James M. Polk" Subject: Re: [Ecrit] terminology In-Reply-To: <43289349.6080504@cs.columbia.edu> References: <9E2283BB-1B6D-4A03-9306-96125A0C8365@hxr.us> <32755D354E6B65498C3BD9FD496C7D462C4513@oefeg-s04.oefeg.loc> <9E2283BB-1B6D-4A03-9306-96125A0C8365@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Sep 2005 21:57:35.0751 (UTC) FILETIME=[50C8C970:01C5B977] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Stastny Richard , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 05:16 PM 9/14/2005 -0400, Henning Schulzrinne wrote: >One way out of these philosophical discussions is to simply label this by >protocol or layer. Thus, we'd have an "IP provider" or a "L1 provider". I think I suggested this 3 hours ago, in which I said Link Provider (at Layer 2) Internet Provider (at Layer 3/4/5) Application (Service) Provider (at Layer 7) >As was mentioned, we don't really care about the business relationships, >but rather trust and management relationships, for example. I disagree with this statement because of the politics and regulation (that's going to be) involved. Specifically with respect to the FCC's ruling that Vonage-type companies MUST produce the 911 call at the appropriate PSAP. This has little to do with trust, the way you're meaning it (I believe). >My concern is that the term "X service provider" will be understood by >most outside parties to refer to a commercial entity providing X for a >fee, even though that entity may have no direct protocol relationship with >the emergency caller. Example: Technically, most definitions would make >universities ISP/IAPs, but if somebody were to ask "Is Columbia an ISP?", >people would be somewhat surprised if you answered yes. Defining terms in >contradiction to commonly understood usage is not a recipe for clarity. > >(And, yes, I've tried in the past to define various I*P terms, but am >starting to doubt the payoff-to-effort ratio of such efforts.) I'm getting equally frustrated in attempting this series of definitions >Henning > > >Andrew Newton wrote: >>On Sep 14, 2005, at 4:41 PM, Stastny Richard wrote: >> >>>We should consider: why do we need this definitions >>>for the requirements? >> >>Perhaps we just need: >>Internet Attachment Provider - the entity that provides attachment to >>the Internet (layer 3) from a layer 2 network (i.e. this type of >>attachment is not considered of the same type as layer 3 tunneling). >>Voice Service Provider - the entity that provides Voice over IP service. >>-andy >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 14 18:09:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFfR8-0003ma-Bp; Wed, 14 Sep 2005 18:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFfR6-0003iJ-9Z for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 18:09:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15165 for ; Wed, 14 Sep 2005 18:08:57 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFfVl-0001hm-Mg for ecrit@ietf.org; Wed, 14 Sep 2005 18:13:50 -0400 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 j8EM89Wk019013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Sep 2005 18:08:10 -0400 (EDT) Message-ID: <43289F2B.7080104@cs.columbia.edu> Date: Wed, 14 Sep 2005 18:07:39 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] terminology References: <9E2283BB-1B6D-4A03-9306-96125A0C8365@hxr.us> <32755D354E6B65498C3BD9FD496C7D462C4513@oefeg-s04.oefeg.loc> <9E2283BB-1B6D-4A03-9306-96125A0C8365@hxr.us> <4.3.2.7.2.20050914165205.032365c8@email.cisco.com> In-Reply-To: <4.3.2.7.2.20050914165205.032365c8@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: Stastny Richard , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > > I think I suggested this 3 hours ago, in which I said I'm sorry I missed this in the flood of messages today. > > Link Provider (at Layer 2) > Internet Provider (at Layer 3/4/5) As far as I can tell, TCP (layer 4) is not provided by anyone except the two TCP end hosts. I don't think you'd want to call Microsoft an Internet Provider. I'm not sure what layer 5 is. > Application (Service) Provider (at Layer 7) This division is fairly similar to the one that had been in many of the early requirements documents I had a hand in drafting. However, I tend to believe now that there are a sufficient number of corner cases where such terms will yield more confusion than insight. > > >> As was mentioned, we don't really care about the business >> relationships, but rather trust and management relationships, for >> example. > > > I disagree with this statement because of the politics and regulation > (that's going to be) involved. Specifically with respect to the FCC's > ruling that Vonage-type companies MUST produce the 911 call at the > appropriate PSAP. This has little to do with trust, the way you're > meaning it (I believe). Unfortunately, these terms are not even clear within the regulatory community. Unless you want to say "A voice service provider is whatever the FCC believes today it happens to be (until some federal court tells them otherwise)", this doesn't help much. The only term they define, by the way, is "connected voice provider", which is yet another beast and clearly does not, for example, include (say) Yahoo! or FWD or (say) Jabber, although they would be considered an ASP according to most discussions we've had and I assume would an ASP in your estimation. In other words: not all ASPs are subject to emergency services mandates today in the US, but some might be today or in other countries. In short: I think trying to follow the regulatory definitions gets us into national regulations we have no way of tracking (nor should we try to). We might hope that crisp, unambiguous, protocol-based definitions will eventually make it into regulations, but that's probably naive to hope for. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 14 18:48:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFg3V-0005j6-EP; Wed, 14 Sep 2005 18:48:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFg3T-0005hQ-BJ for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 18:48:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17414 for ; Wed, 14 Sep 2005 18:48:36 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFg8A-0002bW-1K for ecrit@ietf.org; Wed, 14 Sep 2005 18:53:30 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 14 Sep 2005 15:48:30 -0700 X-IronPort-AV: i="3.97,111,1125903600"; d="scan'208"; a="659845369:sNHT31445048" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8EMm15I014116; Wed, 14 Sep 2005 15:48:25 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 15:48:26 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.121.125]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 15:48:25 -0700 Message-Id: <4.3.2.7.2.20050914173516.02841500@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Sep 2005 17:48:24 -0500 To: Henning Schulzrinne From: "James M. Polk" Subject: Re: [Ecrit] terminology In-Reply-To: <43289F2B.7080104@cs.columbia.edu> References: <4.3.2.7.2.20050914165205.032365c8@email.cisco.com> <9E2283BB-1B6D-4A03-9306-96125A0C8365@hxr.us> <32755D354E6B65498C3BD9FD496C7D462C4513@oefeg-s04.oefeg.loc> <9E2283BB-1B6D-4A03-9306-96125A0C8365@hxr.us> <4.3.2.7.2.20050914165205.032365c8@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Sep 2005 22:48:25.0808 (UTC) FILETIME=[6AC28D00:01C5B97E] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Stastny Richard , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 06:07 PM 9/14/2005 -0400, Henning Schulzrinne wrote: >>I think I suggested this 3 hours ago, in which I said > >I'm sorry I missed this in the flood of messages today. > >>Link Provider (at Layer 2) >>Internet Provider (at Layer 3/4/5) > >As far as I can tell, TCP (layer 4) is not provided by anyone except the >two TCP end hosts. I don't think you'd want to call Microsoft an Internet >Provider. I'm not sure what layer 5 is. 3/4/5 is getting into the backbone nature of an IP transport function of an Internet Provider, like where RTP is (as was mentioned specifically in a message within the last 24 hours) - perhaps I shouldn't use numbers other than 3 for the Internet Provider. >>Application (Service) Provider (at Layer 7) > >This division is fairly similar to the one that had been in many of the >early requirements documents I had a hand in drafting. However, I tend to >believe now that there are a sufficient number of corner cases where such >terms will yield more confusion than insight. we talk of a VSP without hesitation now, and that orgnaization is the provider of a specific application. If we agreed on the use of "Application" here to mean Layer 7 Provider, we can get past the confusion - I hope. This is one reason why I think we need to get rid of the word "service" in ISP and ASP. That is the word I believe is the most confusing, because voice is a service, but in the context of an Internet Service Provider, the ISP might not be the one to provide that service - hense there is confusion. >>>As was mentioned, we don't really care about the business relationships, >>>but rather trust and management relationships, for example. >> >>I disagree with this statement because of the politics and regulation >>(that's going to be) involved. Specifically with respect to the FCC's >>ruling that Vonage-type companies MUST produce the 911 call at the >>appropriate PSAP. This has little to do with trust, the way you're >>meaning it (I believe). > >Unfortunately, these terms are not even clear within the regulatory >community. Unless you want to say "A voice service provider is whatever >the FCC believes today it happens to be (until some federal court tells >them otherwise)", this doesn't help much. The only term they define, by >the way, is "connected voice provider", which is yet another beast and >clearly does not, for example, include (say) Yahoo! or FWD or (say) >Jabber, although they would be considered an ASP according to most >discussions we've had and I assume would an ASP in your estimation. agreed >In other words: not all ASPs are subject to emergency services mandates >today in the US, I absolutely agree with this, as we're focusing on voice first, with IM and video later; but for now, IM providers are not in this emergency services mix. >but some might be today or in other countries. > >In short: I think trying to follow the regulatory definitions gets us into >national regulations we have no way of tracking (nor should we try to). I'm not saying "get into regulatory definitions" per se, unless there is one staring us in the face like the recent one is (US FCC 05-116). Flying in the face of this seems equally foolish IMO. >We might hope that crisp, unambiguous, protocol-based definitions will >eventually make it into regulations, but that's probably naive to hope for. I wish you had your way, I would prefer that too. Perhaps we go with longer terms: Link Layer Provider (LLP) Internet Layer Provider (ILP) Application Layer Provider (ALP) I'm not trying to just come up with terms for the sake of terms, I'm trying to get to the point where everyone can agree on a set of meanings and have discussions without having to define what is being discussed each time a discussion comes up >Henning 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 Sep 14 19:19:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFgXS-0005hL-1G; Wed, 14 Sep 2005 19:19:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFgXQ-0005hD-7F for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 19:19:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18762 for ; Wed, 14 Sep 2005 19:19:33 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFgc5-0003Na-7z for ecrit@ietf.org; Wed, 14 Sep 2005 19:24:27 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 18:19:22 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 14 Sep 2005 18:19:22 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 18:19:22 -0500 Message-ID: From: "Winterbottom, James" To: "Rodrig, Benny \(Benny\)" , "James M. Polk" , , "ECRIT" Date: Wed, 14 Sep 2005 18:19:20 -0500 Subject: RE: [Ecrit] Emergency [VPN issue] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 14 Sep 2005 23:19:22.0171 (UTC) FILETIME=[BD3D10B0:01C5B982] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Emergency [VPN issue] Thread-Index: AcW5YUUnsJ9kEcYDTuSHc22uMymGxwAAjZzwAAc5H8A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Benny, That is certainly not what I meant. I do believe that first IP in the chain is responsible for providing location to the VEP, even if they must acquire the information from someone else in the chain.=20 The enterprise is however responsible to sure that the call gets delivered to a suitable gateway that can handle the request, and this latter part may include understanding PSAP filtering policies. Cheers James > -----Original Message----- > From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] > Sent: Thursday, 15 September 2005 5:43 AM > To: James M. Polk; br@brianrosen.net; Winterbottom, James; ECRIT > Subject: RE: [Ecrit] Emergency [VPN issue] >=20 > James, >=20 > I meant the other James. I completely agree with you. It was a message > from James Winterbottom that seemed to suggest putting the enterprise on > the hook for that. >=20 > Benny >=20 > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Wednesday, September 14, 2005 3:18 PM > To: Rodrig, Benny (Benny); br@brianrosen.net; Winterbottom, James; ECRIT > Subject: RE: [Ecrit] Emergency [VPN issue] >=20 > At 10:03 AM 9/13/2005 -0400, Rodrig, Benny \(Benny\) wrote: > >My comment below was regarding the enterprise remote users connecting > >to the corporate network through a VPN from home or from e.g. some > >remote hotel. For that case, I was disagreeing with James's argument > >that the enterprise is the access provider if it requires all traffic > >to go through the VPN. >=20 > I don't believe I stated this, and if it read that way, I apologize > because that is clearly not what I meant. The call will go through the > enterprise, but the caller is not connected physically to the > enterprise, therefore the enterprise cannot know where the caller is, > thus not be on the hook for providing location during the emergency call > (which is what I was arguing against). >=20 > >It does not seem feasible for the enterprise to provide the user's > >location in this case. > > > >Benny >=20 >=20 > cheers, > James >=20 > ******************* > Truth is not to be argued... it is to be presented. >=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 14 20:31:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFhey-00080Z-V8; Wed, 14 Sep 2005 20:31:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFhex-00080U-GN for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 20:31:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22402 for ; Wed, 14 Sep 2005 20:31:25 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFhjf-0005Rm-57 for ecrit@ietf.org; Wed, 14 Sep 2005 20:36:19 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 19:31:16 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 14 Sep 2005 19:31:15 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 19:31:15 -0500 Message-ID: From: "Thomson, Martin" To: "James Polk \(jmpolk\)" , Date: Wed, 14 Sep 2005 19:31:13 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 15 Sep 2005 00:31:15.0171 (UTC) FILETIME=[C7FCA330:01C5B98C] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: draft-polk-dhc-uri-00: mixed goals Thread-Index: AcW5jMcvS2U1RylvQe64dH7fd2NtHQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Subject: [Ecrit] draft-polk-dhc-uri-00: mixed goals 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="===============0434026173==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============0434026173== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message Content-Transfer-Encoding: base64 VG8gcHV0IHRoaXMgaW50byBwZXJzcGVjdGl2ZSwgSSBsaWtlIHRoZSBpZGVhIG9mIHRoaXMgZHJh ZnQgLSBJIGNhbiBzZWUgaG93IHRoaXMgd291bGQgYmUgYmVuZWZpY2lhbCwgYnV0IEkgaGF2ZSBh IGZldyBxdWVzdGlvbnMuDQoNCkZyb20gYSBoaWdoIGxldmVsLCB3aGVuIHlvdSBsb29rIGF0IHRo ZSBhYnN0cmFjdCwgdGhlIGRyYWZ0IHRhbGtzIGFib3V0IFVSSXMgLSBubyBzcGVjaWZpYyB0b3Bp Yy4gIFNvIHRoaXMgZHJhZnQgaGFzIHRoZSBwb3RlbnRpYWwgdG8gY292ZXIgYSB3aWRlIGFycmF5 IG9mIFVSSS10eXBlIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24uICBBbGwgcHJlc2VudCBVUklz IGFyZSBtYXBwaW5nIG9yIGVtZXJnZW5jeSBiYXNlZCwgb2J2aW91c2x5IGRyaXZlbiBieSBuZWVk Lg0KDQpJcyB0aGlzIGRyYWZ0IGludGVuZGVkIHRvIGJlIGEgY29udGFpbmVyIGZvciBmdXR1cmUg VVJJLXR5cGUgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbj8NCg0KSWYgdGhpcyBpcyBnb2luZyB0 byBiZSBhIGNvbnRhaW5lciwgd2h5IHRoZW4gdXNlIHVwIG51bWJlcnMgc28gcmFwaWRseSB3aXRo IHByaW1hcnkgYW5kIHNlY29uZGFyeSBvcHRpb25zPyAgV2h5IG5vdCBwcm92aWRlIGEgbGlzdCBp biBlYWNoIG9wdGlvbiwgc2ltaWxhciB0byB0aGUgd2F5IHRoYXQgUkZDIDMzNjEgYW5kIFJGQyAz Mzk3IHByb3ZpZGUgYSBsaXN0IG9mIGRvbWFpbiBuYW1lcz8gIFRoYXQgd291bGQgZW5hYmxlIHRo ZSBwcm92aXNpb24gb2YgbW9yZSB0aGFuIHR3byBmYWxsYmFjayB2YWx1ZXMgaWYgbmVjZXNzYXJ5 IC0ga2VlcGluZyBpbiBtaW5kIE1pY2hhZWwncyBwb2ludCB0aGF0IHdlIGFscmVhZHkgaGF2ZSBt ZWFucyBvZiBmYWxsYmFjayBhdCBvdGhlciBsYXllcnMuDQoNClRoZSByZXN0IG9mIG15IGNvbW1l bnRzIGFyZSBtb3JlIHNwZWNpZmljIHRvIHRoZSBjb250ZW50cyBvZiB0aGUgZG9jdW1lbnQuLi4N Cg0KVGhlICJwcm92aWRlZC1ieSIgVVJJIGlzIHByb2JhYmx5IGJldHRlciB0aGFuIHRoZSBzdHJ1 Y3R1cmUgaW4gUElERi1MTywgYnV0IGhvdyBkbyB5b3UgZW52aXNhZ2UgdGhpcyB3b3JraW5nPyAg VGhlIDxwcm92aWRlZC1ieT4gZWxlbWVudCBpcyBjdXJyZW50bHkgdW5kZXJzcGVjaWZpZWQsIHNv IGFuIGV4YW1wbGUgbWlnaHQgYmUgdXNlZnVsIGhlcmUuICBJcyB0aGlzIFVSSSBzb21ldGhpbmcg dGhhdCBpcyBpbmNsdWRlZCBpbiB0aGUgUElERi1MTyBkaXJlY3RseT8gIElmIHNvLCBkbyB5b3Ug d2FudCB0byByZWdpc3RlciBhIFVSTiBhbmQgc2NoZW1hIGZvciB0aGUgPHByb3ZpZGVkLWJ5PiBj b250ZW50cz8gIE9SIGlzIHRoZSBpbnRlbnQgb2YgdGhpcyBVUkkgdGhhdCB0aGUgZW5kcG9pbnQg ZGVyZWZlcmVuY2VzIHRoZSBVUkkgYW5kIHJldHJpZXZlcyBhbiBYTUwgZnJhZ21lbnQgY29udGFp bmluZyB0aGUgPHByb3ZpZGVkLWJ5PiBjb250ZW50cz8gIEluIHdoaWNoIGNhc2UgZG8geW91IGV4 cGVjdCB0aGF0IGFwcGxpY2F0aW9uL3htbCBpcyBzdWZmaWNpZW50IGFzIGEgTUlNRS10eXBlPw0K DQpJIHRoaW5rIHRoYXQgZnJvbSBhIHVzZXIgcGVyc3BlY3RpdmUgdGhlIEVTUlAgYW5kIFBTQVAg c2hvdWxkIGFwcGVhciB0byBiZSB0aGUgc2FtZSBlbnRpdHkuICBUaGlzIGlzIHJlYWxseSBhIHF1 ZXN0aW9uIG9mIGRlZ3JlZTogZG8gSSB3YW50IHRoZSBTSVAgVVJJIGZvciBhbiBpbmRpdmlkdWFs IFBTQVAgb3BlcmF0b3I/ICBGb3IgaW5zdGFuY2UsIGVtZXJnZW5jeUBteS5sb2NhbC5hcmVhIHNo b3VsZCBiZSBlbm91Z2ggLSBJIGRvbid0IGNhcmUgd2hhdCBpcyBkb25lIGJleW9uZCB0aGlzIHBv aW50LiAgSSBhc3N1bWUgdGhhdCBjb250YWN0aW5nIGVtZXJnZW5jeUBteS5sb2NhbC5hcmVhIHdp bGwgZ2V0IG1lIGhlbHAuDQoNCkRpc3Rpbmd1aXNoaW5nIGJldHdlZW4gYW4gRVNHVyBhbmQgRVNS UCBpcyBldmVuIGxlc3MgdXNlZnVsIC0gSSB3b3VsZCBob3BlIHRoYXQgdGhleSBhbGwgYXBwZWFy IHRoZSBzYW1lIHRvIHRoZSBlbmQgdXNlci4NCg0KSSB0aGluayB0aGF0IHdlIHNob3VsZCBhbHNv IG1hbmRhdGUgdGhhdCBhIG1hcHBpbmcgc2VydmljZSB1c2UgYSBQSURGLUxPIGFzIGlucHV0LCB0 aGVyZWZvcmUgZGlzdGluZ3Vpc2hpbmcgYmV0d2VlbiBhIGNpdmljIGFuZCBnZW8gbWFwcGluZyBz ZXJ2aWNlIGRvZXMgbm90IGFkZCBhbnkgdmFsdWUuICBUaGUgY2FwYWJpbGl0aWVzIG9mIHRoZSBt YXBwaW5nIHNlcnZpY2UgKHRoZSBhYmlsaXR5IHRvIGFjY2VwdCBjaXZpYyBvciBnZW8gaW5wdXQp IGFyZSBtZXRhZGF0YS4NCg0KQ2hlZXJzLA0KTWFydGluIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQg cmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwg b3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVk IGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBk ZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwg aXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K W21mMl0= --===============0434026173== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0434026173==-- From ecrit-bounces@ietf.org Wed Sep 14 21:08:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFiEi-0000pS-1g; Wed, 14 Sep 2005 21:08:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFiEg-0000pN-Na for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 21:08:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24537 for ; Wed, 14 Sep 2005 21:08:20 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFiJM-0006Z2-E0 for ecrit@ietf.org; Wed, 14 Sep 2005 21:13:15 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 14 Sep 2005 18:08:11 -0700 X-IronPort-AV: i="3.97,111,1125903600"; d="scan'208"; a="212011122:sNHT56843228" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j8F17qW3020958; Wed, 14 Sep 2005 18:08:01 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 18:07:57 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.121.125]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 18:07:56 -0700 Message-Id: <4.3.2.7.2.20050914194328.028f1090@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Sep 2005 20:07:55 -0500 To: "Thomson, Martin" , From: "James M. Polk" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 15 Sep 2005 01:07:56.0933 (UTC) FILETIME=[E856DB50:01C5B991] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: Subject: [Ecrit] Re: draft-polk-dhc-uri-00: mixed goals X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 07:31 PM 9/14/2005 -0500, Thomson, Martin wrote: >To put this into perspective, I like the idea of this draft - I can see >how this would be beneficial, Thank you >but I have a few questions. don't you always? ;-) > From a high level, when you look at the abstract, the draft talks about > URIs - no specific topic. yep > So this draft has the potential to cover a wide array of URI-type > configuration information. yep >All present URIs are mapping or emergency based, obviously driven by need. yep >Is this draft intended to be a container for future URI-type configuration >information? yep >If this is going to be a container, why then use up numbers so rapidly >with primary and secondary options? How many URIs do you feel qualify as configuration information? I hope not 255, but I could be wrong - as I've already received a comment I should make the purpose byte 2 bytes long. I know there will be resistance in the DHC community to overloading their servers with that many URIs, so I thought I'd leave it at 1 byte in length (255 possible URI types) until someone from that WG told me to up it). >Why not provide a list in each option, similar to the way that RFC 3361 >and RFC 3397 provide a list of domain names? That would enable the >provision of more than two fallback values if necessary - keeping in mind >Michael's point that we already have means of fallback at other layers. yeah - this is why I don't know if we need to address more than two URIs for PSAPs, as the network, if designed right, ought to route around problems. I mean, it's not like a URI is the same as an IP address. www.google.com has many ways to it through many IP addresses. >The rest of my comments are more specific to the contents of the document... > >The "provided-by" URI is probably better than the structure in PIDF-LO, >but how do you envisage this working? I see, for example, both Option 123 and this doc's Option in the Request/Response from the server to bind the two, with the purpose=6 (Org owning the Location) being exactly what is put into the element within the PIDF-LO. This solves that nasty little discussion we all had for about a year in "how do we learn this URL for 3825 and the civic Option?" If they are in the same DHCP message, that ought to be a good enough bind to Mr White-hat to allow troubleshooting of bad location information after-the-fact. >The element is currently underspecified, so an example might >be useful here. I am cautious of putting that in the DHC doc, and want that in another Arch doc where the scemantics can be layed out within the context we want. Maybe I'm being overly sensitive to the DHC WG not caring about these specific URIs and getting hammered with all our messages back and forth clarifying this or that. But I can be talked into adding this type of example for each purpose value into this doc if folks want that. >Is this URI something that is included in the PIDF-LO directly? yep - and that ought to go into one of ECRIT's docs >If so, do you want to register a URN and schema for the >contents? Not sure on this - but I really had something like www.cisco.com/richardson in mind for this, denoting Cisco was the company that gave out the location info, and it was out of their Richardson (in this case Texas) office. I thought this should give enough info to whomever to do the troubleshooting. I really hadn't thought it needed to be much more complicated than that. Maybe I'm being naive. >OR is the intent of this URI that the endpoint dereferences the URI and >retrieves an XML fragment containing the contents? In which >case do you expect that application/xml is sufficient as a MIME-type? > >I think that from a user perspective the ESRP and PSAP should appear to be >the same entity. This could be a policy area in which only one is returned to the client. We can make that semantic clear in an ECRIT Arch/BCP type doc. Something like: "If the client asks for a PSAP URI, and gets back a ESRP URI, it MUST be satisfied with that URI and treat it the same." >This is really a question of degree: do I want the SIP URI for an >individual PSAP operator? Again - this is a policy decision I didn't want this doc to deal with, so I put in both (and one backup) >For instance, emergency@my.local.area should be enough - I don't care what >is done beyond this point. I assume that contacting >emergency@my.local.area will get me help. I agree >Distinguishing between an ESGW and ESRP is even less useful - I would hope >that they all appear the same to the end user. This is something that might be important to the end user, but might be important to the operator - in that >I think that we should also mandate that a mapping service use a PIDF-LO >as input, therefore distinguishing between a civic and geo mapping service >does not add any value. Andy Newton asked for these, and he can give more justification for them (I've slept since he talked me into adding them). >The capabilities of the mapping service (the ability to accept civic or >geo input) are metadata. > >Cheers, >Martin > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] 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 Sep 14 21:46:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFipH-0001ju-2h; Wed, 14 Sep 2005 21:46:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFipE-0001jm-Q6 for ecrit@megatron.ietf.org; Wed, 14 Sep 2005 21:46:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26508 for ; Wed, 14 Sep 2005 21:46:06 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFitv-0007YU-TP for ecrit@ietf.org; Wed, 14 Sep 2005 21:51:01 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 20:45:58 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 14 Sep 2005 20:45:58 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 20:45:57 -0500 Message-ID: From: "Thomson, Martin" To: "James M. Polk" , Date: Wed, 14 Sep 2005 20:45:55 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 15 Sep 2005 01:45:57.0475 (UTC) FILETIME=[37A5F330:01C5B997] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: draft-polk-dhc-uri-00: mixed goals Thread-Index: AcW5kfI7zKcmbnnpTsK4oaX1rE0TpQAAbn0g X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: Subject: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals 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="===============0061042812==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============0061042812== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgcXVpY2sgcmVzcG9uc2UsIGJ1dCBJIHRoaW5rIHlvdSBoYXZlIG1lIG1p c3Rha2VuIGZvciBzb21lb25lIGVsc2UgOykNCg0KSSBhbSBvZiB0aGUgbWluZCB0aGF0IDI1NSBw dXJwb3NlIGNvZGVzIHNob3VsZCBiZSBlbm91Z2g7IGxpc3RzIG9mIFVSSXMgY291bGQgaGVscCBp biB0aGF0LiAgT25lIHRoaW5nIHRoYXQgbWlnaHQgYmUgd29ydGggY29uc2lkZXJpbmcgaXMgdGhh dCBkaWZmZXJlbnQgVVJJcyBtYXkgcmVwcmVzZW50IHNlcnZpY2VzIHdpdGggZGlmZmVyZW50IGNh cGFiaWxpdGllcyAtIGhhdmluZyBtdWx0aXBsZSBvcHRpb25zIG1pZ2h0IGhlbHAgdGhlcmUuICBU aGF0IG1pZ2h0IG5vdCBhcHBseSBmb3IgZW1lcmdlbmN5LCBidXQgaWYgeW91IGFyZSB0YWxraW5n IGEgZ2VuZXJhbCBzb2x1dGlvbiwgd2h5IG5vdCBpbmNsdWRlIHRoZSBvcHRpb24/ICBNYXliZSBv dGhlcnMgY2FuIGFkZCB3ZWlnaHQgdG8gb25lIGFyZ3VtZW50IG9yIHRoZSBvdGhlci4NCg0KV2l0 aCByZWdhcmRzIHRvIHRoZSA8cHJvdmlkZWQtYnk+LCB0aGUgUElERi1MTyBzb29uLVJGQyBzYXlz IHRoYXQgY29udGVudCBuZWVkcyB0byBiZSByZWdpc3RlcmVkIHdpdGggSUFOQS4gIEN1cnJlbnRs eSBVUkktc3R5bGUgY29udGVudCBpcyBub3QgYW4gb3B0aW9uOyB0aGVyZSBpcyBvbmx5IHRoZSBO RU5BIGRlZmluaXRpb24gKGluY2lkZW50YWxseSwgdGhpcyBpcyBicm9rZW4sIGJlY2F1c2UgYSB0 ZWw6IFVSSSBvZiBvbmx5IDEwIGNoYXJhY3RlcnMgaXNuJ3QgbXVjaCB1c2UpLiAgVGhpcyB3b3Vs ZCBzdWdnZXN0IHRoYXQgdG8gaW5jbHVkZSBhIFVSSSB5b3UgbmVlZCB0byBkZWZpbmUgYSByZWdp c3RlcmVkIGZvcm1hdCwgcHJvYmFibHkgd2l0aCBzY2hlbWEuICBBbHNvLCB0aGUgZm9ybWF0IHRo YXQgeW91IGRlc2NyaWJlIGlzIHNvbWV0aGluZyBsaWtlIGEgVVJOLCBidXQgZGlkIHlvdSBpbnRl bmQgdG8gZm9ybWFsaXplIHRoaXMgZGVmaW5pdGlvbj8gIE9yLCBtZXJlbHkgaGF2ZSBpdCBhcyBh biBpbmZvcm1hbCBpbmRpY2F0b3IgKHdoaWNoIEkgdGhpbmsgaXMgeW91ciBpbnRlbnRpb24pLiAg QW55IGNvbXBsZXhpdHkgbWlnaHQgZGVwZW5kIG9uIHdoYXQgcGVvcGxlIHdhbnQgdG8gdXNlIHRo aXMgaW5mb3JtYXRpb24gZm9yOyBJIHdvdWxkbid0IHdhbnQgdG8gc3VnZ2VzdCB0aGF0IHlvdSBh cmUgbmHDr3ZlLCBidXQgbWF5YmUgdGhlcmUgYXJlIG1vcmUgdXNlcyB0aGFuIHRoYXQuDQoNCkJ5 IHRoZSB3YXksIHRoaXMgc3RhcnRzIHRvIGJsdXIgdGhlIGxpbmUgYmV0d2VlbiBFQ1JJVCBhbmQg R0VPUFJJVi4NCg0KV2hlbiBJIHRhbGsgYWJvdXQgUFNBUCB2cy4gRVNSUCB2cy4gRVNHVyBVUklz IEkgYW0gYWN0dWFsbHkgdGFsa2luZyBhYm91dCB0aGUgc2FtZSBzb3J0IG9mIHBvbGljeSB0aGF0 IHlvdSBhcmUgdGFsa2luZyBhYm91dC4gIFRoYXQgaXMsIHRoZSBkZWNpc2lvbiBvZiB0aGUgZW1l cmdlbmN5IG9wZXJhdG9yIHRvIHByb3ZpZGUgYSB1c2VmdWwgVVJJLCByZWdhcmRsZXNzIG9mIHRo ZSB0eXBlIG9mIGVudGl0eSB0aGF0IGFjdHVhbGx5IGdldHMgcm91dGVkIHRvLiAgSSBqdXN0IGRv bid0IHNlZSB3aGVyZSBrbm93aW5nIHRoZSBkaWZmZXJlbmNlIGlzIG9mIGJlbmVmaXQgdG8gYW55 b25lLiAgV2h5IGNhbid0IHdlIGp1c3QgaGF2ZSBvbmUgZW1lcmdlbmN5IFVSST8NCg0KSSBiZWxp ZXZlIHRoYXQgYW4gZW1lcmdlbmN5IG9wZXJhdG9yIHVzZXMgYW4gRVNSUCBhbmQgRVNHVyBpbiB0 aGUgc2FtZSB3YXkgdGhhdCB0aGV5IHVzZSBlbWVyZ2VuY3lAbXkubG9jYWwuYXJlYSByYXRoZXIg dGhhbiBvcGVyYXRvci5qYW5lQG15LmxvY2FsLnBzYXA7IEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGlz IGlzIG92ZXJzaW1wbGlmaWNhdGlvbiwgYnV0IEkgd291bGQgYmUgd2lsbGluZyB0byBjb25zaWRl ciByZWFzb25zIHdoeSBzb21lb25lIChhbnlvbmUpIHdvdWxkIHdhbnQgdG8ga25vdyB0aGUgZGlm ZmVyZW5jZS4NCg0KQlRXLCBJIHRoaW5rIHlvdSBtZWFudCB0byBzYXkgc29tZXRoaW5nIG1vcmUg aGVyZSAob24gRVNHVyBhbmQgRVNSUCBVUklzKToNCj4gVGhpcyBpcyBzb21ldGhpbmcgdGhhdCBt aWdodCBiZSBpbXBvcnRhbnQgdG8gdGhlIGVuZCB1c2VyLCBidXQgbWlnaHQgYmUgDQo+IGltcG9y dGFudCB0byB0aGUgb3BlcmF0b3IgLSBpbiB0aGF0DQoNClRhLA0KTWFydGluDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEphbWVzIE0uIFBvbGsgW21haWx0bzpqbXBvbGtA Y2lzY28uY29tXSANClNlbnQ6IFRodXJzZGF5LCAxNSBTZXB0ZW1iZXIgMjAwNSAxMTowOCBBTQ0K VG86IFRob21zb24sIE1hcnRpbjsgZWNyaXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBkcmFmdC1w b2xrLWRoYy11cmktMDA6IG1peGVkIGdvYWxzDQoNCkF0IDA3OjMxIFBNIDkvMTQvMjAwNSAtMDUw MCwgVGhvbXNvbiwgTWFydGluIHdyb3RlOg0KPlRvIHB1dCB0aGlzIGludG8gcGVyc3BlY3RpdmUs IEkgbGlrZSB0aGUgaWRlYSBvZiB0aGlzIGRyYWZ0IC0gSSBjYW4gc2VlIA0KPmhvdyB0aGlzIHdv dWxkIGJlIGJlbmVmaWNpYWwsDQoNClRoYW5rIHlvdQ0KDQo+YnV0IEkgaGF2ZSBhIGZldyBxdWVz dGlvbnMuDQoNCmRvbid0IHlvdSBhbHdheXM/DQoNCjstKQ0KDQoNCj4gRnJvbSBhIGhpZ2ggbGV2 ZWwsIHdoZW4geW91IGxvb2sgYXQgdGhlIGFic3RyYWN0LCB0aGUgZHJhZnQgdGFsa3MgYWJvdXQg DQo+IFVSSXMgLSBubyBzcGVjaWZpYyB0b3BpYy4NCg0KeWVwDQoNCj4gIFNvIHRoaXMgZHJhZnQg aGFzIHRoZSBwb3RlbnRpYWwgdG8gY292ZXIgYSB3aWRlIGFycmF5IG9mIFVSSS10eXBlIA0KPiBj b25maWd1cmF0aW9uIGluZm9ybWF0aW9uLg0KDQp5ZXANCg0KPkFsbCBwcmVzZW50IFVSSXMgYXJl IG1hcHBpbmcgb3IgZW1lcmdlbmN5IGJhc2VkLCBvYnZpb3VzbHkgZHJpdmVuIGJ5IG5lZWQuDQoN CnllcA0KDQoNCj5JcyB0aGlzIGRyYWZ0IGludGVuZGVkIHRvIGJlIGEgY29udGFpbmVyIGZvciBm dXR1cmUgVVJJLXR5cGUgY29uZmlndXJhdGlvbiANCj5pbmZvcm1hdGlvbj8NCg0KeWVwDQoNCg0K PklmIHRoaXMgaXMgZ29pbmcgdG8gYmUgYSBjb250YWluZXIsIHdoeSB0aGVuIHVzZSB1cCBudW1i ZXJzIHNvIHJhcGlkbHkgDQo+d2l0aCBwcmltYXJ5IGFuZCBzZWNvbmRhcnkgb3B0aW9ucz8NCg0K SG93IG1hbnkgVVJJcyBkbyB5b3UgZmVlbCBxdWFsaWZ5IGFzIGNvbmZpZ3VyYXRpb24gaW5mb3Jt YXRpb24/DQoNCkkgaG9wZSBub3QgMjU1LCBidXQgSSBjb3VsZCBiZSB3cm9uZyAtIGFzIEkndmUg YWxyZWFkeSByZWNlaXZlZCBhIGNvbW1lbnQgSSANCnNob3VsZCBtYWtlIHRoZSBwdXJwb3NlIGJ5 dGUgMiBieXRlcyBsb25nLg0KDQpJIGtub3cgdGhlcmUgd2lsbCBiZSByZXNpc3RhbmNlIGluIHRo ZSBESEMgY29tbXVuaXR5IHRvIG92ZXJsb2FkaW5nIHRoZWlyIA0Kc2VydmVycyB3aXRoIHRoYXQg bWFueSBVUklzLCBzbyBJIHRob3VnaHQgSSdkIGxlYXZlIGl0IGF0IDEgYnl0ZSBpbiBsZW5ndGgg DQooMjU1IHBvc3NpYmxlIFVSSSB0eXBlcykgdW50aWwgc29tZW9uZSBmcm9tIHRoYXQgV0cgdG9s ZCBtZSB0byB1cCBpdCkuDQoNCj5XaHkgbm90IHByb3ZpZGUgYSBsaXN0IGluIGVhY2ggb3B0aW9u LCBzaW1pbGFyIHRvIHRoZSB3YXkgdGhhdCBSRkMgMzM2MSANCj5hbmQgUkZDIDMzOTcgcHJvdmlk ZSBhIGxpc3Qgb2YgZG9tYWluIG5hbWVzPyAgVGhhdCB3b3VsZCBlbmFibGUgdGhlIA0KPnByb3Zp c2lvbiBvZiBtb3JlIHRoYW4gdHdvIGZhbGxiYWNrIHZhbHVlcyBpZiBuZWNlc3NhcnkgLSBrZWVw aW5nIGluIG1pbmQgDQo+TWljaGFlbCdzIHBvaW50IHRoYXQgd2UgYWxyZWFkeSBoYXZlIG1lYW5z IG9mIGZhbGxiYWNrIGF0IG90aGVyIGxheWVycy4NCg0KeWVhaCAtIHRoaXMgaXMgd2h5IEkgZG9u J3Qga25vdyBpZiB3ZSBuZWVkIHRvIGFkZHJlc3MgbW9yZSB0aGFuIHR3byBVUklzIA0KZm9yIFBT QVBzLCBhcyB0aGUgbmV0d29yaywgaWYgZGVzaWduZWQgcmlnaHQsIG91Z2h0IHRvIHJvdXRlIGFy b3VuZCANCnByb2JsZW1zLiAgSSBtZWFuLCBpdCdzIG5vdCBsaWtlIGEgVVJJIGlzIHRoZSBzYW1l IGFzIGFuIElQIGFkZHJlc3MuDQoNCnd3dy5nb29nbGUuY29tIGhhcyBtYW55IHdheXMgdG8gaXQg dGhyb3VnaCBtYW55IElQIGFkZHJlc3Nlcy4NCg0KDQo+VGhlIHJlc3Qgb2YgbXkgY29tbWVudHMg YXJlIG1vcmUgc3BlY2lmaWMgdG8gdGhlIGNvbnRlbnRzIG9mIHRoZSBkb2N1bWVudC4uLg0KPg0K PlRoZSAicHJvdmlkZWQtYnkiIFVSSSBpcyBwcm9iYWJseSBiZXR0ZXIgdGhhbiB0aGUgc3RydWN0 dXJlIGluIFBJREYtTE8sIA0KPmJ1dCBob3cgZG8geW91IGVudmlzYWdlIHRoaXMgd29ya2luZz8N Cg0KSSBzZWUsIGZvciBleGFtcGxlLCBib3RoIE9wdGlvbiAxMjMgYW5kIHRoaXMgZG9jJ3MgT3B0 aW9uIGluIHRoZSANClJlcXVlc3QvUmVzcG9uc2UgZnJvbSB0aGUgc2VydmVyIHRvIGJpbmQgdGhl IHR3bywgd2l0aCB0aGUgcHVycG9zZT02IChPcmcgDQpvd25pbmcgdGhlIExvY2F0aW9uKSBiZWlu ZyBleGFjdGx5IHdoYXQgaXMgcHV0IGludG8gdGhlIDxwcm92aWRlZC1ieT4gDQplbGVtZW50IHdp dGhpbiB0aGUgUElERi1MTy4gVGhpcyBzb2x2ZXMgdGhhdCBuYXN0eSBsaXR0bGUgZGlzY3Vzc2lv biB3ZSBhbGwgDQpoYWQgZm9yIGFib3V0IGEgeWVhciBpbiAiaG93IGRvIHdlIGxlYXJuIHRoaXMg VVJMIGZvciAzODI1IGFuZCB0aGUgY2l2aWMgDQpPcHRpb24/IiBJZiB0aGV5IGFyZSBpbiB0aGUg c2FtZSBESENQIG1lc3NhZ2UsIHRoYXQgb3VnaHQgdG8gYmUgYSBnb29kIA0KZW5vdWdoIGJpbmQg dG8gTXIgV2hpdGUtaGF0IHRvIGFsbG93IHRyb3VibGVzaG9vdGluZyBvZiBiYWQgbG9jYXRpb24g DQppbmZvcm1hdGlvbiBhZnRlci10aGUtZmFjdC4NCg0KPlRoZSA8cHJvdmlkZWQtYnk+IGVsZW1l bnQgaXMgY3VycmVudGx5IHVuZGVyc3BlY2lmaWVkLCBzbyBhbiBleGFtcGxlIG1pZ2h0IA0KPmJl IHVzZWZ1bCBoZXJlLg0KDQpJIGFtIGNhdXRpb3VzIG9mIHB1dHRpbmcgdGhhdCBpbiB0aGUgREhD IGRvYywgYW5kIHdhbnQgdGhhdCBpbiBhbm90aGVyIEFyY2ggDQpkb2Mgd2hlcmUgdGhlIHNjZW1h bnRpY3MgY2FuIGJlIGxheWVkIG91dCB3aXRoaW4gdGhlIGNvbnRleHQgd2UgDQp3YW50LiAgTWF5 YmUgSSdtIGJlaW5nIG92ZXJseSBzZW5zaXRpdmUgdG8gdGhlIERIQyBXRyBub3QgY2FyaW5nIGFi b3V0IA0KdGhlc2Ugc3BlY2lmaWMgVVJJcyBhbmQgZ2V0dGluZyBoYW1tZXJlZCB3aXRoIGFsbCBv dXIgbWVzc2FnZXMgYmFjayBhbmQgDQpmb3J0aCBjbGFyaWZ5aW5nIHRoaXMgb3IgdGhhdC4NCg0K QnV0IEkgY2FuIGJlIHRhbGtlZCBpbnRvIGFkZGluZyB0aGlzIHR5cGUgb2YgZXhhbXBsZSBmb3Ig ZWFjaCBwdXJwb3NlIHZhbHVlIA0KaW50byB0aGlzIGRvYyBpZiBmb2xrcyB3YW50IHRoYXQuDQoN Cj5JcyB0aGlzIFVSSSBzb21ldGhpbmcgdGhhdCBpcyBpbmNsdWRlZCBpbiB0aGUgUElERi1MTyBk aXJlY3RseT8NCg0KeWVwIC0gYW5kIHRoYXQgb3VnaHQgdG8gZ28gaW50byBvbmUgb2YgRUNSSVQn cyBkb2NzDQoNCj5JZiBzbywgZG8geW91IHdhbnQgdG8gcmVnaXN0ZXIgYSBVUk4gYW5kIHNjaGVt YSBmb3IgdGhlIDxwcm92aWRlZC1ieT4gDQo+Y29udGVudHM/DQoNCk5vdCBzdXJlIG9uIHRoaXMg LSBidXQgSSByZWFsbHkgaGFkIHNvbWV0aGluZyBsaWtlIHd3dy5jaXNjby5jb20vcmljaGFyZHNv biANCmluIG1pbmQgZm9yIHRoaXMsIGRlbm90aW5nIENpc2NvIHdhcyB0aGUgY29tcGFueSB0aGF0 IGdhdmUgb3V0IHRoZSBsb2NhdGlvbiANCmluZm8sIGFuZCBpdCB3YXMgb3V0IG9mIHRoZWlyIFJp Y2hhcmRzb24gKGluIHRoaXMgY2FzZSBUZXhhcykgb2ZmaWNlLiBJIA0KdGhvdWdodCB0aGlzIHNo b3VsZCBnaXZlIGVub3VnaCBpbmZvIHRvIHdob21ldmVyIHRvIGRvIHRoZSB0cm91Ymxlc2hvb3Rp bmcuDQoNCkkgcmVhbGx5IGhhZG4ndCB0aG91Z2h0IGl0IG5lZWRlZCB0byBiZSBtdWNoIG1vcmUg Y29tcGxpY2F0ZWQgdGhhbiANCnRoYXQuICBNYXliZSBJJ20gYmVpbmcgbmFpdmUuDQoNCj5PUiBp cyB0aGUgaW50ZW50IG9mIHRoaXMgVVJJIHRoYXQgdGhlIGVuZHBvaW50IGRlcmVmZXJlbmNlcyB0 aGUgVVJJIGFuZCANCj5yZXRyaWV2ZXMgYW4gWE1MIGZyYWdtZW50IGNvbnRhaW5pbmcgdGhlIDxw cm92aWRlZC1ieT4gY29udGVudHM/ICBJbiB3aGljaCANCj5jYXNlIGRvIHlvdSBleHBlY3QgdGhh dCBhcHBsaWNhdGlvbi94bWwgaXMgc3VmZmljaWVudCBhcyBhIE1JTUUtdHlwZT8NCj4NCj5JIHRo aW5rIHRoYXQgZnJvbSBhIHVzZXIgcGVyc3BlY3RpdmUgdGhlIEVTUlAgYW5kIFBTQVAgc2hvdWxk IGFwcGVhciB0byBiZSANCj50aGUgc2FtZSBlbnRpdHkuDQoNClRoaXMgY291bGQgYmUgYSBwb2xp Y3kgYXJlYSBpbiB3aGljaCBvbmx5IG9uZSBpcyByZXR1cm5lZCB0byB0aGUgY2xpZW50LiBXZSAN CmNhbiBtYWtlIHRoYXQgc2VtYW50aWMgY2xlYXIgaW4gYW4gRUNSSVQgQXJjaC9CQ1AgdHlwZSBk b2MuIFNvbWV0aGluZyBsaWtlOg0KDQoiSWYgdGhlIGNsaWVudCBhc2tzIGZvciBhIFBTQVAgVVJJ LCBhbmQgZ2V0cyBiYWNrIGEgRVNSUCBVUkksIGl0IE1VU1QgYmUgDQpzYXRpc2ZpZWQgd2l0aCB0 aGF0IFVSSSBhbmQgdHJlYXQgaXQgdGhlIHNhbWUuIg0KDQo+VGhpcyBpcyByZWFsbHkgYSBxdWVz dGlvbiBvZiBkZWdyZWU6IGRvIEkgd2FudCB0aGUgU0lQIFVSSSBmb3IgYW4gDQo+aW5kaXZpZHVh bCBQU0FQIG9wZXJhdG9yPw0KDQpBZ2FpbiAtIHRoaXMgaXMgYSBwb2xpY3kgZGVjaXNpb24gSSBk aWRuJ3Qgd2FudCB0aGlzIGRvYyB0byBkZWFsIHdpdGgsIHNvIEkgDQpwdXQgaW4gYm90aCAoYW5k IG9uZSBiYWNrdXApDQoNCj5Gb3IgaW5zdGFuY2UsIGVtZXJnZW5jeUBteS5sb2NhbC5hcmVhIHNo b3VsZCBiZSBlbm91Z2ggLSBJIGRvbid0IGNhcmUgd2hhdCANCj5pcyBkb25lIGJleW9uZCB0aGlz IHBvaW50LiAgSSBhc3N1bWUgdGhhdCBjb250YWN0aW5nIA0KPmVtZXJnZW5jeUBteS5sb2NhbC5h cmVhIHdpbGwgZ2V0IG1lIGhlbHAuDQoNCkkgYWdyZWUNCg0KDQo+RGlzdGluZ3Vpc2hpbmcgYmV0 d2VlbiBhbiBFU0dXIGFuZCBFU1JQIGlzIGV2ZW4gbGVzcyB1c2VmdWwgLSBJIHdvdWxkIGhvcGUg DQo+dGhhdCB0aGV5IGFsbCBhcHBlYXIgdGhlIHNhbWUgdG8gdGhlIGVuZCB1c2VyLg0KDQpUaGlz IGlzIHNvbWV0aGluZyB0aGF0IG1pZ2h0IGJlIGltcG9ydGFudCB0byB0aGUgZW5kIHVzZXIsIGJ1 dCBtaWdodCBiZSANCmltcG9ydGFudCB0byB0aGUgb3BlcmF0b3IgLSBpbiB0aGF0DQoNCg0KPkkg dGhpbmsgdGhhdCB3ZSBzaG91bGQgYWxzbyBtYW5kYXRlIHRoYXQgYSBtYXBwaW5nIHNlcnZpY2Ug dXNlIGEgUElERi1MTyANCj5hcyBpbnB1dCwgdGhlcmVmb3JlIGRpc3Rpbmd1aXNoaW5nIGJldHdl ZW4gYSBjaXZpYyBhbmQgZ2VvIG1hcHBpbmcgc2VydmljZSANCj5kb2VzIG5vdCBhZGQgYW55IHZh bHVlLg0KDQpBbmR5IE5ld3RvbiBhc2tlZCBmb3IgdGhlc2UsIGFuZCBoZSBjYW4gZ2l2ZSBtb3Jl IGp1c3RpZmljYXRpb24gZm9yIHRoZW0gDQooSSd2ZSBzbGVwdCBzaW5jZSBoZSB0YWxrZWQgbWUg aW50byBhZGRpbmcgdGhlbSkuDQoNCj5UaGUgY2FwYWJpbGl0aWVzIG9mIHRoZSBtYXBwaW5nIHNl cnZpY2UgKHRoZSBhYmlsaXR5IHRvIGFjY2VwdCBjaXZpYyBvciANCj5nZW8gaW5wdXQpIGFyZSBt ZXRhZGF0YS4NCj4NCj5DaGVlcnMsDQo+TWFydGluDQo8c25pcCB1Z2x5IGRpc2NsYWltZXI+DQoN CmNoZWVycywNCkphbWVzDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICoqKioq KioqKioqKioqKioqKioNCiAgICAgICAgICAgICAgICAgVHJ1dGggaXMgbm90IHRvIGJlIGFyZ3Vl ZC4uLiBpdCBpcyB0byBiZSBwcmVzZW50ZWQuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGll bnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhl cndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0 aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9o aWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ== --===============0061042812== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0061042812==-- From ecrit-bounces@ietf.org Thu Sep 15 02:05:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFms9-00077u-DQ; Thu, 15 Sep 2005 02:05:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFms7-00077p-UA for ecrit@megatron.ietf.org; Thu, 15 Sep 2005 02:05:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12291 for ; Thu, 15 Sep 2005 02:05:22 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFmwq-0005NF-F6 for ecrit@ietf.org; Thu, 15 Sep 2005 02:10:18 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Sep 2005 01:05:10 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 15 Sep 2005 01:05:09 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Sep 2005 01:05:08 -0500 Message-ID: From: "Thomson, Martin" To: "James M. Polk" , Date: Thu, 15 Sep 2005 01:05:07 -0500 Subject: RE: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 15 Sep 2005 06:05:08.0802 (UTC) FILETIME=[6CF62220:01C5B9BB] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals Thread-Index: AcW5kfI7zKcmbnnpTsK4oaX1rE0TpQAAbn0gAAla4uA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1817734734==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============1817734734== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message Content-Transfer-Encoding: base64 SGkgSmFtZXMsDQoNClNvcnJ5LCBicmFpbiBzZWVtcyB0byBiZSBiZWhhdmluZyBvZGRseSB0b2Rh eSAtIEkgaGF2ZSBtb3JlICh5ZXMsIHRoZXJlIGlzIGFsd2F5cyBtb3JlKS4NCg0KSnVzdCBhbm90 aGVyIHRob3VnaHQgLSBpdCBpc24ndCBjbGVhciBpbiB0aGUgZG9jdW1lbnQgaG93IGEgY2xpZW50 IHJlcXVlc3RzIFVSSXMgZm9yIGEgc2luZ2xlIHB1cnBvc2UsIG9yIGlmIHRoZXkgY2FuIGF0IGFs bC4gIE9wdGlvbiA1NSBhbGxvd3MgdGhlIHJlcXVlc3Rpbmcgb2YgdGhpcyBvcHRpb24gKG9yIG5v dCksIGJ1dCBob3cgZG9lcyBhIGNsaWVudCBhdm9pZCBnZXR0aW5nIGFsbCBVUklzIHdoZW4gYWxs IHRoZXkgd2FudCBpcyB0aGUgVVJJIG9mIHRoZSBlbWVyZ2VuY3kgc2VydmljZT8NCg0KSSBkb24n dCB0aGluayB0aGF0IHlvdSBzaG91bGQgYXZvaWQgdGhpcyBwYXJ0aWN1bGFyIGZ1bmN0aW9uLCBw YXJ0aWN1bGFybHkgaWYgeW91IGludGVuZCB0aGlzIHRvIGJlIGEgY29udGFpbmVyIGZvciBtYW55 IGRpZmZlcmVudCBVUklzLg0KDQpUaGlzIGlzIGEgYml0IG9mIGEgc3RyZXRjaCwgYnV0IGl0IG1p Z2h0IHRyaWdnZXIgc29tZSB0aG91Z2h0cy4uLiAgTW9yZSBzZXJ2aWNlcyBhcmUgbW92aW5nIHRv IGEgd2ViIHNlcnZpY2VzIGluZnJhc3RydWN0dXJlOyBhbmQsIHdlYiBzZXJ2aWNlcyBjYW4gdXN1 YWxseSBiZSBkZXNjcmliZWQgYnkgYSBVUkkgKHdoaWNoIHByb2JhYmx5IHBvaW50cyB0byBhIFdT REwgZmlsZSAuLi4/KS4gIElzIHRoaXMgb3B0aW9uIGFwcGxpY2FibGUgdG8gd2ViIHNlcnZpY2Vz IHR5cGVzIG9mIGFwcGxpY2F0aW9ucywgb3IgaXMgVURESSBtb3JlIGFwcHJvcHJpYXRlPyAgQ291 bGQgdGhpcyBzZXJ2aWNlIGJlIGNoYXJhY3Rlcml6ZWQgYXMgYSB2ZXJ5IHNwZWNpZmljLCBsaW1p dGVkIHN1YnNldCBvZiB0aGF0IHNvcnQgb2Ygc2VydmljZT8NCg0KVGEsDQpNYXJ0aW4NCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGhvbXNvbiwgTWFydGlu DQpTZW50OiBUaHVyc2RheSwgMTUgU2VwdGVtYmVyIDIwMDUgMTE6NDYgQU0NClRvOiBKYW1lcyBN LiBQb2xrOyBlY3JpdEBpZXRmLm9yZw0KU3ViamVjdDogW0Vjcml0XSBSRTogZHJhZnQtcG9say1k aGMtdXJpLTAwOiBtaXhlZCBnb2Fscw0KDQo8c25pcD4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNp cGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBv dGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0 ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBw cm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYy XQ== --===============1817734734== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1817734734==-- From ecrit-bounces@ietf.org Thu Sep 15 03:32:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFoEW-0003QI-Hu; Thu, 15 Sep 2005 03:32:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFoES-0003Pf-H2 for ecrit@megatron.ietf.org; Thu, 15 Sep 2005 03:32:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24271 for ; Thu, 15 Sep 2005 03:32:30 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFoJC-0007fG-4z for ecrit@ietf.org; Thu, 15 Sep 2005 03:37:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] terminology Date: Thu, 15 Sep 2005 09:35:54 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B213C@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] terminology Thread-Index: AcW5fvT7u6J8UAdvTDyYyLQQAdfgMgAR8CDg From: "Stastny Richard" To: "James M. Polk" , "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 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 James Polk proposed: > Link Layer Provider (LLP) > Internet Layer Provider (ILP) > Application Layer Provider (ALP) I could live with these definitions, especially if we give the other terms as examples: ALP e.g. a VSP This also includes self-provision. And it would also save some discussions later if the example terms are not matching exactly. Now I cam move on to my next question: on which of these layers is the mapping database (LCMS) or the DNS in general? ;-) It may seem to some that I am picky here, but I consider this discussion as a trial run for the parallel discussions going on the exact same issues in voipeer and Carrier ENUM ;-) And the arguments and solutions found here will be very useful over there ;-) And over there there ARE business models involved. Cheers=20 Richard > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Thursday, September 15, 2005 12:48 AM > To: Henning Schulzrinne > Cc: Andrew Newton; Stastny Richard; ecrit@ietf.org > Subject: Re: [Ecrit] terminology >=20 > At 06:07 PM 9/14/2005 -0400, Henning Schulzrinne wrote: > >>I think I suggested this 3 hours ago, in which I said > > > >I'm sorry I missed this in the flood of messages today. > > > >>Link Provider (at Layer 2) > >>Internet Provider (at Layer 3/4/5) > > > >As far as I can tell, TCP (layer 4) is not provided by anyone except the > >two TCP end hosts. I don't think you'd want to call Microsoft an Internet > >Provider. I'm not sure what layer 5 is. >=20 > 3/4/5 is getting into the backbone nature of an IP transport function of > an > Internet Provider, like where RTP is (as was mentioned specifically in a > message within the last 24 hours) - perhaps I shouldn't use numbers other > than 3 for the Internet Provider. >=20 >=20 >=20 > >>Application (Service) Provider (at Layer 7) > > > >This division is fairly similar to the one that had been in many of the > >early requirements documents I had a hand in drafting. However, I tend to > >believe now that there are a sufficient number of corner cases where such > >terms will yield more confusion than insight. >=20 > we talk of a VSP without hesitation now, and that orgnaization is the > provider of a specific application. >=20 > If we agreed on the use of "Application" here to mean Layer 7 Provider, we > can get past the confusion - I hope. This is one reason why I think we > need > to get rid of the word "service" in ISP and ASP. That is the word I > believe > is the most confusing, because voice is a service, but in the context of > an > Internet Service Provider, the ISP might not be the one to provide that > service - hense there is confusion. >=20 >=20 >=20 >=20 > >>>As was mentioned, we don't really care about the business > relationships, > >>>but rather trust and management relationships, for example. > >> > >>I disagree with this statement because of the politics and regulation > >>(that's going to be) involved. Specifically with respect to the FCC's > >>ruling that Vonage-type companies MUST produce the 911 call at the > >>appropriate PSAP. This has little to do with trust, the way you're > >>meaning it (I believe). > > > >Unfortunately, these terms are not even clear within the regulatory > >community. Unless you want to say "A voice service provider is whatever > >the FCC believes today it happens to be (until some federal court tells > >them otherwise)", this doesn't help much. The only term they define, by > >the way, is "connected voice provider", which is yet another beast and > >clearly does not, for example, include (say) Yahoo! or FWD or (say) > >Jabber, although they would be considered an ASP according to most > >discussions we've had and I assume would an ASP in your estimation. >=20 > agreed >=20 >=20 > >In other words: not all ASPs are subject to emergency services mandates > >today in the US, >=20 > I absolutely agree with this, as we're focusing on voice first, with IM > and > video later; but for now, IM providers are not in this emergency services > mix. >=20 > >but some might be today or in other countries. > > > >In short: I think trying to follow the regulatory definitions gets us > into > >national regulations we have no way of tracking (nor should we try to). >=20 > I'm not saying "get into regulatory definitions" per se, unless there is > one staring us in the face like the recent one is (US FCC 05-116). Flying > in the face of this seems equally foolish IMO. >=20 > >We might hope that crisp, unambiguous, protocol-based definitions will > >eventually make it into regulations, but that's probably naive to hope > for. >=20 > I wish you had your way, I would prefer that too. >=20 > Perhaps we go with longer terms: >=20 > Link Layer Provider (LLP) > Internet Layer Provider (ILP) > Application Layer Provider (ALP) >=20 > I'm not trying to just come up with terms for the sake of terms, I'm > trying > to get to the point where everyone can agree on a set of meanings and have > discussions without having to define what is being discussed each time a > discussion comes up >=20 >=20 > >Henning >=20 >=20 > cheers, > James >=20 > ******************* > Truth is not to be argued... it is to be presented. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 15 04:30:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFp8l-00013R-OZ; Thu, 15 Sep 2005 04:30:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFp8k-000134-PQ for ecrit@megatron.ietf.org; Thu, 15 Sep 2005 04:30:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26530 for ; Thu, 15 Sep 2005 04:30:40 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFpDV-0000x4-CX for ecrit@ietf.org; Thu, 15 Sep 2005 04:35:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals Date: Thu, 15 Sep 2005 10:34:15 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B213E@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals Thread-Index: AcW5kfI7zKcmbnnpTsK4oaX1rE0TpQAAbn0gAA3Q3YA= From: "Stastny Richard" To: "Thomson, Martin" , "James M. Polk" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Sorry for jumping in into this discussion a bit late but I had no time up to now to read the draft completely I also apologize if I re-query some issues already discussed In principle I consider it as a good idea to have a vehicle to provide such information to a client. Having said this, I would like to discuss the purpose list in detail. Purpose =3D 1 (Primary PSAP URI) Purpose =3D 2 (Secondary PSAP URI) Purpose =3D 3 (Location By-Reference of Client) Purpose =3D 4 (ESGW URI of Client) Purpose =3D 5 (ESRP URI of Client) Purpose =3D 6 (Location Providing Location for Client) Purpose =3D 7 (URI of Geocoding/Reverse Geocoding) Purpose =3D 8 (Primary URI of Geo Mapping Service) Purpose =3D 9 (Secondary URI of Geo Mapping Service) Purpose =3D 10 (Primary URI of Civic Mapping Service) Purpose =3D 11 (Secondary URI of Civic Mapping Service) General remark 1 (this was already discussed): There needs to be a requirement in ecrit req I-D defining the TTL of such information and therefore the minimum lease time Also the concern of Brian regarding short time changes has to by taken into=20 account, which may render the transmissinon of the URI of the Mapping service and the PSAP useless, because then they always need to be queried at emergency call setup. General remark 2: Is it necessary to provide secondaries in general? Especially for SIP URIs (PSAP) this can be done with other means (e.g. SRV RR) Remark ESRP If you query the mapping service, you get back a SIP URI. You do not care if this is a PSAP direct or a ESRP. As far as I know there is no distinction within the proposed protocols. So why put this distinction here. If you have a distinction, you need first to get the date. Since the provider of this date may (Must?) derive this data from the mapping service anyway, how can he make the distinction? So IMHO this purpose is not needed. Remark ESGW: Now here I have a serious problem It is stated in the draft "This purpose=3D4 URI is for the Emergency Services Gateway that an = IP=20 client would contact when setting up an emergency call with a PSAP=20 that is not IP enabled. Having this information locally in the client will allow it to contact the ESGW directly and not have to=20 rely on an intermediary to determine which ESGW is the right one for this client, and possibly fail the call set-up during that=20 determination." We are planning to use ESGW, but these may accessed only via the ESRPs. The ESGW are basically PoIs to the PSTN. If you access the ESGW with a SIP URI, you are basically accessing a SIP proxy and then it is a ESRP. We are planning to access the ESGW with tel URIs via the ESRP. It is the task of the ESRP to map the location (via the mapping service or via a local DB to the NATIONAL routing numbers required to access the national emergency service network. This mapping is very national specific (it may not use E.164 numbers). Since the client is not able in most case to access the ESGW directly this purpose should not be there. Side remark: there are discussions here in Europe to provide international access to PSAPs (at least to a national default PSAP), as an intermediary solution for VSPs having no national gateway and if, they may need to know=20 the national practice, but I do not consider this as a good idea. In this case you may provide this TEL URI in the purpose. First, this is not generally available (some countries do not provide access to PSAPs via international calls) and second, it is only a deviating from the more straightforward solution using a national ESRP with access to a national ESGW. One possible solution here is to store in the mapping service in addition to the SIP URI to the ESRP (which is used by the clients) also a TEL URI with local context (which is then used only by the ESRP). The local context indicated that the TEL URI can only be interpreted by the specific national ESRP to provide the ESGW with the necessary routing information. Now one may consider to store this tel URI in the ESGW purpose, but since this information is useless to the client, I need not be there What I am missing in the I-D is a way to provide the client eventually with the local emergency identifiers Cheers Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 15 08:51:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFtD4-00037H-Jr; Thu, 15 Sep 2005 08:51:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFtD3-000359-12 for ecrit@megatron.ietf.org; Thu, 15 Sep 2005 08:51:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08360 for ; Thu, 15 Sep 2005 08:51:23 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFtHq-0008BJ-6Z for ecrit@ietf.org; Thu, 15 Sep 2005 08:56:23 -0400 Received: from [10.0.1.100] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 15 Sep 2005 08:51:19 -0400 id 000C7E0D.43296E47.00003AF8 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] draft-polk-dhc-uri-00: mixed goals Date: Thu, 15 Sep 2005 08:51:13 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 14, 2005, at 8:31 PM, Thomson, Martin wrote: > I think that we should also mandate that a mapping service use a > PIDF-LO as input, therefore distinguishing between a civic and geo > mapping service does not add any value. The capabilities of the > mapping service (the ability to accept civic or geo input) are > metadata. Martin, I'm not sure all of PIDF-LO should be a requirement, but certainly the location elements seem appropriate. As of my last reading of the requirements document, neither were required. The intent of separating out the two types of URIs was not to suggest that they have different inputs, but only to tell the client when LCMS is needed and when the direct PSAP URIs can be used. For instance, if the client is provided PSAP URIs and geo-LCMS URIs (and not civic-LCMS URIs), it can know not to invoke LCMS for civic cases and instead use the PSAP URIs. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 15 09:09:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFtUt-0008Iv-2n; Thu, 15 Sep 2005 09:09:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFtUk-0008IB-Ix for ecrit@megatron.ietf.org; Thu, 15 Sep 2005 09:09:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09245 for ; Thu, 15 Sep 2005 09:09:40 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFtZX-0000EO-NR for ecrit@ietf.org; Thu, 15 Sep 2005 09:14:41 -0400 Received: from [10.0.1.100] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 15 Sep 2005 09:09:39 -0400 id 000C7E0D.43297293.00003E35 In-Reply-To: <200509141531.LAA17265@ietf.org> References: <200509141531.LAA17265@ietf.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] draft-polk-dhc-uri-00 Date: Thu, 15 Sep 2005 09:09:36 -0400 To: br@brianrosen.net X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 14, 2005, at 11:29 AM, Brian Rosen wrote: > It's probably true that a 24 hour old mapping will work in most > cases. I'm > pretty unhappy with "probably" and "most", because of the > consequences of > getting wrong and the uncertainty of being able to manipulate a > limited > number of levers when lots of infrastructure is failing. Perhaps we should have a better understanding of what failures you are trying to avoid. After all, if infrastructure is failing then that can mean much more than SIP proxies, it can mean copper and fibber being cut and all manner of problems. If infrastructure is failing, it would seem that lower layer redundancies such as anycast might be more effective. Before inflicting complexity on 99.99% of the cases for something that is only needed 0.01% of the time, there should be a better understanding of what failures are being mitigated. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 15 09:47:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFu5m-0003eS-RO; Thu, 15 Sep 2005 09:47:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFu5l-0003eC-1e for ecrit@megatron.ietf.org; Thu, 15 Sep 2005 09:47:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11126 for ; Thu, 15 Sep 2005 09:47:54 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFuAY-0001Lz-HE for ecrit@ietf.org; Thu, 15 Sep 2005 09:52:55 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 15 Sep 2005 09:47:46 -0400 X-IronPort-AV: i="3.97,113,1125892800"; d="scan'208"; a="70359338:sNHT28582932" Received: from [68.50.138.194] (che-vpn-cluster-1-137.cisco.com [10.86.240.137]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8FDlgQl004928; Thu, 15 Sep 2005 09:47:43 -0400 (EDT) In-Reply-To: References: <200509141531.LAA17265@ietf.org> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit] draft-polk-dhc-uri-00 Date: Thu, 15 Sep 2005 09:47:38 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I actually think that getting into the potential failures is not worthwhile. Brian's point is that periodically updating emergency call routing information at the far edge of the network is not as robust a design as letting the responsible party handle the routing. This concept is familiar to Internet historians. The most radical difference between the circuit-switched model and the Internet model is that the originating edge does not know how the (call) packet is being routed. Routing takes place closer to the destination so that less routing information needs to be propagated through the network. Although Brian's point regards emergency-call routing rather than packet routing, the engineering principle is the same. John On Sep 15, 2005, at 9:09 AM, Andrew Newton wrote: > > On Sep 14, 2005, at 11:29 AM, Brian Rosen wrote: > >> It's probably true that a 24 hour old mapping will work in most >> cases. I'm >> pretty unhappy with "probably" and "most", because of the >> consequences of >> getting wrong and the uncertainty of being able to manipulate a >> limited >> number of levers when lots of infrastructure is failing. > > Perhaps we should have a better understanding of what failures you are > trying to avoid. After all, if infrastructure is failing then that > can mean much more than SIP proxies, it can mean copper and fibber > being cut and all manner of problems. If infrastructure is failing, > it would seem that lower layer redundancies such as anycast might be > more effective. > > Before inflicting complexity on 99.99% of the cases for something that > is only needed 0.01% of the time, there should be a better > understanding of what failures are being mitigated. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 15 15:23:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFzK0-0002LX-ID; Thu, 15 Sep 2005 15:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFzJy-0002LP-VA for ecrit@megatron.ietf.org; Thu, 15 Sep 2005 15:22:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29543 for ; Thu, 15 Sep 2005 15:22:56 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFzOn-0001r7-IX for ecrit@ietf.org; Thu, 15 Sep 2005 15:28:00 -0400 Received: from [10.0.1.100] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 15 Sep 2005 15:22:44 -0400 id 000C7FC9.4329CA06.00006782 In-Reply-To: References: <200509141531.LAA17265@ietf.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <42CC6B9B-0362-49CD-BDEE-99A6F82D8332@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] draft-polk-dhc-uri-00 Date: Thu, 15 Sep 2005 15:22:22 -0400 To: John Schnizlein X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 15, 2005, at 9:47 AM, John Schnizlein wrote: > I actually think that getting into the potential failures is not > worthwhile. Brian's point is that periodically updating emergency > call routing information at the far edge of the network is not as > robust a design as letting the responsible party handle the routing. Conceptually, what is the difference between a list of end points delivered with a DHCP lease time and a list of end points delivered with DNS Time-To-Live? Because MX records are used quite successfully near that same edge. Anyway, your description of where to place this control still does not rule out anycast. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 15 15:39:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFzZb-0006Ui-HN; Thu, 15 Sep 2005 15:39:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFzZZ-0006U3-9G; Thu, 15 Sep 2005 15:39:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00304; Thu, 15 Sep 2005 15:39:02 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFzeP-0002EI-O0; Thu, 15 Sep 2005 15:44:07 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 15 Sep 2005 12:38:21 -0700 X-IronPort-AV: i="3.97,114,1125903600"; d="scan'208"; a="342101868:sNHT965693498" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8FJcH4X019877; Thu, 15 Sep 2005 12:38:19 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Sep 2005 12:38:13 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Sep 2005 12:38:11 -0700 From: "Marc Linsner" To: "'James M. Polk'" Date: Thu, 15 Sep 2005 15:38:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW5dLaN0VyI7mkQSh6csVrk6ft3hgABF6jg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <4.3.2.7.2.20050914160915.0301adc8@email.cisco.com> Message-ID: X-OriginalArrivalTime: 15 Sep 2005 19:38:11.0993 (UTC) FILETIME=[02025890:01C5BA2D] X-Spam-Score: 1.1 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, 'ECRIT' Subject: [Ecrit] RE: draft-polk-dhc-uri-00 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 James, Thanks for your answer. My question was about the basis for your assertion that it is 'more appropriate' to perform location to psap uri mapping at host configuration setup time vs. emergency call setup time. I derive from your answer that your basis for this assertion is getting this task done prior to call setup, making call setup faster and possibly more reliable. More comments in-line.... > At 08:48 AM 9/14/2005 -0400, Marc Linsner wrote: > >James, > > > >Would you please provide the basis for your text below regarding the > >timing of psap determination, I can't seem to match it up > with any of > >the requirements within ecrit or geopriv. > > When something is urgent, do you want to invoke more > processing complexity or less processing complexity? More > typically means "more prone to errors", less typically means > "less prone to errors". No one can argue that simple is good, but there must be a balance with all requirements. > Everyone hear is assuming that the UA > providing location will get mapped to the appropriate PSAP > within a reasonable call set-up timeframe. This assumption is based on years of experience, it's the way things have work for 30+ years. There is every expectation of success in duplicating a like mechanism using Internet techologies. If that wasn't possible, we wouldn't be having this conversation as there would not be a PSTN-like capability on the Internet. > > This document suggests an optimization - to do the "mapping" > before time is wasted doing the mapping just to set-up the call. It is not clear such optimization is necessary. We don't have a 'failed' mechanism (yet). -Marc- > > The ECRIT Charter says: > > (item #1) "Successful delivery of an emergency service call > within those systems requires both an association of the > physical location of the originator with an appropriate > emergency service center and call routing to deliver the call > to the center." > > and > > (item #2) "Calls placed using Internet technologies do not > use the same systems to achieve those goals, and the common > use of overlay networks and tunnels (either as VPNs or for > mobility) makes meeting them more challenging. There are, > however, Internet technologies available to describe location > and to manage call routing. This working group will describe > when these may be appropriate and how they may be used." > > and > > (item #3) "The group will show how the availability of > location data and call routing information at different steps > in session setup would enable communication between a user > and a relevant emergency response center. " > > Item # 1 talks the association of user location and the > appropriate PSAP. > - This ID describes this by using the same Link > provider that knows the > UA's location (and give the UA its location. > > Item #2 talks about describing location and managing call > routing - specifically "when" these may be appropriate. > - This ID describes accomplishing this mapping > before call set-up. > - I don't remember reading a requirement in either > WG that says > "this mapping function MUST take place *only* during > call set-up". > > Item #3 talks about different information at different times > in the session set-up. > - This ID provides the Request-URI for the INVITE > message, plus provides > an alternate Request-URI, plus the URI of the ESGW and ESRP. > > SIP Proxies will determine if a route is available or not, > and reroute around any problems if there are any. A URI is > not an IP Address, of which there is one. The same URI can go > to many difference locations in times of overload or error. > Webservers have been doing this function for better than > 5 years now. > > > >"One example of this URI download would be one specifically > for the SIP > >or SIPS URI of the appropriate Public Safety Answer Point (PSAP) for > >the client when the user of that client calls for emergency > help (911 > >or 112-type of help). This is not a transaction that should > take place > >when a voice application wants to make such a critical call > set-up. It > >is more appropriate that this information be downloaded to > the client > >when the voice (or other) application boots up in case it is > needed at a later time." > > > >Thanks, > > > >-Marc- > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 15 15:59:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFzsx-0002nU-BL; Thu, 15 Sep 2005 15:59:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFzsu-0002n5-Ve; Thu, 15 Sep 2005 15:59:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02065; Thu, 15 Sep 2005 15:59:02 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFzxl-0003Af-DK; Thu, 15 Sep 2005 16:04:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] RE: draft-polk-dhc-uri-00 Date: Thu, 15 Sep 2005 21:58:47 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4516@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] RE: draft-polk-dhc-uri-00 Thread-Index: AcW5dLaN0VyI7mkQSh6csVrk6ft3hgABF6jgAC2zVW4= From: "Stastny Richard" To: "Marc Linsner" , "James M. Polk" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Is there a possibility to get this question back to facts: what will the average call setup delay be for lets say one additional DNS query to the x queries required to do the call-setup from the client to the PSAP, eventually via an ESRP and a ESGW in the first place? Richard ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von Marc Linsner Gesendet: Do 15.09.2005 21:38 An: 'James M. Polk' Cc: dhcwg@ietf.org; 'ECRIT' Betreff: [Ecrit] RE: draft-polk-dhc-uri-00 James, Thanks for your answer. My question was about the basis for your = assertion that it is 'more appropriate' to perform location to psap uri mapping at host configuration setup time vs. emergency call setup time. I derive = from your answer that your basis for this assertion is getting this task done prior to call setup, making call setup faster and possibly more = reliable. More comments in-line.... > At 08:48 AM 9/14/2005 -0400, Marc Linsner wrote: > >James, > > > >Would you please provide the basis for your text below regarding the > >timing of psap determination, I can't seem to match it up > with any of > >the requirements within ecrit or geopriv. > > When something is urgent, do you want to invoke more > processing complexity or less processing complexity? More > typically means "more prone to errors", less typically means > "less prone to errors". No one can argue that simple is good, but there must be a balance with = all requirements. > Everyone hear is assuming that the UA > providing location will get mapped to the appropriate PSAP > within a reasonable call set-up timeframe. This assumption is based on years of experience, it's the way things = have work for 30+ years. There is every expectation of success in = duplicating a like mechanism using Internet techologies. If that wasn't possible, we wouldn't be having this conversation as there would not be a PSTN-like capability on the Internet. > > This document suggests an optimization - to do the "mapping" > before time is wasted doing the mapping just to set-up the call. It is not clear such optimization is necessary. We don't have a = 'failed' mechanism (yet). -Marc- > > The ECRIT Charter says: > > (item #1) "Successful delivery of an emergency service call > within those systems requires both an association of the > physical location of the originator with an appropriate > emergency service center and call routing to deliver the call > to the center." > > and > > (item #2) "Calls placed using Internet technologies do not > use the same systems to achieve those goals, and the common > use of overlay networks and tunnels (either as VPNs or for > mobility) makes meeting them more challenging. There are, > however, Internet technologies available to describe location > and to manage call routing. This working group will describe > when these may be appropriate and how they may be used." > > and > > (item #3) "The group will show how the availability of > location data and call routing information at different steps > in session setup would enable communication between a user > and a relevant emergency response center. " > > Item # 1 talks the association of user location and the > appropriate PSAP. > - This ID describes this by using the same Link > provider that knows the > UA's location (and give the UA its location. > > Item #2 talks about describing location and managing call > routing - specifically "when" these may be appropriate. > - This ID describes accomplishing this mapping > before call set-up. > - I don't remember reading a requirement in either > WG that says > "this mapping function MUST take place *only* during > call set-up". > > Item #3 talks about different information at different times > in the session set-up. > - This ID provides the Request-URI for the INVITE > message, plus provides > an alternate Request-URI, plus the URI of the ESGW and ESRP. > > SIP Proxies will determine if a route is available or not, > and reroute around any problems if there are any. A URI is > not an IP Address, of which there is one. The same URI can go > to many difference locations in times of overload or error. > Webservers have been doing this function for better than > 5 years now. > > > >"One example of this URI download would be one specifically > for the SIP > >or SIPS URI of the appropriate Public Safety Answer Point (PSAP) for > >the client when the user of that client calls for emergency > help (911 > >or 112-type of help). This is not a transaction that should > take place > >when a voice application wants to make such a critical call > set-up. It > >is more appropriate that this information be downloaded to > the client > >when the voice (or other) application boots up in case it is > needed at a later time." > > > >Thanks, > > > >-Marc- > > > 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 Sep 15 16:44:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG0az-0007aV-Qy; Thu, 15 Sep 2005 16:44:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG0ay-0007Yq-6B for ecrit@megatron.ietf.org; Thu, 15 Sep 2005 16:44:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09558 for ; Thu, 15 Sep 2005 16:44:32 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EG0fo-0006Hz-Gq for ecrit@ietf.org; Thu, 15 Sep 2005 16:49:37 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j8FKiJNB032383 for ; Thu, 15 Sep 2005 22:44:19 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j8FKiJoG006068 for ; Thu, 15 Sep 2005 22:44:19 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 15 Sep 2005 22:44:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Sep 2005 22:44:18 +0200 Message-ID: Thread-Topic: open issues Thread-Index: AcW6Nj2lUwOTGVeYTMmEGp13MbWt2g== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 15 Sep 2005 20:44:18.0601 (UTC) FILETIME=[3E4AB190:01C5BA36] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] open issues X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 please take a look at the open issues of the requirements draft: http://www.ietf-ecrit.org:8080/ecrit-req/ your input is needed! ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 15 17:12:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG11f-0006FU-T6; Thu, 15 Sep 2005 17:12:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG11b-0006Ej-6E for ecrit@megatron.ietf.org; Thu, 15 Sep 2005 17:12:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10800 for ; Thu, 15 Sep 2005 17:12:01 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EG16Q-00070m-50 for ecrit@ietf.org; Thu, 15 Sep 2005 17:17:07 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Sep 2005 16:11:39 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 15 Sep 2005 16:11:39 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Sep 2005 16:11:38 -0500 Message-ID: From: "Winterbottom, James" To: "Andrew Newton" , "Thomson, Martin" Date: Thu, 15 Sep 2005 16:11:35 -0500 Subject: RE: [Ecrit] draft-polk-dhc-uri-00: mixed goals MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 15 Sep 2005 21:11:38.0424 (UTC) FILETIME=[0FB3D380:01C5BA3A] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] draft-polk-dhc-uri-00: mixed goals Thread-Index: AcW59KMlSMmSTGDhS/e8w6Lk7iSDigARUuog X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Andy, This kind of problem can be completely avoided by providing a LocationURI and allowing the proposed recipient to decide what kind of location ot request. Cheers James=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Andrew Newton > Sent: Thursday, 15 September 2005 10:51 PM > To: Thomson, Martin > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] draft-polk-dhc-uri-00: mixed goals >=20 >=20 > On Sep 14, 2005, at 8:31 PM, Thomson, Martin wrote: >=20 > > I think that we should also mandate that a mapping service use a > > PIDF-LO as input, therefore distinguishing between a civic and geo > > mapping service does not add any value. The capabilities of the > > mapping service (the ability to accept civic or geo input) are > > metadata. >=20 > Martin, >=20 > I'm not sure all of PIDF-LO should be a requirement, but certainly > the location elements seem appropriate. As of my last reading of the > requirements document, neither were required. >=20 > The intent of separating out the two types of URIs was not to suggest > that they have different inputs, but only to tell the client when > LCMS is needed and when the direct PSAP URIs can be used. For > instance, if the client is provided PSAP URIs and geo-LCMS URIs (and > not civic-LCMS URIs), it can know not to invoke LCMS for civic cases > and instead use the PSAP URIs. >=20 > -andy >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 15 17:22:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG1Bc-0000kU-Bb; Thu, 15 Sep 2005 17:22:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG1Bb-0000kP-9r for ecrit@megatron.ietf.org; Thu, 15 Sep 2005 17:22:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11257 for ; Thu, 15 Sep 2005 17:22:24 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EG1GS-0007I4-Vn for ecrit@ietf.org; Thu, 15 Sep 2005 17:27:30 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 15 Sep 2005 17:22:18 -0400 X-IronPort-AV: i="3.97,114,1125892800"; d="scan'208"; a="70437541:sNHT30718130" Received: from [68.50.138.194] (che-vpn-cluster-1-137.cisco.com [10.86.240.137]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8FLMET6019993; Thu, 15 Sep 2005 17:22:15 -0400 (EDT) In-Reply-To: <42CC6B9B-0362-49CD-BDEE-99A6F82D8332@hxr.us> References: <200509141531.LAA17265@ietf.org> <42CC6B9B-0362-49CD-BDEE-99A6F82D8332@hxr.us> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit] draft-polk-dhc-uri-00 Date: Thu, 15 Sep 2005 17:22:10 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 15, 2005, at 3:22 PM, Andrew Newton wrote: > > Conceptually, what is the difference between a list of end points > delivered with a DHCP lease time and a list of end points delivered > with DNS Time-To-Live? Because MX records are used quite successfully > near that same edge. > > Anyway, your description of where to place this control still does not > rule out anycast. > The conceptual difference between DHCP and DNS is that DHCP is intended to provide a host with configuration options appropriate for its local network attachment; DNS is intended for hosts to look up records associated with host names that are (mostly) not local. Careful design and redesign when initial problems (like the need for negative caching) were found has led to a global operation of DNS caching that has been proved to work. This good design allows each domain to update its own records, new domains to be found through referrals, and the load on servers to be workable. Nobody has explained what protocol would provide for the distribution and selection of all those URIs that would have to be in all the DHCP servers that are not advertised to the outside world. DHCP leases are entirely a local matter, the DNS TTL is set by the remote domain's administration and decremented throughout any caches. DHCP has no design for caching. MX records are specific to email exchanges; SRV records generalize this mechanism rather than inventing a new resource record for every application. MX records work because the SMTP hosts have names and addresses in the DNS - unlike arbitrary geographic or civic locations. It is unclear to me how DNS could be relevant here. What proposal for routing emergency calls to or among PSAPs? I have to admit I do not understand what problem we are solving here. To my way of thinking, a reasonable and simple approach is for hosts to include their locations (information local to the host) in an emergency call request, which goes to an emergency-call router (sip gateway for whatever number means emergency). The emergency-call router would have emergency call routing information enabling it to forward the request to (toward) the relevant PSAP. This information would at some point along its forwarding path use the call-originating host's location to forward the request. Information would have to be shared only between relative neighbors in each aspect of the call handling. Any of the components that were critical would have redundant operational peers. Why attempt propagation of information beyond where it is needed? John _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 16 00:49:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG89v-0005Qu-92; Fri, 16 Sep 2005 00:49:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG89u-0005Qp-Am for ecrit@megatron.ietf.org; Fri, 16 Sep 2005 00:49:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10148 for ; Fri, 16 Sep 2005 00:49:06 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EG8Ep-0000rs-Qo for ecrit@ietf.org; Fri, 16 Sep 2005 00:54:17 -0400 Received: from [127.0.0.1] (razor.cs.columbia.edu [128.59.16.8]) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j8G4mVWj011579; Fri, 16 Sep 2005 00:48:46 -0400 (EDT) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B213C@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D461B213C@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] terminology Date: Fri, 16 Sep 2005 00:49:00 -0400 To: Stastny Richard X-Mailer: Apple Mail (2.733) X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org One easy-to-remember version is to call them L1P L3P L7P On Sep 15, 2005, at 3:35 AM, Stastny Richard wrote: > James Polk proposed: > > >> Link Layer Provider (LLP) >> Internet Layer Provider (ILP) >> Application Layer Provider (ALP) >> > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 16 09:11:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGFzi-00083g-DO; Fri, 16 Sep 2005 09:11:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGFzf-00083P-Re; Fri, 16 Sep 2005 09:11:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15116; Fri, 16 Sep 2005 09:11:05 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGG4f-0005Wl-Pd; Fri, 16 Sep 2005 09:16:19 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 16 Sep 2005 06:10:57 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8GDAq4X025792; Fri, 16 Sep 2005 06:10:55 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 06:10:54 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 06:10:53 -0700 From: "Marc Linsner" To: "'James M. Polk'" Date: Fri, 16 Sep 2005 09:10:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW6wA8NEISDSVZ7QciL47vDe81Zpw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 16 Sep 2005 13:10:53.0731 (UTC) FILETIME=[1156B730:01C5BAC0] X-Spam-Score: 1.1 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, 'ECRIT' Subject: [Ecrit] draft-polk-dhc-uri-00 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 James, Can you expand on the following topics wrt uri purposes 1, 2, 4 in your draft.... 1) How does the dhcp server (or admin) derive the PSAP/ESGW uri(s)? 2) How can the PSAP effect a routing change, therefore a change to the PSAP/ESGW uri information that a particular dhcp server is passing on to it's clients (in support of the ecrit requirement that PSAPs control the routing db)? Thanks, -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 16 09:31:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGGJN-0006Gp-KH; Fri, 16 Sep 2005 09:31:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGGJK-0006Dr-Hd for ecrit@megatron.ietf.org; Fri, 16 Sep 2005 09:31:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16646 for ; Fri, 16 Sep 2005 09:31:24 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGGOL-0006Hx-D2 for ecrit@ietf.org; Fri, 16 Sep 2005 09:36:38 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 16 Sep 2005 06:31:17 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j8GDUwWB021452; Fri, 16 Sep 2005 06:31:15 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 06:31:05 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 06:31:04 -0700 From: "Marc Linsner" To: "'Stastny Richard'" Subject: RE: [Ecrit] terminology Date: Fri, 16 Sep 2005 09:31:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW5fvT7u6J8UAdvTDyYyLQQAdfgMgAR8CDgAD7Rd6A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B213C@oefeg-s04.oefeg.loc> Message-ID: X-OriginalArrivalTime: 16 Sep 2005 13:31:05.0208 (UTC) FILETIME=[E36F6F80:01C5BAC2] X-Spam-Score: 1.1 (+) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 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 in-line.... > > > Link Layer Provider (LLP) > > Internet Layer Provider (ILP) > > Application Layer Provider (ALP) > > I could live with these definitions, especially if we give > the other terms as examples: ALP e.g. a VSP This also > includes self-provision. And it would also save some > discussions later if the example terms are not matching exactly. > > Now I cam move on to my next question: on which of these > layers is the mapping database (LCMS) or the DNS in general? ;-) I'll bite.....the mapping database (all pieces) and DNS (resolver, recursive server, authoritative server) are all layer 7 (applications). (I missed the meaning of LCMS - too much email!) -Marc- > > It may seem to some that I am picky here, but I consider this > discussion as a trial run for the parallel discussions going > on the exact same issues in voipeer and Carrier ENUM ;-) > > And the arguments and solutions found here will be very > useful over there ;-) > > And over there there ARE business models involved. > > Cheers > Richard > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Thursday, September 15, 2005 12:48 AM > > To: Henning Schulzrinne > > Cc: Andrew Newton; Stastny Richard; ecrit@ietf.org > > Subject: Re: [Ecrit] terminology > > > > At 06:07 PM 9/14/2005 -0400, Henning Schulzrinne wrote: > > >>I think I suggested this 3 hours ago, in which I said > > > > > >I'm sorry I missed this in the flood of messages today. > > > > > >>Link Provider (at Layer 2) > > >>Internet Provider (at Layer 3/4/5) > > > > > >As far as I can tell, TCP (layer 4) is not provided by > anyone except > the > > >two TCP end hosts. I don't think you'd want to call Microsoft an > Internet > > >Provider. I'm not sure what layer 5 is. > > > > 3/4/5 is getting into the backbone nature of an IP > transport function > of > > an > > Internet Provider, like where RTP is (as was mentioned > specifically in > a > > message within the last 24 hours) - perhaps I shouldn't use numbers > other > > than 3 for the Internet Provider. > > > > > > > > >>Application (Service) Provider (at Layer 7) > > > > > >This division is fairly similar to the one that had been in many of > the > > >early requirements documents I had a hand in drafting. However, I > tend to > > >believe now that there are a sufficient number of corner > cases where > such > > >terms will yield more confusion than insight. > > > > we talk of a VSP without hesitation now, and that > orgnaization is the > > provider of a specific application. > > > > If we agreed on the use of "Application" here to mean Layer 7 > Provider, we > > can get past the confusion - I hope. This is one reason why > I think we > > need to get rid of the word "service" in ISP and ASP. That > is the word > > I believe is the most confusing, because voice is a service, but in > > the context > of > > an > > Internet Service Provider, the ISP might not be the one to provide > that > > service - hense there is confusion. > > > > > > > > > > >>>As was mentioned, we don't really care about the business > > relationships, > > >>>but rather trust and management relationships, for example. > > >> > > >>I disagree with this statement because of the politics and > regulation > > >>(that's going to be) involved. Specifically with respect to the > FCC's > > >>ruling that Vonage-type companies MUST produce the 911 > call at the > > >>appropriate PSAP. This has little to do with trust, the > way you're > > >>meaning it (I believe). > > > > > >Unfortunately, these terms are not even clear within the > regulatory > > >community. Unless you want to say "A voice service provider is > whatever > > >the FCC believes today it happens to be (until some federal court > tells > > >them otherwise)", this doesn't help much. The only term > they define, > by > > >the way, is "connected voice provider", which is yet another beast > and > > >clearly does not, for example, include (say) Yahoo! or FWD > or (say) > > >Jabber, although they would be considered an ASP according to most > > >discussions we've had and I assume would an ASP in your estimation. > > > > agreed > > > > > > >In other words: not all ASPs are subject to emergency services > mandates > > >today in the US, > > > > I absolutely agree with this, as we're focusing on voice first, with > IM > > and > > video later; but for now, IM providers are not in this emergency > services > > mix. > > > > >but some might be today or in other countries. > > > > > >In short: I think trying to follow the regulatory > definitions gets us > > into > > >national regulations we have no way of tracking (nor should we try > to). > > > > I'm not saying "get into regulatory definitions" per se, > unless there > is > > one staring us in the face like the recent one is (US FCC 05-116). > Flying > > in the face of this seems equally foolish IMO. > > > > >We might hope that crisp, unambiguous, protocol-based definitions > will > > >eventually make it into regulations, but that's probably naive to > hope > > for. > > > > I wish you had your way, I would prefer that too. > > > > Perhaps we go with longer terms: > > > > Link Layer Provider (LLP) > > Internet Layer Provider (ILP) > > Application Layer Provider (ALP) > > > > I'm not trying to just come up with terms for the sake of > terms, I'm > > trying to get to the point where everyone can agree on a set of > > meanings and > have > > discussions without having to define what is being > discussed each time > a > > discussion comes up > > > > > > >Henning > > > > > > 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 Sep 16 09:40:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGGRs-00006e-9a; Fri, 16 Sep 2005 09:40:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGGRr-000062-08 for ecrit@megatron.ietf.org; Fri, 16 Sep 2005 09:40:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17223 for ; Fri, 16 Sep 2005 09:40:12 -0400 (EDT) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGGWq-0006a3-Rx for ecrit@ietf.org; Fri, 16 Sep 2005 09:45:26 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8GDbPKG004679 for ; Fri, 16 Sep 2005 09:37:25 -0400 (EDT) Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8GDZdKG001776 for ; Fri, 16 Sep 2005 09:35:56 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] terminology Date: Fri, 16 Sep 2005 09:38:22 -0400 Message-ID: Thread-Topic: [Ecrit] terminology Thread-Index: AcW6eqxivbtnImlkQN2Yvuvlqre5ZAARjFZQ From: "Rodrig, Benny \(Benny\)" To: "Henning Schulzrinne" , "Stastny Richard" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 This easy version might be ambiguous though regarding L2, e.g. the entity that can provide location via LLDP-MED. I assume it is the L1P, but this may not be obvious from this terminology. L1&2P looks rather ugly... Maybe use L2P assuming it is then obvious that this one includes L1? or just stick to the LLP (Link layer Provider) term. Benny -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, September 16, 2005 12:49 AM To: Stastny Richard Cc: ecrit@ietf.org Subject: Re: [Ecrit] terminology One easy-to-remember version is to call them L1P L3P L7P On Sep 15, 2005, at 3:35 AM, Stastny Richard wrote: > James Polk proposed: > > >> Link Layer Provider (LLP) >> Internet Layer Provider (ILP) >> Application Layer Provider (ALP) >> > _______________________________________________ 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 Sep 16 09:45:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGGXL-0002IQ-7f; Fri, 16 Sep 2005 09:45:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGGXJ-0002DP-0w for ecrit@megatron.ietf.org; Fri, 16 Sep 2005 09:45:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17602 for ; Fri, 16 Sep 2005 09:45:50 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGGcJ-0006m3-9U for ecrit@ietf.org; Fri, 16 Sep 2005 09:51:04 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 16 Sep 2005 06:45:43 -0700 X-IronPort-AV: i="3.97,117,1125903600"; d="scan'208"; a="660214214:sNHT32176672" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8GDisKk008588; Fri, 16 Sep 2005 06:45:38 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 06:45:34 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 06:45:34 -0700 From: "Marc Linsner" To: "'Henning Schulzrinne'" , "'Stastny Richard'" Subject: RE: [Ecrit] terminology Date: Fri, 16 Sep 2005 09:45:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW6eq/p8WcoxF7FQuKJ6eV5FpjNvAASGVeA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Message-ID: X-OriginalArrivalTime: 16 Sep 2005 13:45:34.0292 (UTC) FILETIME=[E9732140:01C5BAC4] X-Spam-Score: 1.1 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I would rather not have any reference to layer 1.....please replace with layer 2. 1) I doubt if dry copper or dark fiber is marketed any longer....at least in use cases we are concerned with. 2) Although I agree that knowledge of layer 1 is where the actual information is derived for 'network-based location mechanisms for physical media' discussed here, we are only concerned with a mechanism that attempts to 'automate' gathering this location information. Since dry copper and dark fiber can't 'talk', it is much easier to deal with the media access control protocols that can/do 'talk'. (Plus the fact we would bring wikipedia to it's knees attempting to understand layer 1 wrt to wireless.) So, I don't care about labels as long as they have reference to 2, 3, and 7.... Just another opinion, -Marc- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Henning Schulzrinne > Sent: Friday, September 16, 2005 12:49 AM > To: Stastny Richard > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] terminology > > One easy-to-remember version is to call them > > L1P > L3P > L7P > > On Sep 15, 2005, at 3:35 AM, Stastny Richard wrote: > > > James Polk proposed: > > > > > >> Link Layer Provider (LLP) > >> Internet Layer Provider (ILP) > >> Application Layer Provider (ALP) > >> > > > > _______________________________________________ > 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 Sep 16 10:07:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGGs5-00082i-0S; Fri, 16 Sep 2005 10:07:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGGs2-00081R-Ld for ecrit@megatron.ietf.org; Fri, 16 Sep 2005 10:07:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18730 for ; Fri, 16 Sep 2005 10:07:16 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGGx1-0007EO-3j for ecrit@ietf.org; Fri, 16 Sep 2005 10:12:30 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 16 Sep 2005 10:07:10 -0400 id 000C7E0D.432AD18E.00006B91 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4516@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C4516@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <468B275C-1321-404C-B202-FCCB345F3C24@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] RE: draft-polk-dhc-uri-00 Date: Fri, 16 Sep 2005 10:07:09 -0400 To: Stastny Richard X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 15, 2005, at 3:58 PM, Stastny Richard wrote: > Is there a possibility to get this question back to facts: > what will the average call setup delay be for lets say one > additional DNS query to the x queries required to do the call-setup > from the client to the PSAP, eventually via an ESRP and a ESGW > in the first place? Which proposal is JUST ONE DNS query? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 16 10:17:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGH23-0002iz-9H; Fri, 16 Sep 2005 10:17:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGH20-0002ip-8C for ecrit@megatron.ietf.org; Fri, 16 Sep 2005 10:17:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19729 for ; Fri, 16 Sep 2005 10:17:24 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGH6s-0007Tl-Cb for ecrit@ietf.org; Fri, 16 Sep 2005 10:22:38 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 16 Sep 2005 10:17:23 -0400 id 000C7FB8.432AD3F4.00006DD0 In-Reply-To: References: <200509141531.LAA17265@ietf.org> <42CC6B9B-0362-49CD-BDEE-99A6F82D8332@hxr.us> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] draft-polk-dhc-uri-00 Date: Fri, 16 Sep 2005 10:17:09 -0400 To: John Schnizlein X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 15, 2005, at 5:22 PM, John Schnizlein wrote: > > On Sep 15, 2005, at 3:22 PM, Andrew Newton wrote: > >> >> Conceptually, what is the difference between a list of end points >> delivered with a DHCP lease time and a list of end points >> delivered with DNS Time-To-Live? Because MX records are used >> quite successfully near that same edge. >> >> Anyway, your description of where to place this control still does >> not rule out anycast. >> >> > > The conceptual difference between DHCP and DNS is that DHCP is > intended to provide a host with configuration options appropriate > for its local network attachment; DNS is intended for hosts to look > up records associated with host names that are (mostly) not local. > Careful design and redesign when initial problems (like the need > for negative caching) were found has led to a global operation of > DNS caching that has been proved to work. This good design allows > each domain to update its own records, new domains to be found > through referrals, and the load on servers to be workable. Nobody > has explained what protocol would provide for the distribution and > selection of all those URIs that would have to be in all the DHCP > servers that are not advertised to the outside world. > > DHCP leases are entirely a local matter, the DNS TTL is set by the > remote domain's administration and decremented throughout any > caches. DHCP has no design for caching. > > MX records are specific to email exchanges; SRV records generalize > this mechanism rather than inventing a new resource record for > every application. MX records work because the SMTP hosts have > names and addresses in the DNS - unlike arbitrary geographic or > civic locations. It is unclear to me how DNS could be relevant here. > > What proposal for routing emergency calls to or among PSAPs? > > I have to admit I do not understand what problem we are solving > here. To my way of thinking, a reasonable and simple approach is > for hosts to include their locations (information local to the > host) in an emergency call request, which goes to an emergency-call > router (sip gateway for whatever number means emergency). The > emergency-call router would have emergency call routing information > enabling it to forward the request to (toward) the relevant PSAP. > This information would at some point along its forwarding path use > the call-originating host's location to forward the request. > Information would have to be shared only between relative neighbors > in each aspect of the call handling. Any of the components that > were critical would have redundant operational peers. Why attempt > propagation of information beyond where it is needed? Perhaps we ought to go back to thrust of the objection that was raised: a device is given a 24 hour validity duration on a list of end points but there is an unforeseen reason for it to be updated 12 hours after the device was given the information. My question was simply, why is that duration unacceptable when it is a DHCP lease but acceptable when it is a DNS TTL? Both will prevent the information from being updated before the end of the duration. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 16 10:46:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGHUD-0001P0-Qv; Fri, 16 Sep 2005 10:46:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGHUD-0001Ov-6z for ecrit@megatron.ietf.org; Fri, 16 Sep 2005 10:46:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21441 for ; Fri, 16 Sep 2005 10:46:42 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EGHZE-0008C0-0x for ecrit@ietf.org; Fri, 16 Sep 2005 10:51:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] terminology Date: Fri, 16 Sep 2005 16:48:17 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C451D@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] terminology Thread-Index: AcW5fvT7u6J8UAdvTDyYyLQQAdfgMgAR8CDgAD7Rd6AAAuxBhw== From: "Stastny Richard" To: "Marc Linsner" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org >(I missed the meaning of LCMS - too much email!) =20 Another four letter word Location Context Mapping System from draft-polk-newton-ecrit-arch-considerations-00 ;-) cheers Richard =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 16 10:47:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGHV1-0001Xs-Da; Fri, 16 Sep 2005 10:47:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGHUz-0001Xn-DA for ecrit@megatron.ietf.org; Fri, 16 Sep 2005 10:47:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21473 for ; Fri, 16 Sep 2005 10:47:30 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGHa0-0008D5-Ah for ecrit@ietf.org; Fri, 16 Sep 2005 10:52:45 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 16 Sep 2005 07:47:24 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,117,1125903600"; d="scan'208"; a="9993984:sNHT20751400" Received: from [68.50.138.194] (che-vpn-cluster-2-135.cisco.com [10.86.242.135]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8GElLT6007436; Fri, 16 Sep 2005 10:47:21 -0400 (EDT) In-Reply-To: References: <200509141531.LAA17265@ietf.org> <42CC6B9B-0362-49CD-BDEE-99A6F82D8332@hxr.us> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <288238a691e5974f4453d647477abe3b@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit] draft-polk-dhc-uri-00 Date: Fri, 16 Sep 2005 10:47:16 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org As you know, the caching specification for DNS makes the TTL the upper bound on how long before the client gets a fresh value from an authoritative server. The problem with using DHCP is not the duration of an address lease, but that there is no mechanism identified for getting new URIs into the DHCP servers. Why is the comparison of DNS and DHCP relevant? We have seen no argument that continuing the practice of PSAPs (which might be SIP proxies for VoIP) routing emergency calls among themselves based on location information in the call request. The unnecessary "optimization" of getting better than default PSAPs into the calling host has unspecified needs for new protocols to distribute information that the PSAPs might not want to share as widely as proposed. John On Sep 16, 2005, at 10:17 AM, Andrew Newton wrote: > > On Sep 15, 2005, at 5:22 PM, John Schnizlein wrote: >> ... >> DHCP leases are entirely a local matter, the DNS TTL is set by the >> remote domain's administration and decremented throughout any caches. >> DHCP has no design for caching. > > Perhaps we ought to go back to thrust of the objection that was > raised: a device is given a 24 hour validity duration on a list of end > points but there is an unforeseen reason for it to be updated 12 hours > after the device was given the information. My question was simply, > why is that duration unacceptable when it is a DHCP lease but > acceptable when it is a DNS TTL? Both will prevent the information > from being updated before the end of the duration. > > -andy > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 16 12:28:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGJ4q-0003Zg-DU; Fri, 16 Sep 2005 12:28:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGJ4o-0003ZY-GW for ecrit@megatron.ietf.org; Fri, 16 Sep 2005 12:28:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27541 for ; Fri, 16 Sep 2005 12:28:35 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGJ9o-0002pn-24 for ecrit@ietf.org; Fri, 16 Sep 2005 12:33:51 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 16 Sep 2005 09:28:25 -0700 X-IronPort-AV: i="3.97,117,1125903600"; d="scan'208"; a="212480989:sNHT30349990" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j8GGSMuk012263; Fri, 16 Sep 2005 09:28:22 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 09:28:18 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 09:28:18 -0700 From: "Marc Linsner" To: "'Andrew Newton'" Subject: RE: [Ecrit] draft-polk-dhc-uri-00 Date: Fri, 16 Sep 2005 12:28:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW6yZWKKclD1muQS8is4nOSsMr3hgACSTNw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Message-ID: X-OriginalArrivalTime: 16 Sep 2005 16:28:18.0449 (UTC) FILETIME=[A5574010:01C5BADB] X-Spam-Score: 1.1 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Andy, > Perhaps we ought to go back to thrust of the objection that was > raised: a device is given a 24 hour validity duration on a > list of end points but there is an unforeseen reason for it > to be updated 12 hours after the device was given the > information. My question was simply, why is that duration > unacceptable when it is a DHCP lease but acceptable when it > is a DNS TTL? Both will prevent the information from being > updated before the end of the duration. > Correct me if wrong....in practice, are not DNS TTLs normally much shorter than DHCP lease times? Of course, beyond the above philosophical argument, the PSAP has no control over DHCP lease times, where in the proposed DNS solution, they have control over TTLs. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 16 14:15:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGKiJ-0004ja-1L; Fri, 16 Sep 2005 14:13:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGKiH-0004jP-2Q for ecrit@megatron.ietf.org; Fri, 16 Sep 2005 14:13:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02222 for ; Fri, 16 Sep 2005 14:13:27 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGKnI-0005RR-Kx for ecrit@ietf.org; Fri, 16 Sep 2005 14:18:43 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 16 Sep 2005 14:13:23 -0400 id 000C7FBF.432B0B43.00002301 In-Reply-To: <288238a691e5974f4453d647477abe3b@cisco.com> References: <200509141531.LAA17265@ietf.org> <42CC6B9B-0362-49CD-BDEE-99A6F82D8332@hxr.us> <288238a691e5974f4453d647477abe3b@cisco.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] draft-polk-dhc-uri-00 Date: Fri, 16 Sep 2005 14:13:26 -0400 To: John Schnizlein , Marc Linsner X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 16, 2005, at 10:47 AM, John Schnizlein wrote: > As you know, the caching specification for DNS makes the TTL the > upper bound on how long before the client gets a fresh value from > an authoritative server. And a DHCP client can renew its lease before the lease time is up. What's your point? Both are unreliable for the purposes of preemption. > The problem with using DHCP is not the duration of an address > lease, but that there is no mechanism identified for getting new > URIs into the DHCP servers. Do DHCP servers have such quirky IP connectivity that they cannot use the same LCMS as a phone or gateway? > Why is the comparison of DNS and DHCP relevant? We have seen no > argument that continuing the practice of PSAPs (which might be SIP > proxies for VoIP) routing emergency calls among themselves based on > location information in the call request. The unnecessary > "optimization" of getting better than default PSAPs into the > calling host has unspecified needs for new protocols to distribute > information that the PSAPs might not want to share as widely as > proposed. The objection raised was not about call routing based on location, but was about call routing based on disaster recovery. Again... Perhaps we ought to go back to thrust of the objection that was raised: a device is given a 24 hour validity duration on a list of end points but there is an unforeseen reason for it to be updated 12 hours after the device was given the information. My question was simply, why is that duration unacceptable when it is a DHCP lease but acceptable when it is a DNS TTL? Both will prevent the information from being updated before the end of the duration. I have no problem with calls being routed be proxies. Actually, for the objection that was raised, that seems to be a pretty good place to do it. On Sep 16, 2005, at 12:28 PM, Marc Linsner wrote: > Correct me if wrong....in practice, are not DNS TTLs normally much > shorter > than DHCP lease times? TTLs where? in the roots? in TLDs? in SLDs? From what Henning has said, for this particular case they would be set for a very, very long time. I take that to mean months. > Of course, beyond the above philosophical argument, the PSAP has no > control > over DHCP lease times, where in the proposed DNS solution, they > have control > over TTLs. True, but it doesn't disprove my point. I also wonder, if DHCP lease times are so untrustworthy, then perhaps LCI should not be delivered via DHCP either. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From mipshop-bounces@ietf.org Fri Sep 16 14:15:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGKfT-0003qL-Lp; Fri, 16 Sep 2005 14:10:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGKfR-0003q4-GB for mipshop@megatron.ietf.org; Fri, 16 Sep 2005 14:10:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02088 for ; Fri, 16 Sep 2005 14:10:31 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGKkR-0005MP-Oe for mipshop@ietf.org; Fri, 16 Sep 2005 14:15:47 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j8GHb6A22890; Fri, 16 Sep 2005 10:37:06 -0700 X-mProtect: <200509161737> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14150.americas.nokia.com (172.18.141.50, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdTQMS9g; Fri, 16 Sep 2005 10:37:05 PDT Message-ID: <432B0A7A.6060400@iprg.nokia.com> Date: Fri, 16 Sep 2005 11:10:02 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mipshop] FMIPv6 - NAR sets up tunnel endpoint? References: <49E7012A614B024B80A7D175CB9A64EC067C4602@ftrdmel1.rd.francetelecom.fr> <432869DC.5040900@iprg.nokia.com> <134001c5b964$b093edc0$196115ac@dcml.docomolabsusa.com> <4328B8EE.1040305@iprg.nokia.com> <146101c5ba19$4daa6ad0$196115ac@dcml.docomolabs In-Reply-To: <186401c5bae7$a381c650$196115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Cc: mipshop@ietf.org, Alexandru Petrescu X-BeenThere: mipshop@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mipshop.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mipshop-bounces@ietf.org Errors-To: mipshop-bounces@ietf.org Perhaps a better question might be "are there objections to having it as an option"? I am okay either way. Just that if someone wishes to keep an option, we should not disallow it (assuming it is not overly complex of course!). Thanks, -Rajeev James Kempf wrote: > I'd like to simplify the protocol. I don't think an additional tunneling > mode is necessary. I don't think it makes a difference if it's a MAY or > not. > > If nobody else is interested in this, I'm willing to drop it. Is anyone > else interested in simplifying the protocol by getting rid of the > PAR-NAR tunnel? > > jak > > ----- Original Message ----- From: "Rajeev Koodli" > To: "James Kempf" > Cc: "GAABAB Brahim RD-CORE-CAE" ; > ; "Alexandru Petrescu" > Sent: Friday, September 16, 2005 10:42 AM > Subject: Re: [Mipshop] FMIPv6 - NAR sets up tunnel endpoint? > > >> >> Hi Jim, >> >> ya, I was showing how the PAR - NAR tunnel could still provide >> predictive handover feature. I agree that you can live with reactive >> handover. Note that: >> >> - PAR - NAR tunnel set up is optional (MAY, not required). >> - there will not be two different tunnels. >> >> Would you object to having it as an option? >> >> -Rajeev >> >> >> James Kempf wrote: >> >>>> Okay. In this case (according to the current spec), the MN knows >>>> that PAR - NAR tunnel is set up already. So, all it has to do is to >>>> announce itself to the NAR and receive packets. And, send packets >>>> using PCoA. >>>> In essence, predictive handover. >>>> >>> >>> If the proposed CoA was accepted, then the tunnel runs from PAR to >>> nCoA on the MN. If not, then the current spec runs the tunnel to the >>> NAR. >>> >>> I'm proposing to modify this. The modification is that the >>> specification of a tunnel to NAR is dropped. Instead, the >>> specification requires the MN to do oDAD on the new link and send FBU >>> to the PAR again from the new link with the new CoA, treating the >>> handover as reactive. >>> >>>>> >>>>> 2) The MN gets the FBack on the NAR as the first packet when it >>>>> arrives on the link, in which case the MN can take the action above. >>>>> >>>> >>>> Before the MN receives FBack, it would have sent FNA to which the >>>> NAR would respond NAACK. In any event, the tunnel is already set up >>>> (hence FBack is waiting in the queue). >>>> >>> >>> I'm proposing the FBack is only sent through NAR to the nCoA if the >>> proposed nCoA is accepted (it is always sent through PAR to the >>> oCoA). If the proposed nCoA is not accepted, no FBack is sent and the >>> MN must again failover to reactive handover. >>> >>> As a separate issue, we can discuss NAR and NAACK v.s. a simple NS. >>> >>>> So, when PAR - NCoA tunnel fails (very rarely I would think), PAR - >>>> NAR tunnel is already set up providing the predictive handover >>>> features when the MN shows up on NAR's link. >>>> >>> >>> Right. I'm proposing that since this is a very rare event, we drop >>> this additional feature with the attendant code and additional >>> complexity and instead use features that are already part of the >>> protocol and necessary for other reasons (i.e. reactive handover) to >>> solve the problem, thereby simplifying the protocol. >>> >>> Would you like me to make a proposal in the issue data base on this? >>> >>> jak >>> >> > > _______________________________________________ Mipshop mailing list Mipshop@ietf.org https://www1.ietf.org/mailman/listinfo/mipshop From ecrit-bounces@ietf.org Fri Sep 16 14:17:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGKmI-0005n5-Hi; Fri, 16 Sep 2005 14:17:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGKmI-0005mv-4i for ecrit@megatron.ietf.org; Fri, 16 Sep 2005 14:17:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02427 for ; Fri, 16 Sep 2005 14:17:36 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGKrK-0005Y5-Pu for ecrit@ietf.org; Fri, 16 Sep 2005 14:22:52 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 16 Sep 2005 11:17:28 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8GIH35E007360 for ; Fri, 16 Sep 2005 11:17:23 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 11:17:24 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 11:17:23 -0700 From: "Marc Linsner" To: Date: Fri, 16 Sep 2005 14:17:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW66t0fC+l6aCYsQXOmCD+a/2vJdg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 16 Sep 2005 18:17:24.0057 (UTC) FILETIME=[E2D3C490:01C5BAEA] X-Spam-Score: 1.1 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Subject: [Ecrit] Proposed Requirement X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org A proposed new requirement for the 'almost finished' req. draft..... Requirement: The ecrit mechanism will only deal with location data in value form, any location by-reference or location-key MUST be resolved to a location by-value prior to query submission to the mapping database. Motivation: It cannot be expected that the entities considered to be 'the mapping database' (accepting the queries and returning a resolution) of the location mapping-to-uri function be part of any trust or authentication mechanism that may be required to resolve location by-reference/location-key. This requirement spurs the need to define location by-reference, location-key and location by-value in section 2 - Terminology. Hence.... Location by-reference: A URI that when accessed by an authorized entity will yield the location of the end-point to which the reference is associated. Location-Key: A mechanism used to provide a reference to a location. This may be a URI, a URL or some other kind of identifier. Location by-value: The location data in it's native form (see location). Fire-away, -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 16 15:23:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGLo4-0005zn-4H; Fri, 16 Sep 2005 15:23:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGLo1-0005zf-US for ecrit@megatron.ietf.org; Fri, 16 Sep 2005 15:23:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06816 for ; Fri, 16 Sep 2005 15:23:27 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGLt5-0007Gf-4M for ecrit@ietf.org; Fri, 16 Sep 2005 15:28:44 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 16 Sep 2005 12:23:19 -0700 X-IronPort-AV: i="3.97,117,1125903600"; d="scan'208"; a="342430566:sNHT31132412" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8GJMh5I011470; Fri, 16 Sep 2005 12:23:14 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 12:23:07 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 12:23:06 -0700 From: "Marc Linsner" To: "'Andrew Newton'" Subject: RE: [Ecrit] draft-polk-dhc-uri-00 Date: Fri, 16 Sep 2005 15:23:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW66qAJmP5WFx5DSASgKsSi0hqaDgAA6LiA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Message-ID: X-OriginalArrivalTime: 16 Sep 2005 19:23:06.0979 (UTC) FILETIME=[10FDEB30:01C5BAF4] X-Spam-Score: 1.1 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Andy, > > Correct me if wrong....in practice, are not DNS TTLs normally much > > shorter than DHCP lease times? > > TTLs where? in the roots? in TLDs? in SLDs? From what > Henning has said, for this particular case they would be set > for a very, very long time. I take that to mean months. I can't comment on Henning's statement, I don't know the context. But I can't imagine whatever mechanism ends up being the solution to effect emergency call routing changes, that most PSAPs will agree to 'months'. My experience (admittedly not much) has been DHCP lease times in numbers of days/weeks whereas DNS TTL in numbers of hours. The main point is PSAPs will know/control the TTL in the DNS solution, neither of which can ever happen with dhcp servers that distribute the PSAP uri. You are absolutely correct, once the TTL is set and read, it can't be retracted until the caching entity's timer expires, but the point, it's a known (by the PSAP) parameter. The requirement/use case is the ability to change the routing of emergency calls adhoc, based on unknown/untimed events. I believe we should deliver this capability to the PSAP community, even if it has the baggage of the known/controllable timing parameters. > > > Of course, beyond the above philosophical argument, the PSAP has no > > control over DHCP lease times, where in the proposed DNS solution, > > they have control over TTLs. > > True, but it doesn't disprove my point. > > I also wonder, if DHCP lease times are so untrustworthy, then > perhaps LCI should not be delivered via DHCP either. I don't understand your tie between lease time and LCI in a wired environment (the target of RFC3825 and the dhc civic draft)? Are you assuming a wired device can change location (unplug and reattach at another network access point) without recontacting dhcp? We normally consider walking the distances allowed by your ethernet-to-wall-jack cord to be the same location. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 16 15:59:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGMMc-0005Tu-9H; Fri, 16 Sep 2005 15:59:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGMMb-0005Tp-KV for ecrit@megatron.ietf.org; Fri, 16 Sep 2005 15:59:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09506 for ; Fri, 16 Sep 2005 15:59:11 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGMRd-000072-2o for ecrit@ietf.org; Fri, 16 Sep 2005 16:04:28 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 16 Sep 2005 15:59:02 -0400 id 000C7FBF.432B2406.000035E3 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] draft-polk-dhc-uri-00 Date: Fri, 16 Sep 2005 15:59:05 -0400 To: Marc Linsner X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 16, 2005, at 3:23 PM, Marc Linsner wrote: > My experience (admittedly not much) has been DHCP lease times in > numbers of > days/weeks whereas DNS TTL in numbers of hours. Hours? COM/NET is 2 days. I normally use one week for my SLDs. > The main point is PSAPs > will know/control the TTL in the DNS solution, neither of which can > ever > happen with dhcp servers that distribute the PSAP uri. You are > absolutely > correct, once the TTL is set and read, it can't be retracted until the > caching entity's timer expires, but the point, it's a known (by the > PSAP) > parameter. The requirement/use case is the ability to change the > routing of > emergency calls adhoc, based on unknown/untimed events. I believe > we should > deliver this capability to the PSAP community, even if it has the > baggage of > the known/controllable timing parameters. From Brian's email: > I'm not sure what your experience is. Mine is that disasters don't go > according to plan. You plan for disasters, and then you deal with > what > actually happens. Often, what you thought would work, doesn't. So the objection was about things that do not go according to plan. You are arguing that one method is better than the other. I am arguing that when you look at the objection, there is no difference. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 16 16:50:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGNAB-0004PS-Hq; Fri, 16 Sep 2005 16:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGNA8-0004PE-Jf for ecrit@megatron.ietf.org; Fri, 16 Sep 2005 16:50:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18972 for ; Fri, 16 Sep 2005 16:50:21 -0400 (EDT) Received: from firewall.objectworld.com ([209.87.233.180] helo=photon.objectworld.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGNFB-0003px-MC for ecrit@ietf.org; Fri, 16 Sep 2005 16:55:39 -0400 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] draft-polk-dhc-uri-00 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 16 Sep 2005 16:50:02 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C50F2ECD@photon.objectworld.com> Thread-Topic: [Ecrit] draft-polk-dhc-uri-00 Thread-Index: AcW66qAJmP5WFx5DSASgKsSi0hqaDgAA6LiAAAQcruA= From: "Michael Slavitch" To: "Marc Linsner" , "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org >I don't understand your tie between lease time and LCI in a wired environment (the target of RFC3825=20 >and the dhc civic draft)? Are you assuming a wired device can change location (unplug and reattach at >another network access point) without recontacting dhcp? We normally consider walking the distances=20 >allowed by your ethernet-to-wall-jack cord to be the same location. A wired device can most certainly do this in a layer two switched network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 16 17:26:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGNid-0003lo-0x; Fri, 16 Sep 2005 17:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGNib-0003le-EF for ecrit@megatron.ietf.org; Fri, 16 Sep 2005 17:26:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20448 for ; Fri, 16 Sep 2005 17:25:58 -0400 (EDT) From: mhammer@cisco.com Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGNnf-0004fA-Qa for ecrit@ietf.org; Fri, 16 Sep 2005 17:31:17 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 16 Sep 2005 17:25:52 -0400 X-IronPort-AV: i="3.97,117,1125892800"; d="scan'208"; a="70601059:sNHT35482796" 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 j8GLP6RP024917; Fri, 16 Sep 2005 17:25:49 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 17:25:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] RE: draft-polk-dhc-uri-00 Date: Fri, 16 Sep 2005 17:25:43 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E38FA8F2@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] RE: draft-polk-dhc-uri-00 Thread-Index: AcW6yE0A0E7Ew6vWQQi8yIMpcBunewAO/O5A To: "Andrew Newton" , "Stastny Richard" X-OriginalArrivalTime: 16 Sep 2005 21:25:44.0447 (UTC) FILETIME=[326270F0:01C5BB05] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Also, is that a query done an hour ago when all was calm,=20 or right now in the middle of an emergency,=20 when the DNS is Choice{overloaded, under DoS attack, down,...} and requests are timing out? Mike Not knowing where the 1 or more points of failure will occur is not the same as not knowing where points of failure can occur and planning for when each of those points do fail. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Andrew Newton > Sent: Friday, September 16, 2005 10:07 AM > To: Stastny Richard > Cc: ECRIT > Subject: Re: [Ecrit] RE: draft-polk-dhc-uri-00 >=20 >=20 > On Sep 15, 2005, at 3:58 PM, Stastny Richard wrote: >=20 > > Is there a possibility to get this question back to facts: > > what will the average call setup delay be for lets say one=20 > additional=20 > > DNS query to the x queries required to do the call-setup from the=20 > > client to the PSAP, eventually via an ESRP and a ESGW in the first=20 > > place? >=20 > Which proposal is JUST ONE DNS query? >=20 > -andy >=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 Sep 16 18:45:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGOxB-0005JA-3c; Fri, 16 Sep 2005 18:45:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGOx9-0005J0-4d for ecrit@megatron.ietf.org; Fri, 16 Sep 2005 18:45:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24821 for ; Fri, 16 Sep 2005 18:45:03 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGP2E-0006N6-VN for ecrit@ietf.org; Fri, 16 Sep 2005 18:50:23 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 16 Sep 2005 15:44:51 -0700 X-IronPort-AV: i="3.97,118,1125903600"; d="scan'208"; a="342493244:sNHT3994592266" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8GMif4u008787; Fri, 16 Sep 2005 15:44:47 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 15:44:38 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.40]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 15:44:37 -0700 Message-Id: <4.3.2.7.2.20050916151043.03585ad0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Sep 2005 17:44:36 -0500 To: "Stastny Richard" , "Thomson, Martin" , From: "James M. Polk" Subject: RE: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B213E@oefeg-s04.oefeg.loc > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 16 Sep 2005 22:44:38.0031 (UTC) FILETIME=[37D209F0:01C5BB10] X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org comments in line At 10:34 AM 9/15/2005 +0200, Stastny Richard wrote: >Sorry for jumping in into this discussion a bit late >but I had no time up to now to read the draft completely > >I also apologize if I re-query some issues already discussed > >In principle I consider it as a good idea to have a vehicle >to provide such information to a client. > >Having said this, I would like to discuss the purpose list >in detail. > >Purpose = 1 (Primary PSAP URI) > Purpose = 2 (Secondary PSAP URI) > Purpose = 3 (Location By-Reference of Client) > Purpose = 4 (ESGW URI of Client) > Purpose = 5 (ESRP URI of Client) > Purpose = 6 (Location Providing Location for Client) > Purpose = 7 (URI of Geocoding/Reverse Geocoding) > Purpose = 8 (Primary URI of Geo Mapping Service) > Purpose = 9 (Secondary URI of Geo Mapping Service) > Purpose = 10 (Primary URI of Civic Mapping Service) > Purpose = 11 (Secondary URI of Civic Mapping Service) > > >General remark 1 (this was already discussed): >There needs to be a requirement in ecrit req I-D defining >the TTL of such information and therefore the minimum lease time ok >Also the concern of Brian regarding short time changes has to by taken >into >account, which may render the transmissinon of the URI of the Mapping >service and the PSAP useless, because then they always need to be >queried at >emergency call setup. Why "at" call set-up? Why not "before" call set-up? >General remark 2: >Is it necessary to provide secondaries in general? Especially >for SIP URIs (PSAP) this can be done with other means (e.g. SRV RR) I thought I'd include them now and see what the WGs said about the reliance on one or two >Remark ESRP > >If you query the mapping service, you get back a SIP URI. You do >not care if this is a PSAP direct or a ESRP. The client might not, but it might be stored in a server differently. Further, the client could get 3 URIs, Pri and Sec PSAP URIs and the ESRP as another fallback. >As far as I know there >is no distinction within the proposed protocols. So why put >this distinction here. Because we don't know every possible instance of how URIs will be used, and there may be a difference somewhere. >If you have a distinction, you need first >to get the date. the date? I don't understand this. >Since the provider of this date may (Must?) derive >this data from the mapping service anyway, how can he make the >distinction? again - I don't understand this "date" >So IMHO this purpose is not needed. > >Remark ESGW: > >Now here I have a serious problem > >It is stated in the draft > "This purpose=4 URI is for the Emergency Services Gateway that an IP > client would contact when setting up an emergency call with a PSAP > that is not IP enabled. Having this information locally in the > client will allow it to contact the ESGW directly and not have to > rely on an intermediary to determine which ESGW is the right one for > this client, and possibly fail the call set-up during that > determination." > >We are planning to use ESGW, but these may accessed only via >the ESRPs. Is that true for every enterprise network? >The ESGW are basically PoIs to the PSTN. If you access >the ESGW with a SIP URI, you are basically accessing a SIP proxy >and then it is a ESRP. You may be telling a call server which GW to direct the call set-up towards. I believe this applies more to the smaller networks than the open Internet >We are planning to access the ESGW with tel URIs via the ESRP. I believe a tel:uri will be converted to a SIP uri that is then sent to the ESGW, but I could be wrong >It is the task of the ESRP to map the location (via the mapping service >or via a local DB to the NATIONAL routing numbers required to access >the national emergency service network. This mapping is very national >specific (it may not use E.164 numbers). yes - but an ESRP is not always necessary. If the UA has the IP destination URI (be it PSAP or ESGW), there doesn't need to be an ESRP to do the mapping that has already been done. >Since the client is not able in most case to access the ESGW directly >this purpose should not be there. "in most cases" means not all the time, so there are instances in which this can be used, maybe not many >What I am missing in the I-D is a way to provide the client eventually >with the local emergency identifiers remember, this is **NOT** an ECRIT Architecture ID, it is a DHC ID that doesn't need to get into all the architecture stuff of emergency communications. Another ECRIT (or two) ID could/should explain how these purposes are used, including message flows. >Cheers >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 From ecrit-bounces@ietf.org Fri Sep 16 19:10:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGPLc-0002Tf-5m; Fri, 16 Sep 2005 19:10:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGPLa-0002Ta-QJ for ecrit@megatron.ietf.org; Fri, 16 Sep 2005 19:10:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25694 for ; Fri, 16 Sep 2005 19:10:19 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EGPQe-0006pS-LB for ecrit@ietf.org; Fri, 16 Sep 2005 19:15:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals Date: Sat, 17 Sep 2005 01:13:42 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4522@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals Thread-Index: AcW7EMqs6Z6RrA9oT8S/XQ9FkU6F9wAAWayA From: "Stastny Richard" To: "James M. Polk" , "Thomson, Martin" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi James Sorry for the "date" problem, I meant data, but the explanation was not very well formulated anyway. It was a bit late Ok, it is late now again, but lets try I will start with your last remark: =20 >remember, this is **NOT** an ECRIT Architecture ID, it is a DHC ID that >doesn't need to get into all the architecture stuff of emergency >communications. Another ECRIT (or two) ID could/should explain how = these >purposes are used, including message flows. Ok, but we are discussing this on the ecrit list. =20 So in ecrit we must define how the data are distributed to the DHCP servers. One method could be that the DHCP servers are querying periodically the mapping database, because this is IMHO the ONLY authoritative source for the location to PSAP URI mapping Any other means would end up in a complete mess (one cannot expect thousands of DHCP servers updated properly if a PSAP URI changes) =20 So the PSAP URI may be retrieved in that way, but I did not see in any of the proposals of the mapping database a datafield indicating a destinction between a PSAP URI or a ESRP URI, and I also did not see an ESGW URI =20 So where are these DATA coming from? The only data in the mapping database up to now is a SIP URI. We would propose to provide IN ADDITION to the PSAP URI (which may also be an ESRP URI -who cares) a TEL URI. This TEL URI may either be used by the ESRP to access an ESGW or maybe by any network knowing or owning a gateway and also knowing the (national) context. =20 cheers =20 Richard ________________________________ Von: James M. Polk [mailto:jmpolk@cisco.com] Gesendet: Sa 17.09.2005 00:44 An: Stastny Richard; Thomson, Martin; ecrit@ietf.org Betreff: RE: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals comments in line At 10:34 AM 9/15/2005 +0200, Stastny Richard wrote: >Sorry for jumping in into this discussion a bit late >but I had no time up to now to read the draft completely > >I also apologize if I re-query some issues already discussed > >In principle I consider it as a good idea to have a vehicle >to provide such information to a client. > >Having said this, I would like to discuss the purpose list >in detail. > >Purpose =3D 1 (Primary PSAP URI) > Purpose =3D 2 (Secondary PSAP URI) > Purpose =3D 3 (Location By-Reference of Client) > Purpose =3D 4 (ESGW URI of Client) > Purpose =3D 5 (ESRP URI of Client) > Purpose =3D 6 (Location Providing Location for Client) > Purpose =3D 7 (URI of Geocoding/Reverse Geocoding) > Purpose =3D 8 (Primary URI of Geo Mapping Service) > Purpose =3D 9 (Secondary URI of Geo Mapping Service) > Purpose =3D 10 (Primary URI of Civic Mapping Service) > Purpose =3D 11 (Secondary URI of Civic Mapping Service) > > >General remark 1 (this was already discussed): >There needs to be a requirement in ecrit req I-D defining >the TTL of such information and therefore the minimum lease time ok >Also the concern of Brian regarding short time changes has to by taken >into >account, which may render the transmissinon of the URI of the Mapping >service and the PSAP useless, because then they always need to be >queried at >emergency call setup. Why "at" call set-up? Why not "before" call set-up? >General remark 2: >Is it necessary to provide secondaries in general? Especially >for SIP URIs (PSAP) this can be done with other means (e.g. SRV RR) I thought I'd include them now and see what the WGs said about the = reliance on one or two >Remark ESRP > >If you query the mapping service, you get back a SIP URI. You do >not care if this is a PSAP direct or a ESRP. The client might not, but it might be stored in a server differently. Further, the client could get 3 URIs, Pri and Sec PSAP URIs and the ESRP = as another fallback. >As far as I know there >is no distinction within the proposed protocols. So why put >this distinction here. Because we don't know every possible instance of how URIs will be used, = and there may be a difference somewhere. >If you have a distinction, you need first >to get the date. the date? I don't understand this. >Since the provider of this date may (Must?) derive >this data from the mapping service anyway, how can he make the >distinction? again - I don't understand this "date" >So IMHO this purpose is not needed. > >Remark ESGW: > >Now here I have a serious problem > >It is stated in the draft > "This purpose=3D4 URI is for the Emergency Services Gateway that an = IP > client would contact when setting up an emergency call with a PSAP > that is not IP enabled. Having this information locally in the > client will allow it to contact the ESGW directly and not have to > rely on an intermediary to determine which ESGW is the right one = for > this client, and possibly fail the call set-up during that > determination." > >We are planning to use ESGW, but these may accessed only via >the ESRPs. Is that true for every enterprise network? >The ESGW are basically PoIs to the PSTN. If you access >the ESGW with a SIP URI, you are basically accessing a SIP proxy >and then it is a ESRP. You may be telling a call server which GW to direct the call set-up towards. I believe this applies more to the smaller networks than the = open Internet >We are planning to access the ESGW with tel URIs via the ESRP. I believe a tel:uri will be converted to a SIP uri that is then sent to = the ESGW, but I could be wrong >It is the task of the ESRP to map the location (via the mapping service >or via a local DB to the NATIONAL routing numbers required to access >the national emergency service network. This mapping is very national >specific (it may not use E.164 numbers). yes - but an ESRP is not always necessary. If the UA has the IP destination URI (be it PSAP or ESGW), there doesn't need to be an ESRP to do the mapping that has already been done. >Since the client is not able in most case to access the ESGW directly >this purpose should not be there. "in most cases" means not all the time, so there are instances in which this can be used, maybe not many >What I am missing in the I-D is a way to provide the client eventually >with the local emergency identifiers remember, this is **NOT** an ECRIT Architecture ID, it is a DHC ID that doesn't need to get into all the architecture stuff of emergency communications. Another ECRIT (or two) ID could/should explain how these purposes are used, including message flows. >Cheers >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 From ecrit-bounces@ietf.org Fri Sep 16 21:10:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGRDu-0003K4-95; Fri, 16 Sep 2005 21:10:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGRDr-0003Jo-Uf for ecrit@megatron.ietf.org; Fri, 16 Sep 2005 21:10:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00540 for ; Fri, 16 Sep 2005 21:10:29 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGRIw-0000ss-P7 for ecrit@ietf.org; Fri, 16 Sep 2005 21:15:49 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 16 Sep 2005 18:10:18 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8H19V53029051; Fri, 16 Sep 2005 18:10:14 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 18:10:07 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.40]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 18:10:06 -0700 Message-Id: <4.3.2.7.2.20050916195002.0377ec10@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Sep 2005 20:10:05 -0500 To: "Stastny Richard" , "Thomson, Martin" , From: "James M. Polk" Subject: RE: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4522@oefeg-s04.oefeg.loc > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 17 Sep 2005 01:10:07.0008 (UTC) FILETIME=[8AB23A00:01C5BB24] X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 01:13 AM 9/17/2005 +0200, Stastny Richard wrote: >Hi James > >Sorry for the "date" problem, I meant data, but the explanation >was not very well formulated anyway. It was a bit late fair it's past Miller Time here too... >Ok, it is late now again, but lets try > >I will start with your last remark: > > >remember, this is **NOT** an ECRIT Architecture ID, it is a DHC ID that > >doesn't need to get into all the architecture stuff of emergency > >communications. Another ECRIT (or two) ID could/should explain how these > >purposes are used, including message flows. > >Ok, but we are discussing this on the ecrit list. yes, and we need to take the context of each topic and determine where it needs to be discussed. In other words, just because no official architecture doc exists doesn't mean we don't talk about architectures. Conversly, just because a single mechanism document is offered doesn't mean it has to cover every bit of the overlaying architecture that can take advantage of it. This gets to your point just below: > >So in ecrit we must define how the data are distributed >to the DHCP servers. One method could be that the >DHCP servers are querying periodically the mapping >database, because this is IMHO the ONLY authoritative >source for the location to PSAP URI mapping The DHCP servers will interact with the wire map database server to get location for endpoints based on a circuit ID (for RFC 3825). I expect the DHCP servers will interact periodically with your authoritative source for PSAP URI mapping to location jurisdications. The timing of the interaction should be configurable, and a local policy decision. I guess I can add some text to address this to the ID. >Any other means would end up in a complete mess I do not know another one that would work >(one >cannot expect thousands of DHCP servers updated >properly if a PSAP URI changes) I think this will happen, but it is a question of how long this will take to fully populate to the servers, and then get to the clients > >So the PSAP URI may be retrieved in that way, but >I did not see in any of the proposals of the mapping >database a datafield indicating a destinction between >a PSAP URI or a ESRP URI, and I also did not >see an ESGW URI > >So where are these DATA coming from? PSAP URIs are not in existence yet, and we need to create them. Just as is true for the ESRP and ESGW URIs. A URI is a unique identifier, that's all (conceptually). An ESRP just has to be uniquely identifable and accept messages to that URI How those URIs get distributed is another exercise. >The only data in the mapping database up >to now is a SIP URI. Figuratively speaking, because not one database has been created yet. The ESRP might not come from the PSAP community anyway, but could come from another source, like the LLP. If I want service from a particular LLP, they ask what state/province I'm in, I tell them, they configure my location to that URI, that propagates to their DHCP servers waiting for my device(s) at my address to boot up to request the URIs. >We would propose >to provide IN ADDITION to the PSAP >URI (which may also be an ESRP URI -who cares) >a TEL URI. Are tel:uris routable? If not, they need to be converted to SIP URIs, which are routable, and that URI could be to a ESRP, ESGW or PSAP... >This TEL URI may either be used >by the ESRP to access an ESGW or maybe >by any network knowing or owning a gateway >and also knowing the (national) context. > >cheers > >Richard > > >________________________________ > >Von: James M. Polk [mailto:jmpolk@cisco.com] >Gesendet: Sa 17.09.2005 00:44 >An: Stastny Richard; Thomson, Martin; ecrit@ietf.org >Betreff: RE: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals > > > >comments in line > >At 10:34 AM 9/15/2005 +0200, Stastny Richard wrote: > >Sorry for jumping in into this discussion a bit late > >but I had no time up to now to read the draft completely > > > >I also apologize if I re-query some issues already discussed > > > >In principle I consider it as a good idea to have a vehicle > >to provide such information to a client. > > > >Having said this, I would like to discuss the purpose list > >in detail. > > > >Purpose = 1 (Primary PSAP URI) > > Purpose = 2 (Secondary PSAP URI) > > Purpose = 3 (Location By-Reference of Client) > > Purpose = 4 (ESGW URI of Client) > > Purpose = 5 (ESRP URI of Client) > > Purpose = 6 (Location Providing Location for Client) > > Purpose = 7 (URI of Geocoding/Reverse Geocoding) > > Purpose = 8 (Primary URI of Geo Mapping Service) > > Purpose = 9 (Secondary URI of Geo Mapping Service) > > Purpose = 10 (Primary URI of Civic Mapping Service) > > Purpose = 11 (Secondary URI of Civic Mapping Service) > > > > > >General remark 1 (this was already discussed): > >There needs to be a requirement in ecrit req I-D defining > >the TTL of such information and therefore the minimum lease time > >ok > > > >Also the concern of Brian regarding short time changes has to by taken > >into > >account, which may render the transmissinon of the URI of the Mapping > >service and the PSAP useless, because then they always need to be > >queried at > >emergency call setup. > >Why "at" call set-up? Why not "before" call set-up? > > > >General remark 2: > >Is it necessary to provide secondaries in general? Especially > >for SIP URIs (PSAP) this can be done with other means (e.g. SRV RR) > >I thought I'd include them now and see what the WGs said about the reliance >on one or two > > > >Remark ESRP > > > >If you query the mapping service, you get back a SIP URI. You do > >not care if this is a PSAP direct or a ESRP. > >The client might not, but it might be stored in a server differently. >Further, the client could get 3 URIs, Pri and Sec PSAP URIs and the ESRP as >another fallback. > > >As far as I know there > >is no distinction within the proposed protocols. So why put > >this distinction here. > >Because we don't know every possible instance of how URIs will be used, and >there may be a difference somewhere. > > >If you have a distinction, you need first > >to get the date. > >the date? I don't understand this. > > >Since the provider of this date may (Must?) derive > >this data from the mapping service anyway, how can he make the > >distinction? > >again - I don't understand this "date" > > > >So IMHO this purpose is not needed. > > > >Remark ESGW: > > > >Now here I have a serious problem > > > >It is stated in the draft > > "This purpose=4 URI is for the Emergency Services Gateway that an IP > > client would contact when setting up an emergency call with a PSAP > > that is not IP enabled. Having this information locally in the > > client will allow it to contact the ESGW directly and not have to > > rely on an intermediary to determine which ESGW is the right one for > > this client, and possibly fail the call set-up during that > > determination." > > > >We are planning to use ESGW, but these may accessed only via > >the ESRPs. > >Is that true for every enterprise network? > > >The ESGW are basically PoIs to the PSTN. If you access > >the ESGW with a SIP URI, you are basically accessing a SIP proxy > >and then it is a ESRP. > >You may be telling a call server which GW to direct the call set-up >towards. I believe this applies more to the smaller networks than the open >Internet > > > >We are planning to access the ESGW with tel URIs via the ESRP. > >I believe a tel:uri will be converted to a SIP uri that is then sent to the >ESGW, but I could be wrong > > >It is the task of the ESRP to map the location (via the mapping service > >or via a local DB to the NATIONAL routing numbers required to access > >the national emergency service network. This mapping is very national > >specific (it may not use E.164 numbers). > >yes - but an ESRP is not always necessary. > >If the UA has the IP destination URI (be it PSAP or ESGW), there doesn't >need to be an ESRP to do the mapping that has already been done. > > > >Since the client is not able in most case to access the ESGW directly > >this purpose should not be there. > >"in most cases" means not all the time, so there are instances in which >this can be used, maybe not many > > >What I am missing in the I-D is a way to provide the client eventually > >with the local emergency identifiers > >remember, this is **NOT** an ECRIT Architecture ID, it is a DHC ID that >doesn't need to get into all the architecture stuff of emergency >communications. Another ECRIT (or two) ID could/should explain how these >purposes are used, including message flows. > > > >Cheers > >Richard > > >cheers, >James > > ******************* > Truth is not to be argued... it is to be presented. 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 Sep 16 22:27:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGSQ9-0004hj-Mc; Fri, 16 Sep 2005 22:27:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGSQ7-0004hb-5p for ecrit@megatron.ietf.org; Fri, 16 Sep 2005 22:27:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04641 for ; Fri, 16 Sep 2005 22:27:12 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGSVE-0002oA-7G for ecrit@ietf.org; Fri, 16 Sep 2005 22:32:33 -0400 Received: from [192.168.0.37] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j8H2QFpN028019 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 16 Sep 2005 22:27:12 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] terminology Date: Fri, 16 Sep 2005 20:33:15 -0400 To: Marc Linsner X-Mailer: Apple Mail (2.733) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: 'Stastny Richard' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 16, 2005, at 9:45 AM, Marc Linsner wrote: > I would rather not have any reference to layer 1.....please replace > with > layer 2. Typo on my part. Definitely should have been L2. > > 1) I doubt if dry copper or dark fiber is marketed any longer....at > least in > use cases we are concerned with. > Not particularly relevant, but it is becoming extremely popular for large universities. All NYC and beyond research universities are converting to getting dark fiber and ditching their traditional SONET or similar provider. Google is apparently doing something similar, for ends unknown (to me). > 2) Although I agree that knowledge of layer 1 is where the actual > information is derived for 'network-based location mechanisms for > physical > media' discussed here, we are only concerned with a mechanism that > attempts > to 'automate' gathering this location information. Since dry > copper and > dark fiber can't 'talk', it is much easier to deal with the media > access > control protocols that can/do 'talk'. (Plus the fact we would bring > wikipedia to it's knees attempting to understand layer 1 wrt to > wireless.) > > So, I don't care about labels as long as they have reference to 2, > 3, and > 7.... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 17 04:09:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGXlR-0004Cm-57; Sat, 17 Sep 2005 04:09:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGXlN-0004Ch-Q7 for ecrit@megatron.ietf.org; Sat, 17 Sep 2005 04:09:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01097 for ; Sat, 17 Sep 2005 04:09:31 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EGXqX-0001VB-Ol for ecrit@ietf.org; Sat, 17 Sep 2005 04:14:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals Date: Sat, 17 Sep 2005 10:12:55 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4523@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals Thread-Index: AcW7JRiM/UTOXjGyRKqG6p/BRRJBuwAOMumo From: "Stastny Richard" To: "James M. Polk" , "Thomson, Martin" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org >Are tel:uris routable? Not on IP, but on the PSTN >If not, they need to be converted to SIP URIs, which are routable, and = that >URI could be to a ESRP, ESGW or PSAP... The problem here is that the ESGW is not precicely defined I think you are talking about a corporate or campus environment using a UNI. I am talking about a Point-of-Interconnect (PoI) using a NNI. NNIs can never be accessed by the end-user directly. That was the reason that although we have an ESGW in the architecture; we considered it as a part of or behind an ESRP. The access from ESRP to ESGW is already a national matter. This may be 1:1 or 1:n The routing between ESRP and ESGW is of course done via SIP, eventally with an embedded Tel URI. The ESGW itself understands only Tel URIs. Which ESGW to use depends eventually on the information contained in the Tel-URI and also on fail-over, etc. Having said that, if the ESGW is used in your case for UNI-GWs, I have no problem with it, we would just not use it. BTW, I have another serious proble with your proposal I have not brought forward yet: You assume only ONE PSAP, but there are countries out there with more then one emergency numbers. We have 9 (no comments on this, please ;-) This implies, that we would need 2x3x9 =3D 54 URI purposes for ES alone ;-) cheers Richard ________________________________ Von: James M. Polk [mailto:jmpolk@cisco.com] Gesendet: Sa 17.09.2005 03:10 An: Stastny Richard; Thomson, Martin; ecrit@ietf.org Betreff: RE: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals At 01:13 AM 9/17/2005 +0200, Stastny Richard wrote: >Hi James > >Sorry for the "date" problem, I meant data, but the explanation >was not very well formulated anyway. It was a bit late fair it's past Miller Time here too... >Ok, it is late now again, but lets try > >I will start with your last remark: > > >remember, this is **NOT** an ECRIT Architecture ID, it is a DHC ID = that > >doesn't need to get into all the architecture stuff of emergency > >communications. Another ECRIT (or two) ID could/should explain how = these > >purposes are used, including message flows. > >Ok, but we are discussing this on the ecrit list. yes, and we need to take the context of each topic and determine where = it needs to be discussed. In other words, just because no official architecture doc exists doesn't mean we don't talk about architectures. Conversly, just because a single mechanism document is offered doesn't = mean it has to cover every bit of the overlaying architecture that can take advantage of it. This gets to your point just below: > >So in ecrit we must define how the data are distributed >to the DHCP servers. One method could be that the >DHCP servers are querying periodically the mapping >database, because this is IMHO the ONLY authoritative >source for the location to PSAP URI mapping The DHCP servers will interact with the wire map database server to get location for endpoints based on a circuit ID (for RFC 3825). I expect = the DHCP servers will interact periodically with your authoritative source = for PSAP URI mapping to location jurisdications. The timing of the interaction should be configurable, and a local policy decision. I guess I can add some text to address this to the ID. >Any other means would end up in a complete mess I do not know another one that would work >(one >cannot expect thousands of DHCP servers updated >properly if a PSAP URI changes) I think this will happen, but it is a question of how long this will = take to fully populate to the servers, and then get to the clients > >So the PSAP URI may be retrieved in that way, but >I did not see in any of the proposals of the mapping >database a datafield indicating a destinction between >a PSAP URI or a ESRP URI, and I also did not >see an ESGW URI > >So where are these DATA coming from? PSAP URIs are not in existence yet, and we need to create them. Just as = is true for the ESRP and ESGW URIs. A URI is a unique identifier, that's = all (conceptually). An ESRP just has to be uniquely identifable and accept messages to that URI How those URIs get distributed is another exercise. >The only data in the mapping database up >to now is a SIP URI. Figuratively speaking, because not one database has been created yet. The ESRP might not come from the PSAP community anyway, but could come = from another source, like the LLP. If I want service from a particular LLP, = they ask what state/province I'm in, I tell them, they configure my location = to that URI, that propagates to their DHCP servers waiting for my device(s) = at my address to boot up to request the URIs. >We would propose >to provide IN ADDITION to the PSAP >URI (which may also be an ESRP URI -who cares) >a TEL URI. Are tel:uris routable? If not, they need to be converted to SIP URIs, which are routable, and = that URI could be to a ESRP, ESGW or PSAP... >This TEL URI may either be used >by the ESRP to access an ESGW or maybe >by any network knowing or owning a gateway >and also knowing the (national) context. > >cheers > >Richard > > >________________________________ > >Von: James M. Polk [mailto:jmpolk@cisco.com] >Gesendet: Sa 17.09.2005 00:44 >An: Stastny Richard; Thomson, Martin; ecrit@ietf.org >Betreff: RE: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals > > > >comments in line > >At 10:34 AM 9/15/2005 +0200, Stastny Richard wrote: > >Sorry for jumping in into this discussion a bit late > >but I had no time up to now to read the draft completely > > > >I also apologize if I re-query some issues already discussed > > > >In principle I consider it as a good idea to have a vehicle > >to provide such information to a client. > > > >Having said this, I would like to discuss the purpose list > >in detail. > > > >Purpose =3D 1 (Primary PSAP URI) > > Purpose =3D 2 (Secondary PSAP URI) > > Purpose =3D 3 (Location By-Reference of Client) > > Purpose =3D 4 (ESGW URI of Client) > > Purpose =3D 5 (ESRP URI of Client) > > Purpose =3D 6 (Location Providing Location for Client) > > Purpose =3D 7 (URI of Geocoding/Reverse Geocoding) > > Purpose =3D 8 (Primary URI of Geo Mapping Service) > > Purpose =3D 9 (Secondary URI of Geo Mapping Service) > > Purpose =3D 10 (Primary URI of Civic Mapping Service) > > Purpose =3D 11 (Secondary URI of Civic Mapping Service) > > > > > >General remark 1 (this was already discussed): > >There needs to be a requirement in ecrit req I-D defining > >the TTL of such information and therefore the minimum lease time > >ok > > > >Also the concern of Brian regarding short time changes has to by = taken > >into > >account, which may render the transmissinon of the URI of the Mapping > >service and the PSAP useless, because then they always need to be > >queried at > >emergency call setup. > >Why "at" call set-up? Why not "before" call set-up? > > > >General remark 2: > >Is it necessary to provide secondaries in general? Especially > >for SIP URIs (PSAP) this can be done with other means (e.g. SRV RR) > >I thought I'd include them now and see what the WGs said about the = reliance >on one or two > > > >Remark ESRP > > > >If you query the mapping service, you get back a SIP URI. You do > >not care if this is a PSAP direct or a ESRP. > >The client might not, but it might be stored in a server differently. >Further, the client could get 3 URIs, Pri and Sec PSAP URIs and the = ESRP as >another fallback. > > >As far as I know there > >is no distinction within the proposed protocols. So why put > >this distinction here. > >Because we don't know every possible instance of how URIs will be used, = and >there may be a difference somewhere. > > >If you have a distinction, you need first > >to get the date. > >the date? I don't understand this. > > >Since the provider of this date may (Must?) derive > >this data from the mapping service anyway, how can he make the > >distinction? > >again - I don't understand this "date" > > > >So IMHO this purpose is not needed. > > > >Remark ESGW: > > > >Now here I have a serious problem > > > >It is stated in the draft > > "This purpose=3D4 URI is for the Emergency Services Gateway that = an IP > > client would contact when setting up an emergency call with a = PSAP > > that is not IP enabled. Having this information locally in the > > client will allow it to contact the ESGW directly and not have to > > rely on an intermediary to determine which ESGW is the right one = for > > this client, and possibly fail the call set-up during that > > determination." > > > >We are planning to use ESGW, but these may accessed only via > >the ESRPs. > >Is that true for every enterprise network? > > >The ESGW are basically PoIs to the PSTN. If you access > >the ESGW with a SIP URI, you are basically accessing a SIP proxy > >and then it is a ESRP. > >You may be telling a call server which GW to direct the call set-up >towards. I believe this applies more to the smaller networks than the = open >Internet > > > >We are planning to access the ESGW with tel URIs via the ESRP. > >I believe a tel:uri will be converted to a SIP uri that is then sent to = the >ESGW, but I could be wrong > > >It is the task of the ESRP to map the location (via the mapping = service > >or via a local DB to the NATIONAL routing numbers required to access > >the national emergency service network. This mapping is very national > >specific (it may not use E.164 numbers). > >yes - but an ESRP is not always necessary. > >If the UA has the IP destination URI (be it PSAP or ESGW), there = doesn't >need to be an ESRP to do the mapping that has already been done. > > > >Since the client is not able in most case to access the ESGW directly > >this purpose should not be there. > >"in most cases" means not all the time, so there are instances in which >this can be used, maybe not many > > >What I am missing in the I-D is a way to provide the client = eventually > >with the local emergency identifiers > >remember, this is **NOT** an ECRIT Architecture ID, it is a DHC ID that >doesn't need to get into all the architecture stuff of emergency >communications. Another ECRIT (or two) ID could/should explain how = these >purposes are used, including message flows. > > > >Cheers > >Richard > > >cheers, >James > > ******************* > Truth is not to be argued... it is to be presented. 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 Sep 17 12:00:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGf6y-0004pG-0P; Sat, 17 Sep 2005 12:00:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGf6u-0004oV-3I for ecrit@megatron.ietf.org; Sat, 17 Sep 2005 12:00:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19531 for ; Sat, 17 Sep 2005 12:00:13 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGfC8-0002ZF-8w for ecrit@ietf.org; Sat, 17 Sep 2005 12:05:41 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j8HG0BhK002574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 17 Sep 2005 12:00:11 -0400 (EDT) Message-ID: <432C3D7C.4040306@cs.columbia.edu> Date: Sat, 17 Sep 2005 11:59:56 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'ECRIT'" Subject: Re: [Ecrit] draft-polk-dhc-uri-00 (big picture) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 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 I'm not sure a DNS-vs.-DHCP discussion is all that helpful. Since a lot of messages have gone back and forth, it would help me at least to summarize some of the points and see if we can at least agree on the facts. # The system we're building has a number of translations between the "dial emergency number" and the final IP address of the phone of the PSAP call taker, including at least: (1) Caller maps location and service desired to PSAP URL, possibly using the mapping URL conveyed in DHCP (2) The PSAP URL needs to be resolved via a sequence of DNS translations (NAPTR, SRV, A), each of which has a TTL value, based on standard SIP procedures documented in RFC 3263. (3) The DNS resolution points to one or more SIP proxies, which in turn route calls to the next step, either another SIP proxy closer to the call taker or the call taker. Repeat step (2) and (3) until the phone rings. # If the PSAP URL(s) are included in the DHCP information, presumably the DHCP server performs step (1) above, for each attached device based on its location. The draft does not really say so, but I'm certainly hoping that this is not manually configured. Presumably, this would take place at the time the client asks for an address or does a DHCPINFORM. Let's see if I got the picture right. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 17 12:16:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGfMO-0008Sf-Dq; Sat, 17 Sep 2005 12:16:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGfMM-0008SU-Ok for ecrit@megatron.ietf.org; Sat, 17 Sep 2005 12:16:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20454 for ; Sat, 17 Sep 2005 12:16:12 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGfRc-00031J-36 for ecrit@ietf.org; Sat, 17 Sep 2005 12:21:40 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j8HGGDU8004566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 17 Sep 2005 12:16:13 -0400 (EDT) Message-ID: <432C413C.40400@cs.columbia.edu> Date: Sat, 17 Sep 2005 12:15:56 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'ECRIT'" Subject: Re: [Ecrit] draft-polk-dhc-uri-00 (DNS) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Continuing to see if we can get a common picture; sorry to belabor points that everyone knows. # DNS seems to be run in two different "modes". Mode 1 (predictable): The TTL value of the DNS record is long, typically a day for resource records close to the leaves of the tree and longer further up. If a change in assignment is anticipated (e.g., new server), the administrator lowers the TTL value. Due to caching, both old and new IP addresses, for example, need to continue to work during the period when some clients have old information and some get the new information. If you want real failover, you need to list all possible servers in NAPTR and SRV records. This is essentially the approach recommended by SIP. It is not feasible for web applications since A records don't have the necessary properties and HTTP doesn't know about SRV. Mode 2 (CDN mode): This mode is used by Akamai and other content distribution networks (CDNs). The TTL of records is set very low (seconds), with essentially no caching. Often, the answer returned by the DNS server varies by who is asking. This is used for round-robin DNS load balancing and use-nearest-server where the DNS server looks at the querying IP address of the resolver and picks a good answer. If you want failover, the DNS server just returns another (live) server. However, this assumes that the DNS server knows which servers are reachable by the querier. If the network is hosed badly, just because the DNS server responsible for server A can talk to server A does not mean that the client can do likewise. Thus, it is certainly possible to build a DNS-based failover system in Mode 2. Clearly, if a PSAP operates in Mode 1, with A records only, and then suddenly decides that it needs Mode 2, it's in trouble. However, firing its network admin would be one of the appropriate things to do in that case - it clearly didn't use the protocols in the right way. The important point to note is that the PSAP is in control, which includes the ability to shoot itself in the foot. I wouldn't necessarily recommend that PSAPs outsource their DNS operations to FEMA. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Sep 18 14:41:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EH46b-0002G2-Ai; Sun, 18 Sep 2005 14:41:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EH46Z-0002Fx-Kp for ecrit@megatron.ietf.org; Sun, 18 Sep 2005 14:41:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08192 for ; Sun, 18 Sep 2005 14:41:34 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EH4C0-0004zD-P8 for ecrit@ietf.org; Sun, 18 Sep 2005 14:47:15 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 18 Sep 2005 11:41:25 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,120,1125903600"; d="scan'208"; a="10193663:sNHT23043280" Received: from [68.50.138.194] (che-vpn-cluster-1-281.cisco.com [10.86.241.26]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8IIfLT6021681; Sun, 18 Sep 2005 14:41:22 -0400 (EDT) In-Reply-To: References: <200509141531.LAA17265@ietf.org> <42CC6B9B-0362-49CD-BDEE-99A6F82D8332@hxr.us> <288238a691e5974f4453d647477abe3b@cisco.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <69f6934020acb1b9f216336a4fc22c70@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit] draft-polk-dhc-uri-00 Date: Sun, 18 Sep 2005 14:41:17 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Answers embedded in context: On Sep 16, 2005, at 2:13 PM, Andrew Newton wrote: > > On Sep 16, 2005, at 10:47 AM, John Schnizlein wrote: > >> As you know, the caching specification for DNS makes the TTL the >> upper bound on how long before the client gets a fresh value from an >> authoritative server. > > And a DHCP client can renew its lease before the lease time is up. > What's your point? Both are unreliable for the purposes of > preemption. The only point was trying to answer your question. Because the DNS protocol specifies that cached entries time out based on the TTL specified at the authoritative server, delays in getting authoritative responses are controlled at the source. There is no such guarantee for the hypothetical distribution of PSAP information to DHCP servers. How is "purposes of preemption" related to the discussion? >> The problem with using DHCP is not the duration of an address >> lease, but that there is no mechanism identified for getting new URIs >> into the DHCP servers. > > Do DHCP servers have such quirky IP connectivity that they cannot use > the same LCMS as a phone or gateway? Nobody (but you) said that DHCP servers have "quirky IP connectivity". The DHCP server is what performs the protocol function. As a practical matter, since the purpose of DHCP is entirely for configuration within an administration, there is no reason for the host on which the protocol server operates to be reachable from outside the perimeter of that organization. Unlike DNS, DHCP is not designed to provide time-limited, cached-for-efficiency, global access to information. Nothing about this protocol function relates to getting information from outside the local administrative area. If a protocol were proposed to add this capability to DHCP, it would deserve careful review. >> Why is the comparison of DNS and DHCP relevant? Please answer this question before continuing the thread. >> We have seen no argument that continuing the practice of PSAPs (which >> might be SIP proxies for VoIP) routing emergency calls among >> themselves based on location information in the call request. The >> unnecessary "optimization" of getting better than default PSAPs into >> the calling host has unspecified needs for new protocols to >> distribute information that the PSAPs might not want to share as >> widely as proposed. > > The objection raised was not about call routing based on location, but > was about call routing based on disaster recovery. Where was this objection raised? > Again... Perhaps we ought to go back to thrust of the objection that > was raised: a device is given a 24 hour validity duration on a list of > end points but there is an unforeseen reason for it to be updated 12 > hours after the device was given the information. My question was > simply, why is that duration unacceptable when it is a DHCP lease but > acceptable when it is a DNS TTL? Both will prevent the information > from being updated before the end of the duration. I have not seen any claim (other than your strawman) that some delay 'is unacceptable when it is a DHCP lease but acceptable when it is a DNS TTL". Where did you find this claim? The relevant comparison is between the subject proposal for distribution (through an undefined protocol with undefined delays between authoritative information and its use for emergency call routing) and the presumed alternative of PSAP location during the call setup. > I have no problem with calls being routed be proxies. Actually, for > the objection that was raised, that seems to be a pretty good place to > do it. Does this statement imply that you oppose the "optimization" proposed in the subject draft, since it is the source of the problem that raised the objection? > On Sep 16, 2005, at 12:28 PM, Marc Linsner wrote: >> ... >> Of course, beyond the above philosophical argument, the PSAP has no >> control over DHCP lease times, >> where in the proposed DNS solution, they have control over TTLs. > > True, but it doesn't disprove my point. What point is that? > I also wonder, if DHCP lease times are so untrustworthy, then perhaps > LCI should not be delivered via DHCP either. I have not seen any claim that DHCP lease times are untrustworthy. Where was this claimed? The point that has been made is that DHCP is useful for configuring hosts with local information (such as its location) within a local administration, but that it seems a poor choice for obtaining information that can be changed in a remote location under a different administration. The principle is to use protocols for the sorts of things for which they were designed. John _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 19 09:55:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHM70-0000Cj-1p; Mon, 19 Sep 2005 09:55:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHM6z-0000Ce-3O for ecrit@megatron.ietf.org; Mon, 19 Sep 2005 09:55:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21859 for ; Mon, 19 Sep 2005 09:55:10 -0400 (EDT) Message-Id: <200509191355.JAA21859@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHMCb-0007ma-Ti for ecrit@ietf.org; Mon, 19 Sep 2005 10:01:02 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EHM6h-00036w-B9; Mon, 19 Sep 2005 08:54:56 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Marc Linsner'" Subject: RE: [Ecrit] draft-polk-dhc-uri-00 Date: Mon, 19 Sep 2005 09:54:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW6++kVCllVMlQjSmGS2vVrH3toWACJGgNA 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: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think that we should anticipate things going wrong in ways we don't predict. For me, that means that we should NOT rely entirely on old (as in days) mapping data. We should, instead, attempt mapping at the time of the call, and use that. It just seems much more prudent to allow the mapping data to change in time frames measured in hours if not minutes. It may be that it fails, for lots of reasons, and thus we should have a cached version of the mapping available. You can imagine circumstances where you have both a mapping change, and there is overload (or loss of connectivity) to the mapping service. While I would like to engineer systems to reduce the probability, it can happen. Those callers would be hosed. The cached data would be wrong. No system is going to be perfect, or foolproof. All we can do is boost the odds. I think presuming mapping data can change, and thus attempt mapping at the time of the call, is one of the steps we can and should make to improve the odds. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Andrew Newton Sent: Friday, September 16, 2005 3:59 PM To: Marc Linsner Cc: 'ECRIT' Subject: Re: [Ecrit] draft-polk-dhc-uri-00 On Sep 16, 2005, at 3:23 PM, Marc Linsner wrote: > My experience (admittedly not much) has been DHCP lease times in > numbers of > days/weeks whereas DNS TTL in numbers of hours. Hours? COM/NET is 2 days. I normally use one week for my SLDs. > The main point is PSAPs > will know/control the TTL in the DNS solution, neither of which can > ever > happen with dhcp servers that distribute the PSAP uri. You are > absolutely > correct, once the TTL is set and read, it can't be retracted until the > caching entity's timer expires, but the point, it's a known (by the > PSAP) > parameter. The requirement/use case is the ability to change the > routing of > emergency calls adhoc, based on unknown/untimed events. I believe > we should > deliver this capability to the PSAP community, even if it has the > baggage of > the known/controllable timing parameters. From Brian's email: > I'm not sure what your experience is. Mine is that disasters don't go > according to plan. You plan for disasters, and then you deal with > what > actually happens. Often, what you thought would work, doesn't. So the objection was about things that do not go according to plan. You are arguing that one method is better than the other. I am arguing that when you look at the objection, there is no difference. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 19 10:07:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHMIX-0002YN-1q; Mon, 19 Sep 2005 10:07:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHMIV-0002YI-RO for ecrit@megatron.ietf.org; Mon, 19 Sep 2005 10:07:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22562 for ; Mon, 19 Sep 2005 10:07:05 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHMO7-00081d-U0 for ecrit@ietf.org; Mon, 19 Sep 2005 10:12:57 -0400 Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j8JE6N714293; Mon, 19 Sep 2005 16:06:23 +0200 (MEST) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zharhxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 15:06:22 +0100 Received: from [127.0.0.1] ([47.130.17.55] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 10:06:20 -0400 Message-ID: <432EC5D8.5090502@nortel.com> Date: Mon, 19 Sep 2005 10:06:16 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Ecrit] Proposed Requirement References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2005 14:06:21.0100 (UTC) FILETIME=[4FD82EC0:01C5BD23] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I like it. Marc Linsner wrote: > A proposed new requirement for the 'almost finished' req. draft..... > > Requirement: The ecrit mechanism will only deal with location data in value > form, any location by-reference or location-key MUST be resolved to a > location by-value prior to query submission to the mapping database. > > Motivation: It cannot be expected that the entities considered to be 'the > mapping database' (accepting the queries and returning a resolution) of the > location mapping-to-uri function be part of any trust or authentication > mechanism that may be required to resolve location > by-reference/location-key. > > > This requirement spurs the need to define location by-reference, > location-key and location by-value in section 2 - Terminology. Hence.... > > Location by-reference: A URI that when accessed by an authorized entity will > yield the location of the end-point to which the reference is associated. > > Location-Key: A mechanism used to provide a reference to a location. This > may be a URI, a URL or some other kind of identifier. > > Location by-value: The location data in it's native form (see location). > > > Fire-away, > > -Marc- > > _______________________________________________ > 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 Sep 19 13:53:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHPps-00018z-Gv; Mon, 19 Sep 2005 13:53:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHPpr-00018N-Lp for ecrit@megatron.ietf.org; Mon, 19 Sep 2005 13:53:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10396 for ; Mon, 19 Sep 2005 13:53:44 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHPvT-0007PU-S2 for ecrit@ietf.org; Mon, 19 Sep 2005 13:59:37 -0400 Received: from zctfhxm0.corp.nortel.com (zctfhxm0.corp.nortel.com [47.164.129.155]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j8JHrM526635 for ; Mon, 19 Sep 2005 19:53:23 +0200 (MEST) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zctfhxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 19:53:07 +0200 Received: from [127.0.0.1] ([47.130.17.55] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 13:53:06 -0400 Message-ID: <432EFAFA.3020801@nortel.com> Date: Mon, 19 Sep 2005 13:52:58 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2005 17:53:06.0216 (UTC) FILETIME=[FD202280:01C5BD42] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [Ecrit] ECRIT requirements: R5 reprise 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 We had a fair-sized discussion on R5 at the beginning of July. Marc formulated an alternative statement that seemed to hold promise. Andrew ignored it and quarelled with Henning instead. I suggest we go with Marc's formulation with a slight tweak: "R5: The mapping protocol should allow for alternative redundant sources of mapping information, possibly of different degrees of currency. "Motivation: This provides the possibility of having available alternative sources of mapping information when the normal source is unavailable or unreachable, without specifying the means by which the alternative source is created or updated." I think this proposition has concrete implications for protocol design, hence should be stated. Tom Taylor _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 19 14:12:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHQ8P-0006CO-F9; Mon, 19 Sep 2005 14:12:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHQ8O-00069o-A6 for ecrit@megatron.ietf.org; Mon, 19 Sep 2005 14:12:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11600 for ; Mon, 19 Sep 2005 14:12:54 -0400 (EDT) From: mhammer@cisco.com Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHQE1-00081y-Us for ecrit@ietf.org; Mon, 19 Sep 2005 14:18:48 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 19 Sep 2005 11:12:45 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,123,1125903600"; d="scan'208"; a="10328833:sNHT22804648" 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 j8JICgT6025888; Mon, 19 Sep 2005 14:12:43 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 14:12:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] draft-polk-dhc-uri-00 (big picture) Date: Mon, 19 Sep 2005 14:12:37 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E38FAC3C@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] draft-polk-dhc-uri-00 (big picture) Thread-Index: AcW7oVMT7qJlfdqOQaK52SaCerMCbwBlkb4g To: "Henning Schulzrinne" , "ECRIT" X-OriginalArrivalTime: 19 Sep 2005 18:12:38.0036 (UTC) FILETIME=[B795AD40:01C5BD45] X-Spam-Score: 0.3 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Henning, Your (1) may need to be broken down further: User maps to network, network maps to location (network itself may be mobile: planes, trains, automobile, ship), location then maps to PSAP. Of course, if the user has GPS, then the above may be short-circuited. Mike =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Henning Schulzrinne > Sent: Saturday, September 17, 2005 12:00 PM > To: 'ECRIT' > Subject: Re: [Ecrit] draft-polk-dhc-uri-00 (big picture) >=20 > I'm not sure a DNS-vs.-DHCP discussion is all that helpful.=20 > Since a lot of messages have gone back and forth, it would=20 > help me at least to summarize some of the points and see if=20 > we can at least agree on the facts. >=20 > # The system we're building has a number of translations=20 > between the "dial emergency number" and the final IP address=20 > of the phone of the PSAP call taker, including at least: >=20 > (1) Caller maps location and service desired to PSAP URL,=20 > possibly using the mapping URL conveyed in DHCP >=20 > (2) The PSAP URL needs to be resolved via a sequence of DNS=20 > translations (NAPTR, SRV, A), each of which has a TTL value,=20 > based on standard SIP procedures documented in RFC 3263. >=20 > (3) The DNS resolution points to one or more SIP proxies,=20 > which in turn route calls to the next step, either another=20 > SIP proxy closer to the call taker or the call taker. Repeat=20 > step (2) and (3) until the phone rings. >=20 >=20 > # If the PSAP URL(s) are included in the DHCP information,=20 > presumably the DHCP server performs step (1) above, for each=20 > attached device based on its location. The draft does not=20 > really say so, but I'm certainly hoping that this is not=20 > manually configured. Presumably, this would take place at the=20 > time the client asks for an address or does a DHCPINFORM. >=20 > Let's see if I got the picture right. >=20 > Henning >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 19 14:25:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHQKp-0001UW-Pe; Mon, 19 Sep 2005 14:25:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHQKo-0001U3-68 for ecrit@megatron.ietf.org; Mon, 19 Sep 2005 14:25:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12329 for ; Mon, 19 Sep 2005 14:25:44 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHQQS-0008P1-Td for ecrit@ietf.org; Mon, 19 Sep 2005 14:31:38 -0400 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 j8JIPdWk010508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Sep 2005 14:25:40 -0400 (EDT) Message-ID: <432F0280.1080706@cs.columbia.edu> Date: Mon, 19 Sep 2005 14:25:04 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mhammer@cisco.com Subject: Re: [Ecrit] draft-polk-dhc-uri-00 (big picture) References: <072C5B76F7CEAB488172C6F64B30B5E38FAC3C@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E38FAC3C@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is probably true in general, but I'm assuming the availability of location information, as that is more of a GEOPRIV rather than ECRIT concern. I'm hoping that we agree that the details of how a caller got their location information should not matter when determining the PSAP URL. As you allude to, the number of possibilities there are rather large and may not directly involve any mapping, even without GPS. For example, LLDP-MED simply says "hi, your wire is in room 1234" every so often. Also, by mapping I mean the more computer science definition of a functional mapping, i.e., an operation that takes one identifier and returns one or more other identifiers. Henning mhammer@cisco.com wrote: > Henning, > > Your (1) may need to be broken down further: > > User maps to network, > network maps to location (network itself may be mobile: planes, trains, > automobile, ship), > location then maps to PSAP. > > Of course, if the user has GPS, then the above may be short-circuited. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 19 14:27:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHQMt-00028G-2y; Mon, 19 Sep 2005 14:27:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHQMs-000284-GA for ecrit@megatron.ietf.org; Mon, 19 Sep 2005 14:27:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12409 for ; Mon, 19 Sep 2005 14:27:52 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHQSX-0008SF-9l for ecrit@ietf.org; Mon, 19 Sep 2005 14:33:46 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Mon, 19 Sep 2005 14:27:49 -0400 id 000C7FC5.432F0325.00005803 In-Reply-To: <432EFAFA.3020801@nortel.com> References: <432EFAFA.3020801@nortel.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] ECRIT requirements: R5 reprise Date: Mon, 19 Sep 2005 14:27:45 -0400 To: Tom-PT Taylor X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 19, 2005, at 1:52 PM, Tom-PT Taylor wrote: > We had a fair-sized discussion on R5 at the beginning of July. > Marc formulated an alternative statement that seemed to hold > promise. Andrew ignored it and quarelled with Henning instead. I > suggest we go with Marc's formulation with a slight tweak: I did not see Marc's message, and still do not see it in my local copy or the IETF archives (I'm not doubting it was sent, I'm just curious why I missed it). BTW, I was not the only one with objections to R5. Ted proposed an alternative as well. > "R5: The mapping protocol should allow for alternative redundant > sources of mapping information, possibly of different degrees of > currency. > > "Motivation: This provides the possibility of having available > alternative sources of mapping information when the normal source > is unavailable or unreachable, without specifying the means by > which the alternative source is created or updated." > > I think this proposition has concrete implications for protocol > design, hence should be stated. Well, I like this much better than the current version. Perhaps a slight tweak: R5: The mapping protocol should not inhibit the deployment of alternative redundant sources of mapping information, possibly of different degrees of currency." -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 19 14:45:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHQdj-0006si-7s; Mon, 19 Sep 2005 14:45:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHQdi-0006sd-EV for ecrit@megatron.ietf.org; Mon, 19 Sep 2005 14:45:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13780 for ; Mon, 19 Sep 2005 14:45:16 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHQjM-0000e4-SR for ecrit@ietf.org; Mon, 19 Sep 2005 14:51:10 -0400 Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j8JIiu509995 for ; Mon, 19 Sep 2005 20:44:56 +0200 (MEST) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zharhxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 19:44:30 +0100 Received: from [127.0.0.1] ([47.130.17.55] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 14:44:29 -0400 Message-ID: <432F0700.1040106@nortel.com> Date: Mon, 19 Sep 2005 14:44:16 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2005 18:44:29.0212 (UTC) FILETIME=[2ABBFDC0:01C5BD4A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Subject: [Ecrit] Comments on draft-ietf-ecrit-requirements-00.txt: definitions section X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is the first of a series of comments organized by section. It covers section 2, Terminology. 1. Term "address" This has already been discussed. I think the agreements include deletion of the definition of the term "address". I certainly support that, since the definition really reads like that of "civic location". 2. Definition of "emergency address" First, if the word "address" must appear, I'd suggest this be designated "Emergency signalling address". Secondly, the definition is far too protocol-specific. I'd suggest it be reworded: "A URI usable within a signalling protocol to route an emergency call to a PSAP." 3. Missing: term "emergency call" This raises another point: we need a definition of "emergency call". I propose the following: "emergency call: within this document, a generalized term describing a communication session between an emergency caller and a PSAP. The term makes no assumptions on the media supported by the call or the signalling protocol used to initiate and maintain it." 4. Minor tweak: "enhanced emergency service" Instead of "identify" on the second line, could we use "provide"? Also, does that have to be "and/or" or could it simply be "and"? Tweaked definition would then read: "Enhanced emergency services add the ability to provide the caller identity and caller location to basic emergency services. (Sometimes, only the caller location may be known ... )" 5. Definition of "location" I would suggest that only the first senetence is necessary. The remainder, starting with "In the geocoding process, ...", should be moved up and tacked on to the definition of "geographic location". 6. Definition of "location validation" Typos: "systems" should be "system", line 3 "reference able" should be "referencable" in line 5. Substantive: replace "caller's location" at the end of the second sentence with "a location provided by or for a caller within an emergency call". 7. Term "minimum connectivity" I would expect this term to be deleted based on discussion of R5. Tom Taylor _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 19 14:46:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHQf3-000798-0R; Mon, 19 Sep 2005 14:46:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHQf1-000793-MP for ecrit@megatron.ietf.org; Mon, 19 Sep 2005 14:46:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13825 for ; Mon, 19 Sep 2005 14:46:37 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHQkd-0000fw-2c for ecrit@ietf.org; Mon, 19 Sep 2005 14:52:28 -0400 Received: from zctfhxm1.corp.nortel.com (zctfhxm1.corp.nortel.com [47.164.129.157]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j8JIkN510288; Mon, 19 Sep 2005 20:46:23 +0200 (MEST) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zctfhxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 20:46:23 +0200 Received: from [127.0.0.1] ([47.130.17.55] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 14:46:21 -0400 Message-ID: <432F0770.8040805@nortel.com> Date: Mon, 19 Sep 2005 14:46:08 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] ECRIT requirements: R5 reprise References: <432EFAFA.3020801@nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2005 18:46:21.0227 (UTC) FILETIME=[6D801FB0:01C5BD4A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'll buy your tweak, and I do apologize: it was Ted, not Marc. Andrew Newton wrote: > > On Sep 19, 2005, at 1:52 PM, Tom-PT Taylor wrote: > >> We had a fair-sized discussion on R5 at the beginning of July. Marc >> formulated an alternative statement that seemed to hold promise. >> Andrew ignored it and quarelled with Henning instead. I suggest we >> go with Marc's formulation with a slight tweak: > > > I did not see Marc's message, and still do not see it in my local copy > or the IETF archives (I'm not doubting it was sent, I'm just curious > why I missed it). > > BTW, I was not the only one with objections to R5. Ted proposed an > alternative as well. > >> "R5: The mapping protocol should allow for alternative redundant >> sources of mapping information, possibly of different degrees of >> currency. >> >> "Motivation: This provides the possibility of having available >> alternative sources of mapping information when the normal source is >> unavailable or unreachable, without specifying the means by which the >> alternative source is created or updated." >> >> I think this proposition has concrete implications for protocol >> design, hence should be stated. > > > Well, I like this much better than the current version. Perhaps a > slight tweak: > > R5: The mapping protocol should not inhibit the deployment of > alternative redundant sources of mapping information, possibly of > different degrees of currency." > > -andy > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 19 15:56:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHRkb-0002H9-Pq; Mon, 19 Sep 2005 15:56:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHRka-0002Cy-Jm for ecrit@megatron.ietf.org; Mon, 19 Sep 2005 15:56:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21879 for ; Mon, 19 Sep 2005 15:56:24 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHRqD-0003fh-RZ for ecrit@ietf.org; Mon, 19 Sep 2005 16:02:19 -0400 Received: from zctfhxm0.corp.nortel.com (zctfhxm0.corp.nortel.com [47.164.129.155]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j8JJu4522823 for ; Mon, 19 Sep 2005 21:56:04 +0200 (MEST) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zctfhxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 21:56:04 +0200 Received: from [127.0.0.1] ([47.130.17.55] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 15:56:02 -0400 Message-ID: <432F17C9.7010006@nortel.com> Date: Mon, 19 Sep 2005 15:55:53 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2005 19:56:02.0716 (UTC) FILETIME=[29DCB5C0:01C5BD54] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [Ecrit] Tweaks to ecrit-requirements-00 section 3 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I propose some editorial tweaks to section 3, Basic Actors, in the requirements document. 1. Para 1: typo Delete either "in" or "during the" on the fifth line. 2. First bullet, on page 8: Last sentence, delete the phrase "used as part of call routing", since that happens no matter where the location information comes from. The sentence will then read: "Alternatively, location information is inserted by intermediaries." 3. Paragraph after second bullet (hence third paragraph on page 8): The last sentence is inconsistent with R1. I'd suggest rewriting it to read: "Additionally, as requirement R1 points out, there may be no Application (Voice) Service Provider in some cases." _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 19 15:57:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHRle-0002mS-BR; Mon, 19 Sep 2005 15:57:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHRlc-0002lr-K0 for ecrit@megatron.ietf.org; Mon, 19 Sep 2005 15:57:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22222 for ; Mon, 19 Sep 2005 15:57:27 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHRrD-0003m5-IQ for ecrit@ietf.org; Mon, 19 Sep 2005 16:03:22 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Mon, 19 Sep 2005 15:57:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] ECRIT requirements: R5 reprise Date: Mon, 19 Sep 2005 12:56:55 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657503232A45@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] ECRIT requirements: R5 reprise Thread-Index: AcW9SoHRbTNX0xvDQ7OylzI/OUaxtgABYTlQ From: "Roger Marshall" To: "Tom-PT Taylor" , "Andrew Newton" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yes, I've included/embedded the thread of Henning's comments to Ted's last R5 contribution down in the body. Based on this, I've reformed the requirement, taking Henning's comment on "call flow" into account, and breaking the paragraph into two parts, a requirement and a motivation, since that seemed to make sense to do so. Proposal: Change R5 Requirement=20 From: R5. Minimum Connectivity: An emergency call SHOULD succeed as long as there is a working network path between the caller and the PSAP. In particular, reliance during call set-up and calls on entities and network paths that are located elsewhere should be minimized. Example: A caller in New York who needs to contact a PSAP in the same city shouldn't have to get information from some entity in Texas to make that call, as the call would then fail if the New York to Texas path is unavailable. (To avoid this, the caller could, for example, have cached mapping information, use a local server that has the necessary information, or use other mechanisms to avoid such off-path dependencies.) To:=20 R5. Minimum Connectivity The ability to discover the correct PSAP, SHOULD NOT require a=20 level of connectivity substantially beyond that which would be=20 needed to contact that PSAP. =20 Motivation: It is not required that the servers used for=20 discovery be on-path to the media and signaling path, but=20 their reachability should be a strong consideration in=20 devising deployment strategies. Does this capture what we want to say about this topic? -Roger. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Henning Schulzrinne >Sent: Thursday, June 30, 2005 6:56 PM >To: Ted Hardie >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] R5 > >Ted Hardie wrote: >> Henning's proposal is: >>=20 >>=20 >>>R5. Minimum Connectivity >>> >>>An emergency call should succeed as long as there is a=20 >working network path between the caller and the PSAP. In=20 >particular, reliance during call set-up and calls on entities=20 >and network paths that are located elsewhere should be minimized. >>> >>>Example: A caller in New York who needs to contact a PSAP in=20 >the same=20 >>>city shouldn't have to get information from some entity in Texas to=20 >>>make that call, as the call would then fail if the New York to Texas=20 >>>path is unavailable. (To avoid this, the caller could, for example,=20 >>>have cached mapping information, use a local server that has the=20 >>>necessary information, or use other mechanisms to avoid such=20 >off-path=20 >>>dependencies.) >>> >>>I hope this is clearer. >>=20 >>=20 >> I think "working network path between the caller and the PSAP" isn't=20 >> clear enough. Do you mean only that there is IP=20 >connectivity between=20 >> the terminal and the PSAP's IP address? Taking SIP as the presumed=20 >> contact method for > > >> a moment, would that imply that the terminal should be able=20 >to connect=20 >> to the PSAP, even if its normal proxy is unavailable and the=20 >proxy for=20 >> the PSAP is also unavailable? Or does the "working network path"=20 >> imply that the proxies configured for these are also up and=20 >available? > >Yes, "working network path" =3D "current IP connectivity" +=20 >"ability to route SIP calls via outbound proxy [if necessary]=20 >and PSAP proxy". The basic rule is simple: > >"The look-up process should not add any additional=20 >network-related failure modes. In other words, if a caller=20 >knew the PSAP signaling address and can reach it via signaling=20 >and media, the usage of a mapping mechanism should not=20 >interfere with that reachability if network connectivity to=20 >parts of the mapping service is temporarily impaired." > > >>=20 >> I'd also strongly suggest that "located elsewhere" mixes up network=20 >> topology with geography, which is one of our constant sources of=20 >> confusion. Can you recast this in terms of network topology? > >Agreed. Located elsewhere =3D=3D> maybe "located in parts of the=20 >network that are neither on the signaling nor media path from=20 >the caller to the PSAP". It's a bit longer... > >>=20 >> Something like: >>=20 >> R.5. >>=20 >> The ability to discover the correct PSAP should not require=20 >a level of=20 >> connectivity substantially beyond that which would be needed to=20 >> contact that PSAP. It is not required that the servers used for=20 >> discovery be on-path to the call flow, but their reachability should=20 >> be a strong consideration in devising deployment strategies. > >This is ok, although "call flow" is a bit mushy (and means=20 >something rather different in the SIP community, if you look=20 >at documents titled "call flows"). One could simply say "media=20 >and signaling path" instead.=20 >I believe these terms are widely understood, at least on the=20 >VoIP side of the world. > > > >>=20 >>=20 >> regards, >> Ted -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tom-PT Taylor Sent: Monday, September 19, 2005 11:46 AM To: Andrew Newton Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT requirements: R5 reprise I'll buy your tweak, and I do apologize: it was Ted, not Marc. Andrew Newton wrote: >=20 > On Sep 19, 2005, at 1:52 PM, Tom-PT Taylor wrote: >=20 >> We had a fair-sized discussion on R5 at the beginning of July. Marc >> formulated an alternative statement that seemed to hold promise. =20 >> Andrew ignored it and quarelled with Henning instead. I suggest we=20 >> go with Marc's formulation with a slight tweak: >=20 >=20 > I did not see Marc's message, and still do not see it in my local =20 > copy or the IETF archives (I'm not doubting it was sent, I'm just =20 > curious why I missed it). >=20 > BTW, I was not the only one with objections to R5. Ted proposed an=20 > alternative as well. >=20 >> "R5: The mapping protocol should allow for alternative redundant=20 >> sources of mapping information, possibly of different degrees of=20 >> currency. >> >> "Motivation: This provides the possibility of having available=20 >> alternative sources of mapping information when the normal source is >> unavailable or unreachable, without specifying the means by which=20 >> the alternative source is created or updated." >> >> I think this proposition has concrete implications for protocol=20 >> design, hence should be stated. >=20 >=20 > Well, I like this much better than the current version. Perhaps a=20 > slight tweak: >=20 > R5: The mapping protocol should not inhibit the deployment of=20 > alternative redundant sources of mapping information, possibly of=20 > different degrees of currency." >=20 > -andy >=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 Mon Sep 19 16:08:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHRw3-00076o-9M; Mon, 19 Sep 2005 16:08:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHRw1-00075v-AI for ecrit@megatron.ietf.org; Mon, 19 Sep 2005 16:08:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24396 for ; Mon, 19 Sep 2005 16:08:14 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHS1g-0004fR-Ox for ecrit@ietf.org; Mon, 19 Sep 2005 16:14:10 -0400 Received: from zctfhxm0.corp.nortel.com (zctfhxm0.corp.nortel.com [47.164.129.155]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j8JK7r527651; Mon, 19 Sep 2005 22:07:53 +0200 (MEST) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zctfhxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 22:07:52 +0200 Received: from [127.0.0.1] ([47.130.17.55] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 16:07:50 -0400 Message-ID: <432F1A92.1030104@nortel.com> Date: Mon, 19 Sep 2005 16:07:46 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] ECRIT requirements: R5 reprise References: <8C837214C95C864C9F34F3635C2A657503232A45@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A657503232A45@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2005 20:07:50.0680 (UTC) FILETIME=[CFD77180:01C5BD55] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 This sounds totally like a deployment requirement, I'm afraid. I can't see the protocol implications. Roger Marshall wrote: > Yes, I've included/embedded the thread of Henning's comments to Ted's > last R5 contribution down in the body. Based on this, I've reformed the > requirement, taking Henning's comment on "call flow" into account, and > breaking the paragraph into two parts, a requirement and a motivation, > since that seemed to make sense to do so. > > Proposal: Change R5 Requirement > > From: > > R5. Minimum Connectivity: An emergency call SHOULD succeed as long > as there is a working network path between the caller and the > PSAP. In particular, reliance during call set-up and calls on > entities and network paths that are located elsewhere should be > minimized. > > Example: A caller in New York who needs to contact a PSAP in the > same city shouldn't have to get information from some entity in > Texas to make that call, as the call would then fail if the New > York to Texas path is unavailable. (To avoid this, the caller > could, for example, have cached mapping information, use a local > server that has the necessary information, or use other mechanisms > to avoid such off-path dependencies.) > > To: > > R5. Minimum Connectivity > > The ability to discover the correct PSAP, SHOULD NOT require a > level of connectivity substantially beyond that which would be > needed to contact that PSAP. > > Motivation: It is not required that the servers used for > discovery be on-path to the media and signaling path, but > their reachability should be a strong consideration in > devising deployment strategies. > > > Does this capture what we want to say about this topic? > > -Roger. > ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 19 17:02:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHSmU-0008Rr-7O; Mon, 19 Sep 2005 17:02:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHSmN-0008QB-Ef for ecrit@megatron.ietf.org; Mon, 19 Sep 2005 17:02:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29214 for ; Mon, 19 Sep 2005 17:02:20 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHSs4-0006EI-8f for ecrit@ietf.org; Mon, 19 Sep 2005 17:08:16 -0400 Received: from zctfhxm0.corp.nortel.com (zctfhxm0.corp.nortel.com [47.164.129.155]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j8JL22507858 for ; Mon, 19 Sep 2005 23:02:02 +0200 (MEST) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zctfhxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 23:01:58 +0200 Received: from [127.0.0.1] ([47.130.17.55] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 17:01:56 -0400 Message-ID: <432F2743.1020906@nortel.com> Date: Mon, 19 Sep 2005 17:01:55 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2005 21:01:56.0440 (UTC) FILETIME=[5E771D80:01C5BD5D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Subject: [Ecrit] Comments on ecrit-requirements-00 section 4: R2, R4, R6, D1 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 1. R2: editorial In the second last line of motivation, suggest deleting "United States". Other places have counties too. 2. R4: almost editorial. The second sentence of motivation slightly contradicts the first as things read now, making for jarring reading. I suggest adding the following at the beginning of the second sentence: "However, looking to the future, ...". 3. R6: substantive. The requirement reads OK subject to what I say below, but the motivation is much too SIP-oriented. The real motivation is to minimize the requirement for specialized support of emergency services routing in devices used for Emergency Services Routing Support beyond the point of mapping. The substantive issue is that for any given call a specific signalling protocol will be used. The requirement should therefore be tweaked not to say that the returned URI(s) should be usable in some signalling protocol, but that they should be usable specifically in the signalling protocol in use at that point in the call path. The exact text might read: "The ECRIT mapping protocol MUST return URIs that are usable by the standard form of the signalling protocol in use at that point in the call path (i.e. without special emergency extensions) unless an error is returned." 4. D1: sort of editorial Requirement D1 as phrased is a bit imprecise. The motivation is a clearer statement. To bring the two in line, I suggest D1 be rephrased as follows: "PSAP identification: The mapping information must be available without requiring the caller to have enrolled with a specific service provider." BTW "VSP" appears in the last line of the motivation, should be "ASP". _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 20 14:57:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHnIo-0002mn-3b; Tue, 20 Sep 2005 14:57:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHnIm-0002mR-7h for ecrit@megatron.ietf.org; Tue, 20 Sep 2005 14:57:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22548 for ; Tue, 20 Sep 2005 14:57:10 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHnOc-0006ap-Cu for ecrit@ietf.org; Tue, 20 Sep 2005 15:03:17 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 20 Sep 2005 11:57:00 -0700 X-IronPort-AV: i="3.97,127,1125903600"; d="scan'208"; a="343605023:sNHT35670646" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8KIuPKa014402; Tue, 20 Sep 2005 11:56:55 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 11:56:56 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.203]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 11:56:58 -0700 Message-Id: <4.3.2.7.2.20050920134254.037b7510@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Sep 2005 13:56:54 -0500 To: "Stastny Richard" , From: "James M. Polk" Subject: Re: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4523@oefeg-s04.oefeg.loc > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Sep 2005 18:56:58.0527 (UTC) FILETIME=[13C622F0:01C5BE15] X-Spam-Score: 0.0 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 10:12 AM 9/17/2005 +0200, Stastny Richard wrote: > >Are tel:uris routable? > >Not on IP, but on the PSTN > > >If not, they need to be converted to SIP URIs, which are routable, and that > >URI could be to a ESRP, ESGW or PSAP... > >The problem here is that the ESGW is not precicely defined >I think you are talking about a corporate or campus environment >using a UNI. I am talking about a Point-of-Interconnect (PoI) using >a NNI. NNIs can never be accessed by the end-user directly. I am talking about both, but your PoI will not necessarily be universally accessable by the UA directly. This doesn't invalidate the "purpose", as it does have a use in campuses/enterprises/small businesses. I think this will be possible in some situations within an IP provider if that provider is directly connecting the UA to the GW within its own network. >That was the reason that although we have an ESGW in the architecture; >we considered it as a part of or behind an ESRP. The above is where some confusion has been caused, because a GW is a GW to some folks, regardless of whether it is directly accessable or not. If it is hidden behind the ESRP *always*, I didn't read that text in the i2 spec. Obviously this cannot be the case, because enterprise GWs have direct access to SRs today, so this diagram would fit medium to large enterprises too. >The access from >ESRP to ESGW is already a national matter. a national matter some of the time, not always. diagrams have a tendency of being the norm, and should avoid such when it is known not to apply. >This may be 1:1 or 1:n > >The routing between ESRP and ESGW is of course done via SIP, >eventally with an embedded Tel URI. The ESGW itself understands >only Tel URIs. no it doesn't. The IP side needs to have access to a tel:uri in order to properly convey that on the TDM side, but it is not void in URI understanding in the SIP message. >Which ESGW to use depends eventually on the >information contained in the Tel-URI and also on fail-over, etc. again, this is not true. I can have a fully formed INVITE from the ESRP using URIs. So long as that INVITE *also* has the tel:uri (the ANI) in it somewhere the ESGW can find it, everything is fine. That ANI field could be in the From header, or Contact header or it could be in a message body - it doesn't matter, as long as it is there for the ESGW to find. >Having said that, if the ESGW is used in your case for UNI-GWs, >I have no problem with it, we would just not use it. who's "we" here? >BTW, I have another serious proble with your proposal I have not >brought forward yet: > >You assume only ONE PSAP, but there are countries out there >with more then one emergency numbers. I don't assume ONE PSAP. I have 2 PSAP URIs now. I was waiting for someone to say they needed another one for Fire, another one for Police, another one for Marine, another one for Mountain, another one for At Sea, etc.... I wasn't going to add these until asked to. Are you asking me to? >We have 9 (no comments >on this, please ;-) > >This implies, that we would need 2x3x9 = 54 URI purposes >for ES alone ;-) What's the 2 and the 3 in the above equation represent? >cheers >Richard > > > > > >________________________________ > >Von: James M. Polk [mailto:jmpolk@cisco.com] >Gesendet: Sa 17.09.2005 03:10 >An: Stastny Richard; Thomson, Martin; ecrit@ietf.org >Betreff: RE: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals > > > >At 01:13 AM 9/17/2005 +0200, Stastny Richard wrote: > >Hi James > > > >Sorry for the "date" problem, I meant data, but the explanation > >was not very well formulated anyway. It was a bit late > >fair > >it's past Miller Time here too... > > > >Ok, it is late now again, but lets try > > > >I will start with your last remark: > > > > >remember, this is **NOT** an ECRIT Architecture ID, it is a DHC ID that > > >doesn't need to get into all the architecture stuff of emergency > > >communications. Another ECRIT (or two) ID could/should explain how these > > >purposes are used, including message flows. > > > >Ok, but we are discussing this on the ecrit list. > >yes, and we need to take the context of each topic and determine where it >needs to be discussed. In other words, just because no official >architecture doc exists doesn't mean we don't talk about architectures. >Conversly, just because a single mechanism document is offered doesn't mean >it has to cover every bit of the overlaying architecture that can take >advantage of it. This gets to your point just below: > > > > >So in ecrit we must define how the data are distributed > >to the DHCP servers. One method could be that the > >DHCP servers are querying periodically the mapping > >database, because this is IMHO the ONLY authoritative > >source for the location to PSAP URI mapping > >The DHCP servers will interact with the wire map database server to get >location for endpoints based on a circuit ID (for RFC 3825). I expect the >DHCP servers will interact periodically with your authoritative source for >PSAP URI mapping to location jurisdications. > >The timing of the interaction should be configurable, and a local policy >decision. I guess I can add some text to address this to the ID. > > > >Any other means would end up in a complete mess > >I do not know another one that would work > > >(one > >cannot expect thousands of DHCP servers updated > >properly if a PSAP URI changes) > >I think this will happen, but it is a question of how long this will take >to fully populate to the servers, and then get to the clients > > > > >So the PSAP URI may be retrieved in that way, but > >I did not see in any of the proposals of the mapping > >database a datafield indicating a destinction between > >a PSAP URI or a ESRP URI, and I also did not > >see an ESGW URI > > > >So where are these DATA coming from? > >PSAP URIs are not in existence yet, and we need to create them. Just as is >true for the ESRP and ESGW URIs. A URI is a unique identifier, that's all >(conceptually). An ESRP just has to be uniquely identifable and accept >messages to that URI > >How those URIs get distributed is another exercise. > > > >The only data in the mapping database up > >to now is a SIP URI. > >Figuratively speaking, because not one database has been created yet. > >The ESRP might not come from the PSAP community anyway, but could come from >another source, like the LLP. If I want service from a particular LLP, they >ask what state/province I'm in, I tell them, they configure my location to >that URI, that propagates to their DHCP servers waiting for my device(s) at >my address to boot up to request the URIs. > > >We would propose > >to provide IN ADDITION to the PSAP > >URI (which may also be an ESRP URI -who cares) > >a TEL URI. > >Are tel:uris routable? > >If not, they need to be converted to SIP URIs, which are routable, and that >URI could be to a ESRP, ESGW or PSAP... > > >This TEL URI may either be used > >by the ESRP to access an ESGW or maybe > >by any network knowing or owning a gateway > >and also knowing the (national) context. > > > >cheers > > > >Richard > > > > > >________________________________ > > > >Von: James M. Polk [mailto:jmpolk@cisco.com] > >Gesendet: Sa 17.09.2005 00:44 > >An: Stastny Richard; Thomson, Martin; ecrit@ietf.org > >Betreff: RE: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals > > > > > > > >comments in line > > > >At 10:34 AM 9/15/2005 +0200, Stastny Richard wrote: > > >Sorry for jumping in into this discussion a bit late > > >but I had no time up to now to read the draft completely > > > > > >I also apologize if I re-query some issues already discussed > > > > > >In principle I consider it as a good idea to have a vehicle > > >to provide such information to a client. > > > > > >Having said this, I would like to discuss the purpose list > > >in detail. > > > > > >Purpose = 1 (Primary PSAP URI) > > > Purpose = 2 (Secondary PSAP URI) > > > Purpose = 3 (Location By-Reference of Client) > > > Purpose = 4 (ESGW URI of Client) > > > Purpose = 5 (ESRP URI of Client) > > > Purpose = 6 (Location Providing Location for Client) > > > Purpose = 7 (URI of Geocoding/Reverse Geocoding) > > > Purpose = 8 (Primary URI of Geo Mapping Service) > > > Purpose = 9 (Secondary URI of Geo Mapping Service) > > > Purpose = 10 (Primary URI of Civic Mapping Service) > > > Purpose = 11 (Secondary URI of Civic Mapping Service) > > > > > > > > >General remark 1 (this was already discussed): > > >There needs to be a requirement in ecrit req I-D defining > > >the TTL of such information and therefore the minimum lease time > > > >ok > > > > > > >Also the concern of Brian regarding short time changes has to by taken > > >into > > >account, which may render the transmissinon of the URI of the Mapping > > >service and the PSAP useless, because then they always need to be > > >queried at > > >emergency call setup. > > > >Why "at" call set-up? Why not "before" call set-up? > > > > > > >General remark 2: > > >Is it necessary to provide secondaries in general? Especially > > >for SIP URIs (PSAP) this can be done with other means (e.g. SRV RR) > > > >I thought I'd include them now and see what the WGs said about the reliance > >on one or two > > > > > > >Remark ESRP > > > > > >If you query the mapping service, you get back a SIP URI. You do > > >not care if this is a PSAP direct or a ESRP. > > > >The client might not, but it might be stored in a server differently. > >Further, the client could get 3 URIs, Pri and Sec PSAP URIs and the ESRP as > >another fallback. > > > > >As far as I know there > > >is no distinction within the proposed protocols. So why put > > >this distinction here. > > > >Because we don't know every possible instance of how URIs will be used, and > >there may be a difference somewhere. > > > > >If you have a distinction, you need first > > >to get the date. > > > >the date? I don't understand this. > > > > >Since the provider of this date may (Must?) derive > > >this data from the mapping service anyway, how can he make the > > >distinction? > > > >again - I don't understand this "date" > > > > > > >So IMHO this purpose is not needed. > > > > > >Remark ESGW: > > > > > >Now here I have a serious problem > > > > > >It is stated in the draft > > > "This purpose=4 URI is for the Emergency Services Gateway that an IP > > > client would contact when setting up an emergency call with a PSAP > > > that is not IP enabled. Having this information locally in the > > > client will allow it to contact the ESGW directly and not have to > > > rely on an intermediary to determine which ESGW is the right one for > > > this client, and possibly fail the call set-up during that > > > determination." > > > > > >We are planning to use ESGW, but these may accessed only via > > >the ESRPs. > > > >Is that true for every enterprise network? > > > > >The ESGW are basically PoIs to the PSTN. If you access > > >the ESGW with a SIP URI, you are basically accessing a SIP proxy > > >and then it is a ESRP. > > > >You may be telling a call server which GW to direct the call set-up > >towards. I believe this applies more to the smaller networks than the open > >Internet > > > > > > >We are planning to access the ESGW with tel URIs via the ESRP. > > > >I believe a tel:uri will be converted to a SIP uri that is then sent to the > >ESGW, but I could be wrong > > > > >It is the task of the ESRP to map the location (via the mapping service > > >or via a local DB to the NATIONAL routing numbers required to access > > >the national emergency service network. This mapping is very national > > >specific (it may not use E.164 numbers). > > > >yes - but an ESRP is not always necessary. > > > >If the UA has the IP destination URI (be it PSAP or ESGW), there doesn't > >need to be an ESRP to do the mapping that has already been done. > > > > > > >Since the client is not able in most case to access the ESGW directly > > >this purpose should not be there. > > > >"in most cases" means not all the time, so there are instances in which > >this can be used, maybe not many > > > > >What I am missing in the I-D is a way to provide the client eventually > > >with the local emergency identifiers > > > >remember, this is **NOT** an ECRIT Architecture ID, it is a DHC ID that > >doesn't need to get into all the architecture stuff of emergency > >communications. Another ECRIT (or two) ID could/should explain how these > >purposes are used, including message flows. > > > > > > >Cheers > > >Richard > > > > > >cheers, > >James > > > > ******************* > > Truth is not to be argued... it is to be presented. > > >cheers, >James > > ******************* > Truth is not to be argued... it is to be presented. 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 Tue Sep 20 15:07:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHnSN-00051c-P7; Tue, 20 Sep 2005 15:07:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHnSM-000514-OT for ecrit@megatron.ietf.org; Tue, 20 Sep 2005 15:07:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23348 for ; Tue, 20 Sep 2005 15:07:04 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHnYC-0006s9-DZ for ecrit@ietf.org; Tue, 20 Sep 2005 15:13:11 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 20 Sep 2005 12:06:54 -0700 X-IronPort-AV: i="3.97,127,1125903600"; d="scan'208"; a="213381808:sNHT31639976" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8KJ665Y020027; Tue, 20 Sep 2005 12:06:50 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 12:06:48 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.203]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 12:06:50 -0700 Message-Id: <4.3.2.7.2.20050920135903.037b4a60@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Sep 2005 14:06:46 -0500 To: Henning Schulzrinne , "'ECRIT'" From: "James M. Polk" Subject: Re: [Ecrit] draft-polk-dhc-uri-00 (big picture) In-Reply-To: <432C3D7C.4040306@cs.columbia.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Sep 2005 19:06:50.0750 (UTC) FILETIME=[74C431E0:01C5BE16] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 11:59 AM 9/17/2005 -0400, Henning Schulzrinne wrote: >I'm not sure a DNS-vs.-DHCP discussion is all that helpful. Since a lot of >messages have gone back and forth, it would help me at least to summarize >some of the points and see if we can at least agree on the facts. > ># The system we're building has a number of translations between the "dial >emergency number" and the final IP address of the phone of the PSAP call >taker, including at least: > >(1) Caller maps location and service desired to PSAP URL, possibly using >the mapping URL conveyed in DHCP DHCP can also - based on the ID - provide the ESRP URI - which is your #3 below >(3) The DNS resolution points to one or more SIP proxies, which in turn >route calls to the next step, either another SIP proxy closer to the call >taker or the call taker. Repeat step (2) and (3) until the phone rings. > ># If the PSAP URL(s) are included in the DHCP information, presumably the >DHCP server performs step (1) above, for each attached device based on its >location. The draft does not really say so, but I'm certainly hoping that >this is not manually configured. I didn't get into what was not a DHCP function in the ID, no. Just as 3825 and your civic ID don't articulate how the DHCP server learns a client's location. In those cases, the DHCP server knows to pass along a circuitID to some external server, wait for an answer, then reply to the client with its location. The same assumptions are made in this ID. The bar shouldn't be raised now for this ID. But perhaps I should make the same operational analogy as is present in 3825 and your civic ID. >Presumably, this would take place at the time the client asks for an >address or does a DHCPINFORM. yes, or I have it possible that the server sends this information unsolicited to the client, which can be ignored without causing error(s). >Let's see if I got the picture right. close >Henning > > > >_______________________________________________ >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 Tue Sep 20 16:45:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHozB-0007sQ-DZ; Tue, 20 Sep 2005 16:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHoz9-0007rn-H9 for ecrit@megatron.ietf.org; Tue, 20 Sep 2005 16:45:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04656 for ; Tue, 20 Sep 2005 16:45:01 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHp53-0002rT-2E for ecrit@ietf.org; Tue, 20 Sep 2005 16:51:09 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 20 Sep 2005 13:44:54 -0700 X-IronPort-AV: i="3.97,127,1125903600"; d="scan'208"; a="343647403:sNHT30424028" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8KKiP5M019610 for ; Tue, 20 Sep 2005 13:44:50 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 13:44:49 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.203]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 13:44:49 -0700 Message-Id: <4.3.2.7.2.20050920140925.037bef08@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Sep 2005 15:44:47 -0500 To: John Schnizlein From: "James M. Polk" Subject: Re: [Ecrit] draft-polk-dhc-uri-00 In-Reply-To: <69f6934020acb1b9f216336a4fc22c70@cisco.com> References: <200509141531.LAA17265@ietf.org> <42CC6B9B-0362-49CD-BDEE-99A6F82D8332@hxr.us> <288238a691e5974f4453d647477abe3b@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Sep 2005 20:44:49.0330 (UTC) FILETIME=[24AC5120:01C5BE24] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org >>> The problem with using DHCP is not the duration of an address lease, >>> but that there is no mechanism identified for getting new URIs into the >>> DHCP servers. >> >>Do DHCP servers have such quirky IP connectivity that they cannot use the >>same LCMS as a phone or gateway? > >Nobody (but you) said that DHCP servers have "quirky IP connectivity". > The DHCP server is what performs the protocol function. As a practical > matter, since the purpose of DHCP is entirely for configuration within an > administration, there is no reason for the host on which the protocol > server operates to be reachable from outside the perimeter of that > organization. Unlike DNS, DHCP is not designed to provide time-limited, > cached-for-efficiency, global access to information. Why are you saying global here? Just as the DHCP server communicates with a wiremap server in 3825, it can communuicate with a pre-call mapping server. What is different is where this mapping server is, and it might/likely is external to the DHCP organization. >Nothing about this protocol function relates to getting information from >outside the local administrative area. If a protocol were proposed to add /add/interwork >this capability to DHCP, it would deserve careful review. > >>I also wonder, if DHCP lease times are so untrustworthy, then perhaps LCI >>should not be delivered via DHCP either. > >I have not seen any claim that DHCP lease times are untrustworthy. >Where was this claimed? > >The point that has been made is that DHCP is useful for configuring hosts >with local information (such as its location) within a local >administration, but that it seems a poor choice for obtaining information >that can be changed in a remote location under a different >administration. The principle is to use protocols for the sorts of things >for which they were designed. > >John > >_______________________________________________ >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 Tue Sep 20 16:46:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHp0L-000818-RA; Tue, 20 Sep 2005 16:46:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHp0J-00080j-En for ecrit@megatron.ietf.org; Tue, 20 Sep 2005 16:46:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04691 for ; Tue, 20 Sep 2005 16:46:12 -0400 (EDT) Message-Id: <200509202046.QAA04691@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHp6C-0002sZ-1k for ecrit@ietf.org; Tue, 20 Sep 2005 16:52:21 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EHp04-0002xd-A7; Tue, 20 Sep 2005 15:46:00 -0500 From: "Brian Rosen" To: "'James M. Polk'" , "'Henning Schulzrinne'" , "'ECRIT'" Subject: RE: [Ecrit] draft-polk-dhc-uri-00 (big picture) Date: Tue, 20 Sep 2005 16:45:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4.3.2.7.2.20050920135903.037b4a60@email.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW+FpSB7ZPoO50uQAe6gl0dJE14zwADUMUQ 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: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org One of the issues with using DHCP to do the mapping function is that it's not universally implemented. That means you cannot use it for everything. That means we need more than one protocol to get the PSAP URI. Given the experience we are having with getting location, where we have two protocols, some folks are demanding a third, and every phone has to implement every protocol, that I am opposed to a mechanism that cannot be reasonably be deployed in every environment. By that criteria, DHCP would not pass muster, DNS would. IRIS and LUMP would also. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James M. Polk Sent: Tuesday, September 20, 2005 3:07 PM To: Henning Schulzrinne; 'ECRIT' Subject: Re: [Ecrit] draft-polk-dhc-uri-00 (big picture) At 11:59 AM 9/17/2005 -0400, Henning Schulzrinne wrote: >I'm not sure a DNS-vs.-DHCP discussion is all that helpful. Since a lot of >messages have gone back and forth, it would help me at least to summarize >some of the points and see if we can at least agree on the facts. > ># The system we're building has a number of translations between the "dial >emergency number" and the final IP address of the phone of the PSAP call >taker, including at least: > >(1) Caller maps location and service desired to PSAP URL, possibly using >the mapping URL conveyed in DHCP DHCP can also - based on the ID - provide the ESRP URI - which is your #3 below >(3) The DNS resolution points to one or more SIP proxies, which in turn >route calls to the next step, either another SIP proxy closer to the call >taker or the call taker. Repeat step (2) and (3) until the phone rings. > ># If the PSAP URL(s) are included in the DHCP information, presumably the >DHCP server performs step (1) above, for each attached device based on its >location. The draft does not really say so, but I'm certainly hoping that >this is not manually configured. I didn't get into what was not a DHCP function in the ID, no. Just as 3825 and your civic ID don't articulate how the DHCP server learns a client's location. In those cases, the DHCP server knows to pass along a circuitID to some external server, wait for an answer, then reply to the client with its location. The same assumptions are made in this ID. The bar shouldn't be raised now for this ID. But perhaps I should make the same operational analogy as is present in 3825 and your civic ID. >Presumably, this would take place at the time the client asks for an >address or does a DHCPINFORM. yes, or I have it possible that the server sends this information unsolicited to the client, which can be ignored without causing error(s). >Let's see if I got the picture right. close >Henning > > > >_______________________________________________ >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 Tue Sep 20 16:57:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHpB6-0003zE-1z; Tue, 20 Sep 2005 16:57:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHpB2-0003y7-4K for ecrit@megatron.ietf.org; Tue, 20 Sep 2005 16:57:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05272 for ; Tue, 20 Sep 2005 16:57:17 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHpGu-0003A1-Ag for ecrit@ietf.org; Tue, 20 Sep 2005 17:03:25 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 20 Sep 2005 13:57:09 -0700 X-IronPort-AV: i="3.97,127,1125903600"; d="scan'208"; a="660883260:sNHT33512380" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8KKue5K029253 for ; Tue, 20 Sep 2005 13:57:05 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 13:57:03 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.203]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 13:57:03 -0700 Message-Id: <4.3.2.7.2.20050920154625.0362ad90@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Sep 2005 15:56:26 -0500 To: ecrit@ietf.org From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Sep 2005 20:57:03.0361 (UTC) FILETIME=[DA308F10:01C5BE25] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ecrit] Timing of PSAPs changing coverage areas X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org All I've heard and read the statements and requirements from folks that the routing of a call to a PSAP needs to be as fresh as possible because a particular PSAP might have moved, or more accurately, that a location might be served "on a moment's notice" by a different PSAP. I'd like to ask how often this happens today. Does anyone know how often a location needs to contact a different PSAP than its normal/standard one? It seems to me that a lot of us might be imagining a worse-case scenario that we need to design protocols for, and that this worse-case scenario happens often. If this is, say only 0.01% of the time - or even under 5% of all emergency calls (2 standard deviations, or SDs), I'm thinking we're focusing too much energy on solving something that is a statistical "outlier". Today's emergency systems aren't build for 2 SDs, and especially not for 4 SDs. 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 Tue Sep 20 17:12:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHpPv-0007bt-0u; Tue, 20 Sep 2005 17:12:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHpPo-0007bk-TE for ecrit@megatron.ietf.org; Tue, 20 Sep 2005 17:12:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06045 for ; Tue, 20 Sep 2005 17:12:34 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHpVh-0003XP-Kl for ecrit@ietf.org; Tue, 20 Sep 2005 17:18:43 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 20 Sep 2005 14:12:25 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8KLBh4x028002; Tue, 20 Sep 2005 14:12:17 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 14:12:15 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.203]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 14:12:14 -0700 Message-Id: <4.3.2.7.2.20050920160345.035d7220@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Sep 2005 16:12:10 -0500 To: br@brianrosen.net From: "James M. Polk" Subject: RE: [Ecrit] draft-polk-dhc-uri-00 In-Reply-To: <200509191355.JAA21859@ietf.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Sep 2005 21:12:14.0814 (UTC) FILETIME=[F9753FE0:01C5BE27] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian You have talked about mapping being old or stale or there is an outage or overload for a while. Give me an example URI of your PSAP. If your phone uses that URI (however your phone got it) to contact your PSAP, where will that INVITE go? SIP will route it to your PSAP, right? If that URI is old, is that PSAP not still yours? If that URI is stale, is that PSAP not still yours? If that URI is to a PSAP that is out of service, will not the proper SIP routing of the INVITE send it to an alternate PSAP? If that URI is to an overloaded PSAP, is that not a general SIP problem, and probably a subject to having SIP routing take care of it and send the INVITE to that alternate PSAP? We haven't addressed the reception of an INVITE by the wrong PSAP yet, and I feel we need to do this as well. What happens if this occurs and your INVITE goes to Philly? Shouldn't they have a Proxy (however stateful) that inspects your INVITE to ansure the location in the message is for the Philly PSAP jurisdiction? And if it is not, to either reroute the INVITE to your PSAP, or to answer the call and ask where you are and then to a call transfer of some form? At 09:54 AM 9/19/2005 -0400, Brian Rosen wrote: >I think that we should anticipate things going wrong in ways we don't >predict. > >For me, that means that we should NOT rely entirely on old (as in days) >mapping data. We should, instead, attempt mapping at the time of the call, >and use that. It just seems much more prudent to allow the mapping data to >change in time frames measured in hours if not minutes. > >It may be that it fails, for lots of reasons, and thus we should have a >cached version of the mapping available. > >You can imagine circumstances where you have both a mapping change, and >there is overload (or loss of connectivity) to the mapping service. While I >would like to engineer systems to reduce the probability, it can happen. >Those callers would be hosed. The cached data would be wrong. > >No system is going to be perfect, or foolproof. All we can do is boost the >odds. I think presuming mapping data can change, and thus attempt mapping >at the time of the call, is one of the steps we can and should make to >improve the odds. > > >Brian > > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >Andrew Newton >Sent: Friday, September 16, 2005 3:59 PM >To: Marc Linsner >Cc: 'ECRIT' >Subject: Re: [Ecrit] draft-polk-dhc-uri-00 > > >On Sep 16, 2005, at 3:23 PM, Marc Linsner wrote: > > > My experience (admittedly not much) has been DHCP lease times in > > numbers of > > days/weeks whereas DNS TTL in numbers of hours. > >Hours? COM/NET is 2 days. I normally use one week for my SLDs. > > > The main point is PSAPs > > will know/control the TTL in the DNS solution, neither of which can > > ever > > happen with dhcp servers that distribute the PSAP uri. You are > > absolutely > > correct, once the TTL is set and read, it can't be retracted until the > > caching entity's timer expires, but the point, it's a known (by the > > PSAP) > > parameter. The requirement/use case is the ability to change the > > routing of > > emergency calls adhoc, based on unknown/untimed events. I believe > > we should > > deliver this capability to the PSAP community, even if it has the > > baggage of > > the known/controllable timing parameters. > > From Brian's email: > > I'm not sure what your experience is. Mine is that disasters don't go > > according to plan. You plan for disasters, and then you deal with > > what > > actually happens. Often, what you thought would work, doesn't. > >So the objection was about things that do not go according to plan. >You are arguing that one method is better than the other. I am >arguing that when you look at the objection, there is no difference. > >-andy > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 20 17:23:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHpZt-0001CH-TP; Tue, 20 Sep 2005 17:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHpZq-00017M-51 for ecrit@megatron.ietf.org; Tue, 20 Sep 2005 17:23:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06567 for ; Tue, 20 Sep 2005 17:22:55 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHpfg-0003nB-RB for ecrit@ietf.org; Tue, 20 Sep 2005 17:29:04 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 20 Sep 2005 17:22:46 -0400 X-IronPort-AV: i="3.97,128,1125892800"; d="scan'208"; a="71064094:sNHT29704116" Received: from [68.50.138.194] (che-vpn-cluster-1-96.cisco.com [10.86.240.96]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8KLMhQl015684; Tue, 20 Sep 2005 17:22:43 -0400 (EDT) In-Reply-To: <4.3.2.7.2.20050920140925.037bef08@email.cisco.com> References: <200509141531.LAA17265@ietf.org> <42CC6B9B-0362-49CD-BDEE-99A6F82D8332@hxr.us> <288238a691e5974f4453d647477abe3b@cisco.com> <4.3.2.7.2.20050920140925.037bef08@email.cisco.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit] draft-polk-dhc-uri-00 Date: Tue, 20 Sep 2005 17:22:39 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Answers embedded in context: On Sep 20, 2005, at 4:44 PM, James M. Polk wrote: > >>>> The problem with using DHCP is not the duration of an address >>>> lease, but that there is no mechanism identified for getting new >>>> URIs into the DHCP servers. >>> >>> ... >> As a practical matter, since the purpose of DHCP is entirely for >> configuration within an administration, there is no reason for the >> host on which the protocol server operates to be reachable from >> outside the perimeter of that organization. Unlike DNS, DHCP is not >> designed to provide time-limited, cached-for-efficiency, global >> access to information. > > Why are you saying global here? Because DNS was designed for and operates as a global lookup service for information maintained by individual authorities. > Just as the DHCP server communicates with a wiremap server in 3825, it > can communuicate with a pre-call mapping server. What is different is > where this mapping server is, and it might/likely is external to the > DHCP organization. There is a big difference between a local translation from wiremap and circuit-ID to location and the proposed service that maintains local and sufficiently current PSAP mappings that are administered elsewhere. Since DHCP operation is clearly intended to be internal, it is stretching credulity to expect the DHCP operator to rely on external services in the process of allocating a local address. > >> Nothing about this protocol function relates to getting information >> from outside the local administrative area. If a protocol were >> proposed to add > > /add/interwork Whatever word you use, there is a huge semantic clash between local (DHCP) function and obtaining and maintaining the proposed remote information. >> ... >> The point that has been made is that DHCP is useful for configuring >> hosts with local information (such as its location) within a local >> administration, but that it seems a poor choice for obtaining >> information that can be changed in a remote location under a >> different administration. The principle is to use protocols for the >> sorts of things for which they were designed. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 20 17:23:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHpaV-0001SN-8H; Tue, 20 Sep 2005 17:23:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHpaT-0001Ra-8h for ecrit@megatron.ietf.org; Tue, 20 Sep 2005 17:23:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06776 for ; Tue, 20 Sep 2005 17:23:34 -0400 (EDT) Received: from mta2.prod1.dngr.net ([216.220.209.221] helo=mfe2.prod.danger.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHpgL-0003ry-6N for ecrit@ietf.org; Tue, 20 Sep 2005 17:29:43 -0400 Received: from [10.253.3.252] (HELO localhost.localdomain) by mfe2.prod.danger.com (CommuniGate Pro SMTP 4.1.6) with ESMTP id 393285151; Tue, 20 Sep 2005 14:23:17 -0700 Date: Tue, 20 Sep 2005 17:23:12 -0400 Subject: Re: [Ecrit] Timing of PSAPs changing coverage areas X-Mailer: Danger Service Content-Transfer-Encoding: 7bit In-Reply-To: <4.3.2.7.2.20050920154625.0362ad90@email.cisco.com> Content-Type: text/plain; charset="us-ascii"; format="flowed" To: "James M. Polk" , ecrit@ietf.org Mime-Version: 1.0 References: <4.3.2.7.2.20050920154625.0362ad90@email.cisco.com> From: Brian Rosen Message-Id: <1127251394.4A98BE6@bd8.dngr.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Is this a trick question? Its pretty hard to decide what happens in a disaster, but you sure want emergency calling to work. How often do disasters occur? Do you wish to be in the position of defending the decision to have catagory 3 levees because there hasn't been a catagory 4 hurricane in 200 years? How many standard deviations is that? Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 20 17:34:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHpkq-0006mR-V5; Tue, 20 Sep 2005 17:34:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHpkp-0006mM-4y for ecrit@megatron.ietf.org; Tue, 20 Sep 2005 17:34:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07473 for ; Tue, 20 Sep 2005 17:34:16 -0400 (EDT) Received: from bay106-dav22.bay106.hotmail.com ([65.54.161.94] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHpqh-0004Dc-U4 for ecrit@ietf.org; Tue, 20 Sep 2005 17:40:25 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 20 Sep 2005 14:34:05 -0700 Message-ID: Received: from 65.54.161.200 by BAY106-DAV22.phx.gbl with DAV; Tue, 20 Sep 2005 21:34:05 +0000 X-Originating-IP: [65.54.161.200] X-Originating-Email: [timothydunn01@msn.com] X-Sender: timothydunn01@msn.com From: "Tim Dunn" To: "'James M. Polk'" , Subject: RE: [Ecrit] Timing of PSAPs changing coverage areas Date: Tue, 20 Sep 2005 15:34:01 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: AAAAAHid4H6cLVBKvI35MTImwgAHANlTnCJhprtFudq2LHCBs8EBACIA//8AANlTnCJhprtFudq2LHCBs8EBAColAAAAAA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW+Jh+2Yf3HuRyjSp2TWkZBWnzpqwAAsTGA X-OriginalArrivalTime: 20 Sep 2005 21:34:05.0696 (UTC) FILETIME=[06CDF800:01C5BE2B] X-Spam-Score: 1.6 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James- In certain parts of the US (generally rural, but I think there are also some urban examples), I am aware of local police departments that answer their emergency calls between 8am and 5pm. At other times the calls are routed to a county or state level center that is a 24x7 operation. So the answer to your question would be that routing changes can occur daily in some places. In the legacy circuit switched environment, there is generally a way to busy out the inbound emergency trunks, allowing for routing of calls to another location. In my example above, the local PSAP throws a switch and the calls now route to an alternate location. This is also, in general, how trunk busyouts occur if a PSAP needs to quickly vacate and you want the calls routed elsewhere. My experience was that there were switches at the PSAP, at the central office (to busy out the trunks) and sometimes at a local backup PSAP (unbusying those trunks to begin accepting calls). If you had your primary and backup location out of business, there are switch level instructions on where to route. Tim Dunn -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James M. Polk Sent: Tuesday, September 20, 2005 2:56 PM To: ecrit@ietf.org Subject: [Ecrit] Timing of PSAPs changing coverage areas All I've heard and read the statements and requirements from folks that the routing of a call to a PSAP needs to be as fresh as possible because a particular PSAP might have moved, or more accurately, that a location might be served "on a moment's notice" by a different PSAP. I'd like to ask how often this happens today. Does anyone know how often a location needs to contact a different PSAP than its normal/standard one? It seems to me that a lot of us might be imagining a worse-case scenario that we need to design protocols for, and that this worse-case scenario happens often. If this is, say only 0.01% of the time - or even under 5% of all emergency calls (2 standard deviations, or SDs), I'm thinking we're focusing too much energy on solving something that is a statistical "outlier". Today's emergency systems aren't build for 2 SDs, and especially not for 4 SDs. 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 Tue Sep 20 17:35:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHpmO-00071b-Bx; Tue, 20 Sep 2005 17:35:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHpmM-00071U-EC for ecrit@megatron.ietf.org; Tue, 20 Sep 2005 17:35:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07506 for ; Tue, 20 Sep 2005 17:35:51 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHpsF-0004FW-8k for ecrit@ietf.org; Tue, 20 Sep 2005 17:42:00 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 20 Sep 2005 14:35:44 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8KLZS4j012747; Tue, 20 Sep 2005 14:35:42 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 14:35:39 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.203]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 14:35:38 -0700 Message-Id: <4.3.2.7.2.20050920162145.03639360@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Sep 2005 16:35:37 -0500 To: From: "James M. Polk" Subject: RE: [Ecrit] draft-polk-dhc-uri-00 (silly picture) In-Reply-To: <4c98s5$310u0r@sj-inbound-b.cisco.com> References: <4.3.2.7.2.20050920135903.037b4a60@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Sep 2005 21:35:38.0517 (UTC) FILETIME=[3E215450:01C5BE2B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 04:45 PM 9/20/2005 -0400, Brian Rosen wrote: >One of the issues with using DHCP to do the mapping function is that it's >not universally implemented. it's also not expected to be a one-size-fits-all solution... come on now. >That means you cannot use it for everything. SIP won't be used for everything so it shouldn't be considered either, by that same logic. >That means we need more than one protocol to get the PSAP URI. Doesn't the ECRIT Arch Considerations ID state exactly that? >Given the >experience we are having with getting location, where we have two protocols, DHCP and what? >some folks are demanding a third, and every phone has to implement every >protocol, that I am opposed to a mechanism that cannot be reasonably be >deployed in every environment. well that gets rid of SIP too... cuz some folks will implement H.323 or .248 and translate at their boundaries. Then there are the Cisco Skinny folks, and the MGCP folks... >By that criteria, DHCP would not pass >muster, DNS would. IRIS and LUMP would also. Is DNS is in my phone? IRIS is not on my phone. LUMP is not on my phone. SIP is. Why don't we use SIP then for the layer 7 solution if you want ONE protocol under your assumption that SIP will be the signaling protocol? It is the ONE common protocol to everything you're working on. We've shown/state HTTP is not uniform or ubiquitous - so it's out. LUMP means SOAP, and I don't believe that's absolutely everywhere. What are you left with? Why are you being so absolute? IP is built on layers. There should be one solution per (applicable) layer as a mandatory to implement. By your same argument, location-by-reference AND location-by-value shouldn't be used either, because neither will be everywhere, and neither will be in the 3G and beyond phone. >Brian > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >James M. Polk >Sent: Tuesday, September 20, 2005 3:07 PM >To: Henning Schulzrinne; 'ECRIT' >Subject: Re: [Ecrit] draft-polk-dhc-uri-00 (big picture) > >At 11:59 AM 9/17/2005 -0400, Henning Schulzrinne wrote: > >I'm not sure a DNS-vs.-DHCP discussion is all that helpful. Since a lot of > >messages have gone back and forth, it would help me at least to summarize > >some of the points and see if we can at least agree on the facts. > > > ># The system we're building has a number of translations between the "dial > >emergency number" and the final IP address of the phone of the PSAP call > >taker, including at least: > > > >(1) Caller maps location and service desired to PSAP URL, possibly using > >the mapping URL conveyed in DHCP > >DHCP can also - based on the ID - provide the ESRP URI - which is your #3 >below > > >(3) The DNS resolution points to one or more SIP proxies, which in turn > >route calls to the next step, either another SIP proxy closer to the call > >taker or the call taker. Repeat step (2) and (3) until the phone rings. > > > ># If the PSAP URL(s) are included in the DHCP information, presumably the > >DHCP server performs step (1) above, for each attached device based on its > >location. The draft does not really say so, but I'm certainly hoping that > >this is not manually configured. > >I didn't get into what was not a DHCP function in the ID, no. Just as 3825 >and your civic ID don't articulate how the DHCP server learns a client's >location. In those cases, the DHCP server knows to pass along a circuitID >to some external server, wait for an answer, then reply to the client with >its location. The same assumptions are made in this ID. The bar shouldn't >be raised now for this ID. But perhaps I should make the same operational >analogy as is present in 3825 and your civic ID. > > >Presumably, this would take place at the time the client asks for an > >address or does a DHCPINFORM. > >yes, or I have it possible that the server sends this information >unsolicited to the client, which can be ignored without causing error(s). > > > >Let's see if I got the picture right. > >close > > > >Henning > > > > > > > >_______________________________________________ > >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 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 Tue Sep 20 17:51:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHq1P-00033W-Nm; Tue, 20 Sep 2005 17:51:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHq1O-000331-CZ for ecrit@megatron.ietf.org; Tue, 20 Sep 2005 17:51:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08212 for ; Tue, 20 Sep 2005 17:51:23 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHq7G-0004YW-FG for ecrit@ietf.org; Tue, 20 Sep 2005 17:57:32 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 20 Sep 2005 14:51:15 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8KLojKU012550; Tue, 20 Sep 2005 14:51:10 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 14:51:10 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.203]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 14:51:10 -0700 Message-Id: <4.3.2.7.2.20050920164006.035e07d0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Sep 2005 16:51:09 -0500 To: Brian Rosen , ecrit@ietf.org From: "James M. Polk" Subject: Re: [Ecrit] Timing of PSAPs changing coverage areas In-Reply-To: <1127251394.4A98BE6@bd8.dngr.org> References: <4.3.2.7.2.20050920154625.0362ad90@email.cisco.com> <4.3.2.7.2.20050920154625.0362ad90@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Sep 2005 21:51:10.0361 (UTC) FILETIME=[698D7090:01C5BE2D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 05:23 PM 9/20/2005 -0400, Brian Rosen wrote: >Is this a trick question? > >Its pretty hard to decide what happens in a disaster, but you sure want >emergency calling to work. The phone infrastructure has to work for 911 to work. Just look at Katrina for evidence of how 911 didn't work on multiple levels - either the phone switches didn't work, or the call centers weren't there, or they were there and told the people that help WAS NOT on the way. Listen to the MSNBC tapes of the 911 calls for proof of that last one. ECRIT shouldn't solve for this because the infrastructure wasn't there. If the infrastructure was there, shouldn't SIP proxies reroute the INVITEs? Pushing the "take this URI and send any message to it to this IP address" to affected Proxies seems to me to be the best of all worlds. >How often do disasters occur? 911 isn't about disasters, although folks use it in times of disasters - and I can ask the question about how effective it is during disasters next if you want. 911 is about individuals calling for local emergencies. There was a car accident. There is a person having a heart attack. Someone is breaking into my house. etc This is what 911 is for at its roots. Lets not plan this to solve for Katrina type disasters and build in all this complexity and cost that will make it less capable and less deployed. >Do you wish to be in the position of defending the decision to have >catagory 3 levees because there hasn't been a catagory 4 hurricane in 200 >years? Dude, like I said, you can listen to the 911 recordings yourself to determine IF THE 911 SYSTEM TODAY worked. If was because the infrastructure - that we are not changing - didn't work. >How many standard deviations is that? listen to the recordings and hear the operators tell people they should have left the city already, and that help was not coming. Would it matter which protocol was used in that case? How many standard deviations is that? Who expected the operators that did receive the calls to turn people away like that? >Brian 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 Tue Sep 20 18:03:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHqD7-0005sE-Rk; Tue, 20 Sep 2005 18:03:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHqD6-0005s9-Un for ecrit@megatron.ietf.org; Tue, 20 Sep 2005 18:03:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08728 for ; Tue, 20 Sep 2005 18:03:30 -0400 (EDT) Received: from mta1.prod1.dngr.net ([216.220.209.220] helo=mfe3.prod.danger.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHqJ0-0004mj-8j for ecrit@ietf.org; Tue, 20 Sep 2005 18:09:39 -0400 Received: from [10.253.1.252] (HELO localhost.localdomain) by mfe3.prod.danger.com (CommuniGate Pro SMTP 4.1.6) with ESMTP id 398947077; Tue, 20 Sep 2005 15:03:09 -0700 Date: Tue, 20 Sep 2005 18:03:06 -0400 Subject: Re: [Ecrit] draft-polk-dhc-uri-00 X-Mailer: Danger Service Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; format="flowed" To: "James M. Polk" Mime-Version: 1.0 References: <1127253544.366E5A85@bf12.dngr.org> From: Brian Rosen Message-Id: <1127253789.7249E77@dj11.dngr.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think a suitable uri for my psap is newcom@psap.state.pa.us. That implies a state level esrp. Presumably, that state level psap has redundancy, and the duplicate esrps have mechanisms that can forward calls to psaps that have made arrangements with the state to get them. What I worry about is that you may get in a situation where calls are being sent to some entity that, for whatever reasons, is unable to respond correctly. This can arise for all sorts of reasons, such as loss of connectivity from the folks who need to change its behavior, to enough failures that backuos aren't working, to effective partitioning of areas requiring actual changes in routing due to failures. While we try to anticipate such conditions, I don't believe its possible to anticipate everything, and its straightforward enough to design the system to allow changes in routing dynamically. So, maybe the psap that was the right route is no longer the right one. For example, maybe the city should go to one alternate psap, but everything else should go to another. I don't know, but I do know that disaster plans, like war plans, are obsolete the moment the shooting starts, and assumptions that you can anticipate what you may need to do are almost always wrong. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 20 18:09:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHqIl-0007Nk-I6; Tue, 20 Sep 2005 18:09:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHqIk-0007NR-Ml for ecrit@megatron.ietf.org; Tue, 20 Sep 2005 18:09:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09266 for ; Tue, 20 Sep 2005 18:09:19 -0400 (EDT) Received: from mta3.prod1.dngr.net ([216.220.209.222] helo=mfe1.prod.danger.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHqOe-0004te-21 for ecrit@ietf.org; Tue, 20 Sep 2005 18:15:29 -0400 Received: from [10.253.1.252] (HELO localhost.localdomain) by mfe1.prod.danger.com (CommuniGate Pro SMTP 4.1.6) with ESMTP id 394075137; Tue, 20 Sep 2005 15:09:12 -0700 Date: Tue, 20 Sep 2005 18:09:09 -0400 Subject: Re: [Ecrit] draft-polk-dhc-uri-00 (silly picture) X-Mailer: Danger Service Content-Transfer-Encoding: 7bit In-Reply-To: <4.3.2.7.2.20050920162145.03639360@email.cisco.com> Content-Type: text/plain; charset="us-ascii"; format="flowed" To: "James M. Polk" Mime-Version: 1.0 References: <4.3.2.7.2.20050920135903.037b4a60@email.cisco.com> <4.3.2.7.2.20050920162145.03639360@email.cisco.com> From: Brian Rosen Message-Id: <1127254152.1C302F30@be12.dngr.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If we select my dns proposal, or lump or iris, every routing element can implement it, without exception. If we use dhcp, only environments that support dhcp can use it. The other location protocol is lldp-med, and the proposed third is HELD. We certainly can have exactly one mapping protocol, and I think we should. It does not bother me that phones don't do iris or lump, and even if they have ds support, they don't ecrit mapping. Its new code. The difference is that dhcp requires local support, and that's not available everywhere. Dns and lump and iris don't need local support. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 20 18:16:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHqQ7-0001VH-CQ; Tue, 20 Sep 2005 18:16:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHqQ6-0001VC-Oi for ecrit@megatron.ietf.org; Tue, 20 Sep 2005 18:16:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10023 for ; Tue, 20 Sep 2005 18:16:55 -0400 (EDT) Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHqW0-00053n-Nl for ecrit@ietf.org; Tue, 20 Sep 2005 18:23:05 -0400 Received: from ([90.152.53.183]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.71547684; Tue, 20 Sep 2005 18:04:23 -0400 Importance: normal Priority: normal Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01AL10015010163.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 20 Sep 2005 17:04:13 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 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] draft-polk-dhc-uri-00 Date: Tue, 20 Sep 2005 17:04:13 -0500 Message-ID: <9888E1AA13C3A1459D122996A58C0E1131BC33@bre2k61p-55> Thread-Topic: [Ecrit] draft-polk-dhc-uri-00 thread-index: AcW+KkP8sfgw61lmRCSVzeeR6JXXTgAAP9KA From: "Stark, Barbara" To: "John Schnizlein" , "James M. Polk" X-OriginalArrivalTime: 20 Sep 2005 22:04:13.0637 (UTC) FILETIME=[3C6BDF50:01C5BE2F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I have a few questions on all this. Am I reading all of this correctly that there's a suggestion that VoIP clients should use DHCP to get the uri of its PSAP provider? My VoIP clients in my home talk to a DHCP server that resides in my home router. My home router doesn't talk to any DHCP server at all (it uses IPCP to get configuration info). Are proponents of a DHCP solution suggesting that my service provider must implement a DHCP server? Would this DHCP mean that PPPoE must not be used, or could it be some sort of DHCP that comes after PPPoE? And are proponents suggesting that I not only must make sure my VoIP devices support this functionality (which would be ok), but that my home router has to either be upgraded or replaced? In my experience, end users will resist all change to home routers unless they have no option (i.e., things break). End users will resist replacing home networks, unless we're able to make things break if they don't. Should we require that a VoIP device not work if it can't get a uri via DHCP (from the home router)? That's the only thing that I can think of that's painful enough to force someone to replace their home network. What if my VoIP device is configured with a static IP address (static netmask, gateway, and DNS, too) and isn't set to do DHCP? Is there still some DHCP message that's proposed for it to use? Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of John Schnizlein Sent: Tuesday, September 20, 2005 5:23 PM To: James M. Polk Cc: ECRIT Subject: Re: [Ecrit] draft-polk-dhc-uri-00 Answers embedded in context: On Sep 20, 2005, at 4:44 PM, James M. Polk wrote: > >>>> The problem with using DHCP is not the duration of an address=20 >>>> lease, but that there is no mechanism identified for getting new=20 >>>> URIs into the DHCP servers. >>> >>> ... >> As a practical matter, since the purpose of DHCP is entirely for=20 >> configuration within an administration, there is no reason for the=20 >> host on which the protocol server operates to be reachable from=20 >> outside the perimeter of that organization. Unlike DNS, DHCP is not=20 >> designed to provide time-limited, cached-for-efficiency, global=20 >> access to information. > > Why are you saying global here? Because DNS was designed for and operates as a global lookup service=20 for information maintained by individual authorities. > Just as the DHCP server communicates with a wiremap server in 3825, it > can communuicate with a pre-call mapping server. What is different is=20 > where this mapping server is, and it might/likely is external to the=20 > DHCP organization. There is a big difference between a local translation from wiremap and=20 circuit-ID to location and the proposed service that maintains local=20 and sufficiently current PSAP mappings that are administered elsewhere.=20 Since DHCP operation is clearly intended to be internal, it is=20 stretching credulity to expect the DHCP operator to rely on external=20 services in the process of allocating a local address. > >> Nothing about this protocol function relates to getting information=20 >> from outside the local administrative area. If a protocol were=20 >> proposed to add > > /add/interwork Whatever word you use, there is a huge semantic clash between local=20 (DHCP) function and obtaining and maintaining the proposed remote=20 information. >> ... >> The point that has been made is that DHCP is useful for configuring=20 >> hosts with local information (such as its location) within a local=20 >> administration, but that it seems a poor choice for obtaining=20 >> information that can be changed in a remote location under a=20 >> different administration. The principle is to use protocols for the=20 >> sorts of things for which they were designed. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. 163 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 20 19:18:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHrNA-0002kZ-To; Tue, 20 Sep 2005 19:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHrN9-0002kE-Gk for ecrit@megatron.ietf.org; Tue, 20 Sep 2005 19:17:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13869 for ; Tue, 20 Sep 2005 19:17:56 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHrT4-0006eS-EK for ecrit@ietf.org; Tue, 20 Sep 2005 19:24:06 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 18:17:44 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 20 Sep 2005 18:17:43 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 18:17:42 -0500 Message-ID: From: "Winterbottom, James" To: "Tom-PT Taylor" , "Marc Linsner" Date: Tue, 20 Sep 2005 18:17:40 -0500 Subject: RE: [Ecrit] Proposed Requirement MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 20 Sep 2005 23:17:42.0859 (UTC) FILETIME=[8085C1B0:01C5BE39] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Proposed Requirement Thread-Index: AcW9I8rqnUuW1BbARweSYy/NHW97fQBFOG6A X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I could not disagree more with this requirement! The Mapping service by its very virtue of providing destination routing information based on location grants it the very trust that is being argued below that it does not have. Further to this, the mapping functions are in most cases likely to be in the best position to have this trust placed on them. I see the argument raised for having this requirement as being moot. A mapping function MUST be able to accept either a location-by-reference (preferred in the mobile case), or alternatively by-value, preferably if the source can be verified. Cheers James =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Tom-PT Taylor > Sent: Tuesday, 20 September 2005 12:06 AM > To: Marc Linsner > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Proposed Requirement >=20 > I like it. >=20 > Marc Linsner wrote: > > A proposed new requirement for the 'almost finished' req. draft..... > > > > Requirement: The ecrit mechanism will only deal with location data in > value > > form, any location by-reference or location-key MUST be resolved to a > > location by-value prior to query submission to the mapping database. > > > > Motivation: It cannot be expected that the entities considered to be > 'the > > mapping database' (accepting the queries and returning a resolution) of > the > > location mapping-to-uri function be part of any trust or authentication > > mechanism that may be required to resolve location > > by-reference/location-key. > > > > > > This requirement spurs the need to define location by-reference, > > location-key and location by-value in section 2 - Terminology. > Hence.... > > > > Location by-reference: A URI that when accessed by an authorized entity > will > > yield the location of the end-point to which the reference is > associated. > > > > Location-Key: A mechanism used to provide a reference to a location. > This > > may be a URI, a URL or some other kind of identifier. > > > > Location by-value: The location data in it's native form (see location). > > > > > > Fire-away, > > > > -Marc- > > > > _______________________________________________ > > 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 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 20 19:30:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHrZY-0006T9-Gi; Tue, 20 Sep 2005 19:30:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHrZW-0006T4-Fd for ecrit@megatron.ietf.org; Tue, 20 Sep 2005 19:30:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14615 for ; Tue, 20 Sep 2005 19:30:42 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHrfP-00071G-TA for ecrit@ietf.org; Tue, 20 Sep 2005 19:36:53 -0400 Received: from zharhxm0.corp.nortel.com (zharhxm0.corp.nortel.com [47.165.48.148]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j8KNTtM14670; Wed, 21 Sep 2005 01:29:55 +0200 (MEST) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zharhxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 00:29:55 +0100 Received: from [127.0.0.1] ([47.130.16.133] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 19:29:53 -0400 Message-ID: <43309B6C.8030101@nortel.com> Date: Tue, 20 Sep 2005 19:29:48 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] Proposed Requirement References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Sep 2005 23:29:53.0606 (UTC) FILETIME=[3414E660:01C5BE3B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org What you're saying is that you don't want us to force the mapping client to be the fetcher of location. You want the mapping server to have to do this. You are imposing an additional interface on that equipment as a result. Is this reasonable? Winterbottom, James wrote: > I could not disagree more with this requirement! > > The Mapping service by its very virtue of providing destination routing > information based on location grants it the very trust that is being > argued below that it does not have. Further to this, the mapping > functions are in most cases likely to be in the best position to have > this trust placed on them. I see the argument raised for having this > requirement as being moot. > > A mapping function MUST be able to accept either a location-by-reference > (preferred in the mobile case), or alternatively by-value, preferably if > the source can be verified. > > Cheers > James > > > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > Of > >>Tom-PT Taylor >>Sent: Tuesday, 20 September 2005 12:06 AM >>To: Marc Linsner >>Cc: ecrit@ietf.org >>Subject: Re: [Ecrit] Proposed Requirement >> >>I like it. >> >>Marc Linsner wrote: >> >>>A proposed new requirement for the 'almost finished' req. draft..... >>> >>>Requirement: The ecrit mechanism will only deal with location data > > in > >>value >> >>>form, any location by-reference or location-key MUST be resolved to > > a > >>>location by-value prior to query submission to the mapping database. >>> >>>Motivation: It cannot be expected that the entities considered to be >> >>'the >> >>>mapping database' (accepting the queries and returning a resolution) > > of > >>the >> >>>location mapping-to-uri function be part of any trust or > > authentication > >>>mechanism that may be required to resolve location >>>by-reference/location-key. >>> >>> >>>This requirement spurs the need to define location by-reference, >>>location-key and location by-value in section 2 - Terminology. >> >>Hence.... >> >>>Location by-reference: A URI that when accessed by an authorized > > entity > >>will >> >>>yield the location of the end-point to which the reference is >> >>associated. >> >>>Location-Key: A mechanism used to provide a reference to a location. >> >>This >> >>>may be a URI, a URL or some other kind of identifier. >>> >>>Location by-value: The location data in it's native form (see > > location). > >>> >>>Fire-away, >>> >>>-Marc- >>> >>>_______________________________________________ >>>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 > > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 21 00:33:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHwIk-0006OF-QO; Wed, 21 Sep 2005 00:33:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHwIh-0006O2-6S for ecrit@megatron.ietf.org; Wed, 21 Sep 2005 00:33:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26668 for ; Wed, 21 Sep 2005 00:33:39 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHwOb-0004vd-Qf for ecrit@ietf.org; Wed, 21 Sep 2005 00:39:53 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 20 Sep 2005 21:33:31 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8L4Wx5I016069; Tue, 20 Sep 2005 21:33:27 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 21:33:14 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.203]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 21:32:30 -0700 Message-Id: <4.3.2.7.2.20050920233212.03740680@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Sep 2005 23:33:12 -0500 To: "Tim Dunn" , From: "James M. Polk" Subject: RE: [Ecrit] Timing of PSAPs changing coverage areas In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 21 Sep 2005 04:32:30.0621 (UTC) FILETIME=[7A8184D0:01C5BE65] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tim This is a good example, and one that SIP covers already, as time-of-day routing is a piece of cake to a SIP Proxy. At 03:34 PM 9/20/2005 -0600, Tim Dunn wrote: >James- > >In certain parts of the US (generally rural, but I think there are also some >urban examples), I am aware of local police departments that answer their >emergency calls between 8am and 5pm. At other times the calls are routed to >a county or state level center that is a 24x7 operation. So the answer to >your question would be that routing changes can occur daily in some places. > > >In the legacy circuit switched environment, there is generally a way to busy >out the inbound emergency trunks, allowing for routing of calls to another >location. In my example above, the local PSAP throws a switch and the calls >now route to an alternate location. > >This is also, in general, how trunk busyouts occur if a PSAP needs to >quickly vacate and you want the calls routed elsewhere. My experience was >that there were switches at the PSAP, at the central office (to busy out the >trunks) and sometimes at a local backup PSAP (unbusying those trunks to >begin accepting calls). If you had your primary and backup location out of >business, there are switch level instructions on where to route. > >Tim Dunn > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >James M. Polk >Sent: Tuesday, September 20, 2005 2:56 PM >To: ecrit@ietf.org >Subject: [Ecrit] Timing of PSAPs changing coverage areas > >All > >I've heard and read the statements and requirements from folks that the >routing of a call to a PSAP needs to be as fresh as possible because a >particular PSAP might have moved, or more accurately, that a location might >be served "on a moment's notice" by a different PSAP. > >I'd like to ask how often this happens today. Does anyone know how often a >location needs to contact a different PSAP than its normal/standard one? > >It seems to me that a lot of us might be imagining a worse-case scenario >that we need to design protocols for, and that this worse-case scenario >happens often. If this is, say only 0.01% of the time - or even under 5% of >all emergency calls (2 standard deviations, or SDs), I'm thinking we're >focusing too much energy on solving something that is a statistical >"outlier". > >Today's emergency systems aren't build for 2 SDs, and especially not for 4 >SDs. > >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 Sep 21 00:54:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHwcq-0004GF-LO; Wed, 21 Sep 2005 00:54:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHwco-0004Fn-0n for ecrit@megatron.ietf.org; Wed, 21 Sep 2005 00:54:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27498 for ; Wed, 21 Sep 2005 00:54:26 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHwil-0005OP-RL for ecrit@ietf.org; Wed, 21 Sep 2005 01:00:40 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 20 Sep 2005 21:54:21 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8L4sI4V027254 for ; Tue, 20 Sep 2005 21:54:19 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 21:54:18 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.203]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 21:54:18 -0700 Message-Id: <4.3.2.7.2.20050920234657.037269c8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Sep 2005 23:54:16 -0500 To: John Schnizlein From: "James M. Polk" Subject: Re: [Ecrit] draft-polk-dhc-uri-00 In-Reply-To: References: <4.3.2.7.2.20050920140925.037bef08@email.cisco.com> <200509141531.LAA17265@ietf.org> <42CC6B9B-0362-49CD-BDEE-99A6F82D8332@hxr.us> <288238a691e5974f4453d647477abe3b@cisco.com> <4.3.2.7.2.20050920140925.037bef08@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 21 Sep 2005 04:54:18.0308 (UTC) FILETIME=[85F2B840:01C5BE68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 05:22 PM 9/20/2005 -0400, John Schnizlein wrote: >Answers embedded in context: > >On Sep 20, 2005, at 4:44 PM, James M. Polk wrote: >>>Unlike DNS, DHCP is not designed to provide time-limited, >>>cached-for-efficiency, global access to information. >> >>Why are you saying global here? > >Because DNS was designed for and operates as a global lookup service for >information maintained by individual authorities. Fair, but I read your comment like you thought I was expecting DHCP to be global in nature for this to work, and I do not have that expectation. >>Just as the DHCP server communicates with a wiremap server in 3825, it >>can communuicate with a pre-call mapping server. What is different is >>where this mapping server is, and it might/likely is external to the DHCP >>organization. > >There is a big difference between a local translation from wiremap and >circuit-ID to location and the proposed service that maintains local and >sufficiently current PSAP mappings that are administered elsewhere. Since >DHCP operation is clearly intended to be internal, it is stretching >credulity to expect the DHCP operator to rely on external services in the >process of allocating a local address. You have a problem with a, perhaps, once-every-24-hours download from a secure site that is outside the local domain? >>>Nothing about this protocol function relates to getting information from >>>outside the local administrative area. If a protocol were proposed to add >> >>/add/interwork > >Whatever word you use, there is a huge semantic clash between local (DHCP) >function and obtaining and maintaining the proposed remote information. > >>>... >>>The point that has been made is that DHCP is useful for configuring >>>hosts with local information (such as its location) within a local >>>administration, but that it seems a poor choice for obtaining >>>information that can be changed in a remote location under a different >>>administration. The principle is to use protocols for the sorts of >>>things for which they were designed. 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 Sep 21 01:13:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHwvH-0000wy-PV; Wed, 21 Sep 2005 01:13:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHwvF-0000wt-MA for ecrit@megatron.ietf.org; Wed, 21 Sep 2005 01:13:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAB28280 for ; Wed, 21 Sep 2005 01:13:33 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHx1B-0005on-CM for ecrit@ietf.org; Wed, 21 Sep 2005 01:19:44 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 20 Sep 2005 22:13:20 -0700 X-IronPort-AV: i="3.97,129,1125903600"; d="scan'208"; a="343835204:sNHT33529064" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8L5CaKi014695; Tue, 20 Sep 2005 22:13:14 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 22:13:05 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.203]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 22:13:04 -0700 Message-Id: <4.3.2.7.2.20050920235509.029f8e48@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 21 Sep 2005 00:13:03 -0500 To: "Stark, Barbara" , "John Schnizlein" From: "James M. Polk" Subject: RE: [Ecrit] draft-polk-dhc-uri-00 In-Reply-To: <9888E1AA13C3A1459D122996A58C0E1131BC33@bre2k61p-55> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 21 Sep 2005 05:13:04.0418 (UTC) FILETIME=[25297820:01C5BE6B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 05:04 PM 9/20/2005 -0500, Stark, Barbara wrote: >I have a few questions on all this. >Am I reading all of this correctly that there's a suggestion that VoIP >clients should use DHCP to get the uri of its PSAP provider? The DHCP client in infrastructures it is condusive towards, yes >My VoIP clients in my home talk to a DHCP server that resides in my home >router. >My home router doesn't talk to any DHCP server at all (it uses IPCP to >get configuration info). This doesn't prevent your DSL modem from having this information through other means. This ID makes not assumptions about a multi-hop scenario like you have. >Are proponents of a DHCP solution suggesting that my service provider >must implement a DHCP server? no, in your situation, it would be from your DSL modem to any client on your home network. >Would this DHCP mean that PPPoE must not >be used, or could it be some sort of DHCP that comes after PPPoE? These are independent as far as I can tell >And >are proponents suggesting that I not only must make sure my VoIP devices >support this functionality (which would be ok), but that my home router >has to either be upgraded or replaced? As with any extension not supported by a device, yes. >In my experience, end users will >resist all change to home routers unless they have no option (i.e., >things break). Recent replacement marketing campaigns seem to be working to the contrary of this statement, at least where I live. >End users will resist replacing home networks, unless >we're able to make things break if they don't. people in general are motivated for a few reasons, they have to gain something, or choose not to loose something. Gaining the ability to call for local emergency help might be enough of a gain for people to make the change. >Should we require that a >VoIP device not work if it can't get a uri via DHCP (from the home >router)? There will have to be a default route of some sort. Remember, your home DSL modem doesn't likely support RFC 3825 or the Civic ID yet, and that is a basis for this WG's effort too. >That's the only thing that I can think of that's painful enough >to force someone to replace their home network. > >What if my VoIP device is configured with a static IP address (static >netmask, gateway, and DNS, too) and isn't set to do DHCP? Is there still >some DHCP message that's proposed for it to use? If everything you have is static, then your PSAP URI might be too. This means you might have to rely on "the SIP Network" to route you sos@ INVITE to the right PSAP if it is not the one at your URI. This is not hard. A front-ending VSP should have this capability from the beginning of their operation. An alternative to the static URI is to have a higher layer do the URI mapping before any emergency call. The Emergency Architecture Considerations ID states this as a layered approach. I have a separate ID using SIP to do this coming soon. The grand picture there would be if DHCP provides this PSAP (and other) URIs, great. If DHCP does not, for whatever reason, the UA knows this and requests the URIs using SIP. Why SIP? I believe it will be the one application layer protocol in the most endpoints - and this extension will not require significant changes to accomodate this request for the URIs. >Barbara > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of >John Schnizlein >Sent: Tuesday, September 20, 2005 5:23 PM >To: James M. Polk >Cc: ECRIT >Subject: Re: [Ecrit] draft-polk-dhc-uri-00 > > >Answers embedded in context: > >On Sep 20, 2005, at 4:44 PM, James M. Polk wrote: > > > >>>> The problem with using DHCP is not the duration of an address > >>>> lease, but that there is no mechanism identified for getting new > >>>> URIs into the DHCP servers. > >>> > >>> ... > >> As a practical matter, since the purpose of DHCP is entirely for > >> configuration within an administration, there is no reason for the > >> host on which the protocol server operates to be reachable from > >> outside the perimeter of that organization. Unlike DNS, DHCP is not > >> designed to provide time-limited, cached-for-efficiency, global > >> access to information. > > > > Why are you saying global here? > >Because DNS was designed for and operates as a global lookup service >for information maintained by individual authorities. > > > Just as the DHCP server communicates with a wiremap server in 3825, it > > > can communuicate with a pre-call mapping server. What is different is > > where this mapping server is, and it might/likely is external to the > > DHCP organization. > >There is a big difference between a local translation from wiremap and >circuit-ID to location and the proposed service that maintains local >and sufficiently current PSAP mappings that are administered elsewhere. > Since DHCP operation is clearly intended to be internal, it is >stretching credulity to expect the DHCP operator to rely on external >services in the process of allocating a local address. > > > > >> Nothing about this protocol function relates to getting information > >> from outside the local administrative area. If a protocol were > >> proposed to add > > > > /add/interwork > >Whatever word you use, there is a huge semantic clash between local >(DHCP) function and obtaining and maintaining the proposed remote >information. > > >> ... > >> The point that has been made is that DHCP is useful for configuring > >> hosts with local information (such as its location) within a local > >> administration, but that it seems a poor choice for obtaining > >> information that can be changed in a remote location under a > >> different administration. The principle is to use protocols for the > >> sorts of things for which they were designed. > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > >The information transmitted is intended only for the person or entity to >which it is addressed and may contain confidential, proprietary, and/or >privileged material. Any review, retransmission, dissemination or other >use of, or taking of any action in reliance upon this information by >persons or entities other than the intended recipient is prohibited. If >you received this in error, please contact the sender and delete the >material from all computers. 163 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 Sep 21 01:25:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHx6e-0003x2-2H; Wed, 21 Sep 2005 01:25:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHx6a-0003w6-0W for ecrit@megatron.ietf.org; Wed, 21 Sep 2005 01:25:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28619 for ; Wed, 21 Sep 2005 01:25:15 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHxCY-00062R-4t for ecrit@ietf.org; Wed, 21 Sep 2005 01:31:26 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 20 Sep 2005 22:25:07 -0700 X-IronPort-AV: i="3.97,129,1125903600"; d="scan'208"; a="343840187:sNHT31509664" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8L5OGKm019516; Tue, 20 Sep 2005 22:24:57 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 22:25:00 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.203]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 22:24:08 -0700 Message-Id: <4.3.2.7.2.20050921001531.035db078@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 21 Sep 2005 00:24:58 -0500 To: Brian Rosen From: "James M. Polk" Subject: Re: [Ecrit] draft-polk-dhc-uri-00 (silly picture) In-Reply-To: <1127254152.1C302F30@be12.dngr.org> References: <4.3.2.7.2.20050920162145.03639360@email.cisco.com> <4.3.2.7.2.20050920135903.037b4a60@email.cisco.com> <4.3.2.7.2.20050920162145.03639360@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 21 Sep 2005 05:24:09.0024 (UTC) FILETIME=[B14C4C00:01C5BE6C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org DNS, IRIS and LUMP are useless without location of the UA. Location seems to be coming from DHCP. In that *very*same* DHCP response IP packet can be the PSAP URI. that seems pretty efficient to me. The lease mechanism can be used to provide a fairly fresh URI in the phones. SIP Routing can take care of reroutes due to: 1- time of day routing changes 2- overloads (by pushing the overload state to the Proxies) 3- jurisdictional changes 4- etc... and Call transfer: - whether before the operator answers the call - because the local PSAP Proxy recognized the INVITE from intended for another PSAP, or - when the operator asks the user where they are will handle the rest of the cases. We already need the call transfer procedure in place for VPNs. For i3, the PSAP will have an ESRP for message inspection. This can do the message rerouting if necessary, and the PSAP administrators can control when that occus for the above 3 listed reasons (plus a few others) At 06:09 PM 9/20/2005 -0400, Brian Rosen wrote: >If we select my dns proposal, or lump or iris, every routing element can >implement it, without exception. If we use dhcp, only environments that >support dhcp can use it. > >The other location protocol is lldp-med, and the proposed third is HELD. > >We certainly can have exactly one mapping protocol, and I think we >should. It does not bother me that phones don't do iris or lump, and even >if they have ds support, they don't ecrit mapping. Its new code. >The difference is that dhcp requires local support, and that's not >available everywhere. Dns and lump and iris don't need local support. 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 Sep 21 02:24:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHy2M-0004M1-1f; Wed, 21 Sep 2005 02:24:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHy2J-0004Ld-OX for ecrit@megatron.ietf.org; Wed, 21 Sep 2005 02:24:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22906 for ; Wed, 21 Sep 2005 02:24:54 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHy8H-0007YP-7Q for ecrit@ietf.org; Wed, 21 Sep 2005 02:31:06 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 01:24:35 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 21 Sep 2005 01:24:34 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 01:24:33 -0500 Message-ID: From: "Thomson, Martin" To: "James M. Polk" , "Brian Rosen" Date: Wed, 21 Sep 2005 01:24:31 -0500 Subject: RE: [Ecrit] draft-polk-dhc-uri-00 (silly picture) MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 21 Sep 2005 06:24:33.0674 (UTC) FILETIME=[21C1FEA0:01C5BE75] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] draft-polk-dhc-uri-00 (silly picture) Thread-Index: AcW+bUOsgG2qMsIaSBm73zz4OehoqwABBY0Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0810363274==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============0810363274== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message Content-Transfer-Encoding: base64 WW91IHVzZSB0aGUgd29yZCAic2VlbXMiLCB3aGljaCBpcyBhcHByb3ByaWF0ZSBiZWNhdXNlIERI Q1AgaXNuJ3QgdW5pdmVyc2FsbHkgYXBwbGljYWJsZS4gIFdlIG5lZWQgbW9yZSB3aWRlbHkgYXBw bGljYWJsZSBzb2x1dGlvbnMuDQoNCkVmZmljaWVuY3kgaXNuJ3QgdGhlIG9ubHkgY29uc2lkZXJh dGlvbiBoZXJlIC0gdGhlIG1vYmlsZSBjYXNlIHN0aWxsIHByb3ZpZGVzIGEgcHJvYmxlbS4gIEFu eWhvdywgdGFsa2luZyBvZiBlZmZpY2llbmN5IGdldHMgdmVyeSBjbG9zZSB0byBzaW1pbGFyIGFy Z3VtZW50cyBhbHJlYWR5IGV4aGF1c3RlZCBpbiBHRU9QUklWIGFib3V0IGFwcGxpY2F0aW9uIGxh eWVyIGxvY2F0aW9uIGFjcXVpc2l0aW9uOyBHRU9QUklWIGRlY2lkZWQgdGhhdCBhcHBsaWNhdGlv biBsYXllciBoYXMgaXQncyBwbGFjZS4NCg0KT2YgY291cnNlLCBJIGFncmVlIHRoYXQgU0lQIHJv dXRpbmcgY2FuIHRha2UgY2FyZSBvZiBhIGxhcmdlIGFtb3VudCBvZiB0aG9zZSBjYXNlcy4NCg0K SnVzdCB0byBwcmV2ZW50IGFueSBtaXNjb25jZXB0aW9ucywgY2FsbCB0cmFuc2ZlciBpcyBub3Qg YWJzb2x1dGVseSBuZWNlc3NhcnkgZm9yIFZQTnMgaWYgdGhlIGVuZHBvaW50IHJldHJpZXZlcyBs b2NhdGlvbiBpbmZvcm1hdGlvbiBiZWZvcmUgY29tbWl0dGluZyB0byBhIFZQTi4NCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmFtZXMgTS4gUG9saw0KU2Vu dDogV2VkbmVzZGF5LCAyMSBTZXB0ZW1iZXIgMjAwNSAzOjI1IFBNDQpUbzogQnJpYW4gUm9zZW4N CkNjOiBFQ1JJVA0KU3ViamVjdDogUmU6IFtFY3JpdF0gZHJhZnQtcG9say1kaGMtdXJpLTAwIChz aWxseSBwaWN0dXJlKQ0KDQpETlMsIElSSVMgYW5kIExVTVAgYXJlIHVzZWxlc3Mgd2l0aG91dCBs b2NhdGlvbiBvZiB0aGUgVUEuIExvY2F0aW9uIHNlZW1zIA0KdG8gYmUgY29taW5nIGZyb20gREhD UC4gSW4gdGhhdCAqdmVyeSpzYW1lKiBESENQIHJlc3BvbnNlIElQIHBhY2tldCBjYW4gYmUgDQp0 aGUgUFNBUCBVUkkuIHRoYXQgc2VlbXMgcHJldHR5IGVmZmljaWVudCB0byBtZS4gIFRoZSBsZWFz ZSBtZWNoYW5pc20gY2FuIA0KYmUgdXNlZCB0byBwcm92aWRlIGEgZmFpcmx5IGZyZXNoIFVSSSBp biB0aGUgcGhvbmVzLiBTSVAgUm91dGluZyBjYW4gdGFrZSANCmNhcmUgb2YgcmVyb3V0ZXMgZHVl IHRvOg0KICAgICAgICAgMS0gdGltZSBvZiBkYXkgcm91dGluZyBjaGFuZ2VzDQogICAgICAgICAy LSBvdmVybG9hZHMgKGJ5IHB1c2hpbmcgdGhlIG92ZXJsb2FkIHN0YXRlIHRvIHRoZSBQcm94aWVz KQ0KICAgICAgICAgMy0ganVyaXNkaWN0aW9uYWwgY2hhbmdlcw0KICAgICAgICAgNC0gZXRjLi4u DQphbmQNCkNhbGwgdHJhbnNmZXI6DQogICAgICAgICAtIHdoZXRoZXIgYmVmb3JlIHRoZSBvcGVy YXRvciBhbnN3ZXJzIHRoZSBjYWxsDQogICAgICAgICAgICAgICAgIC0gYmVjYXVzZSB0aGUgbG9j YWwgUFNBUCBQcm94eSByZWNvZ25pemVkIHRoZQ0KICAgICAgICAgICAgICAgICBJTlZJVEUgZnJv bSBpbnRlbmRlZCBmb3IgYW5vdGhlciBQU0FQLCBvcg0KICAgICAgICAgLSB3aGVuIHRoZSBvcGVy YXRvciBhc2tzIHRoZSB1c2VyIHdoZXJlIHRoZXkgYXJlDQoNCndpbGwgaGFuZGxlIHRoZSByZXN0 IG9mIHRoZSBjYXNlcy4NCg0KV2UgYWxyZWFkeSBuZWVkIHRoZSBjYWxsIHRyYW5zZmVyIHByb2Nl ZHVyZSBpbiBwbGFjZSBmb3IgVlBOcy4NCg0KRm9yIGkzLCB0aGUgUFNBUCB3aWxsIGhhdmUgYW4g RVNSUCBmb3IgbWVzc2FnZSBpbnNwZWN0aW9uLiBUaGlzIGNhbiBkbyB0aGUgDQptZXNzYWdlIHJl cm91dGluZyBpZiBuZWNlc3NhcnksIGFuZCB0aGUgUFNBUCBhZG1pbmlzdHJhdG9ycyBjYW4gY29u dHJvbCANCndoZW4gdGhhdCBvY2N1cyBmb3IgdGhlIGFib3ZlIDMgbGlzdGVkIHJlYXNvbnMgKHBs dXMgYSBmZXcgb3RoZXJzKQ0KDQpBdCAwNjowOSBQTSA5LzIwLzIwMDUgLTA0MDAsIEJyaWFuIFJv c2VuIHdyb3RlOg0KPklmIHdlIHNlbGVjdCBteSBkbnMgcHJvcG9zYWwsIG9yIGx1bXAgb3IgaXJp cywgZXZlcnkgcm91dGluZyBlbGVtZW50IGNhbiANCj5pbXBsZW1lbnQgaXQsIHdpdGhvdXQgZXhj ZXB0aW9uLiAgSWYgd2UgdXNlIGRoY3AsIG9ubHkgZW52aXJvbm1lbnRzIHRoYXQgDQo+c3VwcG9y dCBkaGNwIGNhbiB1c2UgaXQuDQo+DQo+VGhlIG90aGVyIGxvY2F0aW9uIHByb3RvY29sIGlzIGxs ZHAtbWVkLCBhbmQgdGhlIHByb3Bvc2VkIHRoaXJkIGlzIEhFTEQuDQo+DQo+V2UgY2VydGFpbmx5 IGNhbiBoYXZlIGV4YWN0bHkgb25lIG1hcHBpbmcgcHJvdG9jb2wsIGFuZCBJIHRoaW5rIHdlIA0K PnNob3VsZC4gIEl0IGRvZXMgbm90IGJvdGhlciBtZSB0aGF0IHBob25lcyBkb24ndCBkbyBpcmlz IG9yIGx1bXAsIGFuZCBldmVuIA0KPmlmIHRoZXkgaGF2ZSBkcyBzdXBwb3J0LCB0aGV5IGRvbid0 IGVjcml0IG1hcHBpbmcuICBJdHMgbmV3IGNvZGUuDQo+VGhlIGRpZmZlcmVuY2UgaXMgdGhhdCBk aGNwIHJlcXVpcmVzIGxvY2FsIHN1cHBvcnQsIGFuZCB0aGF0J3Mgbm90IA0KPmF2YWlsYWJsZSBl dmVyeXdoZXJlLiBEbnMgYW5kIGx1bXAgYW5kIGlyaXMgZG9uJ3QgbmVlZCBsb2NhbCBzdXBwb3J0 Lg0KDQoNCmNoZWVycywNCkphbWVzDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICoqKioqKioqKioqKioqKioqKioNCiAgICAgICAgICAgICAgICAgVHJ1dGggaXMgbm90IHRvIGJl IGFyZ3VlZC4uLiBpdCBpcyB0byBiZSBwcmVzZW50ZWQuDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFY3JpdCBtYWlsaW5nIGxpc3QNCkVjcml0QGll dGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBm b3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxl Z2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklm IHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIN CmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1 c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0= --===============0810363274== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0810363274==-- From ecrit-bounces@ietf.org Wed Sep 21 06:57:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI2Hn-00011R-Be; Wed, 21 Sep 2005 06:57:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI2Hk-0000yP-Ay for ecrit@megatron.ietf.org; Wed, 21 Sep 2005 06:57:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11596 for ; Wed, 21 Sep 2005 06:57:05 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI2Nk-00068W-Fq for ecrit@ietf.org; Wed, 21 Sep 2005 07:03:21 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 21 Sep 2005 03:56:58 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,130,1125903600"; d="scan'208"; a="10602159:sNHT21569104" Received: from [68.50.138.194] (che-vpn-cluster-2-108.cisco.com [10.86.242.108]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8LAuuT6021013; Wed, 21 Sep 2005 06:56:56 -0400 (EDT) In-Reply-To: <4.3.2.7.2.20050920234657.037269c8@email.cisco.com> References: <4.3.2.7.2.20050920140925.037bef08@email.cisco.com> <200509141531.LAA17265@ietf.org> <42CC6B9B-0362-49CD-BDEE-99A6F82D8332@hxr.us> <288238a691e5974f4453d647477abe3b@cisco.com> <4.3.2.7.2.20050920140925.037bef08@email.cisco.com> <4.3.2.7.2.20050920234657.037269c8@email.cisco.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <66dfdedf04f5b806059d022405147b56@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit] draft-polk-dhc-uri-00 Date: Wed, 21 Sep 2005 06:56:39 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The fundamental problem is that the organizational and technical details of this "download from a secure site" must be specified and reviewed because there is widespread doubt that it is feasible. For example, it appears that the site from which the download is performed, and the particular values downloaded should be different for different DHCP servers. Expecting that enough DHCP-server operators would add this coordination burden to their internal services to justify any clients trying to use it seems to be unrealistic. As Barbara asks: would you expect the DHCP server in her home router to perform this "download"? John On Sep 21, 2005, at 12:54 AM, James M. Polk wrote: > >>> Just as the DHCP server communicates with a wiremap server in 3825, >>> it can communuicate with a pre-call mapping server. What is >>> different is where this mapping server is, and it might/likely is >>> external to the DHCP organization. >> >> There is a big difference between a local translation from wiremap >> and circuit-ID to location and the proposed service that maintains >> local and sufficiently current PSAP mappings that are administered >> elsewhere. Since DHCP operation is clearly intended to be internal, >> it is stretching credulity to expect the DHCP operator to rely on >> external services in the process of allocating a local address. > > You have a problem with a, perhaps, once-every-24-hours download from > a secure site that is outside the local domain? > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 21 08:26:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI3gD-00081N-Hv; Wed, 21 Sep 2005 08:26:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI3gC-00080o-2r for ecrit@megatron.ietf.org; Wed, 21 Sep 2005 08:26:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16118 for ; Wed, 21 Sep 2005 08:26:27 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI3mD-000076-RP for ecrit@ietf.org; Wed, 21 Sep 2005 08:32:42 -0400 Received: from [10.0.1.100] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 21 Sep 2005 08:26:23 -0400 id 000C7E5C.4331516F.000073EB In-Reply-To: <66dfdedf04f5b806059d022405147b56@cisco.com> References: <4.3.2.7.2.20050920140925.037bef08@email.cisco.com> <200509141531.LAA17265@ietf.org> <42CC6B9B-0362-49CD-BDEE-99A6F82D8332@hxr.us> <288238a691e5974f4453d647477abe3b@cisco.com> <4.3.2.7.2.20050920140925.037bef08@email.cisco.com> <4.3.2.7.2.20050920234657.037269c8@email.cisco.com> <66dfdedf04f5b806059d022405147b56@cisco.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] draft-polk-dhc-uri-00 Date: Wed, 21 Sep 2005 08:26:21 -0400 To: John Schnizlein , br@brianrosen.net X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 21, 2005, at 6:56 AM, John Schnizlein wrote: > The fundamental problem is that the organizational and technical > details of this "download from a secure site" must be specified and > reviewed because there is widespread doubt that it is feasible. It just hasn't been specified. Calling it a "fundamental problem" seems premature. > For example, it appears that the site from which the download is > performed, and the particular values downloaded should be different > for different DHCP servers. Isn't this the same problem we have with LCMS? > Expecting that enough DHCP-server operators would add this > coordination burden to their internal services to justify any > clients trying to use it seems to be unrealistic. As Barbara asks: > would you expect the DHCP server in her home router to perform this > "download"? Well, that certainly is an interesting question. Just as interesting as: would you expect the DHCP server in her home router to have been given its civic address? If we cannot expect users to enter in a URI for the download, we certainly cannot expect users to enter in their multiline civic address. Especially when it must be done carefully, as was the conclusion here: http://www1.ietf.org/mail-archive/web/ ecrit/current/msg00746.html ... and especially given that this type of thing may not work with the Pizza Hut delivery mapping server. On Sep 20, 2005, at 4:45 PM, Brian Rosen wrote: > One of the issues with using DHCP to do the mapping function is > that it's > not universally implemented. That means you cannot use it for > everything. > That means we need more than one protocol to get the PSAP URI. > Given the > experience we are having with getting location, where we have two > protocols, > some folks are demanding a third, and every phone has to implement > every > protocol, that I am opposed to a mechanism that cannot be > reasonably be > deployed in every environment. By that criteria, DHCP would not pass > muster, DNS would. IRIS and LUMP would also. There are two things being said here: 1) DHCP is not universally implemented. and 2) DHCP is not a good LCMS I agree. From what I have read, I think James Polk would agree. On point 1, not only is DHCP not universally implemented, neither is any type of network-based location sighting. Therefore, I do not think it is unreasonable for James to suggest tweaks to protocols that have not been deployed (and in some cases, are not even ratified as standards). Also, I do not think James is saying that DHCP is the only way this can be done. I think his intention is that if DHCP is being used for LCI, then it can also be used for URIs. If other methods can be used for LCI, then they can also be used for URIs. On point 2, James is not proposing another LCMS. If anything, he is proposing it take place at another stage. And even then, not even in all cases: LCMS will likely be needed just before call setup in most geo cases. Additionally, there is one other use for his proposal. If LCMS is not available at call setup, then this is a good way of provisioning default/backup PSAP URIs (given all the talk about the need for anticipating what we cannot anticipate). -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 21 09:05:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI4Hl-0007Q9-Ri; Wed, 21 Sep 2005 09:05:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI4Hj-0007PV-K8 for ecrit@megatron.ietf.org; Wed, 21 Sep 2005 09:05:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17506 for ; Wed, 21 Sep 2005 09:05:04 -0400 (EDT) Received: from dnsmx1pya.telcordia.com ([128.96.20.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI4NX-0000xm-H0 for ecrit@ietf.org; Wed, 21 Sep 2005 09:11:19 -0400 Received: from rrc-its-ieg01.cc.telcordia.com (rrc-its-ieg01.cc.telcordia.com [128.96.109.78]) by dnsmx1pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j8LD4bg27023 for ; Wed, 21 Sep 2005 09:04:37 -0400 (EDT) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-its-ieg01.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005092109043203206 for ; Wed, 21 Sep 2005 09:04:33 -0400 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 21 Sep 2005 09:03:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] draft-polk-dhc-uri-00 Date: Wed, 21 Sep 2005 09:03:45 -0400 Message-ID: Thread-Topic: [Ecrit] draft-polk-dhc-uri-00 Thread-Index: AcW+qAJSGISxBP7NRSq9sZVnbOdxKQABFIPQ From: "Abbott, Nadine B" To: "ECRIT" X-OriginalArrivalTime: 21 Sep 2005 13:03:48.0802 (UTC) FILETIME=[E8207220:01C5BEAC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 I think Andy's point is a good one, and extensible to other mechanisms used for acquiring location as well. >...there is one other use for [James'] proposal. If LCMS is =20 >not available at call setup, then this is a good way of provisioning =20 >default/backup PSAP URIs. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 21 09:24:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI4ak-0004iI-E1; Wed, 21 Sep 2005 09:24:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI4af-0004gU-3I for ecrit@megatron.ietf.org; Wed, 21 Sep 2005 09:24:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18938 for ; Wed, 21 Sep 2005 09:24:47 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI4gT-0001ew-4p for ecrit@ietf.org; Wed, 21 Sep 2005 09:31:03 -0400 Received: from [172.27.0.211] ([64.251.114.2]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j8LDO7P4002024 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 21 Sep 2005 09:24:08 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <923D744D-FA7C-400E-89D3-F2C1BC0BA711@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Proposed Requirement Date: Wed, 21 Sep 2005 09:24:41 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.733) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The problem is that there is an unbounded number of de-referencing mechanisms for by-reference mechanisms (any URL, essentially), while the protocol format clearly limits what's legal in by-value. Given the hierarchical nature of mapping, these references would also be passed around, with unknown access characteristics. Thus, without serious constraints on protocol mechanisms, this is a recipe for mapping failures. The security issues are even hairier. On Sep 20, 2005, at 7:17 PM, Winterbottom, James wrote: > I could not disagree more with this requirement! > > The Mapping service by its very virtue of providing destination > routing > information based on location grants it the very trust that is being > argued below that it does not have. Further to this, the mapping > functions are in most cases likely to be in the best position to have > this trust placed on them. I see the argument raised for having this > requirement as being moot. > > A mapping function MUST be able to accept either a location-by- > reference > (preferred in the mobile case), or alternatively by-value, > preferably if > the source can be verified. > > Cheers > James > > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf >> > Of > >> Tom-PT Taylor >> Sent: Tuesday, 20 September 2005 12:06 AM >> To: Marc Linsner >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Proposed Requirement >> >> I like it. >> >> Marc Linsner wrote: >> >>> A proposed new requirement for the 'almost finished' req. draft..... >>> >>> Requirement: The ecrit mechanism will only deal with location data >>> > in > >> value >> >>> form, any location by-reference or location-key MUST be resolved to >>> > a > >>> location by-value prior to query submission to the mapping database. >>> >>> Motivation: It cannot be expected that the entities considered to be >>> >> 'the >> >>> mapping database' (accepting the queries and returning a resolution) >>> > of > >> the >> >>> location mapping-to-uri function be part of any trust or >>> > authentication > >>> mechanism that may be required to resolve location >>> by-reference/location-key. >>> >>> >>> This requirement spurs the need to define location by-reference, >>> location-key and location by-value in section 2 - Terminology. >>> >> Hence.... >> >>> >>> Location by-reference: A URI that when accessed by an authorized >>> > entity > >> will >> >>> yield the location of the end-point to which the reference is >>> >> associated. >> >>> >>> Location-Key: A mechanism used to provide a reference to a location. >>> >> This >> >>> may be a URI, a URL or some other kind of identifier. >>> >>> Location by-value: The location data in it's native form (see >>> > location). > >>> >>> >>> Fire-away, >>> >>> -Marc- >>> >>> _______________________________________________ >>> 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 >> > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2] > > _______________________________________________ > 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 Sep 21 09:48:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI4y3-0001SM-5k; Wed, 21 Sep 2005 09:48:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI4y1-0001S8-12 for ecrit@megatron.ietf.org; Wed, 21 Sep 2005 09:48:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20619 for ; Wed, 21 Sep 2005 09:48:55 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI541-0002RC-DU for ecrit@ietf.org; Wed, 21 Sep 2005 09:55:11 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 21 Sep 2005 06:48:45 -0700 X-IronPort-AV: i="3.97,130,1125903600"; d="scan'208"; a="661123898:sNHT28582936" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8LDmGKW016494 for ; Wed, 21 Sep 2005 06:48:41 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 06:48:25 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 06:48:25 -0700 From: "Marc Linsner" To: "'James M. Polk'" Subject: RE: [Ecrit] draft-polk-dhc-uri-00 Date: Wed, 21 Sep 2005 09:48:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcW+aOGOBUQqMqgyRMOatm9mLEpjQQASeAHw In-Reply-To: <4.3.2.7.2.20050920234657.037269c8@email.cisco.com> Message-ID: X-OriginalArrivalTime: 21 Sep 2005 13:48:25.0322 (UTC) FILETIME=[2374FCA0:01C5BEB3] X-Spam-Score: 1.1 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > > > >There is a big difference between a local translation from > wiremap and > >circuit-ID to location and the proposed service that > maintains local and > >sufficiently current PSAP mappings that are administered > elsewhere. Since > >DHCP operation is clearly intended to be internal, it is stretching > >credulity to expect the DHCP operator to rely on external > services in the > >process of allocating a local address. > > You have a problem with a, perhaps, once-every-24-hours > download from a > secure site that is outside the local domain? Why 'once-every-24-hours'? Where did number this come from? How do you propose to 'enforce' this? -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 21 11:30:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI6YI-0007ff-4x; Wed, 21 Sep 2005 11:30:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI6YH-0007fa-6Z for ecrit@megatron.ietf.org; Wed, 21 Sep 2005 11:30:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28343 for ; Wed, 21 Sep 2005 11:30:27 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI6eJ-0005bs-Dk for ecrit@ietf.org; Wed, 21 Sep 2005 11:36:44 -0400 Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j8LFU5B13770 for ; Wed, 21 Sep 2005 17:30:06 +0200 (MEST) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zharhxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 16:30:05 +0100 Received: from [127.0.0.1] ([47.130.17.158] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 11:30:04 -0400 Message-ID: <43317C79.5020809@nortel.com> Date: Wed, 21 Sep 2005 11:30:01 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Sep 2005 15:30:04.0214 (UTC) FILETIME=[56AE0D60:01C5BEC1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Subject: [Ecrit] Comments on ecrit-requirements-00 section 5: L6 and L29 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 L6: the "motivation" is really just a definition, and there is a better definition in the terminology section. I think the real motivation is to provide opportunity to improve the accuracy of the routing process and to speed emergency call setup. Actual text: "Motivation: this provides the opportunity to help assure the accuracy of routing of emergency calls, and avoid delays during emergency call setup due to invalid locations." L29: (1) It would be good if this followed immediately after L6, since the two requirements are closely related. (2) The motivation is too broad relative to the requirement. I'd suggest something like the following: "Motivation: failures of routine procedures or special circumstances will inevitably result in the occasional presentation of non-validated and in some cases invalid locations. The emergency routing system must provide a reasonable response to them." Tom Taylor _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 21 15:43:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIAUy-0006du-It; Wed, 21 Sep 2005 15:43:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIAUv-0006dl-ER for ecrit@megatron.ietf.org; Wed, 21 Sep 2005 15:43:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15023 for ; Wed, 21 Sep 2005 15:43:15 -0400 (EDT) Message-Id: <200509211943.PAA15023@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIAb0-0004bD-6V for ecrit@ietf.org; Wed, 21 Sep 2005 15:49:35 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EIAUb-0007lL-2p; Wed, 21 Sep 2005 14:42:57 -0500 From: "Brian Rosen" To: "'Abbott, Nadine B'" , "'ECRIT'" Subject: RE: [Ecrit] draft-polk-dhc-uri-00 Date: Wed, 21 Sep 2005 15:42:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW+qAJSGISxBP7NRSq9sZVnbOdxKQABFIPQAA3B/CA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Not so fast. How did the DHCP server find out the mapping? Did it use the LCMS to do it (at boot time)? If so, then the endpoint could (and I believe should) do the mapping directly. Is the DHCP entry returned provisioned (as opposed to discovered from the LCMS)? If so, use the UA provisioning process to provide the default. Where else could it come from? Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Abbott, Nadine B Sent: Wednesday, September 21, 2005 9:04 AM To: ECRIT Subject: RE: [Ecrit] draft-polk-dhc-uri-00 I think Andy's point is a good one, and extensible to other mechanisms used for acquiring location as well. >...there is one other use for [James'] proposal. If LCMS is >not available at call setup, then this is a good way of provisioning >default/backup PSAP URIs. _______________________________________________ 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 Sep 21 17:46:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EICPq-0005dT-5J; Wed, 21 Sep 2005 17:46:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EICPl-0005d6-6s for ecrit@megatron.ietf.org; Wed, 21 Sep 2005 17:46:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04308 for ; Wed, 21 Sep 2005 17:46:02 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EICVq-000451-Li for ecrit@ietf.org; Wed, 21 Sep 2005 17:52:24 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 21 Sep 2005 14:45:54 -0700 X-IronPort-AV: i="3.97,132,1125903600"; d="scan'208"; a="344176385:sNHT2125028078" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8LLjP5E020978; Wed, 21 Sep 2005 14:45:45 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 14:45:35 -0700 Received: from jmpolk-wxp.cisco.com ([64.101.175.173]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 14:44:37 -0700 Message-Id: <4.3.2.7.2.20050921164224.035440a8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 21 Sep 2005 16:45:34 -0500 To: "Thomson, Martin" , "Brian Rosen" From: "James M. Polk" Subject: RE: [Ecrit] draft-polk-dhc-uri-00 (silly picture) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 21 Sep 2005 21:44:38.0035 (UTC) FILETIME=[AA1EFE30:01C5BEF5] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 01:24 AM 9/21/2005 -0500, Thomson, Martin wrote: >You use the word "seems", which is appropriate because DHCP isn't >universally applicable. I said the latter too! >We need more widely applicable solutions. one size fits all is a great dream, but no one here has come up with one in the 2+ years we've been at this, so how much longer do we wait? >Efficiency isn't the only consideration here - the mobile case still >provides a problem. 3GPP *WILL*NOT*ALLOW the UA to know its own location, so that concept MUST be dropped from all our models and diagrams - then where are we at? >Anyhow, talking of efficiency gets very close to similar arguments already >exhausted in GEOPRIV about application layer location acquisition; GEOPRIV >decided that application layer has it's place. > >Of course, I agree that SIP routing can take care of a large amount of >those cases. > >Just to prevent any misconceptions, call transfer is not absolutely >necessary for VPNs if the endpoint retrieves location information before >committing to a VPN. Just as I said "seems", you say "if" - and I think that is a big IF to rely on. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >James M. Polk >Sent: Wednesday, 21 September 2005 3:25 PM >To: Brian Rosen >Cc: ECRIT >Subject: Re: [Ecrit] draft-polk-dhc-uri-00 (silly picture) > >DNS, IRIS and LUMP are useless without location of the UA. Location seems >to be coming from DHCP. In that *very*same* DHCP response IP packet can be >the PSAP URI. that seems pretty efficient to me. The lease mechanism can >be used to provide a fairly fresh URI in the phones. SIP Routing can take >care of reroutes due to: > 1- time of day routing changes > 2- overloads (by pushing the overload state to the Proxies) > 3- jurisdictional changes > 4- etc... >and >Call transfer: > - whether before the operator answers the call > - because the local PSAP Proxy recognized the > INVITE from intended for another PSAP, or > - when the operator asks the user where they are > >will handle the rest of the cases. > >We already need the call transfer procedure in place for VPNs. > >For i3, the PSAP will have an ESRP for message inspection. This can do the >message rerouting if necessary, and the PSAP administrators can control >when that occus for the above 3 listed reasons (plus a few others) > >At 06:09 PM 9/20/2005 -0400, Brian Rosen wrote: > >If we select my dns proposal, or lump or iris, every routing element can > >implement it, without exception. If we use dhcp, only environments that > >support dhcp can use it. > > > >The other location protocol is lldp-med, and the proposed third is HELD. > > > >We certainly can have exactly one mapping protocol, and I think we > >should. It does not bother me that phones don't do iris or lump, and even > >if they have ds support, they don't ecrit mapping. Its new code. > >The difference is that dhcp requires local support, and that's not > >available everywhere. Dns and lump and iris don't need local support. > > >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 > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] 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 Sep 21 17:53:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EICWR-0006Sd-T0; Wed, 21 Sep 2005 17:52:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EICWQ-0006SV-Vw for ecrit@megatron.ietf.org; Wed, 21 Sep 2005 17:52:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04573 for ; Wed, 21 Sep 2005 17:52:56 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EICcW-0004DO-PN for ecrit@ietf.org; Wed, 21 Sep 2005 17:59:18 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 21 Sep 2005 14:52:46 -0700 X-IronPort-AV: i="3.97,132,1125903600"; d="scan'208"; a="661247184:sNHT28446290" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8LLqK5E025323 for ; Wed, 21 Sep 2005 14:52:42 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 17:52:37 -0400 Received: from jmpolk-wxp.cisco.com ([64.101.175.173]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 17:52:36 -0400 Message-Id: <4.3.2.7.2.20050921165105.03279630@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 21 Sep 2005 16:52:36 -0500 To: "Marc Linsner" From: "James M. Polk" Subject: RE: [Ecrit] draft-polk-dhc-uri-00 In-Reply-To: References: <4.3.2.7.2.20050920234657.037269c8@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 21 Sep 2005 21:52:36.0972 (UTC) FILETIME=[C796FAC0:01C5BEF6] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 09:48 AM 9/21/2005 -0400, Marc Linsner wrote: > > You have a problem with a, perhaps, once-every-24-hours > > download from a > > secure site that is outside the local domain? > >Why 'once-every-24-hours'? Where did number this come from? hmmm.... isn't this the number that's currently available today for emergency calling changes? >How do you >propose to 'enforce' this? "enforce" and "the IETF" don't mix. We don't write laws... >-Marc- 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 Sep 21 18:04:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIChD-0002si-F6; Wed, 21 Sep 2005 18:04:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIChC-0002sT-8G for ecrit@megatron.ietf.org; Wed, 21 Sep 2005 18:04:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05115 for ; Wed, 21 Sep 2005 18:04:03 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EICnJ-0004Sc-5R for ecrit@ietf.org; Wed, 21 Sep 2005 18:10:25 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 17:03:48 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 21 Sep 2005 17:03:47 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 17:03:46 -0500 Message-ID: From: "Thomson, Martin" To: "James M. Polk" Date: Wed, 21 Sep 2005 17:03:45 -0500 Subject: Re: [Ecrit] draft-polk-dhc-uri-00 (silly picture) MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 21 Sep 2005 22:03:46.0770 (UTC) FILETIME=[56D20B20:01C5BEF8] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: Re: [Ecrit] draft-polk-dhc-uri-00 (silly picture) Thread-Index: AcW+9djXXoMFsql2TSiMFtuvbjoxBAAAgakg X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0899143596==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============0899143596== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message Content-Transfer-Encoding: base64 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW1lcyBNLiBQb2xrIFttYWls dG86am1wb2xrQGNpc2NvLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIDIyIFNlcHRlbWJlciAyMDA1 IDc6NDYgQU0NCj4gVG86IFRob21zb24sIE1hcnRpbjsgQnJpYW4gUm9zZW4NCj4gQ2M6IEVDUklU DQo+IFN1YmplY3Q6IFJFOiBbRWNyaXRdIGRyYWZ0LXBvbGstZGhjLXVyaS0wMCAoc2lsbHkgcGlj dHVyZSkNCj4gDQo+IEF0IDAxOjI0IEFNIDkvMjEvMjAwNSAtMDUwMCwgVGhvbXNvbiwgTWFydGlu IHdyb3RlOg0KPiA+WW91IHVzZSB0aGUgd29yZCAic2VlbXMiLCB3aGljaCBpcyBhcHByb3ByaWF0 ZSBiZWNhdXNlIERIQ1AgaXNuJ3QNCj4gPnVuaXZlcnNhbGx5IGFwcGxpY2FibGUuDQo+IA0KPiBJ IHNhaWQgdGhlIGxhdHRlciB0b28hDQo+IA0KPiA+V2UgbmVlZCBtb3JlIHdpZGVseSBhcHBsaWNh YmxlIHNvbHV0aW9ucy4NCj4gDQo+IG9uZSBzaXplIGZpdHMgYWxsIGlzIGEgZ3JlYXQgZHJlYW0s IGJ1dCBubyBvbmUgaGVyZSBoYXMgY29tZSB1cCB3aXRoIG9uZQ0KPiBpbg0KPiB0aGUgMisgeWVh cnMgd2UndmUgYmVlbiBhdCB0aGlzLCBzbyBob3cgbXVjaCBsb25nZXIgZG8gd2Ugd2FpdD8NCg0K VGhvc2UgMisgeWVhcnMgd2VyZW4ndCB3YXN0ZWQgKEkgaG9wZSkgLSB3ZSBub3cgaGF2ZSByZXF1 aXJlbWVudHMgYWxtb3N0IGZpbmlzaGVkLCB3aGljaCBjYW4gcHJvdmlkZSBpbnB1dCB0byB0aGUg ZGVzaWduIG9mIGFuIGFwcHJvcHJpYXRlIExDTVMgcHJvdG9jb2wuDQoNCj4gDQo+ID5FZmZpY2ll bmN5IGlzbid0IHRoZSBvbmx5IGNvbnNpZGVyYXRpb24gaGVyZSAtIHRoZSBtb2JpbGUgY2FzZSBz dGlsbA0KPiA+cHJvdmlkZXMgYSBwcm9ibGVtLg0KPiANCj4gM0dQUCAqV0lMTCpOT1QqQUxMT1cg dGhlIFVBIHRvIGtub3cgaXRzIG93biBsb2NhdGlvbiwgc28gdGhhdCBjb25jZXB0IE1VU1QNCj4g YmUgZHJvcHBlZCBmcm9tIGFsbCBvdXIgbW9kZWxzIGFuZCBkaWFncmFtcyAtIHRoZW4gd2hlcmUg YXJlIHdlIGF0Pw0KDQpJIHdvbmRlciBhYm91dCB5b3VyIHN0YXRlbWVudCBhYm91dCAzR1BQIC0g SSBkb24ndCB3YW50IHRvIHNvdW5kIGNvbnRyYXJ5LCBidXQgSSBoYXZlIGhlcmUgYSBjb3B5IG9m IFRTIDIzLjI3MSwgd2hpY2ggaW5jbHVkZXMgYSBzaXphYmxlIHNlY3Rpb24gZW50aXRsZWQgIjku MiBNb2JpbGUgT3JpZ2luYXRpbmcgTG9jYXRpb24gUmVxdWVzdCIsIHdoaWNoIHNlZW1zIHRvIGNv bnRyYWRpY3QgeW91ciBzdGF0ZW1lbnQuICBXaGVyZSBkaWQgeW91IGdldCB0aGlzIGluZm9ybWF0 aW9uPw0KDQpUaGUgb3RoZXIgdGhpbmcgaXMsIEkgYW0gbm90IHRhbGtpbmcgYWJvdXQgM0dQUCB3 aXJlbGVzcyBzcGVjaWZpY2FsbHksIEkgd2FzIHJlZmVycmluZyB0byB0aGUgZ2VuZXJhbCB3aXJl bGVzcyBjYXNlLCB3aGljaCBpbmNsdWRlcyBhIGxhcmdlIG51bWJlciBvZiB0ZWNobm9sb2dpZXMg KFdpRmkgYW5kIFdpTWF4IGZvciBpbnN0YW5jZSkuDQoNCj4gPkFueWhvdywgdGFsa2luZyBvZiBl ZmZpY2llbmN5IGdldHMgdmVyeSBjbG9zZSB0byBzaW1pbGFyIGFyZ3VtZW50cw0KPiBhbHJlYWR5 DQo+ID5leGhhdXN0ZWQgaW4gR0VPUFJJViBhYm91dCBhcHBsaWNhdGlvbiBsYXllciBsb2NhdGlv biBhY3F1aXNpdGlvbjsNCj4gR0VPUFJJVg0KPiA+ZGVjaWRlZCB0aGF0IGFwcGxpY2F0aW9uIGxh eWVyIGhhcyBpdCdzIHBsYWNlLg0KPiA+DQo+ID5PZiBjb3Vyc2UsIEkgYWdyZWUgdGhhdCBTSVAg cm91dGluZyBjYW4gdGFrZSBjYXJlIG9mIGEgbGFyZ2UgYW1vdW50IG9mDQo+ID50aG9zZSBjYXNl cy4NCj4gPg0KPiA+SnVzdCB0byBwcmV2ZW50IGFueSBtaXNjb25jZXB0aW9ucywgY2FsbCB0cmFu c2ZlciBpcyBub3QgYWJzb2x1dGVseQ0KPiA+bmVjZXNzYXJ5IGZvciBWUE5zIGlmIHRoZSBlbmRw b2ludCByZXRyaWV2ZXMgbG9jYXRpb24gaW5mb3JtYXRpb24gYmVmb3JlDQo+ID5jb21taXR0aW5n IHRvIGEgVlBOLg0KPiANCj4gSnVzdCBhcyBJIHNhaWQgInNlZW1zIiwgeW91IHNheSAiaWYiIC0g YW5kIEkgdGhpbmsgdGhhdCBpcyBhIGJpZyBJRiB0bw0KPiByZWx5IG9uLg0KIA0KTXkgb3Bpbmlv biBkaWZmZXJzLCBJIGRvbid0IHRoaW5rIHRoYXQgdGhpcyAiaWYiIGlzIHVucmVhc29uYWJsZSAt IHRoYXQgaXMgbm90IHRvIHNheSB0aGF0IGNhbGwgdHJhbnNmZXIgaXMgcG9pbnRsZXNzLCBtaXNy b3V0aW5nIGlzIHN0aWxsIGdvaW5nIHRvIG9jY3VyLCBidXQgdGhhdCB0aGlzIGlzIHRoZSBtb2Rl bCB0aGF0IHdlIHdhbnQgdG8gd29yayB0b3dhcmRzLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lw aWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90 aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRl IHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHBy b2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd --===============0899143596== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0899143596==-- From ecrit-bounces@ietf.org Wed Sep 21 21:13:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIFeJ-00071J-TA; Wed, 21 Sep 2005 21:13:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIFeI-00071E-PA for ecrit@megatron.ietf.org; Wed, 21 Sep 2005 21:13:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14301 for ; Wed, 21 Sep 2005 21:13:17 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIFkR-00006F-4B for ecrit@ietf.org; Wed, 21 Sep 2005 21:19:39 -0400 Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j8M1D2g18925 for ; Thu, 22 Sep 2005 03:13:02 +0200 (MEST) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zharhxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 02:13:02 +0100 Received: from [127.0.0.1] ([47.130.17.158] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 21:13:31 -0400 Message-ID: <43320517.90703@nortel.com> Date: Wed, 21 Sep 2005 21:12:55 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Sep 2005 01:13:32.0095 (UTC) FILETIME=[D900C4F0:01C5BF12] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Subject: [Ecrit] Comments on ecrit-requirements-00 section 6: Emergency Identifier X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think section 6 can back off slightly from the solution we all know is out there, and state the requirements a little more precisely. I would rewrite the requirements as follows: "A1a: Universal identifier -- setup. For each signalling protocol that can be used in an emergency call, it must be possible to indicate, within every message associated with that call, that this is an emergency call." Remark: does every message have to be flagged, or only the call initiating message? Further remark: using sos.* in the R-URI actually fulfills two purposes: it flags an emergency call, and it provides a dummy emergency address until a real one can be determined. If my rewriting of the requirement is accepted, we have a further requirement for a dummy emergency address. "A1a+: Dummy emergency address: For each signalling protocol that can be used in an emergency call, reserved addresses should be available to use in place of an emergency address prior to the point in the signalling path where mapping is done. The appropriate dummy emergency address may be based on local convention (e.g., 911, 112, ...)." Point of discussion: do we still need an emergency indicator in the signalling beyond the point of mapping? I think we do: use case, to allow non-emergency calls (e.g., test calls) to go to the same URI if required. ------------ A1b: Universal identifier -- mapping. I'm not sure what this requirement is saying as written. The motivation suggests that the requirement is that signalling must contain an indication that it is associated with an emergency call, that is recognizable by any device in the signalling path that is capable of invoking the mapping service. I do see a possible requirement that the mapping protocol must carry an indication that a given request is associated with an emergency call. The motivation for that requirement would be the possibility of use of the same protocol to the same mapping server for non-emergency purposes. Then what would be needed is a purpose identifier with "emergency" as one of those purposes. I suspect recent discussion is ahead of me on that one. --------- A1c: Emergency marking. In terms of my rewriting of A1a, this is two requirements: A1c: any device in the signalling path that recognizes by some means that the signalling is associated with an emergency call MUST add the emergency indication called for in A1a to the signalling before forwarding it. A1c+: User agents, proxies, and other network elements that may process signalling associated with emergency calls should be configured to recognize a reasonable repertoire of dummy emergency addresses (per requirement A1a+) as a means to trigger emergency marking. ---------- A3: Recognizable. I think the motivation is the requirement. The stated requirement is surely covered already in A1a and A1c. Hence the requirement should be stated as: "A3. Prevention of fraud. A call identified as an emergency call or marked as such in accordance with requirement A1c MUST be routed to a PSAP. Motivation: this prevents use of a dummy emergency address to gain access to call features or authentication override for non-emergency purposes." --------- A4 gets tweaked slightly: substitute the phrase "local dummy emergency addresses" for "local emergency identifiers". Tom Taylor _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 22 09:29:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIR8e-0005h0-Lo; Thu, 22 Sep 2005 09:29:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIR8c-0005gp-Ad for ecrit@megatron.ietf.org; Thu, 22 Sep 2005 09:29:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29431 for ; Thu, 22 Sep 2005 09:29:20 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIREq-00012v-Bf for ecrit@ietf.org; Thu, 22 Sep 2005 09:35:49 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j8MDTIVF009301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Sep 2005 09:29:19 -0400 (EDT) Message-ID: <4332B191.6080303@cs.columbia.edu> Date: Thu, 22 Sep 2005 09:28:49 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom-PT Taylor Subject: Re: [Ecrit] Comments on ecrit-requirements-00 section 6: Emergency Identifier References: <43320517.90703@nortel.com> In-Reply-To: <43320517.90703@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tom-PT Taylor wrote: > I think section 6 can back off slightly from the solution we all know is > out there, and state the requirements a little more precisely. I would > rewrite the requirements as follows: > > "A1a: Universal identifier -- setup. For each signalling protocol that > can be used in an emergency call, it must be possible to indicate, > within every message associated with that call, that this is an > emergency call." > > Remark: does every message have to be flagged, or only the call > initiating message? This is a little trickier than it might seem, security-wise. You want to be sure that people can only use an 'emergency' indicator for messages that actually go to the PSAP if such an indicator triggers special behavior. It would be bad, for example, if special BYE behavior is triggered by such an indicator and I could send random folks such marked messages and network elements in the middle would respect the flag. > > Further remark: using sos.* in the R-URI actually fulfills two purposes: > it flags an emergency call, and it provides a dummy emergency address > until a real one can be determined. If my rewriting of the requirement > is accepted, we have a further requirement for a dummy emergency address. > > "A1a+: Dummy emergency address: For each signalling protocol that can be > used in an emergency call, reserved addresses should be available to use > in place of an emergency address prior to the point in the signalling > path where mapping is done. The appropriate dummy emergency address may > be based on local convention (e.g., 911, 112, ...)." > > Point of discussion: do we still need an emergency indicator in the > signalling beyond the point of mapping? I think we do: use case, to > allow non-emergency calls (e.g., test calls) to go to the same URI if > required. We do need an indicator in the signaling message as proxies may treat the message differently, e.g., in terms of authorization requirement. If the phone does the mapping, the outbound proxy needs to know that this is an emergency call and maybe suspend authorization. This actually raises an interesting issue: an outbound proxy may want to verify that the call actually goes to a PSAP before suspending Digest requirements. You wouldn't want something like INVITE sip:1-900-hot-chat@voip-is-us.com To: urn:service:sos to enable free gateway calls. > > ------------ > > A1b: Universal identifier -- mapping. > I'm not sure what this requirement is saying as written. The motivation > suggests that the requirement is that signalling must contain an > indication that it is associated with an emergency call, that is > recognizable by any device in the signalling path that is capable of > invoking the mapping service. > > I do see a possible requirement that the mapping protocol must carry an > indication that a given request is associated with an emergency call. > The motivation for that requirement would be the possibility of use of > the same protocol to the same mapping server for non-emergency purposes. > Then what would be needed is a purpose identifier with "emergency" as > one of those purposes. I suspect recent discussion is ahead of me on > that one. > > --------- > > A1c: Emergency marking. > In terms of my rewriting of A1a, this is two requirements: > A1c: any device in the signalling path that recognizes by some means > that the signalling is associated with an emergency call MUST add the > emergency indication called for in A1a to the signalling before > forwarding it. > > A1c+: User agents, proxies, and other network elements that may process > signalling associated with emergency calls should be configured to > recognize a reasonable repertoire of dummy emergency addresses (per > requirement A1a+) as a means to trigger emergency marking. As noted below, 'dummy' is not the term I would use here. > > ---------- > > A3: Recognizable. > I think the motivation is the requirement. The stated requirement is > surely covered already in A1a and A1c. Hence the requirement should be > stated as: > > "A3. Prevention of fraud. > A call identified as an emergency call or marked as such in accordance > with requirement A1c MUST be routed to a PSAP. > > Motivation: this prevents use of a dummy emergency address to gain > access to call features or authentication override for non-emergency > purposes." Agreed. > > --------- > > A4 gets tweaked slightly: substitute the phrase "local dummy emergency > addresses" for "local emergency identifiers". I don't like the word "dummy". This is a logical identifier, but otherwise a fully real (service) identifier. This is not fundamentally different from sip:sales@ibm.com being redirected within IBM to sip:education-sales@nyc.ny.ibm.com based on my identity or location. > > Tom Taylor > > > _______________________________________________ > 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 Sep 22 09:50:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIRSb-0002nY-IQ; Thu, 22 Sep 2005 09:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIRSZ-0002nF-JB for ecrit@megatron.ietf.org; Thu, 22 Sep 2005 09:49:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00435 for ; Thu, 22 Sep 2005 09:49:57 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIRYn-0001WN-IW for ecrit@ietf.org; Thu, 22 Sep 2005 09:56:27 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 22 Sep 2005 06:49:30 -0700 X-IronPort-AV: i="3.97,138,1125903600"; d="scan'208"; a="213934848:sNHT1015310614" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j8MDmjvM024119 for ; Thu, 22 Sep 2005 06:49:28 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 06:49:08 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 06:49:08 -0700 From: "Marc Linsner" To: "'James M. Polk'" Subject: RE: [Ecrit] draft-polk-dhc-uri-00 Date: Thu, 22 Sep 2005 09:49:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <4.3.2.7.2.20050921165105.03279630@email.cisco.com> Thread-Index: AcW+9sebyIkervwbSqWYjnkj1T8qggAg/L+g Message-ID: X-OriginalArrivalTime: 22 Sep 2005 13:49:08.0726 (UTC) FILETIME=[67BDA960:01C5BF7C] X-Spam-Score: 1.1 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > > At 09:48 AM 9/21/2005 -0400, Marc Linsner wrote: > > > You have a problem with a, perhaps, once-every-24-hours download > > > from a secure site that is outside the local domain? > > > >Why 'once-every-24-hours'? Where did number this come from? > > hmmm.... isn't this the number that's currently available > today for emergency calling changes? No. > > >How do you > >propose to 'enforce' this? > > "enforce" and "the IETF" don't mix. OK, let's dance. How do you precieve a PSAP (routing db authority) effecting a routing change that is cached for an unknown amount of time in an unknown group of dhcp servers? -Marc- > > We don't write laws... > > > >-Marc- > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 22 10:00:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIRd4-0006V7-7M; Thu, 22 Sep 2005 10:00:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIRd2-0006Uv-GX for ecrit@megatron.ietf.org; Thu, 22 Sep 2005 10:00:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01239 for ; Thu, 22 Sep 2005 10:00:46 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIRjE-0001uO-0F for ecrit@ietf.org; Thu, 22 Sep 2005 10:07:15 -0400 Received: from zctfhxm1.corp.nortel.com (zctfhxm1.corp.nortel.com [47.164.129.157]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j8ME0Ng07272; Thu, 22 Sep 2005 16:00:23 +0200 (MEST) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zctfhxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 16:00:22 +0200 Received: from [127.0.0.1] ([47.130.17.66] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 10:00:20 -0400 Message-ID: <4332B8F2.3040302@nortel.com> Date: Thu, 22 Sep 2005 10:00:18 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Comments on ecrit-requirements-00 section 6: Emergency Identifier References: <43320517.90703@nortel.com> <4332B191.6080303@cs.columbia.edu> In-Reply-To: <4332B191.6080303@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Sep 2005 14:00:20.0863 (UTC) FILETIME=[F85DA0F0:01C5BF7D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Henning Schulzrinne wrote: > Tom-PT Taylor wrote: > >> I think section 6 can back off slightly from the solution we all know >> is out there, and state the requirements a little more precisely. I >> would rewrite the requirements as follows: >> >> "A1a: Universal identifier -- setup. For each signalling protocol >> that can be used in an emergency call, it must be possible to >> indicate, within every message associated with that call, that this is >> an emergency call." >> >> Remark: does every message have to be flagged, or only the call >> initiating message? > > > This is a little trickier than it might seem, security-wise. You want to > be sure that people can only use an 'emergency' indicator for messages > that actually go to the PSAP if such an indicator triggers special > behavior. It would be bad, for example, if special BYE behavior is > triggered by such an indicator and I could send random folks such marked > messages and network elements in the middle would respect the flag. > [PTT] Agreed. Is this covered by A3? Beyond that, I was asking if people even saw a requirement for marking messages beyond the initial message. > > >> >> Further remark: using sos.* in the R-URI actually fulfills two >> purposes: it flags an emergency call, and it provides a dummy >> emergency address until a real one can be determined. If my rewriting >> of the requirement is accepted, we have a further requirement for a >> dummy emergency address. >> >> "A1a+: Dummy emergency address: For each signalling protocol that can >> be used in an emergency call, reserved addresses should be available >> to use in place of an emergency address prior to the point in the >> signalling path where mapping is done. The appropriate dummy >> emergency address may be based on local convention (e.g., 911, 112, >> ...)." >> >> Point of discussion: do we still need an emergency indicator in the >> signalling beyond the point of mapping? I think we do: use case, to >> allow non-emergency calls (e.g., test calls) to go to the same URI if >> required. > > > We do need an indicator in the signaling message as proxies may treat > the message differently, e.g., in terms of authorization requirement. If > the phone does the mapping, the outbound proxy needs to know that this > is an emergency call and maybe suspend authorization. > > This actually raises an interesting issue: an outbound proxy may want to > verify that the call actually goes to a PSAP before suspending Digest > requirements. You wouldn't want something like > > INVITE sip:1-900-hot-chat@voip-is-us.com > To: urn:service:sos > > to enable free gateway calls. > [PTT] Hmm. Maybe another requirement, but it's tough to implement once the call is in the network. The general idea is clearly that for any call-initiating signalling containing the emergency indication, the address to which the call is being directed MUST be consistent with an emergency destination. The question is, if an inconsistency is found, is the call rejected, redirected to a PSAP, or is the emergency indicator cleared? >> >> ------------ >> >> A1b: Universal identifier -- mapping. >> I'm not sure what this requirement is saying as written. The >> motivation suggests that the requirement is that signalling must >> contain an indication that it is associated with an emergency call, >> that is recognizable by any device in the signalling path that is >> capable of invoking the mapping service. >> [PTT] It would be good to know that I have understood this one correctly. If so, I'll offer alternative text to make it more clear. >> I do see a possible requirement that the mapping protocol must carry >> an indication that a given request is associated with an emergency >> call. The motivation for that requirement would be the possibility of >> use of the same protocol to the same mapping server for non-emergency >> purposes. Then what would be needed is a purpose identifier with >> "emergency" as one of those purposes. I suspect recent discussion is >> ahead of me on that one. > > [PTT] Do people see this as a real requirement? > > > > > >> >> --------- >> >> A1c: Emergency marking. >> In terms of my rewriting of A1a, this is two requirements: >> A1c: any device in the signalling path that recognizes by some means >> that the signalling is associated with an emergency call MUST add the >> emergency indication called for in A1a to the signalling before >> forwarding it. >> >> A1c+: User agents, proxies, and other network elements that may >> process signalling associated with emergency calls should be >> configured to recognize a reasonable repertoire of dummy emergency >> addresses (per requirement A1a+) as a means to trigger emergency marking. > > > As noted below, 'dummy' is not the term I would use here. > > [PTT] Agreed. > >> >> ---------- >> >> A3: Recognizable. >> I think the motivation is the requirement. The stated requirement is >> surely covered already in A1a and A1c. Hence the requirement should >> be stated as: >> >> "A3. Prevention of fraud. >> A call identified as an emergency call or marked as such in accordance >> with requirement A1c MUST be routed to a PSAP. >> >> Motivation: this prevents use of a dummy emergency address to gain >> access to call features or authentication override for non-emergency >> purposes." > > > > Agreed. > > >> >> --------- >> >> A4 gets tweaked slightly: substitute the phrase "local dummy emergency >> addresses" for "local emergency identifiers". > > > I don't like the word "dummy". This is a logical identifier, but > otherwise a fully real (service) identifier. This is not fundamentally > different from > > sip:sales@ibm.com > > being redirected within IBM to > > sip:education-sales@nyc.ny.ibm.com > > based on my identity or location. > > [PTT] Instead of "dummy emergency address" how about "logical emergency address" then? > >> >> Tom Taylor >> >> >> _______________________________________________ >> 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 Sep 22 12:08:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EITcD-0001hT-6Z; Thu, 22 Sep 2005 12:08:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EITcB-0001gn-0V for ecrit@megatron.ietf.org; Thu, 22 Sep 2005 12:08:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08874 for ; Thu, 22 Sep 2005 12:08:00 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EITiQ-0005Dl-EE for ecrit@ietf.org; Thu, 22 Sep 2005 12:14:31 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 22 Sep 2005 09:07:51 -0700 X-IronPort-AV: i="3.97,138,1125903600"; d="scan'208"; a="213988689:sNHT33593814" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j8MG7nuk012105; Thu, 22 Sep 2005 09:07:50 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 09:07:47 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.146.27]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 09:07:47 -0700 Message-Id: <4.3.2.7.2.20050922104746.033d9a98@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Sep 2005 11:07:45 -0500 To: "Thomson, Martin" From: "James M. Polk" Subject: Re: [Ecrit] draft-polk-dhc-uri-00 (silly picture) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 22 Sep 2005 16:07:47.0432 (UTC) FILETIME=[C6137680:01C5BF8F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 05:03 PM 9/21/2005 -0500, Thomson, Martin wrote: > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Thursday, 22 September 2005 7:46 AM > > To: Thomson, Martin; Brian Rosen > > Cc: ECRIT > > Subject: RE: [Ecrit] draft-polk-dhc-uri-00 (silly picture) > > > > At 01:24 AM 9/21/2005 -0500, Thomson, Martin wrote: > > >You use the word "seems", which is appropriate because DHCP isn't > > >universally applicable. > > > > I said the latter too! > > > > >We need more widely applicable solutions. > > > > one size fits all is a great dream, but no one here has come up with one > > in > > the 2+ years we've been at this, so how much longer do we wait? > >Those 2+ years weren't wasted (I hope) - I didn't say it was a waste. I think people often get so focused on a particular aspect that they lose sight of other angles and pieces of the puzzle. Take the statement: ' if one protocol cannot cover 100% of the cases, it shouldn't be considered for any of them'. This DHCP idea is in essence for when the Location is provided by the same server. This DHCP idea is NOT all about PSAP URIs, as there are several URIs defined that have little to do with PSAPs, yet folks on this list (who are not taking this same argument to the DHC list themselves) are focusing on purpose=1 (PSAP URI). One other person discussed purpose=4 (ESRP URI) & =5 (ESGW URI). But that's the end of the comments, other than this whole DHCP idea is bad. This idea is the only one proposing getting the organization who provided location to the client/UA in order to include it in the PIDF-LO. No one else has done anything to resolve that one - yet that was a BIG deal last year as to why the DHCP provided location was a BAD idea. This discussion makes me think folks only want to talk about what's bad about someone else's idea, or it's just me they like to pick on ;-) >we now have requirements almost finished, which can provide input to the >design of an appropriate LCMS protocol. > > > > > >Efficiency isn't the only consideration here - the mobile case still > > >provides a problem. > > > > 3GPP *WILL*NOT*ALLOW the UA to know its own location, so that concept MUST > > be dropped from all our models and diagrams - then where are we at? > >I wonder about your statement about 3GPP - I don't want to sound contrary, >but I have here a copy of TS 23.271, which includes a sizable section >entitled "9.2 Mobile Originating Location Request", which seems to >contradict your statement. Where did you get this information? I'm the author of SIP Location Conveyance doc, and I was appraoched about modifying that IETF doc to suit 3GPP's requirements. >The other thing is, I am not talking about 3GPP wireless specifically, I >was referring to the general wireless case, which includes a large number >of technologies (WiFi and WiMax for instance). I do not believe the 802.11 case is that much of a problem from a routing to the right PSAP pov. WiMax is another issue. > > >Anyhow, talking of efficiency gets very close to similar arguments > > already > > >exhausted in GEOPRIV about application layer location acquisition; > > GEOPRIV > > >decided that application layer has it's place. > > > > > >Of course, I agree that SIP routing can take care of a large amount of > > >those cases. you seem to be the first to acknowledge this - I give you kudos > > > > > >Just to prevent any misconceptions, call transfer is not absolutely > > >necessary for VPNs if the endpoint retrieves location information before > > >committing to a VPN. > > > > Just as I said "seems", you say "if" - and I think that is a big IF to > > rely on. > >My opinion differs, I don't think that this "if" is unreasonable - that is >not to say that call transfer is pointless, misrouting is still going to >occur, but that this is the model that we want to work towards. >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 22 18:16:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIZMp-0008QR-TP; Thu, 22 Sep 2005 18:16:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIZMo-0008QH-Jm for ecrit@megatron.ietf.org; Thu, 22 Sep 2005 18:16:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29634 for ; Thu, 22 Sep 2005 18:16:31 -0400 (EDT) Message-Id: <200509222216.SAA29634@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIZT8-0006JW-5d for ecrit@ietf.org; Thu, 22 Sep 2005 18:23:06 -0400 Received: from acs-24-154-127-115.zoominternet.net ([24.154.127.115] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EIZMU-0002hf-Uq; Thu, 22 Sep 2005 17:16:15 -0500 From: "Brian Rosen" To: "'James M. Polk'" Subject: RE: [Ecrit] draft-polk-dhc-uri-00 Date: Thu, 22 Sep 2005 18:15:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW+9sebyIkervwbSqWYjnkj1T8qggAg/L+gAA5TXCA= 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: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This draft provides a mechanism to return URIs from DHCP. Here in ecrit, one we would have interest in is the PSAP URI(s). James proposes that we support the notion of a PSAP URI being returned from DHCP. There has been a lot of discussion on this one on the list. Before we go any farther, would it be appropriate to ask who else on this list thinks this is a good idea? If there is a lot of support, then we can get into details. If there isn't a lot of support, then we don't have to spend time on it. Please note that, as I understand it, James is NOT proposing that DHCP be considered a candidate for the protocol to perform the mapping between location and the URI of a PSAP. He is proposing that DHCP be one of several mechanisms that could be used to tell an endpoint what the result of mapping would be. I'm guessing that the DHCP server (or something connected to it) would use the mapping protocol to map location to PSAP URI, and deliver the result to the endpoint. My personal opinion is that this is not a good idea, that we don't want another mechanism between the mapping protocol and the end device, and that DHCP is not an appropriate protocol to deliver the URI of the PSAP. Among other reasons, unless we mandated that DHCP is the only way an endpoint finds out the URI of a PSAP, then every endpoint that looked for this DHCP option would have to implement at least one other way to get it. To me, that makes this idea pretty worthless. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 22 18:23:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIZT7-0001OY-Hd; Thu, 22 Sep 2005 18:23:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIZT6-0001NP-BW for ecrit@megatron.ietf.org; Thu, 22 Sep 2005 18:23:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00191 for ; Thu, 22 Sep 2005 18:23:01 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIZZO-0006QM-8A for ecrit@ietf.org; Thu, 22 Sep 2005 18:29:35 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 17:22:42 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 22 Sep 2005 17:22:42 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 17:22:41 -0500 Message-ID: From: "Thomson, Martin" To: "James M. Polk" Date: Thu, 22 Sep 2005 17:22:19 -0500 Subject: Re: [Ecrit] draft-polk-dhc-uri-00 (silly picture) MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 22 Sep 2005 22:22:41.0769 (UTC) FILETIME=[25BEE590:01C5BFC4] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: Re: [Ecrit] draft-polk-dhc-uri-00 (silly picture) Thread-Index: AcW/kE1XjhLaXhn2RD6pFM9Y9ZjXJwAMDO+A X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1268758554==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============1268758554== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message Content-Transfer-Encoding: base64 SGkgSmFtZXMsDQoNCklubGluZS4uLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YNCj4gSmFtZXMgTS4gUG9saw0KPiBTZW50OiBGcmlkYXksIDIzIFNl cHRlbWJlciAyMDA1IDI6MDggQU0NCj4gVG86IFRob21zb24sIE1hcnRpbg0KPiBDYzogRUNSSVQN Cj4gU3ViamVjdDogUmU6IFtFY3JpdF0gZHJhZnQtcG9say1kaGMtdXJpLTAwIChzaWxseSBwaWN0 dXJlKQ0KPiANCj4gPg0KPiA+VGhvc2UgMisgeWVhcnMgd2VyZW4ndCB3YXN0ZWQgKEkgaG9wZSkg LQ0KPiANCj4gSSBkaWRuJ3Qgc2F5IGl0IHdhcyBhIHdhc3RlLiBJIHRoaW5rIHBlb3BsZSBvZnRl biBnZXQgc28gZm9jdXNlZCBvbiBhDQo+IHBhcnRpY3VsYXIgYXNwZWN0IHRoYXQgdGhleSBsb3Nl IHNpZ2h0IG9mIG90aGVyIGFuZ2xlcyBhbmQgcGllY2VzIG9mIHRoZQ0KPiBwdXp6bGUuDQoNClRv byB0cnVlOyBwZXJoYXBzIHRoZSBwcm9ibGVtIGlzIGV4YWNlcmJhdGVkIGJ5IGRpZmZlcmluZyBw ZXJzcGVjdGl2ZXMgYXMgd2VsbC4gIEkgZG9uJ3QgdGhpbmsgdGhhdCBhbnl0aGluZyBidXQgaGVh bHRoeSBkaXNjdXNzaW9uIHdpbGwgc29sdmUgdGhhdCBwYXJ0aWN1bGFyIHByb2JsZW0uDQoNCj4g VGFrZSB0aGUgc3RhdGVtZW50OiAnIGlmIG9uZSBwcm90b2NvbCBjYW5ub3QgY292ZXIgMTAwJSBv ZiB0aGUgY2FzZXMsIGl0DQo+IHNob3VsZG4ndCBiZSBjb25zaWRlcmVkIGZvciBhbnkgb2YgdGhl bScuDQoNCkknbSBpbmNsaW5lZCB0byBhZ3JlZSB3aXRoIHlvdSwgYnV0IEkgdGhpbmsgdGhhdCB0 aGUgYXJndW1lbnRzIGFyZSB1c3VhbGx5IGxlc3MgYmxhY2sgJiB3aGl0ZSB0aGFuIHRoYXQgcGFy dGljdWxhciBvbmUuICBIb3cgYWJvdXQgJ2lmIG9uZSBwcm90b2NvbCBjYW4gY292ZXIgMTAwJSBv ZiB0aGUgY2FzZXMsIHdoeSBib3RoZXIgd2l0aCBhbnkgb3RoZXJzPycNCg0KPiBUaGlzIERIQ1Ag aWRlYSBpcyBpbiBlc3NlbmNlIGZvciB3aGVuIHRoZSBMb2NhdGlvbiBpcyBwcm92aWRlZCBieSB0 aGUgc2FtZQ0KPiBzZXJ2ZXIuICBUaGlzIERIQ1AgaWRlYSBpcyBOT1QgYWxsIGFib3V0IFBTQVAg VVJJcywgYXMgdGhlcmUgYXJlIHNldmVyYWwNCj4gVVJJcyBkZWZpbmVkIHRoYXQgaGF2ZSBsaXR0 bGUgdG8gZG8gd2l0aCBQU0FQcywgeWV0IGZvbGtzIG9uIHRoaXMgbGlzdA0KPiAod2hvDQo+IGFy ZSBub3QgdGFraW5nIHRoaXMgc2FtZSBhcmd1bWVudCB0byB0aGUgREhDIGxpc3QgdGhlbXNlbHZl cykgYXJlIGZvY3VzaW5nDQo+IG9uIHB1cnBvc2U9MSAoUFNBUCBVUkkpLiBPbmUgb3RoZXIgcGVy c29uIGRpc2N1c3NlZCBwdXJwb3NlPTQgKEVTUlAgVVJJKSAmDQo+ID01IChFU0dXIFVSSSkuIEJ1 dCB0aGF0J3MgdGhlIGVuZCBvZiB0aGUgY29tbWVudHMsIG90aGVyIHRoYW4gdGhpcyB3aG9sZQ0K PiBESENQIGlkZWEgaXMgYmFkLg0KPg0KPiBUaGlzIGlkZWEgaXMgdGhlIG9ubHkgb25lIHByb3Bv c2luZyBnZXR0aW5nIHRoZSBvcmdhbml6YXRpb24gd2hvIHByb3ZpZGVkDQo+IGxvY2F0aW9uIHRv IHRoZSBjbGllbnQvVUEgaW4gb3JkZXIgdG8gaW5jbHVkZSBpdCBpbiB0aGUgUElERi1MTy4gTm8g b25lDQo+IGVsc2UgaGFzIGRvbmUgYW55dGhpbmcgdG8gcmVzb2x2ZSB0aGF0IG9uZSAtIHlldCB0 aGF0IHdhcyBhIEJJRyBkZWFsIGxhc3QNCj4geWVhciBhcyB0byB3aHkgdGhlIERIQ1AgcHJvdmlk ZWQgbG9jYXRpb24gd2FzIGEgQkFEIGlkZWEuDQoNCkknbSBub3Qgc3VyZSB3aGF0IHlvdSBhcmUg dGFsa2luZyBhYm91dCAtIHlvdXIgZmlyc3Qgc2VudGVuY2UgZG9lc24ndCBwYXJzZS4gIEJ1dCwg aWYgeW91IHJlZmVyIHRvIERIQ1AgcHJvdmlkaW5nIGxvY2F0aW9uIGluZm9ybWF0aW9uLCB0aGVu IEknZCBzdWdnZXN0IHlvdSBhcmUgd3JvbmcuICBIRUxEIGdvZXMgb25lIHN0ZXAgZnVydGhlciBh bmQgcHJvdmlkZXMgYSBQSURGLUxPLg0KDQo+IFRoaXMgZGlzY3Vzc2lvbiBtYWtlcyBtZSB0aGlu ayBmb2xrcyBvbmx5IHdhbnQgdG8gdGFsayBhYm91dCB3aGF0J3MgYmFkDQo+IGFib3V0IHNvbWVv bmUgZWxzZSdzIGlkZWEsIG9yIGl0J3MganVzdCBtZSB0aGV5IGxpa2UgdG8gcGljayBvbiAgOy0p DQoNCkJ1dCB0YWxraW5nIGRvd24gb3RoZXIgcGVvcGxlJ3MgaWRlYXMgaXMgZnVuIDspICBJdCdz IHNvIG11Y2ggaGFyZGVyIHRvIGJlIGNvbnN0cnVjdGl2ZSwgdGhhdCB0YWtlcyB0aW1lIGFuZCBl ZmZvcnQuDQoNClNlcmlvdXNseSB0aG91Z2gsIEkgZ2VuZXJhbGx5IGxpa2UgdGhlIGlkZWEgb2Yg aGF2aW5nIGEgbWVhbnMgdG8gcHJvdmlkZSBjb25maWd1cmF0aW9uIFVSSXMgdGhyb3VnaCBESENQ LiAgSSBoYXZlIGFscmVhZHkgcmFpc2VkIG15IG90aGVyIGNvbmNlcm5zIC0gd2hpY2ggZGlkIG5v dCBpbmNsdWRlIHNheWluZyB0aGF0IHB1cnBvc2U9MSB3YXMgYmFkLCBvbmx5IHRoYXQgSSB3b3Vs ZCBkbyBpdCBhbm90aGVyIHdheS4NCg0KPiANCj4gPndlIG5vdyBoYXZlIHJlcXVpcmVtZW50cyBh bG1vc3QgZmluaXNoZWQsIHdoaWNoIGNhbiBwcm92aWRlIGlucHV0IHRvIHRoZQ0KPiA+ZGVzaWdu IG9mIGFuIGFwcHJvcHJpYXRlIExDTVMgcHJvdG9jb2wuDQo+ID4NCj4gPiA+DQo+ID4gPiA+RWZm aWNpZW5jeSBpc24ndCB0aGUgb25seSBjb25zaWRlcmF0aW9uIGhlcmUgLSB0aGUgbW9iaWxlIGNh c2Ugc3RpbGwNCj4gPiA+ID5wcm92aWRlcyBhIHByb2JsZW0uDQo+ID4gPg0KPiA+ID4gM0dQUCAq V0lMTCpOT1QqQUxMT1cgdGhlIFVBIHRvIGtub3cgaXRzIG93biBsb2NhdGlvbiwgc28gdGhhdCBj b25jZXB0DQo+IE1VU1QNCj4gPiA+IGJlIGRyb3BwZWQgZnJvbSBhbGwgb3VyIG1vZGVscyBhbmQg ZGlhZ3JhbXMgLSB0aGVuIHdoZXJlIGFyZSB3ZSBhdD8NCj4gPg0KPiA+SSB3b25kZXIgYWJvdXQg eW91ciBzdGF0ZW1lbnQgYWJvdXQgM0dQUCAtIEkgZG9uJ3Qgd2FudCB0byBzb3VuZA0KPiBjb250 cmFyeSwNCj4gPmJ1dCBJIGhhdmUgaGVyZSBhIGNvcHkgb2YgVFMgMjMuMjcxLCB3aGljaCBpbmNs dWRlcyBhIHNpemFibGUgc2VjdGlvbg0KPiA+ZW50aXRsZWQgIjkuMiBNb2JpbGUgT3JpZ2luYXRp bmcgTG9jYXRpb24gUmVxdWVzdCIsIHdoaWNoIHNlZW1zIHRvDQo+ID5jb250cmFkaWN0IHlvdXIg c3RhdGVtZW50LiAgV2hlcmUgZGlkIHlvdSBnZXQgdGhpcyBpbmZvcm1hdGlvbj8NCj4gDQo+IEkn bSB0aGUgYXV0aG9yIG9mIFNJUCBMb2NhdGlvbiBDb252ZXlhbmNlIGRvYywgYW5kIEkgd2FzIGFw cHJhb2NoZWQgYWJvdXQNCj4gbW9kaWZ5aW5nIHRoYXQgSUVURiBkb2MgdG8gc3VpdCAzR1BQJ3Mg cmVxdWlyZW1lbnRzLg0KDQpZb3Ugc2VlbSB0byBoYXZlIGNvbXBsZXRlbHkgY29udHJhZGljdG9y eSBpbmZvcm1hdGlvbiB0byB3aGF0IGlzIGluIHB1Ymxpc2hlZCAzR1BQIHN0YW5kYXJkcy4gIFdo aWNoIHJlcXVpcmVtZW50cyBkbyB5b3UgcmVmZXIgdG8gc3BlY2lmaWNhbGx5Pw0KDQo+ID5UaGUg b3RoZXIgdGhpbmcgaXMsIEkgYW0gbm90IHRhbGtpbmcgYWJvdXQgM0dQUCB3aXJlbGVzcyBzcGVj aWZpY2FsbHksIEkNCj4gPndhcyByZWZlcnJpbmcgdG8gdGhlIGdlbmVyYWwgd2lyZWxlc3MgY2Fz ZSwgd2hpY2ggaW5jbHVkZXMgYSBsYXJnZSBudW1iZXINCj4gPm9mIHRlY2hub2xvZ2llcyAoV2lG aSBhbmQgV2lNYXggZm9yIGluc3RhbmNlKS4NCj4gDQo+IEkgZG8gbm90IGJlbGlldmUgdGhlIDgw Mi4xMSBjYXNlIGlzIHRoYXQgbXVjaCBvZiBhIHByb2JsZW0gZnJvbSBhIHJvdXRpbmcNCj4gdG8g dGhlIHJpZ2h0IFBTQVAgcG92LiBXaU1heCBpcyBhbm90aGVyIGlzc3VlDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2ln bmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmll dGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJl Y2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5 IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMg ZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KW21mMl0= --===============1268758554== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1268758554==-- From ecrit-bounces@ietf.org Thu Sep 22 20:06:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIb4r-000681-BU; Thu, 22 Sep 2005 20:06:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIb4p-00067t-Se for ecrit@megatron.ietf.org; Thu, 22 Sep 2005 20:06:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14454 for ; Thu, 22 Sep 2005 20:06:05 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIbB7-0003dH-VJ for ecrit@ietf.org; Thu, 22 Sep 2005 20:12:40 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8N04xoV023133; Thu, 22 Sep 2005 17:04:59 -0700 (PDT) Received: from [192.168.1.4] (vpn-10-50-16-137.qualcomm.com [10.50.16.137]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8N04skM025296; Thu, 22 Sep 2005 17:04:57 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <200509222216.SAA29634@ietf.org> References: <200509222216.SAA29634@ietf.org> Date: Thu, 22 Sep 2005 17:04:53 -0700 To: br@brianrosen.net, "'James M. Polk'" From: Ted Hardie Subject: RE: [Ecrit] draft-polk-dhc-uri-00 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 6:15 PM -0400 9/22/05, Brian Rosen wrote: >This draft provides a mechanism to return URIs from DHCP. Here in ecrit, >one we would have interest in is the PSAP URI(s). > >James proposes that we support the notion of a PSAP URI being returned from >DHCP. > >There has been a lot of discussion on this one on the list. Before we go >any farther, would it be appropriate to ask who else on this list thinks >this is a good idea? If there is a lot of support, then we can get into >details. If there isn't a lot of support, then we don't have to spend time >on it. I support getting down to the details; I may or may not support what emerges once we get there. I have some concerns about how to handle what schemes are allowed, as there are tradeoffs here in interoperability that may be tricky. But I wouldn't rule the discussion out; it's a useful tool in a toolkit. For what it's worth, I'm in the camp that believes we will never reach 100% reliability with any single solution, and I question whether we'll get to five nines. I believe the most robust situation is one in which we understand multiple mechanisms as layered defenses against the inability to make this call. Let's say I have a dhcp capable device, which has a mapping protocol client and a sip client, and talks to a sip proxy that is also capable of mapping. My ideal is that at emergency time the client takes the location, maps to the correct PSAP, initiates the call and sends the location along with as useful data for the PSAP. But I would have the client request the location mapping at boot and periodically thereafter, so that stale data is available if fresh is not. And if the DHCP server provided information, it would get used until fresher data replaced it (imagine turning on your sip phone to report the emergency) And if none of the above were available, I would initiate a sip call to an "sos" uri sending the location information I had so it could do the mapping if it is capable of doing so; if I had no location information, I would still send to the "sos" URI, and hope either the proxy could determine my location (as it could in some networks) or it was willing to default route me so a human could ask. Put all of the above together, and I'll get closer to five nines than using any one of them. And I think the principle by which data inconsistency is resolved may be simpler than some people wins. In many, many cases "freshest data wins" is good enough. regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 22 20:37:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIbYu-0006Qv-Gi; Thu, 22 Sep 2005 20:37:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIbYu-0006Qq-0I for ecrit@megatron.ietf.org; Thu, 22 Sep 2005 20:37:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15880 for ; Thu, 22 Sep 2005 20:37:10 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIbfC-0004RL-T4 for ecrit@ietf.org; Thu, 22 Sep 2005 20:43:45 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j8N0ZrPP021369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Sep 2005 20:36:06 -0400 (EDT) Message-ID: <43334DE9.5010307@cs.columbia.edu> Date: Thu, 22 Sep 2005 20:35:53 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [Ecrit] draft-polk-dhc-uri-00 References: <200509222216.SAA29634@ietf.org> In-Reply-To: <200509222216.SAA29634@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Learning the location of mapping servers seems well within the overall scope of ECRIT. However, depending on the architecture, DHCP may or may not be the right approach for that and it will probably be hard to tell until the mapping mechanisms have gelled a bit more. Thus, I'm not convinced that the DHCP mechanism proposed currently addresses any ECRIT charter items, unless this is indeed proposed as a mapping protocol. For the reasons others and I stated earlier, I have serious concerns about the protocol as a mechanism to learn PSAP identities: - serious security vulnerabilities that a non-deployed shared-key algorithm does not address and that differ significantly from other uses of DHCP; - undefined caching and lifetime definitions that make it hard to predict what kind of information end systems will be getting when and when stale information will be "flushed" from the system; - additional implementation and method-selection effort; - if systems attempt to use both a mapping protocol and DHCP, the complexity of dealing with conflicts; - the difficulty of supporting additional PSAP URIs for service-specific URIs (mountain rescue, etc.), with another namespace to manage; - the lack of generality that makes it difficult to apply this mapping mechanism to other location-to-URI problems. I suspect that some of these issues can be addressed by clarifying the description, but some of the issues seem fundamental in having a second approach. We already have a mechanism to have end systems delegate resolution to third parties, namely by having the outbound proxy perform the mapping. As a procedural matter, I don't think it is incumbent upon the working group to demonstrate that a protocol does not work or does not work well in its current form, but rather for the authors to demonstrate that the proposal addresses agreed-upon requirements. Henning Brian Rosen wrote: > This draft provides a mechanism to return URIs from DHCP. Here in ecrit, > one we would have interest in is the PSAP URI(s). > > James proposes that we support the notion of a PSAP URI being returned from > DHCP. > > There has been a lot of discussion on this one on the list. Before we go > any farther, would it be appropriate to ask who else on this list thinks > this is a good idea? If there is a lot of support, then we can get into > details. If there isn't a lot of support, then we don't have to spend time > on it. > > Please note that, as I understand it, James is NOT proposing that DHCP be > considered a candidate for the protocol to perform the mapping between > location and the URI of a PSAP. He is proposing that DHCP be one of several > mechanisms that could be used to tell an endpoint what the result of mapping > would be. I'm guessing that the DHCP server (or something connected to it) > would use the mapping protocol to map location to PSAP URI, and deliver the > result to the endpoint. > > My personal opinion is that this is not a good idea, that we don't want > another mechanism between the mapping protocol and the end device, and that > DHCP is not an appropriate protocol to deliver the URI of the PSAP. Among > other reasons, unless we mandated that DHCP is the only way an endpoint > finds out the URI of a PSAP, then every endpoint that looked for this DHCP > option would have to implement at least one other way to get it. To me, > that makes this idea pretty worthless. > > Brian > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 22 20:55:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIbqC-0002M5-EO; Thu, 22 Sep 2005 20:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIbqA-0002K8-5p for ecrit@megatron.ietf.org; Thu, 22 Sep 2005 20:55:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16559 for ; Thu, 22 Sep 2005 20:55:00 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIbwT-0004qe-D3 for ecrit@ietf.org; Thu, 22 Sep 2005 21:01:35 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8N0sRoV028207; Thu, 22 Sep 2005 17:54:28 -0700 (PDT) Received: from [192.168.1.4] (vpn-10-50-16-18.qualcomm.com [10.50.16.18]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8N0sP7S013044; Thu, 22 Sep 2005 17:54:26 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <43334DE9.5010307@cs.columbia.edu> References: <200509222216.SAA29634@ietf.org> <43334DE9.5010307@cs.columbia.edu> Date: Thu, 22 Sep 2005 17:54:22 -0700 To: Henning Schulzrinne , br@brianrosen.net From: Ted Hardie Subject: Re: [Ecrit] draft-polk-dhc-uri-00 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 8:35 PM -0400 9/22/05, Henning Schulzrinne wrote: >For the reasons others and I stated earlier, I have serious concerns about the protocol as a mechanism to learn PSAP identities: >- serious security vulnerabilities that a non-deployed shared-key algorithm does not address and that differ significantly from other uses of DHCP; > >- undefined caching and lifetime definitions that make it hard to predict what kind of information end systems will be getting when and when stale information will be "flushed" from the system; This is why I believe we need to drill down to details. If, for example, the system told you what the local tel: URI was for emergency calls (tel:911, tel:999, tel:112, etc.), there is some marginal utility there and the likelihood of the information being stale without a location change is nil. For some constructions of psap URIs, the same might be true; for others they are not. It depends on the scheme, the deployment scenario, etc. None of this changes the basic principle that having some data is having no data. As long as fresher data/data derived from a mapping protocol is known to kick this out, then I think we're still better off. The "complexity" of reconciling is still up to us to specify, and I think with some models we can do well here. But without the discussing the details, we don't know how well the tool fits. The URIs carried in DHCP mechanism is very, very general. Unless the mechanism used here gets specified in more detail, the question of suitability will always get answered "it depends". My personal take and 2 cents, regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 22 21:08:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIc3G-0005PB-Hv; Thu, 22 Sep 2005 21:08:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIc3F-0005OH-0I for ecrit@megatron.ietf.org; Thu, 22 Sep 2005 21:08:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17063 for ; Thu, 22 Sep 2005 21:08:31 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIc9Y-0005Ay-7i for ecrit@ietf.org; Thu, 22 Sep 2005 21:15:06 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j8N18TYm025617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Sep 2005 21:08:29 -0400 (EDT) Message-ID: <4333558F.9090202@cs.columbia.edu> Date: Thu, 22 Sep 2005 21:08:31 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom-PT Taylor Subject: Re: [Ecrit] Comments on ecrit-requirements-00 section 6: Emergency Identifier References: <43320517.90703@nortel.com> <4332B191.6080303@cs.columbia.edu> <4332B8F2.3040302@nortel.com> In-Reply-To: <4332B8F2.3040302@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tom-PT Taylor wrote: > [PTT] Agreed. Is this covered by A3? Beyond that, I was asking if > people even saw a requirement for marking messages beyond the initial > message. I currently do not see a requirement, although several of the alternatives proposed will make it almost harder *not* to do this. >> > [PTT] Hmm. Maybe another requirement, but it's tough to implement once > the call is in the network. The general idea is clearly that for any > call-initiating signalling containing the emergency indication, the > address to which the call is being directed MUST be consistent with an > emergency destination. The question is, if an inconsistency is found, is > the call rejected, redirected to a PSAP, or is the emergency indicator > cleared? A reasonable argument can be made that a provider should only reject the call if it actually costs them money. There have been proposals for using 800# for PSAPs in some cases, for example, and you wouldn't want to accidentally reject such a call. Also, this is only a problem if the call is un-authenticated. In most residential cases, all calls will be authenticated, so you'd have to have a combination of factors to have things go wrong: - mapping check fails - no authentication available (so that you have to invoke special treatment) - call is to a PSTN number (rather than an on-net call) - which is not a freephone number For i3, this combination should not happen since one wouldn't call regular PSTN numbers except through an ESGW. > >>> >>> ------------ >>> >>> A1b: Universal identifier -- mapping. >>> I'm not sure what this requirement is saying as written. The >>> motivation suggests that the requirement is that signalling must >>> contain an indication that it is associated with an emergency call, >>> that is recognizable by any device in the signalling path that is >>> capable of invoking the mapping service. >>> > [PTT] It would be good to know that I have understood this one > correctly. If so, I'll offer alternative text to make it more clear. This may well overlap strongly with A1a. The idea is that any call routing entity (SIP proxy) in the call path may need to do mapping and thus be able to recognize when that should happen (for emergency calls only). > [PTT] Do people see this as a real requirement? The mapping protocol proposals all seem to have some indication of the (emergency) service required, which seems to cover that need. >> > [PTT] Instead of "dummy emergency address" how about "logical emergency > address" then? Works, or "emergency service identifier". I hate to add yet more something-addresses to the stew and this is something that identifies the service rather than allows you to (directly) get to it. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 22 21:15:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIc9Z-0006jf-IR; Thu, 22 Sep 2005 21:15:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIc9X-0006hl-Mm for ecrit@megatron.ietf.org; Thu, 22 Sep 2005 21:15:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17451 for ; Thu, 22 Sep 2005 21:15:02 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIcFr-0005Rk-0U for ecrit@ietf.org; Thu, 22 Sep 2005 21:21:37 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j8N1EtgM022549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Sep 2005 21:14:55 -0400 (EDT) Message-ID: <4333570D.70205@cs.columbia.edu> Date: Thu, 22 Sep 2005 21:14:53 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Ecrit] draft-polk-dhc-uri-00 References: <200509222216.SAA29634@ietf.org> <43334DE9.5010307@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Ted Hardie wrote: > This is why I believe we need to drill down to details. If, for example, the system > told you what the local tel: URI was for emergency calls (tel:911, tel:999, tel:112, > etc.), there is some marginal utility there and the likelihood of the information being This idea has popped up in the past and isn't really related to the DHCP discussion, but... I don't think this is a workable idea. The DHCP server has no idea what proxy server is going to resolve tel URIs for me. If I use sipgate.de as my VSP and my Verizon DHCP server tells me to use tel:911, I suspect that this is not going to work very well when my SIP request hits the proxy somewhere in Munich. If the proxy server is specified somehow and known to be local to the caller, there is no advantage here - the end system might as well just have the proxy server resolve the SIP request, marked as an emergency call, to the appropriate number or SIP URI. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 22 21:49:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIchI-00071C-Ah; Thu, 22 Sep 2005 21:49:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIchF-0006yT-WC for ecrit@megatron.ietf.org; Thu, 22 Sep 2005 21:49:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18659 for ; Thu, 22 Sep 2005 21:49:52 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIcna-0006Kg-JH for ecrit@ietf.org; Thu, 22 Sep 2005 21:56:27 -0400 Received: from [10.0.1.100] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 22 Sep 2005 21:49:48 -0400 id 000C7E72.43335F3C.00005BF8 In-Reply-To: <200509222216.SAA29634@ietf.org> References: <200509222216.SAA29634@ietf.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] draft-polk-dhc-uri-00 Date: Thu, 22 Sep 2005 21:49:46 -0400 To: br@brianrosen.net X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 22, 2005, at 6:15 PM, Brian Rosen wrote: > My personal opinion is that this is not a good idea, that we don't > want > another mechanism between the mapping protocol and the end device, > and that > DHCP is not an appropriate protocol to deliver the URI of the > PSAP. Among > other reasons, unless we mandated that DHCP is the only way an > endpoint > finds out the URI of a PSAP, then every endpoint that looked for > this DHCP > option would have to implement at least one other way to get it. > To me, > that makes this idea pretty worthless. Why is it that the lack of DHCPs ubiquity is acceptable for the sighting of location information, which is key to the success of the LCMS, but this same protocol must be ubiquitous in order for it to be used for an optional optimization? As for there being multiple methods to obtain this information, that is already the case today with location information. Why is this not a problem, especially given that location information is essential to the entire premise of this working groups output? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 23 08:27:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EImeU-0005Yj-FJ; Fri, 23 Sep 2005 08:27:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EImeS-0005YY-R4 for ecrit@megatron.ietf.org; Fri, 23 Sep 2005 08:27:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11377 for ; Fri, 23 Sep 2005 08:27:38 -0400 (EDT) Message-Id: <200509231227.IAA11377@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EImkq-000599-HJ for ecrit@ietf.org; Fri, 23 Sep 2005 08:34:19 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EIme7-0003A8-C8; Fri, 23 Sep 2005 07:27:20 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] draft-polk-dhc-uri-00 Date: Fri, 23 Sep 2005 08:25:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW/4RTzSSG4+bt9RWSsJDyzCLhEGgAUSK+w 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: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I deeply deplore the location determination situation we find ourselves in. It is my opinion that the IETF (I suspect that means geopriv) should state that the only acceptable protocol for getting location into the endpoint is DHCP, and if you manually provision an IP address you could either use DHCP for location anyway or manually provision location. DHCP will work in every circumstance. LLDP-MED, in my opinion, is 100% duplicative, and should not be deployed. It changes the element that reports location to be one which is closer to the endpoint. While that is a positive thing, the negatives of two options outweigh the positive. LLDP-MED is only really suitable for deployment in enterprise situations where managed Ethernet switches face the endpoints, but manufactures of endpoints don't know if they will be used in a home or an enterprise. DHCP is suitable in every environment for endpoints. Home routers may need some protocol to get location that isn't DHCP so they can give location to endpoints via DHCP, but we don't have to implement that in every endpoint. In my opinion, HELD is a very large mistake being pushed for a poor reason: the installed base of home routers for which in the field upgrade of firmware is deemed to be so difficult that the promoters of L7 protocols believe every phone from now till the next big thing should need a third protocol. That is, again in my opinion, erroneous, and we should decline to standardize an L7 location determination protocol. I have no illusions that my opinions as expressed above are prevalent enough that we will in fact do what I suggest. I'm advising endpoint manufacturers that all phones will need to implement all three protocols. That is stupid, but it's reality. I've probably committed an error raising these issues on this thread in this venue as we should argue the above in geopriv, but I've said this before, and we're still spending lots of time on them so rough consensus is not going my way :( However to repeat this mistake in the mapping side is wrong. All of the proposed protocols for mapping are simple enough that endpoints can implement them directly. We'll choose one, and that's it, we don't need anything else. Having other options forces all endpoints into more code, for no good reason. Having one protocol makes life simpler for everyone. With this particular one (DHCP for mapping determination), endpoints have to implement the mapping protocol directly, and having done so, should choose to use it, because the DHCP mechanism is another intermediary that would have to implement the mapping protocol, and it can fail. It adds no value; the endpoint can duplicate the function itself, and in fact, since it doesn't know if the DHCP option will be available, HAS to duplicate the functionality. If this was proposed as the ONLY mechanism, then I'd have fewer problems. In fact if DHCP was the only location determination mechanism, and this was the only mapping determination protocol, then I would be fairly happy. Folks, you CAN query DHCP at call time. You can query DHCP any time. DHCP is fast. I'm not worried about DHCP as a protocol; I just don't want any options where we don't need any, because of the effect on hundreds or thousands of endpoint designs. I'm a little more worried about robustness, we don't design DHCP servers to be ultra reliable. However, I suspect if your DHCP server is down, you can't do much of anything anyway, and the cached value is likely to be good anyways even if I don't want to rely on it. Brian -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Thursday, September 22, 2005 9:50 PM To: br@brianrosen.net Cc: 'James M. Polk'; 'ECRIT' Subject: Re: [Ecrit] draft-polk-dhc-uri-00 On Sep 22, 2005, at 6:15 PM, Brian Rosen wrote: > My personal opinion is that this is not a good idea, that we don't > want > another mechanism between the mapping protocol and the end device, > and that > DHCP is not an appropriate protocol to deliver the URI of the > PSAP. Among > other reasons, unless we mandated that DHCP is the only way an > endpoint > finds out the URI of a PSAP, then every endpoint that looked for > this DHCP > option would have to implement at least one other way to get it. > To me, > that makes this idea pretty worthless. Why is it that the lack of DHCPs ubiquity is acceptable for the sighting of location information, which is key to the success of the LCMS, but this same protocol must be ubiquitous in order for it to be used for an optional optimization? As for there being multiple methods to obtain this information, that is already the case today with location information. Why is this not a problem, especially given that location information is essential to the entire premise of this working groups output? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 23 08:53:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIn3m-0003Vc-91; Fri, 23 Sep 2005 08:53:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIn3j-0003VU-On for ecrit@megatron.ietf.org; Fri, 23 Sep 2005 08:53:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12425 for ; Fri, 23 Sep 2005 08:53:46 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EInAA-0005kN-81 for ecrit@ietf.org; Fri, 23 Sep 2005 09:00:27 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j8NCrjMQ018003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 23 Sep 2005 08:53:45 -0400 (EDT) Message-ID: <4333FAC6.2020904@cs.columbia.edu> Date: Fri, 23 Sep 2005 08:53:26 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'ecrit@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: [Ecrit] 911 and location story 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 http://www.nytimes.com/2005/09/23/nyregion/23stab.html Only vaguely relevant to our discussions, but an indication of some of the issues in handling 911 calls today. "Mr. Eason said the caller provided an incorrect address about a block away from the three-story apartment building where the killings took place. When the officers who were dispatched to the wrong location called Mr. Andrews' cellphone number to verify the address, no one answered, he said." "When the second call came in on Tuesday night, Mr. Eason said, a dispatcher transferred the call to a district precinct, but the caller hung up before the transfer was completed. Because Mr. Andrews used a cellphone to alert authorities, the police were not able to pinpoint his location, Mr. Eason said. The 911 calls were first reported in The Jersey Journal on Thursday." _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 23 09:58:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIo4L-0002L8-Vs; Fri, 23 Sep 2005 09:58:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIo4K-0002L3-9U for ecrit@megatron.ietf.org; Fri, 23 Sep 2005 09:58:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15480 for ; Fri, 23 Sep 2005 09:58:26 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIoAl-0007MU-Q9 for ecrit@ietf.org; Fri, 23 Sep 2005 10:05:08 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Sep 2005 09:58:18 -0400 X-IronPort-AV: i="3.97,141,1125892800"; d="scan'208"; a="71508665:sNHT30120200" Received: from [68.50.138.194] (che-vpn-cluster-2-146.cisco.com [10.86.242.146]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8NDwFQl003642; Fri, 23 Sep 2005 09:58:16 -0400 (EDT) In-Reply-To: <200509231227.IAA11377@ietf.org> References: <200509231227.IAA11377@ietf.org> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2568b6f4f29bdc84e42e1ca0c12fbca2@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit] draft-polk-dhc-uri-00 Date: Fri, 23 Sep 2005 09:58:10 -0400 To: br@brianrosen.net X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, I suspect that you have misinterpreted the extended discussion exploring alternatives as diverging opinions. I mostly agree with what you say here - minor clarifying comments embedded in context. It is possible that we already have "rough" consensus on the set of conclusions you collected here. There are, of course, particular advocates of other views, but I have seen no coherent alternative collection. On Sep 23, 2005, at 8:25 AM, Brian Rosen wrote: > I deeply deplore the location determination situation we find > ourselves in. > It is my opinion that the IETF (I suspect that means geopriv) should > state > that the only acceptable protocol for getting location into the > endpoint is > DHCP, and if you manually provision an IP address you could either use > DHCP > for location anyway or manually provision location. DHCP will work in > every > circumstance. The above conclusion is for the case where the host gets its location from the network. There is no prohibition on the likely case where (especially mobile) hosts know their location by other means such as GPS or Galileo. > LLDP-MED, in my opinion, is 100% duplicative, and should not be > deployed. > It changes the element that reports location to be one which is closer > to > the endpoint. While that is a positive thing, the negatives of two > options > outweigh the positive. LLDP-MED is only really suitable for > deployment in > enterprise situations where managed Ethernet switches face the > endpoints, > but manufactures of endpoints don't know if they will be used in a > home or > an enterprise. > > DHCP is suitable in every environment for endpoints. Home routers may > need > some protocol to get location that isn't DHCP so they can give > location to > endpoints via DHCP, but we don't have to implement that in every > endpoint. This is compatible with PPPoE and PPPoATM which uses PPP rather than DHCP to assign attributes to the router. There is no reason that the Network Control Protocol (NCP) [RFC 1332] could not include a configuration option analogous to the option in RFC 3825 along with the IP address of the host (DSL router). The router can provide this location to the host using the dynamic host configuration protocol. > In my opinion, HELD is a very large mistake being pushed for a poor > reason: > the installed base of home routers for which in the field upgrade of > firmware is deemed to be so difficult that the promoters of L7 > protocols > believe every phone from now till the next big thing should need a > third > protocol. That is, again in my opinion, erroneous, and we should > decline to > standardize an L7 location determination protocol. Since the deployment of Internet telephony is in its infancy now, the majority of IP phones that will need the ability to provide their locations to emergency services are not deployed. The currently installed base is a tiny fraction of what is expected at general deployment, and should not interfere with designing the general solution around Internet standard protocols as much as possible. > I have no illusions that my opinions as expressed above are prevalent > enough > that we will in fact do what I suggest. I'm advising endpoint > manufacturers > that all phones will need to implement all three protocols. That is > stupid, > but it's reality. I've probably committed an error raising these > issues on > this thread in this venue as we should argue the above in geopriv, but > I've > said this before, and we're still spending lots of time on them so > rough > consensus is not going my way :( > > However to repeat this mistake in the mapping side is wrong. All of > the > proposed protocols for mapping are simple enough that endpoints can > implement them directly. We'll choose one, and that's it, we don't > need > anything else. Having other options forces all endpoints into more > code, for > no good reason. > > Having one protocol makes life simpler for everyone. With this > particular > one (DHCP for mapping determination), endpoints have to implement the > mapping protocol directly, and having done so, should choose to use it, > because the DHCP mechanism is another intermediary that would have to > implement the mapping protocol, and it can fail. It adds no value; the > endpoint can duplicate the function itself, and in fact, since it > doesn't > know if the DHCP option will be available, HAS to duplicate the > functionality. > > If this was proposed as the ONLY mechanism, then I'd have fewer > problems. > In fact if DHCP was the only location determination mechanism, and > this was > the only mapping determination protocol, then I would be fairly happy. > Folks, you CAN query DHCP at call time. You can query DHCP any time. > DHCP > is fast. I'm not worried about DHCP as a protocol; I just don't want > any > options where we don't need any, because of the effect on hundreds or > thousands of endpoint designs. I'm a little more worried about > robustness, > we don't design DHCP servers to be ultra reliable. However, I suspect > if > your DHCP server is down, you can't do much of anything anyway, and the > cached value is likely to be good anyways even if I don't want to rely > on > it. Well put. DHCP is not the problem. The problem with the subject proposal is inserting DHCP unnecessarily in the process. It is unhelpful to have hosts get information through DHCP that they can get as well or better otherwise because that information is not part of the local network environment. John _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 23 10:01:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIo7g-0002ux-NK; Fri, 23 Sep 2005 10:01:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIo7e-0002sk-EF for ecrit@megatron.ietf.org; Fri, 23 Sep 2005 10:01:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15737 for ; Fri, 23 Sep 2005 10:01:52 -0400 (EDT) From: g.caron@bell.ca Received: from bellwfep8.bellnexxia.net ([207.236.237.101] helo=bellwfep8-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIoE4-0007Ta-2S for ecrit@ietf.org; Fri, 23 Sep 2005 10:08:34 -0400 Received: from dm3cn8.bell.ca ([206.47.0.145]) by bellwfep8-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050923140137.KIGJ29452.bellwfep8-srv.bellnexxia.net@dm3cn8.bell.ca>; Fri, 23 Sep 2005 10:01:37 -0400 Received: from 142.182.84.162dm3cn8.bell.ca with ESMTP (Tumbleweed MMS SMTP Relay (MMS v5.0)); Fri, 23 Sep 2005 10:01:24 -0400 X-Server-Uuid: D4A4E604-913A-4A1B-8C07-2866D92AD410 Received: from toroondc912.bell.corp.bce.ca ([142.182.89.15]) by toroondc550.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Sep 2005 10:01:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE : [Ecrit] draft-polk-dhc-uri-00 Date: Fri, 23 Sep 2005 10:01:19 -0400 Message-ID: <2E62ACF8ADDB4D4F89093CBFDF2FBAF303A903F2@Toroondc912> Thread-Topic: [Ecrit] draft-polk-dhc-uri-00 Thread-Index: AcW/4RTzSSG4+bt9RWSsJDyzCLhEGgAUSK+wAAOEvRA= To: br@brianrosen.net, andy@hxr.us X-OriginalArrivalTime: 23 Sep 2005 14:01:19.0930 (UTC) FILETIME=[45FC49A0:01C5C047] X-WSS-ID: 6F2AD51111758265-16-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 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 Brian, I just joined this tread so if any of my comments have already been = provided by others and discussed, I apologise. The main reason why DHCP should NOT be the ONLY method for location = acquisition is because it would not work for a large portion of existing = broadband access infrastructures that do not use DHCP today (and don't = plan to), especially in the residential market. If you mean to have DHCP in the home network only (between IP device and = HG), this would still not address how the HG would acquire the location = in the first place. BTW, L7 solutions are not pushed only because of the reasons you = mentioned but also because of what I explained above. Who can claim to know what kind of L2 mechanisms (and mixes of) are = deployed in the world today? How can the IETF certify any L2 mechanism = (and mixes of) will work "out of the box" for any implementation? On the other hand, applications will always work. I would also claim = that applications are easier to develop and to evolve over time. Finally, the issue is not with location determination but rather with = location acquisition. The former uses local mechanisms proprietary to = the type of broadband access network the EP gets the service from. My 2 cents. P.S.: If this is not the right forum for this discussion, please direct = me to the right one. I would be happy to continue this further. Guy Caron -----Message d'origine----- De=A0: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] De la part = de Brian Rosen Envoy=E9=A0: 23 septembre 2005 08:26 =C0=A0: 'Andrew Newton' Cc=A0: 'ECRIT' Objet=A0: RE: [Ecrit] draft-polk-dhc-uri-00 I deeply deplore the location determination situation we find ourselves = in. It is my opinion that the IETF (I suspect that means geopriv) should = state that the only acceptable protocol for getting location into the endpoint = is DHCP, and if you manually provision an IP address you could either use = DHCP for location anyway or manually provision location. DHCP will work in = every circumstance. LLDP-MED, in my opinion, is 100% duplicative, and should not be = deployed. It changes the element that reports location to be one which is closer = to the endpoint. While that is a positive thing, the negatives of two = options outweigh the positive. LLDP-MED is only really suitable for deployment = in enterprise situations where managed Ethernet switches face the = endpoints, but manufactures of endpoints don't know if they will be used in a home = or an enterprise. =20 DHCP is suitable in every environment for endpoints. Home routers may = need some protocol to get location that isn't DHCP so they can give location = to endpoints via DHCP, but we don't have to implement that in every = endpoint. In my opinion, HELD is a very large mistake being pushed for a poor = reason: the installed base of home routers for which in the field upgrade of firmware is deemed to be so difficult that the promoters of L7 protocols believe every phone from now till the next big thing should need a third protocol. That is, again in my opinion, erroneous, and we should = decline to standardize an L7 location determination protocol. I have no illusions that my opinions as expressed above are prevalent = enough that we will in fact do what I suggest. I'm advising endpoint = manufacturers that all phones will need to implement all three protocols. That is = stupid, but it's reality. I've probably committed an error raising these issues = on this thread in this venue as we should argue the above in geopriv, but = I've said this before, and we're still spending lots of time on them so rough consensus is not going my way :( However to repeat this mistake in the mapping side is wrong. All of the proposed protocols for mapping are simple enough that endpoints can implement them directly. We'll choose one, and that's it, we don't need anything else. Having other options forces all endpoints into more code, = for no good reason. Having one protocol makes life simpler for everyone. With this = particular one (DHCP for mapping determination), endpoints have to implement the mapping protocol directly, and having done so, should choose to use it, because the DHCP mechanism is another intermediary that would have to implement the mapping protocol, and it can fail. It adds no value; the endpoint can duplicate the function itself, and in fact, since it = doesn't know if the DHCP option will be available, HAS to duplicate the functionality. =20 If this was proposed as the ONLY mechanism, then I'd have fewer = problems. In fact if DHCP was the only location determination mechanism, and this = was the only mapping determination protocol, then I would be fairly happy. Folks, you CAN query DHCP at call time. You can query DHCP any time. = DHCP is fast. I'm not worried about DHCP as a protocol; I just don't want = any options where we don't need any, because of the effect on hundreds or thousands of endpoint designs. I'm a little more worried about = robustness, we don't design DHCP servers to be ultra reliable. However, I suspect = if your DHCP server is down, you can't do much of anything anyway, and the cached value is likely to be good anyways even if I don't want to rely = on it. Brian -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Thursday, September 22, 2005 9:50 PM To: br@brianrosen.net Cc: 'James M. Polk'; 'ECRIT' Subject: Re: [Ecrit] draft-polk-dhc-uri-00 On Sep 22, 2005, at 6:15 PM, Brian Rosen wrote: > My personal opinion is that this is not a good idea, that we don't =20 > want > another mechanism between the mapping protocol and the end device, =20 > and that > DHCP is not an appropriate protocol to deliver the URI of the =20 > PSAP. Among > other reasons, unless we mandated that DHCP is the only way an =20 > endpoint > finds out the URI of a PSAP, then every endpoint that looked for =20 > this DHCP > option would have to implement at least one other way to get it. =20 > To me, > that makes this idea pretty worthless. Why is it that the lack of DHCPs ubiquity is acceptable for the =20 sighting of location information, which is key to the success of the =20 LCMS, but this same protocol must be ubiquitous in order for it to be =20 used for an optional optimization? As for there being multiple methods to obtain this information, that =20 is already the case today with location information. Why is this not =20 a problem, especially given that location information is essential to =20 the entire premise of this working groups output? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 23 10:02:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIo86-00037v-5l; Fri, 23 Sep 2005 10:02:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIo85-00037c-5g for ecrit@megatron.ietf.org; Fri, 23 Sep 2005 10:02:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15771 for ; Fri, 23 Sep 2005 10:02:19 -0400 (EDT) Received: from ns2.sccx.com ([209.108.197.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIoEV-0007Ug-Of for ecrit@ietf.org; Fri, 23 Sep 2005 10:09:01 -0400 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] draft-polk-dhc-uri-00 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 23 Sep 2005 09:01:52 -0500 Message-ID: <422D410BD61FC04185076AD99AA7207A0114372C@inilmx01.lgmt.trdo> Thread-Topic: [Ecrit] draft-polk-dhc-uri-00 Thread-Index: AcW/4RTzSSG4+bt9RWSsJDyzCLhEGgAUSK+wAAUnZ2A= From: "McCalmont, Patti" To: , "Andrew Newton" X-OriginalArrivalTime: 23 Sep 2005 14:01:53.0950 (UTC) FILETIME=[5A4353E0:01C5C047] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Wow.......guess we all know how you stand but......... even James Polk stated that one size won't fit all. HELD provides a solution for many other types of interfaces, such as Wireless as the mobile is moving. It does take care of the embedded base and it meets other Carrier needs. Probably not a surprise, but I don't agree at all with your statements. Patti -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, September 23, 2005 7:26 AM To: 'Andrew Newton' Cc: 'ECRIT' Subject: RE: [Ecrit] draft-polk-dhc-uri-00 I deeply deplore the location determination situation we find ourselves in. It is my opinion that the IETF (I suspect that means geopriv) should state that the only acceptable protocol for getting location into the endpoint is DHCP, and if you manually provision an IP address you could either use DHCP for location anyway or manually provision location. DHCP will work in every circumstance. LLDP-MED, in my opinion, is 100% duplicative, and should not be deployed. It changes the element that reports location to be one which is closer to the endpoint. While that is a positive thing, the negatives of two options outweigh the positive. LLDP-MED is only really suitable for deployment in enterprise situations where managed Ethernet switches face the endpoints, but manufactures of endpoints don't know if they will be used in a home or an enterprise. =20 DHCP is suitable in every environment for endpoints. Home routers may need some protocol to get location that isn't DHCP so they can give location to endpoints via DHCP, but we don't have to implement that in every endpoint. In my opinion, HELD is a very large mistake being pushed for a poor reason: the installed base of home routers for which in the field upgrade of firmware is deemed to be so difficult that the promoters of L7 protocols believe every phone from now till the next big thing should need a third protocol. That is, again in my opinion, erroneous, and we should decline to standardize an L7 location determination protocol. I have no illusions that my opinions as expressed above are prevalent enough that we will in fact do what I suggest. I'm advising endpoint manufacturers that all phones will need to implement all three protocols. That is stupid, but it's reality. I've probably committed an error raising these issues on this thread in this venue as we should argue the above in geopriv, but I've said this before, and we're still spending lots of time on them so rough consensus is not going my way :( However to repeat this mistake in the mapping side is wrong. All of the proposed protocols for mapping are simple enough that endpoints can implement them directly. We'll choose one, and that's it, we don't need anything else. Having other options forces all endpoints into more code, for no good reason. Having one protocol makes life simpler for everyone. With this particular one (DHCP for mapping determination), endpoints have to implement the mapping protocol directly, and having done so, should choose to use it, because the DHCP mechanism is another intermediary that would have to implement the mapping protocol, and it can fail. It adds no value; the endpoint can duplicate the function itself, and in fact, since it doesn't know if the DHCP option will be available, HAS to duplicate the functionality. =20 If this was proposed as the ONLY mechanism, then I'd have fewer problems. In fact if DHCP was the only location determination mechanism, and this was the only mapping determination protocol, then I would be fairly happy. Folks, you CAN query DHCP at call time. You can query DHCP any time. DHCP is fast. I'm not worried about DHCP as a protocol; I just don't want any options where we don't need any, because of the effect on hundreds or thousands of endpoint designs. I'm a little more worried about robustness, we don't design DHCP servers to be ultra reliable. However, I suspect if your DHCP server is down, you can't do much of anything anyway, and the cached value is likely to be good anyways even if I don't want to rely on it. Brian -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Thursday, September 22, 2005 9:50 PM To: br@brianrosen.net Cc: 'James M. Polk'; 'ECRIT' Subject: Re: [Ecrit] draft-polk-dhc-uri-00 On Sep 22, 2005, at 6:15 PM, Brian Rosen wrote: > My personal opinion is that this is not a good idea, that we don't =20 > want > another mechanism between the mapping protocol and the end device, =20 > and that > DHCP is not an appropriate protocol to deliver the URI of the =20 > PSAP. Among > other reasons, unless we mandated that DHCP is the only way an =20 > endpoint > finds out the URI of a PSAP, then every endpoint that looked for =20 > this DHCP > option would have to implement at least one other way to get it. =20 > To me, > that makes this idea pretty worthless. Why is it that the lack of DHCPs ubiquity is acceptable for the =20 sighting of location information, which is key to the success of the =20 LCMS, but this same protocol must be ubiquitous in order for it to be =20 used for an optional optimization? As for there being multiple methods to obtain this information, that =20 is already the case today with location information. Why is this not =20 a problem, especially given that location information is essential to =20 the entire premise of this working groups output? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 23 10:19:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIoO2-0008Ey-Jt; Fri, 23 Sep 2005 10:18:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIoO0-0008EU-7J for ecrit@megatron.ietf.org; Fri, 23 Sep 2005 10:18:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17503 for ; Fri, 23 Sep 2005 10:18:46 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIoUP-0007wc-Tp for ecrit@ietf.org; Fri, 23 Sep 2005 10:25:28 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Sep 2005 07:18:35 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,141,1125903600"; d="scan'208"; a="10974742:sNHT20433780" Received: from [68.50.138.194] (che-vpn-cluster-2-146.cisco.com [10.86.242.146]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8NEIWT6000974; Fri, 23 Sep 2005 10:18:32 -0400 (EDT) In-Reply-To: <2E62ACF8ADDB4D4F89093CBFDF2FBAF303A903F2@Toroondc912> References: <2E62ACF8ADDB4D4F89093CBFDF2FBAF303A903F2@Toroondc912> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9aae18a36e4f6a1ae8c37371738fd30c@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: RE : [Ecrit] draft-polk-dhc-uri-00 Date: Fri, 23 Sep 2005 10:18:27 -0400 To: g.caron@bell.ca X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The best forum to discuss HELD is the GeoPriv Working Group, where several issues with it have been raised. John On Sep 23, 2005, at 10:01 AM, g.caron@bell.ca wrote: > > ... > BTW, L7 solutions are not pushed only because of the reasons you > mentioned but also because of what I explained above. > > Who can claim to know what kind of L2 mechanisms (and mixes of) are > deployed in the world today? How can the IETF certify any L2 mechanism > (and mixes of) will work "out of the box" for any implementation? > > On the other hand, applications will always work. I would also claim > that applications are easier to develop and to evolve over time. > ... > P.S.: If this is not the right forum for this discussion, please > direct me to the right one. I would be happy to continue this further. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 23 10:20:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIoPx-00007a-GK; Fri, 23 Sep 2005 10:20:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIoPw-00007S-Cp for ecrit@megatron.ietf.org; Fri, 23 Sep 2005 10:20:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17708 for ; Fri, 23 Sep 2005 10:20:46 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIoWN-00080P-0N for ecrit@ietf.org; Fri, 23 Sep 2005 10:27:28 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Sep 2005 07:20:37 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,141,1125903600"; d="scan'208"; a="10975072:sNHT19769392" Received: from [68.50.138.194] (che-vpn-cluster-2-146.cisco.com [10.86.242.146]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8NEKYT6001491; Fri, 23 Sep 2005 10:20:34 -0400 (EDT) In-Reply-To: <422D410BD61FC04185076AD99AA7207A0114372C@inilmx01.lgmt.trdo> References: <422D410BD61FC04185076AD99AA7207A0114372C@inilmx01.lgmt.trdo> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit] draft-polk-dhc-uri-00 Date: Fri, 23 Sep 2005 10:20:33 -0400 To: "McCalmont, Patti" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Wouldn't it be reasonable to keep the discussion of the issues and claims with HELD in the GeoPriv WG where it has been? We should not recapitulate that in this WG also. John On Sep 23, 2005, at 10:01 AM, McCalmont, Patti wrote: > Wow.......guess we all know how you stand but......... even James Polk > stated that one size won't fit all. HELD provides a solution for many > other types of interfaces, such as Wireless as the mobile is moving. It > does take care of the embedded base and it meets other Carrier needs. > Probably not a surprise, but I don't agree at all with your statements. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 23 10:26:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIoVP-0002OI-UR; Fri, 23 Sep 2005 10:26:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIoVO-0002NI-FE for ecrit@megatron.ietf.org; Fri, 23 Sep 2005 10:26:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18296 for ; Fri, 23 Sep 2005 10:26:24 -0400 (EDT) From: mhammer@cisco.com Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIobo-0008AK-34 for ecrit@ietf.org; Fri, 23 Sep 2005 10:33:06 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 23 Sep 2005 07:26:13 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8NEPo4l010076; Fri, 23 Sep 2005 07:26:11 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Sep 2005 10:26:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] draft-polk-dhc-uri-00 Date: Fri, 23 Sep 2005 10:26:04 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E395B427@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] draft-polk-dhc-uri-00 Thread-Index: AcW/3JBaSem9kwEjTeanY4rxJUHU4wAbBbvw To: "Henning Schulzrinne" , "Ted Hardie" X-OriginalArrivalTime: 23 Sep 2005 14:26:06.0614 (UTC) FILETIME=[BC1E4360:01C5C04A] X-Spam-Score: 0.3 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Henning, There are three assertions that I will make that seem to favor the use of DHCP as part of the solution: Robustness in the face of partial network failure: Why is it that we promote pushing the intelligence to the edge as a means of improving reliability, yet in this case, where crucial data could be pushed/pulled in advance of an emergency to a point local in the network to the endpoint that needs it, we seem to be saying no, it is better to centralize this distantly in the network somewhere? Closely related dependencies: We seem to acknowledge that the key to determining where to route the call is based on the location information that is local to the network point of attachment and that local mechanisms are good enough to deliver that information to the caller, but that those same mechanisms are somehow insufficient to deliver derived information based on that location. Subsequent correctability by the application proxies: Independent of what the client does in terms of initiating a call, the application servers always have the ability to override and re-route the call if they know the information that the client had and have better (more current) information derived from their own sources. The design of the network needs to account for multiple possible failure points, including the location and mapping services themselves. There is a time dimension to this that suggests that at the time of the call, the dependencies may be more reliable if they share the same fate as the client, i.e. local to the client versus having multiple possible failure points between the client and the relied on element/data. Let's not design in single points of failure. Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Henning Schulzrinne > Sent: Thursday, September 22, 2005 9:15 PM > To: Ted Hardie > Cc: 'ECRIT' > Subject: Re: [Ecrit] draft-polk-dhc-uri-00 >=20 > Ted Hardie wrote: >=20 > > This is why I believe we need to drill down to details. If, for=20 > > example, the system told you what the local tel: URI was=20 > for emergency=20 > > calls (tel:911, tel:999, tel:112, etc.), there is some marginal=20 > > utility there and the likelihood of the information being >=20 > This idea has popped up in the past and isn't really related=20 > to the DHCP discussion, but... >=20 > I don't think this is a workable idea. The DHCP server has no=20 > idea what proxy server is going to resolve tel URIs for me.=20 > If I use sipgate.de as my VSP and my Verizon DHCP server=20 > tells me to use tel:911, I suspect that this is not going to=20 > work very well when my SIP request hits the proxy somewhere in Munich. >=20 > If the proxy server is specified somehow and known to be=20 > local to the caller, there is no advantage here - the end=20 > system might as well just have the proxy server resolve the=20 > SIP request, marked as an emergency call, to the appropriate=20 > number or SIP URI. >=20 > Henning >=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 Sep 23 11:00:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIp2W-0002BG-Dr; Fri, 23 Sep 2005 11:00:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIp2U-0002BB-U0 for ecrit@megatron.ietf.org; Fri, 23 Sep 2005 11:00:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20059 for ; Fri, 23 Sep 2005 11:00:37 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIp8x-0000VB-CW for ecrit@ietf.org; Fri, 23 Sep 2005 11:07:19 -0400 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 j8NExIWk000752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Sep 2005 10:59:19 -0400 (EDT) Message-ID: <43341821.6050703@cs.columbia.edu> Date: Fri, 23 Sep 2005 10:58:41 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mhammer@cisco.com Subject: Re: [Ecrit] draft-polk-dhc-uri-00 References: <072C5B76F7CEAB488172C6F64B30B5E395B427@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E395B427@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Mike, I would certainly not be in favor of a design with a single point of failure. Indeed, I had previously argued (and written up) a design that encourages local caching of mapping information. You may remember the long and arduous discussions on 'minimal connectivity'. Thus, I'm in favor of designing a mapping protocol that is caching-friendly, but that allows predictable caching behavior to make it easy to predict who is going to see what information. It is very difficult to do that if there are all kinds of less-than-deterministic paths of information flow, using an unknown (to the data source) variety of delivery protocols that cannot convey, for example, TTL information or may disagree about the meaning of that information. In other words, introducing this extra mechanism is not necessary for local information retrieval, but seems to make it less predictable and less robust. We have experience with same-protocol caching (e.g., in DNS and HTTP), but very little with multi-protocol caching. The closest analogy I can think of, largely outside my area of experience, is the IGP/EGP split in routing, where you sometimes need to propagate external routing information via an IGP such as OSPF. We do know that protocol translation is generally painful and may imply information loss. Sometimes there are strong reasons to do this, but I have yet to hear a reason why this is such a case. I have only heard lots of "we *could* do this" and "it's no worse than X". Inherently, more mechanism means more complexity, more fault scenarios and more interop testing, so there should be a strong motivation ("can't reasonably do it any other way") before adding more. Henning mhammer@cisco.com wrote: > Henning, > > There are three assertions that I will make that seem to favor the use > of DHCP as part of the solution: > > Robustness in the face of partial network failure: Why is it that we > promote pushing the intelligence to the edge as a means of improving > reliability, yet in this case, where crucial data could be pushed/pulled > in advance of an emergency to a point local in the network to the > endpoint that needs it, we seem to be saying no, it is better to > centralize this distantly in the network somewhere? > > Closely related dependencies: We seem to acknowledge that the key to > determining where to route the call is based on the location information > that is local to the network point of attachment and that local > mechanisms are good enough to deliver that information to the caller, > but that those same mechanisms are somehow insufficient to deliver > derived information based on that location. > > Subsequent correctability by the application proxies: Independent of > what the client does in terms of initiating a call, the application > servers always have the ability to override and re-route the call if > they know the information that the client had and have better (more > current) information derived from their own sources. > > The design of the network needs to account for multiple possible failure > points, including the location and mapping services themselves. There > is a time dimension to this that suggests that at the time of the call, > the dependencies may be more reliable if they share the same fate as the > client, i.e. local to the client versus having multiple possible failure > points between the client and the relied on element/data. > > Let's not design in single points of failure. > > Mike > > > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>On Behalf Of Henning Schulzrinne >>Sent: Thursday, September 22, 2005 9:15 PM >>To: Ted Hardie >>Cc: 'ECRIT' >>Subject: Re: [Ecrit] draft-polk-dhc-uri-00 >> >>Ted Hardie wrote: >> >> >>>This is why I believe we need to drill down to details. If, for >>>example, the system told you what the local tel: URI was >> >>for emergency >> >>>calls (tel:911, tel:999, tel:112, etc.), there is some marginal >>>utility there and the likelihood of the information being >> >>This idea has popped up in the past and isn't really related >>to the DHCP discussion, but... >> >>I don't think this is a workable idea. The DHCP server has no >>idea what proxy server is going to resolve tel URIs for me. >>If I use sipgate.de as my VSP and my Verizon DHCP server >>tells me to use tel:911, I suspect that this is not going to >>work very well when my SIP request hits the proxy somewhere in Munich. >> >>If the proxy server is specified somehow and known to be >>local to the caller, there is no advantage here - the end >>system might as well just have the proxy server resolve the >>SIP request, marked as an emergency call, to the appropriate >>number or SIP URI. >> >>Henning >> >>_______________________________________________ >>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 Sep 23 12:23:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqKj-0006Kl-Pv; Fri, 23 Sep 2005 12:23:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqKi-0006Jg-KN for ecrit@megatron.ietf.org; Fri, 23 Sep 2005 12:23:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23643 for ; Fri, 23 Sep 2005 12:23:30 -0400 (EDT) Message-Id: <200509231623.MAA23643@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIqR9-0002Q5-OK for ecrit@ietf.org; Fri, 23 Sep 2005 12:30:14 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EIqKU-0006ii-QR; Fri, 23 Sep 2005 11:23:19 -0500 From: "Brian Rosen" To: "'John Schnizlein'" Subject: RE: [Ecrit] draft-polk-dhc-uri-00 Date: Fri, 23 Sep 2005 12:22:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <2568b6f4f29bdc84e42e1ca0c12fbca2@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXARtq9ZI8860z3RPObxTxhY/1/TAAFANqQ 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: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Agree in all respects. -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: Friday, September 23, 2005 9:58 AM To: br@brianrosen.net Cc: 'Andrew Newton'; 'ECRIT' Subject: Re: [Ecrit] draft-polk-dhc-uri-00 Brian, I suspect that you have misinterpreted the extended discussion exploring alternatives as diverging opinions. I mostly agree with what you say here - minor clarifying comments embedded in context. It is possible that we already have "rough" consensus on the set of conclusions you collected here. There are, of course, particular advocates of other views, but I have seen no coherent alternative collection. On Sep 23, 2005, at 8:25 AM, Brian Rosen wrote: > I deeply deplore the location determination situation we find > ourselves in. > It is my opinion that the IETF (I suspect that means geopriv) should > state > that the only acceptable protocol for getting location into the > endpoint is > DHCP, and if you manually provision an IP address you could either use > DHCP > for location anyway or manually provision location. DHCP will work in > every > circumstance. The above conclusion is for the case where the host gets its location from the network. There is no prohibition on the likely case where (especially mobile) hosts know their location by other means such as GPS or Galileo. > LLDP-MED, in my opinion, is 100% duplicative, and should not be > deployed. > It changes the element that reports location to be one which is closer > to > the endpoint. While that is a positive thing, the negatives of two > options > outweigh the positive. LLDP-MED is only really suitable for > deployment in > enterprise situations where managed Ethernet switches face the > endpoints, > but manufactures of endpoints don't know if they will be used in a > home or > an enterprise. > > DHCP is suitable in every environment for endpoints. Home routers may > need > some protocol to get location that isn't DHCP so they can give > location to > endpoints via DHCP, but we don't have to implement that in every > endpoint. This is compatible with PPPoE and PPPoATM which uses PPP rather than DHCP to assign attributes to the router. There is no reason that the Network Control Protocol (NCP) [RFC 1332] could not include a configuration option analogous to the option in RFC 3825 along with the IP address of the host (DSL router). The router can provide this location to the host using the dynamic host configuration protocol. > In my opinion, HELD is a very large mistake being pushed for a poor > reason: > the installed base of home routers for which in the field upgrade of > firmware is deemed to be so difficult that the promoters of L7 > protocols > believe every phone from now till the next big thing should need a > third > protocol. That is, again in my opinion, erroneous, and we should > decline to > standardize an L7 location determination protocol. Since the deployment of Internet telephony is in its infancy now, the majority of IP phones that will need the ability to provide their locations to emergency services are not deployed. The currently installed base is a tiny fraction of what is expected at general deployment, and should not interfere with designing the general solution around Internet standard protocols as much as possible. > I have no illusions that my opinions as expressed above are prevalent > enough > that we will in fact do what I suggest. I'm advising endpoint > manufacturers > that all phones will need to implement all three protocols. That is > stupid, > but it's reality. I've probably committed an error raising these > issues on > this thread in this venue as we should argue the above in geopriv, but > I've > said this before, and we're still spending lots of time on them so > rough > consensus is not going my way :( > > However to repeat this mistake in the mapping side is wrong. All of > the > proposed protocols for mapping are simple enough that endpoints can > implement them directly. We'll choose one, and that's it, we don't > need > anything else. Having other options forces all endpoints into more > code, for > no good reason. > > Having one protocol makes life simpler for everyone. With this > particular > one (DHCP for mapping determination), endpoints have to implement the > mapping protocol directly, and having done so, should choose to use it, > because the DHCP mechanism is another intermediary that would have to > implement the mapping protocol, and it can fail. It adds no value; the > endpoint can duplicate the function itself, and in fact, since it > doesn't > know if the DHCP option will be available, HAS to duplicate the > functionality. > > If this was proposed as the ONLY mechanism, then I'd have fewer > problems. > In fact if DHCP was the only location determination mechanism, and > this was > the only mapping determination protocol, then I would be fairly happy. > Folks, you CAN query DHCP at call time. You can query DHCP any time. > DHCP > is fast. I'm not worried about DHCP as a protocol; I just don't want > any > options where we don't need any, because of the effect on hundreds or > thousands of endpoint designs. I'm a little more worried about > robustness, > we don't design DHCP servers to be ultra reliable. However, I suspect > if > your DHCP server is down, you can't do much of anything anyway, and the > cached value is likely to be good anyways even if I don't want to rely > on > it. Well put. DHCP is not the problem. The problem with the subject proposal is inserting DHCP unnecessarily in the process. It is unhelpful to have hosts get information through DHCP that they can get as well or better otherwise because that information is not part of the local network environment. John _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 23 16:08:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EItqW-0000gQ-H2; Fri, 23 Sep 2005 16:08:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EItqT-0000fZ-GB for ecrit@megatron.ietf.org; Fri, 23 Sep 2005 16:08:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06864 for ; Fri, 23 Sep 2005 16:08:31 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EItwv-00009a-Aa for ecrit@ietf.org; Fri, 23 Sep 2005 16:15:16 -0400 Received: by zproxy.gmail.com with SMTP id l1so737312nzf for ; Fri, 23 Sep 2005 13:08:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=mzs2uxTuWwZw1uDAnFeC679l+yVZICC/7YkKJS6Ry++WMVImOGXC/SruQVh1xOZSRw5SWiFD/kFhBBlWAvIgQLl8XjPcfxdnY6UrzrnH2xUF5QYYm6ueu1rHj58xrk29w8T5iROY7CsyTWNaFZkEaDY4CDek2dcjs74GZl9Mx/M= Received: by 10.36.17.20 with SMTP id 20mr918690nzq; Fri, 23 Sep 2005 13:08:19 -0700 (PDT) Received: by 10.36.58.9 with HTTP; Fri, 23 Sep 2005 13:08:19 -0700 (PDT) Message-ID: <181f29c05092313081c0f50aa@mail.gmail.com> Date: Fri, 23 Sep 2005 16:08:19 -0400 From: Nate Wilcox To: "James M. Polk" Subject: Re: [Ecrit] Timing of PSAPs changing coverage areas In-Reply-To: <4.3.2.7.2.20050920233212.03740680@email.cisco.com> MIME-Version: 1.0 References: <4.3.2.7.2.20050920233212.03740680@email.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nate Wilcox List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0088522540==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============0088522540== Content-Type: multipart/alternative; boundary="----=_Part_1082_30383116.1127506099549" ------=_Part_1082_30383116.1127506099549 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sorry I did not pick up on this thread sooner. As a former PSAP type person I can tell you that in the State of Vermont over the last 7 years we have had 5 significant PSAP reconfigurations that involved re-routing of calls t= o new permanent locations. However, using historical references to determine this is not going to help. Their is a shift afoot right now towards dispatch/PSAP consolidation and the rate of change could increase exponentially particularly as new funding mechanisms in pursuit of better disaster preparedness becomes available for this specific purpose. I would also add that bringing new PSAP's on line and decommisioing old ones will become more common place as old cumbersome legacy gear gets replaced by mor= e capable, less complex systems. Nate Wilcox On 9/21/05, James M. Polk wrote: > > Tim > > This is a good example, and one that SIP covers already, as time-of-day > routing is a piece of cake to a SIP Proxy. > > At 03:34 PM 9/20/2005 -0600, Tim Dunn wrote: > >James- > > > >In certain parts of the US (generally rural, but I think there are also > some > >urban examples), I am aware of local police departments that answer thei= r > >emergency calls between 8am and 5pm. At other times the calls are routed > to > >a county or state level center that is a 24x7 operation. So the answer t= o > >your question would be that routing changes can occur daily in some > places. > > > > > >In the legacy circuit switched environment, there is generally a way to > busy > >out the inbound emergency trunks, allowing for routing of calls to > another > >location. In my example above, the local PSAP throws a switch and the > calls > >now route to an alternate location. > > > >This is also, in general, how trunk busyouts occur if a PSAP needs to > >quickly vacate and you want the calls routed elsewhere. My experience wa= s > >that there were switches at the PSAP, at the central office (to busy out > the > >trunks) and sometimes at a local backup PSAP (unbusying those trunks to > >begin accepting calls). If you had your primary and backup location out > of > >business, there are switch level instructions on where to route. > > > >Tim Dunn > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf O= f > >James M. Polk > >Sent: Tuesday, September 20, 2005 2:56 PM > >To: ecrit@ietf.org > >Subject: [Ecrit] Timing of PSAPs changing coverage areas > > > >All > > > >I've heard and read the statements and requirements from folks that the > >routing of a call to a PSAP needs to be as fresh as possible because a > >particular PSAP might have moved, or more accurately, that a location > might > >be served "on a moment's notice" by a different PSAP. > > > >I'd like to ask how often this happens today. Does anyone know how often > a > >location needs to contact a different PSAP than its normal/standard one? > > > >It seems to me that a lot of us might be imagining a worse-case scenario > >that we need to design protocols for, and that this worse-case scenario > >happens often. If this is, say only 0.01% of the time - or even under 5% > of > >all emergency calls (2 standard deviations, or SDs), I'm thinking we're > >focusing too much energy on solving something that is a statistical > >"outlier". > > > >Today's emergency systems aren't build for 2 SDs, and especially not for > 4 > >SDs. > > > >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 > ------=_Part_1082_30383116.1127506099549 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Sorry I did not pick up on this thread sooner. As a = former PSAP type person I can tell you that in the State of Vermont over the last 7 years we have had 5 significant PSAP reconfigurations that involved re-routing of calls to new permanent locations. However, using historical references to determine this is not going to help. Their is a shift afoot right now towards dispatch/PSAP consolidation and the rate of change could increase exponentially particularly as new funding mechanisms in pursuit of better disaster preparedness becomes available for this specific purpose. I would also add that bringing new PSAP's on line and decommisioing old ones will become more common place as old cumbersome legacy gear gets replaced by more capable, less complex systems.

Nate Wilcox


On 9/21/05, James M. Polk <jmpolk@ci= sco.com> wrote:
Tim

This is a good example, and one that SIP covers already, as time= -of-day
routing is a piece of cake to a SIP Proxy.

At 03:34 PM 9/= 20/2005 -0600, Tim Dunn wrote:
>James-
>
>In certain part= s of the US (generally rural, but I think there are also some
>urban examples), I am aware of local police departments that answer= their
>emergency calls between 8am and 5pm.  At other time= s the calls are routed to
>a county or state level center that is a 2= 4x7 operation.  So the answer to
>your question would be that routing changes can occur daily in some= places.
>
>
>In the legacy circuit switched environment,= there is generally a way to busy
>out the inbound emergency trunks, = allowing for routing of calls to another
>location.  In my example above, the local PSAP throws a s= witch and the calls
>now route to an alternate location.
>
&= gt;This is also, in general, how trunk busyouts occur if a PSAP needs to>quickly vacate and you want the calls routed elsewhere.  My = experience was
>that there were switches at the PSAP, at the central office (to bus= y out the
>trunks) and sometimes at a local backup PSAP (unbusying th= ose trunks to
>begin accepting calls).  If you had your pri= mary and backup location out of
>business, there are switch level instructions on where to route.>
>Tim Dunn
>
>-----Original Message-----
>From= : ecrit-bounces@ietf.org [mai= lto: ecrit-bounces@ietf.org] On Be= half Of
>James M. Polk
>Sent: Tuesday, September 20, 2005 2:56 = PM
>To: ecrit@ietf.org
>S= ubject: [Ecrit] Timing of PSAPs changing coverage areas
>
>All
>
>I've heard and read the statements and r= equirements from folks that the
>routing of a call to a PSAP needs to= be as fresh as possible because a
>particular PSAP might have moved,= or more accurately, that a location might
>be served "on a moment's notice" by a different PSAP.
= >
>I'd like to ask how often this happens today. Does anyone know = how often a
>location needs to contact a different PSAP than its norm= al/standard one?
>
>It seems to me that a lot of us might be imagining a worse-= case scenario
>that we need to design protocols for, and that this wo= rse-case scenario
>happens often. If this is, say only 0.01% of the t= ime - or even under 5% of
>all emergency calls (2 standard deviations, or SDs), I'm thinking w= e're
>focusing too much energy on solving something that is a statist= ical
>"outlier".
>
>Today's emergency systems a= ren't build for 2 SDs, and especially not for 4
>SDs.
>
>cheers,
>James
>
>  = ;            &n= bsp;            = ;       *******************
> = ;            &n= bsp;    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,
Jame= s

           =             &nb= sp;         *******************
        &nbs= p;        Truth is not to be argued... it is to be presented.

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

------=_Part_1082_30383116.1127506099549-- --===============0088522540== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0088522540==-- From ecrit-bounces@ietf.org Fri Sep 23 16:59:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIue6-0004yP-9a; Fri, 23 Sep 2005 16:59:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIue3-0004yJ-34 for ecrit@megatron.ietf.org; Fri, 23 Sep 2005 16:59:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13017 for ; Fri, 23 Sep 2005 16:59:44 -0400 (EDT) Received: from bay106-dav2.bay106.hotmail.com ([65.54.161.74] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIukV-0002l5-Ru for ecrit@ietf.org; Fri, 23 Sep 2005 17:06:30 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 23 Sep 2005 13:59:30 -0700 Message-ID: Received: from 65.54.161.200 by BAY106-DAV2.phx.gbl with DAV; Fri, 23 Sep 2005 20:59:30 +0000 X-Originating-IP: [65.54.161.200] X-Originating-Email: [timothydunn01@msn.com] X-Sender: timothydunn01@msn.com From: "Tim Dunn" To: "'Nate Wilcox'" , "'James M. Polk'" Subject: RE: [Ecrit] Timing of PSAPs changing coverage areas Date: Fri, 23 Sep 2005 14:59:23 -0600 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXAeor4oxldAVVDR02LXPD2ic8XvQABMHpg In-Reply-To: AAAAAHid4H6cLVBKvI35MTImwgAHANlTnCJhprtFudq2LHCBs8EBACIA//8AANlTnCJhprtFudq2LHCBs8EBAAUmAAAAAA== X-OriginalArrivalTime: 23 Sep 2005 20:59:30.0786 (UTC) FILETIME=[B14D1420:01C5C081] X-Spam-Score: 2.5 (++) X-Scan-Signature: 08868c2bcdb53bddcb7cc7e7cf96b038 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="===============0930463424==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0930463424== Content-Type: multipart/alternative; boundary="----=_NextPart_000_005C_01C5C04F.63222A60" This is a multi-part message in MIME format. ------=_NextPart_000_005C_01C5C04F.63222A60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nate- =20 My reference to circuit switched language was intended to answer the question of whether or not =93=85anyone know(s) how often a location = needs to contact a different PSAP than its normal/standard one=94. I was in no = way defending the status quo of the circuit switched technology. = Realistically, in many places in the US, call routing changes occur quite often and are = not =93a statistical =91outlier=92" as was asked in James=92 original = statements. I was simply attempting to say that there we must take into account both time based (the 8-5 PSAP) and situation based (PSAP Consolidation, Special Events, Relocation to an Backup PSAP, Disasters, etc.) scenarios when we talk about the routing of the emergency call to the PSAP. =20 I agree that we=92re about to undergo a systematic review of PSAPs, = responses, and public safety communications in general as a part of the = Katrina/Rita events. New funding streams bring the potential of new PSAP = configurations which makes the point even more that the PSAP call routing functions = must be flexible and able to have a call =93=85be served "on a moment's notice" = by a different PSAP=94. =20 And not all PSAPs are consolidating, I know of at least one PSAP that consolidated years ago and has re-split. =20 Tim Dunn =20 _____ =20 From: Nate Wilcox [mailto:ngwilcox@gmail.com]=20 Sent: Friday, September 23, 2005 2:08 PM To: James M. Polk Cc: Tim Dunn; ecrit@ietf.org Subject: Re: [Ecrit] Timing of PSAPs changing coverage areas =20 Sorry I did not pick up on this thread sooner. As a former PSAP type = person I can tell you that in the State of Vermont over the last 7 years we = have had 5 significant PSAP reconfigurations that involved re-routing of = calls to new permanent locations. However, using historical references to = determine this is not going to help. Their is a shift afoot right now towards dispatch/PSAP consolidation and the rate of change could increase exponentially particularly as new funding mechanisms in pursuit of = better disaster preparedness becomes available for this specific purpose. I = would also add that bringing new PSAP's on line and decommisioing old ones = will become more common place as old cumbersome legacy gear gets replaced by = more capable, less complex systems. Nate Wilcox On 9/21/05, James M. Polk wrote: Tim This is a good example, and one that SIP covers already, as time-of-day routing is a piece of cake to a SIP Proxy. At 03:34 PM 9/20/2005 -0600, Tim Dunn wrote: >James- > >In certain parts of the US (generally rural, but I think there are also some=20 >urban examples), I am aware of local police departments that answer = their >emergency calls between 8am and 5pm. At other times the calls are = routed to >a county or state level center that is a 24x7 operation. So the answer = to=20 >your question would be that routing changes can occur daily in some = places. > > >In the legacy circuit switched environment, there is generally a way to busy >out the inbound emergency trunks, allowing for routing of calls to = another=20 >location. In my example above, the local PSAP throws a switch and the calls >now route to an alternate location. > >This is also, in general, how trunk busyouts occur if a PSAP needs to >quickly vacate and you want the calls routed elsewhere. My experience = was=20 >that there were switches at the PSAP, at the central office (to busy = out the >trunks) and sometimes at a local backup PSAP (unbusying those trunks to >begin accepting calls). If you had your primary and backup location = out of >business, there are switch level instructions on where to route. > >Tim Dunn > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto: ecrit-bounces@ietf.org] On Behalf = Of >James M. Polk >Sent: Tuesday, September 20, 2005 2:56 PM >To: ecrit@ietf.org >Subject: [Ecrit] Timing of PSAPs changing coverage areas=20 > >All > >I've heard and read the statements and requirements from folks that the >routing of a call to a PSAP needs to be as fresh as possible because a >particular PSAP might have moved, or more accurately, that a location = might >be served "on a moment's notice" by a different PSAP. > >I'd like to ask how often this happens today. Does anyone know how = often a >location needs to contact a different PSAP than its normal/standard = one?=20 > >It seems to me that a lot of us might be imagining a worse-case = scenario >that we need to design protocols for, and that this worse-case scenario >happens often. If this is, say only 0.01% of the time - or even under = 5% of >all emergency calls (2 standard deviations, or SDs), I'm thinking we're >focusing too much energy on solving something that is a statistical >"outlier". > >Today's emergency systems aren't build for 2 SDs, and especially not = for 4=20 >SDs. > >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 =20 ------=_NextPart_000_005C_01C5C04F.63222A60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Nate-

 

My reference to circuit switched = language was intended to answer the question of whether or not “…anyone = know(s) how often a location needs to contact a different PSAP than its = normal/standard one”.    I was in no way defending the status quo = of the circuit switched technology.  Realistically, in many places in the = US, = call routing changes occur quite often and are not “a statistical = ‘outlier’" as was asked in James’ original statements.  I was simply = attempting to say that there we must take into account both time based (the 8-5 = PSAP) and situation based (PSAP Consolidation, Special Events, Relocation to an = Backup PSAP, Disasters, etc.) scenarios when we talk about the routing of the = emergency call to the PSAP.

 

I agree that we’re about to = undergo a systematic review of PSAPs, responses, and public safety = communications in general as a part of the Katrina/Rita events.  New funding streams = bring the potential of new PSAP configurations which makes the point even more = that the PSAP call routing functions must be flexible and able to have a call = “…be served "on a moment's notice" by a different = PSAP”.

 

And not all PSAPs are = consolidating, I know of at least one PSAP that consolidated years ago and has = re-split.

 

Tim = Dunn

 

From: Nate = Wilcox [mailto:ngwilcox@gmail.com]
Sent: Friday, September = 23, 2005 2:08 PM
To: James M. Polk
Cc: Tim Dunn; = ecrit@ietf.org
Subject: Re: [Ecrit] = Timing of PSAPs changing coverage areas

 

Sorry = I did not pick up on this thread sooner. As a former PSAP type person I can tell = you that in the State of Vermont over the last 7 years we have had 5 significant PSAP reconfigurations = that involved re-routing of calls to new permanent locations. However, using historical references to determine this is not going to help. Their is a = shift afoot right now towards dispatch/PSAP consolidation and the rate of = change could increase exponentially particularly as new funding mechanisms in = pursuit of better disaster preparedness becomes available for this specific = purpose. I would also add that bringing new PSAP's on line and decommisioing old = ones will become more common place as old cumbersome legacy gear gets replaced by = more capable, less complex systems.

Nate = Wilcox

On 9/21/05, James M. Polk <jmpolk@cisco.com> wrote:

Tim

This is a good example, and one that SIP covers already, as = time-of-day
routing is a piece of cake to a SIP Proxy.

At 03:34 PM 9/20/2005 -0600, Tim Dunn wrote:
>James-
>
>In certain parts of the US (generally rural, but I think there are also some
>urban examples), I am aware of local police departments that answer = their
>emergency calls between 8am and 5pm.  At other times the = calls are routed to
>a county or state level center that is a 24x7 = operation.  So the answer to
>your question would be that routing changes can occur daily in some = places.
>
>
>In the legacy circuit switched environment, there is generally a way = to busy
>out the inbound emergency trunks, allowing for routing of calls to = another
>location.  In my example above, the local PSAP throws a = switch and the calls
>now route to an alternate location.
>
>This is also, in general, how trunk busyouts occur if a PSAP needs = to
>quickly vacate and you want the calls routed = elsewhere.  My experience was
>that there were switches at the PSAP, at the central office (to busy = out the
>trunks) and sometimes at a local backup PSAP (unbusying those trunks = to
>begin accepting calls).  If you had your primary and = backup location out of
>business, there are switch level instructions on where to route.
>
>Tim Dunn
>
>-----Original Message-----
>From: ecrit-bounces@ietf.org [mailto: ecrit-bounces@ietf.org] On Behalf Of
>James M. Polk
>Sent: Tuesday, September 20, 2005 2:56 PM
>To: ecrit@ietf.org
>Subject: [Ecrit] Timing of PSAPs changing coverage areas
>
>All
>
>I've heard and read the statements and requirements from folks that = the
>routing of a call to a PSAP needs to be as fresh as possible because = a
>particular PSAP might have moved, or more accurately, that a = location might
>be served "on a moment's notice" by a different PSAP.
>
>I'd like to ask how often this happens today. Does anyone know how = often a
>location needs to contact a different PSAP than its normal/standard = one?
>
>It seems to me that a lot of us might be imagining a worse-case = scenario
>that we need to design protocols for, and that this worse-case = scenario
>happens often. If this is, say only 0.01% of the time - or even = under 5% of
>all emergency calls (2 standard deviations, or SDs), I'm thinking = we're
>focusing too much energy on solving something that is a = statistical
>"outlier".
>
>Today's emergency systems aren't build for 2 SDs, and especially not = for 4
>SDs.
>
>cheers,
>James
>
>           &nb= sp;           &nbs= p;          ***********= ********
>           &nb= sp;      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

            &= nbsp;           &n= bsp;        *******************
            &= nbsp;    Truth is not to be argued... it is to be presented.

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

 

------=_NextPart_000_005C_01C5C04F.63222A60-- --===============0930463424== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0930463424==-- From ecrit-bounces@ietf.org Fri Sep 23 18:46:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIwJ8-0007le-OZ; Fri, 23 Sep 2005 18:46:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIwJ5-0007l6-96 for ecrit@megatron.ietf.org; Fri, 23 Sep 2005 18:46:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20256 for ; Fri, 23 Sep 2005 18:46:12 -0400 (EDT) From: Rockford9@aol.com Received: from imo-m14.mx.aol.com ([64.12.138.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIwPb-0005b7-NV for ecrit@ietf.org; Fri, 23 Sep 2005 18:53:00 -0400 Received: from Rockford9@aol.com by imo-m14.mx.aol.com (mail_out_v38_r5.5.) id l.ac.7b8333f5 (48552) for ; Fri, 23 Sep 2005 18:46:03 -0400 (EDT) Message-ID: Date: Fri, 23 Sep 2005 18:46:03 EDT Subject: Re: [Ecrit] 911 and location story To: ecrit@ietf.org MIME-Version: 1.0 X-Mailer: 9.0 Security Edition for Windows sub 2340 X-Spam-Flag: NO X-Spam-Score: 1.1 (+) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 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="===============1239697234==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============1239697234== Content-Type: multipart/alternative; boundary="-----------------------------1127515563" -------------------------------1127515563 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Another vaguely related, more on the positive side. Everyday there are such stories somewhere across those areas of the world with enhanced emergency services access. _http://www.thewbalchannel.com/news/5008448/detail.html_ (http://www.thewbalchannel.com/news/5008448/detail.html) FREDERICK, Md. -- Michael Cosgrove considers himself "saved by the cell" thanks to a new system that allows all primary 911 centers in Maryland to locate wireless emergency calls. Cosgrove said he was leaving Ocean City last month when an allergic reaction to a bee's nest left him helpless. He could not drive and had just enough energy to dial 911 on his cell phone before passing out. Cosgrove, who is executive vice president of a Maryland marketing communications company, was in Frederick Thursday to proclaim that the new system works. "I'm a beneficiary," he said. Maryland is the eighth state in the country to announce that all 23 counties, Baltimore and Ocean City, can receive Phase II wireless calls. Phase II enhancement allows 911 operators to locate a caller and display their phone number and location on a computer within seconds - provided the cell phone and its service provider is properly equipped. "This saves lives. Callers have died because we have been unable to find them," said Gov. Robert Ehrlich, who christened the statewide service Thursday. "Regardless of where you are you will be found." In a message dated 9/23/2005 7:55:07 A.M. Central Standard Time, hgs@cs.columbia.edu writes: http://www.nytimes.com/2005/09/23/nyregion/23stab.html Only vaguely relevant to our discussions, but an indication of some of the issues in handling 911 calls today. "Mr. Eason said the caller provided an incorrect address about a block away from the three-story apartment building where the killings took place. When the officers who were dispatched to the wrong location called Mr. Andrews' cellphone number to verify the address, no one answered, he said." "When the second call came in on Tuesday night, Mr. Eason said, a dispatcher transferred the call to a district precinct, but the caller hung up before the transfer was completed. Because Mr. Andrews used a cellphone to alert authorities, the police were not able to pinpoint his location, Mr. Eason said. The 911 calls were first reported in The Jersey Journal on Thursday." _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit -------------------------------1127515563 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Another vaguely related, more on the positive side. Everyday there are=20= such=20 stories somewhere across those areas of the world with enhanced emergency=20 services access.
 

http://www.thewbalchannel.com/news/5008448/detail.html

 

FREDERICK, Md. -- Michael=20 Cosgrove considers himself "saved by the cell" thanks to a new system that=20 allows all primary 911 centers in Maryland to locate wireless emergency calls.=20

Cosgrove said he=20= was=20 leaving Ocean City last month when an allergic reaction to a bee's nest left= him=20 helpless. He could not drive and had just enough energy to dial 911 on his c= ell=20 phone before passing out.

Cosgrove, who is=20 executive vice president of a Maryland marketing communications company, was in=20 Frederick Thursday to proclaim that the new system works.= "I'm=20 a beneficiary," he said.

Maryland is the eighth state in the country to announce=20= that=20 all 23 counties, Baltimore and Ocean City, can receive Phase II wireless=20 calls.

 

Phase II enhancem= ent=20 allows 911 operators to locate a caller and display their phone number and=20 location on a computer within seconds - provided the cell phone and its serv= ice=20 provider is properly equipped.

"This saves lives= .=20 Callers have died because we have been unable to find them," said Gov. Rober= t=20 Ehrlich, who christened the statewide service Thursday. "Regardless of where= you=20 are you will be found."

 
In a message dated 9/23/2005 7:55:07 A.M. Central Standard Time,=20 hgs@cs.columbia.edu writes:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>http://www.nytimes.com/2005/09/23/nyregion/23stab.html

Onl= y=20 vaguely relevant to our discussions, but an indication of some of
the=20 issues in handling 911 calls today.

"Mr. Eason said the caller prov= ided=20 an incorrect address about a block
away from the three-story apartment= =20 building where the killings took
place. When the officers who were=20 dispatched to the wrong location
called Mr. Andrews' cellphone number=20= to=20 verify the address, no one
answered, he said."

"When the second= =20 call came in on Tuesday night, Mr. Eason said, a
dispatcher transferre= d=20 the call to a district precinct, but the caller
hung up before the=20 transfer was completed. Because Mr. Andrews used a
cellphone to alert=20 authorities, the police were not able to pinpoint his
location, Mr. Ea= son=20 said. The 911 calls were first reported in The
Jersey Journal on=20 Thursday."

_______________________________________________
Ecrit= =20 mailing=20 list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit
=
 
-------------------------------1127515563-- --===============1239697234== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1239697234==-- From ecrit-bounces@ietf.org Mon Sep 26 07:13:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJqv0-0002d9-Pv; Mon, 26 Sep 2005 07:13:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJquz-0002d4-Bn for ecrit@megatron.ietf.org; Mon, 26 Sep 2005 07:13:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18894 for ; Mon, 26 Sep 2005 07:13:06 -0400 (EDT) Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJr20-00018C-Gm for ecrit@ietf.org; Mon, 26 Sep 2005 07:20:26 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id j8QBD1qS002476; Mon, 26 Sep 2005 11:13:01 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1EJquq-0003MO-00 for ecrit@ietf.org; Mon, 26 Sep 2005 12:13:00 +0100 Date: Mon, 26 Sep 2005 12:13:00 +0100 From: "Clive D.W. Feather" To: ecrit@ietf.org Message-ID: <20050926111300.GQ97112@finch-staff-1.thus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Ecrit] draft-polk-dhc-uri-00: technical comment X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm new to this, but I have a comment on this I-D. Why are many of the attributes in primary/secondary pairs? This doesn't make allowance for, say, a tertiary value while, at the same time, using up number space to no good end. Better would be to allow multiple URIs in the value. Contrary to 2.1 bullet point 3, all that is necessary is to have some delimiter (say a zero octet) between URIs. If the resulting sequence is over 255 octets, use the concatenation mechanism. Suppose that the URIs for two PSAPs are and . The present protocol would have: XXX 20 1 's' 'i' 'p' ':' 'p' 's' 'a' 'p' '@' 't' 'e' 'l' 'c' 'o' '.' 'n' 'e' 't' XXX 27 2 's' 'i' 'p' ':' 'b' 'a' 'c' 'k' 'u' 'p' '@' 'p' 's' 'a' 'p' '.' 't' 'e' 'l' 'c' 'o' '.' 'c' 'o' 'm' while I would propose: XXX 46 1 's' 'i' 'p' ':' 'p' 's' 'a' 'p' '@' 't' 'e' 'l' 'c' 'o' '.' 'n' 'e' 't' 0 's' 'i' 'p' ':' 'b' 'a' 'c' 'k' 'u' 'p' '@' 'p' 's' 'a' 'p' '.' 't' 'e' 'l' 'c' 'o' '.' 'c' 'o' 'm' -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 26 09:32:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJt5u-0006ex-Qw; Mon, 26 Sep 2005 09:32:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJt5s-0006es-Vm for ecrit@megatron.ietf.org; Mon, 26 Sep 2005 09:32:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26473 for ; Mon, 26 Sep 2005 09:32:31 -0400 (EDT) Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EJtCv-0005Bm-DN for ecrit@ietf.org; Mon, 26 Sep 2005 09:39:50 -0400 Received: (qmail invoked by alias); 26 Sep 2005 13:32:21 -0000 Received: from unknown (EHLO [192.168.0.133]) [195.84.156.34] by mail.gmx.net (mp013) with SMTP; 26 Sep 2005 15:32:21 +0200 X-Authenticated: #29516787 Message-ID: <4337F856.9000008@gmx.net> Date: Mon, 26 Sep 2005 15:32:06 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Clive D.W. Feather" Subject: Re: [Ecrit] draft-polk-dhc-uri-00: technical comment References: <20050926111300.GQ97112@finch-staff-1.thus.net> In-Reply-To: <20050926111300.GQ97112@finch-staff-1.thus.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 hi clive, before we jump into the details of draft proposed by james i would like to see whether the working group thinks that the proposal is actually a candidate for a mapping protocol (therefore competing with iris-econ, dns-sos and lump). if draft-polk-dhc-uri-00.txt is not a proposal for a mapping protocol then we do not need to further discuss it in this working group since we have plenty of other topics to finish first. ciao hannes Clive D.W. Feather wrote: >I'm new to this, but I have a comment on this I-D. > >Why are many of the attributes in primary/secondary pairs? This doesn't >make allowance for, say, a tertiary value while, at the same time, using up >number space to no good end. > >Better would be to allow multiple URIs in the value. Contrary to 2.1 bullet >point 3, all that is necessary is to have some delimiter (say a zero octet) >between URIs. If the resulting sequence is over 255 octets, use the >concatenation mechanism. > >Suppose that the URIs for two PSAPs are and >. The present protocol would have: > > XXX 20 1 's' > 'i' 'p' ':' 'p' > 's' 'a' 'p' '@' > 't' 'e' 'l' 'c' > 'o' '.' 'n' 'e' > 't' XXX 27 2 > 's' 'i' 'p' ':' > 'b' 'a' 'c' 'k' > 'u' 'p' '@' 'p' > 's' 'a' 'p' '.' > 't' 'e' 'l' 'c' > 'o' '.' 'c' 'o' > 'm' > >while I would propose: > > XXX 46 1 's' > 'i' 'p' ':' 'p' > 's' 'a' 'p' '@' > 't' 'e' 'l' 'c' > 'o' '.' 'n' 'e' > 't' 0 's' 'i' > 'p' ':' 'b' 'a' > 'c' 'k' 'u' 'p' > '@' 'p' 's' 'a' > 'p' '.' 't' 'e' > 'l' 'c' 'o' '.' > 'c' 'o' 'm' > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 26 10:29:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJtyu-0002dl-Iu; Mon, 26 Sep 2005 10:29:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJtyq-0002ci-W5 for ecrit@megatron.ietf.org; Mon, 26 Sep 2005 10:29:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01001 for ; Mon, 26 Sep 2005 10:29:09 -0400 (EDT) Received: from [199.117.205.100] (helo=ns2.sccx.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJu5j-0006nJ-RL for ecrit@ietf.org; Mon, 26 Sep 2005 10:36:29 -0400 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] draft-polk-dhc-uri-00 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 26 Sep 2005 09:28:27 -0500 Message-ID: <422D410BD61FC04185076AD99AA7207A01143960@inilmx01.lgmt.trdo> Thread-Topic: [Ecrit] draft-polk-dhc-uri-00 Thread-Index: AcXASfp25eM/5Jr5TBmYSBgNiPPX7wCXBJ0g From: "McCalmont, Patti" To: "John Schnizlein" X-OriginalArrivalTime: 26 Sep 2005 14:28:30.0418 (UTC) FILETIME=[91124320:01C5C2A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi John, HELD is just as much a part of the ECRIT discussion as DHCP, both are dealing with location, a critical component required to route the emergency call. Are you thinking we should also move this DHCP discussion to the DHC group as well? -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com]=20 Sent: Friday, September 23, 2005 9:21 AM To: McCalmont, Patti Cc: Andrew Newton; ECRIT; br@brianrosen.net Subject: Re: [Ecrit] draft-polk-dhc-uri-00 Wouldn't it be reasonable to keep the discussion of the issues and=20 claims with HELD in the GeoPriv WG where it has been? We should not=20 recapitulate that in this WG also. John On Sep 23, 2005, at 10:01 AM, McCalmont, Patti wrote: > Wow.......guess we all know how you stand but......... even James Polk > stated that one size won't fit all. HELD provides a solution for many > other types of interfaces, such as Wireless as the mobile is moving. It > does take care of the embedded base and it meets other Carrier needs. > Probably not a surprise, but I don't agree at all with your statements. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 26 10:57:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuQT-00017S-E1; Mon, 26 Sep 2005 10:57:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuQR-00011G-Pv for ecrit@megatron.ietf.org; Mon, 26 Sep 2005 10:57:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02931 for ; Mon, 26 Sep 2005 10:57:50 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJuXT-0007jA-78 for ecrit@ietf.org; Mon, 26 Sep 2005 11:05:10 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Mon, 26 Sep 2005 10:57:38 -0400 id 000EBA0B.43380C62.00001519 In-Reply-To: <4337F856.9000008@gmx.net> References: <20050926111300.GQ97112@finch-staff-1.thus.net> <4337F856.9000008@gmx.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] draft-polk-dhc-uri-00: technical comment Date: Mon, 26 Sep 2005 10:57:34 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 26, 2005, at 9:32 AM, Hannes Tschofenig wrote: > before we jump into the details of draft proposed by james i would > like to see whether the working group thinks that the proposal > is actually a candidate for a mapping protocol (therefore > competing with iris-econ, dns-sos and lump). I don't think it is. > if draft-polk-dhc-uri-00.txt is not a proposal for a mapping > protocol then we do not need to further discuss it in this working > group since we have plenty of other topics to finish first. But if that were the case, then we need throw out half of the requirements document. Our charter is broader than "just create a mapping protocol." -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 26 11:18:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJujz-0004Gd-KD; Mon, 26 Sep 2005 11:18:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJujx-0004FS-5N for ecrit@megatron.ietf.org; Mon, 26 Sep 2005 11:18:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10031 for ; Mon, 26 Sep 2005 11:17:59 -0400 (EDT) Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EJuqz-00022O-AS for ecrit@ietf.org; Mon, 26 Sep 2005 11:25:19 -0400 Received: (qmail invoked by alias); 26 Sep 2005 15:17:48 -0000 Received: from unknown (EHLO [192.168.0.133]) [195.84.156.34] by mail.gmx.net (mp011) with SMTP; 26 Sep 2005 17:17:48 +0200 X-Authenticated: #29516787 Message-ID: <43381116.2050301@gmx.net> Date: Mon, 26 Sep 2005 17:17:42 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] draft-polk-dhc-uri-00: technical comment References: <20050926111300.GQ97112@finch-staff-1.thus.net> <4337F856.9000008@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 # hi andy, Andrew Newton wrote: > > On Sep 26, 2005, at 9:32 AM, Hannes Tschofenig wrote: > >> before we jump into the details of draft proposed by james i would >> like to see whether the working group thinks that the proposal is >> actually a candidate for a mapping protocol (therefore competing >> with iris-econ, dns-sos and lump). > > > I don't think it is. > # i went through the entire mailing list thread again and wasn't quite sure where this work is going. it certainly raised many interesting discussions. >> if draft-polk-dhc-uri-00.txt is not a proposal for a mapping >> protocol then we do not need to further discuss it in this working >> group since we have plenty of other topics to finish first. > > > But if that were the case, then we need throw out half of the > requirements document. Our charter is broader than "just create a > mapping protocol." > # actually we dumped most of the requirements (both security and non-security requirements) already to be a bit more focused. # i personally think that we need to get the basic work done first before we extend our scope. at the last ietf meeting we gave henning a similar feedback with regards to parts of his lump proposal where the protocol between mapping servers was discussed. this topic is also relevant for the core work of the working group but we said that we do not understand the requirements yet and we need to focus on the mapping protocol between the mapping client and the mapping server. # ciao # hannes > -andy > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 26 11:21:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJunR-0006Lq-Kq; Mon, 26 Sep 2005 11:21:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJunQ-0006LK-1V for ecrit@megatron.ietf.org; Mon, 26 Sep 2005 11:21:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11188 for ; Mon, 26 Sep 2005 11:21:34 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJuuQ-0002VU-6O for ecrit@ietf.org; Mon, 26 Sep 2005 11:28:54 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 26 Sep 2005 11:21:21 -0400 X-IronPort-AV: i="3.97,146,1125892800"; d="scan'208"; a="71780037:sNHT42002150" Received: from [68.50.138.194] (che-vpn-cluster-2-135.cisco.com [10.86.242.135]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8QFLIT6029519; Mon, 26 Sep 2005 11:21:19 -0400 (EDT) In-Reply-To: <422D410BD61FC04185076AD99AA7207A01143960@inilmx01.lgmt.trdo> References: <422D410BD61FC04185076AD99AA7207A01143960@inilmx01.lgmt.trdo> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: <3ca5963e22bd7ad96475087d6620ac70@cisco.com> From: John Schnizlein Subject: Re: [Ecrit] draft-polk-dhc-uri-00 Date: Mon, 26 Sep 2005 11:21:15 -0400 To: "McCalmont, Patti" X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1587475105==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============1587475105== Content-Type: multipart/alternative; boundary=Apple-Mail-1--882980131 --Apple-Mail-1--882980131 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit HELD [draft-winterbottom-http-location-delivery-01.txt] was discussed extensively on the GeoPriv mailing list and at that WG's session of IETF 63. James Winterbottom announced the -00 version February 22 on the GeoPriv list. My impression was that the WG chairs and authors chose in which WG to pursue its technical review. My suggestion is that we not start all that discussion over again here. It seems wasteful to cover the same ground again in a different WG. If the WG chairs want to recapitulate the HELD discussion here, it is OK with me. I would recommend that those interested first read the material covered in GeoPriv. There is a previous agreement between the chairs of the DHC WG that documents that involve both location semantics and DHCP should be discussed first in the WG most appropriate to the semantics, and then in the DHC WG regarding those issues that relate to the protocol. On (the same day as posted here) September 12, James Polk solicited discussion of the DHCP aspects of his draft on the DHC mailing list, and it has received some. Since most of the discussion of James' draft here on the ECRIT list has been about how this facility would contribute to the emergency-response system design, it seems to me that about the right balance between these WG discussions has occurred. John On Sep 26, 2005, at 10:28 AM, McCalmont, Patti wrote: > > HELD is just as much a part of the ECRIT discussion as DHCP, both are > dealing with location, a critical component required to route the > emergency call. Are you thinking we should also move this DHCP > discussion to the DHC group as well? > > From: John Schnizlein [mailto:jschnizl@cisco.com] >> >> Wouldn't it be reasonable to keep the discussion of the issues and >> claims with HELD in the GeoPriv WG where it has been? We should not >> recapitulate that in this WG also. >> >> On Sep 23, 2005, at 10:01 AM, McCalmont, Patti wrote: >> >>> Wow.......guess we all know how you stand but......... even James >>> Polk >>> stated that one size won't fit all. HELD provides a solution for many >>> other types of interfaces, such as Wireless as the mobile is moving. >>> It does take care of the embedded base and it meets other Carrier >>> needs. >>> Probably not a surprise, but I don't agree at all with your >>> statements. >> --Apple-Mail-1--882980131 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit HELD [draft-winterbottom-http-location-delivery-01.txt] was discussed extensively on the GeoPriv mailing list and at that WG's session of IETF 63. James Winterbottom announced the -00 version February 22 on the GeoPriv list. My impression was that the WG chairs and authors chose in which WG to pursue its technical review. My suggestion is that we not start all that discussion over again here. It seems wasteful to cover the same ground again in a different WG. If the WG chairs want to recapitulate the HELD discussion here, it is OK with me. I would recommend that those interested first read the material covered in GeoPriv. There is a previous agreement between the chairs of the DHC WG that documents that involve both location semantics and DHCP should be discussed first in the WG most appropriate to the semantics, and then in the DHC WG regarding those issues that relate to the protocol. On (the same day as posted here) September 12, James Polk solicited discussion of the DHCP aspects of his draft on the DHC mailing list, and it has received some. Since most of the discussion of James' draft here on the ECRIT list has been about how this facility would contribute to the emergency-response system design, it seems to me that about the right balance between these WG discussions has occurred. John On Sep 26, 2005, at 10:28 AM, McCalmont, Patti wrote: HELD is just as much a part of the ECRIT discussion as DHCP, both are dealing with location, a critical component required to route the emergency call. Are you thinking we should also move this DHCP discussion to the DHC group as well? From: John Schnizlein [mailto:jschnizl@cisco.com] Wouldn't it be reasonable to keep the discussion of the issues and claims with HELD in the GeoPriv WG where it has been? We should not recapitulate that in this WG also. On Sep 23, 2005, at 10:01 AM, McCalmont, Patti wrote: Wow.......guess we all know how you stand but......... even James Polk stated that one size won't fit all. HELD provides a solution for many other types of interfaces, such as Wireless as the mobile is moving. It does take care of the embedded base and it meets other Carrier needs. Probably not a surprise, but I don't agree at all with your statements. --Apple-Mail-1--882980131-- --===============1587475105== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1587475105==-- From ecrit-bounces@ietf.org Mon Sep 26 11:42:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJv7t-0002wB-T0; Mon, 26 Sep 2005 11:42:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJv7s-0002vn-FK for ecrit@megatron.ietf.org; Mon, 26 Sep 2005 11:42:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18627 for ; Mon, 26 Sep 2005 11:42:42 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJvEw-0005UW-9Q for ecrit@ietf.org; Mon, 26 Sep 2005 11:50:03 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Mon, 26 Sep 2005 11:42:41 -0400 id 000EBA0B.433816F1.00002394 In-Reply-To: <43381116.2050301@gmx.net> References: <20050926111300.GQ97112@finch-staff-1.thus.net> <4337F856.9000008@gmx.net> <43381116.2050301@gmx.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0F1F3FC6-0014-4B4D-95FD-4DCD2ACD701F@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] draft-polk-dhc-uri-00: technical comment Date: Mon, 26 Sep 2005 11:42:41 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 26, 2005, at 11:17 AM, Hannes Tschofenig wrote: > # i went through the entire mailing list thread again and wasn't > quite sure where this work is going. > it certainly raised many interesting discussions. I can see how it is confusing as some people have mischaracterized it, intentionally or not. >> But if that were the case, then we need throw out half of the >> requirements document. Our charter is broader than "just create >> a mapping protocol." >> >> > # actually we dumped most of the requirements (both security and > non-security requirements) already to be a bit more focused. > # i personally think that we need to get the basic work done first > before we extend our scope. at the last ietf meeting we gave > henning a similar feedback with regards to parts of his lump > proposal where the protocol between mapping servers was discussed. > this topic is also relevant for the core work of the working group > but we said that we do not understand the requirements yet and we > need to focus on the mapping protocol between the mapping client > and the mapping server. If this is the case, then we can safely drop the following requirements: R7, UA-inserted, UA-referenced, Proxy-inserted, L28, A1a, A1c, A3, A4, and all of Section 9. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 26 11:51:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJvFt-0002u0-8c; Mon, 26 Sep 2005 11:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJvFr-0002tq-HF for ecrit@megatron.ietf.org; Mon, 26 Sep 2005 11:50:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20178 for ; Mon, 26 Sep 2005 11:50:57 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJvMt-00067u-Ab for ecrit@ietf.org; Mon, 26 Sep 2005 11:58:18 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Mon, 26 Sep 2005 11:50:54 -0400 id 000EBA03.433818DE.0000266E In-Reply-To: <3ca5963e22bd7ad96475087d6620ac70@cisco.com> References: <422D410BD61FC04185076AD99AA7207A01143960@inilmx01.lgmt.trdo> <3ca5963e22bd7ad96475087d6620ac70@cisco.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7F275591-5BC5-42FF-96F7-21760CB6BE76@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] draft-polk-dhc-uri-00 Date: Mon, 26 Sep 2005 11:50:52 -0400 To: John Schnizlein X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: "McCalmont, Patti" , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 26, 2005, at 11:21 AM, John Schnizlein wrote: > HELD [draft-winterbottom-http-location-delivery-01.txt] was > discussed extensively on the GeoPriv mailing list and at that WG's > session of IETF 63. James Winterbottom announced the -00 version > February 22 on the GeoPriv list. My impression was that the WG > chairs and authors chose in which WG to pursue its technical > review. My suggestion is that we not start all that discussion > over again here. It seems wasteful to cover the same ground again > in a different WG. If the WG chairs want to recapitulate the HELD > discussion here, it is OK with me. I would recommend that those > interested first read the material covered in GeoPriv. > > There is a previous agreement between the chairs of the DHC WG that > documents that involve both location semantics and DHCP should be > discussed first in the WG most appropriate to the semantics, and > then in the DHC WG regarding those issues that relate to the > protocol. On (the same day as posted here) September 12, James > Polk solicited discussion of the DHCP aspects of his draft on the > DHC mailing list, and it has received some. Since most of the > discussion of James' draft here on the ECRIT list has been about > how this facility would contribute to the emergency-response system > design, it seems to me that about the right balance between these > WG discussions has occurred. Since I'm on the cc: list for this message and happen to be co-chair of GEOPRIV, I wonder if it is being directed at me for that reason. So I'll say the following: 1) Whether or not HELD conforms to the protocol and security requirements of GEOPRIV (RFCs 3693 and RFCs 3694) is a matter for the GEOPRIV working group. 2) Whether or not HELD can be discussed as a part of the solution to ECRIT is not a GEOPRIV matter. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 26 11:53:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJvIH-00039D-9m; Mon, 26 Sep 2005 11:53:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJvIF-000395-Lf for ecrit@megatron.ietf.org; Mon, 26 Sep 2005 11:53:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20359 for ; Mon, 26 Sep 2005 11:53:25 -0400 (EDT) Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EJvPI-0006Dl-2Z for ecrit@ietf.org; Mon, 26 Sep 2005 12:00:46 -0400 Received: (qmail invoked by alias); 26 Sep 2005 15:53:14 -0000 Received: from 1958415634-CONSESS-NET.host.songnetworks.se (EHLO [192.168.0.133]) [195.84.156.34] by mail.gmx.net (mp004) with SMTP; 26 Sep 2005 17:53:14 +0200 X-Authenticated: #29516787 Message-ID: <43381962.1020906@gmx.net> Date: Mon, 26 Sep 2005 17:53:06 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Schnizlein References: <422D410BD61FC04185076AD99AA7207A01143960@inilmx01.lgmt.trdo> <3ca5963e22bd7ad96475087d6620ac70@cisco.com> In-Reply-To: <3ca5963e22bd7ad96475087d6620ac70@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: "McCalmont, Patti" , ECRIT Subject: [Ecrit] relationships between different working groups X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi john, hi all, although most all of us are subscribed to the relevant mailing lists (such as dhc, geopriv and ecrit, etc.) it seems to be natural to discuss plain geopriv topics on the geopriv mailing list. if a topic touches multiple working groups then post your mail to the relevant mailing lists. we need to be pragmatic here and consider the fact that there is obviously a lot of overlap. as a practical suggestion: a) change the email subject header (as i did with this mail) and b) split your feedback to different individual mails (if it touches different topics) ciao hannes John Schnizlein wrote: > HELD [draft-winterbottom-http-location-delivery-01.txt] was discussed > extensively on the GeoPriv mailing list and at that WG's session of > IETF 63. James Winterbottom announced the -00 version February 22 on > the GeoPriv list. My impression was that the WG chairs and authors > chose in which WG to pursue its technical review. My suggestion is > that we not start all that discussion over again here. It seems > wasteful to cover the same ground again in a different WG. If the WG > chairs want to recapitulate the HELD discussion here, it is OK with > me. I would recommend that those interested first read the material > covered in GeoPriv. > > There is a previous agreement between the chairs of the DHC WG that > documents that involve both location semantics and DHCP should be > discussed first in the WG most appropriate to the semantics, and then > in the DHC WG regarding those issues that relate to the protocol. On > (the same day as posted here) September 12, James Polk solicited > discussion of the DHCP aspects of his draft on the DHC mailing list, > and it has received some. Since most of the discussion of James' draft > here on the ECRIT list has been about how this facility would > contribute to the emergency-response system design, it seems to me > that about the right balance between these WG discussions has occurred. > > John > > On Sep 26, 2005, at 10:28 AM, McCalmont, Patti wrote: > > > HELD is just as much a part of the ECRIT discussion as DHCP, both are > dealing with location, a critical component required to route the > emergency call. Are you thinking we should also move this DHCP > discussion to the DHC group as well? > > From: John Schnizlein [mailto:jschnizl@cisco.com] > > > Wouldn't it be reasonable to keep the discussion of the issues > and > claims with HELD in the GeoPriv WG where it has been? We > should not > recapitulate that in this WG also. > > On Sep 23, 2005, at 10:01 AM, McCalmont, Patti wrote: > > Wow.......guess we all know how you stand but......... > even James Polk > stated that one size won't fit all. HELD provides a > solution for many > other types of interfaces, such as Wireless as the mobile > is moving. > It does take care of the embedded base and it meets other > Carrier needs. > Probably not a surprise, but I don't agree at all with > your statements. > > >------------------------------------------------------------------------ > >_______________________________________________ >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 Sep 26 14:03:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJxKZ-0001Yu-DT; Mon, 26 Sep 2005 14:03:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJxKX-0001XR-Ck for ecrit@megatron.ietf.org; Mon, 26 Sep 2005 14:03:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26566 for ; Mon, 26 Sep 2005 14:03:56 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJxRP-00016U-HO for ecrit@ietf.org; Mon, 26 Sep 2005 14:11:05 -0400 Received: from zctfhxm1.corp.nortel.com (zctfhxm1.corp.nortel.com [47.164.129.157]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j8QI3ML10537; Mon, 26 Sep 2005 20:03:23 +0200 (MEST) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zctfhxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Sep 2005 20:03:22 +0200 Received: from [127.0.0.1] ([47.130.17.119] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Sep 2005 14:03:19 -0400 Message-ID: <433837E5.1050004@nortel.com> Date: Mon, 26 Sep 2005 14:03:17 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ECRIT , Henning Schulzrinne Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2005 18:03:20.0111 (UTC) FILETIME=[93ED53F0:01C5C2C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Cc: Subject: [Ecrit] Summary ecrit-requirements-00 section 6: Emergency Identifier X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Just to summarize my understanding of our discussion last week, here's how a rewritten section 6 would look: -------- A1a: Universal emergency indication -- setup. For each signalling protocol that can be used in an emergency call, it must be possible to indicate, as a standard part of the protocol within the call-initiating message, that this is an emergency call. Motivation: such an indication is necessary to trigger emergency handling including relaxation of authentication and authorization procedures, access to call features otherwise not available, and routing toward the PSAP including mapping from location when required. A1a+: The emergency indication is required beyond the point of mapping. Motivation: there is a continuing need for a trigger for emergency handling procedures in ESRPs beyond the point of mapping. --------------- A1b: original formulation is seen as redundant, DELETED. New requirement: A1b': the mapping protocol also needs an emergency indication. Motivation: this allows reuse of the mapping protocol and the mapping servers for non-emergency purposes. -------- A1c: emergency marking. Any device in the signalling path that recognizes by some means that the signalling is associated with an emergency call MUST add the emergency indication called for in A1a to the signalling before forwarding it. Motivation: this ensures proper handling as an emergency call by downstream elements that may not recognize, for example, a local variant of a logical emergency address (see requirement A4+). A1c+: User agents, proxies, and other network elements that may process signalling associated with emergency calls should be configured to recognize a reasonable repertoire of logical emergency addresses (described in requirement A4+ below) as a means to trigger emergency marking. Because emergency numbers from one region may have different uses in another, it is best if a network entity is able to place a call in the context of its point of origin before using a non-local logical emergency address as the basis for emergency marking. Motivation: Out-of-region logical emergency addresses may be emitted by an user terminal that has been imported into a given region but is configured for a different home region. The user may have dialled a familiar emergency number rather than the local one. Signalling may have crossed regional boundaries before being processed by a network entity capable of performing emergency marking and other emergency processing. All of these cases must be handled as emergency calls if at possible. ----------- A3. Prevention of fraud. A call identified as an emergency call or marked as such in accordance with requirement A1c MUST be routed to a PSAP. Motivation: this prevents use of the emergency call indication to gain access to call features or authentication override for non-emergency purposes. ------------ A4+: Logical emergency addresses. For each signalling protocol that can be used in an emergency call, reserved addresses should be available to use in place of an emergency address prior to the point in the signalling path where mapping is done. The appropriate logical emergency address may be based on local convention (e.g., 911, 112, ..., in form appropriate to the signalling protocol). However, it is desirable to have a universal logical emergency address or a set of them identifying specific emergency services. Motivation: Any signalling protocol requires the use of some address to indicate the called party, and the user terminal may lack the capability to determine the actual PSAP address. The use of local conventions may be required as a transition mechanism. However, such use complicates international movement of the user terminal, and evolution to a standardized universal logical emergency address or set of addresses is preferable. A4. Minimal configuration. Any local logical emergency addresses should be configured into user terminals automatically, without user intervention. Motivation: a new user terminal "unofficially imported" into an organization from elsewhere should have the same emergency capabilities as one officially installed. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 26 16:03:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJzCR-0007BX-Vv; Mon, 26 Sep 2005 16:03:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJzCQ-0007BS-KS for ecrit@megatron.ietf.org; Mon, 26 Sep 2005 16:03:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06558 for ; Mon, 26 Sep 2005 16:03:40 -0400 (EDT) Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EJzJU-0005RW-3F for ecrit@ietf.org; Mon, 26 Sep 2005 16:11:03 -0400 Received: (qmail invoked by alias); 26 Sep 2005 20:03:22 -0000 Received: from host-n17-190.homerun.telia.com (EHLO [212.181.244.190]) [212.181.244.190] by mail.gmx.net (mp023) with SMTP; 26 Sep 2005 22:03:22 +0200 X-Authenticated: #29516787 Message-ID: <433853FD.209@gmx.net> Date: Mon, 26 Sep 2005 22:03:09 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton References: <20050926111300.GQ97112@finch-staff-1.thus.net> <4337F856.9000008@gmx.net> <43381116.2050301@gmx.net> <0F1F3FC6-0014-4B4D-95FD-4DCD2ACD701F@hxr.us> In-Reply-To: <0F1F3FC6-0014-4B4D-95FD-4DCD2ACD701F@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: [Ecrit] focus of the requirements draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi andy, > If this is the case, then we can safely drop the following > requirements: R7, UA-inserted, UA-referenced, Proxy-inserted, L28, > A1a, A1c, A3, A4, and all of Section 9. > > -andy > that's an important question that needs to be answered for the requirements and the security document. in the last few months we tried to remove as much as we can from the original documents to make them more "focused".. it is up to us to decide how far we would like to go. i know that this is quite difficult and that there is certainly no single best answer. you have been involved with all of the documents in the working group. what would you like to see? ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 26 21:06:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK3vs-0002BZ-GC; Mon, 26 Sep 2005 21:06:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK3vq-0002AW-Dk for ecrit@megatron.ietf.org; Mon, 26 Sep 2005 21:06:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22929 for ; Mon, 26 Sep 2005 21:06:53 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EK42x-0004ir-4y for ecrit@ietf.org; Mon, 26 Sep 2005 21:14:18 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j8R16nWa014393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Sep 2005 21:06:50 -0400 (EDT) Message-ID: <43389B4C.60206@cs.columbia.edu> Date: Mon, 26 Sep 2005 21:07:24 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom-PT Taylor References: <433837E5.1050004@nortel.com> In-Reply-To: <433837E5.1050004@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: ECRIT Subject: [Ecrit] Re: Summary ecrit-requirements-00 section 6: Emergency Identifier 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 Some comments inline. Tom-PT Taylor wrote: > > A1b: original formulation is seen as redundant, DELETED. New requirement: > > A1b': the mapping protocol also needs an emergency indication. > > Motivation: this allows reuse of the mapping protocol and the mapping > servers for non-emergency purposes. To avoid having two requirements that are essentially supersets of one another, we might simply say that it needs to indicate the emergency service (such as "fire") in jurisdictions where more than a single emergency service contact is provided. > A4. Minimal configuration. Any local logical emergency addresses should > be configured into user terminals automatically, without user intervention. > > Motivation: a new user terminal "unofficially imported" into an > organization from elsewhere should have the same emergency capabilities > as one officially installed. I think one distinction getting a bit lost is between the digits or symbols dialed by a user placing an emergency call and the call signaling emitted. The configuration is only necessary for the digits/symbols, as then the device can automatically translate into the "logical identifier". By using examples such as 911, the distinction between dial strings and identifiers is getting blurred. We had lots of problem with that in the 2806bis discussion and it would be unhelpful to muddy the waters again. Btw, the discussion here addresses ECRIT charter item "A BCP describing how to identify a session set-up request is to an emergency response center". Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 26 22:06:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK4rY-0005fk-4x; Mon, 26 Sep 2005 22:06:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK4rX-0005fJ-5B for ecrit@megatron.ietf.org; Mon, 26 Sep 2005 22:06:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25251 for ; Mon, 26 Sep 2005 22:06:29 -0400 (EDT) Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EK4yg-0005yK-Eh for ecrit@ietf.org; Mon, 26 Sep 2005 22:13:55 -0400 Received: from [10.0.1.102] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 26 Sep 2005 22:07:32 -0400 id 0158806A.4338A964.00004C36 In-Reply-To: <433853FD.209@gmx.net> References: <20050926111300.GQ97112@finch-staff-1.thus.net> <4337F856.9000008@gmx.net> <43381116.2050301@gmx.net> <0F1F3FC6-0014-4B4D-95FD-4DCD2ACD701F@hxr.us> <433853FD.209@gmx.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B28D96F-1B0C-4BE9-8184-9D177458196B@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Mon, 26 Sep 2005 22:06:14 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: ECRIT Subject: [Ecrit] Re: focus of the requirements draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Sep 26, 2005, at 4:03 PM, Hannes Tschofenig wrote: > hi andy, > > >> If this is the case, then we can safely drop the following >> requirements: R7, UA-inserted, UA-referenced, Proxy-inserted, >> L28, A1a, A1c, A3, A4, and all of Section 9. >> >> -andy >> >> > that's an important question that needs to be answered for the > requirements and the security document. in the last few months we > tried to remove as much as we can from the original documents to > make them more "focused".. > it is up to us to decide how far we would like to go. i know that > this is quite difficult and that there is certainly no single best > answer. > > you have been involved with all of the documents in the working > group. what would you like to see? Hannes, I was just pointing out an inconsistency. And I'll note that the requirements milestone does not say anything about just LCMS. Personally, I'd like us to rethink our milestones and break that first one out into two: a requirements document for the LCMS and a separate document describing the architecture and environment for the LCMS. One of the problems I think this group has is that many people have different views on how all the pieces will fit together. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 27 04:07:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKAUW-0003CJ-LZ; Tue, 27 Sep 2005 04:07:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKAUV-0003CB-L2 for ecrit@megatron.ietf.org; Tue, 27 Sep 2005 04:07:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21998 for ; Tue, 27 Sep 2005 04:07:06 -0400 (EDT) Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKAbh-0005L6-Vp for ecrit@ietf.org; Tue, 27 Sep 2005 04:14:35 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id j8R874HO008616; Tue, 27 Sep 2005 08:07:04 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1EKAUS-000P2p-00 for ecrit@ietf.org; Tue, 27 Sep 2005 09:07:04 +0100 Date: Tue, 27 Sep 2005 09:07:04 +0100 From: "Clive D.W. Feather" To: ECRIT Message-ID: <20050927080704.GA93011@finch-staff-1.thus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Ecrit] Comment on ecrit-requirements-00 item L10 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 Item L10 says that "The preferred coordinate reference system for emergency calls MUST be WGS-84". Firstly, I'm not sure how "MUST" interacts with "preferred". Secondly, in the UK the preferred coordinate system for emergency services is OSGB National Grid. Emergency services won't easily know what to do with a lat-long pair. Even if there is software at each end of the call to do the conversion, it feels the wrong thing to do; furthermore, as I understand it the conversion isn't exact and I'd hate a rounding error to creep in. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 27 10:22:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKGLW-00051m-DF; Tue, 27 Sep 2005 10:22:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKGLU-00051e-3R for ecrit@megatron.ietf.org; Tue, 27 Sep 2005 10:22:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11746 for ; Tue, 27 Sep 2005 10:22:10 -0400 (EDT) Received: from bay106-dav2.bay106.hotmail.com ([65.54.161.74] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKGSj-0006iB-Hj for ecrit@ietf.org; Tue, 27 Sep 2005 10:29:42 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 27 Sep 2005 07:22:01 -0700 Message-ID: Received: from 65.54.161.208 by BAY106-DAV2.phx.gbl with DAV; Tue, 27 Sep 2005 14:22:00 +0000 X-Originating-IP: [65.54.161.208] X-Originating-Email: [timothydunn01@msn.com] X-Sender: timothydunn01@msn.com From: "Tim Dunn" To: "'Clive D.W. Feather'" , "'ECRIT'" Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 Date: Tue, 27 Sep 2005 08:21:58 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-index: AcXDOsy3AnX97seySiGv4WaDAGWJBQAMkMOA In-Reply-To: AAAAAHid4H6cLVBKvI35MTImwgAHANlTnCJhprtFudq2LHCBs8EBACIA//8AANlTnCJhprtFudq2LHCBs8EBAHkmAAAAAA== X-OriginalArrivalTime: 27 Sep 2005 14:22:01.0266 (UTC) FILETIME=[D3882120:01C5C36E] X-Spam-Score: 1.6 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Clive- How about an alternate presentation of the requirement, specifically: A: The preferred coordinate reference system for emergency calls is WGS-84. B: Systems using coordinate reference systems other than WGS-84 (should/must) have the ability to perform coordinate transformation from the alternate system to WGS-84 and vice-versa. I feel the best classifier is MUST but I'm OK with SHOULD. Tim Dunn Timothy N. Dunn Consulting -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Clive D.W. Feather Sent: Tuesday, September 27, 2005 2:07 AM To: ECRIT Subject: [Ecrit] Comment on ecrit-requirements-00 item L10 Item L10 says that "The preferred coordinate reference system for emergency calls MUST be WGS-84". Firstly, I'm not sure how "MUST" interacts with "preferred". Secondly, in the UK the preferred coordinate system for emergency services is OSGB National Grid. Emergency services won't easily know what to do with a lat-long pair. Even if there is software at each end of the call to do the conversion, it feels the wrong thing to do; furthermore, as I understand it the conversion isn't exact and I'd hate a rounding error to creep in. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ 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 Sep 27 10:46:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKGiy-0002Mp-T1; Tue, 27 Sep 2005 10:46:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKGiw-0002Mg-Mv for ecrit@megatron.ietf.org; Tue, 27 Sep 2005 10:46:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13386 for ; Tue, 27 Sep 2005 10:46:25 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKGqC-0007I2-JD for ecrit@ietf.org; Tue, 27 Sep 2005 10:53:57 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 27 Sep 2005 07:46:16 -0700 X-IronPort-AV: i="3.97,150,1125903600"; d="scan'208"; a="345931492:sNHT30256812" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8REjq4r014860; Tue, 27 Sep 2005 07:46:14 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 07:46:11 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.82.145]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 07:46:10 -0700 Message-Id: <4.3.2.7.2.20050927094203.0364f838@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Sep 2005 09:46:09 -0500 To: "Tim Dunn" , "'Clive D.W. Feather'" , "'ECRIT'" From: "James M. Polk" Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Sep 2005 14:46:11.0088 (UTC) FILETIME=[33B16900:01C5C372] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 08:21 AM 9/27/2005 -0600, Tim Dunn wrote: >Clive- > >How about an alternate presentation of the requirement, specifically: > >A: The preferred coordinate reference system for emergency calls is WGS-84. >B: Systems using coordinate reference systems other than WGS-84 >(should/must) have the ability to perform coordinate transformation from the >alternate system to WGS-84 and vice-versa. Tim so what you're saying is: "we prefer you use WGS84, and if you don't, you (should/must) convert to/from it" ...this seems like a MUST to me dressed up to sound more palatable by those that don't use it. I agree with Clive - we cannot have the words "preferred" and "MUST" in the same sentence anywhere. >I feel the best classifier is MUST but I'm OK with SHOULD. > >Tim Dunn >Timothy N. Dunn Consulting > > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >Clive D.W. Feather >Sent: Tuesday, September 27, 2005 2:07 AM >To: ECRIT >Subject: [Ecrit] Comment on ecrit-requirements-00 item L10 > >Item L10 says that "The preferred coordinate reference system for emergency >calls MUST be WGS-84". > >Firstly, I'm not sure how "MUST" interacts with "preferred". > >Secondly, in the UK the preferred coordinate system for emergency services >is OSGB National Grid. Emergency services won't easily know what to do with >a lat-long pair. Even if there is software at each end of the call to do >the conversion, it feels the wrong thing to do; furthermore, as I >understand it the conversion isn't exact and I'd hate a rounding error to >creep in. > >-- >Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 >Internet Expert | Home: | Fax: +44 870 051 9937 >Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 >Thus plc | | > >_______________________________________________ >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 Tue Sep 27 11:08:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKH4U-0008J2-Jq; Tue, 27 Sep 2005 11:08:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKH4S-0008It-Tp for ecrit@megatron.ietf.org; Tue, 27 Sep 2005 11:08:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16301 for ; Tue, 27 Sep 2005 11:08:38 -0400 (EDT) Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EKHBi-00088T-M8 for ecrit@ietf.org; Tue, 27 Sep 2005 11:16:12 -0400 Received: (qmail invoked by alias); 27 Sep 2005 15:08:28 -0000 Received: from unknown (EHLO [192.168.0.133]) [195.84.156.34] by mail.gmx.net (mp015) with SMTP; 27 Sep 2005 17:08:28 +0200 X-Authenticated: #29516787 Message-ID: <43396066.9070101@gmx.net> Date: Tue, 27 Sep 2005 17:08:22 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton References: <20050926111300.GQ97112@finch-staff-1.thus.net> <4337F856.9000008@gmx.net> <43381116.2050301@gmx.net> <0F1F3FC6-0014-4B4D-95FD-4DCD2ACD701F@hxr.us> <433853FD.209@gmx.net> <0B28D96F-1B0C-4BE9-8184-9D177458196B@hxr.us> In-Reply-To: <0B28D96F-1B0C-4BE9-8184-9D177458196B@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: ECRIT Subject: [Ecrit] Re: focus of the requirements draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi andy, > Hannes, > > I was just pointing out an inconsistency. And I'll note that the > requirements milestone does not say anything about just LCMS. > sure. when the charter was written we haven't had the same understand as we have it today. > Personally, I'd like us to rethink our milestones and break that > first one out into two: a requirements document for the LCMS and a > separate document describing the architecture and environment for the > LCMS. One of the problems I think this group has is that many people > have different views on how all the pieces will fit together. > we already discussed whether it would be useful to work on an best current practice document describing the architecture. i got the impression that there was a strong agreement to have such a document. one question is whether we have to start to work on such a document soon. in previous discussions (e.g. at the interim meeting) i got the impression that people want to work on it but certainly not now (rather at some time in the future). i guess you do not suggest to work on two requirements document: (a) one for the lcms and (b) another one that is more generic. rethinking about the milestones is certainly needed. ciao hannes > -andy > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 27 11:11:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKH73-0000HP-Rk; Tue, 27 Sep 2005 11:11:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKH72-0000H7-6e for ecrit@megatron.ietf.org; Tue, 27 Sep 2005 11:11:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16688 for ; Tue, 27 Sep 2005 11:11:18 -0400 (EDT) Received: from bay106-dav15.bay106.hotmail.com ([65.54.161.87] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKHEH-0008EY-PC for ecrit@ietf.org; Tue, 27 Sep 2005 11:18:51 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 27 Sep 2005 08:11:08 -0700 Message-ID: Received: from 65.54.161.208 by BAY106-DAV15.phx.gbl with DAV; Tue, 27 Sep 2005 15:11:07 +0000 X-Originating-IP: [65.54.161.208] X-Originating-Email: [timothydunn01@msn.com] X-Sender: timothydunn01@msn.com From: "Tim Dunn" To: "'James M. Polk'" , "'Clive D.W. Feather'" , "'ECRIT'" Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 Date: Tue, 27 Sep 2005 09:11:04 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-index: AcXDcjc3keDJ+kSATnC1XwdMe85tgAAAk4bg In-Reply-To: AAAAAHid4H6cLVBKvI35MTImwgAHANlTnCJhprtFudq2LHCBs8EBACIA//8AANlTnCJhprtFudq2LHCBs8EBAIcmAAAAAA== X-OriginalArrivalTime: 27 Sep 2005 15:11:08.0650 (UTC) FILETIME=[B04F3CA0:01C5C375] X-Spam-Score: 1.6 (+) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think, yes, we prefer WGS-84 (I read that as the crux of that original requirement). But if you're using a coordinate system other than WGS-84, you should have a facility that allows you to convert from that system to WGS-84. By the way I said I preferred must in the second requirement but was OK with should (because I thought there would be consternation with requiring coordinate transformation). So to re-reword to a much more generic set of requirements that: A: The preferred coordinate reference system for emergency calls is WGS-84. B: Systems should have an ability to perform coordinate transformation between differing coordinate reference systems. Tim -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Tuesday, September 27, 2005 8:46 AM To: Tim Dunn; 'Clive D.W. Feather'; 'ECRIT' Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 At 08:21 AM 9/27/2005 -0600, Tim Dunn wrote: >Clive- > >How about an alternate presentation of the requirement, specifically: > >A: The preferred coordinate reference system for emergency calls is WGS-84. >B: Systems using coordinate reference systems other than WGS-84 >(should/must) have the ability to perform coordinate transformation from the >alternate system to WGS-84 and vice-versa. Tim so what you're saying is: "we prefer you use WGS84, and if you don't, you (should/must) convert to/from it" ..this seems like a MUST to me dressed up to sound more palatable by those that don't use it. I agree with Clive - we cannot have the words "preferred" and "MUST" in the same sentence anywhere. >I feel the best classifier is MUST but I'm OK with SHOULD. > >Tim Dunn >Timothy N. Dunn Consulting > > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >Clive D.W. Feather >Sent: Tuesday, September 27, 2005 2:07 AM >To: ECRIT >Subject: [Ecrit] Comment on ecrit-requirements-00 item L10 > >Item L10 says that "The preferred coordinate reference system for emergency >calls MUST be WGS-84". > >Firstly, I'm not sure how "MUST" interacts with "preferred". > >Secondly, in the UK the preferred coordinate system for emergency services >is OSGB National Grid. Emergency services won't easily know what to do with >a lat-long pair. Even if there is software at each end of the call to do >the conversion, it feels the wrong thing to do; furthermore, as I >understand it the conversion isn't exact and I'd hate a rounding error to >creep in. > >-- >Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 >Internet Expert | Home: | Fax: +44 870 051 9937 >Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 >Thus plc | | > >_______________________________________________ >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 Tue Sep 27 12:51:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKIgO-0002sL-FA; Tue, 27 Sep 2005 12:51:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKIgM-0002sB-Bb for ecrit@megatron.ietf.org; Tue, 27 Sep 2005 12:51:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25225 for ; Tue, 27 Sep 2005 12:51:51 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKIne-00031p-A8 for ecrit@ietf.org; Tue, 27 Sep 2005 12:59:26 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 27 Sep 2005 09:51:26 -0700 X-IronPort-AV: i="3.97,150,1125903600"; d="scan'208"; a="345977671:sNHT2074369324" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8RGpN4V020412; Tue, 27 Sep 2005 09:51:24 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 09:51:22 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.82.145]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 09:51:21 -0700 Message-Id: <4.3.2.7.2.20050927115042.0346fff8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Sep 2005 11:51:20 -0500 To: "Tim Dunn" , "'Clive D.W. Feather'" , "'ECRIT'" From: "James M. Polk" Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Sep 2005 16:51:21.0428 (UTC) FILETIME=[B0345940:01C5C383] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 09:11 AM 9/27/2005 -0600, Tim Dunn wrote: >I think, yes, we prefer WGS-84 (I read that as the crux of that original >requirement). But if you're using a coordinate system other than WGS-84, you >should have a facility that allows you to convert from that system to >WGS-84. > >By the way I said I preferred must in the second requirement but was OK with >should (because I thought there would be consternation with requiring >coordinate transformation). > >So to re-reword to a much more generic set of requirements that: > >A: The preferred coordinate reference system for emergency calls is WGS-84. >B: Systems should have an ability to perform coordinate transformation >between differing coordinate reference systems.... ...to WGS84. then I agree with this wording >Tim > > >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: Tuesday, September 27, 2005 8:46 AM >To: Tim Dunn; 'Clive D.W. Feather'; 'ECRIT' >Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 > >At 08:21 AM 9/27/2005 -0600, Tim Dunn wrote: > >Clive- > > > >How about an alternate presentation of the requirement, specifically: > > > >A: The preferred coordinate reference system for emergency calls is >WGS-84. > >B: Systems using coordinate reference systems other than WGS-84 > >(should/must) have the ability to perform coordinate transformation from >the > >alternate system to WGS-84 and vice-versa. > >Tim > >so what you're saying is: > > "we prefer you use WGS84, and if you don't, you (should/must) > convert to/from it" > >..this seems like a MUST to me dressed up to sound more palatable by those >that don't use it. > >I agree with Clive - we cannot have the words "preferred" and "MUST" in the >same sentence anywhere. > > > >I feel the best classifier is MUST but I'm OK with SHOULD. > > > >Tim Dunn > >Timothy N. Dunn Consulting > > > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > >Clive D.W. Feather > >Sent: Tuesday, September 27, 2005 2:07 AM > >To: ECRIT > >Subject: [Ecrit] Comment on ecrit-requirements-00 item L10 > > > >Item L10 says that "The preferred coordinate reference system for emergency > >calls MUST be WGS-84". > > > >Firstly, I'm not sure how "MUST" interacts with "preferred". > > > >Secondly, in the UK the preferred coordinate system for emergency services > >is OSGB National Grid. Emergency services won't easily know what to do with > >a lat-long pair. Even if there is software at each end of the call to do > >the conversion, it feels the wrong thing to do; furthermore, as I > >understand it the conversion isn't exact and I'd hate a rounding error to > >creep in. > > > >-- > >Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 > >Internet Expert | Home: | Fax: +44 870 051 9937 > >Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 > >Thus plc | | > > > >_______________________________________________ > >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. 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 Tue Sep 27 14:22:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKK5e-00006A-Ha; Tue, 27 Sep 2005 14:22:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKK5O-0008Qd-Ri for ecrit@megatron.ietf.org; Tue, 27 Sep 2005 14:21:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29662 for ; Tue, 27 Sep 2005 14:21:49 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKKCg-0005S9-3b for ecrit@ietf.org; Tue, 27 Sep 2005 14:29:23 -0400 Received: from zctfhxm0.corp.nortel.com (zctfhxm0.corp.nortel.com [47.164.129.155]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j8RIKUH25543; Tue, 27 Sep 2005 20:20:30 +0200 (MEST) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zctfhxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 20:20:30 +0200 Received: from [127.0.0.1] ([47.130.17.225] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 14:20:28 -0400 Message-ID: <43398D67.60006@nortel.com> Date: Tue, 27 Sep 2005 14:20:23 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] Comment on ecrit-requirements-00 item L10 References: <4.3.2.7.2.20050927115042.0346fff8@email.cisco.com> In-Reply-To: <4.3.2.7.2.20050927115042.0346fff8@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Sep 2005 18:20:28.0195 (UTC) FILETIME=[23203F30:01C5C390] X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I don't see why a UK system (not sure what "system" refers to, BTW) would want to convert to WGS-84. I would think it would be the other way around. James M. Polk wrote: > At 09:11 AM 9/27/2005 -0600, Tim Dunn wrote: > >> I think, yes, we prefer WGS-84 (I read that as the crux of that original >> requirement). But if you're using a coordinate system other than >> WGS-84, you >> should have a facility that allows you to convert from that system to >> WGS-84. >> >> By the way I said I preferred must in the second requirement but was >> OK with >> should (because I thought there would be consternation with requiring >> coordinate transformation). >> >> So to re-reword to a much more generic set of requirements that: >> >> A: The preferred coordinate reference system for emergency calls is >> WGS-84. >> B: Systems should have an ability to perform coordinate transformation >> between differing coordinate reference systems.... > > > ...to WGS84. > > then I agree with this wording > > > >> Tim >> >> >> -----Original Message----- >> From: James M. Polk [mailto:jmpolk@cisco.com] >> Sent: Tuesday, September 27, 2005 8:46 AM >> To: Tim Dunn; 'Clive D.W. Feather'; 'ECRIT' >> Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 >> >> At 08:21 AM 9/27/2005 -0600, Tim Dunn wrote: >> >Clive- >> > >> >How about an alternate presentation of the requirement, specifically: >> > >> >A: The preferred coordinate reference system for emergency calls is >> WGS-84. >> >B: Systems using coordinate reference systems other than WGS-84 >> >(should/must) have the ability to perform coordinate transformation from >> the >> >alternate system to WGS-84 and vice-versa. >> >> Tim >> >> so what you're saying is: >> >> "we prefer you use WGS84, and if you don't, you (should/must) >> convert to/from it" >> >> ..this seems like a MUST to me dressed up to sound more palatable by >> those >> that don't use it. >> >> I agree with Clive - we cannot have the words "preferred" and "MUST" >> in the >> same sentence anywhere. >> >> >> >I feel the best classifier is MUST but I'm OK with SHOULD. >> > >> >Tim Dunn >> >Timothy N. Dunn Consulting >> > >> > >> >-----Original Message----- >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf Of >> >Clive D.W. Feather >> >Sent: Tuesday, September 27, 2005 2:07 AM >> >To: ECRIT >> >Subject: [Ecrit] Comment on ecrit-requirements-00 item L10 >> > >> >Item L10 says that "The preferred coordinate reference system for >> emergency >> >calls MUST be WGS-84". >> > >> >Firstly, I'm not sure how "MUST" interacts with "preferred". >> > >> >Secondly, in the UK the preferred coordinate system for emergency >> services >> >is OSGB National Grid. Emergency services won't easily know what to >> do with >> >a lat-long pair. Even if there is software at each end of the call to do >> >the conversion, it feels the wrong thing to do; furthermore, as I >> >understand it the conversion isn't exact and I'd hate a rounding >> error to >> >creep in. >> > >> >-- >> >Clive D.W. Feather | Work: | Tel: +44 20 >> 8495 6138 >> >Internet Expert | Home: | Fax: +44 870 >> 051 9937 >> >Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 >> 377646 >> >Thus plc | | >> > >> >_______________________________________________ >> >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. > > > > 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 Tue Sep 27 15:11:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKKrv-0004W0-BO; Tue, 27 Sep 2005 15:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKKru-0004VD-DJ for ecrit@megatron.ietf.org; Tue, 27 Sep 2005 15:11:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02583 for ; Tue, 27 Sep 2005 15:11:57 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKKzB-0006fp-3c for ecrit@ietf.org; Tue, 27 Sep 2005 15:19:31 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 27 Sep 2005 12:11:45 -0700 X-IronPort-AV: i="3.97,150,1125903600"; d="scan'208"; a="215253191:sNHT34470492" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8RJBUKI001848; Tue, 27 Sep 2005 12:11:38 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 15:11:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 Date: Tue, 27 Sep 2005 15:11:41 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E39C9738@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Comment on ecrit-requirements-00 item L10 Thread-Index: AcXDcjc3keDJ+kSATnC1XwdMe85tgAAAk4bgAAihP3A= From: "Michael Hammer \(mhammer\)" To: "Tim Dunn" , "James Polk \(jmpolk\)" , "Clive D.W. Feather" , "ECRIT" X-OriginalArrivalTime: 27 Sep 2005 19:11:41.0989 (UTC) FILETIME=[4B3FFD50:01C5C397] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Where is "preferred" in RFC 2119? Also, is the IETF establishing some sort of national variant, or are we saying here is the global method and if you like national variants, do the conversion at the local site that uses the data. Mike =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Tim Dunn > Sent: Tuesday, September 27, 2005 11:11 AM > To: James Polk (jmpolk); 'Clive D.W. Feather'; 'ECRIT' > Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 >=20 > I think, yes, we prefer WGS-84 (I read that as the crux of=20 > that original requirement). But if you're using a coordinate=20 > system other than WGS-84, you should have a facility that=20 > allows you to convert from that system to WGS-84. >=20 > By the way I said I preferred must in the second requirement=20 > but was OK with should (because I thought there would be=20 > consternation with requiring coordinate transformation). >=20 > So to re-reword to a much more generic set of requirements that: >=20 > A: The preferred coordinate reference system for emergency=20 > calls is WGS-84. > B: Systems should have an ability to perform coordinate=20 > transformation between differing coordinate reference systems. >=20 >=20 > Tim >=20 >=20 > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Tuesday, September 27, 2005 8:46 AM > To: Tim Dunn; 'Clive D.W. Feather'; 'ECRIT' > Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 >=20 > At 08:21 AM 9/27/2005 -0600, Tim Dunn wrote: > >Clive- > > > >How about an alternate presentation of the requirement, specifically: > > > >A: The preferred coordinate reference system for emergency calls is > WGS-84. > >B: Systems using coordinate reference systems other than WGS-84 > >(should/must) have the ability to perform coordinate transformation=20 > >from > the > >alternate system to WGS-84 and vice-versa. >=20 > Tim >=20 > so what you're saying is: >=20 > "we prefer you use WGS84, and if you don't, you (should/must) > convert to/from it" >=20 > ..this seems like a MUST to me dressed up to sound more=20 > palatable by those that don't use it. >=20 > I agree with Clive - we cannot have the words "preferred" and=20 > "MUST" in the same sentence anywhere. >=20 >=20 > >I feel the best classifier is MUST but I'm OK with SHOULD. > > > >Tim Dunn > >Timothy N. Dunn Consulting > > > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of > >Clive D.W. Feather > >Sent: Tuesday, September 27, 2005 2:07 AM > >To: ECRIT > >Subject: [Ecrit] Comment on ecrit-requirements-00 item L10 > > > >Item L10 says that "The preferred coordinate reference=20 > system for emergency > >calls MUST be WGS-84". > > > >Firstly, I'm not sure how "MUST" interacts with "preferred". > > > >Secondly, in the UK the preferred coordinate system for=20 > emergency services > >is OSGB National Grid. Emergency services won't easily know=20 > what to do with > >a lat-long pair. Even if there is software at each end of=20 > the call to do > >the conversion, it feels the wrong thing to do; furthermore, as I > >understand it the conversion isn't exact and I'd hate a=20 > rounding error to > >creep in. > > > >-- > >Clive D.W. Feather | Work: | Tel: =20 > +44 20 8495 6138 > >Internet Expert | Home: | Fax: =20 > +44 870 051 9937 > >Demon Internet | WWW: http://www.davros.org | Mobile:=20 > +44 7973 377646 > >Thus plc | | > > > >_______________________________________________ > >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 > 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 From ecrit-bounces@ietf.org Tue Sep 27 15:14:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKKuQ-00050Y-Rb; Tue, 27 Sep 2005 15:14:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKKuQ-00050T-6V for ecrit@megatron.ietf.org; Tue, 27 Sep 2005 15:14:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02847 for ; Tue, 27 Sep 2005 15:14:32 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKL1h-0006jl-VJ for ecrit@ietf.org; Tue, 27 Sep 2005 15:22:07 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Tue, 27 Sep 2005 15:14:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 Date: Tue, 27 Sep 2005 12:14:12 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575033411DA@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Comment on ecrit-requirements-00 item L10 Thread-Index: AcXDkHNW0J+mdt4SQsWqLyBirHUStAAA+s0A From: "Roger Marshall" To: "Tom-PT Taylor" , "James M. Polk" , "Clive D.W. Feather" X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I don't think that use of the OSGB should be prevented, but do think that WGS-84 should be the sole standard referred to, mostly because wgs-84 is already prevalent and is global in scope, whereas OSGB does not have the same reach. I agree with Clive's first point and other subsequent suggestions from James & Tim. So to clarify L10 as to "preferred" vs. "MUST", I proposed text (item added to issue tracker at, http://www.ietf-ecrit.org:8080/ecrit-req/) So the proposal is to reword L10 into two separate requirements, "L10a. Reference Datum: The preferred coordinate reference system is WGS-84." "L10b. Reference Datum Conversion: Systems SHOULD support the ability to perform coordinate transformation from any used coordinate reference system to the WGS-84 coordinate reference system." Roger Marshall >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Tom-PT Taylor >Sent: Tuesday, September 27, 2005 11:20 AM >To: James M. Polk >Cc: 'ECRIT' >Subject: Re: [Ecrit] Comment on ecrit-requirements-00 item L10 > >I don't see why a UK system (not sure what "system" refers to,=20 >BTW) would want to convert to WGS-84. I would think it would=20 >be the other way around. > >James M. Polk wrote: >> At 09:11 AM 9/27/2005 -0600, Tim Dunn wrote: >>=20 >>> I think, yes, we prefer WGS-84 (I read that as the crux of that=20 >>> original requirement). But if you're using a coordinate=20 >system other=20 >>> than WGS-84, you should have a facility that allows you to convert=20 >>> from that system to WGS-84. >>> >>> By the way I said I preferred must in the second=20 >requirement but was=20 >>> OK with should (because I thought there would be consternation with=20 >>> requiring coordinate transformation). >>> >>> So to re-reword to a much more generic set of requirements that: >>> >>> A: The preferred coordinate reference system for emergency=20 >calls is=20 >>> WGS-84. >>> B: Systems should have an ability to perform coordinate=20 >>> transformation between differing coordinate reference systems.... >>=20 >>=20 >> ...to WGS84. >>=20 >> then I agree with this wording >>=20 >>=20 >>=20 >>> Tim >>> >>> >>> -----Original Message----- >>> From: James M. Polk [mailto:jmpolk@cisco.com] >>> Sent: Tuesday, September 27, 2005 8:46 AM >>> To: Tim Dunn; 'Clive D.W. Feather'; 'ECRIT' >>> Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 >>> >>> At 08:21 AM 9/27/2005 -0600, Tim Dunn wrote: >>> >Clive- >>> > >>> >How about an alternate presentation of the requirement,=20 >specifically: >>> > >>> >A: The preferred coordinate reference system for=20 >emergency calls is >>> WGS-84. >>> >B: Systems using coordinate reference systems other than WGS-84 >>> >(should/must) have the ability to perform coordinate=20 >transformation=20 >>> >from >>> the >>> >alternate system to WGS-84 and vice-versa. >>> >>> Tim >>> >>> so what you're saying is: >>> >>> "we prefer you use WGS84, and if you don't, you=20 >(should/must) >>> convert to/from it" >>> >>> ..this seems like a MUST to me dressed up to sound more=20 >palatable by=20 >>> those that don't use it. >>> >>> I agree with Clive - we cannot have the words "preferred"=20 >and "MUST"=20 >>> in the >>> same sentence anywhere. >>> >>> >>> >I feel the best classifier is MUST but I'm OK with SHOULD. >>> > >>> >Tim Dunn >>> >Timothy N. Dunn Consulting >>> > >>> > >>> >-----Original Message----- >>> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> Behalf Of >>> >Clive D.W. Feather >>> >Sent: Tuesday, September 27, 2005 2:07 AM >>> >To: ECRIT >>> >Subject: [Ecrit] Comment on ecrit-requirements-00 item L10 >>> > >>> >Item L10 says that "The preferred coordinate reference system for >>> emergency >>> >calls MUST be WGS-84". >>> > >>> >Firstly, I'm not sure how "MUST" interacts with "preferred". >>> > >>> >Secondly, in the UK the preferred coordinate system for emergency >>> services >>> >is OSGB National Grid. Emergency services won't easily know what to >>> do with >>> >a lat-long pair. Even if there is software at each end of the call=20 >>> >to do the conversion, it feels the wrong thing to do; furthermore,=20 >>> >as I understand it the conversion isn't exact and I'd hate a=20 >>> >rounding >>> error to >>> >creep in. >>> > >>> >-- >>> >Clive D.W. Feather | Work: | Tel: +44 20=20 >>> 8495 6138 >>> >Internet Expert | Home: | Fax: +44 870=20 >>> 051 9937 >>> >Demon Internet | WWW: http://www.davros.org | Mobile:=20 >+44 7973=20 >>> 377646 >>> >Thus plc | | >>> > >>> >_______________________________________________ >>> >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. >>=20 >>=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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 27 16:14:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKLoI-0005xG-2K; Tue, 27 Sep 2005 16:12:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKLoG-0005x0-K2 for ecrit@megatron.ietf.org; Tue, 27 Sep 2005 16:12:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11341 for ; Tue, 27 Sep 2005 16:12:13 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKLvY-0001jE-Ox for ecrit@ietf.org; Tue, 27 Sep 2005 16:19:49 -0400 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 j8RKC9Wk013460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Sep 2005 16:12:10 -0400 (EDT) Message-ID: <4339A770.1000807@cs.columbia.edu> Date: Tue, 27 Sep 2005 16:11:28 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom-PT Taylor Subject: Re: [Ecrit] Comment on ecrit-requirements-00 item L10 References: <4.3.2.7.2.20050927115042.0346fff8@email.cisco.com> <43398D67.60006@nortel.com> In-Reply-To: <43398D67.60006@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CHILD_PORN_NOT_1 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_TINHORN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Given that a phone made in Japan, say, has to work when the owner visits London, using a local mapping server, support for a common datum seems pretty much required. Otherwise, we have to have a discovery mechanism for mapping servers based on the datum they support - I don't think we'd want that. (Our core assumption is that there may not be a service provider, so the Japanese tourist in London may not have a "home" provider to go ask, either.) Tom-PT Taylor wrote: > I don't see why a UK system (not sure what "system" refers to, BTW) > would want to convert to WGS-84. I would think it would be the other > way around. > > James M. Polk wrote: > >> At 09:11 AM 9/27/2005 -0600, Tim Dunn wrote: >> >>> I think, yes, we prefer WGS-84 (I read that as the crux of that original >>> requirement). But if you're using a coordinate system other than >>> WGS-84, you >>> should have a facility that allows you to convert from that system to >>> WGS-84. >>> >>> By the way I said I preferred must in the second requirement but was >>> OK with >>> should (because I thought there would be consternation with requiring >>> coordinate transformation). >>> >>> So to re-reword to a much more generic set of requirements that: >>> >>> A: The preferred coordinate reference system for emergency calls is >>> WGS-84. >>> B: Systems should have an ability to perform coordinate transformation >>> between differing coordinate reference systems.... >> >> >> >> ...to WGS84. >> >> then I agree with this wording >> >> >> >>> Tim >>> >>> >>> -----Original Message----- >>> From: James M. Polk [mailto:jmpolk@cisco.com] >>> Sent: Tuesday, September 27, 2005 8:46 AM >>> To: Tim Dunn; 'Clive D.W. Feather'; 'ECRIT' >>> Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 >>> >>> At 08:21 AM 9/27/2005 -0600, Tim Dunn wrote: >>> >Clive- >>> > >>> >How about an alternate presentation of the requirement, specifically: >>> > >>> >A: The preferred coordinate reference system for emergency calls is >>> WGS-84. >>> >B: Systems using coordinate reference systems other than WGS-84 >>> >(should/must) have the ability to perform coordinate transformation >>> from >>> the >>> >alternate system to WGS-84 and vice-versa. >>> >>> Tim >>> >>> so what you're saying is: >>> >>> "we prefer you use WGS84, and if you don't, you (should/must) >>> convert to/from it" >>> >>> ..this seems like a MUST to me dressed up to sound more palatable by >>> those >>> that don't use it. >>> >>> I agree with Clive - we cannot have the words "preferred" and "MUST" >>> in the >>> same sentence anywhere. >>> >>> >>> >I feel the best classifier is MUST but I'm OK with SHOULD. >>> > >>> >Tim Dunn >>> >Timothy N. Dunn Consulting >>> > >>> > >>> >-----Original Message----- >>> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> Behalf Of >>> >Clive D.W. Feather >>> >Sent: Tuesday, September 27, 2005 2:07 AM >>> >To: ECRIT >>> >Subject: [Ecrit] Comment on ecrit-requirements-00 item L10 >>> > >>> >Item L10 says that "The preferred coordinate reference system for >>> emergency >>> >calls MUST be WGS-84". >>> > >>> >Firstly, I'm not sure how "MUST" interacts with "preferred". >>> > >>> >Secondly, in the UK the preferred coordinate system for emergency >>> services >>> >is OSGB National Grid. Emergency services won't easily know what to >>> do with >>> >a lat-long pair. Even if there is software at each end of the call >>> to do >>> >the conversion, it feels the wrong thing to do; furthermore, as I >>> >understand it the conversion isn't exact and I'd hate a rounding >>> error to >>> >creep in. >>> > >>> >-- >>> >Clive D.W. Feather | Work: | Tel: +44 20 >>> 8495 6138 >>> >Internet Expert | Home: | Fax: +44 870 >>> 051 9937 >>> >Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 >>> 377646 >>> >Thus plc | | >>> > >>> >_______________________________________________ >>> >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. >> >> >> >> >> 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 Tue Sep 27 16:28:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKM3Z-0004St-MM; Tue, 27 Sep 2005 16:28:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKM3Y-0004Sa-NF for ecrit@megatron.ietf.org; Tue, 27 Sep 2005 16:28:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18209 for ; Tue, 27 Sep 2005 16:28:00 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKMAo-0004Iq-16 for ecrit@ietf.org; Tue, 27 Sep 2005 16:35:35 -0400 Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j8RKRaH16722; Tue, 27 Sep 2005 22:27:36 +0200 (MEST) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zharhxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 21:27:36 +0100 Received: from [127.0.0.1] ([47.130.17.225] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 16:27:34 -0400 Message-ID: <4339AB31.90502@nortel.com> Date: Tue, 27 Sep 2005 16:27:29 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Comment on ecrit-requirements-00 item L10 References: <4.3.2.7.2.20050927115042.0346fff8@email.cisco.com> <43398D67.60006@nortel.com> <4339A770.1000807@cs.columbia.edu> In-Reply-To: <4339A770.1000807@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Sep 2005 20:27:34.0599 (UTC) FILETIME=[E4D12570:01C5C3A1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org We have two requirements: (1) create a workable mapping system; (2) provide location to the PSAP and beyond in a form they can use. These two requirements seem to conflict if PSAPs and/or emergency services use something other than WGS-84. The key issues are: - where is the best place to do the conversion; - do we have any hope of specifying the coordinate system that must be used when creating a geolocation? Henning Schulzrinne wrote: > Given that a phone made in Japan, say, has to work when the owner visits > London, using a local mapping server, support for a common datum seems > pretty much required. Otherwise, we have to have a discovery mechanism > for mapping servers based on the datum they support - I don't think we'd > want that. (Our core assumption is that there may not be a service > provider, so the Japanese tourist in London may not have a "home" > provider to go ask, either.) > > Tom-PT Taylor wrote: > >> I don't see why a UK system (not sure what "system" refers to, BTW) >> would want to convert to WGS-84. I would think it would be the other >> way around. >> ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 27 16:42:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKMHH-00031C-Sh; Tue, 27 Sep 2005 16:42:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKMHF-0002zQ-KI for ecrit@megatron.ietf.org; Tue, 27 Sep 2005 16:42:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAB19374 for ; Tue, 27 Sep 2005 16:42:11 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKMOZ-0004pC-Nb for ecrit@ietf.org; Tue, 27 Sep 2005 16:49:47 -0400 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 j8RKg8Wk015254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Sep 2005 16:42:09 -0400 (EDT) Message-ID: <4339AE78.4040403@cs.columbia.edu> Date: Tue, 27 Sep 2005 16:41:28 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom-PT Taylor Subject: Re: [Ecrit] Comment on ecrit-requirements-00 item L10 References: <4.3.2.7.2.20050927115042.0346fff8@email.cisco.com> <43398D67.60006@nortel.com> <4339A770.1000807@cs.columbia.edu> <4339AB31.90502@nortel.com> In-Reply-To: <4339AB31.90502@nortel.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, __FRAUD_419_TINHORN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org How much effort is datum conversion in practice? Given that the number of mapping servers and PSAPs is orders of magnitude lower than the number of users and that those servers and PSAPs are operated by people who know something about datums (as opposed to most client developers...), I think putting the conversion burden on mapping servers and PSAPs is the better decision, unless there's no way to convert these data representations with reliability at all. Tom-PT Taylor wrote: > We have two requirements: > (1) create a workable mapping system; > (2) provide location to the PSAP and beyond in a form they can use. > > These two requirements seem to conflict if PSAPs and/or emergency > services use something other than WGS-84. The key issues are: > - where is the best place to do the conversion; > - do we have any hope of specifying the coordinate system that must be > used when creating a geolocation? > > Henning Schulzrinne wrote: > >> Given that a phone made in Japan, say, has to work when the owner >> visits London, using a local mapping server, support for a common >> datum seems pretty much required. Otherwise, we have to have a >> discovery mechanism for mapping servers based on the datum they >> support - I don't think we'd want that. (Our core assumption is that >> there may not be a service provider, so the Japanese tourist in London >> may not have a "home" provider to go ask, either.) >> >> Tom-PT Taylor wrote: >> >>> I don't see why a UK system (not sure what "system" refers to, BTW) >>> would want to convert to WGS-84. I would think it would be the other >>> way around. >>> > ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 27 18:38:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKO5x-0004B7-2Q; Tue, 27 Sep 2005 18:38:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKO5v-0004Az-Gl for ecrit@megatron.ietf.org; Tue, 27 Sep 2005 18:38:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26220 for ; Tue, 27 Sep 2005 18:38:37 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKODE-0007kH-Dm for ecrit@ietf.org; Tue, 27 Sep 2005 18:46:14 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 17:38:18 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 27 Sep 2005 17:38:17 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 17:38:10 -0500 Message-ID: From: "Thomson, Martin" To: "James M. Polk" , "Tim Dunn" , "Clive D.W. Feather" , "ECRIT" Date: Tue, 27 Sep 2005 17:38:14 -0500 Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 27 Sep 2005 22:38:10.0588 (UTC) FILETIME=[236E2DC0:01C5C3B4] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Comment on ecrit-requirements-00 item L10 Thread-Index: AcXDg/CCHdV2GtXJTZGMhdGkZwAjOwALlhNg X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1515914864==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============1515914864== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message Content-Transfer-Encoding: base64 VGhpcyBzb3VuZHMgcmVtYXJrYWJseSBsaWtlIHNpbWlsYXIgc3RhdGVtZW50cyBJIGhhdmUgcmVh ZCBvbiBVVEYtOCBzdXBwb3J0IGluIFhNTCBhbmQgbWFueSBwcm90b2NvbCBzcGVjcy4gIFdoYXQg eW91IHdhbnQgaXMgYSBjb21tb24gYmFzZWxpbmUgdGhhdCBldmVyeW9uZSB1bmRlcnN0YW5kcywg b3RoZXJ3aXNlIGludGVyb3BlcmF0aW9uIGJlY29tZXMgY2hhbGxlbmdpbmcuICBJJ2Qgc3VnZ2Vz dCBhIE1VU1QgaXMgYmV0dGVyLg0KDQpBbHNvIHRoZSB3b3JkaW5nIHRoYXQgeW91IGhhdmUgY2hv c2VuIGNvdWxkIGJlIGludGVycHJldGVkIGFzIHJlcXVpcmluZyBpbXBsZW1lbnRhdGlvbnMgdG8g Y29udmVydCBmcm9tIGFyYml0cmFyeSBDUlMncy4gIEluc3RlYWQgc3VnZ2VzdCBzb21ldGhpbmcg bGlrZToNCg0KIkltcGxlbWVudGF0aW9ucyBNVVNUIHN1cHBvcnQgdGhlIFdHUy04NCBjb29yZGlu YXRlIHJlZmVyZW5jZSBzeXN0ZW0gZm9yIGVtZXJnZW5jeSBjYWxscy4gIEltcGxlbWVudGF0aW9u cyBNQVkgc3VwcG9ydCBvdGhlciBjb29yZGluYXRlIHJlZmVyZW5jZSBzeXN0ZW1zLCBidXQgdGhl eSBNVVNUIGJlIGFibGUgdG8gcGVyZm9ybSBhIGNvb3JkaW5hdGUgdHJhbnNmb3JtYXRpb24gdG8g V0dTLTg0IHdoZXJlIG5lY2Vzc2FyeS4iDQoNClRoZXJlIGlzIGEgcHJlY2VkZW50IGZvciB0aGlz IHNvcnQgb2Ygc3RhdGVtZW50LCBzZWUgU2VjdGlvbiA3Ljggb2Y6IA0KaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1nZW9wcml2LXBkaWYtbG8tcHJvZmlsZS0w MS50eHQNCg0KQ2hlZXJzLA0KTWFydGluDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEphbWVzIE0uIFBvbGsNClNlbnQ6IFdlZG5lc2RheSwgMjggU2VwdGVt YmVyIDIwMDUgMjo1MSBBTQ0KVG86IFRpbSBEdW5uOyAnQ2xpdmUgRC5XLiBGZWF0aGVyJzsgJ0VD UklUJw0KU3ViamVjdDogUkU6IFtFY3JpdF0gQ29tbWVudCBvbiBlY3JpdC1yZXF1aXJlbWVudHMt MDAgaXRlbSBMMTANCg0KQXQgMDk6MTEgQU0gOS8yNy8yMDA1IC0wNjAwLCBUaW0gRHVubiB3cm90 ZToNCj5JIHRoaW5rLCB5ZXMsIHdlIHByZWZlciBXR1MtODQgKEkgcmVhZCB0aGF0IGFzIHRoZSBj cnV4IG9mIHRoYXQgb3JpZ2luYWwNCj5yZXF1aXJlbWVudCkuIEJ1dCBpZiB5b3UncmUgdXNpbmcg YSBjb29yZGluYXRlIHN5c3RlbSBvdGhlciB0aGFuIFdHUy04NCwgeW91DQo+c2hvdWxkIGhhdmUg YSBmYWNpbGl0eSB0aGF0IGFsbG93cyB5b3UgdG8gY29udmVydCBmcm9tIHRoYXQgc3lzdGVtIHRv DQo+V0dTLTg0Lg0KPg0KPkJ5IHRoZSB3YXkgSSBzYWlkIEkgcHJlZmVycmVkIG11c3QgaW4gdGhl IHNlY29uZCByZXF1aXJlbWVudCBidXQgd2FzIE9LIHdpdGgNCj5zaG91bGQgKGJlY2F1c2UgSSB0 aG91Z2h0IHRoZXJlIHdvdWxkIGJlIGNvbnN0ZXJuYXRpb24gd2l0aCByZXF1aXJpbmcNCj5jb29y ZGluYXRlIHRyYW5zZm9ybWF0aW9uKS4NCj4NCj5TbyB0byByZS1yZXdvcmQgdG8gYSBtdWNoIG1v cmUgZ2VuZXJpYyBzZXQgb2YgcmVxdWlyZW1lbnRzIHRoYXQ6DQo+DQo+QTogIFRoZSBwcmVmZXJy ZWQgY29vcmRpbmF0ZSByZWZlcmVuY2Ugc3lzdGVtIGZvciBlbWVyZ2VuY3kgY2FsbHMgaXMgV0dT LTg0Lg0KPkI6ICBTeXN0ZW1zIHNob3VsZCBoYXZlIGFuIGFiaWxpdHkgdG8gcGVyZm9ybSBjb29y ZGluYXRlIHRyYW5zZm9ybWF0aW9uDQo+YmV0d2VlbiBkaWZmZXJpbmcgY29vcmRpbmF0ZSByZWZl cmVuY2Ugc3lzdGVtcy4uLi4NCg0KLi4udG8gV0dTODQuDQoNCnRoZW4gSSBhZ3JlZSB3aXRoIHRo aXMgd29yZGluZw0KDQoNCg0KPlRpbQ0KPg0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+RnJvbTogSmFtZXMgTS4gUG9sayBbbWFpbHRvOmptcG9sa0BjaXNjby5jb21dDQo+U2VudDog VHVlc2RheSwgU2VwdGVtYmVyIDI3LCAyMDA1IDg6NDYgQU0NCj5UbzogVGltIER1bm47ICdDbGl2 ZSBELlcuIEZlYXRoZXInOyAnRUNSSVQnDQo+U3ViamVjdDogUkU6IFtFY3JpdF0gQ29tbWVudCBv biBlY3JpdC1yZXF1aXJlbWVudHMtMDAgaXRlbSBMMTANCj4NCj5BdCAwODoyMSBBTSA5LzI3LzIw MDUgLTA2MDAsIFRpbSBEdW5uIHdyb3RlOg0KPiA+Q2xpdmUtDQo+ID4NCj4gPkhvdyBhYm91dCBh biBhbHRlcm5hdGUgcHJlc2VudGF0aW9uIG9mIHRoZSByZXF1aXJlbWVudCwgc3BlY2lmaWNhbGx5 Og0KPiA+DQo+ID5BOiAgVGhlIHByZWZlcnJlZCBjb29yZGluYXRlIHJlZmVyZW5jZSBzeXN0ZW0g Zm9yIGVtZXJnZW5jeSBjYWxscyBpcw0KPldHUy04NC4NCj4gPkI6ICBTeXN0ZW1zIHVzaW5nIGNv b3JkaW5hdGUgcmVmZXJlbmNlIHN5c3RlbXMgb3RoZXIgdGhhbiBXR1MtODQNCj4gPihzaG91bGQv bXVzdCkgaGF2ZSB0aGUgYWJpbGl0eSB0byBwZXJmb3JtIGNvb3JkaW5hdGUgdHJhbnNmb3JtYXRp b24gZnJvbQ0KPnRoZQ0KPiA+YWx0ZXJuYXRlIHN5c3RlbSB0byBXR1MtODQgYW5kIHZpY2UtdmVy c2EuDQo+DQo+VGltDQo+DQo+c28gd2hhdCB5b3UncmUgc2F5aW5nIGlzOg0KPg0KPiAgICAgICAg ICAid2UgcHJlZmVyIHlvdSB1c2UgV0dTODQsIGFuZCBpZiB5b3UgZG9uJ3QsIHlvdSAoc2hvdWxk L211c3QpDQo+ICAgICAgICAgICAgY29udmVydCB0by9mcm9tIGl0Ig0KPg0KPi4udGhpcyBzZWVt cyBsaWtlIGEgTVVTVCB0byBtZSBkcmVzc2VkIHVwIHRvIHNvdW5kIG1vcmUgcGFsYXRhYmxlIGJ5 IHRob3NlDQo+dGhhdCBkb24ndCB1c2UgaXQuDQo+DQo+SSBhZ3JlZSB3aXRoIENsaXZlIC0gd2Ug Y2Fubm90IGhhdmUgdGhlIHdvcmRzICJwcmVmZXJyZWQiIGFuZCAiTVVTVCIgaW4gdGhlDQo+c2Ft ZSBzZW50ZW5jZSBhbnl3aGVyZS4NCj4NCj4NCj4gPkkgZmVlbCB0aGUgYmVzdCBjbGFzc2lmaWVy IGlzIE1VU1QgYnV0IEknbSBPSyB3aXRoIFNIT1VMRC4NCj4gPg0KPiA+VGltIER1bm4NCj4gPlRp bW90aHkgTi4gRHVubiBDb25zdWx0aW5nDQo+ID4NCj4gPg0KPiA+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPkZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gPkNsaXZlIEQuVy4gRmVhdGhlcg0KPiA+ U2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDI3LCAyMDA1IDI6MDcgQU0NCj4gPlRvOiBFQ1JJVA0K PiA+U3ViamVjdDogW0Vjcml0XSBDb21tZW50IG9uIGVjcml0LXJlcXVpcmVtZW50cy0wMCBpdGVt IEwxMA0KPiA+DQo+ID5JdGVtIEwxMCBzYXlzIHRoYXQgIlRoZSBwcmVmZXJyZWQgY29vcmRpbmF0 ZSByZWZlcmVuY2Ugc3lzdGVtIGZvciBlbWVyZ2VuY3kNCj4gPmNhbGxzIE1VU1QgYmUgV0dTLTg0 Ii4NCj4gPg0KPiA+Rmlyc3RseSwgSSdtIG5vdCBzdXJlIGhvdyAiTVVTVCIgaW50ZXJhY3RzIHdp dGggInByZWZlcnJlZCIuDQo+ID4NCj4gPlNlY29uZGx5LCBpbiB0aGUgVUsgdGhlIHByZWZlcnJl ZCBjb29yZGluYXRlIHN5c3RlbSBmb3IgZW1lcmdlbmN5IHNlcnZpY2VzDQo+ID5pcyBPU0dCIE5h dGlvbmFsIEdyaWQuIEVtZXJnZW5jeSBzZXJ2aWNlcyB3b24ndCBlYXNpbHkga25vdyB3aGF0IHRv IGRvIHdpdGgNCj4gPmEgbGF0LWxvbmcgcGFpci4gRXZlbiBpZiB0aGVyZSBpcyBzb2Z0d2FyZSBh dCBlYWNoIGVuZCBvZiB0aGUgY2FsbCB0byBkbw0KPiA+dGhlIGNvbnZlcnNpb24sIGl0IGZlZWxz IHRoZSB3cm9uZyB0aGluZyB0byBkbzsgZnVydGhlcm1vcmUsIGFzIEkNCj4gPnVuZGVyc3RhbmQg aXQgdGhlIGNvbnZlcnNpb24gaXNuJ3QgZXhhY3QgYW5kIEknZCBoYXRlIGEgcm91bmRpbmcgZXJy b3IgdG8NCj4gPmNyZWVwIGluLg0KPiA+DQo+ID4tLQ0KPiA+Q2xpdmUgRC5XLiBGZWF0aGVyICB8 IFdvcms6ICA8Y2xpdmVAZGVtb24ubmV0PiAgIHwgVGVsOiAgICArNDQgMjAgODQ5NSA2MTM4DQo+ ID5JbnRlcm5ldCBFeHBlcnQgICAgIHwgSG9tZTogIDxjbGl2ZUBkYXZyb3Mub3JnPiAgfCBGYXg6 ICAgICs0NCA4NzAgMDUxIDk5MzcNCj4gPkRlbW9uIEludGVybmV0ICAgICAgfCBXV1c6IGh0dHA6 Ly93d3cuZGF2cm9zLm9yZyB8IE1vYmlsZTogKzQ0IDc5NzMgMzc3NjQ2DQo+ID5UaHVzIHBsYyAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+DQo+ID5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+RWNyaXQgbWFpbGlu ZyBsaXN0DQo+ID5FY3JpdEBpZXRmLm9yZw0KPiA+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZWNyaXQNCj4gPg0KPiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPkVjcml0IG1haWxpbmcgbGlzdA0KPiA+RWNyaXRAaWV0Zi5v cmcNCj4gPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+DQo+ DQo+Y2hlZXJzLA0KPkphbWVzDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICoqKioqKioqKioqKioqKioqKioNCj4gICAgICAgICAgICAgICAgICBUcnV0aCBpcyBub3QgdG8g YmUgYXJndWVkLi4uIGl0IGlzIHRvIGJlIHByZXNlbnRlZC4NCg0KDQpjaGVlcnMsDQpKYW1lcw0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqKioqKioqKioqKioqKioqKioqDQog ICAgICAgICAgICAgICAgIFRydXRoIGlzIG5vdCB0byBiZSBhcmd1ZWQuLi4gaXQgaXMgdG8gYmUg cHJlc2VudGVkLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRWNyaXQgbWFpbGluZyBsaXN0DQpFY3JpdEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lw aWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90 aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRl IHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHBy b2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd --===============1515914864== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1515914864==-- From ecrit-bounces@ietf.org Tue Sep 27 19:50:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKPDh-0006pb-5M; Tue, 27 Sep 2005 19:50:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKPDe-0006pO-VT for ecrit@megatron.ietf.org; Tue, 27 Sep 2005 19:50:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29008 for ; Tue, 27 Sep 2005 19:50:41 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKPL0-0000nt-9P for ecrit@ietf.org; Tue, 27 Sep 2005 19:58:18 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 27 Sep 2005 16:50:33 -0700 X-IronPort-AV: i="3.97,151,1125903600"; d="scan'208"; a="662321861:sNHT34388596" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8RNoPKE021203; Tue, 27 Sep 2005 16:50:28 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 16:50:28 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.255]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 16:50:27 -0700 Message-Id: <4.3.2.7.2.20050927184143.033d12b0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Sep 2005 18:50:25 -0500 To: "Thomson, Martin" , "Tim Dunn" , "Clive D.W. Feather" , "ECRIT" From: "James M. Polk" Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Sep 2005 23:50:27.0876 (UTC) FILETIME=[3CA7CE40:01C5C3BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I've changed my mind on this matter, and like Martin's wording better. Remember, this is a requirements ID. Requirements docs say "MUST" a lot. ECRIT is based on work done in Geopriv, which has a single datum for interoperability - WGS84 - even though endpoints of a communication can choose to use another datum, all MUST support WGS84 (EPSG's CRS 4326, I think). As Henning pointed out correctly, this isn't about national variants, yet anyone's device has to work in the US, just as US devices have to work elsewhere. If we give in to national variants - we'll lose interoperability on day one to all those not native within their home nation. We need to specify one datum, and let others be used between devices that negotiate the other datum(s). At 05:38 PM 9/27/2005 -0500, Thomson, Martin wrote: >This sounds remarkably like similar statements I have read on UTF-8 >support in XML and many protocol specs. What you want is a common >baseline that everyone understands, otherwise interoperation becomes >challenging. I'd suggest a MUST is better. > >Also the wording that you have chosen could be interpreted as requiring >implementations to convert from arbitrary CRS's. Instead suggest >something like: > >"Implementations MUST support the WGS-84 coordinate reference system for >emergency calls. Implementations MAY support other coordinate reference >systems, but they MUST be able to perform a coordinate transformation to >WGS-84 where necessary." > >There is a precedent for this sort of statement, see Section 7.8 of: >http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-01.txt > >Cheers, >Martin > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >James M. Polk >Sent: Wednesday, 28 September 2005 2:51 AM >To: Tim Dunn; 'Clive D.W. Feather'; 'ECRIT' >Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 > >At 09:11 AM 9/27/2005 -0600, Tim Dunn wrote: > >I think, yes, we prefer WGS-84 (I read that as the crux of that original > >requirement). But if you're using a coordinate system other than WGS-84, you > >should have a facility that allows you to convert from that system to > >WGS-84. > > > >By the way I said I preferred must in the second requirement but was OK with > >should (because I thought there would be consternation with requiring > >coordinate transformation). > > > >So to re-reword to a much more generic set of requirements that: > > > >A: The preferred coordinate reference system for emergency calls is WGS-84. > >B: Systems should have an ability to perform coordinate transformation > >between differing coordinate reference systems.... > >...to WGS84. > >then I agree with this wording > > > > >Tim > > > > > >-----Original Message----- > >From: James M. Polk [mailto:jmpolk@cisco.com] > >Sent: Tuesday, September 27, 2005 8:46 AM > >To: Tim Dunn; 'Clive D.W. Feather'; 'ECRIT' > >Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 > > > >At 08:21 AM 9/27/2005 -0600, Tim Dunn wrote: > > >Clive- > > > > > >How about an alternate presentation of the requirement, specifically: > > > > > >A: The preferred coordinate reference system for emergency calls is > >WGS-84. > > >B: Systems using coordinate reference systems other than WGS-84 > > >(should/must) have the ability to perform coordinate transformation from > >the > > >alternate system to WGS-84 and vice-versa. > > > >Tim > > > >so what you're saying is: > > > > "we prefer you use WGS84, and if you don't, you (should/must) > > convert to/from it" > > > >..this seems like a MUST to me dressed up to sound more palatable by those > >that don't use it. > > > >I agree with Clive - we cannot have the words "preferred" and "MUST" in the > >same sentence anywhere. > > > > > > >I feel the best classifier is MUST but I'm OK with SHOULD. > > > > > >Tim Dunn > > >Timothy N. Dunn Consulting > > > > > > > > >-----Original Message----- > > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > > >Clive D.W. Feather > > >Sent: Tuesday, September 27, 2005 2:07 AM > > >To: ECRIT > > >Subject: [Ecrit] Comment on ecrit-requirements-00 item L10 > > > > > >Item L10 says that "The preferred coordinate reference system for > emergency > > >calls MUST be WGS-84". > > > > > >Firstly, I'm not sure how "MUST" interacts with "preferred". > > > > > >Secondly, in the UK the preferred coordinate system for emergency services > > >is OSGB National Grid. Emergency services won't easily know what to do > with > > >a lat-long pair. Even if there is software at each end of the call to do > > >the conversion, it feels the wrong thing to do; furthermore, as I > > >understand it the conversion isn't exact and I'd hate a rounding error to > > >creep in. > > > > > >-- > > >Clive D.W. Feather | Work: | Tel: +44 20 8495 > 6138 > > >Internet Expert | Home: | Fax: +44 870 051 > 9937 > > >Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 > > >Thus plc | | > > > > > >_______________________________________________ > > >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. > > >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 > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] 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 Sep 28 19:10:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKl3w-0002e9-HP; Wed, 28 Sep 2005 19:10:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKl3u-0002d7-ID for ecrit@megatron.ietf.org; Wed, 28 Sep 2005 19:10:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20051 for ; Wed, 28 Sep 2005 19:10:03 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKlBQ-0006uw-RY for ecrit@ietf.org; Wed, 28 Sep 2005 19:17:54 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 28 Sep 2005 19:09:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 Date: Wed, 28 Sep 2005 16:09:45 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750337E7BC@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Comment on ecrit-requirements-00 item L10 Thread-Index: AcXDvrf4fky0hheMTBO21QAa7mjOkwAdYjZg From: "Roger Marshall" To: "James M. Polk" , "Thomson, Martin" , "Tim Dunn" , "Clive D.W. Feather" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I agree that stronger language (MUST) makes the requirement clearer. I think the suggested text is good, but should still be separated. I'll also argue that the context of how a supported CRS is to be used (i.e. for MAPPING) should also be mentioned as is now worded. Proposed revision to requirement: "L10a. Reference Datum: Implementations MUST support the WGS-84 coordinate reference system for use in mapping emergency calls." "L10b. Reference Datum Translation: Any implementation which supports a different coordinate reference system, MUST support the ability to perform coordinate transformation to the WGS-84 coordinate reference system where necessary." Are we getting closer? Roger Marshall. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of James M. Polk >Sent: Tuesday, September 27, 2005 4:50 PM >To: Thomson, Martin; Tim Dunn; Clive D.W. Feather; ECRIT >Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 > >I've changed my mind on this matter, and like Martin's wording better. > >Remember, this is a requirements ID. Requirements docs say=20 >"MUST" a lot. > >ECRIT is based on work done in Geopriv, which has a single=20 >datum for interoperability - WGS84 - even though endpoints of=20 >a communication can choose to use another datum, all MUST=20 >support WGS84 (EPSG's CRS 4326, I think). > >As Henning pointed out correctly, this isn't about national=20 >variants, yet anyone's device has to work in the US, just as=20 >US devices have to work elsewhere. If we give in to national=20 >variants - we'll lose interoperability on day one to all those=20 >not native within their home nation. > >We need to specify one datum, and let others be used between=20 >devices that negotiate the other datum(s). > >At 05:38 PM 9/27/2005 -0500, Thomson, Martin wrote: >>This sounds remarkably like similar statements I have read on UTF-8=20 >>support in XML and many protocol specs. What you want is a common=20 >>baseline that everyone understands, otherwise interoperation becomes=20 >>challenging. I'd suggest a MUST is better. >> >>Also the wording that you have chosen could be interpreted as=20 >requiring=20 >>implementations to convert from arbitrary CRS's. Instead suggest=20 >>something like: >> >>"Implementations MUST support the WGS-84 coordinate reference system=20 >>for emergency calls. Implementations MAY support other coordinate=20 >>reference systems, but they MUST be able to perform a coordinate=20 >>transformation to >>WGS-84 where necessary." >> >>There is a precedent for this sort of statement, see Section 7.8 of: >>http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo >-profile- >>01.txt >> >>Cheers, >>Martin >> >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf=20 >>Of James M. Polk >>Sent: Wednesday, 28 September 2005 2:51 AM >>To: Tim Dunn; 'Clive D.W. Feather'; 'ECRIT' >>Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 >> >>At 09:11 AM 9/27/2005 -0600, Tim Dunn wrote: >> >I think, yes, we prefer WGS-84 (I read that as the crux of that=20 >> >original requirement). But if you're using a coordinate=20 >system other=20 >> >than WGS-84, you should have a facility that allows you to convert=20 >> >from that system to WGS-84. >> > >> >By the way I said I preferred must in the second=20 >requirement but was=20 >> >OK with should (because I thought there would be consternation with=20 >> >requiring coordinate transformation). >> > >> >So to re-reword to a much more generic set of requirements that: >> > >> >A: The preferred coordinate reference system for emergency=20 >calls is WGS-84. >> >B: Systems should have an ability to perform coordinate=20 >> >transformation between differing coordinate reference systems.... >> >>...to WGS84. >> >>then I agree with this wording >> >> >> >> >Tim >> > >> > >> >-----Original Message----- >> >From: James M. Polk [mailto:jmpolk@cisco.com] >> >Sent: Tuesday, September 27, 2005 8:46 AM >> >To: Tim Dunn; 'Clive D.W. Feather'; 'ECRIT' >> >Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 >> > >> >At 08:21 AM 9/27/2005 -0600, Tim Dunn wrote: >> > >Clive- >> > > >> > >How about an alternate presentation of the requirement,=20 >specifically: >> > > >> > >A: The preferred coordinate reference system for emergency calls=20 >> > >is >> >WGS-84. >> > >B: Systems using coordinate reference systems other than WGS-84 >> > >(should/must) have the ability to perform coordinate=20 >transformation=20 >> > >from >> >the >> > >alternate system to WGS-84 and vice-versa. >> > >> >Tim >> > >> >so what you're saying is: >> > >> > "we prefer you use WGS84, and if you don't, you=20 >(should/must) >> > convert to/from it" >> > >> >..this seems like a MUST to me dressed up to sound more=20 >palatable by=20 >> >those that don't use it. >> > >> >I agree with Clive - we cannot have the words "preferred"=20 >and "MUST"=20 >> >in the same sentence anywhere. >> > >> > >> > >I feel the best classifier is MUST but I'm OK with SHOULD. >> > > >> > >Tim Dunn >> > >Timothy N. Dunn Consulting >> > > >> > > >> > >-----Original Message----- >> > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 >> > >Behalf Of Clive D.W. Feather >> > >Sent: Tuesday, September 27, 2005 2:07 AM >> > >To: ECRIT >> > >Subject: [Ecrit] Comment on ecrit-requirements-00 item L10 >> > > >> > >Item L10 says that "The preferred coordinate reference system for >> emergency >> > >calls MUST be WGS-84". >> > > >> > >Firstly, I'm not sure how "MUST" interacts with "preferred". >> > > >> > >Secondly, in the UK the preferred coordinate system for emergency=20 >> > >services is OSGB National Grid. Emergency services won't easily=20 >> > >know what to do >> with >> > >a lat-long pair. Even if there is software at each end of=20 >the call=20 >> > >to do the conversion, it feels the wrong thing to do;=20 >furthermore,=20 >> > >as I understand it the conversion isn't exact and I'd hate a=20 >> > >rounding error to creep in. >> > > >> > >-- >> > >Clive D.W. Feather | Work: | Tel: =20 > +44 20 8495=20 >> 6138 >> > >Internet Expert | Home: | Fax: =20 > +44 870 051=20 >> 9937 >> > >Demon Internet | WWW: http://www.davros.org |=20 >Mobile: +44 7973 377646 >> > >Thus plc | | >> > > >> > >_______________________________________________ >> > >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=20 >presented. >> >> >>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 >> >>-------------------------------------------------------------- >--------- >>------------------------- This message is for the designated=20 >recipient=20 >>only and may contain privileged, proprietary, or otherwise private=20 >>information. >>If you have received it in error, please notify the sender=20 >immediately=20 >>and delete the original. Any unauthorized use of this email is=20 >>prohibited. >>-------------------------------------------------------------- >--------- >>------------------------- >>[mf2] > > >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 Sep 28 22:49:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKoUd-0007sZ-SQ; Wed, 28 Sep 2005 22:49:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKoUc-0007sU-MR for ecrit@megatron.ietf.org; Wed, 28 Sep 2005 22:49:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29937 for ; Wed, 28 Sep 2005 22:49:50 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKoc9-0003rU-F5 for ecrit@ietf.org; Wed, 28 Sep 2005 22:57:42 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j8T2nLW5021179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Sep 2005 22:49:31 -0400 (EDT) Message-ID: <433B5633.2060905@cs.columbia.edu> Date: Wed, 28 Sep 2005 22:49:23 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] Comment on ecrit-requirements-00 item L10 References: <8C837214C95C864C9F34F3635C2A65750337E7BC@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A65750337E7BC@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: ECRIT , "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think this is still somewhat confusing, as it is not quite clear who is supposed to be doing what. For the mapping protocol server, I think we want "The server MUST understand WGS-84 coordinate reference system and MAY understand other reference systems." I don't see where transformation comes into play, unless we might be talking about some hybrid systems mixing coordinate systems within a hierarchy of servers. This would seem a bit odd and unnecessarily complicated. Roger Marshall wrote: > I agree that stronger language (MUST) makes the requirement clearer. I > think the suggested text is good, but should still be separated. I'll > also argue that the context of how a supported CRS is to be used (i.e. > for MAPPING) should also be mentioned as is now worded. > > Proposed revision to requirement: > > "L10a. Reference Datum: Implementations MUST support the WGS-84 > coordinate reference system for use in mapping emergency calls." > > "L10b. Reference Datum Translation: Any implementation which supports a > different coordinate reference system, MUST support the ability to > perform coordinate transformation to the WGS-84 coordinate reference > system where necessary." > > Are we getting closer? > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 29 05:16:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKuWy-0000sV-Hv; Thu, 29 Sep 2005 05:16:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKuWv-0000sN-KB for ecrit@megatron.ietf.org; Thu, 29 Sep 2005 05:16:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28208 for ; Thu, 29 Sep 2005 05:16:38 -0400 (EDT) Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKueX-0003p9-Bu for ecrit@ietf.org; Thu, 29 Sep 2005 05:24:34 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id j8T9GbPO015293Thu, 29 Sep 2005 09:16:37 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1EKuWr-000Lna-00; Thu, 29 Sep 2005 10:16:37 +0100 Date: Thu, 29 Sep 2005 10:16:37 +0100 From: "Clive D.W. Feather" To: Tim Dunn Subject: Re: [Ecrit] Comment on ecrit-requirements-00 item L10 Message-ID: <20050929091637.GC75147@finch-staff-1.thus.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tim Dunn said: > How about an alternate presentation of the requirement, specifically: [...] Having read the discussion over the last couple of days, what I think is needed is: A: There MUST be a way in the protocol for the caller's equipment to negotiate a choice of coordinate system with the PSAP. Aa: Calling equipment MUST be able to convert its location to any of the coordinate systems it offers in the negotiation. Ab: PSAP equipment MUST be able to convert the received location from any of the coordinate systems it offers in the negotiation to that required internally. B: Both calling equipment and PSAP MUST offer WGS-84 as part of the negotiation (even if not the first choice). [This could be implemented either by requiring it to be on any lists, or by making it the fallback if negotiation fails.] Then, if the negotiation is the common one of "offer an ordered list, use the first one on both side's lists": UK CPE offers: OSGB, WGS-84 other CPE offers: XXX, YYY, WGS-84 UK PSAP accepts: OSGB, WGS-84 other PSAP accepts: ZZZ, WGS-84 (where XXX, YYY, ZZZ are other systems) and all works. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 29 10:27:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKzNs-00012w-TI; Thu, 29 Sep 2005 10:27:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKzNr-00012i-7V for ecrit@megatron.ietf.org; Thu, 29 Sep 2005 10:27:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14771 for ; Thu, 29 Sep 2005 10:27:36 -0400 (EDT) Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKzVW-0003f0-3V for ecrit@ietf.org; Thu, 29 Sep 2005 10:35:35 -0400 Received: from rrc-its-ieg02.cc.telcordia.com (rrc-its-ieg02.cc.telcordia.com [128.96.109.3]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j8TERJP22883 for ; Thu, 29 Sep 2005 10:27:19 -0400 (EDT) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-its-ieg02.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005092910271532583 for ; Thu, 29 Sep 2005 10:27:15 -0400 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Sep 2005 10:27:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Sep 2005 10:27:20 -0400 Message-ID: Thread-Topic: Comment on ecrit-requirements-00 Thread-Index: AcXE1qYFtg3q6Dn5S860bQ0EpdIFGAAKOAtA From: "Abbott, Nadine B" To: "ECRIT" X-OriginalArrivalTime: 29 Sep 2005 14:27:20.0837 (UTC) FILETIME=[E6D64B50:01C5C501] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Comment on ecrit-requirements-00 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 Suggest that we add in to Section 6 a requirement for the capability to distinguish an emergency "test call" as previously described in I-Ds on emergency services architectures. This is necessary so that the emergency service that receives the call can provide different processing for such test calls. Proposed text: It must be possible to distinguish an emergency "test call." Ax?. Emergency Test Call Marking: Emergency test requests MUST be recognizable and marked =20 by user agents, proxies, and other network elements as emergency test calls. Motivation: SIP and other call signaling protocols are not specific to one country or service provider and devices are likely to be used across national or service provider boundaries. Since services such as disabling mandatory authentication for emergency calls requires the cooperation of outbound proxies, the outbound proxy has to be able to recognize the emergency test call and be assured that it will be routed as an emergency call. However, the PSAP=20 receiving the call will want to handle the emergency test call differently from a real emergency call. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 29 13:35:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL2JZ-0002RB-PO; Thu, 29 Sep 2005 13:35:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL2JY-0002R4-Ou for ecrit@megatron.ietf.org; Thu, 29 Sep 2005 13:35:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24256 for ; Thu, 29 Sep 2005 13:35:22 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL2RB-0008QX-LS for ecrit@ietf.org; Thu, 29 Sep 2005 13:43:22 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 29 Sep 2005 13:35:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 Date: Thu, 29 Sep 2005 10:35:05 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750337EC04@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] Comment on ecrit-requirements-00 item L10 Thread-Index: AcXE1slmQT60S4eLSoyIE9dOMV/0hgARHu7A From: "Roger Marshall" To: "Clive D.W. Feather" , "Tim Dunn" X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Clive: With the idea of keeping the requirements more general (not saying your system can't impose more detailed requirements on top), I believe that the following single requirement proposed by Henning is sufficient: L10. Reference Datum: "The server MUST understand WGS-84 coordinate reference system and MAY understand other reference systems." Roger Marshall >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Clive D.W. Feather >Sent: Thursday, September 29, 2005 2:17 AM >To: Tim Dunn >Cc: 'ECRIT' >Subject: Re: [Ecrit] Comment on ecrit-requirements-00 item L10 > >Tim Dunn said: >> How about an alternate presentation of the requirement, specifically: >[...] > >Having read the discussion over the last couple of days, what=20 >I think is needed is: > >A: There MUST be a way in the protocol for the caller's equipment to > negotiate a choice of coordinate system with the PSAP. >Aa: Calling equipment MUST be able to convert its location to=20 >any of the > coordinate systems it offers in the negotiation. >Ab: PSAP equipment MUST be able to convert the received=20 >location from any > of the coordinate systems it offers in the negotiation to that > required internally. >B: Both calling equipment and PSAP MUST offer WGS-84 as part of the > negotiation (even if not the first choice). [This could be=20 >implemented > either by requiring it to be on any lists, or by making it=20 >the fallback > if negotiation fails.] > >Then, if the negotiation is the common one of "offer an=20 >ordered list, use the first one on both side's lists": > > UK CPE offers: OSGB, WGS-84 > other CPE offers: XXX, YYY, WGS-84 > UK PSAP accepts: OSGB, WGS-84 > other PSAP accepts: ZZZ, WGS-84 > >(where XXX, YYY, ZZZ are other systems) and all works. > >--=20 >Clive D.W. Feather | Work: | Tel: +44=20 >20 8495 6138 >Internet Expert | Home: | Fax: +44=20 >870 051 9937 >Demon Internet | WWW: http://www.davros.org | Mobile: +44=20 >7973 377646 >Thus plc | | > >_______________________________________________ >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 Sep 29 17:13:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL5ie-0003Kh-Rp; Thu, 29 Sep 2005 17:13:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL5ia-0003Jv-2z for ecrit@megatron.ietf.org; Thu, 29 Sep 2005 17:13:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14021 for ; Thu, 29 Sep 2005 17:13:25 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL5qI-0008Sf-FR for ecrit@ietf.org; Thu, 29 Sep 2005 17:21:27 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 29 Sep 2005 14:13:17 -0700 X-IronPort-AV: i="3.97,158,1125903600"; d="scan'208"; a="215888875:sNHT35345696" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j8TLD4W1024945; Thu, 29 Sep 2005 14:13:10 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 14:13:12 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.161]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 14:13:11 -0700 Message-Id: <4.3.2.7.2.20050929154633.02b15f08@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Sep 2005 16:13:07 -0500 To: "Roger Marshall" , "Clive D.W. Feather" From: "James M. Polk" Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 In-Reply-To: <8C837214C95C864C9F34F3635C2A65750337EC04@SEA-EXCHVS-2.tele comsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 29 Sep 2005 21:13:11.0924 (UTC) FILETIME=[99374B40:01C5C53A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org A couple of points: Clive - you suggest a negotiation (of datums) MUST be supported, and I read round-trips are surely the result, and at least one extension to the SIP protocol is needed as well. I believe not even a worse case scenario is the UA negotiates with the ESRP (one or more extra round trip involved), then the ESRP negotiates with the PSAP (one or more extra round trip involved). And the ESRP cannot start its negotiation until it has agreement from the UA as to which datum to start with. In-series delays are not good. While I sympathize with your suggestion, I think mandating one "mandatory to implement " (the thingy here is the datum) is the best way to ensure there will always be *one* common so that there is not additional delays and incompatibilities from the negotiation. Perhaps in your coutry's case, you could accept WGS84 from the UA or ESRP into the PSAP and then convert to OSGB. This ensures it occurs once, and always in the same way with the same inaccuracy if there is any introduced with the conversion. This inaccuracy can become measurable and adjusted for with testing or time. Also, this negotiation will have to be built into SIP spec(s) for all UAs to understand the new error or Reason codes involved with conveying that "the message was otherwise good, if it were not for the datum choice". Neither a 406 (Unacceptable) or 488 (Not Acceptable Here) Response message state this in SIP today, and this is also voilating another tenant within this reqs doc that 3261 compliant UAs be able to set-up an emergency call. As to Henning's wording... comments below At 10:35 AM 9/29/2005 -0700, Roger Marshall wrote: >Clive: > >With the idea of keeping the requirements more general (not saying your >system can't impose more detailed requirements on top), I believe that >the following single requirement proposed by Henning is sufficient: > >L10. Reference Datum: "The server MUST understand WGS-84 coordinate >reference system and MAY understand other reference systems." Stating the Server MUST understand WGS84 doesn't mean the UA MUST send WGS84 (if it is sending coordinates for location). That is one loophole I see in the wording that could result in interoperability problems. May I suggest this wording expansion: L10. Reference Datum: "If a coordinate reference system is to be transmitted by the UA, the WGS-84 coordinate reference system MUST be used, and MUST be understand by the server. Additional reference systems MAY be used if negotiated prior to the initial emergency INVITE message." >Roger Marshall > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of Clive D.W. Feather > >Sent: Thursday, September 29, 2005 2:17 AM > >To: Tim Dunn > >Cc: 'ECRIT' > >Subject: Re: [Ecrit] Comment on ecrit-requirements-00 item L10 > > > >Tim Dunn said: > >> How about an alternate presentation of the requirement, specifically: > >[...] > > > >Having read the discussion over the last couple of days, what > >I think is needed is: > > > >A: There MUST be a way in the protocol for the caller's equipment to > > negotiate a choice of coordinate system with the PSAP. > >Aa: Calling equipment MUST be able to convert its location to > >any of the > > coordinate systems it offers in the negotiation. > >Ab: PSAP equipment MUST be able to convert the received > >location from any > > of the coordinate systems it offers in the negotiation to that > > required internally. > >B: Both calling equipment and PSAP MUST offer WGS-84 as part of the > > negotiation (even if not the first choice). [This could be > >implemented > > either by requiring it to be on any lists, or by making it > >the fallback > > if negotiation fails.] > > > >Then, if the negotiation is the common one of "offer an > >ordered list, use the first one on both side's lists": > > > > UK CPE offers: OSGB, WGS-84 > > other CPE offers: XXX, YYY, WGS-84 > > UK PSAP accepts: OSGB, WGS-84 > > other PSAP accepts: ZZZ, WGS-84 > > > >(where XXX, YYY, ZZZ are other systems) and all works. > > > >-- > >Clive D.W. Feather | Work: | Tel: +44 > >20 8495 6138 > >Internet Expert | Home: | Fax: +44 > >870 051 9937 > >Demon Internet | WWW: http://www.davros.org | Mobile: +44 > >7973 377646 > >Thus plc | | > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 29 18:19:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL6ka-0007hJ-Bm; Thu, 29 Sep 2005 18:19:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL6kW-0007hA-VF for ecrit@megatron.ietf.org; Thu, 29 Sep 2005 18:19:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18047 for ; Thu, 29 Sep 2005 18:19:27 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL6sE-0001cn-S2 for ecrit@ietf.org; Thu, 29 Sep 2005 18:27:31 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 17:19:17 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 29 Sep 2005 17:19:16 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 17:19:16 -0500 Message-ID: From: "Thomson, Martin" To: "Roger Marshall" Date: Thu, 29 Sep 2005 17:19:14 -0500 Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 29 Sep 2005 22:19:16.0162 (UTC) FILETIME=[D4160220:01C5C543] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Comment on ecrit-requirements-00 item L10 Thread-Index: AcXE1slmQT60S4eLSoyIE9dOMV/0hgARHu7AAAoKoKA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0393650517==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============0393650517== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message Content-Transfer-Encoding: base64 WW91IG5lZWQgdG8gaWRlbnRpZnkgd2hhdCB5b3UgbWVhbiBieSAiVGhlIHNlcnZlciIsIHRoZSBj b250ZXh0IGRvZXNuJ3QgbWFrZSB0aGF0IGNsZWFyLiAgQXJlIHdlIHRhbGtpbmcgYWJvdXQgYW4g TENNUyBzZXJ2ZXI/ICBJZiBzbywgdXNlICJMQ01TIHNlcnZlcnMgTVVTVC4uLiIuDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIFttYWls dG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvZ2VyIE1hcnNoYWxsDQpT ZW50OiBGcmlkYXksIDMwIFNlcHRlbWJlciAyMDA1IDM6MzUgQU0NClRvOiBDbGl2ZSBELlcuIEZl YXRoZXI7IFRpbSBEdW5uDQpDYzogRUNSSVQNClN1YmplY3Q6IFJFOiBbRWNyaXRdIENvbW1lbnQg b24gZWNyaXQtcmVxdWlyZW1lbnRzLTAwIGl0ZW0gTDEwDQoNCkNsaXZlOg0KDQpXaXRoIHRoZSBp ZGVhIG9mIGtlZXBpbmcgdGhlIHJlcXVpcmVtZW50cyBtb3JlIGdlbmVyYWwgKG5vdCBzYXlpbmcg eW91cg0Kc3lzdGVtIGNhbid0IGltcG9zZSBtb3JlIGRldGFpbGVkIHJlcXVpcmVtZW50cyBvbiB0 b3ApLCBJIGJlbGlldmUgdGhhdA0KdGhlIGZvbGxvd2luZyBzaW5nbGUgcmVxdWlyZW1lbnQgcHJv cG9zZWQgYnkgSGVubmluZyBpcyBzdWZmaWNpZW50Og0KDQpMMTAuICBSZWZlcmVuY2UgRGF0dW06 ICJUaGUgc2VydmVyIE1VU1QgdW5kZXJzdGFuZCBXR1MtODQgY29vcmRpbmF0ZQ0KcmVmZXJlbmNl IHN5c3RlbSBhbmQgTUFZIHVuZGVyc3RhbmQgb3RoZXIgcmVmZXJlbmNlIHN5c3RlbXMuIg0KDQpS b2dlciBNYXJzaGFsbA0KDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGVj cml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSANCj5P biBCZWhhbGYgT2YgQ2xpdmUgRC5XLiBGZWF0aGVyDQo+U2VudDogVGh1cnNkYXksIFNlcHRlbWJl ciAyOSwgMjAwNSAyOjE3IEFNDQo+VG86IFRpbSBEdW5uDQo+Q2M6ICdFQ1JJVCcNCj5TdWJqZWN0 OiBSZTogW0Vjcml0XSBDb21tZW50IG9uIGVjcml0LXJlcXVpcmVtZW50cy0wMCBpdGVtIEwxMA0K Pg0KPlRpbSBEdW5uIHNhaWQ6DQo+PiBIb3cgYWJvdXQgYW4gYWx0ZXJuYXRlIHByZXNlbnRhdGlv biBvZiB0aGUgcmVxdWlyZW1lbnQsIHNwZWNpZmljYWxseToNCj5bLi4uXQ0KPg0KPkhhdmluZyBy ZWFkIHRoZSBkaXNjdXNzaW9uIG92ZXIgdGhlIGxhc3QgY291cGxlIG9mIGRheXMsIHdoYXQgDQo+ SSB0aGluayBpcyBuZWVkZWQgaXM6DQo+DQo+QTogIFRoZXJlIE1VU1QgYmUgYSB3YXkgaW4gdGhl IHByb3RvY29sIGZvciB0aGUgY2FsbGVyJ3MgZXF1aXBtZW50IHRvDQo+ICAgIG5lZ290aWF0ZSBh IGNob2ljZSBvZiBjb29yZGluYXRlIHN5c3RlbSB3aXRoIHRoZSBQU0FQLg0KPkFhOiBDYWxsaW5n IGVxdWlwbWVudCBNVVNUIGJlIGFibGUgdG8gY29udmVydCBpdHMgbG9jYXRpb24gdG8gDQo+YW55 IG9mIHRoZQ0KPiAgICBjb29yZGluYXRlIHN5c3RlbXMgaXQgb2ZmZXJzIGluIHRoZSBuZWdvdGlh dGlvbi4NCj5BYjogUFNBUCBlcXVpcG1lbnQgTVVTVCBiZSBhYmxlIHRvIGNvbnZlcnQgdGhlIHJl Y2VpdmVkIA0KPmxvY2F0aW9uIGZyb20gYW55DQo+ICAgIG9mIHRoZSBjb29yZGluYXRlIHN5c3Rl bXMgaXQgb2ZmZXJzIGluIHRoZSBuZWdvdGlhdGlvbiB0byB0aGF0DQo+ICAgIHJlcXVpcmVkIGlu dGVybmFsbHkuDQo+QjogIEJvdGggY2FsbGluZyBlcXVpcG1lbnQgYW5kIFBTQVAgTVVTVCBvZmZl ciBXR1MtODQgYXMgcGFydCBvZiB0aGUNCj4gICAgbmVnb3RpYXRpb24gKGV2ZW4gaWYgbm90IHRo ZSBmaXJzdCBjaG9pY2UpLiBbVGhpcyBjb3VsZCBiZSANCj5pbXBsZW1lbnRlZA0KPiAgICBlaXRo ZXIgYnkgcmVxdWlyaW5nIGl0IHRvIGJlIG9uIGFueSBsaXN0cywgb3IgYnkgbWFraW5nIGl0IA0K PnRoZSBmYWxsYmFjaw0KPiAgICBpZiBuZWdvdGlhdGlvbiBmYWlscy5dDQo+DQo+VGhlbiwgaWYg dGhlIG5lZ290aWF0aW9uIGlzIHRoZSBjb21tb24gb25lIG9mICJvZmZlciBhbiANCj5vcmRlcmVk IGxpc3QsIHVzZSB0aGUgZmlyc3Qgb25lIG9uIGJvdGggc2lkZSdzIGxpc3RzIjoNCj4NCj4gICAg VUsgQ1BFIG9mZmVyczogICAgICAgICBPU0dCLCBXR1MtODQNCj4gICAgb3RoZXIgQ1BFIG9mZmVy czogICAgICBYWFgsIFlZWSwgV0dTLTg0DQo+ICAgIFVLIFBTQVAgYWNjZXB0czogICAgICAgT1NH QiwgV0dTLTg0DQo+ICAgIG90aGVyIFBTQVAgYWNjZXB0czogICAgWlpaLCBXR1MtODQNCj4NCj4o d2hlcmUgWFhYLCBZWVksIFpaWiBhcmUgb3RoZXIgc3lzdGVtcykgYW5kIGFsbCB3b3Jrcy4NCj4N Cj4tLSANCj5DbGl2ZSBELlcuIEZlYXRoZXIgIHwgV29yazogIDxjbGl2ZUBkZW1vbi5uZXQ+ICAg fCBUZWw6ICAgICs0NCANCj4yMCA4NDk1IDYxMzgNCj5JbnRlcm5ldCBFeHBlcnQgICAgIHwgSG9t ZTogIDxjbGl2ZUBkYXZyb3Mub3JnPiAgfCBGYXg6ICAgICs0NCANCj44NzAgMDUxIDk5MzcNCj5E ZW1vbiBJbnRlcm5ldCAgICAgIHwgV1dXOiBodHRwOi8vd3d3LmRhdnJvcy5vcmcgfCBNb2JpbGU6 ICs0NCANCj43OTczIDM3NzY0Ng0KPlRodXMgcGxjICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj5FY3JpdCBtYWlsaW5nIGxpc3QNCj5FY3JpdEBpZXRmLm9yZw0KPmh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+DQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFY3JpdCBtYWlsaW5nIGxpc3QN CkVjcml0QGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9l Y3JpdA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVz c2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFp biBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRp b24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0 aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0= --===============0393650517== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0393650517==-- From ecrit-bounces@ietf.org Thu Sep 29 21:59:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELABh-0006Ek-MT; Thu, 29 Sep 2005 21:59:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELABg-0006Ef-Aw for ecrit@megatron.ietf.org; Thu, 29 Sep 2005 21:59:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28787 for ; Thu, 29 Sep 2005 21:59:45 -0400 (EDT) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELAJP-0006nl-Dr for ecrit@ietf.org; Thu, 29 Sep 2005 22:07:50 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 20:59:29 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 29 Sep 2005 20:59:29 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 20:59:28 -0500 Message-ID: From: "Winterbottom, James" To: "Clive D.W. Feather" , "Tim Dunn" Date: Thu, 29 Sep 2005 20:59:27 -0500 Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 30 Sep 2005 01:59:28.0977 (UTC) FILETIME=[97899410:01C5C562] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Comment on ecrit-requirements-00 item L10 Thread-Index: AcXE1qJgYEdh5MuUTH26AH12jbebFgAFappA X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi, Maybe I am missing something here, but this seems to be being represented as a requirement for how location is presented to the PSAP rather than how the network will use location to determine a route to the PSAP. I see these as potentially two different problems and I am not even sure that the presentation issue is in scope for ECRIT. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Clive D.W. Feather > Sent: Thursday, 29 September 2005 7:17 PM > To: Tim Dunn > Cc: 'ECRIT' > Subject: Re: [Ecrit] Comment on ecrit-requirements-00 item L10 >=20 > Tim Dunn said: > > How about an alternate presentation of the requirement, specifically: > [...] >=20 > Having read the discussion over the last couple of days, what I think is > needed is: >=20 > A: There MUST be a way in the protocol for the caller's equipment to > negotiate a choice of coordinate system with the PSAP. > Aa: Calling equipment MUST be able to convert its location to any of the > coordinate systems it offers in the negotiation. > Ab: PSAP equipment MUST be able to convert the received location from any > of the coordinate systems it offers in the negotiation to that > required internally. > B: Both calling equipment and PSAP MUST offer WGS-84 as part of the > negotiation (even if not the first choice). [This could be implemented > either by requiring it to be on any lists, or by making it the > fallback > if negotiation fails.] >=20 > Then, if the negotiation is the common one of "offer an ordered list, use > the first one on both side's lists": >=20 > UK CPE offers: OSGB, WGS-84 > other CPE offers: XXX, YYY, WGS-84 > UK PSAP accepts: OSGB, WGS-84 > other PSAP accepts: ZZZ, WGS-84 >=20 > (where XXX, YYY, ZZZ are other systems) and all works. >=20 > -- > Clive D.W. Feather | Work: | Tel: +44 20 8495 > 6138 > Internet Expert | Home: | Fax: +44 870 051 > 9937 > Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 > Thus plc | | >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit