From RMarshall@telecomsys.com Mon Jul 9 12:01:39 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C0311E80D0 for ; Mon, 9 Jul 2012 12:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7p1jEdt0l-na for ; Mon, 9 Jul 2012 12:01:38 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) by ietfa.amsl.com (Postfix) with ESMTP id CA36011E81AA for ; Mon, 9 Jul 2012 12:01:23 -0700 (PDT) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-02.telecomsys.com (8.14.1/8.14.1) with ESMTP id q69J1ffv016534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 9 Jul 2012 12:01:41 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.114]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Mon, 9 Jul 2012 12:01:41 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: IETF84 - ECRIT call for agenda items Thread-Index: Ac1eBUWBIsMgsaZAQoiHNuCcgikWhA== Date: Mon, 9 Jul 2012 19:01:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC0B2A8DSEAEXMB1telecomsy_" MIME-Version: 1.0 Subject: [Ecrit] IETF84 - ECRIT call for agenda items X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 19:01:39 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC0B2A8DSEAEXMB1telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A meeting slot for the ECRIT working group has been scheduled for IETF84 on= Tuesday, July 31, 13:00-15:00. If any of you want to request specific agenda time to present, please send = an email to both Marc & me. https://datatracker.ietf.org/meeting/84/agenda.txt Thanks. Roger Marshall & Marc Linsner ECRIT chairs CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC0B2A8DSEAEXMB1telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A meeting slot for the E= CRIT working group has been scheduled for IETF84 on Tuesday, July 31, 13:00= -15:00.

 =

If any of you want to re= quest specific agenda time to present, please send an email to both Marc &a= mp; me.

 =

https://datatracker.ietf.org/meeting= /84/agenda.txt

 =

Thanks.

 =

Roger Marshall & Mar= c Linsner

ECRIT chairs<= /span>

 

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC0B2A8DSEAEXMB1telecomsy_-- From internet-drafts@ietf.org Tue Jul 10 01:50:10 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB57111E8103; Tue, 10 Jul 2012 01:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id io8H6Gjuj3KG; Tue, 10 Jul 2012 01:50:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434F411E80D6; Tue, 10 Jul 2012 01:50:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120710085009.9516.50646.idtracker@ietfa.amsl.com> Date: Tue, 10 Jul 2012 01:50:09 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-lost-sync-18.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 08:50:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Synchronizing Location-to-Service Translation (LoST) Pro= tocol based Service Boundaries and Mapping Elements Author(s) : Henning Schulzrinne Hannes Tschofenig Filename : draft-ietf-ecrit-lost-sync-18.txt Pages : 30 Date : 2012-07-10 Abstract: The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The element is used to encapsulate information about service boundaries is defined in the LoST protocol specification and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative elements between two entities. Exchanging cached elements, i.e. non-authoritative elements, is possible but not envisioned. In any case, this document can also be used without the LoST protocol even though the format of the element is re-used from the LoST specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-sync There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-lost-sync-18 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-lost-sync-18 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Tue Jul 10 02:28:13 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A7C21F8567 for ; Tue, 10 Jul 2012 02:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.308 X-Spam-Level: X-Spam-Status: No, score=-102.308 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lABhTFB1gUi for ; Tue, 10 Jul 2012 02:28:12 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 3A49921F8562 for ; Tue, 10 Jul 2012 02:28:07 -0700 (PDT) Received: (qmail invoked by alias); 10 Jul 2012 09:28:33 -0000 Received: from unknown (EHLO [10.255.134.171]) [194.251.119.201] by mail.gmx.net (mp001) with SMTP; 10 Jul 2012 11:28:33 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/fr+h2VKXfu5ZjIX8NrevZr+Uz0rW75iS1qrWbnj lR4USWDBKDaTzd From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Jul 2012 12:28:25 +0300 Message-Id: <75DE9F3D-0893-4A7C-8517-7A93566FC58A@gmx.net> To: "ecrit@ietf.org Org" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [Ecrit] draft-ietf-ecrit-lost-sync-18 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 09:28:13 -0000 Hi all,=20 with this draft update I tried to address the IESG feedback.=20 The changes are minor even though the diff may tell you otherwise. You = will notice a change in the introduction: I moved the old text into a = new section and wrote a new introduction.=20 Here is the draft:=20 http://tools.ietf.org/html/draft-ietf-ecrit-lost-sync-18 Ciao Hannes From hannes.tschofenig@gmx.net Tue Jul 10 09:08:53 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3DE111E8181 for ; Tue, 10 Jul 2012 09:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.082 X-Spam-Level: X-Spam-Status: No, score=-103.082 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, GB_I_LETTER=-2, SARE_TOWRITE=1.05, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6K1FYkPWVvly for ; Tue, 10 Jul 2012 09:08:52 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 2153611E8175 for ; Tue, 10 Jul 2012 09:08:51 -0700 (PDT) Received: (qmail invoked by alias); 10 Jul 2012 16:09:19 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.106]) [88.115.216.191] by mail.gmx.net (mp037) with SMTP; 10 Jul 2012 18:09:19 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19Svp0EmtZS3gf0VXESlicq0bDnNoCiAi/bGdHg1Z Lvcbx3qJkXQhQ0 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Hannes Tschofenig Date: Tue, 10 Jul 2012 19:09:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <22A077A4-9E8B-44B6-A0B6-C18FB67BBC20@gmx.net> To: "ecrit@ietf.org Org" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 16:08:53 -0000 Hi all,=20 years ago the ECRIT working group discussed the topic of 'location = hiding' and this lead to the publication of RFC 6444 = (http://datatracker.ietf.org/doc/rfc6444/). Consequently, a solution was = developed (and is still work in progress) called "Rough Location", see = http://tools.ietf.org/id/draft-ietf-ecrit-rough-loc. It looked like we solved that problem. Right?=20 You may think. Early 2011, about 4 years after the first location hiding = draft was published, the European Commission (EC) comes along and = published mandate 493. Without going into the details of the mandate the = European Commission had the impression that there are no specifications = available.=20 The Internet Architecture Board (IAB) provided a response to that = mandate, which you can find here: = http://www.iab.org/documents/correspondence-reports-documents/2011-2/lette= r-to-the-european-commission-on-global-interoperability-in-emergency-servi= ces/. Unfortunately, the IAB interaction with the EC did not lead to the = desired outcome, i.e., to look at our documents carefully enough and to = realize that we have a solution already.=20 In any case, a new standards group in ETSI was created to work on this = topic: the M493 group. This group is supposed to develop an emergency = services architecture in fulfillment of the location hiding requirement = (the mandate phrases it differently, of course but the requirements that = are discussed flow in that direction). To provide feedback into that process James Winterbottom and myself had = decided to write an Internet draft for an architecture that we believe = could meet their requirements and, at the same time, re-uses some of our = earlier standardization work. You can find the document here: http://tools.ietf.org/html/draft-winterbottom-ecrit-priv-loc-00 Feedback is welcome.=20 Ciao Hannes PS: Marc, can we get an agenda slot to discuss this topic? =20 From rbarnes@bbn.com Tue Jul 10 09:30:43 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A0811E8194 for ; Tue, 10 Jul 2012 09:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.036 X-Spam-Level: X-Spam-Status: No, score=-107.036 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, SARE_TOWRITE=1.05, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbdtbzK8-SAW for ; Tue, 10 Jul 2012 09:30:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id BA94811E8187 for ; Tue, 10 Jul 2012 09:30:42 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:55027) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SodLC-000C65-7B; Tue, 10 Jul 2012 12:31:10 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <22A077A4-9E8B-44B6-A0B6-C18FB67BBC20@gmx.net> Date: Tue, 10 Jul 2012 12:31:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <94D082C9-E6CC-4F3F-838B-A9F7F588DA60@bbn.com> References: <22A077A4-9E8B-44B6-A0B6-C18FB67BBC20@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1278) Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 16:30:43 -0000 Hey Hannes, James, I agree that -rough-loc seems not to be meeting some stakeholders' = needs. It does like we need a little more protocol revision. I think that this document goes about it in the wrong way. Using the = DNS for LIS discovery is fragile, as we've discussed often in the past. = And from the perspective of client implementation, this document = completely screws up the normal location->LoST->call flow. It would be better to allow location by reference in LoST queries. The = major challenge in that regard was that the LoST server might not be = able to dereference the URI, but that can be mitigated with local LoST = server discovery, which -phonebcp requires to be preferred over = configured LoST servers. I'm going to take a first past at LbyR-in-LoST in a rev of rough-loc in = time for the draft deadline, so that we can have a basis for discussion = in Vancouver. Thanks for getting this conversation started, --Richard On Jul 10, 2012, at 12:09 PM, Hannes Tschofenig wrote: > Hi all,=20 >=20 > years ago the ECRIT working group discussed the topic of 'location = hiding' and this lead to the publication of RFC 6444 = (http://datatracker.ietf.org/doc/rfc6444/). Consequently, a solution was = developed (and is still work in progress) called "Rough Location", see = http://tools.ietf.org/id/draft-ietf-ecrit-rough-loc. >=20 > It looked like we solved that problem. Right?=20 >=20 > You may think. Early 2011, about 4 years after the first location = hiding draft was published, the European Commission (EC) comes along and = published mandate 493. Without going into the details of the mandate the = European Commission had the impression that there are no specifications = available.=20 >=20 > The Internet Architecture Board (IAB) provided a response to that = mandate, which you can find here: = http://www.iab.org/documents/correspondence-reports-documents/2011-2/lette= r-to-the-european-commission-on-global-interoperability-in-emergency-servi= ces/. >=20 > Unfortunately, the IAB interaction with the EC did not lead to the = desired outcome, i.e., to look at our documents carefully enough and to = realize that we have a solution already.=20 >=20 > In any case, a new standards group in ETSI was created to work on this = topic: the M493 group. This group is supposed to develop an emergency = services architecture in fulfillment of the location hiding requirement = (the mandate phrases it differently, of course but the requirements that = are discussed flow in that direction). >=20 > To provide feedback into that process James Winterbottom and myself = had decided to write an Internet draft for an architecture that we = believe could meet their requirements and, at the same time, re-uses = some of our earlier standardization work. >=20 > You can find the document here: > http://tools.ietf.org/html/draft-winterbottom-ecrit-priv-loc-00 >=20 > Feedback is welcome.=20 >=20 > Ciao > Hannes >=20 > PS: Marc, can we get an agenda slot to discuss this topic? =20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Tue Jul 10 10:35:18 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA4721F8762 for ; Tue, 10 Jul 2012 10:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.549 X-Spam-Level: X-Spam-Status: No, score=-104.549 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, SARE_TOWRITE=1.05, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K56FqOyPoiWR for ; Tue, 10 Jul 2012 10:35:17 -0700 (PDT) Received: from barmail6.idig.net (barmail6.idig.net [64.34.111.239]) by ietfa.amsl.com (Postfix) with ESMTP id 8E28B21F86DE for ; Tue, 10 Jul 2012 10:35:17 -0700 (PDT) X-ASG-Debug-ID: 1341941743-0538de37f52a8c30001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail6.idig.net with ESMTP id 2oe7JTrrdj0sTlHp; Tue, 10 Jul 2012 10:35:43 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233]:28992 helo=[192.168.133.232]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SoeLf-003tOc-Nm; Tue, 10 Jul 2012 10:35:43 -0700 References: <22A077A4-9E8B-44B6-A0B6-C18FB67BBC20@gmx.net> <94D082C9-E6CC-4F3F-838B-A9F7F588DA60@bbn.com> In-Reply-To: <94D082C9-E6CC-4F3F-838B-A9F7F588DA60@bbn.com> Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii Message-Id: <14997FA0-9C35-46A9-97AD-0635488A2E99@brianrosen.net> Content-Transfer-Encoding: quoted-printable From: Brian Rosen Date: Tue, 10 Jul 2012 13:35:35 -0400 X-ASG-Orig-Subj: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 To: Richard L. Barnes X-Mailer: Apple Mail (2.1278) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1341941743 X-Barracuda-URL: http://64.34.111.239:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 1.17 X-Barracuda-Spam-Status: No, SCORE=1.17 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332, SARE_TOWRITE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.102309 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.05 SARE_TOWRITE BODY: Contains phrasing used by spammers 0.12 CN_BODY_332 BODY: CN_BODY_332 Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 17:35:18 -0000 Tell me more about why DNS for LIS discovery is fragile - not that I = particularly like it. There was good reason that LoST didn't allow LbyR -- it makes the whole = transaction more fragile. Local LoST server discovery is the same issue = as DNS reverse lookup - the ISP has to do it right. Hard to see how you = win with LbyR. Brian On Jul 10, 2012, at 12:31 PM, Richard L. Barnes wrote: > Hey Hannes, James, >=20 > I agree that -rough-loc seems not to be meeting some stakeholders' = needs. It does like we need a little more protocol revision. >=20 > I think that this document goes about it in the wrong way. Using the = DNS for LIS discovery is fragile, as we've discussed often in the past. = And from the perspective of client implementation, this document = completely screws up the normal location->LoST->call flow. >=20 > It would be better to allow location by reference in LoST queries. = The major challenge in that regard was that the LoST server might not be = able to dereference the URI, but that can be mitigated with local LoST = server discovery, which -phonebcp requires to be preferred over = configured LoST servers. >=20 > I'm going to take a first past at LbyR-in-LoST in a rev of rough-loc = in time for the draft deadline, so that we can have a basis for = discussion in Vancouver. >=20 > Thanks for getting this conversation started, > --Richard >=20 >=20 >=20 >=20 >=20 > On Jul 10, 2012, at 12:09 PM, Hannes Tschofenig wrote: >=20 >> Hi all,=20 >>=20 >> years ago the ECRIT working group discussed the topic of 'location = hiding' and this lead to the publication of RFC 6444 = (http://datatracker.ietf.org/doc/rfc6444/). Consequently, a solution was = developed (and is still work in progress) called "Rough Location", see = http://tools.ietf.org/id/draft-ietf-ecrit-rough-loc. >>=20 >> It looked like we solved that problem. Right?=20 >>=20 >> You may think. Early 2011, about 4 years after the first location = hiding draft was published, the European Commission (EC) comes along and = published mandate 493. Without going into the details of the mandate the = European Commission had the impression that there are no specifications = available.=20 >>=20 >> The Internet Architecture Board (IAB) provided a response to that = mandate, which you can find here: = http://www.iab.org/documents/correspondence-reports-documents/2011-2/lette= r-to-the-european-commission-on-global-interoperability-in-emergency-servi= ces/. >>=20 >> Unfortunately, the IAB interaction with the EC did not lead to the = desired outcome, i.e., to look at our documents carefully enough and to = realize that we have a solution already.=20 >>=20 >> In any case, a new standards group in ETSI was created to work on = this topic: the M493 group. This group is supposed to develop an = emergency services architecture in fulfillment of the location hiding = requirement (the mandate phrases it differently, of course but the = requirements that are discussed flow in that direction). >>=20 >> To provide feedback into that process James Winterbottom and myself = had decided to write an Internet draft for an architecture that we = believe could meet their requirements and, at the same time, re-uses = some of our earlier standardization work. >>=20 >> You can find the document here: >> http://tools.ietf.org/html/draft-winterbottom-ecrit-priv-loc-00 >>=20 >> Feedback is welcome.=20 >>=20 >> Ciao >> Hannes >>=20 >> PS: Marc, can we get an agenda slot to discuss this topic? =20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@nsn.com Tue Jul 10 10:40:28 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C360021F875C for ; Tue, 10 Jul 2012 10:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.117 X-Spam-Level: X-Spam-Status: No, score=-107.117 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, SARE_TOWRITE=1.05, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xm5oluxOX65v for ; Tue, 10 Jul 2012 10:40:27 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFD621F86EA for ; Tue, 10 Jul 2012 10:40:27 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q6AHeiQE000597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Jul 2012 19:40:44 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q6AHeiZa012963; Tue, 10 Jul 2012 19:40:44 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jul 2012 19:40:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Jul 2012 20:42:31 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D01A4937A@FIESEXC035.nsn-intra.net> In-Reply-To: <14997FA0-9C35-46A9-97AD-0635488A2E99@brianrosen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 Thread-Index: Ac1ewnXag6KdFIMsSkCjrctn5eDhlAAALL5Q References: <22A077A4-9E8B-44B6-A0B6-C18FB67BBC20@gmx.net><94D082C9-E6CC-4F3F-838B-A9F7F588DA60@bbn.com> <14997FA0-9C35-46A9-97AD-0635488A2E99@brianrosen.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Brian Rosen" , "Richard L. Barnes" X-OriginalArrivalTime: 10 Jul 2012 17:40:44.0733 (UTC) FILETIME=[22194ED0:01CD5EC3] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4833 X-purgate-ID: 151667::1341942044-0000425E-4543A318/0-0/0-0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 17:40:28 -0000 Brian, Richard,=20 the discovery of the LIS or LoST server isn't the important part of the document. This is just the stuff we had developed in ECRIT/GEOPRIV. Nothing new there.=20 So, don't get distracted.=20 The core story is that the LoST lookup is triggered by the lookup for location to the HELD server. Since the location server is local it can initiate a regular LoST lookup and channel the response back to the end device.=20 Ciao Hannes > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of ext Brian Rosen > Sent: Tuesday, July 10, 2012 8:36 PM > To: Richard L. Barnes > Cc: ecrit@ietf.org Org > Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 >=20 > Tell me more about why DNS for LIS discovery is fragile - not that I > particularly like it. >=20 > There was good reason that LoST didn't allow LbyR -- it makes the whole > transaction more fragile. Local LoST server discovery is the same issue > as DNS reverse lookup - the ISP has to do it right. Hard to see how you > win with LbyR. >=20 > Brian >=20 > On Jul 10, 2012, at 12:31 PM, Richard L. Barnes wrote: >=20 > > Hey Hannes, James, > > > > I agree that -rough-loc seems not to be meeting some stakeholders' > needs. It does like we need a little more protocol revision. > > > > I think that this document goes about it in the wrong way. Using the > DNS for LIS discovery is fragile, as we've discussed often in the past. > And from the perspective of client implementation, this document > completely screws up the normal location->LoST->call flow. > > > > It would be better to allow location by reference in LoST queries. > The major challenge in that regard was that the LoST server might not be > able to dereference the URI, but that can be mitigated with local LoST > server discovery, which -phonebcp requires to be preferred over > configured LoST servers. > > > > I'm going to take a first past at LbyR-in-LoST in a rev of rough-loc > in time for the draft deadline, so that we can have a basis for > discussion in Vancouver. > > > > Thanks for getting this conversation started, > > --Richard > > > > > > > > > > > > On Jul 10, 2012, at 12:09 PM, Hannes Tschofenig wrote: > > > >> Hi all, > >> > >> years ago the ECRIT working group discussed the topic of 'location > hiding' and this lead to the publication of RFC 6444 > (http://datatracker.ietf.org/doc/rfc6444/). Consequently, a solution was > developed (and is still work in progress) called "Rough Location", see > http://tools.ietf.org/id/draft-ietf-ecrit-rough-loc. > >> > >> It looked like we solved that problem. Right? > >> > >> You may think. Early 2011, about 4 years after the first location > hiding draft was published, the European Commission (EC) comes along and > published mandate 493. Without going into the details of the mandate the > European Commission had the impression that there are no specifications > available. > >> > >> The Internet Architecture Board (IAB) provided a response to that > mandate, which you can find here: > http://www.iab.org/documents/correspondence-reports-documents/2011- > 2/letter-to-the-european-commission-on-global-interoperability-in- > emergency-services/. > >> > >> Unfortunately, the IAB interaction with the EC did not lead to the > desired outcome, i.e., to look at our documents carefully enough and to > realize that we have a solution already. > >> > >> In any case, a new standards group in ETSI was created to work on > this topic: the M493 group. This group is supposed to develop an > emergency services architecture in fulfillment of the location hiding > requirement (the mandate phrases it differently, of course but the > requirements that are discussed flow in that direction). > >> > >> To provide feedback into that process James Winterbottom and myself > had decided to write an Internet draft for an architecture that we > believe could meet their requirements and, at the same time, re-uses > some of our earlier standardization work. > >> > >> You can find the document here: > >> http://tools.ietf.org/html/draft-winterbottom-ecrit-priv-loc-00 > >> > >> Feedback is welcome. > >> > >> Ciao > >> Hannes > >> > >> PS: Marc, can we get an agenda slot to discuss this topic? > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Tue Jul 10 11:40:27 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8923A11E80A2 for ; Tue, 10 Jul 2012 11:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.059 X-Spam-Level: X-Spam-Status: No, score=-107.059 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, SARE_TOWRITE=1.05, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 755U5Ti262xg for ; Tue, 10 Jul 2012 11:40:26 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id ACA2311E809C for ; Tue, 10 Jul 2012 11:40:26 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:56181) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SofMf-000Dgp-J6; Tue, 10 Jul 2012 14:40:49 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <14997FA0-9C35-46A9-97AD-0635488A2E99@brianrosen.net> Date: Tue, 10 Jul 2012 14:40:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <86400A7E-988A-41C9-BC4D-D2AF6F676ECE@bbn.com> References: <22A077A4-9E8B-44B6-A0B6-C18FB67BBC20@gmx.net> <94D082C9-E6CC-4F3F-838B-A9F7F588DA60@bbn.com> <14997FA0-9C35-46A9-97AD-0635488A2E99@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1278) Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 18:40:27 -0000 > Tell me more about why DNS for LIS discovery is fragile - not that I = particularly like it. Well, not the DNS per se, but rather the reverse DNS, done remotely. = Gets screwed up by things like CGNs, VPNs, etc. =20 I had in mind Figure 5 in the document, which shows the VSP proxy using = the DNS to look up the caller's LIS, which I inferred was done using the = caller's IP address. That has the fragility properties above. > There was good reason that LoST didn't allow LbyR -- it makes the = whole transaction more fragile. Local LoST server discovery is the same = issue as DNS reverse lookup - the ISP has to do it right. Hard to see = how you win with LbyR. The only reason it makes the transaction more fragile is if the request = can make its way (through the LoST hierarchy) to a server that can = access the LbyR. You can mitigate this through LoST discovery, and by = having the rough location (if any) sent along with the LoST query, so = that the LbyV can be used even if the LbyR can't. So, for example, = maybe my ISP is willing to at least say "You're in Virginia", which = would get me to a VA-level LoST server, who could dereference the LbyR = and forward the request on. Local LoST discovery is more robust than remote LIS discovery using the = DNS. It can be done without an reverse DNS at all (if there's DHCP = information). If it does fall back to reverse DNS, then things are more = fragile, but I would think still less fragile than from remote, since = the DNS resolver could take things like CGN into account. --Richard > Brian >=20 > On Jul 10, 2012, at 12:31 PM, Richard L. Barnes wrote: >=20 >> Hey Hannes, James, >>=20 >> I agree that -rough-loc seems not to be meeting some stakeholders' = needs. It does like we need a little more protocol revision. >>=20 >> I think that this document goes about it in the wrong way. Using the = DNS for LIS discovery is fragile, as we've discussed often in the past. = And from the perspective of client implementation, this document = completely screws up the normal location->LoST->call flow. >>=20 >> It would be better to allow location by reference in LoST queries. = The major challenge in that regard was that the LoST server might not be = able to dereference the URI, but that can be mitigated with local LoST = server discovery, which -phonebcp requires to be preferred over = configured LoST servers. >>=20 >> I'm going to take a first past at LbyR-in-LoST in a rev of rough-loc = in time for the draft deadline, so that we can have a basis for = discussion in Vancouver. >>=20 >> Thanks for getting this conversation started, >> --Richard >>=20 >>=20 >>=20 >>=20 >>=20 >> On Jul 10, 2012, at 12:09 PM, Hannes Tschofenig wrote: >>=20 >>> Hi all,=20 >>>=20 >>> years ago the ECRIT working group discussed the topic of 'location = hiding' and this lead to the publication of RFC 6444 = (http://datatracker.ietf.org/doc/rfc6444/). Consequently, a solution was = developed (and is still work in progress) called "Rough Location", see = http://tools.ietf.org/id/draft-ietf-ecrit-rough-loc. >>>=20 >>> It looked like we solved that problem. Right?=20 >>>=20 >>> You may think. Early 2011, about 4 years after the first location = hiding draft was published, the European Commission (EC) comes along and = published mandate 493. Without going into the details of the mandate the = European Commission had the impression that there are no specifications = available.=20 >>>=20 >>> The Internet Architecture Board (IAB) provided a response to that = mandate, which you can find here: = http://www.iab.org/documents/correspondence-reports-documents/2011-2/lette= r-to-the-european-commission-on-global-interoperability-in-emergency-servi= ces/. >>>=20 >>> Unfortunately, the IAB interaction with the EC did not lead to the = desired outcome, i.e., to look at our documents carefully enough and to = realize that we have a solution already.=20 >>>=20 >>> In any case, a new standards group in ETSI was created to work on = this topic: the M493 group. This group is supposed to develop an = emergency services architecture in fulfillment of the location hiding = requirement (the mandate phrases it differently, of course but the = requirements that are discussed flow in that direction). >>>=20 >>> To provide feedback into that process James Winterbottom and myself = had decided to write an Internet draft for an architecture that we = believe could meet their requirements and, at the same time, re-uses = some of our earlier standardization work. >>>=20 >>> You can find the document here: >>> http://tools.ietf.org/html/draft-winterbottom-ecrit-priv-loc-00 >>>=20 >>> Feedback is welcome.=20 >>>=20 >>> Ciao >>> Hannes >>>=20 >>> PS: Marc, can we get an agenda slot to discuss this topic? =20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From hannes.tschofenig@nsn.com Tue Jul 10 12:39:08 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0687311E80D9 for ; Tue, 10 Jul 2012 12:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.685 X-Spam-Level: X-Spam-Status: No, score=-106.685 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Gb3qF5Cxmx6 for ; Tue, 10 Jul 2012 12:39:07 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF0F11E80A6 for ; Tue, 10 Jul 2012 12:39:07 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q6AJdOU9019863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Jul 2012 21:39:25 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q6AJdOLw013858; Tue, 10 Jul 2012 21:39:24 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jul 2012 21:39:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Jul 2012 22:41:11 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D01A4937F@FIESEXC035.nsn-intra.net> In-Reply-To: <86400A7E-988A-41C9-BC4D-D2AF6F676ECE@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 Thread-Index: Ac1ey48gKtiwBte1QUqrFGF6EiPznQAB8ycQ References: <22A077A4-9E8B-44B6-A0B6-C18FB67BBC20@gmx.net><94D082C9-E6CC-4F3F-838B-A9F7F588DA60@bbn.com><14997FA0-9C35-46A9-97AD-0635488A2E99@brianrosen.net> <86400A7E-988A-41C9-BC4D-D2AF6F676ECE@bbn.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Richard L. Barnes" , "Brian Rosen" X-OriginalArrivalTime: 10 Jul 2012 19:39:23.0906 (UTC) FILETIME=[B574E620:01CD5ED3] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1072 X-purgate-ID: 151667::1341949165-0000425E-99443DA0/0-0/0-0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 19:39:08 -0000 Hi Richard, Hi Brian,=20 > The only reason it makes the transaction more fragile is if the request > can make its way (through the LoST hierarchy) to a server that can > access the LbyR. You can mitigate this through LoST discovery, and by > having the rough location (if any) sent along with the LoST query, so > that the LbyV can be used even if the LbyR can't. =20 We have a document for the LoST server discover using DHCP: http://tools.ietf.org/html/rfc5223 There was an issue raised a little while ago when we found out that HP had been using the same DHCP code point for some of their thin client provisioning systems (of course without registering the code point with IANA).... > So, for example, > maybe my ISP is willing to at least say "You're in Virginia", which > would get me to a VA-level LoST server, who could dereference the LbyR > and forward the request on. If that's the case then we wouldn't have to discuss this issue at all since then the currently described rough location solution would work.=20 Ciao Hannes From br@brianrosen.net Tue Jul 10 12:41:38 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A45511E812D for ; Tue, 10 Jul 2012 12:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.549 X-Spam-Level: X-Spam-Status: No, score=-104.549 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, SARE_TOWRITE=1.05, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUTm8xVpxqTT for ; Tue, 10 Jul 2012 12:41:37 -0700 (PDT) Received: from barmail6.idig.net (barmail6.idig.net [64.34.111.239]) by ietfa.amsl.com (Postfix) with ESMTP id 91AD411E80EA for ; Tue, 10 Jul 2012 12:41:37 -0700 (PDT) X-ASG-Debug-ID: 1341949325-0538de37f62b9cb0001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail6.idig.net with ESMTP id CuEJH81fIFAoWASb; Tue, 10 Jul 2012 12:42:05 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233]:28305 helo=[192.168.133.232]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SogJx-0047SX-Gn; Tue, 10 Jul 2012 12:42:05 -0700 References: <22A077A4-9E8B-44B6-A0B6-C18FB67BBC20@gmx.net> <94D082C9-E6CC-4F3F-838B-A9F7F588DA60@bbn.com> <14997FA0-9C35-46A9-97AD-0635488A2E99@brianrosen.net> <86400A7E-988A-41C9-BC4D-D2AF6F676ECE@bbn.com> In-Reply-To: <86400A7E-988A-41C9-BC4D-D2AF6F676ECE@bbn.com> Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii Message-Id: <3628224E-9D9B-44F2-8CEE-0E6ED4757AE5@brianrosen.net> Content-Transfer-Encoding: quoted-printable From: Brian Rosen Date: Tue, 10 Jul 2012 15:42:02 -0400 X-ASG-Orig-Subj: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 To: Richard L. Barnes X-Mailer: Apple Mail (2.1278) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1341949325 X-Barracuda-URL: http://64.34.111.239:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 1.17 X-Barracuda-Spam-Status: No, SCORE=1.17 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332, SARE_TOWRITE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.102317 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.05 SARE_TOWRITE BODY: Contains phrasing used by spammers 0.12 CN_BODY_332 BODY: CN_BODY_332 Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 19:41:38 -0000 On Jul 10, 2012, at 2:40 PM, Richard L. Barnes wrote: >> Tell me more about why DNS for LIS discovery is fragile - not that I = particularly like it. >=20 > Well, not the DNS per se, but rather the reverse DNS, done remotely. = Gets screwed up by things like CGNs, VPNs, etc. =20 The LIS discovery gets screwed up in exactly the same way and we're not = fixing that. LIS discovery and LoST discovery are two peas in the same = pod. >=20 > I had in mind Figure 5 in the document, which shows the VSP proxy = using the DNS to look up the caller's LIS, which I inferred was done = using the caller's IP address. That has the fragility properties above. Yes, of course - 3rd party lookup is always an issue using IP addresses. The regulators can force connections, but that only works if you don't = have any nomading. >=20 >=20 >> There was good reason that LoST didn't allow LbyR -- it makes the = whole transaction more fragile. Local LoST server discovery is the same = issue as DNS reverse lookup - the ISP has to do it right. Hard to see = how you win with LbyR. >=20 > The only reason it makes the transaction more fragile is if the = request can make its way (through the LoST hierarchy) to a server that = can access the LbyR. You can mitigate this through LoST discovery, and = by having the rough location (if any) sent along with the LoST query, so = that the LbyV can be used even if the LbyR can't. So, for example, = maybe my ISP is willing to at least say "You're in Virginia", which = would get me to a VA-level LoST server, who could dereference the LbyR = and forward the request on. But you don't need any rough loc stuff to do that. If the LIS is = willing to give you a location good enough to route to the right ESInet, = you are done. Even in the US, with 6000 PSAPs, we're not going to have 6000 ESInets. = Most of the access points will be state ESInets. In Europe, it's almost = always easier than that. We've discouraged sending two locations, including LbyV and LbyR because = of the problems when they aren't the same - what do you do? Another reason it's fragile is that the LoST server needs credentials = for the LIS, and we may have lots of LoST servers that are not actually = run by the emergency authorities. Your VPN gets you in trouble again if = the right LbyR goes to the wrong LoST server. The LoST server may not = have credentials to get the dereference. >=20 > Local LoST discovery is more robust than remote LIS discovery using = the DNS. It can be done without an reverse DNS at all (if there's DHCP = information). If it does fall back to reverse DNS, then things are more = fragile, but I would think still less fragile than from remote, since = the DNS resolver could take things like CGN into account. >=20 > --Richard >=20 >=20 >=20 >> Brian >>=20 >> On Jul 10, 2012, at 12:31 PM, Richard L. Barnes wrote: >>=20 >>> Hey Hannes, James, >>>=20 >>> I agree that -rough-loc seems not to be meeting some stakeholders' = needs. It does like we need a little more protocol revision. >>>=20 >>> I think that this document goes about it in the wrong way. Using = the DNS for LIS discovery is fragile, as we've discussed often in the = past. And from the perspective of client implementation, this document = completely screws up the normal location->LoST->call flow. >>>=20 >>> It would be better to allow location by reference in LoST queries. = The major challenge in that regard was that the LoST server might not be = able to dereference the URI, but that can be mitigated with local LoST = server discovery, which -phonebcp requires to be preferred over = configured LoST servers. >>>=20 >>> I'm going to take a first past at LbyR-in-LoST in a rev of rough-loc = in time for the draft deadline, so that we can have a basis for = discussion in Vancouver. >>>=20 >>> Thanks for getting this conversation started, >>> --Richard >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Jul 10, 2012, at 12:09 PM, Hannes Tschofenig wrote: >>>=20 >>>> Hi all,=20 >>>>=20 >>>> years ago the ECRIT working group discussed the topic of 'location = hiding' and this lead to the publication of RFC 6444 = (http://datatracker.ietf.org/doc/rfc6444/). Consequently, a solution was = developed (and is still work in progress) called "Rough Location", see = http://tools.ietf.org/id/draft-ietf-ecrit-rough-loc. >>>>=20 >>>> It looked like we solved that problem. Right?=20 >>>>=20 >>>> You may think. Early 2011, about 4 years after the first location = hiding draft was published, the European Commission (EC) comes along and = published mandate 493. Without going into the details of the mandate the = European Commission had the impression that there are no specifications = available.=20 >>>>=20 >>>> The Internet Architecture Board (IAB) provided a response to that = mandate, which you can find here: = http://www.iab.org/documents/correspondence-reports-documents/2011-2/lette= r-to-the-european-commission-on-global-interoperability-in-emergency-servi= ces/. >>>>=20 >>>> Unfortunately, the IAB interaction with the EC did not lead to the = desired outcome, i.e., to look at our documents carefully enough and to = realize that we have a solution already.=20 >>>>=20 >>>> In any case, a new standards group in ETSI was created to work on = this topic: the M493 group. This group is supposed to develop an = emergency services architecture in fulfillment of the location hiding = requirement (the mandate phrases it differently, of course but the = requirements that are discussed flow in that direction). >>>>=20 >>>> To provide feedback into that process James Winterbottom and myself = had decided to write an Internet draft for an architecture that we = believe could meet their requirements and, at the same time, re-uses = some of our earlier standardization work. >>>>=20 >>>> You can find the document here: >>>> http://tools.ietf.org/html/draft-winterbottom-ecrit-priv-loc-00 >>>>=20 >>>> Feedback is welcome.=20 >>>>=20 >>>> Ciao >>>> Hannes >>>>=20 >>>> PS: Marc, can we get an agenda slot to discuss this topic? =20 >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 From hannes.tschofenig@nsn.com Tue Jul 10 12:45:29 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C84411E80E3 for ; Tue, 10 Jul 2012 12:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.677 X-Spam-Level: X-Spam-Status: No, score=-106.677 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kU3+Mq4Lh6v for ; Tue, 10 Jul 2012 12:45:28 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5D021F861C for ; Tue, 10 Jul 2012 12:45:28 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q6AJjkdv009398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Jul 2012 21:45:46 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q6AJjku0023117; Tue, 10 Jul 2012 21:45:46 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jul 2012 21:45:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Jul 2012 22:47:33 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D01A49381@FIESEXC035.nsn-intra.net> In-Reply-To: <3628224E-9D9B-44F2-8CEE-0E6ED4757AE5@brianrosen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 Thread-Index: Ac1e1B2rRaetoiNATnyB3a96Eo1nRAAAFrdQ References: <22A077A4-9E8B-44B6-A0B6-C18FB67BBC20@gmx.net><94D082C9-E6CC-4F3F-838B-A9F7F588DA60@bbn.com><14997FA0-9C35-46A9-97AD-0635488A2E99@brianrosen.net><86400A7E-988A-41C9-BC4D-D2AF6F676ECE@bbn.com> <3628224E-9D9B-44F2-8CEE-0E6ED4757AE5@brianrosen.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Brian Rosen" , "Richard L. Barnes" X-OriginalArrivalTime: 10 Jul 2012 19:45:46.0581 (UTC) FILETIME=[998C7850:01CD5ED4] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 859 X-purgate-ID: 151667::1341949546-00003CDD-84688D94/0-0/0-0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 19:45:29 -0000 Hi Brian,=20 > Even in the US, with 6000 PSAPs, we're not going to have 6000 ESInets. > Most of the access points will be state ESInets. In Europe, it's almost > always easier than that. >=20 > We've discouraged sending two locations, including LbyV and LbyR because > of the problems when they aren't the same - what do you do? It is true that in most countries it is pretty trivial.=20 However, the problem is that some European countries want to stick with their existing PSAP infrastructure. For example, Germany is such a case and they have a number of PSAPs.=20 They also do not want to introduce an ESRP either.=20 Why they have managed to come up with a different view in case of eCall is a mystery to me but that's what I had been told.=20 So, in some sense you could call it a legacy deployment.=20 Ciao Hannes From br@brianrosen.net Tue Jul 10 12:53:42 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDDC11E80FB for ; Tue, 10 Jul 2012 12:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.074 X-Spam-Level: X-Spam-Status: No, score=-104.074 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPeHTJ6byLQS for ; Tue, 10 Jul 2012 12:53:41 -0700 (PDT) Received: from barmail6.idig.net (barmail6.idig.net [64.34.111.239]) by ietfa.amsl.com (Postfix) with ESMTP id 942BF11E80D9 for ; Tue, 10 Jul 2012 12:53:41 -0700 (PDT) X-ASG-Debug-ID: 1341949941-0538de37f52bb000001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail6.idig.net with ESMTP id Gf09oIgg93gIJVZI; Tue, 10 Jul 2012 12:52:21 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233]:28467 helo=[192.168.133.232]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SogTt-0048oA-9M; Tue, 10 Jul 2012 12:52:21 -0700 References: <22A077A4-9E8B-44B6-A0B6-C18FB67BBC20@gmx.net><94D082C9-E6CC-4F3F-838B-A9F7F588DA60@bbn.com><14997FA0-9C35-46A9-97AD-0635488A2E99@brianrosen.net><86400A7E-988A-41C9-BC4D-D2AF6F676ECE@bbn.com> <3628224E-9D9B-44F2-8CEE-0E6ED4757AE5@brianrosen.net> <999913AB42CC9341B05A99BBF358718D01A49381@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718D01A49381@FIESEXC035.nsn-intra.net> Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Brian Rosen Date: Tue, 10 Jul 2012 15:52:18 -0400 X-ASG-Orig-Subj: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 To: "Tschofenig, Hannes (NSN - FI/Espoo)" X-Mailer: Apple Mail (2.1278) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1341949941 X-Barracuda-URL: http://64.34.111.239:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.102317 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 19:53:42 -0000 Okay, but where are the boundaries? Do they equate to U.S. state = boundaries or equivalent? Where is the actual problem? I can get you a whole lot closer to a = state given an IP address right now. Who is hiding what? Brian On Jul 10, 2012, at 3:47 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi Brian,=20 >=20 >=20 >> Even in the US, with 6000 PSAPs, we're not going to have 6000 = ESInets. >> Most of the access points will be state ESInets. In Europe, it's > almost >> always easier than that. >>=20 >> We've discouraged sending two locations, including LbyV and LbyR > because >> of the problems when they aren't the same - what do you do? >=20 > It is true that in most countries it is pretty trivial.=20 >=20 > However, the problem is that some European countries want to stick = with > their existing PSAP infrastructure. For example, Germany is such a = case > and they have a number of PSAPs.=20 > They also do not want to introduce an ESRP either.=20 >=20 > Why they have managed to come up with a different view in case of = eCall > is a mystery to me but that's what I had been told.=20 >=20 > So, in some sense you could call it a legacy deployment.=20 >=20 > Ciao > Hannes >=20 >=20 From hannes.tschofenig@gmx.net Tue Jul 10 13:06:37 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42BA21F86BA for ; Tue, 10 Jul 2012 13:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 598DNd+Yz6WP for ; Tue, 10 Jul 2012 13:06:37 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 69B3D21F86BB for ; Tue, 10 Jul 2012 13:06:36 -0700 (PDT) Received: (qmail invoked by alias); 10 Jul 2012 20:07:03 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.106]) [88.115.216.191] by mail.gmx.net (mp038) with SMTP; 10 Jul 2012 22:07:03 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1897K0asls9PH6BB0Hq/hIqJ/sJoYqSIfGojSJWHI a5Eapqk8KI/eIf Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Tue, 10 Jul 2012 23:06:58 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <71175DF8-B98C-4F9E-96BC-A63F3498049F@gmx.net> References: <22A077A4-9E8B-44B6-A0B6-C18FB67BBC20@gmx.net><94D082C9-E6CC-4F3F-838B-A9F7F588DA60@bbn.com><14997FA0-9C35-46A9-97AD-0635488A2E99@brianrosen.net><86400A7E-988A-41C9-BC4D-D2AF6F676ECE@bbn.com> <3628224E-9D9B-44F2-8CEE-0E6ED4757AE5@brianrosen.net> <999913AB42CC9341B05A99BBF358718D01A49381@FIESEXC035.nsn-intra.net> To: Brian Rosen X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 20:06:38 -0000 I will ask for the precise number of PSAPs in some European countries = and whether their service boundaries are available.=20 On Jul 10, 2012, at 10:52 PM, Brian Rosen wrote: > Okay, but where are the boundaries? Do they equate to U.S. state = boundaries or equivalent? > Where is the actual problem? I can get you a whole lot closer to a = state given an IP address right now. Who is hiding what? >=20 > Brian >=20 > On Jul 10, 2012, at 3:47 PM, Tschofenig, Hannes (NSN - FI/Espoo) = wrote: >=20 >> Hi Brian,=20 >>=20 >>=20 >>> Even in the US, with 6000 PSAPs, we're not going to have 6000 = ESInets. >>> Most of the access points will be state ESInets. In Europe, it's >> almost >>> always easier than that. >>>=20 >>> We've discouraged sending two locations, including LbyV and LbyR >> because >>> of the problems when they aren't the same - what do you do? >>=20 >> It is true that in most countries it is pretty trivial.=20 >>=20 >> However, the problem is that some European countries want to stick = with >> their existing PSAP infrastructure. For example, Germany is such a = case >> and they have a number of PSAPs.=20 >> They also do not want to introduce an ESRP either.=20 >>=20 >> Why they have managed to come up with a different view in case of = eCall >> is a mystery to me but that's what I had been told.=20 >>=20 >> So, in some sense you could call it a legacy deployment.=20 >>=20 >> Ciao >> Hannes >>=20 >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@gmx.net Tue Jul 10 13:13:52 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2977111E80A6 for ; Tue, 10 Jul 2012 13:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYQAXHi58cl8 for ; Tue, 10 Jul 2012 13:13:51 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 18CE611E809A for ; Tue, 10 Jul 2012 13:13:50 -0700 (PDT) Received: (qmail invoked by alias); 10 Jul 2012 20:14:18 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.106]) [88.115.216.191] by mail.gmx.net (mp024) with SMTP; 10 Jul 2012 22:14:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/lHSdaQQPlkergNPkdbJ1MGZW4Bk8xHbOuRqPlZi WR0Hc94YY+Y0B7 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Jul 2012 23:14:17 +0300 Message-Id: <9AB6AD2F-B193-4964-8F1B-1EBE8ABB6FF9@gmx.net> To: "ecrit@ietf.org Org" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [Ecrit] ECRIT Direct X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 20:13:52 -0000 Hi Richard, Hi Brian,=20 I would like to bring this old document back into the discussion since = it is relevant IMHO. In a slightly modified form it provides the features we want as well.=20 Here is the doc:=20 = https://raw.github.com/hannestschofenig/tschofenig-ids/master/ecrit-direct= /draft-winterbottom-ecrit-direct-02.txt What do you guys think?=20 Ciao Hannes From br@brianrosen.net Tue Jul 10 14:15:27 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9521321F862A for ; Tue, 10 Jul 2012 14:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.916 X-Spam-Level: X-Spam-Status: No, score=-103.916 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdEdxwkFbpLi for ; Tue, 10 Jul 2012 14:15:26 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id C847721F862F for ; Tue, 10 Jul 2012 14:15:26 -0700 (PDT) X-ASG-Debug-ID: 1341954954-04d035105905290001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id zK7oWk3fvps2t94w; Tue, 10 Jul 2012 14:15:54 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233]:42381 helo=[192.168.133.232]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Sohml-004I5G-JA; Tue, 10 Jul 2012 14:15:55 -0700 References: <9AB6AD2F-B193-4964-8F1B-1EBE8ABB6FF9@gmx.net> In-Reply-To: <9AB6AD2F-B193-4964-8F1B-1EBE8ABB6FF9@gmx.net> Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii Message-Id: <7D88E7AD-55EB-4867-B210-E4666525887F@brianrosen.net> Content-Transfer-Encoding: quoted-printable From: Brian Rosen Date: Tue, 10 Jul 2012 17:15:52 -0400 X-ASG-Orig-Subj: Re: [Ecrit] ECRIT Direct To: Hannes Tschofenig X-Mailer: Apple Mail (2.1278) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1341954954 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.102323 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] ECRIT Direct X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 21:15:27 -0000 I think it's a terrible idea to require an access network to operate a = SIP proxy server. It's one thing to force it to supply location. It's quite another to force it to be in the call path of an emergency = call. It works, technically, with all the limitations of VPNs and other things = that totally screw up all of this stuff if you aren't really careful. = For example, does the ISP have to serve a call for which it is not the = ISP because some VPN is in the path? How about an enterprise? It's just a bad idea in my opinion. Brian On Jul 10, 2012, at 4:14 PM, Hannes Tschofenig wrote: > Hi Richard, Hi Brian,=20 >=20 > I would like to bring this old document back into the discussion since = it is relevant IMHO. > In a slightly modified form it provides the features we want as well.=20= >=20 > Here is the doc:=20 > = https://raw.github.com/hannestschofenig/tschofenig-ids/master/ecrit-direct= /draft-winterbottom-ecrit-direct-02.txt >=20 > What do you guys think?=20 >=20 > Ciao > Hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From bernard_aboba@hotmail.com Tue Jul 10 14:57:22 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACF211E80F8 for ; Tue, 10 Jul 2012 14:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.899 X-Spam-Level: X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRdkltyscNEw for ; Tue, 10 Jul 2012 14:57:21 -0700 (PDT) Received: from blu0-omc3-s36.blu0.hotmail.com (blu0-omc3-s36.blu0.hotmail.com [65.55.116.111]) by ietfa.amsl.com (Postfix) with ESMTP id C7C7B11E80E6 for ; Tue, 10 Jul 2012 14:57:21 -0700 (PDT) Received: from BLU169-DS33 ([65.55.116.74]) by blu0-omc3-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jul 2012 14:57:49 -0700 X-Originating-IP: [64.134.136.11] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'Brian Rosen'" , "'Hannes Tschofenig'" References: <9AB6AD2F-B193-4964-8F1B-1EBE8ABB6FF9@gmx.net> <7D88E7AD-55EB-4867-B210-E4666525887F@brianrosen.net> In-Reply-To: <7D88E7AD-55EB-4867-B210-E4666525887F@brianrosen.net> Date: Tue, 10 Jul 2012 14:57:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH3O7oviPEyAPCxB0iIs9m29uMnsAGuDGb1lsHkQPA= Content-Language: en-us X-OriginalArrivalTime: 10 Jul 2012 21:57:49.0249 (UTC) FILETIME=[0BD3AB10:01CD5EE7] Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Direct X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 21:57:22 -0000 Have to agree with Brian on this. >From a practical point of view, if the access network isn't already a VoIP provider, then you are asking them to provide services in an area in which they have no experience, where there are lives at stake. I doubt that access network providers (such as hotspots) will be enthusiastic about this, to put it mildly. If the access network is already a VoIP provider, then they already need to provide emergency services for their own customers, so they won't see the need. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, July 10, 2012 2:16 PM To: Hannes Tschofenig Cc: ecrit@ietf.org Org Subject: Re: [Ecrit] ECRIT Direct I think it's a terrible idea to require an access network to operate a SIP proxy server. It's one thing to force it to supply location. It's quite another to force it to be in the call path of an emergency call. It works, technically, with all the limitations of VPNs and other things that totally screw up all of this stuff if you aren't really careful. For example, does the ISP have to serve a call for which it is not the ISP because some VPN is in the path? How about an enterprise? It's just a bad idea in my opinion. Brian On Jul 10, 2012, at 4:14 PM, Hannes Tschofenig wrote: > Hi Richard, Hi Brian, > > I would like to bring this old document back into the discussion since it is relevant IMHO. > In a slightly modified form it provides the features we want as well. > > Here is the doc: > https://raw.github.com/hannestschofenig/tschofenig-ids/master/ecrit-direct/d raft-winterbottom-ecrit-direct-02.txt > > What do you guys think? > > Ciao > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@nsn.com Tue Jul 10 22:27:45 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4534F21F85FF for ; Tue, 10 Jul 2012 22:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.669 X-Spam-Level: X-Spam-Status: No, score=-106.669 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypWicfTxe2Fa for ; Tue, 10 Jul 2012 22:27:44 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id DA05321F857A for ; Tue, 10 Jul 2012 22:27:43 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q6B5S1YV025540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jul 2012 07:28:02 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q6B5S0E1025680; Wed, 11 Jul 2012 07:28:00 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jul 2012 07:28:01 +0200 Received: from 10.159.32.93 ([10.159.32.93]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) with Microsoft Exchange Server HTTP-DAV ; Wed, 11 Jul 2012 05:28:00 +0000 MIME-Version: 1.0 From: "Tschofenig, Hannes (NSN - FI/Espoo)" Message-ID: <068501cd5f25$ef41716f$5d209f0a@nsnintra.net> Date: Wed, 11 Jul 2012 08:28:01 +0300 To: "ext Bernard Aboba" , "'Brian Rosen'" , "'Hannes Tschofenig'" Thread-Topic: [Ecrit] ECRIT Direct Thread-Index: Ac1fJe9BUF9a9DSdTuOGHDxCdoVg7A== Content-Type: multipart/alternative; boundary="_20030DED-5A58-65F0-D18E-3892746FC9E9_"; charset="iso-8859-1" X-OriginalArrivalTime: 11 Jul 2012 05:28:01.0169 (UTC) FILETIME=[F02F9010:01CD5F25] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 7145 X-purgate-ID: 151667::1341984482-0000425E-4A204916/0-0/0-0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Direct X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 05:27:45 -0000 --_20030DED-5A58-65F0-D18E-3892746FC9E9_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" I agree with both of you. Forcing the access provider to deploy ESRPs was not my idea. In fact, that= 's the proposal put forward by others in ETSI. Instead, ECRIT Direct suggests to send the emergency call directly from the= end device to the PASP/ESRP instead of going through the Voip provider. Ciao Hannes Sent from my Windows Phone -----Original Message----- From: ext Bernard Aboba Sent: 7/11/2012 12:57 AM To: 'Brian Rosen'; 'Hannes Tschofenig' Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Direct Have to agree with Brian on this.=20 >From a practical point of view, if the access network isn't already a VoIP provider, then you are asking them to provide services in an area in which they have no experience, where there are lives at stake. I doubt that access network providers (such as hotspots) will be enthusiastic about this= , to put it mildly.=20 If the access network is already a VoIP provider, then they already need to provide emergency services for their own customers, so they won't see the need.=20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, July 10, 2012 2:16 PM To: Hannes Tschofenig Cc: ecrit@ietf.org Org Subject: Re: [Ecrit] ECRIT Direct I think it's a terrible idea to require an access network to operate a SIP proxy server. It's one thing to force it to supply location. It's quite another to force it to be in the call path of an emergency call. It works, technically, with all the limitations of VPNs and other things that totally screw up all of this stuff if you aren't really careful. For example, does the ISP have to serve a call for which it is not the ISP because some VPN is in the path? How about an enterprise? It's just a bad idea in my opinion. Brian On Jul 10, 2012, at 4:14 PM, Hannes Tschofenig wrote: > Hi Richard, Hi Brian,=20 >=20 > I would like to bring this old document back into the discussion since it is relevant IMHO. > In a slightly modified form it provides the features we want as well.=20 >=20 > Here is the doc:=20 > https://raw.github.com/hannestschofenig/tschofenig-ids/master/ecrit-direct/= d raft-winterbottom-ecrit-direct-02.txt >=20 > What do you guys think?=20 >=20 > Ciao > Hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_20030DED-5A58-65F0-D18E-3892746FC9E9_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
I agree with both of you.

Forcing the access p= rovider to deploy ESRPs was not my idea. In fact, that's the proposal put f= orward by others in ETSI.

Instead, ECRIT Direct suggests to send the= emergency call directly from the end device to the PASP/ESRP instead of go= ing through the Voip provider.

Ciao
Hannes

Sent from my Wi= ndows Phone
From: ext Bernard Aboba
Sent: 7/11/2012 12:57 AM
To: 'Brian Rosen'; 'Hannes Tscho= fenig'
Cc: ecrit@ietf.org
Subject: Re: [Ecr= it] ECRIT Direct

Have to agree with Brian on this.

Fr= om a practical point of view, if the access network isn't already a VoIPprovider, then you are asking them to provide services in an area in which=
they have no experience, where there are lives at stake.  I doubt = that
access network providers (such as hotspots) will be enthusiastic ab= out this,
to put it mildly.

If the access network is already a V= oIP provider, then they already need to
provide emergency services for t= heir own customers, so they won't see the
need.

-----Original Me= ssage-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] = On Behalf Of
Brian Rosen
Sent: Tuesday, July 10, 2012 2:16 PM
To: = Hannes Tschofenig
Cc: ecrit@ietf.org Org
Subject: Re: [Ecrit] ECRIT D= irect

I think it's a terrible idea to require an access network to o= perate a SIP
proxy server.

It's one thing to force it to supply l= ocation.

It's quite another to force it to be in the call path of an= emergency call.

It works, technically, with all the limitations of = VPNs and other things
that totally screw up all of this stuff if you are= n't really careful.  For
example, does the ISP have to serve a call= for which it is not the ISP
because some VPN is in the path?

How= about an enterprise?

It's just a bad idea in my opinion.

Bri= an

On Jul 10, 2012, at 4:14 PM, Hannes Tschofenig wrote:

>= Hi Richard, Hi Brian,
>
> I would like to bring this old doc= ument back into the discussion since it
is relevant IMHO.
> In a s= lightly modified form it provides the features we want as well.
> > Here is the doc:
>
https://raw.github.com/hannestschofenig= /tschofenig-ids/master/ecrit-direct/d
raft-winterbottom-ecrit-direct-02.= txt
>
> What do you guys think?
>
> Ciao
>= Hannes
>
> _______________________________________________> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.or= g/mailman/listinfo/ecrit

___________________________________________= ____
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailma= n/listinfo/ecrit

_______________________________________________
= Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listin= fo/ecrit
= --_20030DED-5A58-65F0-D18E-3892746FC9E9_-- From mlinsner@cisco.com Wed Jul 11 09:56:59 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADECA11E8116 for ; Wed, 11 Jul 2012 09:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvuyH303WhT8 for ; Wed, 11 Jul 2012 09:56:59 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 19B8211E80EF for ; Wed, 11 Jul 2012 09:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=349; q=dns/txt; s=iport; t=1342025850; x=1343235450; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=gf5gMtRoRTSrHx8kRJfQTbPevXUDbMgapSwI45twIuc=; b=et8+ls2HB6SPxvBas/VpJHwPskBX2ZKPzHlluhkDHiqlL3WZPi2f6Bbd cPabeKMMjdVmzM3qzwzZRFTorvWbVdpERBctCU+zsBgycgol7lQHCgbdy UxWq3qx2YcBJpmdafrDcseQE2LkwxAolIwENoqfV9u5evHdUbN2+C0QMj Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAOw/U+tJXG//2dsb2JhbABFt2yBB4InEgEnAgE8EwiBHQYBDSeHa51GoB+RLgOVOoVWiEqBZoJ7 X-IronPort-AV: E=Sophos;i="4.77,569,1336348800"; d="scan'208";a="100888169" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 11 Jul 2012 16:57:29 +0000 Received: from [10.116.195.114] (rtp-mlinsner-8711.cisco.com [10.116.195.114]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6BGvRCk023237; Wed, 11 Jul 2012 16:57:28 GMT User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 11 Jul 2012 12:57:25 -0400 From: Marc Linsner To: "Richard L. Barnes" , Hannes Tschofenig Message-ID: Thread-Topic: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 In-Reply-To: <94D082C9-E6CC-4F3F-838B-A9F7F588DA60@bbn.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 16:56:59 -0000 Richard, > >I'm going to take a first past at LbyR-in-LoST in a rev of rough-loc in >time for the draft deadline, so that we can have a basis for discussion >in Vancouver. > >Thanks for getting this conversation started, >--Richard Rough-loc is a WG document that's been through wglc. New ideas need to be in a new draft. -Marc- From hannes.tschofenig@gmx.net Wed Jul 11 10:04:58 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D1711E8096 for ; Wed, 11 Jul 2012 10:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.614 X-Spam-Level: X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gv6Z0C4U95yI for ; Wed, 11 Jul 2012 10:04:57 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E079311E8088 for ; Wed, 11 Jul 2012 10:04:56 -0700 (PDT) Received: (qmail invoked by alias); 11 Jul 2012 17:05:27 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.106]) [88.115.216.191] by mail.gmx.net (mp041) with SMTP; 11 Jul 2012 19:05:27 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/WAFUaYiPWGCL25hYR9Du7xX9i3m9FToJonotzn/ xa94Uvvh8/qXSl Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Wed, 11 Jul 2012 20:05:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <53C19D8F-680F-4D0E-AFBB-C2B865B04CB2@gmx.net> References: To: Marc Linsner X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 17:04:58 -0000 That's a good point, Marc.=20 The document has good content even though it does not meet the needs of = everyone.=20 On Jul 11, 2012, at 7:57 PM, Marc Linsner wrote: > Richard, >=20 >=20 >>=20 >> I'm going to take a first past at LbyR-in-LoST in a rev of rough-loc = in >> time for the draft deadline, so that we can have a basis for = discussion >> in Vancouver. >>=20 >> Thanks for getting this conversation started, >> --Richard >=20 > Rough-loc is a WG document that's been through wglc. New ideas need = to be > in a new draft. >=20 > -Marc- >=20 >=20 From rbarnes@bbn.com Thu Jul 12 12:45:06 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547A821F861A for ; Thu, 12 Jul 2012 12:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITYncwqYhBA1 for ; Thu, 12 Jul 2012 12:45:05 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id BFB5D21F8617 for ; Thu, 12 Jul 2012 12:45:05 -0700 (PDT) Received: from ros-dhcp192-1-51-20.bbn.com ([192.1.51.20]:50063) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SpPKR-000DwQ-DX; Thu, 12 Jul 2012 15:45:35 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <999913AB42CC9341B05A99BBF358718D01A4937F@FIESEXC035.nsn-intra.net> Date: Thu, 12 Jul 2012 15:45:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5A8F2A5C-0A86-4EB4-B188-AEEC2A9A08C9@bbn.com> References: <22A077A4-9E8B-44B6-A0B6-C18FB67BBC20@gmx.net><94D082C9-E6CC-4F3F-838B-A9F7F588DA60@bbn.com><14997FA0-9C35-46A9-97AD-0635488A2E99@brianrosen.net> <86400A7E-988A-41C9-BC4D-D2AF6F676ECE@bbn.com> <999913AB42CC9341B05A99BBF358718D01A4937F@FIESEXC035.nsn-intra.net> To: "Tschofenig, Hannes (NSN - FI/Espoo)" X-Mailer: Apple Mail (2.1278) Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 19:45:06 -0000 >> The only reason it makes the transaction more fragile is if the > request >> can make its way (through the LoST hierarchy) to a server that can >> access the LbyR. You can mitigate this through LoST discovery, and = by >> having the rough location (if any) sent along with the LoST query, so >> that the LbyV can be used even if the LbyR can't. =20 >=20 > We have a document for the LoST server discover using DHCP: > http://tools.ietf.org/html/rfc5223 >=20 > There was an issue raised a little while ago when we found out that HP > had been using the same DHCP code point for some of their thin client > provisioning systems (of course without registering the code point = with > IANA).... I had gotten in touch with some HP guys on this, but I forget where that = conversation ended up. I'll see if I can find the messages. >> So, for example, >> maybe my ISP is willing to at least say "You're in Virginia", which >> would get me to a VA-level LoST server, who could dereference the = LbyR >> and forward the request on. >=20 > If that's the case then we wouldn't have to discuss this issue at all > since then the currently described rough location solution would work.=20= Only if there's a VA PSAP. If there's any finer granularity (and there = is), then "You're in Virginia" is not good enough to get me to a PSAP. --Richard= From rbarnes@bbn.com Thu Jul 12 12:50:50 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D14611E8116 for ; Thu, 12 Jul 2012 12:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.064 X-Spam-Level: X-Spam-Status: No, score=-107.064 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, SARE_TOWRITE=1.05, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSBUplQV1EpL for ; Thu, 12 Jul 2012 12:50:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B937911E8114 for ; Thu, 12 Jul 2012 12:50:46 -0700 (PDT) Received: from ros-dhcp192-1-51-20.bbn.com ([192.1.51.20]:50072) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SpPPz-000E3a-BO; Thu, 12 Jul 2012 15:51:19 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <3628224E-9D9B-44F2-8CEE-0E6ED4757AE5@brianrosen.net> Date: Thu, 12 Jul 2012 15:51:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <22A077A4-9E8B-44B6-A0B6-C18FB67BBC20@gmx.net> <94D082C9-E6CC-4F3F-838B-A9F7F588DA60@bbn.com> <14997FA0-9C35-46A9-97AD-0635488A2E99@brianrosen.net> <86400A7E-988A-41C9-BC4D-D2AF6F676ECE@bbn.com> <3628224E-9D9B-44F2-8CEE-0E6ED4757AE5@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1278) Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 19:50:50 -0000 >>> Tell me more about why DNS for LIS discovery is fragile - not that I = particularly like it. >>=20 >> Well, not the DNS per se, but rather the reverse DNS, done remotely. = Gets screwed up by things like CGNs, VPNs, etc. =20 > The LIS discovery gets screwed up in exactly the same way and we're = not fixing that. LIS discovery and LoST discovery are two peas in the = same pod. By the same token, if LIS discovery works (as required by -priv-loc), = then LoST discovery should too. So there's no incremental fragility. >>> There was good reason that LoST didn't allow LbyR -- it makes the = whole transaction more fragile. Local LoST server discovery is the same = issue as DNS reverse lookup - the ISP has to do it right. Hard to see = how you win with LbyR. >>=20 >> The only reason it makes the transaction more fragile is if the = request can make its way (through the LoST hierarchy) to a server that = can access the LbyR. You can mitigate this through LoST discovery, and = by having the rough location (if any) sent along with the LoST query, so = that the LbyV can be used even if the LbyR can't. So, for example, = maybe my ISP is willing to at least say "You're in Virginia", which = would get me to a VA-level LoST server, who could dereference the LbyR = and forward the request on. > But you don't need any rough loc stuff to do that. If the LIS is = willing to give you a location good enough to route to the right ESInet, = you are done. >=20 > Even in the US, with 6000 PSAPs, we're not going to have 6000 ESInets. = Most of the access points will be state ESInets. In Europe, it's = almost always easier than that. >=20 > We've discouraged sending two locations, including LbyV and LbyR = because of the problems when they aren't the same - what do you do? >=20 > Another reason it's fragile is that the LoST server needs credentials = for the LIS, and we may have lots of LoST servers that are not actually = run by the emergency authorities. Your VPN gets you in trouble again if = the right LbyR goes to the wrong LoST server. The LoST server may not = have credentials to get the dereference. That last point is why you want the captive LoST server and the rough = loc. If the client uses the captive LoST server, then you're good; the = ISP can arrange everything so it works. If the client uses some other = server, then the rough loc can get him to an authorized server. Note that this is a different degree of "roughness" / precision than = we've talked about before: Not precise enough to get you to a PSAP, just = precise enough to get you to an authorized LoST server. --Richard >=20 >=20 >>=20 >> Local LoST discovery is more robust than remote LIS discovery using = the DNS. It can be done without an reverse DNS at all (if there's DHCP = information). If it does fall back to reverse DNS, then things are more = fragile, but I would think still less fragile than from remote, since = the DNS resolver could take things like CGN into account. >>=20 >> --Richard >>=20 >>=20 >>=20 >>> Brian >>>=20 >>> On Jul 10, 2012, at 12:31 PM, Richard L. Barnes wrote: >>>=20 >>>> Hey Hannes, James, >>>>=20 >>>> I agree that -rough-loc seems not to be meeting some stakeholders' = needs. It does like we need a little more protocol revision. >>>>=20 >>>> I think that this document goes about it in the wrong way. Using = the DNS for LIS discovery is fragile, as we've discussed often in the = past. And from the perspective of client implementation, this document = completely screws up the normal location->LoST->call flow. >>>>=20 >>>> It would be better to allow location by reference in LoST queries. = The major challenge in that regard was that the LoST server might not be = able to dereference the URI, but that can be mitigated with local LoST = server discovery, which -phonebcp requires to be preferred over = configured LoST servers. >>>>=20 >>>> I'm going to take a first past at LbyR-in-LoST in a rev of = rough-loc in time for the draft deadline, so that we can have a basis = for discussion in Vancouver. >>>>=20 >>>> Thanks for getting this conversation started, >>>> --Richard >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Jul 10, 2012, at 12:09 PM, Hannes Tschofenig wrote: >>>>=20 >>>>> Hi all,=20 >>>>>=20 >>>>> years ago the ECRIT working group discussed the topic of 'location = hiding' and this lead to the publication of RFC 6444 = (http://datatracker.ietf.org/doc/rfc6444/). Consequently, a solution was = developed (and is still work in progress) called "Rough Location", see = http://tools.ietf.org/id/draft-ietf-ecrit-rough-loc. >>>>>=20 >>>>> It looked like we solved that problem. Right?=20 >>>>>=20 >>>>> You may think. Early 2011, about 4 years after the first location = hiding draft was published, the European Commission (EC) comes along and = published mandate 493. Without going into the details of the mandate the = European Commission had the impression that there are no specifications = available.=20 >>>>>=20 >>>>> The Internet Architecture Board (IAB) provided a response to that = mandate, which you can find here: = http://www.iab.org/documents/correspondence-reports-documents/2011-2/lette= r-to-the-european-commission-on-global-interoperability-in-emergency-servi= ces/. >>>>>=20 >>>>> Unfortunately, the IAB interaction with the EC did not lead to the = desired outcome, i.e., to look at our documents carefully enough and to = realize that we have a solution already.=20 >>>>>=20 >>>>> In any case, a new standards group in ETSI was created to work on = this topic: the M493 group. This group is supposed to develop an = emergency services architecture in fulfillment of the location hiding = requirement (the mandate phrases it differently, of course but the = requirements that are discussed flow in that direction). >>>>>=20 >>>>> To provide feedback into that process James Winterbottom and = myself had decided to write an Internet draft for an architecture that = we believe could meet their requirements and, at the same time, re-uses = some of our earlier standardization work. >>>>>=20 >>>>> You can find the document here: >>>>> http://tools.ietf.org/html/draft-winterbottom-ecrit-priv-loc-00 >>>>>=20 >>>>> Feedback is welcome.=20 >>>>>=20 >>>>> Ciao >>>>> Hannes >>>>>=20 >>>>> PS: Marc, can we get an agenda slot to discuss this topic? =20 >>>>>=20 >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>=20 >=20 From rbarnes@bbn.com Thu Jul 12 12:54:24 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF3921F86A4 for ; Thu, 12 Jul 2012 12:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.596 X-Spam-Level: X-Spam-Status: No, score=-106.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAu0WFQPKf3A for ; Thu, 12 Jul 2012 12:54:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 11C3421F86A5 for ; Thu, 12 Jul 2012 12:54:24 -0700 (PDT) Received: from ros-dhcp192-1-51-20.bbn.com ([192.1.51.20]:50076) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SpPTU-0006li-JD; Thu, 12 Jul 2012 15:54:56 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Thu, 12 Jul 2012 15:54:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <18E3CF29-296D-4942-B254-1745978CA84D@bbn.com> References: To: Marc Linsner X-Mailer: Apple Mail (2.1278) Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 19:54:24 -0000 On Jul 11, 2012, at 12:57 PM, Marc Linsner wrote: > Richard, >=20 >=20 >>=20 >> I'm going to take a first past at LbyR-in-LoST in a rev of rough-loc = in >> time for the draft deadline, so that we can have a basis for = discussion >> in Vancouver. >>=20 >> Thanks for getting this conversation started, >> --Richard >=20 > Rough-loc is a WG document that's been through wglc. New ideas need = to be > in a new draft. >=20 > -Marc- I'm not sure I agree. Doesn't the current conversation demonstrate that = rough-loc doesn't solve the problem it was intended to solve? I was = taking this thread as very late WGLC comments -- or early IETF LC = comments :) If you still want me to hold off, let me know and I will. --Richard= From rbarnes@bbn.com Thu Jul 12 12:55:54 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8277221F86A4 for ; Thu, 12 Jul 2012 12:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.596 X-Spam-Level: X-Spam-Status: No, score=-106.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plUKAWIXz6Ny for ; Thu, 12 Jul 2012 12:55:54 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0E64521F8611 for ; Thu, 12 Jul 2012 12:55:54 -0700 (PDT) Received: from ros-dhcp192-1-51-20.bbn.com ([192.1.51.20]:50077) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SpPUs-000EA2-0y; Thu, 12 Jul 2012 15:56:22 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <53C19D8F-680F-4D0E-AFBB-C2B865B04CB2@gmx.net> Date: Thu, 12 Jul 2012 15:56:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4BEE3196-A6FA-4472-A865-E7809A93A2E7@bbn.com> References: <53C19D8F-680F-4D0E-AFBB-C2B865B04CB2@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1278) Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 19:55:54 -0000 We shouldn't publish the document if it doesn't solve a problem. I'm = happy to adapt it so that it does. We can always re-WGLC. --Richard On Jul 11, 2012, at 1:05 PM, Hannes Tschofenig wrote: > That's a good point, Marc.=20 >=20 > The document has good content even though it does not meet the needs = of everyone.=20 >=20 > On Jul 11, 2012, at 7:57 PM, Marc Linsner wrote: >=20 >> Richard, >>=20 >>=20 >>>=20 >>> I'm going to take a first past at LbyR-in-LoST in a rev of rough-loc = in >>> time for the draft deadline, so that we can have a basis for = discussion >>> in Vancouver. >>>=20 >>> Thanks for getting this conversation started, >>> --Richard >>=20 >> Rough-loc is a WG document that's been through wglc. New ideas need = to be >> in a new draft. >>=20 >> -Marc- >>=20 >>=20 >=20 From mlinsner@cisco.com Thu Jul 12 13:05:06 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3263221F854B for ; Thu, 12 Jul 2012 13:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biM0XFvx+dFK for ; Thu, 12 Jul 2012 13:05:05 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4379021F8548 for ; Thu, 12 Jul 2012 13:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1224; q=dns/txt; s=iport; t=1342123539; x=1343333139; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=Jl2lQUTceNdSq6tWQs7K5NX9/33/snBLPvjiuDhjlDI=; b=EdeWZhHgd/ygUYChxToDN33oEV2V53TeyonfuzTnEWrucfvKM8leKzOW 6MeFs9+OBy41PxcG9FwoG6nWp/Bg6ezygfH7yDX3tg9HghhgU/n3ddqhY M4r8UTiuh/7mrdNWaTc8oU3h7kvqzjzag5AFq5ipd976f0ZkWW0P3VV37 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAwt/0+tJV2Y/2dsb2JhbABFuBaBB4IgAQEBBBIBJwIBPAwHCBEDAQIBfQgGDgUih1wDDJ10oByKWmaFfAOVOoVWiEqBZoJ7 X-IronPort-AV: E=Sophos;i="4.77,575,1336348800"; d="scan'208";a="98361108" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 12 Jul 2012 20:05:39 +0000 Received: from [10.116.195.114] (rtp-mlinsner-8711.cisco.com [10.116.195.114]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6CK5WNf004767; Thu, 12 Jul 2012 20:05:34 GMT User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 12 Jul 2012 16:05:30 -0400 From: Marc Linsner To: "Richard L. Barnes" Message-ID: Thread-Topic: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 In-Reply-To: <18E3CF29-296D-4942-B254-1745978CA84D@bbn.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 20:05:07 -0000 I would rather the WG agree to add/erase text from the document. Post the proposed text to the list for discussion vs. changing the document. -Marc- -----Original Message----- From: "Richard L. Barnes" Date: Thu, 12 Jul 2012 15:54:56 -0400 To: Marc Linsner Cc: Hannes Tschofenig , "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 >On Jul 11, 2012, at 12:57 PM, Marc Linsner wrote: > >> Richard, >> >> >>> >>> I'm going to take a first past at LbyR-in-LoST in a rev of rough-loc in >>> time for the draft deadline, so that we can have a basis for discussion >>> in Vancouver. >>> >>> Thanks for getting this conversation started, >>> --Richard >> >> Rough-loc is a WG document that's been through wglc. New ideas need to >>be >> in a new draft. >> >> -Marc- > > >I'm not sure I agree. Doesn't the current conversation demonstrate that >rough-loc doesn't solve the problem it was intended to solve? I was >taking this thread as very late WGLC comments -- or early IETF LC >comments :) > >If you still want me to hold off, let me know and I will. > >--Richard From iesg-secretary@ietf.org Thu Jul 12 15:53:40 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2959E21F859A; Thu, 12 Jul 2012 15:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZAMPlpEZGhP; Thu, 12 Jul 2012 15:53:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF3821F859E; Thu, 12 Jul 2012 15:53:39 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120712225339.23992.9832.idtracker@ietfa.amsl.com> Date: Thu, 12 Jul 2012 15:53:39 -0700 Cc: ecrit chair , ecrit mailing list , RFC Editor Subject: [Ecrit] Document Action: 'Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements' to Experimental RFC (draft-ietf-ecrit-lost-sync-18.txt) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 22:53:40 -0000 The IESG has approved the following document: - 'Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements' (draft-ietf-ecrit-lost-sync-18.txt) as Experimental RFC This document is the product of the Emergency Context Resolution with Internet Technologies Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-sync/ Technical Summary The Location-to-Service Translation (LoST) protocol (RFC5222) is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The main data structure, the element, used for encapsulating information about service boundaries is defined in the LoST protocol specification and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative elements between two entities. Exchanging cached elements, i.e. non-authoritative elements, is possible but not envisioned. In any case, this document can also be used without the LoST protocol even though the format of the element is re-used from the LoST specification. Working Group Summary There is consensus in the WG to publish this document. Document Quality The LoST Sync protocol was implemented during the development of RFC 5222 specification. This extension has been tested in various company-internal implementations, as reported to the wg chairs. Two open source implementations were made available by Columbia University and by Goettingen University. Interoperability tests between them have been made. The code produced by Goettingen University is available (at the time of this announcement) at: http://sourceforge.net/projects/heldandlost/files/ The LoST specification has experienced extensive review, including reviews by other SDOs. From hannes.tschofenig@gmx.net Fri Jul 13 00:48:12 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9291421F8504 for ; Fri, 13 Jul 2012 00:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ct222OVDPVp for ; Fri, 13 Jul 2012 00:48:11 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 505E421F8503 for ; Fri, 13 Jul 2012 00:48:11 -0700 (PDT) Received: (qmail invoked by alias); 13 Jul 2012 07:48:46 -0000 Received: from unknown (EHLO [10.255.128.232]) [194.251.119.201] by mail.gmx.net (mp019) with SMTP; 13 Jul 2012 09:48:46 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18lfAR+1UYlDALzZd6qP/5xThDaFHBdOfUAtpUwko 2CKRBB6DuLAcha Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4BEE3196-A6FA-4472-A865-E7809A93A2E7@bbn.com> Date: Fri, 13 Jul 2012 10:48:44 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4197EDF1-F16A-4B81-A6B9-A2B27890DC96@gmx.net> References: <53C19D8F-680F-4D0E-AFBB-C2B865B04CB2@gmx.net> <4BEE3196-A6FA-4472-A865-E7809A93A2E7@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 07:48:12 -0000 Rough location does not solve the routing issues of certain countries = but that does not mean it does not offer a solution for many others.=20 The challenge is that countries have PSAP deployments that differ quite = a bit and they are even changing over time. The best solution for = addressing the location based routing depends a bit on the deployment = they have.=20 Here are two examples. I doubt that UK or Sweden need the solution we = have described in draft-winterbottom-ecrit-priv-loc. In the UK there are = stage 1 PSAPs with replicated routing information and you can send it to = any one of them to get the call routed correctly to the stage 2 PSAP. = So, if you know that you are in the UK you are already good to go.=20 In Sweden there is no separation between stage 1 and stage 2 PSAPs. = Nevertheless, they have a couple of PSAPs that are interconnected. = Reaching any one of them is sufficient. So, you only need to know that = you are in Sweden. Finally, I believe that many countries will in their transition story = have to rely on an ESRP (like some of the countries plan to do for = eCall).=20 Ciao Hannes On Jul 12, 2012, at 10:56 PM, Richard L. Barnes wrote: > We shouldn't publish the document if it doesn't solve a problem. I'm = happy to adapt it so that it does. We can always re-WGLC. >=20 > --Richard >=20 >=20 >=20 > On Jul 11, 2012, at 1:05 PM, Hannes Tschofenig wrote: >=20 >> That's a good point, Marc.=20 >>=20 >> The document has good content even though it does not meet the needs = of everyone.=20 >>=20 >> On Jul 11, 2012, at 7:57 PM, Marc Linsner wrote: >>=20 >>> Richard, >>>=20 >>>=20 >>>>=20 >>>> I'm going to take a first past at LbyR-in-LoST in a rev of = rough-loc in >>>> time for the draft deadline, so that we can have a basis for = discussion >>>> in Vancouver. >>>>=20 >>>> Thanks for getting this conversation started, >>>> --Richard >>>=20 >>> Rough-loc is a WG document that's been through wglc. New ideas need = to be >>> in a new draft. >>>=20 >>> -Marc- >>>=20 >>>=20 >>=20 >=20 From laura.liess.dt@googlemail.com Fri Jul 13 03:30:53 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBB321F86CF for ; Fri, 13 Jul 2012 03:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, SARE_TOWRITE=1.05] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kt5bXtKFuq+A for ; Fri, 13 Jul 2012 03:30:52 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D63F221F8552 for ; Fri, 13 Jul 2012 03:30:51 -0700 (PDT) Received: by yenq13 with SMTP id q13so3701971yen.31 for ; Fri, 13 Jul 2012 03:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NRcMkQET9HJnan5LNvYMMhhCRwggDXoJgX6LETqidgI=; b=eKtlkMQBcTBkiJFCxL07HZlKNm57VsiT6AHNv69gu5ANraiPCn+8vb1Ez0gPVUveLY dzh+UVOkZRrKtluqRq1wjLMu/lGZOY9rDxvrrduHlkwzaTSs1QnCbDaft8RCWOyELcsx fgjpSpyKM0qMjFnFrXk12Wbomgs/aqQ8lgn8n9qggR4RKVWblwuVBnNtFGiPH2V1+9/N bThNrUgnH+uCC1XTjs/FRI+iHTamKlWXbnct3/67zfJGn1irVFEaatrIA+QQ0+H46JaO XU2ZPfVzq/w54mDR7klhTc82W9hdrhaE9BmisTK2xIrt1VkqK5KLdyMf4N8AlJLDDaYA 7yBw== MIME-Version: 1.0 Received: by 10.50.171.40 with SMTP id ar8mr477556igc.14.1342175486792; Fri, 13 Jul 2012 03:31:26 -0700 (PDT) Received: by 10.231.200.37 with HTTP; Fri, 13 Jul 2012 03:31:26 -0700 (PDT) In-Reply-To: <999913AB42CC9341B05A99BBF358718D01A4937A@FIESEXC035.nsn-intra.net> References: <22A077A4-9E8B-44B6-A0B6-C18FB67BBC20@gmx.net> <94D082C9-E6CC-4F3F-838B-A9F7F588DA60@bbn.com> <14997FA0-9C35-46A9-97AD-0635488A2E99@brianrosen.net> <999913AB42CC9341B05A99BBF358718D01A4937A@FIESEXC035.nsn-intra.net> Date: Fri, 13 Jul 2012 12:31:26 +0200 Message-ID: From: Laura Liess To: "Tschofenig, Hannes (NSN - FI/Espoo)" , james.winterbottom@comscope.com Content-Type: text/plain; charset=ISO-8859-1 Cc: A.Seus@telekom.de, ecrit@ietf.org Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 10:30:53 -0000 Hannes, James, Thank you for submitting this draft. The architecture and interfaces described in the draft is in principle what we intend to implement in Germany. (I think most countries which do not have dedicated emergency calling telecomunication infrastructure will do that.) For Germany, a very similar architecture has already been agreed between DT and the German regulator (BNetzA). DT already submitted this architecture to ETSI as a solution proposal for the European Commission (EC) mandate 493. The only difference between the architecture proposed in the draft and the architecture already proposed by DT in ETSI is that the second does currently not contain the LIS interface to LOST, the LIS was supposed to get the EcrfURI using an internal proprietary interface. I think the LIS interface to LOST shown in Figure 5 is a very good idea. It makes the architecture more general and more flexible. I think if the draft is agreed in ECRIT without significant architecture changes, it would make sense that ETSI adopts the architecture described in the draft. Kind regards Laura 2012/7/10 Tschofenig, Hannes (NSN - FI/Espoo) : > Brian, Richard, > > > the discovery of the LIS or LoST server isn't the important part of the > document. This is just the stuff we had developed in ECRIT/GEOPRIV. > Nothing new there. > So, don't get distracted. > > The core story is that the LoST lookup is triggered by the lookup for > location to the HELD server. Since the location server is local it can > initiate a regular LoST lookup and channel the response back to the end > device. > > Ciao > Hannes > > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of ext Brian Rosen >> Sent: Tuesday, July 10, 2012 8:36 PM >> To: Richard L. Barnes >> Cc: ecrit@ietf.org Org >> Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 >> >> Tell me more about why DNS for LIS discovery is fragile - not that I >> particularly like it. >> >> There was good reason that LoST didn't allow LbyR -- it makes the > whole >> transaction more fragile. Local LoST server discovery is the same > issue >> as DNS reverse lookup - the ISP has to do it right. Hard to see how > you >> win with LbyR. >> >> Brian >> >> On Jul 10, 2012, at 12:31 PM, Richard L. Barnes wrote: >> >> > Hey Hannes, James, >> > >> > I agree that -rough-loc seems not to be meeting some stakeholders' >> needs. It does like we need a little more protocol revision. >> > >> > I think that this document goes about it in the wrong way. Using > the >> DNS for LIS discovery is fragile, as we've discussed often in the > past. >> And from the perspective of client implementation, this document >> completely screws up the normal location->LoST->call flow. >> > >> > It would be better to allow location by reference in LoST queries. >> The major challenge in that regard was that the LoST server might not > be >> able to dereference the URI, but that can be mitigated with local LoST >> server discovery, which -phonebcp requires to be preferred over >> configured LoST servers. >> > >> > I'm going to take a first past at LbyR-in-LoST in a rev of rough-loc >> in time for the draft deadline, so that we can have a basis for >> discussion in Vancouver. >> > >> > Thanks for getting this conversation started, >> > --Richard >> > >> > >> > >> > >> > >> > On Jul 10, 2012, at 12:09 PM, Hannes Tschofenig wrote: >> > >> >> Hi all, >> >> >> >> years ago the ECRIT working group discussed the topic of 'location >> hiding' and this lead to the publication of RFC 6444 >> (http://datatracker.ietf.org/doc/rfc6444/). Consequently, a solution > was >> developed (and is still work in progress) called "Rough Location", see >> http://tools.ietf.org/id/draft-ietf-ecrit-rough-loc. >> >> >> >> It looked like we solved that problem. Right? >> >> >> >> You may think. Early 2011, about 4 years after the first location >> hiding draft was published, the European Commission (EC) comes along > and >> published mandate 493. Without going into the details of the mandate > the >> European Commission had the impression that there are no > specifications >> available. >> >> >> >> The Internet Architecture Board (IAB) provided a response to that >> mandate, which you can find here: >> http://www.iab.org/documents/correspondence-reports-documents/2011- >> 2/letter-to-the-european-commission-on-global-interoperability-in- >> emergency-services/. >> >> >> >> Unfortunately, the IAB interaction with the EC did not lead to the >> desired outcome, i.e., to look at our documents carefully enough and > to >> realize that we have a solution already. >> >> >> >> In any case, a new standards group in ETSI was created to work on >> this topic: the M493 group. This group is supposed to develop an >> emergency services architecture in fulfillment of the location hiding >> requirement (the mandate phrases it differently, of course but the >> requirements that are discussed flow in that direction). >> >> >> >> To provide feedback into that process James Winterbottom and myself >> had decided to write an Internet draft for an architecture that we >> believe could meet their requirements and, at the same time, re-uses >> some of our earlier standardization work. >> >> >> >> You can find the document here: >> >> http://tools.ietf.org/html/draft-winterbottom-ecrit-priv-loc-00 >> >> >> >> Feedback is welcome. >> >> >> >> Ciao >> >> Hannes >> >> >> >> PS: Marc, can we get an agenda slot to discuss this topic? >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From laura.liess.dt@googlemail.com Fri Jul 13 06:44:23 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4725421F8742 for ; Fri, 13 Jul 2012 06:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+YmkJEi7tzn for ; Fri, 13 Jul 2012 06:44:22 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 62CBA21F8732 for ; Fri, 13 Jul 2012 06:44:22 -0700 (PDT) Received: by yhq56 with SMTP id 56so4069396yhq.31 for ; Fri, 13 Jul 2012 06:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uVYK/+BBPZq1X2LUf44ZHRufnqxJG7MtP0maGt73Hjw=; b=NQnIJR6NJONT7JNnfnBergqLYJ0OlHVz6Moy9mO42johc+vYr6RENiYEtKpw4gtzLI Jj6lpPifecElXfr3LPIxBleTI8AhkbijZuxqvTUb1uP/94DXEIqtJba8z3lOQvI2ofPa 0zrNR6UQa+/GctD+irl1ERenH+FNJ3kHi+6uJYuDIH9Ta2fJC5hyl2AIM7xxdFt6jk6H VVtMklg82FcuIkfargwXXbQByQJSiwRG2p07T8zE326/BVzumsdwo/yi0W/F5svm42xH +us4u3N+4Wh59IPGUWE4s2ZEno03gSdB1zmkqQmtefuIsu3/y2ZNnJPBcXqVgdP3R9dk bpKw== MIME-Version: 1.0 Received: by 10.50.190.163 with SMTP id gr3mr1024972igc.22.1342187097905; Fri, 13 Jul 2012 06:44:57 -0700 (PDT) Received: by 10.231.200.37 with HTTP; Fri, 13 Jul 2012 06:44:57 -0700 (PDT) In-Reply-To: <18E3CF29-296D-4942-B254-1745978CA84D@bbn.com> References: <18E3CF29-296D-4942-B254-1745978CA84D@bbn.com> Date: Fri, 13 Jul 2012 15:44:57 +0200 Message-ID: From: Laura Liess To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Cc: A.Seus@telekom.de, "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 13:44:23 -0000 Richard, My understanding is that rough location and the LOST query from the LIS are two different alternatives for two different use cases and both are useful. Please let me know if I am wrong. Rough location is a good choice in countries with dedicated emergency calling telecommunication infrastructure (and budget dedicated to develop this infrastructure) as ESInet. ESRPs and the LOST-tree are developped by organizations responsible for this infrastructure. A VSP queries the LIS with the IP-address and gets the rough location and the LbyR, then makes a LOST query with the rough location and gets the ESRP/PSAP. The ESRP/PSAP queries the LIS with the LbyR and gets the LbyV. The ISP will trust any ESRP/PSAP because they are parts of the emergency service infrastructure. The ISP do not care about LOST. In Germany, without dedicated emergency calling telecommunication infrastructure, ESRPs will be provided by some (large) national carriers. Because they are not paid for this in any way, they are not willing to provide LOST trees accessible from the Internet or ESRPs which have to query the LISs for every possible ISP. On the other side, small ISPs will not want to have trust relationships with more than one ESRP provider, in general they have an SLA with some large carrier for IP-access anyway. So it is important that the ESRP URI in the LOST response is ISP-specific. ISPs which are DT customers will get a different LOST response than the Vodafone customers for the same location in the query. In Germany, I could imagine that a so-called carrier LOST will be developped on the long term. At the beginning ISPs will configure one ESRP URI and that's it. There is no chance for the development of an open LOST infrastructure accessible from the Internet because there is nobody there to pay for it. In the current aggreement with the regulator, there is no LOST at all, the LIS is responsible for returning an ESRP URI which is able to query the location. Kind regards Laura 2012/7/12 Richard L. Barnes : > On Jul 11, 2012, at 12:57 PM, Marc Linsner wrote: > >> Richard, >> >> >>> >>> I'm going to take a first past at LbyR-in-LoST in a rev of rough-loc in >>> time for the draft deadline, so that we can have a basis for discussion >>> in Vancouver. >>> >>> Thanks for getting this conversation started, >>> --Richard >> >> Rough-loc is a WG document that's been through wglc. New ideas need to be >> in a new draft. >> >> -Marc- > > > I'm not sure I agree. Doesn't the current conversation demonstrate that rough-loc doesn't solve the problem it was intended to solve? I was taking this thread as very late WGLC comments -- or early IETF LC comments :) > > If you still want me to hold off, let me know and I will. > > --Richard > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Fri Jul 13 09:32:10 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE5111E80B5 for ; Fri, 13 Jul 2012 09:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.57 X-Spam-Level: X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaVCzFSCnyDg for ; Fri, 13 Jul 2012 09:32:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9B19111E8073 for ; Fri, 13 Jul 2012 09:32:09 -0700 (PDT) Received: from [128.89.253.210] (port=59217) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SpinB-000DW2-6r; Fri, 13 Jul 2012 12:32:33 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: "Richard L. Barnes" In-Reply-To: Date: Fri, 13 Jul 2012 12:32:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <18E3CF29-296D-4942-B254-1745978CA84D@bbn.com> To: Laura Liess X-Mailer: Apple Mail (2.1278) Cc: A.Seus@telekom.de, "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 16:32:10 -0000 Hi Laura, Thank you for this clarification. It is very useful in helping to = understand the problem. I love your phrase "carrier LoST". That seems to me to be the best = solution here. It is cheap to deploy (a very simple CGI script), and = meets two important goals: (1) Allowing ISPs to specify particular ESRPs, and (2) Not requiring significant modifications to the end client interface. This solution doesn't actually require any modification to ECRIT at all. = Clients are already required to support LoST discovery, so the carrier = LoST server can send them to whatever ESRP the carrier desires. =20 There's still a need for the LIS to provide *something*, though, so that = clients don't say "I don't have any location, so I can't do LoST". But = DT's LIS, for example, could just return either a URI or = DE, which doesn't seem like it would cost them = anything. So I'm a little puzzled as to why we're talking about protocol changes. --Richard On Jul 13, 2012, at 9:44 AM, Laura Liess wrote: > Richard, >=20 > My understanding is that rough location and the LOST query from the > LIS are two different alternatives for two different use cases and > both are useful. Please let me know if I am wrong. >=20 > Rough location is a good choice in countries with dedicated emergency > calling telecommunication infrastructure (and budget dedicated to > develop this infrastructure) as ESInet. ESRPs and the LOST-tree are > developped by organizations responsible for this infrastructure. A VSP > queries the LIS with the IP-address and gets the rough location and > the LbyR, then makes a LOST query with the rough location and gets the > ESRP/PSAP. The ESRP/PSAP queries the LIS with the LbyR and gets the > LbyV. The ISP will trust any ESRP/PSAP because they are parts of the > emergency service infrastructure. The ISP do not care about LOST. >=20 > In Germany, without dedicated emergency calling telecommunication > infrastructure, ESRPs will be provided by some (large) national > carriers. Because they are not paid for this in any way, they are not > willing to provide LOST trees accessible from the Internet or ESRPs > which have to query the LISs for every possible ISP. On the other > side, small ISPs will not want to have trust relationships with more > than one ESRP provider, in general they have an SLA with some large > carrier for IP-access anyway. So it is important that the ESRP URI in > the LOST response is ISP-specific. ISPs which are DT customers will > get a different LOST response than the Vodafone customers for the same > location in the query. > In Germany, I could imagine that a so-called carrier LOST will be > developped on the long term. At the beginning ISPs will configure one > ESRP URI and that's it. There is no chance for the development of an > open LOST infrastructure accessible from the Internet because there is > nobody there to pay for it. In the current aggreement with the > regulator, there is no LOST at all, the LIS is responsible for > returning an ESRP URI which is able to query the location. >=20 > Kind regards > Laura >=20 >=20 >=20 >=20 > 2012/7/12 Richard L. Barnes : >> On Jul 11, 2012, at 12:57 PM, Marc Linsner wrote: >>=20 >>> Richard, >>>=20 >>>=20 >>>>=20 >>>> I'm going to take a first past at LbyR-in-LoST in a rev of = rough-loc in >>>> time for the draft deadline, so that we can have a basis for = discussion >>>> in Vancouver. >>>>=20 >>>> Thanks for getting this conversation started, >>>> --Richard >>>=20 >>> Rough-loc is a WG document that's been through wglc. New ideas need = to be >>> in a new draft. >>>=20 >>> -Marc- >>=20 >>=20 >> I'm not sure I agree. Doesn't the current conversation demonstrate = that rough-loc doesn't solve the problem it was intended to solve? I = was taking this thread as very late WGLC comments -- or early IETF LC = comments :) >>=20 >> If you still want me to hold off, let me know and I will. >>=20 >> --Richard >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit From laura.liess.dt@googlemail.com Mon Jul 16 05:23:30 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D58121F86EA for ; Mon, 16 Jul 2012 05:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.904 X-Spam-Level: X-Spam-Status: No, score=-2.904 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+SqBVf3ju12 for ; Mon, 16 Jul 2012 05:23:29 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id BE59D21F8705 for ; Mon, 16 Jul 2012 05:23:28 -0700 (PDT) Received: by yhq56 with SMTP id 56so5559892yhq.31 for ; Mon, 16 Jul 2012 05:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bX9xiMKH6kZpDmsEa5UQ+6g6J4kAlT4/iUWKQ1i0wzs=; b=EJesBjU5vvv/KhRm8xwhqdIgDix92OHLG2uHhT7ziqO/5OpwyLGwkoytTvw08e1Con LjZL0eQRuYsq2W+BSHkX6iXYIH3W7qbDr2vaw66ig9+rzKUNgUWXA9+/O+roQKesyCNY nkiPjm7GfsUMT0+yMsgfD1hRApDGgt7oldeaEFMDDE4hvXnYmLG+/5IL6ybN7wmHkeKt zuVABvDXPViaKtOJ1+gonl+AhuWXNd3+DvUyUahpuqUU//Uv5pbE+p2HczeYg1G4mW/p ubZ1lIkkEo28qvLlV/yRK/kpgLgHzob6Qm/LloIPY7VqNQRXcNmI9lTI/cjuIbXh1qn+ vg9A== MIME-Version: 1.0 Received: by 10.50.222.162 with SMTP id qn2mr5033421igc.46.1342441452670; Mon, 16 Jul 2012 05:24:12 -0700 (PDT) Received: by 10.231.200.37 with HTTP; Mon, 16 Jul 2012 05:24:12 -0700 (PDT) In-Reply-To: References: <18E3CF29-296D-4942-B254-1745978CA84D@bbn.com> Date: Mon, 16 Jul 2012 14:24:12 +0200 Message-ID: From: Laura Liess To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: A.Seus@telekom.de, "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 12:23:30 -0000 Hi Richard, please see inline. > > Thank you for this clarification. It is very useful in helping to unders= tand the problem. [LL] There are two possible solutios described in Section 6. My comments are restricted to the second approach because this is the model we follow in Germany. Maybe there are countries where the first approach is prefered. > > I love your phrase "carrier LoST". That seems to me to be the best solut= ion here. It is cheap to deploy (a very simple CGI script), > and meets two important goals: > (1) Allowing ISPs to specify particular ESRPs, and > (2) Not requiring significant modifications to the end client interface. [LL] Another aspect the German regulator brought up is he wants keep the dependencies on functionalities which are outside his country/jurisdiction as low as possible. > > This solution doesn't actually require any modification to ECRIT at all. = Clients are already required to support LoST discovery, so the carrier LoS= T server can send them to whatever ESRP the carrier desires. > > There's still a need for the LIS to provide *something*, though, so that = clients don't say "I don't have any location, so I can't do LoST". But DT'= s LIS, for example, could just return either a URI or DE= , which doesn't seem like it would cost them anything. > > So I'm a little puzzled as to why we're talking about protocol changes. [LL] We need an extenssion to HELD, which enable us to return the ESRP URI. Returning DE would mean, if I understood correctly your intention, that the VSP queries the DT LOST with DE. DT has no intention to allow access to the "carrier LOST" from the Internet. At least at the beginning, the "carrier LOST" will be just the existing functionality doing the mapping between the location and the ESRP, accessed from the LIS via already existing proprietary interface. There is no new LOST implementation planed. I can imagine this existing functionality evolving in time towards a real LOST when the emergency calling scenarios become more general. E.g. for emergency calling from a distributed enterprise ( e.g. the local offices of a a bank) it makes sense that the enterprise does not have its own LOST but the enterprise LIS queries the DT LOST via the standardized LOST protocol, but still the access to LOST will be restricted to DT customers. Thanks a lot Laura > > --Richard > > > > > On Jul 13, 2012, at 9:44 AM, Laura Liess wrote: > >> Richard, >> >> My understanding is that rough location and the LOST query from the >> LIS are two different alternatives for two different use cases and >> both are useful. Please let me know if I am wrong. >> >> Rough location is a good choice in countries with dedicated emergency >> calling telecommunication infrastructure (and budget dedicated to >> develop this infrastructure) as ESInet. ESRPs and the LOST-tree are >> developped by organizations responsible for this infrastructure. A VSP >> queries the LIS with the IP-address and gets the rough location and >> the LbyR, then makes a LOST query with the rough location and gets the >> ESRP/PSAP. The ESRP/PSAP queries the LIS with the LbyR and gets the >> LbyV. The ISP will trust any ESRP/PSAP because they are parts of the >> emergency service infrastructure. The ISP do not care about LOST. >> >> In Germany, without dedicated emergency calling telecommunication >> infrastructure, ESRPs will be provided by some (large) national >> carriers. Because they are not paid for this in any way, they are not >> willing to provide LOST trees accessible from the Internet or ESRPs >> which have to query the LISs for every possible ISP. On the other >> side, small ISPs will not want to have trust relationships with more >> than one ESRP provider, in general they have an SLA with some large >> carrier for IP-access anyway. So it is important that the ESRP URI in >> the LOST response is ISP-specific. ISPs which are DT customers will >> get a different LOST response than the Vodafone customers for the same >> location in the query. >> In Germany, I could imagine that a so-called carrier LOST will be >> developped on the long term. At the beginning ISPs will configure one >> ESRP URI and that's it. There is no chance for the development of an >> open LOST infrastructure accessible from the Internet because there is >> nobody there to pay for it. In the current aggreement with the >> regulator, there is no LOST at all, the LIS is responsible for >> returning an ESRP URI which is able to query the location. >> >> Kind regards >> Laura >> >> >> >> >> 2012/7/12 Richard L. Barnes : >>> On Jul 11, 2012, at 12:57 PM, Marc Linsner wrote: >>> >>>> Richard, >>>> >>>> >>>>> >>>>> I'm going to take a first past at LbyR-in-LoST in a rev of rough-loc = in >>>>> time for the draft deadline, so that we can have a basis for discussi= on >>>>> in Vancouver. >>>>> >>>>> Thanks for getting this conversation started, >>>>> --Richard >>>> >>>> Rough-loc is a WG document that's been through wglc. New ideas need t= o be >>>> in a new draft. >>>> >>>> -Marc- >>> >>> >>> I'm not sure I agree. Doesn't the current conversation demonstrate tha= t rough-loc doesn't solve the problem it was intended to solve? I was taki= ng this thread as very late WGLC comments -- or early IETF LC comments :) >>> >>> If you still want me to hold off, let me know and I will. >>> >>> --Richard >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit > From br@brianrosen.net Mon Jul 16 06:20:17 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A0B21F8731 for ; Mon, 16 Jul 2012 06:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.789 X-Spam-Level: X-Spam-Status: No, score=-103.789 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-c00nJ4XCwy for ; Mon, 16 Jul 2012 06:20:15 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id 4813021F8732 for ; Mon, 16 Jul 2012 06:20:15 -0700 (PDT) X-ASG-Debug-ID: 1342444859-04d035105bf1440001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id hfFX1WDizSOWy1mA; Mon, 16 Jul 2012 06:20:59 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233]:20938 helo=[192.168.133.247]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SqlEQ-003uXn-8z; Mon, 16 Jul 2012 06:20:58 -0700 Mime-Version: 1.0 (Apple Message framework v1278) X-ASG-Orig-Subj: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: Date: Mon, 16 Jul 2012 09:20:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9C0749C2-33E7-4E59-95F7-5D421E014D05@brianrosen.net> References: <18E3CF29-296D-4942-B254-1745978CA84D@bbn.com> To: Laura Liess X-Mailer: Apple Mail (2.1278) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1342444859 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.102866 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: A.Seus@telekom.de, "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 13:20:17 -0000 You could easily restrict your carrier LoST server to only serve DT = customers. Wouldn't that work? You are asking for a change that would affect every endpoint (they would = have to understand the ESRP return from a HELD query). If there is a = less drastic way of handling the problem, given that you admit you may = evolve to something closer to the current model, would that be = acceptable? Your LoST return could even be nonsense, as long as the carrier LoST = server recognized the nonsense. I wouldn't recommend it, but it would = work. Brian On Jul 16, 2012, at 8:24 AM, Laura Liess wrote: > Hi Richard, >=20 > please see inline. >=20 >>=20 >> Thank you for this clarification. It is very useful in helping to = understand the problem. >=20 > [LL] There are two possible solutios described in Section 6. My > comments are restricted to the second approach because this is the > model we follow in Germany. Maybe there are countries where the first > approach is prefered. >>=20 >> I love your phrase "carrier LoST". That seems to me to be the best = solution here. It is cheap to deploy (a very simple CGI script), >> and meets two important goals: >> (1) Allowing ISPs to specify particular ESRPs, and >> (2) Not requiring significant modifications to the end client = interface. >=20 > [LL] Another aspect the German regulator brought up is he wants keep > the dependencies on functionalities which are outside his > country/jurisdiction as low as possible. >>=20 >> This solution doesn't actually require any modification to ECRIT at = all. Clients are already required to support LoST discovery, so the = carrier LoST server can send them to whatever ESRP the carrier desires. >>=20 >> There's still a need for the LIS to provide *something*, though, so = that clients don't say "I don't have any location, so I can't do LoST". = But DT's LIS, for example, could just return either a URI or = DE, which doesn't seem like it would cost them = anything. >>=20 >> So I'm a little puzzled as to why we're talking about protocol = changes. >=20 > [LL] We need an extenssion to HELD, which enable us to return the ESRP = URI. > Returning DE would mean, if I understood correctly > your intention, that the VSP queries the DT LOST with > DE. DT has no intention to allow access to the > "carrier LOST" from the Internet. At least at the beginning, the > "carrier LOST" will be just the existing functionality doing the > mapping between the location and the ESRP, accessed from the LIS via > already existing proprietary interface. There is no new LOST > implementation planed. I can imagine this existing functionality > evolving in time towards a real LOST when the emergency calling > scenarios become more general. E.g. for emergency calling from a > distributed enterprise ( e.g. the local offices of a a bank) it makes > sense that the enterprise does not have its own LOST but the > enterprise LIS queries the DT LOST via the standardized LOST protocol, > but still the access to LOST will be restricted to DT customers. >=20 > Thanks a lot > Laura >=20 >>=20 >> --Richard >>=20 >>=20 >>=20 >>=20 >> On Jul 13, 2012, at 9:44 AM, Laura Liess wrote: >>=20 >>> Richard, >>>=20 >>> My understanding is that rough location and the LOST query from the >>> LIS are two different alternatives for two different use cases and >>> both are useful. Please let me know if I am wrong. >>>=20 >>> Rough location is a good choice in countries with dedicated = emergency >>> calling telecommunication infrastructure (and budget dedicated to >>> develop this infrastructure) as ESInet. ESRPs and the LOST-tree are >>> developped by organizations responsible for this infrastructure. A = VSP >>> queries the LIS with the IP-address and gets the rough location and >>> the LbyR, then makes a LOST query with the rough location and gets = the >>> ESRP/PSAP. The ESRP/PSAP queries the LIS with the LbyR and gets the >>> LbyV. The ISP will trust any ESRP/PSAP because they are parts of the >>> emergency service infrastructure. The ISP do not care about LOST. >>>=20 >>> In Germany, without dedicated emergency calling telecommunication >>> infrastructure, ESRPs will be provided by some (large) national >>> carriers. Because they are not paid for this in any way, they are = not >>> willing to provide LOST trees accessible from the Internet or ESRPs >>> which have to query the LISs for every possible ISP. On the other >>> side, small ISPs will not want to have trust relationships with more >>> than one ESRP provider, in general they have an SLA with some large >>> carrier for IP-access anyway. So it is important that the ESRP URI = in >>> the LOST response is ISP-specific. ISPs which are DT customers will >>> get a different LOST response than the Vodafone customers for the = same >>> location in the query. >>> In Germany, I could imagine that a so-called carrier LOST will be >>> developped on the long term. At the beginning ISPs will configure = one >>> ESRP URI and that's it. There is no chance for the development of an >>> open LOST infrastructure accessible from the Internet because there = is >>> nobody there to pay for it. In the current aggreement with the >>> regulator, there is no LOST at all, the LIS is responsible for >>> returning an ESRP URI which is able to query the location. >>>=20 >>> Kind regards >>> Laura >>>=20 >>>=20 >>>=20 >>>=20 >>> 2012/7/12 Richard L. Barnes : >>>> On Jul 11, 2012, at 12:57 PM, Marc Linsner wrote: >>>>=20 >>>>> Richard, >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> I'm going to take a first past at LbyR-in-LoST in a rev of = rough-loc in >>>>>> time for the draft deadline, so that we can have a basis for = discussion >>>>>> in Vancouver. >>>>>>=20 >>>>>> Thanks for getting this conversation started, >>>>>> --Richard >>>>>=20 >>>>> Rough-loc is a WG document that's been through wglc. New ideas = need to be >>>>> in a new draft. >>>>>=20 >>>>> -Marc- >>>>=20 >>>>=20 >>>> I'm not sure I agree. Doesn't the current conversation demonstrate = that rough-loc doesn't solve the problem it was intended to solve? I = was taking this thread as very late WGLC comments -- or early IETF LC = comments :) >>>>=20 >>>> If you still want me to hold off, let me know and I will. >>>>=20 >>>> --Richard >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From internet-drafts@ietf.org Mon Jul 16 13:36:07 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F00F11E8260; Mon, 16 Jul 2012 13:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGGZ57n6qh-g; Mon, 16 Jul 2012 13:36:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F9E11E8160; Mon, 16 Jul 2012 13:36:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716203606.19700.92204.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 13:36:06 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-rough-loc-05.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 20:36:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Using Imprecise Location for Emergency Context Resolution Author(s) : Richard Barnes Matt Lepinski Filename : draft-ietf-ecrit-rough-loc-05.txt Pages : 19 Date : 2012-07-16 Abstract: Emergency calling works best when precise location is available for emergency call routing. However, there are situations in which a location provider is unable or unwilling to provide precise location, yet still wishes to enable subscribers to make emergency calls. This document describes the level of location accuracy that providers must provide to enable emergency call routing. In addition, we describe additional rules for networks and endpoints to enable emergency calling by endpoints that do not have access to precise location. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-rough-loc There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-rough-loc-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-rough-loc-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rbarnes@bbn.com Mon Jul 16 13:41:26 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C94311E8269 for ; Mon, 16 Jul 2012 13:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.596 X-Spam-Level: X-Spam-Status: No, score=-106.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zW-BOvCgXH8 for ; Mon, 16 Jul 2012 13:41:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5119311E8160 for ; Mon, 16 Jul 2012 13:41:25 -0700 (PDT) Received: from ros-dhcp192-1-51-20.bbn.com ([192.1.51.20]:51690) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sqs7H-0006s3-Ge for ecrit@ietf.org; Mon, 16 Jul 2012 16:42:03 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: "Richard L. Barnes" In-Reply-To: <20120716203606.19700.92204.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 16:42:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <49D51955-61A7-4106-9240-70D9672345CB@bbn.com> References: <20120716203606.19700.92204.idtracker@ietfa.amsl.com> To: "ecrit@ietf.org Org" X-Mailer: Apple Mail (2.1278) Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-rough-loc-05.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 20:41:26 -0000 This version is mostly a maintenance release, updating references, and = things like that. =20 There are a few substantive changes, though none very large or = fundamental: -- Added some additional civic address notes, including mention of = geocoding -- Added some notes on privileged LoST servers (like Laura's "carrier = LoST")=20 -- Consolidated Section 5 into "Additional Requirements for Networks and = Endpoints" -- Expressed additional requirements using phonebcp notation -- Removed section on non-emergency services, since nobody seemed to = care Diff here: I would suggest to the chairs that we discuss this document at IETF 84, = with an eye toward a new WGLC shortly thereafter. (It probably needed a = WGLC anyway!) Thanks, --Richard On Jul 16, 2012, at 4:36 PM, internet-drafts@ietf.org wrote: >=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. >=20 > Title : Using Imprecise Location for Emergency Context = Resolution > Author(s) : Richard Barnes > Matt Lepinski > Filename : draft-ietf-ecrit-rough-loc-05.txt > Pages : 19 > Date : 2012-07-16 >=20 > Abstract: > Emergency calling works best when precise location is available for > emergency call routing. However, there are situations in which a > location provider is unable or unwilling to provide precise = location, > yet still wishes to enable subscribers to make emergency calls. = This > document describes the level of location accuracy that providers = must > provide to enable emergency call routing. In addition, we describe > additional rules for networks and endpoints to enable emergency > calling by endpoints that do not have access to precise location. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-rough-loc >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ecrit-rough-loc-05 >=20 > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-rough-loc-05 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From internet-drafts@ietf.org Mon Jul 16 15:07:59 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDA711E82C2; Mon, 16 Jul 2012 15:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpzwpX4wGRdL; Mon, 16 Jul 2012 15:07:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E8D11E82D5; Mon, 16 Jul 2012 15:07:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716220758.32213.58123.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 15:07:58 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 22:07:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Author(s) : Brian Rosen Hannes Tschofenig Roger Marshall Filename : draft-ietf-ecrit-additional-data-04.txt Pages : 50 Date : 2012-07-16 Abstract: When an emergency call is sent to a Public Safety Answering Point (PSAP), the device that sends it, as well as any service provider in the path of the call, or access network may have information about the call which the PSAP may be able to use. This document describes an XML data structure that contains this kind of information in a standardized form. A Uniform Resource Identifier (URI) that points to the structure can be included in the SIP signaling with the call, or the data may be included in the body of a SIP message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From keith.drage@alcatel-lucent.com Tue Jul 17 04:00:25 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E207821F86C1 for ; Tue, 17 Jul 2012 04:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.715 X-Spam-Level: X-Spam-Status: No, score=-109.715 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUgArJqAPQ8J for ; Tue, 17 Jul 2012 04:00:23 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6302A21F86AA for ; Tue, 17 Jul 2012 04:00:23 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6HB0l51025470 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 17 Jul 2012 13:00:57 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 17 Jul 2012 13:00:55 +0200 From: "DRAGE, Keith (Keith)" To: Laura Liess , "Richard L. Barnes" Date: Tue, 17 Jul 2012 13:00:53 +0200 Thread-Topic: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 Thread-Index: Ac1jTe9zAZpzYG80SkmwHy1f2nsrRwAvSMVA Message-ID: References: <18E3CF29-296D-4942-B254-1745978CA84D@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "A.Seus@telekom.de" , "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 11:00:25 -0000 > [LL] Another aspect the German regulator brought up is he wants keep > the dependencies on functionalities which are outside his > country/jurisdiction as low as possible. This cannot possibly mean non-existent. For example, my understanding is th= at the German regulator is moving (at least in mobile) from a regime were t= here is no requirement to authenticate the calling device to one where ther= e is a need. For a roaming user, that at least involves an out of country t= ransaction. Given that this is to reduce the number of false calls, I assum= e it would apply to other technologies other than mobile. Regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Laura Liess > Sent: 16 July 2012 13:24 > To: Richard L. Barnes > Cc: A.Seus@telekom.de; ecrit@ietf.org Org > Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 >=20 > Hi Richard, >=20 > please see inline. >=20 > > > > Thank you for this clarification. It is very useful in helping to > understand the problem. >=20 > [LL] There are two possible solutios described in Section 6. My > comments are restricted to the second approach because this is the > model we follow in Germany. Maybe there are countries where the first > approach is prefered. > > > > I love your phrase "carrier LoST". That seems to me to be the best > solution here. It is cheap to deploy (a very simple CGI script), > > and meets two important goals: > > (1) Allowing ISPs to specify particular ESRPs, and > > (2) Not requiring significant modifications to the end client interface= . >=20 > [LL] Another aspect the German regulator brought up is he wants keep > the dependencies on functionalities which are outside his > country/jurisdiction as low as possible. > > > > This solution doesn't actually require any modification to ECRIT at all= . > Clients are already required to support LoST discovery, so the carrier > LoST server can send them to whatever ESRP the carrier desires. > > > > There's still a need for the LIS to provide *something*, though, so tha= t > clients don't say "I don't have any location, so I can't do LoST". But > DT's LIS, for example, could just return either a URI or > DE, which doesn't seem like it would cost them anythin= g. > > > > So I'm a little puzzled as to why we're talking about protocol changes. >=20 > [LL] We need an extenssion to HELD, which enable us to return the ESRP UR= I. > Returning DE would mean, if I understood correctly > your intention, that the VSP queries the DT LOST with > DE. DT has no intention to allow access to the > "carrier LOST" from the Internet. At least at the beginning, the > "carrier LOST" will be just the existing functionality doing the > mapping between the location and the ESRP, accessed from the LIS via > already existing proprietary interface. There is no new LOST > implementation planed. I can imagine this existing functionality > evolving in time towards a real LOST when the emergency calling > scenarios become more general. E.g. for emergency calling from a > distributed enterprise ( e.g. the local offices of a a bank) it makes > sense that the enterprise does not have its own LOST but the > enterprise LIS queries the DT LOST via the standardized LOST protocol, > but still the access to LOST will be restricted to DT customers. >=20 > Thanks a lot > Laura >=20 > > > > --Richard > > > > > > > > > > On Jul 13, 2012, at 9:44 AM, Laura Liess wrote: > > > >> Richard, > >> > >> My understanding is that rough location and the LOST query from the > >> LIS are two different alternatives for two different use cases and > >> both are useful. Please let me know if I am wrong. > >> > >> Rough location is a good choice in countries with dedicated emergency > >> calling telecommunication infrastructure (and budget dedicated to > >> develop this infrastructure) as ESInet. ESRPs and the LOST-tree are > >> developped by organizations responsible for this infrastructure. A VSP > >> queries the LIS with the IP-address and gets the rough location and > >> the LbyR, then makes a LOST query with the rough location and gets the > >> ESRP/PSAP. The ESRP/PSAP queries the LIS with the LbyR and gets the > >> LbyV. The ISP will trust any ESRP/PSAP because they are parts of the > >> emergency service infrastructure. The ISP do not care about LOST. > >> > >> In Germany, without dedicated emergency calling telecommunication > >> infrastructure, ESRPs will be provided by some (large) national > >> carriers. Because they are not paid for this in any way, they are not > >> willing to provide LOST trees accessible from the Internet or ESRPs > >> which have to query the LISs for every possible ISP. On the other > >> side, small ISPs will not want to have trust relationships with more > >> than one ESRP provider, in general they have an SLA with some large > >> carrier for IP-access anyway. So it is important that the ESRP URI in > >> the LOST response is ISP-specific. ISPs which are DT customers will > >> get a different LOST response than the Vodafone customers for the same > >> location in the query. > >> In Germany, I could imagine that a so-called carrier LOST will be > >> developped on the long term. At the beginning ISPs will configure one > >> ESRP URI and that's it. There is no chance for the development of an > >> open LOST infrastructure accessible from the Internet because there is > >> nobody there to pay for it. In the current aggreement with the > >> regulator, there is no LOST at all, the LIS is responsible for > >> returning an ESRP URI which is able to query the location. > >> > >> Kind regards > >> Laura > >> > >> > >> > >> > >> 2012/7/12 Richard L. Barnes : > >>> On Jul 11, 2012, at 12:57 PM, Marc Linsner wrote: > >>> > >>>> Richard, > >>>> > >>>> > >>>>> > >>>>> I'm going to take a first past at LbyR-in-LoST in a rev of rough-lo= c > in > >>>>> time for the draft deadline, so that we can have a basis for > discussion > >>>>> in Vancouver. > >>>>> > >>>>> Thanks for getting this conversation started, > >>>>> --Richard > >>>> > >>>> Rough-loc is a WG document that's been through wglc. New ideas need > to be > >>>> in a new draft. > >>>> > >>>> -Marc- > >>> > >>> > >>> I'm not sure I agree. Doesn't the current conversation demonstrate > that rough-loc doesn't solve the problem it was intended to solve? I was > taking this thread as very late WGLC comments -- or early IETF LC > comments :) > >>> > >>> If you still want me to hold off, let me know and I will. > >>> > >>> --Richard > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From laura.liess.dt@googlemail.com Tue Jul 17 07:40:28 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF0321F86F9 for ; Tue, 17 Jul 2012 07:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.913 X-Spam-Level: X-Spam-Status: No, score=-2.913 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyS8qpkyP7ZT for ; Tue, 17 Jul 2012 07:40:26 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id ACEDE21F86EE for ; Tue, 17 Jul 2012 07:40:26 -0700 (PDT) Received: by qcsg15 with SMTP id g15so390391qcs.27 for ; Tue, 17 Jul 2012 07:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=551lJgmWRK9u6xvcpsxfCzQxRufReV99X3jP/F9PWfY=; b=IUEv/UPmVD7E7OI/9PeA4SiS67wND9+XWa2if9ALmg/yjfNDezhDNGZDOf4qKBL3SM ao/Rt8ekpejA92ctkPmodb884n2yjEKUUVCwRWIxFtiKaf4kydK+qbdJQ+Qh3BhPufXY oW2sMEc+NFruOPFa7gudpTIAQOelmASkdbK8C90n+a7bAw4TwY6CZlBqEE/JZbUOGIRx v0eSpz36E1X6vFdNVvCFt7ASZVQaPAuiwdd7MzKdSwPzeiUM5hlSP5TjWXk/lAFYl7tM 5MfOMdo1L0/m02ydJx8nGNajjHV5lc4ka9piK6epYCiGcUhBicHs1gfMsQH/3+/SltBK NodQ== MIME-Version: 1.0 Received: by 10.50.157.136 with SMTP id wm8mr1594252igb.14.1342536073494; Tue, 17 Jul 2012 07:41:13 -0700 (PDT) Received: by 10.231.200.37 with HTTP; Tue, 17 Jul 2012 07:41:13 -0700 (PDT) In-Reply-To: <9C0749C2-33E7-4E59-95F7-5D421E014D05@brianrosen.net> References: <18E3CF29-296D-4942-B254-1745978CA84D@bbn.com> <9C0749C2-33E7-4E59-95F7-5D421E014D05@brianrosen.net> Date: Tue, 17 Jul 2012 16:41:13 +0200 Message-ID: From: Laura Liess To: Brian Rosen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: A.Seus@telekom.de, "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 14:40:28 -0000 Hi Brian, 2012/7/16 Brian Rosen : > You could easily restrict your carrier LoST server to only serve DT custo= mers. > > Wouldn't that work? I am not sure I understand exactly the scenario you talk about. It seems to me that you have in mind a scenario where the end device requires the location. This is not the case in the scenario I am talking about, where the end device is not EC enabled and just initiates an emergency call. This scenario is described in Figure 5 in the draft. The ESRP URI is returned by LIS to the VSP, ot to the end device. I am aware that there are scenarios where this model does not work, especialy in connection with emergency calls from the enterprises and VPNs. Here the end device must query the LIS for the LbyR, otherwise the EC does not work properly. Also in this case, we could keep the HELD query done by the end device unchanged (returning the LbyR) and the VSP to query the LIS for the ESRP URI (using extended HELD or whatever protocol). And if you mean restricting the carrier LOST queries to end devices of DT customers: yes, this is possible. The reasons we prefer the LIS to query the LOST are: - The regulator very clearly requires to keep the functionalities and interfaces for end devices and networlk elements outside his country at a minimum. What if some guy is nomadic in the DT IP-network and our LOST and the end device LOST are different versions and do not interop? It was not just a call, but an emergency call .... We do not control the end devices and are not responsible if the guy dies. The regulator wants us to be responsible, not the dead guy with his old end device. - DT does not intend to implement the standardised LOST in the first stage. Today, we have one software component, for both. The standardized LOST will come later (at least I hope so), and DT will operate a real LOST server which is queried its enterprise dcustomers and smaler ISPs with their own LIS. > You are asking for a change that would affect every endpoint (they would = have to understand the ESRP return from a HELD query). If there is a less = drastic way of handling the problem, given that you admit you may evolve to= something closer to the current model, would that be acceptable? [LL] I am not sure I understand exactly the scenario you talk about. It seems to me that you have in mind a scenario where the end device requires the location. This is not the case in the scenario I am talking about, where the end device is not EC enabled and just initiates an emergency call. This scenario is described in Figure 5 in the draft. The ESRP URI is returned by LIS to the VSP, ot to the end device. I am aware that there are scenarios where this model does not work, especialy in connection with emergency calls from the enterprises and VPNs. Here the end device must query the LIS for the LbyR, otherwise the EC does not work properly. Also in this case, we could keep the HELD query done by the end device unchanged (returning the LbyR) and the VSP to query the LIS for the ESRP URI (using extended HELD or whatever protocol). And if you mean restricting the carrier LOST queries to end devices of DT customers: yes, this is possible. The reasons we prefer the LIS to query the LOST are: - The regulator very clearly requires to keep the functionalities and interfaces for end devices and networlk elements outside his country at a minimum. What if some guy is nomadic in the DT IP-network and our LOST and the end device LOST are different versions and do not interop? It was not just a call, but an emergency call .... We do not control the end devices and are not responsible if the guy dies. For DT this is OK; but the regulator wants us to be responsible, not the dead guy with his old end device. - DT does not intend to implement the standardised LOST in the first stage. Today, we have one software component, for both. The standardized LOST will come later (at least I hope so), and DT will operate a real LOST server which is queried its enterprise dcustomers and smaler ISPs with their own LIS. Thank you Laura > > Your LoST return could even be nonsense, as long as the carrier LoST serv= er recognized the nonsense. I wouldn't recommend it, but it would work. > > Brian > > On Jul 16, 2012, at 8:24 AM, Laura Liess wrote: > >> Hi Richard, >> >> please see inline. >> >>> >>> Thank you for this clarification. It is very useful in helping to unde= rstand the problem. >> >> [LL] There are two possible solutios described in Section 6. My >> comments are restricted to the second approach because this is the >> model we follow in Germany. Maybe there are countries where the first >> approach is prefered. >>> >>> I love your phrase "carrier LoST". That seems to me to be the best sol= ution here. It is cheap to deploy (a very simple CGI script), >>> and meets two important goals: >>> (1) Allowing ISPs to specify particular ESRPs, and >>> (2) Not requiring significant modifications to the end client interface= . >> >> [LL] Another aspect the German regulator brought up is he wants keep >> the dependencies on functionalities which are outside his >> country/jurisdiction as low as possible. >>> >>> This solution doesn't actually require any modification to ECRIT at all= . Clients are already required to support LoST discovery, so the carrier L= oST server can send them to whatever ESRP the carrier desires. >>> >>> There's still a need for the LIS to provide *something*, though, so tha= t clients don't say "I don't have any location, so I can't do LoST". But D= T's LIS, for example, could just return either a URI or DE, which doesn't seem like it would cost them anything. >>> >>> So I'm a little puzzled as to why we're talking about protocol changes. >> >> [LL] We need an extenssion to HELD, which enable us to return the ESRP U= RI. >> Returning DE would mean, if I understood correctly >> your intention, that the VSP queries the DT LOST with >> DE. DT has no intention to allow access to the >> "carrier LOST" from the Internet. At least at the beginning, the >> "carrier LOST" will be just the existing functionality doing the >> mapping between the location and the ESRP, accessed from the LIS via >> already existing proprietary interface. There is no new LOST >> implementation planed. I can imagine this existing functionality >> evolving in time towards a real LOST when the emergency calling >> scenarios become more general. E.g. for emergency calling from a >> distributed enterprise ( e.g. the local offices of a a bank) it makes >> sense that the enterprise does not have its own LOST but the >> enterprise LIS queries the DT LOST via the standardized LOST protocol, >> but still the access to LOST will be restricted to DT customers. >> >> Thanks a lot >> Laura >> >>> >>> --Richard >>> >>> >>> >>> >>> On Jul 13, 2012, at 9:44 AM, Laura Liess wrote: >>> >>>> Richard, >>>> >>>> My understanding is that rough location and the LOST query from the >>>> LIS are two different alternatives for two different use cases and >>>> both are useful. Please let me know if I am wrong. >>>> >>>> Rough location is a good choice in countries with dedicated emergency >>>> calling telecommunication infrastructure (and budget dedicated to >>>> develop this infrastructure) as ESInet. ESRPs and the LOST-tree are >>>> developped by organizations responsible for this infrastructure. A VSP >>>> queries the LIS with the IP-address and gets the rough location and >>>> the LbyR, then makes a LOST query with the rough location and gets the >>>> ESRP/PSAP. The ESRP/PSAP queries the LIS with the LbyR and gets the >>>> LbyV. The ISP will trust any ESRP/PSAP because they are parts of the >>>> emergency service infrastructure. The ISP do not care about LOST. >>>> >>>> In Germany, without dedicated emergency calling telecommunication >>>> infrastructure, ESRPs will be provided by some (large) national >>>> carriers. Because they are not paid for this in any way, they are not >>>> willing to provide LOST trees accessible from the Internet or ESRPs >>>> which have to query the LISs for every possible ISP. On the other >>>> side, small ISPs will not want to have trust relationships with more >>>> than one ESRP provider, in general they have an SLA with some large >>>> carrier for IP-access anyway. So it is important that the ESRP URI in >>>> the LOST response is ISP-specific. ISPs which are DT customers will >>>> get a different LOST response than the Vodafone customers for the same >>>> location in the query. >>>> In Germany, I could imagine that a so-called carrier LOST will be >>>> developped on the long term. At the beginning ISPs will configure one >>>> ESRP URI and that's it. There is no chance for the development of an >>>> open LOST infrastructure accessible from the Internet because there is >>>> nobody there to pay for it. In the current aggreement with the >>>> regulator, there is no LOST at all, the LIS is responsible for >>>> returning an ESRP URI which is able to query the location. >>>> >>>> Kind regards >>>> Laura >>>> >>>> >>>> >>>> >>>> 2012/7/12 Richard L. Barnes : >>>>> On Jul 11, 2012, at 12:57 PM, Marc Linsner wrote: >>>>> >>>>>> Richard, >>>>>> >>>>>> >>>>>>> >>>>>>> I'm going to take a first past at LbyR-in-LoST in a rev of rough-lo= c in >>>>>>> time for the draft deadline, so that we can have a basis for discus= sion >>>>>>> in Vancouver. >>>>>>> >>>>>>> Thanks for getting this conversation started, >>>>>>> --Richard >>>>>> >>>>>> Rough-loc is a WG document that's been through wglc. New ideas need= to be >>>>>> in a new draft. >>>>>> >>>>>> -Marc- >>>>> >>>>> >>>>> I'm not sure I agree. Doesn't the current conversation demonstrate t= hat rough-loc doesn't solve the problem it was intended to solve? I was ta= king this thread as very late WGLC comments -- or early IETF LC comments :) >>>>> >>>>> If you still want me to hold off, let me know and I will. >>>>> >>>>> --Richard >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > From br@brianrosen.net Tue Jul 17 08:13:37 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E479721F86D0 for ; Tue, 17 Jul 2012 08:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.757 X-Spam-Level: X-Spam-Status: No, score=-103.757 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCSxi+T4v5il for ; Tue, 17 Jul 2012 08:13:37 -0700 (PDT) Received: from barmail6.idig.net (barmail6.idig.net [64.34.111.239]) by ietfa.amsl.com (Postfix) with ESMTP id 0A31421F864B for ; Tue, 17 Jul 2012 08:13:37 -0700 (PDT) X-ASG-Debug-ID: 1342538063-0538de37f5516770001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail6.idig.net with ESMTP id fWZtQDRqH3V8CQI7; Tue, 17 Jul 2012 08:14:23 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233]:28755 helo=[192.168.133.249]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Sr9Ti-003JJP-Q3; Tue, 17 Jul 2012 08:14:23 -0700 Mime-Version: 1.0 (Apple Message framework v1278) X-ASG-Orig-Subj: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 Content-Type: text/plain; charset=iso-8859-1 From: Brian Rosen In-Reply-To: Date: Tue, 17 Jul 2012 11:14:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <47648695-109F-4143-A92C-CF7E962E8A9A@brianrosen.net> References: <18E3CF29-296D-4942-B254-1745978CA84D@bbn.com> <9C0749C2-33E7-4E59-95F7-5D421E014D05@brianrosen.net> To: Laura Liess X-Mailer: Apple Mail (2.1278) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1342538063 X-Barracuda-URL: http://64.34.111.239:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.102970 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: A.Seus@telekom.de, "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 15:13:38 -0000 See inline On Jul 17, 2012, at 10:41 AM, Laura Liess wrote: > Hi Brian, >=20 > 2012/7/16 Brian Rosen : >> You could easily restrict your carrier LoST server to only serve DT = customers. >>=20 >> Wouldn't that work? > I am not sure I understand exactly the scenario you talk about. It > seems to me that you have in mind a scenario where the end device > requires the location. This is not the case in the scenario I am > talking about, where the end device is not EC enabled and just > initiates an emergency call. This scenario is described in Figure 5 in > the draft. The ESRP URI is returned by LIS to the VSP, ot to the end > device. You have a LIS, you are proposing to have a "carrier LoST server" of = some sort at some stage. You want a single LIS query that returns ESRP URI. I'm suggesting you = query LIS to get something from the LIS, query LoST with that something = and get ESRP URI. Two queries to two boxes that gets the same result = instead of one query. >=20 > I am aware that there are scenarios where this model does not work, > especialy in connection with emergency calls from the enterprises and > VPNs. Here the end device must query the LIS for the LbyR, otherwise > the EC does not work properly. =20 So the LIS has to return some form of location. That's what I propose = you do, just like the current model. I'm suggesting that when a VSP = does the query, it gets some location that routes properly, but is not = the location of the caller. It's the VSP doing the query, so we don't = have a problem with obscuring for privacy, we only have a problem of = theft of service by the VSP (if you actually worry about that), and the = way around it is to have a single location per ESRP that is returned to = the VSP by the LIS. > Also in this case, we could keep the > HELD query done by the end device unchanged (returning the LbyR) and > the VSP to query the LIS for the ESRP URI (using extended HELD or > whatever protocol). And again I suggest this is dereference by VSP to the per-ESRP location = and a LoST query. >=20 > And if you mean restricting the carrier LOST queries to end devices of > DT customers: yes, this is possible. The reasons we prefer the LIS to > query the LOST are: >=20 > - The regulator very clearly requires to keep the functionalities and > interfaces for end devices and networlk elements outside his country > at a minimum. What if some guy is nomadic in the DT IP-network and our > LOST and the end device LOST are different versions and do not > interop? It was not just a call, but an emergency call .... We do not > control the end devices and are not responsible if the guy dies. The > regulator wants us to be responsible, not the dead guy with his old > end device. You are discussing new things (HELD). If you admit to new things, = HELD/LoST works fine. This is not a backwards compatibility issue - old things don't do HELD = queries. Simple is in the eye of the beholder. I want all devices to do exactly = the same thing in all environments. You query LIS, then you query LoST. = =20 >=20 > - DT does not intend to implement the standardised LOST in the first > stage. Today, we have one software component, for both. The > standardized LOST will come later (at least I hope so), and DT will > operate a real LOST server which is queried its enterprise dcustomers > and smaler ISPs with their own LIS. Today, you don't have HELD either. This is all new stuff. Do it right = the first time is a good suggestion I think. >=20 >> You are asking for a change that would affect every endpoint (they = would have to understand the ESRP return from a HELD query). If there = is a less drastic way of handling the problem, given that you admit you = may evolve to something closer to the current model, would that be = acceptable? >=20 > [LL] I am not sure I understand exactly the scenario you talk about. > It seems to me that you have in mind a scenario where the end device > requires the location. This is not the case in the scenario I am > talking about, where the end device is not EC enabled and just > initiates an emergency call. This scenario is described in Figure 5 in > the draft. The ESRP URI is returned by LIS to the VSP, ot to the end > device. If we change HELD so that it can return an ESRP URI, devices that = implement HELD have to change to deal with the ESRP URI instead of = location in the response. So it's "every endpoint that implements HELD", so I don't include = existing devices that don't query a LIS. >=20 > I am aware that there are scenarios where this model does not work, > especialy in connection with emergency calls from the enterprises and > VPNs. Here the end device must query the LIS for the LbyR, otherwise > the EC does not work properly. Also in this case, we could keep the > HELD query done by the end device unchanged (returning the LbyR) and > the VSP to query the LIS for the ESRP URI (using extended HELD or > whatever protocol). Or LoST :) >=20 > And if you mean restricting the carrier LOST queries to end devices of > DT customers: yes, this is possible. The reasons we prefer the LIS to > query the LOST are: >=20 > - The regulator very clearly requires to keep the functionalities and > interfaces for end devices and networlk elements outside his country > at a minimum. A worthy goal, but when you try to do that, you often make the whole = thing more complicated because you don't cover all the cases with the = "simple" approach. > What if some guy is nomadic in the DT IP-network and our > LOST and the end device LOST are different versions and do not > interop? I'm trying to help you by asking that you follow -phonebcp, so we don't = have the problem you are worried about. If we implement -phonebcp in = the U.S., what do you want to happen for a device roaming from US to = Germany or Germany to US? > It was not just a call, but an emergency call .... We do not > control the end devices and are not responsible if the guy dies. For > DT this is OK; but the regulator wants us to be responsible, not the > dead guy with his old end device. Backwards compatibility with older devices is of course a problem we all = have. The basic approach is VSP query LIS and VSP query LoST when the = device doesn't do it. You seem to agree. We're only dealing with the = specifics of how that works. I'd like the VSP to do a straight OBO = query for location from the LIS using the IP address of the caller and = get some form of location which, when used in a LoST query, returns the = ESRP URI you want it to. Combining LIS/LoST queries into one step is an = optimization that I don't think is a good idea. The VSP doesn't do a = HELD query today. Having the HELD query return ESRP URI is only an = optimization - the VSP needs new code, it has to implement HELD, and = asking that it also implement LoST is not an undue burden. >=20 > - DT does not intend to implement the standardised LOST in the first > stage. Today, we have one software component, for both. The > standardized LOST will come later (at least I hope so), and DT will > operate a real LOST server which is queried its enterprise dcustomers > and smaler ISPs with their own LIS. I don't understand why you are willing to implement a new HELD query but = are not willing to implement a new LoST query. They could be done in = the same box if you want to. Brian From brian.rosen@neustar.biz Tue Jul 17 08:53:33 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 094DE21F8535 for ; Tue, 17 Jul 2012 08:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxS6nnjwJM6u for ; Tue, 17 Jul 2012 08:53:30 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 7A23B21F8567 for ; Tue, 17 Jul 2012 08:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1342540714; x=1657894642; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=z+FG3MLAF2eN9VGuwH1Wy 8c3unwh003hm1URlT1Qw0U=; b=izTXhzPkpDgTQzlyKxpWgEKdL/iHXxNvB6Ohv Vii/2x3XPG2yezHCdED8Zoib0XN8o3OKXjgt8KPicSrE3e70w== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.12014373; Tue, 17 Jul 2012 11:58:33 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::28fd:d8c6:49f0:619b]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Tue, 17 Jul 2012 11:54:14 -0400 From: "Rosen, Brian" To: "ecrit@ietf.org Org" Date: Tue, 17 Jul 2012 11:54:12 -0400 Thread-Topic: -additional-data-04 Thread-Index: Ac1kNGlt3sC6N0KDRD2HxMOHlfzz9g== Message-ID: <3CCA04BA-CB42-4621-B77E-575421063DDA@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: pEaeIMbdxTua+84GObef2w== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Ecrit] -additional-data-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 15:53:33 -0000 http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-04 New release has changes as requested by Matt Serra (from NENA) and some edi= ts for the discussion Martin Thomson and I had on how to have one Call-Info= URI with multiple MIME types. I think the benefits of the MIME are slim a= nd the overhead is not worth it, but I did the link. I also added a registr= y of block types to make the job of the client (PSAP) easier. On the NENA updates, I started making the change requested to handle what t= hey called "data provider" but it looked to ugly to me. I did it a differe= nt way: I add a type of provider called "subcontractor" and added two eleme= nts: the "Principal" (the service provider who the subcontractor is contrac= ted to and "Priority" (who should be contacted first, the subcontractor or = the principal). I think this is a better way to solve the problem which ge= neralized to more cases than the specific backwards compatible mechanism pr= oposed. I think that this document is ready for work group last call. Brian From RMarshall@telecomsys.com Tue Jul 17 22:14:40 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3269A11E8123 for ; Tue, 17 Jul 2012 22:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9ysMFmFNtNk for ; Tue, 17 Jul 2012 22:14:39 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC2511E80FC for ; Tue, 17 Jul 2012 22:14:39 -0700 (PDT) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-01.telecomsys.com (8.14.1/8.14.1) with ESMTP id q6I5FKt0029264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 17 Jul 2012 22:15:20 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.114]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Tue, 17 Jul 2012 22:15:19 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: IETF84 - ECRIT agenda posted, comments? Thread-Index: Ac1kpFJID8uLzcPFSIGI6ZxYynhU/A== Date: Wed, 18 Jul 2012 05:15:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC0B9C89SEAEXMB1telecomsy_" MIME-Version: 1.0 Subject: [Ecrit] IETF84 - ECRIT agenda posted, comments? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 05:14:40 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC0B9C89SEAEXMB1telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The ECRIT proposed agenda has been uploaded and can be viewed at: http://www.ietf.org/proceedings/84/agenda/agenda-84-ecrit.txt Please send your comments for change before the start of IETF84. Regards, Roger Marshall & Marc Linsner, ECRIT Chairs CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC0B9C89SEAEXMB1telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The ECRIT proposed agenda has been uploaded and c= an be viewed at:

http://www.ietf.org/proceedings/84/agenda/agenda-8= 4-ecrit.txt

 

Please send your comments for change before the s= tart of IETF84.

Regards,

Roger Marshall & Marc Linsner, ECRIT Chairs

 

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC0B9C89SEAEXMB1telecomsy_-- From hannes.tschofenig@gmx.net Wed Jul 18 04:06:39 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB94B21F871E for ; Wed, 18 Jul 2012 04:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.624 X-Spam-Level: X-Spam-Status: No, score=-102.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfntYgRYKeVB for ; Wed, 18 Jul 2012 04:06:38 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 7296C21F869C for ; Wed, 18 Jul 2012 04:06:37 -0700 (PDT) Received: (qmail invoked by alias); 18 Jul 2012 11:07:25 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.102]) [88.115.216.191] by mail.gmx.net (mp016) with SMTP; 18 Jul 2012 13:07:25 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+1J1obcFO1P/Ie41F9wwNWnebTvqdxWRNvoTIshf VYI5PwHsEaNG2q Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Wed, 18 Jul 2012 14:07:19 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5A28BED2-A46C-4079-97C6-4F9532F9E648@gmx.net> References: To: Roger Marshall X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] IETF84 - ECRIT agenda posted, comments? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 11:06:39 -0000 Hey Roger,=20 looks like a good start.=20 Is Andrea going to be at the meeting to talk about = ?=20 I would like to mark the eCall draft as optional and discuss it only if = time permits. The allocated agenda time would then be moved to = draft-winterbottom-ecrit-priv-loc (which then gives it 20min discussion = time instead of 10min, which I think is far too short). = draft-winterbottom-ecrit-priv-loc had gotten feedback on the list and = the eCall draft hasn't.=20 Ciao Hannes On Jul 18, 2012, at 8:15 AM, Roger Marshall wrote: > The ECRIT proposed agenda has been uploaded and can be viewed at: > http://www.ietf.org/proceedings/84/agenda/agenda-84-ecrit.txt > =20 > Please send your comments for change before the start of IETF84. > Regards, > Roger Marshall & Marc Linsner, ECRIT Chairs > =20 > CONFIDENTIALITY NOTICE: The information contained in this message may = be privileged and/or confidential. If you are not the intended = recipient, or responsible for delivering this message to the intended = recipient, any review, forwarding, dissemination, distribution or = copying of this communication or any attachment(s) is strictly = prohibited. If you have received this message in error, please notify = the sender immediately, and delete it and all attachments from your = computer and network. >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From RMarshall@telecomsys.com Wed Jul 18 09:41:24 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D867511E80ED for ; Wed, 18 Jul 2012 09:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lA5H3c4jNMwB for ; Wed, 18 Jul 2012 09:41:24 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3805C11E80D9 for ; Wed, 18 Jul 2012 09:41:24 -0700 (PDT) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-02.telecomsys.com (8.14.1/8.14.1) with ESMTP id q6IGg3fI032247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 18 Jul 2012 09:42:03 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.203]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Wed, 18 Jul 2012 09:42:02 -0700 From: Roger Marshall To: Hannes Tschofenig Thread-Topic: [Ecrit] IETF84 - ECRIT agenda posted, comments? Thread-Index: Ac1kpFJID8uLzcPFSIGI6ZxYynhU/AAa9liAAAOAeuA= Date: Wed, 18 Jul 2012 16:42:01 +0000 Message-ID: References: <5A28BED2-A46C-4079-97C6-4F9532F9E648@gmx.net> In-Reply-To: <5A28BED2-A46C-4079-97C6-4F9532F9E648@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] IETF84 - ECRIT agenda posted, comments? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 16:41:25 -0000 Hannes: Thanks for the feedback. Will check with Andrea as to his availability for= the ecrit-service-urn-policy draft. The updated agenda moves the eCall slot to optional (10 min in lieu of choi= ce of discussion at end), and bumping up the draft-winterbottom-ecrit-priv-= loc time to 20 min. The updated agenda is at the following: http://www.ietf.org/proceedings/84/agenda/agenda-84-ecrit.txt -roger marshall. -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Wednesday, July 18, 2012 4:07 AM To: Roger Marshall Cc: Hannes Tschofenig; ecrit@ietf.org Subject: Re: [Ecrit] IETF84 - ECRIT agenda posted, comments? Hey Roger,=20 looks like a good start.=20 Is Andrea going to be at the meeting to talk about ?=20 I would like to mark the eCall draft as optional and discuss it only if tim= e permits. The allocated agenda time would then be moved to draft-winterbot= tom-ecrit-priv-loc (which then gives it 20min discussion time instead of 10= min, which I think is far too short). draft-winterbottom-ecrit-priv-loc had= gotten feedback on the list and the eCall draft hasn't.=20 Ciao Hannes On Jul 18, 2012, at 8:15 AM, Roger Marshall wrote: > The ECRIT proposed agenda has been uploaded and can be viewed at: > http://www.ietf.org/proceedings/84/agenda/agenda-84-ecrit.txt > =20 > Please send your comments for change before the start of IETF84. > Regards, > Roger Marshall & Marc Linsner, ECRIT Chairs > =20 > CONFIDENTIALITY NOTICE: The information contained in this message may be = privileged and/or confidential. If you are not the intended recipient, or r= esponsible for delivering this message to the intended recipient, any revie= w, forwarding, dissemination, distribution or copying of this communication= or any attachment(s) is strictly prohibited. If you have received this mes= sage in error, please notify the sender immediately, and delete it and all = attachments from your computer and network. >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Wed Jul 18 16:39:16 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E55321F8504 for ; Wed, 18 Jul 2012 16:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.609 X-Spam-Level: X-Spam-Status: No, score=-106.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7WSLYkIimQo for ; Wed, 18 Jul 2012 16:39:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 43EDA21F84EE for ; Wed, 18 Jul 2012 16:39:15 -0700 (PDT) Received: from [128.89.253.162] (port=61051) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SrdqY-0000Tf-RS; Wed, 18 Jul 2012 19:39:58 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 18 Jul 2012 19:39:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A28BED2-A46C-4079-97C6-4F9532F9E648@gmx.net> To: Roger Marshall X-Mailer: Apple Mail (2.1278) Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] IETF84 - ECRIT agenda posted, comments? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 23:39:16 -0000 If I could make one more suggestion: -priv-loc is closely related to = -rough-loc, so we should move their slots together to facilitate = discussion. We might even combine the slots if Hannes is willing to = share :) --Richard On Jul 18, 2012, at 12:42 PM, Roger Marshall wrote: > Hannes: > Thanks for the feedback. Will check with Andrea as to his = availability for the ecrit-service-urn-policy draft. >=20 > The updated agenda moves the eCall slot to optional (10 min in lieu of = choice of discussion at end), and bumping up the = draft-winterbottom-ecrit-priv-loc time to 20 min. >=20 > The updated agenda is at the following: > http://www.ietf.org/proceedings/84/agenda/agenda-84-ecrit.txt >=20 > -roger marshall. >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 > Sent: Wednesday, July 18, 2012 4:07 AM > To: Roger Marshall > Cc: Hannes Tschofenig; ecrit@ietf.org > Subject: Re: [Ecrit] IETF84 - ECRIT agenda posted, comments? >=20 > Hey Roger,=20 >=20 > looks like a good start.=20 >=20 > Is Andrea going to be at the meeting to talk about = ?=20 >=20 > I would like to mark the eCall draft as optional and discuss it only = if time permits. The allocated agenda time would then be moved to = draft-winterbottom-ecrit-priv-loc (which then gives it 20min discussion = time instead of 10min, which I think is far too short). = draft-winterbottom-ecrit-priv-loc had gotten feedback on the list and = the eCall draft hasn't.=20 >=20 > Ciao > Hannes >=20 > On Jul 18, 2012, at 8:15 AM, Roger Marshall wrote: >=20 >> The ECRIT proposed agenda has been uploaded and can be viewed at: >> http://www.ietf.org/proceedings/84/agenda/agenda-84-ecrit.txt >>=20 >> Please send your comments for change before the start of IETF84. >> Regards, >> Roger Marshall & Marc Linsner, ECRIT Chairs >>=20 >> CONFIDENTIALITY NOTICE: The information contained in this message may = be privileged and/or confidential. If you are not the intended = recipient, or responsible for delivering this message to the intended = recipient, any review, forwarding, dissemination, distribution or = copying of this communication or any attachment(s) is strictly = prohibited. If you have received this message in error, please notify = the sender immediately, and delete it and all attachments from your = computer and network. >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From rjsparks@nostrum.com Thu Jul 19 14:51:27 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A83511E80C4 for ; Thu, 19 Jul 2012 14:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkZsATtZNFFq for ; Thu, 19 Jul 2012 14:51:26 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9B511E80C5 for ; Thu, 19 Jul 2012 14:51:25 -0700 (PDT) Received: from unexplicable.local (pool-173-57-102-202.dllstx.fios.verizon.net [173.57.102.202]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q6JLqIsZ098648 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Thu, 19 Jul 2012 16:52:19 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <50088192.1000103@nostrum.com> Date: Thu, 19 Jul 2012 16:52:18 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: ecrit@ietf.org References: <20120713003410.30068.4536.idtracker@ietfa.amsl.com> In-Reply-To: <20120713003410.30068.4536.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120713003410.30068.4536.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020408050908030909050307" Received-SPF: pass (nostrum.com: 173.57.102.202 is authenticated by a trusted mechanism) Subject: [Ecrit] Fwd: New Version Notification - draft-polk-local-emergency-rph-namespace-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 21:51:27 -0000 This is a multi-part message in MIME format. --------------020408050908030909050307 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit FYI - I believe this version addresses the IETF LC comments and am moving the document into IESG evaluation. RjS -------- Original Message -------- Subject: New Version Notification - draft-polk-local-emergency-rph-namespace-02.txt Date: Thu, 12 Jul 2012 17:34:10 -0700 From: internet-drafts@ietf.org To: jmpolk@cisco.com, draft-polk-local-emergency-rph-namespace@tools.ietf.org, Brian.Rosen@neustar.biz, rjsparks@nostrum.com New version (-02) has been submitted for draft-polk-local-emergency-rph-namespace-02.txt: http://www.ietf.org/internet-drafts/draft-polk-local-emergency-rph-namespace-02.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-polk-local-emergency-rph-namespace/ Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-polk-local-emergency-rph-namespace-02 IETF Secretariat. --------------020408050908030909050307 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit FYI -

I believe this version addresses the IETF LC comments and am moving the document into IESG evaluation.

RjS


-------- Original Message --------
Subject: New Version Notification - draft-polk-local-emergency-rph-namespace-02.txt
Date: Thu, 12 Jul 2012 17:34:10 -0700
From: internet-drafts@ietf.org
To: jmpolk@cisco.com, draft-polk-local-emergency-rph-namespace@tools.ietf.org, Brian.Rosen@neustar.biz, rjsparks@nostrum.com 


New version (-02) has been submitted for draft-polk-local-emergency-rph-namespace-02.txt:
http://www.ietf.org/internet-drafts/draft-polk-local-emergency-rph-namespace-02.txt

Sub state has been changed to AD Followup from Revised ID Needed


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-polk-local-emergency-rph-namespace/

Diff from previous version:
http://tools.ietf.org/rfcdiff?url2=draft-polk-local-emergency-rph-namespace-02

IETF Secretariat.



--------------020408050908030909050307-- From laura.liess.dt@googlemail.com Fri Jul 20 05:57:35 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1219221F861F for ; Fri, 20 Jul 2012 05:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtYI4J9EV6Pt for ; Fri, 20 Jul 2012 05:57:33 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 92A5C21F861B for ; Fri, 20 Jul 2012 05:57:33 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4299152ghb.31 for ; Fri, 20 Jul 2012 05:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=j3tyEeAvVAJ/QIqsBD1wX20z8Z9mALLIjuGX9J7mfR0=; b=iUh1j+/GtM0dfYT17quGCpBjOnmVRb5tUY65oj0ZeboVYEpKKto8i5mmcvCFV62z0w Z0azQzsi2NpK0bQZjcz55UbijvcaElhvKnUjbpziJ5/AXjb8aRTlPM2NP7VBB/Fi1E8C YehT/GxATRA8iAtkDi7Qlpv70JpfALkX3bp8kX4uKpdzXk+vl+glvtJTXMtp7mAwEYkj 84SiV+2k6smL222zmwtKaSJ1qxzjFxNkmDm3JYHT+uj3GbVYeSy+QqMHyqPgZn/+tMY/ mHKXAQ4Oh6oo4OKjQFCGM96c23kbb4o6qtMSjnKDTvfSaDUczZxA5QPUuYVhoWIiMX+b YFdw== MIME-Version: 1.0 Received: by 10.50.157.136 with SMTP id wm8mr4323929igb.14.1342789109131; Fri, 20 Jul 2012 05:58:29 -0700 (PDT) Received: by 10.231.200.37 with HTTP; Fri, 20 Jul 2012 05:58:28 -0700 (PDT) In-Reply-To: <47648695-109F-4143-A92C-CF7E962E8A9A@brianrosen.net> References: <18E3CF29-296D-4942-B254-1745978CA84D@bbn.com> <9C0749C2-33E7-4E59-95F7-5D421E014D05@brianrosen.net> <47648695-109F-4143-A92C-CF7E962E8A9A@brianrosen.net> Date: Fri, 20 Jul 2012 14:58:28 +0200 Message-ID: From: Laura Liess To: Brian Rosen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: A.Seus@telekom.de, "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 12:57:35 -0000 Brian, We already discussed the "two queries" alternative within DT and with the regulator. There was no acceptance for it. Let me try to explain why. There is in Germany no obligation for end devices, for enterprises, for VSPs which do not have an SLA with German carriers to support emergency calls and no obligation for ISPs to interop with them for emergency calls. More than that, VSPs and ISPs which must support emergency calls are not allowed to rely on end device functionality. DT has no advantage from providing more emergency calling functionalty than required by the regulator and every product manager is trying to keep his costs as low as possible. DT has today a server similar to a LIS. SIP-proxies query this server with the IP-address and get a kind of location reference (a string) and the PSAP URI. PSAPs can query the server with the location referene (string) and get the the LbyV. The query is HTTP with proprietary xml-format. DT has to add some functionality to suport SIP emergency calls when the ISP and VSP are different. The cost for the implementation must be kept as low as possible. I see some chance to replace the proprietary interface and move to HELD if HELD supports the functionality we have today. But I would not find any product manager to pay the vendors for a second LOST query which is not necessary at all, just to interwork with end devices. Queries from end devices are not even desirable. And the regulator sees that if we have 2 queries to 2 boxes instead of 1 query to 1 box the risk for the emergency call to fail is higher. Sorry for not having better news...Personally, I would like to see emergency calls working worldwide, too, but unfortunately it's all about money :-(. Kind regards Laura 2012/7/17 Brian Rosen : > See inline > On Jul 17, 2012, at 10:41 AM, Laura Liess wrote: > >> Hi Brian, >> >> 2012/7/16 Brian Rosen : >>> You could easily restrict your carrier LoST server to only serve DT cus= tomers. >>> >>> Wouldn't that work? >> I am not sure I understand exactly the scenario you talk about. It >> seems to me that you have in mind a scenario where the end device >> requires the location. This is not the case in the scenario I am >> talking about, where the end device is not EC enabled and just >> initiates an emergency call. This scenario is described in Figure 5 in >> the draft. The ESRP URI is returned by LIS to the VSP, ot to the end >> device. > You have a LIS, you are proposing to have a "carrier LoST server" of some= sort at some stage. > You want a single LIS query that returns ESRP URI. I'm suggesting you q= uery LIS to get something from the LIS, query LoST with that something and = get ESRP URI. Two queries to two boxes that gets the same result instead o= f one query. > >> >> I am aware that there are scenarios where this model does not work, >> especialy in connection with emergency calls from the enterprises and >> VPNs. Here the end device must query the LIS for the LbyR, otherwise >> the EC does not work properly. > So the LIS has to return some form of location. That's what I propose yo= u do, just like the current model. I'm suggesting that when a VSP does the= query, it gets some location that routes properly, but is not the location= of the caller. It's the VSP doing the query, so we don't have a problem w= ith obscuring for privacy, we only have a problem of theft of service by th= e VSP (if you actually worry about that), and the way around it is to have = a single location per ESRP that is returned to the VSP by the LIS. > >> Also in this case, we could keep the >> HELD query done by the end device unchanged (returning the LbyR) and >> the VSP to query the LIS for the ESRP URI (using extended HELD or >> whatever protocol). > And again I suggest this is dereference by VSP to the per-ESRP location a= nd a LoST query. > >> >> And if you mean restricting the carrier LOST queries to end devices of >> DT customers: yes, this is possible. The reasons we prefer the LIS to >> query the LOST are: >> >> - The regulator very clearly requires to keep the functionalities and >> interfaces for end devices and networlk elements outside his country >> at a minimum. What if some guy is nomadic in the DT IP-network and our >> LOST and the end device LOST are different versions and do not >> interop? It was not just a call, but an emergency call .... We do not >> control the end devices and are not responsible if the guy dies. The >> regulator wants us to be responsible, not the dead guy with his old >> end device. > You are discussing new things (HELD). If you admit to new things, HELD/L= oST works fine. > This is not a backwards compatibility issue - old things don't do HELD qu= eries. > > Simple is in the eye of the beholder. I want all devices to do exactly t= he same thing in all environments. You query LIS, then you query LoST. > >> >> - DT does not intend to implement the standardised LOST in the first >> stage. Today, we have one software component, for both. The >> standardized LOST will come later (at least I hope so), and DT will >> operate a real LOST server which is queried its enterprise dcustomers >> and smaler ISPs with their own LIS. > Today, you don't have HELD either. This is all new stuff. Do it right t= he first time is a good suggestion I think. > >> >>> You are asking for a change that would affect every endpoint (they woul= d have to understand the ESRP return from a HELD query). If there is a les= s drastic way of handling the problem, given that you admit you may evolve = to something closer to the current model, would that be acceptable? >> >> [LL] I am not sure I understand exactly the scenario you talk about. >> It seems to me that you have in mind a scenario where the end device >> requires the location. This is not the case in the scenario I am >> talking about, where the end device is not EC enabled and just >> initiates an emergency call. This scenario is described in Figure 5 in >> the draft. The ESRP URI is returned by LIS to the VSP, ot to the end >> device. > If we change HELD so that it can return an ESRP URI, devices that impleme= nt HELD have to change to deal with the ESRP URI instead of location in the= response. > > So it's "every endpoint that implements HELD", so I don't include existin= g devices that don't query a LIS. >> >> I am aware that there are scenarios where this model does not work, >> especialy in connection with emergency calls from the enterprises and >> VPNs. Here the end device must query the LIS for the LbyR, otherwise >> the EC does not work properly. Also in this case, we could keep the >> HELD query done by the end device unchanged (returning the LbyR) and >> the VSP to query the LIS for the ESRP URI (using extended HELD or >> whatever protocol). > Or LoST :) >> >> And if you mean restricting the carrier LOST queries to end devices of >> DT customers: yes, this is possible. The reasons we prefer the LIS to >> query the LOST are: >> >> - The regulator very clearly requires to keep the functionalities and >> interfaces for end devices and networlk elements outside his country >> at a minimum. > A worthy goal, but when you try to do that, you often make the whole thin= g more complicated because you don't cover all the cases with the "simple" = approach. > >> What if some guy is nomadic in the DT IP-network and our >> LOST and the end device LOST are different versions and do not >> interop? > I'm trying to help you by asking that you follow -phonebcp, so we don't h= ave the problem you are worried about. If we implement -phonebcp in the U.= S., what do you want to happen for a device roaming from US to Germany or G= ermany to US? > >> It was not just a call, but an emergency call .... We do not >> control the end devices and are not responsible if the guy dies. For >> DT this is OK; but the regulator wants us to be responsible, not the >> dead guy with his old end device. > Backwards compatibility with older devices is of course a problem we all = have. The basic approach is VSP query LIS and VSP query LoST when the devi= ce doesn't do it. You seem to agree. We're only dealing with the specific= s of how that works. I'd like the VSP to do a straight OBO query for locat= ion from the LIS using the IP address of the caller and get some form of lo= cation which, when used in a LoST query, returns the ESRP URI you want it t= o. Combining LIS/LoST queries into one step is an optimization that I don'= t think is a good idea. The VSP doesn't do a HELD query today. Having the= HELD query return ESRP URI is only an optimization - the VSP needs new co= de, it has to implement HELD, and asking that it also implement LoST is not= an undue burden. > >> >> - DT does not intend to implement the standardised LOST in the first >> stage. Today, we have one software component, for both. The >> standardized LOST will come later (at least I hope so), and DT will >> operate a real LOST server which is queried its enterprise dcustomers >> and smaler ISPs with their own LIS. > I don't understand why you are willing to implement a new HELD query but = are not willing to implement a new LoST query. They could be done in the s= ame box if you want to. > > Brian > From mserra@ravemobilesafety.com Mon Jul 23 14:13:51 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2CA11E807F for ; Mon, 23 Jul 2012 14:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8twXnhuYj-MZ for ; Mon, 23 Jul 2012 14:13:51 -0700 (PDT) Received: from server505.appriver.com (server505h.appriver.com [98.129.35.13]) by ietfa.amsl.com (Postfix) with ESMTP id 12F9521F848F for ; Mon, 23 Jul 2012 14:13:50 -0700 (PDT) X-Note-AR-ScanTimeLocal: 7/23/2012 4:13:49 PM X-Policy: GLOBAL - ravemobilesafety.com X-Policy: GLOBAL - ravemobilesafety.com X-Primary: mserra@ravemobilesafety.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @ravemobilesafety.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: X-Note-Return-Path: mserra@ravemobilesafety.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G279 G280 G281 G282 G286 G287 G298 G389 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.4) with ESMTPS id 238235385; Mon, 23 Jul 2012 16:13:49 -0500 Received: from MBX05.exg5.exghost.com ([169.254.1.137]) by HT08-E5.exg5.exghost.com ([98.129.23.244]) with mapi; Mon, 23 Jul 2012 16:13:47 -0500 From: Matt Serra To: "ecrit@ietf.org" Date: Mon, 23 Jul 2012 16:13:43 -0500 Thread-Topic: Comments against Additional Caller Data v4.0 ECRIT Draft from NENA Add'l Data WG. Thread-Index: Ac1pGApBxKIYgq8DSsiKLxK4PPpFLQ== Message-ID: <6B92B1E73D1E7B468E5C97CAE569CBA108DDE207D4@MBX05.exg5.exghost.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Addl Data WG Subject: [Ecrit] Comments against Additional Caller Data v4.0 ECRIT Draft from NENA Add'l Data WG. X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 21:13:52 -0000 On behalf of the NENA Additional Data Work Group, I respectfully submit the= following comments against this document: http://tools.ietf.org/html/draft= -ietf-ecrit-additional-data-04=20 --------------Begin Comments-------------- 1. Introduction * V4.0: "In general, there are four types of data exchanged:" * NENA Comment: Recommend we reference "three" rather than "four" types of = data. This also requires that we strike the associated "Data associated wi= th a PSAP:" paragraph. * V4.0 Nit: " Data Associated with a Call: . . (as part of the SIP header= s as well as in the body of the SIP message," * NENA Comment: (nit) is missing a closing parentheses " . . (as part of t= he SIP headers as well as in the body of the SIP message)," 3. Call Info Specification * V4.0 "More than one Call-Info header with an emergencyCallData purpose ca= n be expected, but at least one MUST be provided. The device MUST provide = one if no service provider is in the path of the call. The device MAY inse= rt one if it uses a service provider, and any intermediary service provider= SHOULD insert its own. When there are multiple intermediaries, each inter= mediary SHOULD each insert one." * NENA Comment: While the first sentence states emergencyCAllData must be p= rovided, the rules that follow this sentence do not necessarily ensure this= is the case. We recommend this paragraph be reworked to ensure at least o= ne set of Call Data is provided with each call. 4.3 Type of Data Provider ID * v4.0 " Description: Identifies the type of data provider id being suppli= ed in the ProviderId data element. A registry will reflect the following v= alid entries: * Access Provider * Origination Network Provider * ServiceProviderSubcontractor * Other * NENA Comment: We recommend the terminology used in ECRIT documentation b= e used, rather than the terminology proposed above. Perhaps consider adding= other valid values as well, such as "Relay Service Provider", "Telematics = Provider", etc. * v4.0: this document speaks to the "function" provided by the referenced = Data Provider * NENA Comment: The original intent of this field was to convey which regi= stry the "Data Provider ID" (4.2) refers to (e.g. NENA Company ID). It see= ms as if a separate field to convey the function of the referenced "Data Pr= ovider ID" needs to be documented. * V4.0 "Description . . . A registry will reflect the following valid entr= ies" * NENA Comment: While the registry is mentioned in the "Description" no su= ch registry is called for within Section 12.1 Registry Creation 4.7 Subcontractor Principal * V4.0 "Description: . . . the data provider is a subcontractor to an acces= s provider or origination network, this element contains the DataProviderSt= ring of the access provider or origination network" * NENA Comment: Similar to feedback on 4.3, should consider alternate terms= for "access provider" and "origination network" consistent with other ECRI= T documents. 5.1 Service Environment * v4.0 - " Reason for Need: To assist in determining equipment and manpowe= r requirements." * NENA Comment: we recommend softening current reason for need, adding a r= eference to ALI backwards compatibility (for Legacy PSAP Gateway). Sample = text: "May be useful in determining equipment and manpower requirements dur= ing dispatch. Supports Legacy PSAP Gateway data transcoding." Similar chan= ges are recommended for "How used by Call Taker" 5.3. Service Mobility Environment * v4.0: "Service Mobility Environment" * NENA Comment: As the valid values describes service environments other t= han Mobile, a more generic name (such as "Service Use Environment" or "Serv= ice Deployment Environment") may be warranted 5.4. addCallSvcInfo XML Schema * v4.0: " * NENA Comment: We believe the maxOccurs should be "1" rather than "unboun= ded". The minOccurs should also be "1", as this is a required field. We r= ecommend the various XML definitions be inspected throughout this DRAFT for= field usage consistency / accuracy. 6.1. Device Classification * v4.0: "It is possible to receive 2 Additional Data Associated with a Call= er data structures, one created by the device and . . ." * NENA Comment: Should reference "Additional Data Associated with Call", r= ather than "Caller" * v4.0: " Reason for Need: . . . does the device require human intervention= to initiate a call or is this call the result of programmed instructions?.= " * NENA Comment: Nit - extraneous period (.) after question mark (?) --------------End Comments-------------- Matthew A. Serra, ENP NENA Additional Data Workgroup Chair Sr. Director, Product Management=20 Rave Mobile Safety | Smart911 Mobile:=A0=A0201.245.1557 mserra@ravemobilesafety.com From randy@qualcomm.com Wed Jul 25 18:51:29 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED41C11E8091 for ; Wed, 25 Jul 2012 18:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeAKx3tSkNRy for ; Wed, 25 Jul 2012 18:51:27 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAAA11E8079 for ; Wed, 25 Jul 2012 18:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1343267488; x=1374803488; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:mime-version:content-type:x-random-sig-tag: x-originating-ip; bh=WjKNKtpCjbUWZX49Ci5GQR4zljE0oXRepeHA4gwM5CQ=; b=u1nHzJ6eJFhIHfj9kvRAjFEFpyJ8tbkEmjvPckZO10FfY+uG7Ud63db4 7mmcLaJN6pQkEEc3T4bu/huyRmGCL8Gq3jXCLeAkE/VITtF7MCNYI4e0E HuDyPGPmcWabVbAtMzJaxbXD3ltVzntfSRvIe+aE0ZhjMLEZ1/mabgS87 I=; X-IronPort-AV: E=McAfee;i="5400,1158,6783"; a="214573343" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 25 Jul 2012 18:51:28 -0700 X-IronPort-AV: E=Sophos;i="4.77,656,1336374000"; d="scan'208";a="353554292" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 25 Jul 2012 18:51:27 -0700 Received: from loud.pensive.org (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 25 Jul 2012 18:51:26 -0700 Message-ID: In-Reply-To: <3CCA04BA-CB42-4621-B77E-575421063DDA@neustar.biz> References: <3CCA04BA-CB42-4621-B77E-575421063DDA@neustar.biz> X-Mailer: Eudora for Mac OS X Date: Wed, 25 Jul 2012 18:50:23 -0700 To: "Rosen, Brian" , "ecrit@ietf.org Org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Subject: Re: [Ecrit] -additional-data-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 01:51:29 -0000 Hi Brian, Did you look at the edits I suggested back in November, submitted against -02? When I asked you in March about it since they weren't reflected in -03, you said you'd missed them by accident. It doesn't look like you considered them in -04, so I'd like to know if this was deliberate or accidental (in which case an -05 might be a good idea prior to WGLC). At 11:54 AM -0400 7/17/12, Brian Rosen wrote: > http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-04 > > New release has changes as requested by Matt Serra (from NENA) and > some edits for the discussion Martin Thomson and I had on how to > have one Call-Info URI with multiple MIME types. I think the > benefits of the MIME are slim and the overhead is not worth it, but > I did the link. I also added a registry of block types to make the > job of the client (PSAP) easier. > > On the NENA updates, I started making the change requested to > handle what they called "data provider" but it looked to ugly to > me. I did it a different way: I add a type of provider called > "subcontractor" and added two elements: the "Principal" (the > service provider who the subcontractor is contracted to and > "Priority" (who should be contacted first, the subcontractor or the > principal). I think this is a better way to solve the problem > which generalized to more cases than the specific backwards > compatible mechanism proposed. > > I think that this document is ready for work group last call. > > Brian > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Genetics explains why you look like your father, and if you don't, why you should. From James.Winterbottom@commscope.com Sun Jul 29 18:51:10 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0857021F861F for ; Sun, 29 Jul 2012 18:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6xgLd-Dw-6z for ; Sun, 29 Jul 2012 18:51:09 -0700 (PDT) Received: from cdcsmgw02.commscope.com (smtp1.andrew.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id E64D221F8622 for ; Sun, 29 Jul 2012 18:51:08 -0700 (PDT) X-AuditID: 0a0404e9-b7cf7ae000005816-87-5015e87fc751 Received: from CDCE10HC1.commscope.com ( [10.86.28.21]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 00.C8.22550.F78E5105; Sun, 29 Jul 2012 20:50:55 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sun, 29 Jul 2012 20:51:06 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 30 Jul 2012 09:51:04 +0800 From: "Winterbottom, James" To: "Richard L. Barnes" , Laura Liess Date: Mon, 30 Jul 2012 09:51:02 +0800 Thread-Topic: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 Thread-Index: Ac1hFSca8iKHO3JWToSZBYd8W4jZCAM4DlCQ Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012121E17004@SISPE7MB1.commscope.com> References: <18E3CF29-296D-4942-B254-1745978CA84D@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAhlX8ksbej7C Cc: "A.Seus@telekom.de" , "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 01:51:10 -0000 Hi Richard, If the LIS is returning a PSAP URI and a location URI, why does it need to = return any location value at all? It is important to note that the end-point in the scenarios we are talking = about doesn't get location at all, because it breaks the requirements if it= does. Cheers James James Winterbottom Global Product Manager Commscope GeoLENs IP Location Product Portfolio Suite 1, Level 2, iC Enterprise 1 Innovation Campus, Squires Way North Wollongong, NSW, 2500 Australia Email: james.winterbottom@commscope.com Phone: +61-2-42-212938 Mobile: +61-447-773-560 www.commscope.com | www.commscopeblogs.com =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Richard L. Barnes > Sent: Saturday, 14 July 2012 2:33 AM > To: Laura Liess > Cc: A.Seus@telekom.de; ecrit@ietf.org Org > Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 >=20 > Hi Laura, >=20 > Thank you for this clarification. It is very useful in helping to > understand the problem. >=20 > I love your phrase "carrier LoST". That seems to me to be the best > solution here. It is cheap to deploy (a very simple CGI script), and > meets two important goals: > (1) Allowing ISPs to specify particular ESRPs, and > (2) Not requiring significant modifications to the end client interface. >=20 > This solution doesn't actually require any modification to ECRIT at all. > Clients are already required to support LoST discovery, so the carrier > LoST server can send them to whatever ESRP the carrier desires. >=20 > There's still a need for the LIS to provide *something*, though, so that > clients don't say "I don't have any location, so I can't do LoST". But > DT's LIS, for example, could just return either a URI or > DE, which doesn't seem like it would cost them > anything. >=20 > So I'm a little puzzled as to why we're talking about protocol changes. >=20 > --Richard >=20 >=20 >=20 >=20 > On Jul 13, 2012, at 9:44 AM, Laura Liess wrote: >=20 > > Richard, > > > > My understanding is that rough location and the LOST query from the > > LIS are two different alternatives for two different use cases and > > both are useful. Please let me know if I am wrong. > > > > Rough location is a good choice in countries with dedicated emergency > > calling telecommunication infrastructure (and budget dedicated to > > develop this infrastructure) as ESInet. ESRPs and the LOST-tree are > > developped by organizations responsible for this infrastructure. A VSP > > queries the LIS with the IP-address and gets the rough location and > > the LbyR, then makes a LOST query with the rough location and gets the > > ESRP/PSAP. The ESRP/PSAP queries the LIS with the LbyR and gets the > > LbyV. The ISP will trust any ESRP/PSAP because they are parts of the > > emergency service infrastructure. The ISP do not care about LOST. > > > > In Germany, without dedicated emergency calling telecommunication > > infrastructure, ESRPs will be provided by some (large) national > > carriers. Because they are not paid for this in any way, they are not > > willing to provide LOST trees accessible from the Internet or ESRPs > > which have to query the LISs for every possible ISP. On the other > > side, small ISPs will not want to have trust relationships with more > > than one ESRP provider, in general they have an SLA with some large > > carrier for IP-access anyway. So it is important that the ESRP URI in > > the LOST response is ISP-specific. ISPs which are DT customers will > > get a different LOST response than the Vodafone customers for the same > > location in the query. > > In Germany, I could imagine that a so-called carrier LOST will be > > developped on the long term. At the beginning ISPs will configure one > > ESRP URI and that's it. There is no chance for the development of an > > open LOST infrastructure accessible from the Internet because there is > > nobody there to pay for it. In the current aggreement with the > > regulator, there is no LOST at all, the LIS is responsible for > > returning an ESRP URI which is able to query the location. > > > > Kind regards > > Laura > > > > > > > > > > 2012/7/12 Richard L. Barnes : > >> On Jul 11, 2012, at 12:57 PM, Marc Linsner wrote: > >> > >>> Richard, > >>> > >>> > >>>> > >>>> I'm going to take a first past at LbyR-in-LoST in a rev of rough-loc > in > >>>> time for the draft deadline, so that we can have a basis for > discussion > >>>> in Vancouver. > >>>> > >>>> Thanks for getting this conversation started, > >>>> --Richard > >>> > >>> Rough-loc is a WG document that's been through wglc. New ideas need > to be > >>> in a new draft. > >>> > >>> -Marc- > >> > >> > >> I'm not sure I agree. Doesn't the current conversation demonstrate > that rough-loc doesn't solve the problem it was intended to solve? I was > taking this thread as very late WGLC comments -- or early IETF LC comment= s > :) > >> > >> If you still want me to hold off, let me know and I will. > >> > >> --Richard > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From RMarshall@telecomsys.com Sun Jul 29 23:17:52 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5567221F848A for ; Sun, 29 Jul 2012 23:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFNRvkvexWMs for ; Sun, 29 Jul 2012 23:17:51 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) by ietfa.amsl.com (Postfix) with ESMTP id 531F921F847A for ; Sun, 29 Jul 2012 23:17:51 -0700 (PDT) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-01.telecomsys.com (8.14.1/8.14.1) with ESMTP id q6U6HX15010219 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sun, 29 Jul 2012 23:17:33 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.203]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Sun, 29 Jul 2012 23:17:33 -0700 From: Roger Marshall To: "Richard L. Barnes" Thread-Topic: [Ecrit] IETF84 - ECRIT agenda posted, comments? Thread-Index: Ac1kpFJID8uLzcPFSIGI6ZxYynhU/AAa9liAAAOAeuAAFsiXgAInGKkQ Date: Mon, 30 Jul 2012 06:17:32 +0000 Message-ID: References: <5A28BED2-A46C-4079-97C6-4F9532F9E648@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] IETF84 - ECRIT agenda posted, comments? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 06:17:52 -0000 I've updated the ecrit agenda, removing ecrit-service-urn-policy, since And= rea isn't able to attend/present. Also I've rearranged the agenda order slightly, putting -rough-loc and -pri= v-loc next to each other, per Richard's suggestion. No change to the amoun= t of time slotted for each. If we need to do that, I'd like to hear more b= ashing. Thanks. -roger. -----Original Message----- From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 Sent: Wednesday, July 18, 2012 4:40 PM To: Roger Marshall Cc: Hannes Tschofenig; ecrit@ietf.org Subject: Re: [Ecrit] IETF84 - ECRIT agenda posted, comments? If I could make one more suggestion: -priv-loc is closely related to -rough= -loc, so we should move their slots together to facilitate discussion. We = might even combine the slots if Hannes is willing to share :) --Richard On Jul 18, 2012, at 12:42 PM, Roger Marshall wrote: > Hannes: > Thanks for the feedback. Will check with Andrea as to his availability f= or the ecrit-service-urn-policy draft. >=20 > The updated agenda moves the eCall slot to optional (10 min in lieu of ch= oice of discussion at end), and bumping up the draft-winterbottom-ecrit-pri= v-loc time to 20 min. >=20 > The updated agenda is at the following: > http://www.ietf.org/proceedings/84/agenda/agenda-84-ecrit.txt >=20 > -roger marshall. >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 > Sent: Wednesday, July 18, 2012 4:07 AM > To: Roger Marshall > Cc: Hannes Tschofenig; ecrit@ietf.org > Subject: Re: [Ecrit] IETF84 - ECRIT agenda posted, comments? >=20 > Hey Roger,=20 >=20 > looks like a good start.=20 >=20 > Is Andrea going to be at the meeting to talk about ?=20 >=20 > I would like to mark the eCall draft as optional and discuss it only if t= ime permits. The allocated agenda time would then be moved to draft-winterb= ottom-ecrit-priv-loc (which then gives it 20min discussion time instead of = 10min, which I think is far too short). draft-winterbottom-ecrit-priv-loc h= ad gotten feedback on the list and the eCall draft hasn't.=20 >=20 > Ciao > Hannes >=20 > On Jul 18, 2012, at 8:15 AM, Roger Marshall wrote: >=20 >> The ECRIT proposed agenda has been uploaded and can be viewed at: >> http://www.ietf.org/proceedings/84/agenda/agenda-84-ecrit.txt >>=20 >> Please send your comments for change before the start of IETF84. >> Regards, >> Roger Marshall & Marc Linsner, ECRIT Chairs >>=20 >> CONFIDENTIALITY NOTICE: The information contained in this message may be= privileged and/or confidential. If you are not the intended recipient, or = responsible for delivering this message to the intended recipient, any revi= ew, forwarding, dissemination, distribution or copying of this communicatio= n or any attachment(s) is strictly prohibited. If you have received this me= ssage in error, please notify the sender immediately, and delete it and all= attachments from your computer and network. >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Mon Jul 30 00:22:12 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E86711E809A for ; Mon, 30 Jul 2012 00:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.608 X-Spam-Level: X-Spam-Status: No, score=-106.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwYRRvyryLaj for ; Mon, 30 Jul 2012 00:22:11 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6945A11E808A for ; Mon, 30 Jul 2012 00:22:11 -0700 (PDT) Received: from [128.89.254.184] (port=65003) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SvkIo-000Nuw-La; Mon, 30 Jul 2012 03:22:06 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188012121E17004@SISPE7MB1.commscope.com> Date: Mon, 30 Jul 2012 00:22:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4A9F73ED-708D-4D3F-83A5-DB2315A0B2A4@bbn.com> References: <18E3CF29-296D-4942-B254-1745978CA84D@bbn.com> <5A55A45AE77F5941B18E5457ECAC8188012121E17004@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1278) Cc: "A.Seus@telekom.de" , "ecrit@ietf.org Org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 07:22:12 -0000 The LIS provides a location value as a fail-safe, in case (for some = reason) the endpoint fails to use the local LoST server. And as Brian points out, there is no point in refusing to return any = location at all. It's a trivial amount of effort to provide it, and not = providing it means that people will just get the same information = elsewhere (Quova, RIPE, etc.), with less assurance as to its quality. = That's just spiteful. --Richard On Jul 29, 2012, at 6:51 PM, Winterbottom, James wrote: > Hi Richard, >=20 > If the LIS is returning a PSAP URI and a location URI, why does it = need to return any location value at all? >=20 > It is important to note that the end-point in the scenarios we are = talking about doesn't get location at all, because it breaks the = requirements if it does. >=20 > Cheers > James >=20 > James Winterbottom > Global Product Manager > Commscope GeoLENs > IP Location Product Portfolio > Suite 1, Level 2, iC Enterprise 1 > Innovation Campus, Squires Way > North Wollongong, NSW, 2500 Australia > Email: james.winterbottom@commscope.com > Phone: +61-2-42-212938 > Mobile: +61-447-773-560 >=20 > www.commscope.com | www.commscopeblogs.com >=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of >> Richard L. Barnes >> Sent: Saturday, 14 July 2012 2:33 AM >> To: Laura Liess >> Cc: A.Seus@telekom.de; ecrit@ietf.org Org >> Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00 >>=20 >> Hi Laura, >>=20 >> Thank you for this clarification. It is very useful in helping to >> understand the problem. >>=20 >> I love your phrase "carrier LoST". That seems to me to be the best >> solution here. It is cheap to deploy (a very simple CGI script), and >> meets two important goals: >> (1) Allowing ISPs to specify particular ESRPs, and >> (2) Not requiring significant modifications to the end client = interface. >>=20 >> This solution doesn't actually require any modification to ECRIT at = all. >> Clients are already required to support LoST discovery, so the = carrier >> LoST server can send them to whatever ESRP the carrier desires. >>=20 >> There's still a need for the LIS to provide *something*, though, so = that >> clients don't say "I don't have any location, so I can't do LoST". = But >> DT's LIS, for example, could just return either a URI or >> DE, which doesn't seem like it would cost them >> anything. >>=20 >> So I'm a little puzzled as to why we're talking about protocol = changes. >>=20 >> --Richard >>=20 >>=20 >>=20 >>=20 >> On Jul 13, 2012, at 9:44 AM, Laura Liess wrote: >>=20 >>> Richard, >>>=20 >>> My understanding is that rough location and the LOST query from the >>> LIS are two different alternatives for two different use cases and >>> both are useful. Please let me know if I am wrong. >>>=20 >>> Rough location is a good choice in countries with dedicated = emergency >>> calling telecommunication infrastructure (and budget dedicated to >>> develop this infrastructure) as ESInet. ESRPs and the LOST-tree are >>> developped by organizations responsible for this infrastructure. A = VSP >>> queries the LIS with the IP-address and gets the rough location and >>> the LbyR, then makes a LOST query with the rough location and gets = the >>> ESRP/PSAP. The ESRP/PSAP queries the LIS with the LbyR and gets the >>> LbyV. The ISP will trust any ESRP/PSAP because they are parts of the >>> emergency service infrastructure. The ISP do not care about LOST. >>>=20 >>> In Germany, without dedicated emergency calling telecommunication >>> infrastructure, ESRPs will be provided by some (large) national >>> carriers. Because they are not paid for this in any way, they are = not >>> willing to provide LOST trees accessible from the Internet or ESRPs >>> which have to query the LISs for every possible ISP. On the other >>> side, small ISPs will not want to have trust relationships with more >>> than one ESRP provider, in general they have an SLA with some large >>> carrier for IP-access anyway. So it is important that the ESRP URI = in >>> the LOST response is ISP-specific. ISPs which are DT customers will >>> get a different LOST response than the Vodafone customers for the = same >>> location in the query. >>> In Germany, I could imagine that a so-called carrier LOST will be >>> developped on the long term. At the beginning ISPs will configure = one >>> ESRP URI and that's it. There is no chance for the development of an >>> open LOST infrastructure accessible from the Internet because there = is >>> nobody there to pay for it. In the current aggreement with the >>> regulator, there is no LOST at all, the LIS is responsible for >>> returning an ESRP URI which is able to query the location. >>>=20 >>> Kind regards >>> Laura >>>=20 >>>=20 >>>=20 >>>=20 >>> 2012/7/12 Richard L. Barnes : >>>> On Jul 11, 2012, at 12:57 PM, Marc Linsner wrote: >>>>=20 >>>>> Richard, >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> I'm going to take a first past at LbyR-in-LoST in a rev of = rough-loc >> in >>>>>> time for the draft deadline, so that we can have a basis for >> discussion >>>>>> in Vancouver. >>>>>>=20 >>>>>> Thanks for getting this conversation started, >>>>>> --Richard >>>>>=20 >>>>> Rough-loc is a WG document that's been through wglc. New ideas = need >> to be >>>>> in a new draft. >>>>>=20 >>>>> -Marc- >>>>=20 >>>>=20 >>>> I'm not sure I agree. Doesn't the current conversation demonstrate >> that rough-loc doesn't solve the problem it was intended to solve? I = was >> taking this thread as very late WGLC comments -- or early IETF LC = comments >> :) >>>>=20 >>>> If you still want me to hold off, let me know and I will. >>>>=20 >>>> --Richard >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@commscope.com Mon Jul 30 17:51:03 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CB321F8527 for ; Mon, 30 Jul 2012 17:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[AWL=-1.211, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBc5TxEkzC8X for ; Mon, 30 Jul 2012 17:51:02 -0700 (PDT) Received: from cdcsmgw02.commscope.com (cdcsmgw02.commscope.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3A21E21F8526 for ; Mon, 30 Jul 2012 17:51:01 -0700 (PDT) X-AuditID: 0a0404e9-b7cf7ae000005816-7f-50172be72b8c Received: from CDCE10HC1.commscope.com ( [10.86.28.21]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 9A.59.22550.7EB27105; Mon, 30 Jul 2012 19:50:48 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 30 Jul 2012 19:51:00 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 31 Jul 2012 08:50:56 +0800 From: "Winterbottom, James" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Bernard Aboba" , 'Brian Rosen' , 'Hannes Tschofenig' Date: Tue, 31 Jul 2012 08:50:54 +0800 Thread-Topic: [Ecrit] ECRIT Direct Thread-Index: Ac1fJe9BUF9a9DSdTuOGHDxCdoVg7APkHITA Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012121E17164@SISPE7MB1.commscope.com> References: <068501cd5f25$ef41716f$5d209f0a@nsnintra.net> In-Reply-To: <068501cd5f25$ef41716f$5d209f0a@nsnintra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_5A55A45AE77F5941B18E5457ECAC8188012121E17164SISPE7MB1co_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: AAAABRlX8ksbeU13G3lNeBt5TXkbej7C Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ECRIT Direct X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 00:51:03 -0000 --_004_5A55A45AE77F5941B18E5457ECAC8188012121E17164SISPE7MB1co_ Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC8188012121E17164SISPE7MB1co_" --_000_5A55A45AE77F5941B18E5457ECAC8188012121E17164SISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Someone has got the wrong end of the stick, ECRIT Direct was never about th= e access provider having to run a SIP proxy, it was about allowing the ESRP= to accept SIP registrations. Cheers James James Winterbottom Global Product Manager Commscope GeoLENs IP Location Product Portfolio Suite 1, Level 2, iC Enterprise 1 Innovation Campus, Squires Way North Wollongong, NSW, 2500 Australia Email: james.winterbottom@commscope.com Phone: +61-2-42-212938 Mobile: +61-447-773-560 [cid:image001.gif@01CD6F0A.5B96AD90] www.commscope.com | www.commscopeblogs.com ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of T= schofenig, Hannes (NSN - FI/Espoo) Sent: Wednesday, 11 July 2012 3:28 PM To: ext Bernard Aboba; 'Brian Rosen'; 'Hannes Tschofenig' Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Direct I agree with both of you. Forcing the access provider to deploy ESRPs was not my idea. In fact, that'= s the proposal put forward by others in ETSI. Instead, ECRIT Direct suggests to send the emergency call directly from the= end device to the PASP/ESRP instead of going through the Voip provider. Ciao Hannes Sent from my Windows Phone ________________________________ From: ext Bernard Aboba Sent: 7/11/2012 12:57 AM To: 'Brian Rosen'; 'Hannes Tschofenig' Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Direct Have to agree with Brian on this. >From a practical point of view, if the access network isn't already a VoIP provider, then you are asking them to provide services in an area in which they have no experience, where there are lives at stake. I doubt that access network providers (such as hotspots) will be enthusiastic about this= , to put it mildly. If the access network is already a VoIP provider, then they already need to provide emergency services for their own customers, so they won't see the need. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, July 10, 2012 2:16 PM To: Hannes Tschofenig Cc: ecrit@ietf.org Org Subject: Re: [Ecrit] ECRIT Direct I think it's a terrible idea to require an access network to operate a SIP proxy server. It's one thing to force it to supply location. It's quite another to force it to be in the call path of an emergency call. It works, technically, with all the limitations of VPNs and other things that totally screw up all of this stuff if you aren't really careful. For example, does the ISP have to serve a call for which it is not the ISP because some VPN is in the path? How about an enterprise? It's just a bad idea in my opinion. Brian On Jul 10, 2012, at 4:14 PM, Hannes Tschofenig wrote: > Hi Richard, Hi Brian, > > I would like to bring this old document back into the discussion since it is relevant IMHO. > In a slightly modified form it provides the features we want as well. > > Here is the doc: > https://raw.github.com/hannestschofenig/tschofenig-ids/master/ecrit-direct/= d raft-winterbottom-ecrit-direct-02.txt > > What do you guys think? > > Ciao > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_5A55A45AE77F5941B18E5457ECAC8188012121E17164SISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Someone has got the wrong end of the s= tick, ECRIT Direct was never about the access provider having to run a SIP proxy,= it was about allowing the ESRP to accept SIP registrations.<= /font>

 

Cheers

James

 

James Winterbottom

Global Product Manager

Commscope GeoLENs

IP Location Product Portfolio

Suite 1, Level 2, iC Enterprise 1

Innovation Campus, Squires Way

North Wollongong, NSW, 2500 Australia=

Email: james.wi= nterbottom@commscope.com

Phone: +61-2-42-212938

Mobile: +61-447-773-560

www.commscope.com |= www.commscopeblogs.com=

 

From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN = - FI/Espoo)
Sent: Wednesday, 11 July 201= 2 3:28 PM
To: ext Bernard Aboba; 'Bria= n Rosen'; 'Hannes Tschofenig'
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] ECRIT D= irect

 

I agree with both of you.

Forcing the access provider to deploy ESRPs was not my idea. In fact, that'= s the proposal put forward by others in ETSI.

Instead, ECRIT Direct suggests to send the emergency call directly from the= end device to the PASP/ESRP instead of going through the Voip provider.

Ciao
Hannes

Sent from my Windows Phone

From: ext Berna= rd Aboba
Sent: 7/11/2012 12:57 AM
To: 'Brian Rosen'; 'Hannes Tschof= enig'
Cc: ecrit@ietf.org<= br> Subject: <= span style=3D'font-size:10.0pt;font-family:Tahoma'>Re: [Ecrit] ECRIT Direct

Have to agree with Brian on this.

>From a practical point of view, if the access network isn't already a VoIP<= br> provider, then you are asking them to provide services in an area in which<= br> they have no experience, where there are lives at stake.  I doubt that=
access network providers (such as hotspots) will be enthusiastic about this= ,
to put it mildly.

If the access network is already a VoIP provider, then they already need to=
provide emergency services for their own customers, so they won't see the need.

-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Tuesday, July 10, 2012 2:16 PM
To: Hannes Tschofenig
Cc: ecrit@ietf.org Org
Subject: Re: [Ecrit] ECRIT Direct

I think it's a terrible idea to require an access network to operate a SIP<= br> proxy server.

It's one thing to force it to supply location.

It's quite another to force it to be in the call path of an emergency call.=

It works, technically, with all the limitations of VPNs and other things that totally screw up all of this stuff if you aren't really careful. = For
example, does the ISP have to serve a call for which it is not the ISP
because some VPN is in the path?

How about an enterprise?

It's just a bad idea in my opinion.

Brian

On Jul 10, 2012, at 4:14 PM, Hannes Tschofenig wrote:

> Hi Richard, Hi Brian,
>
> I would like to bring this old document back into the discussion since= it
is relevant IMHO.
> In a slightly modified form it provides the features we want as well. =
>
> Here is the doc:
>
https://raw.github.com/hannestschofenig/tschofenig-ids/master/ecrit-direct/= d
raft-winterbottom-ecrit-direct-02.txt
>
> What do you guys think?
>
> Ciao
> Hannes
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit

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

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

--_000_5A55A45AE77F5941B18E5457ECAC8188012121E17164SISPE7MB1co_-- --_004_5A55A45AE77F5941B18E5457ECAC8188012121E17164SISPE7MB1co_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=4560; creation-date="Tue, 31 Jul 2012 00:50:54 GMT"; modification-date="Tue, 31 Jul 2012 00:50:54 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhyAAhAHcAACH/C01TT0ZGSUNFOS4wDQAAAAFzUkdCAK7OHOkAIf8LTVNPRkZJQ0U5LjAX AAAAC21zT1BNU09GRklDRTkuMEI8pPUALAAAAADIACEAh/X19QGCtYjY+AC18eP0/nGyzJWTlOXl 5X16e1fL9XVyc97d3RgUFcvr/P7+/qvh+gG48R0ZGkqMqISBguLi4gBqlIyLiwaVzBYSE+34/unp 6dbV1tPu/WxpapHa+aXH1wB9rC6151xaWu3s7CfD9GPO9bPj+mqkvIvG3FRRUhBWdha98vz8/Oj2 /ra1tfr6+vn9/vDw8E1KSwCs7NTx/s7NzUbK9b28vfX9/2ViY6Xe+DnI9Zvd+TUxMnjN7tLR0XzU 9sbi7QFjiz06O0az3EVCQ/D5/sLBwsrJySAcHZqYmbq5ubnl+6qoqdnx/SmaxODr8sTp/NnZ2S4q K8bFxfLy8hyDq4C81GrR+CUhIrXa6wCY0prT7PD1+vj4+DSTt7Kxsq6srfn7/qKgofP6/vz+/wB0 onvW+mhmZt72/qypqe/u7nDQ9rzp/xeKtDAsLTCk0NHj66nU6dbq897y/aelpp+dnZnb9ygkJvz8 /9r0/gGKwDg0NW3E5Bd1mwu78lBNToiFhvT7/li74QF4pwBwnACj4UhFRl9dXhsWF3BtbkA8Pbi2 t0Gu1wJagTo3OPD5/amnqLCurpeWll3Q9hy/9KWjpKSio8Dn+8zLy5uZmqimp8fGx7SyswCh3ACx 8LSztJ+ennd1dvP6/PD6/4+Njtrx+7y7vL++vgwICQqz8EtHSDIvMIF/gImHiBAMDaGfoHJvcF2g uSonKMjHx2JfYCIeH7u6u1JPUFdVVpmXmBCCqxQQEUI/QFpXWPj3+PDv8Hp4eezr6+zr7M/Pz9/f 3+7t7pKQkOjn5/Dv7/f39/v7+9zc3ODg4NHQ0PH5/vLx8vr5+rPQ3PH4+//8++vr65jP6MG/wACu 73TB32+Tpev09xys4/39/SR9oBF8pKHM3tzb29Ha3cfo9dPT0zJzj7Pp/Lzi87i3uPv8/Mjf59TU 1H98ffD6/dfv+/Dw7wB7rw6r4kSky/T09FWjwsTDxNzy+u3t7fHx8Z2bnOP6/6yrq/n6+vn5+XPW +v///wj/AP8JHEhQ4LJlBRMmTLeMhcKHECNKnEhxoIMXFQseRKjQQUEY9pwQwFHQgceMKFMKJDcJ DSAZMnApaoIMYr8jgUTAlIGoVCaJP8C4AMNs4j1QLjod6UawmVAwNSb2uwUKFLp5CQFI6iBjFSAE GyYqOzJBxCqYviagwkjw5DgfPu60iaLlg9041B5SEOqi75ENVRL2W4K0r2HDoJYA+MdijChRdpgW pIIoCwYGmDMz6FHqV8kmhyJgTkSaAYYkKRhBRJSKQaocE5WkwvCqRwyCx2a/eoQ1Ii0MGHglIlYQ yaHRiUxn0QVx2ZgiES6PNp1o1ZKCc4gQuUPHCDgJu/Zs/9lygUgQhZdmA8cQAc+jDjcICrPFa719 4LxsUfhnAZEmSzmUQpAXEyTBgGiJZDFFFslFEAEvKSwwEAWIMJAIgkkkEUGDFiqCj0K+MGBLElMc EJEDuCQyYg/VEORKfrZEgIpE7GBgy4i0EEQLHgwYGEESpIkWiUIbpGBhg3hMAWSPB06gjEBcXDAI AYK0cAIInkCwQwI2kPDJDGfAUFAkDGQRHXAWdhjYPyMoact9672SxAHJiNAJIrWEIcNAwIjAi4FT xCLJBhRIgc4EQxzIi2r/kDPEaQzwEUwYxKxTQySKvNEjBjLsR1A3gKhoCwNDQrROFkmMOIuJAyFg 45vBRP9UxRAR3MjAKQNB00uPWYhyxDqghBoBKxoUdAQrBzJQhAVHhNMMOZGgwWMirLSIwh59wGCE IAXsMUAlZ+jARBRReFDJDDaQQhCZESyCAAKxyJBFj690wFSb7Sny7r7vBjNBFVKgUc9ZUgAiEAAi nJZIB1IoNEIpEeTgUTF8HGhLIDUltIAoP2Kwyj0DHpJID1NgABtEpfAyyxBJZCHhQIpgMEUPiQyx 2EOnJLiIZaAMpEaPtnRC0DwpJILBJgQRM8uFeCjRW0Hk1IKBJP+gEAAROJCBQxzeQlCCAB7w8IAJ DTBRCTYJlDEQmQx0MNALzuTwYyLXsDlFBG8YExEAuRj/MEYd7KQg0AR/RjCJRFQU888vuBw4S3wR WZIhBm4PlEyiLzEwRcYJvXAIL4DkkEgSxA0k9RByR1D3Q7HwwocoSWBgyUAKXKZAQqfQpshAa/Ry IStIRMSCakEEcEED2jqAQpYrlMAGEALcocMDUQgwADYCrI0ZGiWJjsHt99z9hqcQ3SCDJqEccsQ/ SGTIgAUZTXKaLZBLdMmPDPQsEDI9MCDCBJiZnUIyEbtAiKJHVLBICjAwBF1E53YKuUcPMFALJSSH OQKpEAMEKBCPVIERYAieQFrxp1n8ZCIw+EIABlGGdkCiG9n4BAT+YIMEYAF6YXvAA1bwCVXQQCBs 415B/2gBJIOtQXzkg8gClKCEojigFpjJhUMoUg0+REdAFVGAhQ7hBYE0YxYYQMMRRIOIh7SCPbTQ YgTQMZB0HGcI65hCIh6xpoKAwTR2uARm4CeQDmAmEBMpxiwMNIaKgAMee9BBGYwACRYAYQAQgAAJ tuQ86PFAByu4HiWAuL2EDANZQ/jHEfGWRIqQY0RJECFFxsCeRTxtIhRQUiIgtwED5UAZrEhEibKy CAY84hdaTIQaBqKMR/iSBbmw0IwSkgMbFaMOmGHHQAxwmjc4QyIWYM8h2CIRB3wBHheggyCeYQQx mAOSM5xkDZ/nATZEsod0+EcQE6KBNyRiEaJEYkpKgf+BROQCJSHCABYzogjTiEIgSIgO96DIgEsk BBVGu10rMFNIgYygf6E8hu0ScoApMGAV/5BEcmIxoVk4iBVqeJJClrGK5MCiInEgRADgkAEyPIMU z2iHDdAJgUqQoIZYKEEmITCAGfBAnp0syDU2JDhjiG8YKclFcjSREQ304Eely0gntoiQU4jmoLCw kAhOQrt+XmeiGDjGQJrh0T0RQ0N8uA1BLGEa+O0jObUgSBgctKFDTKKU/wiHSfGgOIp8oBABaIRN GQkJMehhBzz9wwoqUYk/oLOoCfhHE5I6EBaIwGitsFsEZmGAOljitKiFxS0ewgoN5agi5NDQIz6E Ein/mPQNNQlDcmLFDDwkYRZJXEPF+PCOf5TCNK4YyDp4ZLAXQCcR1yFIiGxBnBuIxhcFkcQbFIaB N4iiYQNBBVcrUgDEKpYMkGCsGDIgABJEkqeRfO8nQvCPn1FuIN0gh+gyFJU2pUozmkkFLh6SoSkU pSIQTYQMuFkRYNAMD+v4Ryj2yJgUMaCiArkjBkj6j0mYJlYIHVUZ/1EjBkBQIOHg0SEQMsZEAIKs AimGAsDYsVkoYSCbZUBeKyKLCgTgCV0ggxGGPGQy5IEA5vDHDv4Q3/heLwRl+FkEemEBVyggBTxK Ai8mYFE3ATgzAn7IiKbwMoowgjQpkExGipkIPPzg/x/HwIxa/0HNRIiAIB3o5zJZyYDdCWSpDDjZ UiMw24FoAjhYfGsiDuGZhDAjEBXTEAak+Q+6ti0jPQ6AG6CAg/QSucgw6IYYaEAJ+BaVG1Euk4Go g6BgsAVfs2CHBWZNawsEolQJGREewEsRTlyoCCrNyAHeMNqGnfHCAtmAmabgKQkyYAhrCsNlTvYP MGz0H7PaEK7+4YBkZiEs/5CChhYBjbbIxwByfNOQfubPjJygAiAgxAcc8Ol6P+MZYshDqeU7A/r+ DFWZwRsi6ifaN4wgJT0AEsElIgVU7RIlmYhRD5LxD1FcpgkCAVVyMP4PUBgNAQNxAWn+KZA6AAfE //8IhmlA/o8F8CjNMTZpD4oVkXXQKgJDeAEVLmSzilxBCIQAgQQEkYEM1PvTjaWBZYmKDU8QQbMH kkET6hCGerCKIPgaX0oQkRwuVyTbidBfRg6diBR4xI8YiC6ck1rQCLz2H6jYkAxO4mFeJFcg1p1y F/NhmhsLZNgReHhEaoCqCHBiGHezRVQoIg0hIFYI0sgAAVrQAqMf3aYkGMAAvrSFPiD10hHJOmAl cugpB3sifmSAECvCAhkY7e4iOND6BPID2c4DAI/AALAHggRb1IwtgTCNAQaS7SRERWp4OPA/7vGI Wik/Ip/FgB3+UTQMeH0i2/ADvM1QDnekgQ50mHz/5S1vhGeQIfOfwIYhLqCFz6/+IaJPicsNhOuJ MAJoi6dIJ0Znizd3o3G2cEL/0A8iEwE1UAPRcXcrgQeJwAe9oXIM8FK0YxqaUAXbdWcDgQ+L8CMR lgmo4AJXVxAqxwuHc2hJwAohGBGy4HgBIAQSwAF6wAFOYArhJ34ZgANzEA/pZwhb8AQZ4H4SEX8p EQvs0QMpCBFeIDIKdjMSgQzNxwCI4BFeUARtBm4CEQjAYQDURF0EIUjUQnN+lAhhQBAep3o3YDQY 9g/R0FIRkEC5QBtpSBBowAC8cGPVcFWgNxHqIAQVEHSOIAHnEIMcwAHu4ATg1wI4cAKGoH5bsAco /8BJqheE+pQSUuBbDJALdSQRIjcqHcBgCrEGRpIqpTMPfKBLhSUQBORPKcALMjBFf0dsU1BYsbdG BGEMNLMIfiR4/6BxtEhC95UQa3BVEbBa/3Bovjd8EoERJ8CHQScEfnAFmEAD0kgDeqAPpqANZjAD ntCIQAaJ7+cwk5gSEzYqKXCKHIUIAmRxo1ILo5dsMiAiGICM/1AN9jRzBNEPVJgFeJBWBVEFDwZu gNAjnFAQfqSPgZYQISKG/zBGLfN2AxF8w9IiaugLpxEBgeCJBHEDgHAA2+ANzBgAhVAIVkAPKCAH cvABBaACjjAeF7AHAdB+3iiJeHOEFREMf8IArP+gCSmIDLDwCK/ACooDAL6QH5GiCym4AK6QbrwQ C2rmhYVGEBNgIy1jhQJRTLUSPMsgMlxIEFtlK2NYEBoUCv+wDI0TAT1AjGqoBCOyZQSBDIcAKSmg GAWxAaJgC6+ABoKgBX7Ah2YAAgFACBUgBELgCCqgAhVwAS35l1dACmQQk6F3N1PwAyMwmZQ5mfeg ZgrBAuxwIaLBCrXgCvngCjnQPxsSdgJRBWjAHp3pCwhgQLngURrCAAjAYM7AIIuAmeyTKmUHY2NZ gOtTBRuYBebIJq11ggdXELGAGchIBTHyI7nQCgjgegbSCyBDEBQgA3/ya7FwDEoQOFnGC48QB2n/ YA17WQGFEHQBAALqiUh74JKEQAgFIIMtICbz9JgtwwdD8Aj6uZ98UAQ0WRD7wAeqiRnSQRoY0Ato KRBKsF0XkhwBZzSPsA8JQQUPUgS8+QuLwAuv4HcEwQKrQBs9U08YgAdHiAavUC8KoQCvkAqhJRD7 MCpLYiEP0gvhoBDAgABvsiGmEXDskQPikAZR0AZc8AWCaZ7nqZ7qSQhmUAFWkA1t0AYcQABiUgcn Sm0PIQwMKBpfRof6QRHIUAq9sGqjMQspEAq0VRDNYAFFEKMWkgWrYAASaSyPwAeVUxAGUAS4MHoK wAc9wEYHcAiPAAhrkBBLcAjqoxBK0AOcQRBU/5ACozIab8AOx/kQmaAIeBhwrNABdYMDTlA2D3AH g2AFgVmkFVCqFfAN8iAAOhQFUSomoMCnLAcRa3AIQ7AItnqrtzoEh8A5EwEAxLAJBjAJmsAIxcCb WfED+zAJyjooGPk2MRADr9ShxnowwBADXdQN+BADVTCt3YCbA/ELz8qEGfcDYxCsoMCrEaEB15AP ygoLVEBz/0AGBNAAmPAAPOABQDAIcOAGu9CvbvAERMAGAnBJTNAAppABasMPMQAM4toR2YoPEBux ERsD+OCtKnGxGJuxGruxFVEGGdCp9XqvAnAGWEAJCUAJWOAPZxA94hIF7jASHBuzMjuzNFuzKXEB AxlABw0QBSZgr3fgAQIQtB4QNjpgApjQAO6AiDa7tEzbtE6rEmVABi3QqVHABCbQszo0NkxwtFGa AWLytGAbtmLrtN1AdATgBIPYAGrbADJIBy3wDF87tnI7t3SrsWUAA4JgBEVndIKAA2UwrWIbEAA7 --_004_5A55A45AE77F5941B18E5457ECAC8188012121E17164SISPE7MB1co_-- From randy@qualcomm.com Tue Jul 31 13:08:07 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC64721F88D9 for ; Tue, 31 Jul 2012 13:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2Wunt3bG7bo for ; Tue, 31 Jul 2012 13:08:07 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 1136121F88E0 for ; Tue, 31 Jul 2012 13:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1343765288; x=1375301288; h=message-id:x-mailer:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-originating-ip; bh=H/TE+dDiZwal4aq9Iz4AlPefZs6G2hMsMPljZhVt01Y=; b=pqpKNL9yPHXISKAgOYmb95lQsw9r4S1fB0T5NPr3eveKzrUb+oMCB3SK GyXAFYtYEPWjYCRljSVGKmnOhC1lrDNCt90dCaDpqmB71FCRoBZT35Jhe MzYoubWKrT1z/iezc+zaZBiDDoKudxHnbjVAPDfCrlv4hEmoexQzebdBP Y=; X-IronPort-AV: E=McAfee;i="5400,1158,6789"; a="214134260" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 31 Jul 2012 13:07:50 -0700 X-IronPort-AV: E=Sophos;i="4.77,688,1336374000"; d="scan'208";a="294928263" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 31 Jul 2012 13:07:50 -0700 Received: from [208.181.207.156] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 31 Jul 2012 13:07:49 -0700 Message-ID: X-Mailer: Eudora for Mac OS X Date: Tue, 31 Jul 2012 13:07:47 -0700 To: From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] Subject: [Ecrit] additional comments on additional-data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:08:08 -0000 We need a way to label the URI, perhaps as a sub-part to the 'purpose' parameter, to indicate which blocks are available at that URI, such as device data. That can provide a hint as to what is attached. Currently, for an entity handling the call to verify that any specific type of data is attached (e.g., crash data in the eCall case) requires following every item of additional data that is attached and checking its MIME type. I think a parameter in the Call-Info header identifying the type of data would be useful so, for example, crash data can be quickly identified and loaded. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Whenever you find that you are on the side of the majority, it is time to reform. --Mark Twain From randy@qualcomm.com Tue Jul 31 13:11:32 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D07821F88A9 for ; Tue, 31 Jul 2012 13:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAQ7Wq-bVViW for ; Tue, 31 Jul 2012 13:11:31 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4D421F87FE for ; Tue, 31 Jul 2012 13:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1343765492; x=1375301492; h=message-id:x-mailer:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-originating-ip; bh=HyMpUTNetL2f/TsK/17hCEuSNC3hEO0HBxuBFfLHM/s=; b=Oy6w1gIHuuCZiX2DesHIsqkWpKZGZj7V/VkGXFIFIz7n1A2uuYqM8P/n QCJxsUcSPfeRkGsFdnpJF0ljgLHNT2pN1JUBdu/6T+Fz14usyJTxCWpH2 Vyxta4I1O+k6+Yjyo4Oz21qaQDlunPtctoCD6/Laj3qSklJqZpk6+W1IB U=; X-IronPort-AV: E=McAfee;i="5400,1158,6789"; a="214135337" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 31 Jul 2012 13:11:32 -0700 X-IronPort-AV: E=Sophos;i="4.77,689,1336374000"; d="scan'208";a="356886520" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 31 Jul 2012 13:11:32 -0700 Received: from [208.181.207.156] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 31 Jul 2012 13:11:30 -0700 Message-ID: X-Mailer: Eudora for Mac OS X Date: Tue, 31 Jul 2012 13:11:28 -0700 To: From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] Subject: [Ecrit] comments on ecrit-ecall-06 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:11:32 -0000 - The draft proposes a new URI which is not an SOS URI, meaning that emergency calls from vehicles won't look like other emergency calls. Specifically, 'urn:service:ecall' and the ':manual' and ':automatic" children of these for when it's known. Other emergency calls use 'urn:service:sos' with many possible children such as ":police" and ":fire" for when these are known. I think eCall calls should be under the 'sos' URN, so such calls can be routed identically as other emergency calls by the VSP. The ESInet or PSAP can then route specially based on eCall support. - The draft puts the burden on the VSP to route eCall properly. If, instead, a 'sos' URN is used, the VSP can process the call exactly as any other emergency call, and leave it to the ESInet and PSAP to handle it specially. - Current text says this provides "notification" to the PSAP that a vehicle has crashed, with a voice channel as secondary intent. I'd suggest that this be reversed -- the primary goal is a voice channel to the PSAP, with crash data. If there is no expectation of a voice channel, this is a "non-human-associated" (a/k/a "data-only") emergency call and handled per that draft. - The draft proposes using caller preferences, such as 'Accept-Language' as a hint as to which language the caller speaks, so the ESInet or PSAP can route or bridge in a translator. I think a per-media SDP parameter containing an IANA language tag makes more sense, since that allows the specific language, including any form of sign language, to be specified per media stream (these already exist in the registry). One possibility is to extend the RFC 4796 established 'content' registry to contain a 'language' attribute, but a new SDP parameter that is explicitly part of SDP offer-answer might be better; I am not sure which is optimal here, but I think whatever it is needs to be per-media and in SDP. - We need to allow for different name spaces of crash data, since it is not yet clear if there is to be one global or one per-region or one minimal global plus region-specific supplement sets of data. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- One's need for loneliness is not satisfied if one sits at a table alone. There must be empty chairs as well. --Karl Kraus From laura.liess.dt@googlemail.com Tue Jul 31 15:13:11 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3488B11E812C for ; Tue, 31 Jul 2012 15:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErH0HkUf2qqK for ; Tue, 31 Jul 2012 15:13:10 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA9611E812F for ; Tue, 31 Jul 2012 15:13:10 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so6782733vcb.31 for ; Tue, 31 Jul 2012 15:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=JGEeG4QjjwzQ4jgzB50DsfnFr7dKd+DDSOIGv09CVvA=; b=hVU7fzOpEX4Th8b6tfvnIyhy7e3+Gbda+iRGvp9Ui/nOcp0UlyZiplrEuCLvShEHr9 FDHpb1s8AQo6FP2IKES3fS3zA/GUJZLYEliLoMeoWrCMk+ZcaENIyrNkMt2xr2ZVmuCC +q73Ck3iwjISyXIbpn9BJtNXbzgKQSCrqplZvuNW4SKMMA1MmCDiy/0WM1N7wf9OwjRq jtBKLHsaUkgOe951gOa0lrjsOJkrzVITjSYtESd8Fs0sMAEipJsXfkSKornGp8zYLXc0 WWn4cgOmTFCHSX7iDmgGZsd+9yvarYpMtcz25hs6VjLu9vrlL7VDgzOzNw4Jxz2gapJ/ GFNg== MIME-Version: 1.0 Received: by 10.52.95.203 with SMTP id dm11mr13458253vdb.70.1343772789751; Tue, 31 Jul 2012 15:13:09 -0700 (PDT) Received: by 10.58.76.194 with HTTP; Tue, 31 Jul 2012 15:13:09 -0700 (PDT) Date: Wed, 1 Aug 2012 00:13:09 +0200 Message-ID: From: Laura Liess To: Brian Rosen , Richard Barnes , ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Ecrit] Rough location vs. HELD extension for Germany and ETSI X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 22:13:11 -0000 Hi, The rough location proposal is not usefull for Germany, because a VSP as Skype will not find any local LOST to query. There will be no LOST infrastructure publicaly available because there is nobody there to provide it. On the other side, every ISP will either have its own ESRP or have some partner ESRP in the same jurisdiction with an ESRP which will dereference the location reference, find out the local PSAP using an internal LOST and route the call to the PSAP. All that is needed is a HELD extenssion to return the ESRP URI to the VSP. It's simple, it works, the ESRP and the LIS have a security relationship, so no security problem. Everybody is happy. Maybe there are other countries where the rough location is the way to go. So why not continue with both proposals? Thanks Laura From mlinsner@cisco.com Tue Jul 31 15:38:45 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C42811E813A for ; Tue, 31 Jul 2012 15:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joFMo9e9lLLm for ; Tue, 31 Jul 2012 15:38:44 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id A882811E8129 for ; Tue, 31 Jul 2012 15:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=1586; q=dns/txt; s=iport; t=1343774324; x=1344983924; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=q3mQhTtQt1xsvD6BanJ4aD5+ECnAtG4uuK8aQbCYE20=; b=H7cou5tgGOROzj/IXrRFbGEfUzMP2XnVI28/Hzz7oSsmide5s2ahzaQj CHZaRzEbst8YjAWzAFteq8ALFKBJJ0zsPag6YeoGvh2I81UM33dIDL1/m NvF5IIatMDZn0rre581SB3APqiaBVBpLDxj7RrRD53wNnX/YdSL1wVMfv g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALZdGFCrRDoJ/2dsb2JhbABFuXuBB4IgAQEBBAEBAQ8BJwIBMQMBEwcIEQMBAlYoCAYBEiKHXAMLDJtZlwoNiUoEimJnhwkDlUeFW4hMgWaCew X-IronPort-AV: E=Sophos;i="4.77,689,1336348800"; d="scan'208";a="50577265" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 31 Jul 2012 22:38:44 +0000 Received: from [10.21.147.179] (sjc-vpn7-947.cisco.com [10.21.147.179]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6VMcga5030433; Tue, 31 Jul 2012 22:38:43 GMT User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Tue, 31 Jul 2012 18:38:41 -0400 From: Marc Linsner To: Laura Liess , Message-ID: Thread-Topic: [Ecrit] Rough location vs. HELD extension for Germany and ETSI In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Ecrit] Rough location vs. HELD extension for Germany and ETSI X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 22:38:45 -0000 Laura, This brings up 2 questions: 1) What happens when a UA 'roams' into Germany using a VSP located outside of Germany? 2) You state "every ISP will either have its own ESRP or have some partner ESRP". Does this include free WiFi hotspot providers (like Starbucks, McDonalds, etc.)? Thanks, -Marc- -----Original Message----- From: Laura Liess Date: Tuesday, July 31, 2012 6:13 PM To: Brian Rosen , Richard Barnes , Subject: [Ecrit] Rough location vs. HELD extension for Germany and ETSI >Hi, > >The rough location proposal is not usefull for Germany, because a VSP >as Skype will not find any local LOST to query. There will be no LOST >infrastructure publicaly available because there is nobody there to >provide it. > > On the other side, every ISP will either have its own ESRP or have >some partner ESRP in the same jurisdiction with an ESRP which will >dereference the location reference, find out the local PSAP using an >internal LOST and route the call to the PSAP. All that is needed is >a HELD extenssion to return the ESRP URI to the VSP. It's simple, it >works, the ESRP and the LIS have a security relationship, so no >security problem. Everybody is happy. > >Maybe there are other countries where the rough location is the way to >go. So why not continue with both proposals? > >Thanks >Laura >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From laura.liess.dt@googlemail.com Tue Jul 31 16:29:12 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C8E11E8169 for ; Tue, 31 Jul 2012 16:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoeD1YZQVreu for ; Tue, 31 Jul 2012 16:29:12 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E921811E8165 for ; Tue, 31 Jul 2012 16:29:11 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6910360vbb.31 for ; Tue, 31 Jul 2012 16:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VSTOaMARsppoIc4HMc88FAvbFi4bSLTf2PvGo/+5+Ls=; b=OUQRlyJpNe6U2kQg2OsuRutJ4RJYhAWMAb/H33SybpqbJs0mGVU7YSH+evxxnL1i4f 4qrXoGcsV/Cuve8vFZ0IR14t0ZANGpflAbYLVLjWRN6KzYatpaPrfKQcUwjTHZXxBwII EK/LbFKw0RvKE5poVlU2vhaHjUsoXN5XJME90CIgv83C9S0vIWC+dnE2Ql/qPEGB2n9Y sJ1RIGGJrkHoumP/5xl2bNQ/Ae1ovGtRh8f3a5PbabM9Yg66/WhoCW/jsjKXv5ZTDj0u +TtLuLdzzHLE8Rka1GhzAEbLBiRtR4gt6KPKvZaugRifMUS/wuzVMgiPAPDlZVM4xgzr JPqA== MIME-Version: 1.0 Received: by 10.220.108.15 with SMTP id d15mr15525663vcp.37.1343777351458; Tue, 31 Jul 2012 16:29:11 -0700 (PDT) Received: by 10.58.76.194 with HTTP; Tue, 31 Jul 2012 16:29:11 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 01:29:11 +0200 Message-ID: From: Laura Liess To: Marc Linsner Content-Type: text/plain; charset=ISO-8859-1 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Rough location vs. HELD extension for Germany and ETSI X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 23:29:12 -0000 Hi Mark, Please see inline. 2012/8/1 Marc Linsner : > Laura, > > This brings up 2 questions: > > 1) What happens when a UA 'roams' into Germany using a VSP located outside > of Germany? The VSP detects the UA's IP-address, queries the reverse DNS/DNS and finds out ISP's domain and the LIS. Then the VSP sends a HELD query to the LIS. The LIS responds with the LybR and ESRP URI. The VSP sends the INVITE including the LybR to the ESRP. ESRP dereferences the LybR using a secure connection with mutual authentication to the LIS, queries its own internal LOST to find out the local PSAP and sends the call to the PSAP. > > 2) You state "every ISP will either have its own ESRP or have some partner > ESRP". Does this include free WiFi hotspot providers (like Starbucks, > McDonalds, etc.)? Small ISPs get Internet access from one of the big carrier as DT or Vodafone. The big carriers will provide the ESRPs,each for the ISPs which are its own customers. So, if Starbucks has connectivity from DT, it will use DT's ESRP. (We already agreed on this with the regulator.) Starbucks has to run a LIS and return sip:esrp.telekom.de (this means Starbucks has a very trivial LOST table with one entry). esrp.telekom.de has a https connection to the Starbucks LIS to dereference the LybR. Thank you Laura > > Thanks, > > -Marc- > > > > -----Original Message----- > From: Laura Liess > Date: Tuesday, July 31, 2012 6:13 PM > To: Brian Rosen , Richard Barnes , > > Subject: [Ecrit] Rough location vs. HELD extension for Germany and ETSI > >>Hi, >> >>The rough location proposal is not usefull for Germany, because a VSP >>as Skype will not find any local LOST to query. There will be no LOST >>infrastructure publicaly available because there is nobody there to >>provide it. >> >> On the other side, every ISP will either have its own ESRP or have >>some partner ESRP in the same jurisdiction with an ESRP which will >>dereference the location reference, find out the local PSAP using an >>internal LOST and route the call to the PSAP. All that is needed is >>a HELD extenssion to return the ESRP URI to the VSP. It's simple, it >>works, the ESRP and the LIS have a security relationship, so no >>security problem. Everybody is happy. >> >>Maybe there are other countries where the rough location is the way to >>go. So why not continue with both proposals? >> >>Thanks >>Laura >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit > > From mlinsner@cisco.com Tue Jul 31 17:21:55 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEAD721F889C for ; Tue, 31 Jul 2012 17:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NB2zQ4gGRQWj for ; Tue, 31 Jul 2012 17:21:55 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0E42821F888F for ; Tue, 31 Jul 2012 17:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=840; q=dns/txt; s=iport; t=1343780515; x=1344990115; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=p1y3OJllS+bkRbhRisXTvE79BWsgHO2nKbVjuDILBOU=; b=U/XDRVkTNIJ5qTBtZGoNwEhOa6dQj5ZHtCKpumpwXg8sSl7bFw3cHg0y 2bUe8aKGwnZM9cy69qSyRnx52gv7wYAiL26azNZdJdluYnmaD7w0jH10U v8p4unbgSAtEABW035mvCWCdb+qPYzzB4w4gd3qyJeKbrLuj1n5QnzB2e s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGN2GFCrRDoH/2dsb2JhbABFuXyBB4InEgEnAgE8EwiBHQYOJ4dqm2mPFpFGklIDlUeFW4hMgWaCew X-IronPort-AV: E=Sophos;i="4.77,690,1336348800"; d="scan'208";a="53618478" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 01 Aug 2012 00:21:54 +0000 Received: from [10.21.72.83] ([10.21.72.83]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q710LrwM002229; Wed, 1 Aug 2012 00:21:54 GMT User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Tue, 31 Jul 2012 20:21:52 -0400 From: Marc Linsner To: Laura Liess Message-ID: Thread-Topic: [Ecrit] Rough location vs. HELD extension for Germany and ETSI In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] Rough location vs. HELD extension for Germany and ETSI X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 00:21:56 -0000 Laura, >> >> 1) What happens when a UA 'roams' into Germany using a VSP located >>outside >> of Germany? > >The VSP detects the UA's IP-address, queries the reverse DNS/DNS and >finds out ISP's domain and the LIS. Then the VSP sends a HELD query to >the LIS. The LIS responds with the LybR and ESRP URI. The VSP sends >the INVITE including the LybR to the ESRP. ESRP dereferences the LybR >using a secure connection with mutual authentication to the LIS, >queries its own internal LOST to find out the local PSAP and sends the >call to the PSAP. I was thinking about the case where a UA from another country, like the USA, roams into Germany and uses a VSP that is not part of the German domain of VSPs? (not part of the German domain of VSPs = doesn't understand the unique German procedure(s)) Thanks, -Marc-