From ecrit-bounces@ietf.org Sun Mar 2 09:54:47 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 956243A6E1C; Sun, 2 Mar 2008 09:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.659 X-Spam-Level: X-Spam-Status: No, score=-0.659 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0UnneN-sm1X; Sun, 2 Mar 2008 09:54:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21B753A6E2C; Sun, 2 Mar 2008 09:54:40 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 851523A6E21 for ; Sun, 2 Mar 2008 09:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLCVCDnJL8pA for ; Sun, 2 Mar 2008 09:54:38 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DC4B03A6866 for ; Sun, 2 Mar 2008 09:54:28 -0800 (PST) Received: (qmail invoked by alias); 02 Mar 2008 17:54:19 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp046) with SMTP; 02 Mar 2008 18:54:19 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19LwTwqZohLFQdiNA2UpCC5uJm3TeC8KP9w2TS6gP cLYyfBE4ZGZr/K Message-ID: <47CAE9CA.9010901@gmx.net> Date: Sun, 02 Mar 2008 19:54:18 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a Last Call for comments on http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-04 Because of the timing of the impending IETF meeting and the interactions with other SDOs, we are setting the call for **4 weeks**. Please have your comments in no later than March 30. Do remember to send a note in if you have read the document and have no other comments other than "its ready to go" - we need those as much as we need "I found a problem". Thanks! Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 2 09:54:55 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEDE93A6CA7; Sun, 2 Mar 2008 09:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.657 X-Spam-Level: X-Spam-Status: No, score=-0.657 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeWeumUfI8PI; Sun, 2 Mar 2008 09:54:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DDE43A6DED; Sun, 2 Mar 2008 09:54:48 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426F83A69EB for ; Sun, 2 Mar 2008 09:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXr0G6PZJR2A for ; Sun, 2 Mar 2008 09:54:43 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 48BDB3A6CA7 for ; Sun, 2 Mar 2008 09:54:41 -0800 (PST) Received: (qmail invoked by alias); 02 Mar 2008 17:54:32 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp040) with SMTP; 02 Mar 2008 18:54:32 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+ux1Ublx2um3KFBz92RF+zc1D+5ja1lpcA8gzy+y h94a5ROpN5RKg+ Message-ID: <47CAE9D4.9080702@gmx.net> Date: Sun, 02 Mar 2008 19:54:28 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] WGLC on draft-ietf-ecrit-framework-05 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a Last Call for comments on http://tools.ietf.org/html/draft-ietf-ecrit-framework-05 Because of the timing of the impending IETF meeting and the interactions with other SDOs, we are setting the call for **4 weeks**. Please have your comments in no later than March 30. Do remember to send a note in if you have read the document and have no other comments other than "its ready to go" - we need those as much as we need "I found a problem". Thanks! Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 2 12:29:34 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AD7F28C3D4; Sun, 2 Mar 2008 12:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.543 X-Spam-Level: X-Spam-Status: No, score=-1.543 tagged_above=-999 required=5 tests=[AWL=-1.406, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJzOHJm49vaC; Sun, 2 Mar 2008 12:29:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3777F28C37F; Sun, 2 Mar 2008 12:29:33 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 575C728C31D for ; Sun, 2 Mar 2008 12:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkemD69+BgiV for ; Sun, 2 Mar 2008 12:29:26 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.113]) by core3.amsl.com (Postfix) with ESMTP id 52D2328C351 for ; Sun, 2 Mar 2008 12:29:25 -0800 (PST) Received: (qmail 93106 invoked from network); 2 Mar 2008 20:29:13 -0000 Received: from s34.loopia.se (HELO s128.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 2 Mar 2008 20:29:13 -0000 Received: (qmail 8885 invoked from network); 2 Mar 2008 20:29:11 -0000 Received: from h240n1fls34o265.telia.com (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[213.64.232.240]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with SMTP for ; 2 Mar 2008 20:29:11 -0000 From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "'Hannes Tschofenig'" , References: <47CAE9CA.9010901@gmx.net> Date: Sun, 2 Mar 2008 21:29:23 +0100 Message-ID: <003e01c87ca4$1a8b32b0$211ea8c0@GunnarH> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ach8jnry6OMvo0p9TJyaL5tZ3OssxAABJ4Nw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <47CAE9CA.9010901@gmx.net> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hannes, I have read the phonebcp draft and think it is good. I have seen one problem. = In section 13, it says: ED-67/SP-37 User Agents and proxys MUST disable outgoing call features such as .... o Three Way Call = Problem: ----------- If users have the habit of including some kind of support for making calls through a three-party arrangement, they will suddenly discover that this habit is blocked in an emergency situation. That could be fatal. Three-way calling initiated by the calling user may for example be used to invoke relay services by people with disabilities. People with speech impairments may invoke a speech-to-speech relay service that can support the PSAP in understanding their way of talking. Text relay services and sign language relay services may also be invoked in this way. There are other ways to invoke relay services, but if a habit to invoke them by three-way calling is established, it is important to allow it also in the emergency situation. Questions: 1. Have I understood the restriction right that the situation I describe would not be allowed? 2. Why is that restriction taken in? 3. Can the restriction be deleted? 4. Relay service invocation can be done in many ways. RFC 4117 describes some, involving three-party call control. Please make sure that the users are not blocked from using these methods in emergency call establishment as well as call-backs. = The same comment is valid for section 13 in the ecrit-framework draft. So please regard this comment valid for both drafts. Sorry for not bringing this up earlier, I hope it will not disturb the approval process of theese good and important drafts. Thanks = Gunnar ------------------------------------------------------------------- Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se Tel: +46708204288 www.omnitor.se -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 02, 2008 6:54 PM To: ecrit@ietf.org Subject: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 This is a Last Call for comments on http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-04 Because of the timing of the impending IETF meeting and the interactions with other SDOs, we are setting the call for **4 weeks**. Please have your comments in no later than March 30. Do remember to send a note in if you have read the document and have no other comments other than "its ready to go" - we need those as much as we need "I found a problem". Thanks! Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit __________ NOD32 2913 (20080301) Information __________ Detta meddelande dr genomsvkt av NOD32 Antivirus. http://www.nod32.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 2 20:37:58 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B871F28C478; Sun, 2 Mar 2008 20:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[AWL=-0.682, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3m8yNhC-evn; Sun, 2 Mar 2008 20:37:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ADE028C419; Sun, 2 Mar 2008 20:37:53 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D8D33A6973 for ; Sun, 2 Mar 2008 20:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7aKOeT4Gjdt for ; Sun, 2 Mar 2008 20:37:49 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D3DB128C419 for ; Sun, 2 Mar 2008 20:37:48 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m234bCMV026013; Mon, 3 Mar 2008 06:37:36 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Mar 2008 06:37:11 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Mar 2008 22:37:09 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 2 Mar 2008 22:37:09 -0600 Message-ID: In-Reply-To: <47CAE9CA.9010901@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 Thread-Index: Ach8jolv/STC1rK7RIKB7KJgoR54QAASL2dg References: <47CAE9CA.9010901@gmx.net> From: To: , X-OriginalArrivalTime: 03 Mar 2008 04:37:09.0143 (UTC) FILETIME=[3DD11A70:01C87CE8] X-Nokia-AV: Clean Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Few comments below: 1. The title of the document does not explicitely say that this document is about "VoIP" emergency calls. Suggestion: add "VoIP" to the title (... Communications Services in support of VoIP Emergency Calling) 2. The title of the documents says "Best Current Practice for ...", while the document is not a collection nor a subset of the currently used practices for emergency calling. And there is no 'current practice' for VoIP emergency calling yet, thus a 'best current practice' of yet nonexisting practices is confusing. Suggestion: change the title eg to "Requirements for Communication Services in support of VoIP Emergency Calling" (and revise the abstract section accordingly) 3. "ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the Request-URI of the INVITE." Marked by whom, the endpoints, the proxies or both? Clarify 4. "ED-5/SP-4 Local dial strings MUST be recognized." and "ED-6/SP-5 Home dial strings MAY be recognized." Recognized by whom? Clarify 5. "ED-10 Devices SHOULD NOT have one button emergency calling initiation." While I understand that the intention is to discourage vendors to design devices with a button dedicated only for emergency calls, current mobile phones have the possibility of 'speed dial', when a preset dial string (including 112 or 911) can be assigned to any button. Requirement ED-10 can be also read to ban this feature in the phone. Clarify. I do not have a suggestion, but as today's devices do not have such a dedicated red button any more, I see no value in this requirement, it just creates confusion. 6. "ED-11/SP-9 All emergency services specified in [I-D.ietf-ecrit-service-urn] MUST be recognized." Recognized by whom? Clarify. 7. "6.1. Types of location information There are several forms of location. In IETF protocols , civic and geospatial (geo) forms are both supported." The term "IETF protocols" is too broad. UDP/TCP/DNS/ARP etc. are all 'IETF protocols', but they do not support location. Be more specific. 8. section 6.1 "Other forms of location representation must be mapped into either a geo or civic for use in emergency calls." Currently most mobile network carriers use cell-id for directing the call to the correct psap. That technique will not go away for yet a long time. While cell-id could be mapped into either civic or geo, there is no added value in doing so, as cell-id based routing serves the purpose just as well as civic or geo based routing. I would suggest relaxing the requirement, otherwise the draft will go against current practices. 9. "ED-17/INT-8/AN-7 Devices that support endpoint measuring of location MUST have at least a coarse location capability (typically <1km accuracy when not location hiding) at all times for routing of calls." I do not understand the text in the brackets. What is location hiding (add reference to it) and what happens when it is applied, will the req become n/a? clarify. Same comment for AN-9 10. same paragraph as above. "This mechanism MAY be a service provided by the access network." It is not clear what 'this mechanism' refers to. 11. "AN-8 Access networks MAY provide network-measured location determination. Wireless access network which do not support network measured location MUST require that all devices connected to the network have end-system measured location. " What kind of wireless access networks are we talking about? Commercial, public, private, academic or all of them? I could hardly believe that a free public network like the google one in Mountain View (which does not support network measured location) would have a means to restrict my laptop's access (which does not have an end-system measured location). Suggestion: be more specific. Say 'commercial wireless access networks' or 'subscription based wireless access networks'. It has to be a managed network, otherwise nothing can be enforced. 12. "ED-27/INT-20 If the device sends a DHCP INFORM message" The text should say 'DHCPINFORM' (no space between, rfc2131). 13. "ED-28/INT-21 To minimize the effects of VPNs that do not allow split tunneling VPNs, location configuration SHOULD be attempted before such tunnels are established." Add reference to 'split tunneling VPNs'(if exists). If there is no reference, then be more explicit. Say that using an LCP while on a VPN may result in getting the location of the vpn gateway. Avoid using non-defined terms. 14. "ED-47 Endpoints MUST support one or more mechanisms that allow them to determine their public IP address. Examples include ICE ..." It should be STUN instead of ICE. 15. " ED-68/SP-38 The emergency dialstrings SHOULD NOT be permitted in Call Forward numbers or speed dial lists." There is no such regulatory requirement in place. Vendors comply with regulatory requirements when it comes to emergency services. This draft is not an amendment to any regulatory document, thus this requirement is inappropriate. Remove it. 16. general comment: the draft seem to focus on 802.11 access networks. The term "access point" is used all over. Access networks other than wi-fi use terms like base station, rnc, node-b, etc. If the draft is meant to be applicable to access networks other than wi-fi, then a more generic term should be used instead of 'Access Point'. - gabor -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Hannes Tschofenig Sent: Sunday, March 02, 2008 9:54 AM To: ecrit@ietf.org Subject: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 This is a Last Call for comments on http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-04 Because of the timing of the impending IETF meeting and the interactions with other SDOs, we are setting the call for **4 weeks**. Please have your comments in no later than March 30. Do remember to send a note in if you have read the document and have no other comments other than "its ready to go" - we need those as much as we need "I found a problem". Thanks! Hannes & Marc _______________________________________________ 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 ecrit-bounces@ietf.org Mon Mar 3 00:29:46 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9550B3A6F4D; Mon, 3 Mar 2008 00:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=-3.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pb+UDca8FGln; Mon, 3 Mar 2008 00:29:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B875428C32A; Mon, 3 Mar 2008 00:29:42 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57983A6E56 for ; Mon, 3 Mar 2008 00:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hkKym+TQjGk for ; Mon, 3 Mar 2008 00:29:39 -0800 (PST) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 88F9728C52D for ; Mon, 3 Mar 2008 00:29:16 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,436,1199664000"; d="scan'208";a="15657223" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 03 Mar 2008 08:29:05 +0000 In-Reply-To: <024e01c87b1c$43c00ea0$640fa8c0@cis.neustar.com> To: ecrit@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Mon, 3 Mar 2008 08:28:33 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 03/03/2008 08:29:05 AM, Serialize complete at 03/03/2008 08:29:05 AM Subject: Re: [Ecrit] Query: How to derive Emergency Call from SIP INVITE Message X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > Generally, the IETF has not spent a lot of time on the specifics of how a > PSAP without an IP connection handles a call that originated in an IP > network. Brian, do you actually mean *no* IP connection, or specifically no SIP connection? The UK's work on an architecture for Emergency Location is based on a PSTN connection to the PSAP with information identifying the VSP and caller carried in SS7. There is however also an out-of-band IP connection from the VSP to the PSAP which carries the source IP address, which is then (by an as yet undecided mechanism) mapped to an access network (ISP) LIS, which is in turn then interrogated with HELD. Ray -- Ray Bellis Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 3 08:30:58 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DE5B28C105; Mon, 3 Mar 2008 08:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.617 X-Spam-Level: X-Spam-Status: No, score=-0.617 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtMVu2Arj126; Mon, 3 Mar 2008 08:30:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 489BA3A69EE; Mon, 3 Mar 2008 08:30:54 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AB663A6A29 for ; Mon, 3 Mar 2008 08:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAtveTt0lMt5 for ; Mon, 3 Mar 2008 08:30:47 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 04E553A67B4 for ; Mon, 3 Mar 2008 08:30:47 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JWDYe-00025t-J4; Mon, 03 Mar 2008 10:30:32 -0600 From: "Brian Rosen" To: , References: <024e01c87b1c$43c00ea0$640fa8c0@cis.neustar.com> Date: Mon, 3 Mar 2008 11:30:35 -0500 Message-ID: <05f601c87d4b$e9f55dd0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Ach9CLf7zVNCAzWCQJWOom1BNHI4ewAQlz4Q In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Query: How to derive Emergency Call from SIPINVITE Message X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The IETF work recognized that there will be nation-specific mechanisms in place to get calls to PSAPs that don't directly take the signaling specified in its documents. Generally, there are no national variations of any Internet protocol. If the device, the access network and the calling network follow the ecrit/geopriv/sip specs, the call will route to some kind of proxy server (we would call this an "emergency services routing proxy"). That proxy, which can get all the information about the call, can forward the call to a gateway to any kind of PSAP you may have. So, in your example, the gateway would provide the SIP to PSTN interwork, as well as the interwork for the (as yet undecided) mechanism to HELD. There is some work in NENA along the same lines, interworking new IETF based devices and networks to older PSAPs. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Ray.Bellis@nominet.org.uk > Sent: Monday, March 03, 2008 3:29 AM > To: ecrit@ietf.org > Subject: Re: [Ecrit] Query: How to derive Emergency Call from SIPINVITE > Message > > Brian Rosen wrote: > > Generally, the IETF has not spent a lot of time on the specifics of how > a > > PSAP without an IP connection handles a call that originated in an IP > > network. > > Brian, do you actually mean *no* IP connection, or specifically no SIP > connection? > > The UK's work on an architecture for Emergency Location is based on a PSTN > connection to the PSAP with information identifying the VSP and caller > carried in SS7. > > There is however also an out-of-band IP connection from the VSP to the > PSAP which carries the source IP address, which is then (by an as yet > undecided mechanism) mapped to an access network (ISP) LIS, which is in > turn then interrogated with HELD. > > Ray > > -- > Ray Bellis > Senior Researcher in Advanced Projects, Nominet > e: ray@nominet.org.uk, t: +44 1865 332211 > _______________________________________________ > 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 ecrit-bounces@ietf.org Mon Mar 3 08:47:22 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95B4B3A6D8A; Mon, 3 Mar 2008 08:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BXL1N6q2Yxb; Mon, 3 Mar 2008 08:47:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A300D28C221; Mon, 3 Mar 2008 08:46:50 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C64DC28C2BD for ; Mon, 3 Mar 2008 08:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yG6im3nFonU for ; Mon, 3 Mar 2008 08:46:44 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id E6CCD28C1AE for ; Mon, 3 Mar 2008 08:45:38 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JWDn1-00035r-V2; Mon, 03 Mar 2008 10:45:24 -0600 From: "Brian Rosen" To: =?iso-8859-1?Q?'Gunnar_Hellstr=F6m'?= , "'Hannes Tschofenig'" , References: <47CAE9CA.9010901@gmx.net> <003e01c87ca4$1a8b32b0$211ea8c0@GunnarH> Date: Mon, 3 Mar 2008 11:45:26 -0500 Message-ID: <05fe01c87d4d$fd4f0ff0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Ach8jnry6OMvo0p9TJyaL5tZ3OssxAABJ4NwAC5bqwA= In-Reply-To: <003e01c87ca4$1a8b32b0$211ea8c0@GunnarH> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think you have the restriction wrong. The idea is that once a 9-1-1 call is in place, you can't then add someone else. The PSAP can, the caller can't. In current POTS phones, we want to disable "FLASH", but the equivalent in more feature phones is the same. The way I propose to handle relay is to treat relay as a "carrier" in the sense that INVITE is forwarded to relay as the outbound proxy. The relay, seeing that it's an emergency call sends the call onward marked with a request to add the relay as a third leg. = We probably should say that. I want the bridge that joins relay to the caller and the PSAP to be the PSAP's bridge, not the relay's bridge. = If a call exists between the relay and the caller it could be referred to the PSAP, with the same request to add the relay to the call. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Gunnar Hellstr=F6m > Sent: Sunday, March 02, 2008 3:29 PM > To: 'Hannes Tschofenig'; ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > = > Hannes, > I have read the phonebcp draft and think it is good. > = > I have seen one problem. > = > In section 13, it says: > = > ED-67/SP-37 User Agents and proxys MUST disable outgoing call > features such as > .... > o Three Way Call > = > Problem: > ----------- > If users have the habit of including some kind of support for making calls > through a three-party arrangement, they will suddenly discover that this > habit is blocked in an emergency situation. That could be fatal. > = > Three-way calling initiated by the calling user may for example be used to > invoke relay services by people with disabilities. People with speech > impairments may invoke a speech-to-speech relay service that can support > the > PSAP in understanding their way of talking. Text relay services and sign > language relay services may also be invoked in this way. > There are other ways to invoke relay services, but if a habit to invoke > them > by three-way calling is established, it is important to allow it also in > the > emergency situation. > = > Questions: > 1. Have I understood the restriction right that the situation I describe > would not be allowed? > 2. Why is that restriction taken in? > 3. Can the restriction be deleted? > 4. Relay service invocation can be done in many ways. RFC 4117 describes > some, involving three-party call control. Please make sure that the users > are not blocked from using these methods in emergency call establishment > as > well as call-backs. > = > The same comment is valid for section 13 in the ecrit-framework draft. So > please regard this comment valid for both drafts. > = > Sorry for not bringing this up earlier, I hope it will not disturb the > approval process of theese good and important drafts. > = > Thanks > Gunnar > ------------------------------------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > Tel: +46708204288 > www.omnitor.se > = > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Sunday, March 02, 2008 6:54 PM > To: ecrit@ietf.org > Subject: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > = > This is a Last Call for comments on > http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-04 > = > Because of the timing of the impending IETF meeting and the interactions > with other SDOs, we are setting the call for **4 weeks**. > = > Please have your comments in no later than March 30. > = > Do remember to send a note in if you have read the document and have no > other comments other than "its ready to go" - we need those as much as we > need "I found a problem". > = > Thanks! > Hannes & Marc > = > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = > __________ NOD32 2913 (20080301) Information __________ > = > Detta meddelande dr genomsvkt av NOD32 Antivirus. > http://www.nod32.com > = > = > _______________________________________________ > 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 ecrit-bounces@ietf.org Tue Mar 4 00:11:52 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D6153A6EA9; Tue, 4 Mar 2008 00:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pNN5KF7OiJ2; Tue, 4 Mar 2008 00:11:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B4C83A6E94; Tue, 4 Mar 2008 00:11:47 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81FC43A6E94 for ; Tue, 4 Mar 2008 00:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgKUTuwdiluw for ; Tue, 4 Mar 2008 00:11:40 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9F4C13A6E8B for ; Tue, 4 Mar 2008 00:11:39 -0800 (PST) Received: (qmail invoked by alias); 04 Mar 2008 08:11:29 -0000 Received: from 81-174-34-167.static.ngi.it (EHLO [192.168.1.70]) [81.174.34.167] by mail.gmx.net (mp021) with SMTP; 04 Mar 2008 09:11:29 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/56XEHhBr5hVPOunEz9okuPWFYGIG0N4urXARcDM admFepmaE3Qg5C Message-ID: <47CD0432.5030103@gmx.net> Date: Tue, 04 Mar 2008 10:11:30 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] [Fwd: DISCUSS: draft-ietf-ecrit-lost] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org -------- Original Message -------- Subject: DISCUSS: draft-ietf-ecrit-lost Date: Mon, 3 Mar 2008 12:24:06 -0800 (PST) From: Tim Polk To: iesg@ietf.org CC: ecrit-chairs@tools.ietf.org, draft-ietf-ecrit-lost@tools.ietf.org Discuss: The introduction suggests that LoST may be appropriate for non-emergency services as well, but does not revisit that notion anywhere else in the document. As noted in Joe Salowey's secdir review, there may be different threats or motivations which could affect the applicability of LoST to such applications. From his review: 3) Use in non-ecrit cases - has much thought been given to the use of LoST in non-Ecrit cases? There may be different threats or at least motivations than those covered in draft-ietf-ecrit-security-threats. For example, in non-ecrit cases an attacker may seek monetary benefit through attacking the LoST protocol to return inaccurate service mapping information. The suggestion here is to either consider this case of non-ecrit in more detail or to state that threats outside ecrit cases may be different. At a minimum, the security considedrations section should note that non-emergency services may face a different set of threats. The requirements for these services should be carefully reviewed to ensure that LoST can be used to achieve the service's security requirements. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 4 05:40:28 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1AA28C430; Tue, 4 Mar 2008 05:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.543 X-Spam-Level: X-Spam-Status: No, score=-1.543 tagged_above=-999 required=5 tests=[AWL=-1.406, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwR853tl2SFc; Tue, 4 Mar 2008 05:40:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01F5D28C51A; Tue, 4 Mar 2008 05:40:24 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FB4F3A6B75 for ; Tue, 4 Mar 2008 05:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPjP0EuM9cE1 for ; Tue, 4 Mar 2008 05:40:18 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.113]) by core3.amsl.com (Postfix) with ESMTP id 89FA728C57C for ; Tue, 4 Mar 2008 05:39:06 -0800 (PST) Received: (qmail 30870 invoked from network); 4 Mar 2008 13:38:53 -0000 Received: from s34.loopia.se (HELO s42.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 4 Mar 2008 13:38:53 -0000 Received: (qmail 89590 invoked from network); 4 Mar 2008 13:38:52 -0000 Received: from unknown (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[217.167.117.109]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with SMTP for ; 4 Mar 2008 13:38:52 -0000 From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "'Brian Rosen'" , "'Hannes Tschofenig'" , References: <47CAE9CA.9010901@gmx.net> <003e01c87ca4$1a8b32b0$211ea8c0@GunnarH> <05fe01c87d4d$fd4f0ff0$640fa8c0@cis.neustar.com> Date: Tue, 4 Mar 2008 14:38:20 +0100 Message-ID: <003a01c87dfd$17fe7890$6d75a7d9@GunnarH> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <05fe01c87d4d$fd4f0ff0$640fa8c0@cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Ach8jnry6OMvo0p9TJyaL5tZ3OssxAABJ4NwAC5bqwAAHgK/IA== Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, I suggest that some words are added to explain why the restrictions in section 13 are needed. I still do not understand why you want to have these limitations. = -- The PSAP can rarely judge what relay to invoke. ---------------------------------------------- The small trial that Omnitor performed last autumn with relay service invocation in emergency SIP multimedia calls showed that we must not expect the PSAP to be able to judge what relay service to involve. That must be either automatic or user initiated. The user would likely have a thoroughly established habit of how the relay is invoked in outgoing calls. It would be best to not deviate from that pattern for emergency calls. It would though be good to let more media through between the user and the PSAP than you usually do in a relay call, where one user usually has only a voice phone. = This comment does not nessessarily mean that I require the restriction about 3-way calls to be deleted. ---------------------------------------------------------------------------- --------- It may be true that most relay service invocation methods will lead to the call coming to the PSAP with two legs of the three party relay call already on the way to be established. = But, is it not also likely that any kind of external support may be wanted in the call, and the user be the one who best knows how to involve that service through a 3-way connection. I do not want to see that restriction just be inserted because of an old habit from PSTN of not accepting flash-hook. = Your relay invocation model may be a bit restricting. ----------------------------------------------------- You suggest that relay service bridges shall be inserted as outbound proxies for the users. There may be some other outbound proxy you need to configure, e.g. for your connectivity to the network. The user may not want that tight relation to its favourite relay service. 99% of the calls may be with friends that are fully capable of handling the same media and modes as the user. So, for the occasional relay call, the user may add a service indicator of some kind, or a number analysis is done that routes the call properly. This discussion is wider than what is suitable for the ecrit group, but it is ccertainly interlinked. I would be interested to sort out some relay calling models, and think that sipping is the right group to host such a discussion. = This whole discussion is not only about relay services, it can be language interpreters and other supporting services as well. Thanks Gunnar ------------------------------------------------------------------- Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se Tel: +46708204288 www.omnitor.se -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] = Sent: Monday, March 03, 2008 5:45 PM To: 'Gunnar Hellstr=F6m'; 'Hannes Tschofenig'; ecrit@ietf.org Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 I think you have the restriction wrong. The idea is that once a 9-1-1 call is in place, you can't then add someone else. The PSAP can, the caller can't. In current POTS phones, we want to disable "FLASH", but the equivalent in more feature phones is the same. The way I propose to handle relay is to treat relay as a "carrier" in the sense that INVITE is forwarded to relay as the outbound proxy. The relay, seeing that it's an emergency call sends the call onward marked with a request to add the relay as a third leg. = We probably should say that. I want the bridge that joins relay to the caller and the PSAP to be the PSAP's bridge, not the relay's bridge. = If a call exists between the relay and the caller it could be referred to the PSAP, with the same request to add the relay to the call. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = > Of Gunnar Hellstr=F6m > Sent: Sunday, March 02, 2008 3:29 PM > To: 'Hannes Tschofenig'; ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > = > Hannes, > I have read the phonebcp draft and think it is good. > = > I have seen one problem. > = > In section 13, it says: > = > ED-67/SP-37 User Agents and proxys MUST disable outgoing call > features such as > .... > o Three Way Call > = > Problem: > ----------- > If users have the habit of including some kind of support for making = > calls through a three-party arrangement, they will suddenly discover = > that this habit is blocked in an emergency situation. That could be fatal. > = > Three-way calling initiated by the calling user may for example be = > used to invoke relay services by people with disabilities. People with = > speech impairments may invoke a speech-to-speech relay service that = > can support the PSAP in understanding their way of talking. Text relay = > services and sign language relay services may also be invoked in this = > way. > There are other ways to invoke relay services, but if a habit to = > invoke them by three-way calling is established, it is important to = > allow it also in the emergency situation. > = > Questions: > 1. Have I understood the restriction right that the situation I = > describe would not be allowed? > 2. Why is that restriction taken in? > 3. Can the restriction be deleted? > 4. Relay service invocation can be done in many ways. RFC 4117 = > describes some, involving three-party call control. Please make sure = > that the users are not blocked from using these methods in emergency = > call establishment as well as call-backs. > = > The same comment is valid for section 13 in the ecrit-framework draft. = > So please regard this comment valid for both drafts. > = > Sorry for not bringing this up earlier, I hope it will not disturb the = > approval process of theese good and important drafts. > = > Thanks > Gunnar > ------------------------------------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > Tel: +46708204288 > www.omnitor.se > = > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = > Of Hannes Tschofenig > Sent: Sunday, March 02, 2008 6:54 PM > To: ecrit@ietf.org > Subject: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > = > This is a Last Call for comments on > http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-04 > = > Because of the timing of the impending IETF meeting and the = > interactions with other SDOs, we are setting the call for **4 weeks**. > = > Please have your comments in no later than March 30. > = > Do remember to send a note in if you have read the document and have = > no other comments other than "its ready to go" - we need those as much = > as we need "I found a problem". > = > Thanks! > Hannes & Marc > = > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = > __________ NOD32 2913 (20080301) Information __________ > = > Detta meddelande dr genomsvkt av NOD32 Antivirus. > http://www.nod32.com > = > = > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit __________ NOD32 2913 (20080301) Information __________ Detta meddelande =E4r genoms=F6kt av NOD32 Antivirus. http://www.nod32.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 4 12:22:14 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4010C28C63B; Tue, 4 Mar 2008 12:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOlxF2li5PML; Tue, 4 Mar 2008 12:22:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C023E3A6BB7; Tue, 4 Mar 2008 12:22:09 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563DD28C3BC for ; Tue, 4 Mar 2008 12:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kT9i5Wu4CH5a for ; Tue, 4 Mar 2008 12:22:07 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id AF5C03A69F0 for ; Tue, 4 Mar 2008 12:22:06 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 04 Mar 2008 12:21:57 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m24KLv3N024470; Tue, 4 Mar 2008 12:21:57 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m24KLpMF003048; Tue, 4 Mar 2008 20:21:57 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Mar 2008 12:21:28 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.149.127]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Mar 2008 12:21:27 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Mar 2008 14:21:25 -0600 To: , , From: "James M. Polk" In-Reply-To: References: <47CAE9CA.9010901@gmx.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 04 Mar 2008 20:21:27.0522 (UTC) FILETIME=[53416420:01C87E35] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9516; t=1204662117; x=1205526117; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20WGLC=20on=20draft-ietf-ecrit- phonebcp-04 |Sender:=20; bh=L9Yy1Q81jQnpwvL16bNCzNFyfVTL/Ye3MO0JdvIKnwQ=; b=mRCm4karV1MbpMXM8F9+6tEQ/S22PXBY3r9lUIRQ2M1t78Kl78ReJ9bfDk NJ0NalPcerXpJViv53oxVeInia+U93FCN0kI/2zyth0dbDkTukXzb4bxsLbs OGltAC/zg8; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Gabor That this document is from the IETF means it involves IP. more in-line below At 10:37 PM 3/2/2008, Gabor.Bajko@nokia.com wrote: >Few comments below: > >1. The title of the document does not explicitely say that this document >is about "VoIP" emergency calls. >Suggestion: add "VoIP" to the title (... Communications Services in >support of VoIP Emergency Calling) Calls are not limited to "voice", even though each are called "calls". >2. The title of the documents says "Best Current Practice for ...", >while the document is not a collection nor a subset of the currently >used practices for emergency calling. And there is no 'current practice' >for VoIP emergency calling yet, thus a 'best current practice' of yet >nonexisting practices is confusing. >Suggestion: change the title eg to "Requirements for Communication >Services in support of VoIP Emergency Calling" >(and revise the abstract section accordingly) While I agree there are no current practices, this document is an effort with a fair degree of interworking amongst emergency calling consortia - and the goal here is to establish an singular architecture, not one of many choices - therefore stating clearly this is "one" practice to be implemented is best. The title does this. The document status is to be Proposed Standard, not Best Current Practice. >3. "ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the > Request-URI of the INVITE." >Marked by whom, the endpoints, the proxies or both? Clarify this is in the document >4. "ED-5/SP-4 Local dial strings MUST be recognized." and "ED-6/SP-5 >Home dial strings MAY be recognized." >Recognized by whom? Clarify What is this document about? (hint: entities supporting this (to be) IETF standard) That's whom. >5. "ED-10 Devices SHOULD NOT have one button emergency calling > initiation." >While I understand that the intention is to discourage vendors to design >devices with a button dedicated only for emergency calls, current mobile >phones have the possibility of 'speed dial', when a preset dial string >(including 112 or 911) can be assigned to any button. Requirement ED-10 >can be also read to ban this feature in the phone. Clarify. Have you not been involved in the emergency calling discussions over the past several years within the IETF or NENA? This "emergency button" was tried and if failed miserably within the US in the late 80s - because of too many false emergency calls because the single button was accidently hit (for example, in a lady's purse). This wrecked havoc on PSAP call takers and first responders. So while this idea sounds great, it doesn't work in practice. If this still needs to be clarified, this can be with a single sentence. >I do not have a suggestion, but as today's devices do not have such a >dedicated red button any more, I see no value in this requirement, it >just creates confusion. it clarifies that one shouldn't ever be thought of again >6. "ED-11/SP-9 All emergency services specified in >[I-D.ietf-ecrit-service-urn] MUST be recognized." >Recognized by whom? Clarify. (hint: entities supporting this (to be) IETF standard) That's whom. >7. "6.1. Types of location information > > There are several forms of location. In IETF protocols , civic and >geospatial (geo) forms are both supported." >The term "IETF protocols" is too broad. UDP/TCP/DNS/ARP etc. are all >'IETF protocols', but they do not support location. Be more specific. In these are to carry location - I think they should consider what's said in this document. To be more specific means to list every protocol that cannot support location and every protocol that might be able to support location. The remainder either is going to or does support location. >8. section 6.1 >"Other forms of > location representation must be mapped into either a geo or civic for > use in emergency calls." >Currently most mobile network carriers use cell-id for directing the >call to the correct psap. Is cell-id a location? If true, is an ALI a location. Both are ids... what's the difference? >That technique will not go away for yet a long >time. While cell-id could be mapped into either civic or geo, there is >no added value in doing so, as cell-id based routing serves the purpose >just as well as civic or geo based routing. Cell-id routing... on IP? I believe you're mixing technologies where mixing shouldn't be done. >I would suggest relaxing the >requirement, otherwise the draft will go against current practices. ...of cellular world infrastructures, which aren't IP based, so there's no reason this requirement addresses the legacy infrastructure. BTW -- I believe IMS (which is cellular based systems) is using PIDF-LO and location-URI references, not cell-ids >9. "ED-17/INT-8/AN-7 Devices that support endpoint measuring of location > MUST have at least a coarse location capability (typically <1km > accuracy when not location hiding) at all times for routing of >calls." >I do not understand the text in the brackets. What is location hiding >(add reference to it) and what happens when it is applied, will the req >become n/a? clarify. I agree location hiding shouldn't be in this document >Same comment for AN-9 > >10. same paragraph as above. "This mechanism MAY be a service provided >by the access network." It is not clear what 'this mechanism' refers to. > >11. "AN-8 Access networks MAY provide network-measured location > determination. Wireless access network which do not support network > measured location MUST require that all devices connected to the > network have end-system measured location. " >What kind of wireless access networks are we talking about? Commercial, >public, private, academic or all of them? I could hardly believe that a >free public network like the google one in Mountain View (which does not >support network measured location) would have a means to restrict my >laptop's access (which does not have an end-system measured location). >Suggestion: be more specific. Say 'commercial wireless access networks' >or 'subscription based wireless access networks'. It has to be a managed >network, otherwise nothing can be enforced. > >12. "ED-27/INT-20 If the device sends a DHCP INFORM message" >The text should say 'DHCPINFORM' (no space between, rfc2131). > >13. "ED-28/INT-21 To minimize the effects of VPNs that do not allow >split > tunneling VPNs, location configuration SHOULD be attempted before > such tunnels are established." >Add reference to 'split tunneling VPNs'(if exists). If there is no >reference, then be more explicit. Say that using an LCP while on a VPN >may result in getting the location of the vpn gateway. Avoid using >non-defined terms. I agree with this >14. "ED-47 Endpoints MUST support one or more mechanisms that allow them > to determine their public IP address. Examples include ICE ..." >It should be STUN instead of ICE. I believe this is true too >15. " ED-68/SP-38 The emergency dialstrings SHOULD NOT be permitted in >Call > Forward numbers or speed dial lists." >There is no such regulatory requirement in place. Vendors comply with >regulatory requirements when it comes to emergency services. This draft >is not an amendment to any regulatory document, thus this requirement is >inappropriate. Remove it. ah, so here's the issue. I you dial 911 from a US phone and the call ends too early, and the call-taker chooses to call-back to the phone you called from, and the phone call-forwards all calls to another phone/location -- you're pretty much jacked. Besides, there is text stating that where local regulation/laws overwrite what's written in this doc, local regulation/laws win. >16. general comment: the draft seem to focus on 802.11 access networks. >The term "access point" is used all over. Access networks other than >wi-fi use terms like base station, rnc, node-b, etc. If the draft is >meant to be applicable to access networks other than wi-fi, then a more >generic term should be used instead of 'Access Point'. If this doc doesn't make it clear that Access Point = AP = wifi = 802.11 base-station then this does need to be clarified. I don't remember if it does at the moment. >- gabor > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of ext Hannes Tschofenig >Sent: Sunday, March 02, 2008 9:54 AM >To: ecrit@ietf.org >Subject: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > >This is a Last Call for comments on >http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-04 > >Because of the timing of the impending IETF meeting and the interactions >with other SDOs, we are setting the call for **4 weeks**. > >Please have your comments in no later than March 30. > >Do remember to send a note in if you have read the document and have no >other comments other than "its ready to go" - we need those as much as >we need "I found a problem". > >Thanks! >Hannes & Marc > >_______________________________________________ >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 ecrit-bounces@ietf.org Tue Mar 4 12:34:44 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E65628C708; Tue, 4 Mar 2008 12:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8vR4nQ4LnAo; Tue, 4 Mar 2008 12:34:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 870A628C5FB; Tue, 4 Mar 2008 12:34:20 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E6A28C638 for ; Tue, 4 Mar 2008 12:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQ43LZxoIuqA for ; Tue, 4 Mar 2008 12:34:16 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 1F69328C5FB for ; Tue, 4 Mar 2008 12:32:23 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 04 Mar 2008 12:32:13 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m24KWDtd025182; Tue, 4 Mar 2008 12:32:13 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m24KWALn013645; Tue, 4 Mar 2008 20:32:13 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Mar 2008 12:32:13 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.149.127]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Mar 2008 12:32:12 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Mar 2008 14:32:11 -0600 To: , , From: "James M. Polk" In-Reply-To: References: <47CAE9CA.9010901@gmx.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 04 Mar 2008 20:32:12.0481 (UTC) FILETIME=[D3AE5310:01C87E36] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10574; t=1204662733; x=1205526733; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20WGLC=20on=20draft-ietf-ecrit- phonebcp-04 |Sender:=20; bh=O52Wa+ouibBgwZOZRZW8fPDHicUzBOYR2mpwmof5Zec=; b=erPa/lE1wjEgeMuvqA0pmqtei4GRx7eOOgojZSadcQkCOpIRL9vJL0Qzkj wp3tVcksEYlgTh2nrL46kIUp7hZI5qdmCPnS5xYk0OQ6xJGB3KsUBEdN6xXr 0jwP52d2ST; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Subha Hey - I'm pretty sure this TBD isn't the same element, which means this guy is going ot come after us each time he thinks of a new element. I agree with your analysis, though I don't want to have to bring several up to speed if they want to join. I don't know if you can suggest that only a few of us tackle this as the EAB-location group, and let it stand as we work it out along the way. If so, this would be better coming from both you and Allan than from me (during the call Friday). James At 02:21 PM 3/4/2008, James M. Polk wrote: >Gabor > >That this document is from the IETF means it involves IP. > >more in-line below > >At 10:37 PM 3/2/2008, Gabor.Bajko@nokia.com wrote: > >Few comments below: > > > >1. The title of the document does not explicitely say that this document > >is about "VoIP" emergency calls. > >Suggestion: add "VoIP" to the title (... Communications Services in > >support of VoIP Emergency Calling) > >Calls are not limited to "voice", even though each are called "calls". > > > >2. The title of the documents says "Best Current Practice for ...", > >while the document is not a collection nor a subset of the currently > >used practices for emergency calling. And there is no 'current practice' > >for VoIP emergency calling yet, thus a 'best current practice' of yet > >nonexisting practices is confusing. > >Suggestion: change the title eg to "Requirements for Communication > >Services in support of VoIP Emergency Calling" > >(and revise the abstract section accordingly) > >While I agree there are no current practices, this document is an >effort with a fair degree of interworking amongst emergency calling >consortia - and the goal here is to establish an singular >architecture, not one of many choices - therefore stating clearly >this is "one" practice to be implemented is best. The title does >this. The document status is to be Proposed Standard, not Best >Current Practice. > > > >3. "ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the > > Request-URI of the INVITE." > >Marked by whom, the endpoints, the proxies or both? Clarify > >this is in the document > > > >4. "ED-5/SP-4 Local dial strings MUST be recognized." and "ED-6/SP-5 > >Home dial strings MAY be recognized." > >Recognized by whom? Clarify > >What is this document about? (hint: entities supporting this (to be) >IETF standard) That's whom. > > > >5. "ED-10 Devices SHOULD NOT have one button emergency calling > > initiation." > >While I understand that the intention is to discourage vendors to design > >devices with a button dedicated only for emergency calls, current mobile > >phones have the possibility of 'speed dial', when a preset dial string > >(including 112 or 911) can be assigned to any button. Requirement ED-10 > >can be also read to ban this feature in the phone. Clarify. > >Have you not been involved in the emergency calling discussions over >the past several years within the IETF or NENA? > >This "emergency button" was tried and if failed miserably within the >US in the late 80s - because of too many false emergency calls >because the single button was accidently hit (for example, in a >lady's purse). This wrecked havoc on PSAP call takers and first >responders. So while this idea sounds great, it doesn't work in practice. > >If this still needs to be clarified, this can be with a single sentence. > > >I do not have a suggestion, but as today's devices do not have such a > >dedicated red button any more, I see no value in this requirement, it > >just creates confusion. > >it clarifies that one shouldn't ever be thought of again > > > >6. "ED-11/SP-9 All emergency services specified in > >[I-D.ietf-ecrit-service-urn] MUST be recognized." > >Recognized by whom? Clarify. > >(hint: entities supporting this (to be) IETF standard) That's whom. > > > >7. "6.1. Types of location information > > > > There are several forms of location. In IETF protocols , civic and > >geospatial (geo) forms are both supported." > >The term "IETF protocols" is too broad. UDP/TCP/DNS/ARP etc. are all > >'IETF protocols', but they do not support location. Be more specific. > >In these are to carry location - I think they should consider what's >said in this document. > >To be more specific means to list every protocol that cannot support >location and every protocol that might be able to support >location. The remainder either is going to or does support location. > > > >8. section 6.1 > >"Other forms of > > location representation must be mapped into either a geo or civic for > > use in emergency calls." > >Currently most mobile network carriers use cell-id for directing the > >call to the correct psap. > >Is cell-id a location? If true, is an ALI a location. Both are >ids... what's the difference? > > >That technique will not go away for yet a long > >time. While cell-id could be mapped into either civic or geo, there is > >no added value in doing so, as cell-id based routing serves the purpose > >just as well as civic or geo based routing. > >Cell-id routing... on IP? I believe you're mixing technologies where >mixing shouldn't be done. > > >I would suggest relaxing the > >requirement, otherwise the draft will go against current practices. > >...of cellular world infrastructures, which aren't IP based, so >there's no reason this requirement addresses the legacy >infrastructure. BTW -- I believe IMS (which is cellular based >systems) is using PIDF-LO and location-URI references, not cell-ids > > > >9. "ED-17/INT-8/AN-7 Devices that support endpoint measuring of location > > MUST have at least a coarse location capability (typically <1km > > accuracy when not location hiding) at all times for routing of > >calls." > >I do not understand the text in the brackets. What is location hiding > >(add reference to it) and what happens when it is applied, will the req > >become n/a? clarify. > >I agree location hiding shouldn't be in this document > > >Same comment for AN-9 > > > >10. same paragraph as above. "This mechanism MAY be a service provided > >by the access network." It is not clear what 'this mechanism' refers to. > > > >11. "AN-8 Access networks MAY provide network-measured location > > determination. Wireless access network which do not support network > > measured location MUST require that all devices connected to the > > network have end-system measured location. " > >What kind of wireless access networks are we talking about? Commercial, > >public, private, academic or all of them? I could hardly believe that a > >free public network like the google one in Mountain View (which does not > >support network measured location) would have a means to restrict my > >laptop's access (which does not have an end-system measured location). > >Suggestion: be more specific. Say 'commercial wireless access networks' > >or 'subscription based wireless access networks'. It has to be a managed > >network, otherwise nothing can be enforced. > > > >12. "ED-27/INT-20 If the device sends a DHCP INFORM message" > >The text should say 'DHCPINFORM' (no space between, rfc2131). > > > >13. "ED-28/INT-21 To minimize the effects of VPNs that do not allow > >split > > tunneling VPNs, location configuration SHOULD be attempted before > > such tunnels are established." > >Add reference to 'split tunneling VPNs'(if exists). If there is no > >reference, then be more explicit. Say that using an LCP while on a VPN > >may result in getting the location of the vpn gateway. Avoid using > >non-defined terms. > >I agree with this > > > >14. "ED-47 Endpoints MUST support one or more mechanisms that allow them > > to determine their public IP address. Examples include ICE ..." > >It should be STUN instead of ICE. > >I believe this is true too > > > >15. " ED-68/SP-38 The emergency dialstrings SHOULD NOT be permitted in > >Call > > Forward numbers or speed dial lists." > >There is no such regulatory requirement in place. Vendors comply with > >regulatory requirements when it comes to emergency services. This draft > >is not an amendment to any regulatory document, thus this requirement is > >inappropriate. Remove it. > >ah, so here's the issue. I you dial 911 from a US phone and the call >ends too early, and the call-taker chooses to call-back to the phone >you called from, and the phone call-forwards all calls to another >phone/location -- you're pretty much jacked. > >Besides, there is text stating that where local regulation/laws >overwrite what's written in this doc, local regulation/laws win. > > > >16. general comment: the draft seem to focus on 802.11 access networks. > >The term "access point" is used all over. Access networks other than > >wi-fi use terms like base station, rnc, node-b, etc. If the draft is > >meant to be applicable to access networks other than wi-fi, then a more > >generic term should be used instead of 'Access Point'. > >If this doc doesn't make it clear that > > Access Point = AP = wifi = 802.11 base-station > >then this does need to be clarified. I don't remember if it does at >the moment. > > > >- gabor > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >Of ext Hannes Tschofenig > >Sent: Sunday, March 02, 2008 9:54 AM > >To: ecrit@ietf.org > >Subject: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > >This is a Last Call for comments on > >http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-04 > > > >Because of the timing of the impending IETF meeting and the interactions > >with other SDOs, we are setting the call for **4 weeks**. > > > >Please have your comments in no later than March 30. > > > >Do remember to send a note in if you have read the document and have no > >other comments other than "its ready to go" - we need those as much as > >we need "I found a problem". > > > >Thanks! > >Hannes & Marc > > > >_______________________________________________ > >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 ecrit-bounces@ietf.org Tue Mar 4 12:35:13 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67BE428C6FF; Tue, 4 Mar 2008 12:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.982 X-Spam-Level: X-Spam-Status: No, score=-0.982 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akxGDr31-IZE; Tue, 4 Mar 2008 12:35:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87D1A3A6CF5; Tue, 4 Mar 2008 12:34:57 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3934428C6ED for ; Tue, 4 Mar 2008 12:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80uqea4hsIua for ; Tue, 4 Mar 2008 12:34:54 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E4FD228C62F for ; Tue, 4 Mar 2008 12:34:45 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 04 Mar 2008 12:34:36 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m24KYaIU010728; Tue, 4 Mar 2008 12:34:36 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m24KYVLt015834; Tue, 4 Mar 2008 20:34:36 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Mar 2008 12:34:35 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.149.127]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Mar 2008 12:34:34 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Mar 2008 14:34:33 -0600 To: , , From: "James M. Polk" Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 04 Mar 2008 20:34:35.0001 (UTC) FILETIME=[28A12690:01C87E37] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11254; t=1204662876; x=1205526876; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Fwd=3A=20Re=3A=20[Ecrit]=20WGLC=20on=20draft-ie tf-ecrit-phonebcp-04 |Sender:=20; bh=94ZAqy7djXe7wKH+VfQBVhhXln2M58DQcqTVXJ1GsMc=; b=UiLlAyzJsRfQJiwGnCEBCtVIeIuzLjoKqo2dFFESyVmAFhvZlVM1B23Ox4 wBKkF8YKG0k6YvokSTfKIVBTI5QJ3gKFTWsATmVu6o07KKl6XN8TtnTbeM2E yXl6nsH941; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Ecrit] Fwd: Re: WGLC on draft-ietf-ecrit-phonebcp-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org please ignore this message, I replied to this message when I thought I was replying to another message. I don't believe there is any secret sauce in this message... hehe sorry! James >Date: Tue, 04 Mar 2008 14:32:11 -0600 >To: , , >From: "James M. Polk" >Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > >Subha > >Hey - I'm pretty sure this TBD isn't the same element, which means >this guy is going ot come after us each time he thinks of a new >element. I agree with your analysis, though I don't want to have to >bring several up to speed if they want to join. I don't know if you >can suggest that only a few of us tackle this as the EAB-location >group, and let it stand as we work it out along the way. If so, >this would be better coming from both you and Allan than from me >(during the call Friday). > >James > >At 02:21 PM 3/4/2008, James M. Polk wrote: >>Gabor >> >>That this document is from the IETF means it involves IP. >> >>more in-line below >> >>At 10:37 PM 3/2/2008, Gabor.Bajko@nokia.com wrote: >> >Few comments below: >> > >> >1. The title of the document does not explicitely say that this document >> >is about "VoIP" emergency calls. >> >Suggestion: add "VoIP" to the title (... Communications Services in >> >support of VoIP Emergency Calling) >> >>Calls are not limited to "voice", even though each are called "calls". >> >> >> >2. The title of the documents says "Best Current Practice for ...", >> >while the document is not a collection nor a subset of the currently >> >used practices for emergency calling. And there is no 'current practice' >> >for VoIP emergency calling yet, thus a 'best current practice' of yet >> >nonexisting practices is confusing. >> >Suggestion: change the title eg to "Requirements for Communication >> >Services in support of VoIP Emergency Calling" >> >(and revise the abstract section accordingly) >> >>While I agree there are no current practices, this document is an >>effort with a fair degree of interworking amongst emergency calling >>consortia - and the goal here is to establish an singular >>architecture, not one of many choices - therefore stating clearly >>this is "one" practice to be implemented is best. The title does >>this. The document status is to be Proposed Standard, not Best >>Current Practice. >> >> >> >3. "ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the >> > Request-URI of the INVITE." >> >Marked by whom, the endpoints, the proxies or both? Clarify >> >>this is in the document >> >> >> >4. "ED-5/SP-4 Local dial strings MUST be recognized." and "ED-6/SP-5 >> >Home dial strings MAY be recognized." >> >Recognized by whom? Clarify >> >>What is this document about? (hint: entities supporting this (to be) >>IETF standard) That's whom. >> >> >> >5. "ED-10 Devices SHOULD NOT have one button emergency calling >> > initiation." >> >While I understand that the intention is to discourage vendors to design >> >devices with a button dedicated only for emergency calls, current mobile >> >phones have the possibility of 'speed dial', when a preset dial string >> >(including 112 or 911) can be assigned to any button. Requirement ED-10 >> >can be also read to ban this feature in the phone. Clarify. >> >>Have you not been involved in the emergency calling discussions over >>the past several years within the IETF or NENA? >> >>This "emergency button" was tried and if failed miserably within the >>US in the late 80s - because of too many false emergency calls >>because the single button was accidently hit (for example, in a >>lady's purse). This wrecked havoc on PSAP call takers and first >>responders. So while this idea sounds great, it doesn't work in practice. >> >>If this still needs to be clarified, this can be with a single sentence. >> >> >I do not have a suggestion, but as today's devices do not have such a >> >dedicated red button any more, I see no value in this requirement, it >> >just creates confusion. >> >>it clarifies that one shouldn't ever be thought of again >> >> >> >6. "ED-11/SP-9 All emergency services specified in >> >[I-D.ietf-ecrit-service-urn] MUST be recognized." >> >Recognized by whom? Clarify. >> >>(hint: entities supporting this (to be) IETF standard) That's whom. >> >> >> >7. "6.1. Types of location information >> > >> > There are several forms of location. In IETF protocols , civic and >> >geospatial (geo) forms are both supported." >> >The term "IETF protocols" is too broad. UDP/TCP/DNS/ARP etc. are all >> >'IETF protocols', but they do not support location. Be more specific. >> >>In these are to carry location - I think they should consider what's >>said in this document. >> >>To be more specific means to list every protocol that cannot support >>location and every protocol that might be able to support >>location. The remainder either is going to or does support location. >> >> >> >8. section 6.1 >> >"Other forms of >> > location representation must be mapped into either a geo or civic for >> > use in emergency calls." >> >Currently most mobile network carriers use cell-id for directing the >> >call to the correct psap. >> >>Is cell-id a location? If true, is an ALI a location. Both are >>ids... what's the difference? >> >> >That technique will not go away for yet a long >> >time. While cell-id could be mapped into either civic or geo, there is >> >no added value in doing so, as cell-id based routing serves the purpose >> >just as well as civic or geo based routing. >> >>Cell-id routing... on IP? I believe you're mixing technologies where >>mixing shouldn't be done. >> >> >I would suggest relaxing the >> >requirement, otherwise the draft will go against current practices. >> >>...of cellular world infrastructures, which aren't IP based, so >>there's no reason this requirement addresses the legacy >>infrastructure. BTW -- I believe IMS (which is cellular based >>systems) is using PIDF-LO and location-URI references, not cell-ids >> >> >> >9. "ED-17/INT-8/AN-7 Devices that support endpoint measuring of location >> > MUST have at least a coarse location capability (typically <1km >> > accuracy when not location hiding) at all times for routing of >> >calls." >> >I do not understand the text in the brackets. What is location hiding >> >(add reference to it) and what happens when it is applied, will the req >> >become n/a? clarify. >> >>I agree location hiding shouldn't be in this document >> >> >Same comment for AN-9 >> > >> >10. same paragraph as above. "This mechanism MAY be a service provided >> >by the access network." It is not clear what 'this mechanism' refers to. >> > >> >11. "AN-8 Access networks MAY provide network-measured location >> > determination. Wireless access network which do not support network >> > measured location MUST require that all devices connected to the >> > network have end-system measured location. " >> >What kind of wireless access networks are we talking about? Commercial, >> >public, private, academic or all of them? I could hardly believe that a >> >free public network like the google one in Mountain View (which does not >> >support network measured location) would have a means to restrict my >> >laptop's access (which does not have an end-system measured location). >> >Suggestion: be more specific. Say 'commercial wireless access networks' >> >or 'subscription based wireless access networks'. It has to be a managed >> >network, otherwise nothing can be enforced. >> > >> >12. "ED-27/INT-20 If the device sends a DHCP INFORM message" >> >The text should say 'DHCPINFORM' (no space between, rfc2131). >> > >> >13. "ED-28/INT-21 To minimize the effects of VPNs that do not allow >> >split >> > tunneling VPNs, location configuration SHOULD be attempted before >> > such tunnels are established." >> >Add reference to 'split tunneling VPNs'(if exists). If there is no >> >reference, then be more explicit. Say that using an LCP while on a VPN >> >may result in getting the location of the vpn gateway. Avoid using >> >non-defined terms. >> >>I agree with this >> >> >> >14. "ED-47 Endpoints MUST support one or more mechanisms that allow them >> > to determine their public IP address. Examples include ICE ..." >> >It should be STUN instead of ICE. >> >>I believe this is true too >> >> >> >15. " ED-68/SP-38 The emergency dialstrings SHOULD NOT be permitted in >> >Call >> > Forward numbers or speed dial lists." >> >There is no such regulatory requirement in place. Vendors comply with >> >regulatory requirements when it comes to emergency services. This draft >> >is not an amendment to any regulatory document, thus this requirement is >> >inappropriate. Remove it. >> >>ah, so here's the issue. I you dial 911 from a US phone and the call >>ends too early, and the call-taker chooses to call-back to the phone >>you called from, and the phone call-forwards all calls to another >>phone/location -- you're pretty much jacked. >> >>Besides, there is text stating that where local regulation/laws >>overwrite what's written in this doc, local regulation/laws win. >> >> >> >16. general comment: the draft seem to focus on 802.11 access networks. >> >The term "access point" is used all over. Access networks other than >> >wi-fi use terms like base station, rnc, node-b, etc. If the draft is >> >meant to be applicable to access networks other than wi-fi, then a more >> >generic term should be used instead of 'Access Point'. >> >>If this doc doesn't make it clear that >> >> Access Point = AP = wifi = 802.11 base-station >> >>then this does need to be clarified. I don't remember if it does at >>the moment. >> >> >> >- gabor >> > >> >-----Original Message----- >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> >Of ext Hannes Tschofenig >> >Sent: Sunday, March 02, 2008 9:54 AM >> >To: ecrit@ietf.org >> >Subject: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 >> > >> >This is a Last Call for comments on >> >http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-04 >> > >> >Because of the timing of the impending IETF meeting and the interactions >> >with other SDOs, we are setting the call for **4 weeks**. >> > >> >Please have your comments in no later than March 30. >> > >> >Do remember to send a note in if you have read the document and have no >> >other comments other than "its ready to go" - we need those as much as >> >we need "I found a problem". >> > >> >Thanks! >> >Hannes & Marc >> > >> >_______________________________________________ >> >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 ecrit-bounces@ietf.org Wed Mar 5 02:00:56 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FF0428C763; Wed, 5 Mar 2008 02:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnDf7qChRkKU; Wed, 5 Mar 2008 02:00:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FA1528C75C; Wed, 5 Mar 2008 02:00:55 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78A2E28C75D for ; Wed, 5 Mar 2008 02:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7yafMi-QRZq for ; Wed, 5 Mar 2008 02:00:53 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 03C5628C75B for ; Wed, 5 Mar 2008 02:00:52 -0800 (PST) Received: (qmail 25637 invoked by uid 0); 5 Mar 2008 10:00:43 -0000 Received: from 192.100.124.218 by www080.gmx.net with HTTP; Wed, 05 Mar 2008 11:00:42 +0100 (CET) Date: Wed, 05 Mar 2008 11:00:42 +0100 From: "Hannes Tschofenig" Message-ID: <20080305100042.160460@gmx.net> MIME-Version: 1.0 To: ecrit@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1/VOK1gMS/VXKLRq7wGliSJiu/s1ZtPBUAo7ZpJ1Y DJAtX6LH1Nlf11kJ2DhMOISi+GL8FE7cpgRA== X-GMX-UID: Kwa7dJoLODB6cJkCsWVMfKI9Ji9SWlK/ Subject: [Ecrit] Fwd: Re: DISCUSS: draft-ietf-ecrit-lost X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org FYI -------- Original-Nachricht -------- Datum: Tue, 4 Mar 2008 11:06:44 -0500 Von: Tim Polk An: Ted Hardie CC: "iesg@ietf.org" , "ecrit-chairs@tools.ietf.org" , "draft-ietf-ecrit-lost@tools.ietf.org" Betreff: Re: DISCUSS: draft-ietf-ecrit-lost Ted, Thanks for the quick response. Yes, this text would work for me. Tim Polk On Mar 4, 2008, at 10:35 AM, Ted Hardie wrote: > At 12:24 PM -0800 3/3/08, Tim Polk wrote: >> Discuss: >> The introduction suggests that LoST may be appropriate for non- >> emergency services >> as well, but does not revisit that notion anywhere else in the >> document. As noted in Joe >> Salowey's secdir review, there may be different threats or >> motivations which could affect >> the applicability of LoST to such applications. From his review: >> >> 3) Use in non-ecrit cases - has much thought been given to the >> use of >> LoST in non-Ecrit cases? There may be different threats or at >> least >> motivations than those covered in draft-ietf-ecrit-security- >> threats. >> For example, in non-ecrit cases an attacker may seek monetary >> benefit >> through attacking the LoST protocol to return inaccurate service >> mapping >> information. The suggestion here is to either consider this >> case of >> non-ecrit in more detail or to state that threats outside ecrit >> cases >> may be different. >> >> At a minimum, the security considedrations section should note that >> non-emergency services may face a different set of threats. The >> requirements >> for these services should be carefully reviewed to ensure that >> LoST can be >> used to achieve the service's security requirements. > > Proposed RFC Editor note: > > OLD: > > A more detailed description of threats and security requirements > are provided in [17]. > > > NEW: > > A more detailed description of threats and security requirements > are provided in [17]. > The threats and security requirements in non-emergency service > uses of LoST may be considerably different from those described here. > For example, an attacker might seek monetary benefit by returning > service mapping information which directed users to specific service > providers. Before deploying LoST in new contexts, a thorough analysis > of the threats and requirements specific to that context should > be undertaken and decisions made on the appropriate mitigations. > > > Please let me know if this works to satisfy your concerns, > regards, > Ted Hardie > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 5 11:04:44 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7CE28C7F5; Wed, 5 Mar 2008 11:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.865 X-Spam-Level: X-Spam-Status: No, score=-0.865 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULJ2NfbPGP94; Wed, 5 Mar 2008 11:04:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB1B53A6A0D; Wed, 5 Mar 2008 11:04:40 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1F343A68CB for ; Wed, 5 Mar 2008 11:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xzDEdOAnFqG for ; Wed, 5 Mar 2008 11:04:37 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 26A863A6A0D for ; Wed, 5 Mar 2008 11:04:36 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m25J3j8h003985; Wed, 5 Mar 2008 21:04:20 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Mar 2008 21:04:05 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Mar 2008 13:04:03 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 13:04:02 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 Thread-Index: Ach+NXKTvRMmxoARTieT0xUa1OcvCwAL7UAg References: <47CAE9CA.9010901@gmx.net> From: To: , , X-OriginalArrivalTime: 05 Mar 2008 19:04:03.0440 (UTC) FILETIME=[AD947700:01C87EF3] X-Nokia-AV: Clean Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James: some comments inline - gabor -----Original Message----- From: ext James M. Polk [mailto:jmpolk@cisco.com] Sent: Tuesday, March 04, 2008 12:21 PM To: Bajko Gabor (Nokia-OCTO/MtView); Hannes.Tschofenig@gmx.net; ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 Gabor That this document is from the IETF means it involves IP. more in-line below At 10:37 PM 3/2/2008, Gabor.Bajko@nokia.com wrote: >Few comments below: > >1. The title of the document does not explicitely say that this >document is about "VoIP" emergency calls. >Suggestion: add "VoIP" to the title (... Communications Services in >support of VoIP Emergency Calling) Calls are not limited to "voice", even though each are called "calls". fair enough, but adding 'IP' (... Communications Services in support of IP based Emergency Calling) would still be beneficial. >2. The title of the documents says "Best Current Practice for ...", >while the document is not a collection nor a subset of the currently >used practices for emergency calling. And there is no 'current practice' >for VoIP emergency calling yet, thus a 'best current practice' of yet >nonexisting practices is confusing. >Suggestion: change the title eg to "Requirements for Communication >Services in support of VoIP Emergency Calling" >(and revise the abstract section accordingly) While I agree there are no current practices, this document is an effort with a fair degree of interworking amongst emergency calling consortia - and the goal here is to establish an singular architecture, not one of many choices - therefore stating clearly this is "one" practice to be implemented is best. The title does this. The document status is to be Proposed Standard, not Best Current Practice. the goal to establish a singular architecture and the interworking effort happens in multiple WGs in ietf and other SDOs, not (only) in this draft. This is clearly a requirements document and the title should say that instead of bcp. Do we disagree on whether this is a requirements document or not? >4. "ED-5/SP-4 Local dial strings MUST be recognized." and "ED-6/SP-5 >Home dial strings MAY be recognized." >Recognized by whom? Clarify What is this document about? (hint: entities supporting this (to be) IETF standard) That's whom. a requirement should state who should do what. Requirements ED-4, ED-5, ED-6 and ED-11 only say what needs to be done, but not who needs to do it. The other requirements do state both who and what, why are these requirements special? I did not ask to reformulate because I did not understand it, but we are not writing the document for ourselves. >8. section 6.1 >"Other forms of > location representation must be mapped into either a geo or civic for > use in emergency calls." >Currently most mobile network carriers use cell-id for directing the >call to the correct psap. Is cell-id a location? If true, is an ALI a location. Both are ids... what's the difference? >That technique will not go away for yet a long >time. While cell-id could be mapped into either civic or geo, there is >no added value in doing so, as cell-id based routing serves the purpose >just as well as civic or geo based routing. Cell-id routing... on IP? I believe you're mixing technologies where mixing shouldn't be done. cell-id is not a technology. What is different between cell-id based routing and coordinates based routing? Is IP routing based on coordinates? No. You need a database to map sg to sg. And one of the sgs can be the call-id. >I would suggest relaxing the >requirement, otherwise the draft will go against current practices. ...of cellular world infrastructures, which aren't IP based, so there's no reason this requirement addresses the legacy infrastructure. BTW -- I believe IMS (which is cellular based systems) is using PIDF-LO and location-URI references, not cell-ids cellular is not IP based? Nooo, it is as IP based as an AP (assuming we talk about the same thing: cellular=commercial mobile network) You can initiate VoIP calls and it is just a matter of regulatory work to be able to initiate VoIP emergency calls from cellular networks. Cell-id is an identifier of a geographical area which is mapped to psap already in today's databases. If you'll make an IP based emergency call on cellular, that will use now and for many years to come the cell-id to select the psap where to direct your call. It works, it's proven. I hope we can keep the discussion technical and not become too religious about the usability of cell-id. >15. " ED-68/SP-38 The emergency dialstrings SHOULD NOT be permitted in >Call > Forward numbers or speed dial lists." >There is no such regulatory requirement in place. Vendors comply with >regulatory requirements when it comes to emergency services. This draft >is not an amendment to any regulatory document, thus this requirement is >inappropriate. Remove it. ah, so here's the issue. I you dial 911 from a US phone and the call ends too early, and the call-taker chooses to call-back to the phone you called from, and the phone call-forwards all calls to another phone/location -- you're pretty much jacked. Besides, there is text stating that where local regulation/laws overwrite what's written in this doc, local regulation/laws win. I didn't get how your reasoning relates to the requirement. ED-68 is about using emergency dialstrings in speed dial lists. Mobile phones have that feature today, and there is no regulatory requirement foreseen to ban that. The feature is a UI feature, not a protocol. This document should certainly not make restrictions on what UI features vendors can implement. If restriction will be required, those will be made by the regulators. And note, laws/regulation say what is not permitted and they are not explicitely listing the allowed features, thus there is no such thing as "regulation/laws overwrite what's written in this doc". >16. general comment: the draft seem to focus on 802.11 access networks. >The term "access point" is used all over. Access networks other than >wi-fi use terms like base station, rnc, node-b, etc. If the draft is >meant to be applicable to access networks other than wi-fi, then a more >generic term should be used instead of 'Access Point'. If this doc doesn't make it clear that Access Point = AP = wifi = 802.11 base-station then this does need to be clarified. I don't remember if it does at the moment. >- gabor > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of ext Hannes Tschofenig >Sent: Sunday, March 02, 2008 9:54 AM >To: ecrit@ietf.org >Subject: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > >This is a Last Call for comments on >http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-04 > >Because of the timing of the impending IETF meeting and the interactions >with other SDOs, we are setting the call for **4 weeks**. > >Please have your comments in no later than March 30. > >Do remember to send a note in if you have read the document and have no >other comments other than "its ready to go" - we need those as much as >we need "I found a problem". > >Thanks! >Hannes & Marc > >_______________________________________________ >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 ecrit-bounces@ietf.org Wed Mar 5 11:29:21 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09BEF3A6F4B; Wed, 5 Mar 2008 11:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.984 X-Spam-Level: X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[AWL=-0.547, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BG1ASyiUz3QZ; Wed, 5 Mar 2008 11:29:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F09B3A6F41; Wed, 5 Mar 2008 11:29:20 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DB0C3A6B62 for ; Wed, 5 Mar 2008 11:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7ZjLHCMBSMs for ; Wed, 5 Mar 2008 11:29:15 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4B26F3A6D2D for ; Wed, 5 Mar 2008 11:29:15 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 05 Mar 2008 11:29:05 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m25JT5vZ004825; Wed, 5 Mar 2008 11:29:05 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m25JT4Ll014711; Wed, 5 Mar 2008 19:29:04 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Mar 2008 11:29:04 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.80.13]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Mar 2008 11:29:03 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 05 Mar 2008 13:29:02 -0600 To: , , From: "James M. Polk" In-Reply-To: References: <47CAE9CA.9010901@gmx.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 05 Mar 2008 19:29:03.0783 (UTC) FILETIME=[2BDAA370:01C87EF7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1076; t=1204745345; x=1205609345; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Ecrit]=20WGLC=20on=20draft-ietf-ecrit- phonebcp-04=20(cell-id) |Sender:=20; bh=DudYENitfgEhOyEqbkyD28byW1xHSyAOLvSpZrNlWgk=; b=TB0AEvOHxRRnl6RBIrjve6TNalFzaQKtKQpK2a9tud5M80oVGz12/zzrUU LbnrtDnoKC1W6OPu4zYd9RzNIBEbrvSAuhhNwO/q+zlxYlpkj00uTo8hOOwg Q/1y/J1Iyu; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: >Cell-id is an identifier of a geographical area which is mapped to psap >already in today's databases. If you'll make an IP based emergency call >on cellular, that will use now and for many years to come the cell-id to >select the psap where to direct your call. GAbor let's discuss this topic as its own thread. All (not just some or one) of the following questions need to be answered positively and definitively in order for your Cell-id scenario to work in IP. Where is the Cell-id to PSAP URI mapping done? What database has this information? What IP protocol is used to resolve this mapping of Cell-id to (appropriate) PSAP? Where is this IP-based server located? How can LoST be used to discover this? What LCP will give this Cell-id to a phone to include in a SIP message? What SIP header is this information placed in? What form does this Cell-id have in the SIP header from the previous question? What IETF document(s) specifies this header and Cell-id form? James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 5 11:35:32 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1410B28C2CF; Wed, 5 Mar 2008 11:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLFs0poHQNKn; Wed, 5 Mar 2008 11:35:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABB7C3A6F2E; Wed, 5 Mar 2008 11:35:26 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 154183A6917 for ; Wed, 5 Mar 2008 11:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OouPQ+e-o45W for ; Wed, 5 Mar 2008 11:35:24 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C439B3A6F08 for ; Wed, 5 Mar 2008 11:35:23 -0800 (PST) Received: (qmail invoked by alias); 05 Mar 2008 19:35:13 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp018) with SMTP; 05 Mar 2008 20:35:13 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+iz0A3RAei/zMouecAp0iQF5qq0Nm5HGmqgTeqkG mX03IEANwnz6OZ Message-ID: <47CEF5EF.4000503@gmx.net> Date: Wed, 05 Mar 2008 21:35:11 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] [Fwd: COMMENT: draft-ietf-ecrit-lost] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org FYI -------- Original Message -------- Subject: COMMENT: draft-ietf-ecrit-lost Date: Tue, 4 Mar 2008 07:37:58 -0800 (PST) From: Dan Romascanu To: iesg@ietf.org CC: ecrit-chairs@tools.ietf.org, draft-ietf-ecrit-lost@tools.ietf.org Comment: 1. second paragraph of Section 1 - PIDF-LO is duplicated 2. second paragraph of Section 1 - please explain what are "2-1-1" and "3-1-1" services. Maybe this is common knowledge in the US, but for a non-American reader they have no significance. Better describe the service for example 'non-emergency municipal services or a citizen community services (e.g. "3-1-1" in the United States', etc. 3. in section 13.2 - I doubt that the three MAY in the descriptions of the warnings are appropriate. If I am not mistaken if each of the warning conditions is met in particular, including the earning message in the response is not optional. 4. Reference [21] has a corrupted content at the time I am writing this comment. This makes me wonder wheter a better protected place can be found for the on-line examples quoted in Appendix B. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 5 11:56:50 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29E9A28C8BC; Wed, 5 Mar 2008 11:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.568 X-Spam-Level: X-Spam-Status: No, score=-0.568 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBX582EOCHcx; Wed, 5 Mar 2008 11:56:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DB3128C7F8; Wed, 5 Mar 2008 11:56:24 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 064A928C58F for ; Wed, 5 Mar 2008 11:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tLo8xu2tC82 for ; Wed, 5 Mar 2008 11:56:21 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id CEB0328C419 for ; Wed, 5 Mar 2008 11:52:48 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JWzfE-0002fk-C3; Wed, 05 Mar 2008 13:52:32 -0600 From: "Brian Rosen" To: "'James M. Polk'" , , , References: <47CAE9CA.9010901@gmx.net> Date: Wed, 5 Mar 2008 14:52:34 -0500 Message-ID: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Ach+9y5eI086D2zvSn+r/wfv6bnvUAAAtK2A X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The basic agreement we have made, in NENA, is that the operator will agree with the PSAP on a location for the cellid. This could be a point or a polygon. That location will be reported, in PIDF-LO form, from the LIS. There was a discussion about actually allowing a cell-id as an alternate form of location representation, but it was decided not to do that. A LIS could, of course, construct a location reference of the form sip:@opco.net, and send that. When dereferenced, it would return the agreed-upon location. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > James M. Polk > Sent: Wednesday, March 05, 2008 2:29 PM > To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > >Cell-id is an identifier of a geographical area which is mapped to psap > >already in today's databases. If you'll make an IP based emergency call > >on cellular, that will use now and for many years to come the cell-id to > >select the psap where to direct your call. GAbor > > let's discuss this topic as its own thread. > > All (not just some or one) of the following questions need to be > answered positively and definitively in order for your Cell-id > scenario to work in IP. > > Where is the Cell-id to PSAP URI mapping done? > > What database has this information? > > What IP protocol is used to resolve this mapping of Cell-id to > (appropriate) PSAP? > > Where is this IP-based server located? > > How can LoST be used to discover this? > > What LCP will give this Cell-id to a phone to include in a SIP message? > > What SIP header is this information placed in? > > What form does this Cell-id have in the SIP header from the previous > question? > > What IETF document(s) specifies this header and Cell-id form? > > James > > > _______________________________________________ > 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 ecrit-bounces@ietf.org Wed Mar 5 12:50:50 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6A3A28C3E2; Wed, 5 Mar 2008 12:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.907 X-Spam-Level: X-Spam-Status: No, score=-0.907 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeYWeyWFgcSz; Wed, 5 Mar 2008 12:50:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C48453A6DC9; Wed, 5 Mar 2008 12:50:49 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3D233A68F0 for ; Wed, 5 Mar 2008 12:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z63T0HOPnngf for ; Wed, 5 Mar 2008 12:50:48 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E143E3A6982 for ; Wed, 5 Mar 2008 12:50:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,452,1199682000"; d="scan'208";a="581289" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Mar 2008 15:50:37 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m25KobUB031696; Wed, 5 Mar 2008 15:50:37 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m25KoBar018436; Wed, 5 Mar 2008 20:50:29 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Mar 2008 15:50:26 -0500 Received: from mlinsnerwxp02 ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Mar 2008 15:50:26 -0500 From: "Marc Linsner" To: "'Brian Rosen'" , , Date: Wed, 5 Mar 2008 15:50:25 -0500 Message-ID: <00b401c87f02$89eafcc0$270d0d0a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Ach+9y5eI086D2zvSn+r/wfv6bnvUAAAtK2AAAD/tFA= In-Reply-To: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com> X-OriginalArrivalTime: 05 Mar 2008 20:50:26.0209 (UTC) FILETIME=[8A01B910:01C87F02] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3226; t=1204750237; x=1205614237; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20WGLC=20on=20draft-ietf-ecrit- phonebcp-04=20(cell-id) |Sender:=20 |To:=20=22'Brian=20Rosen'=22=20,=20,=0A=20=20=20=20=20=20=20=20; bh=rWnbdW0wkhdA/y19e7HgNUFRrbm5A3W9QRfnwnxk/pY=; b=iJRkwi3HbkTUj6TwAwBqOKd8FUobzpfMdMDZNNyasnwh+SEUIcz6HbvyVa I3+z3upcfmOTDr4Mx6LmVC6BpqlwGJj2Td2L+XjbbaUzzSLsf7JKyksdrqSU 9mhmpQeE/S; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Of course there is no reason the operator couldn't provide civic location (123 Main St.) in place of cell-id either (verses a geo location). The main objective is to have location information in the device such that it makes sense to the consumer vs. every context having their own location descriptions (cell-id, water meter number, telephone pole id, property tax plat number, fire hydrant inventory id, msag address, etc.). -Marc- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Wednesday, March 05, 2008 2:53 PM > To: 'James M. Polk'; Gabor.Bajko@nokia.com; > Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > The basic agreement we have made, in NENA, is that the > operator will agree with the PSAP on a location for the > cellid. This could be a point or a polygon. That location > will be reported, in PIDF-LO form, from the LIS. > There was a discussion about actually allowing a cell-id as > an alternate form of location representation, but it was > decided not to do that. A LIS could, of course, construct a > location reference of the form sip:@opco.net, and > send that. When dereferenced, it would return the > agreed-upon location. > > Brian > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of James M. Polk > > Sent: Wednesday, March 05, 2008 2:29 PM > > To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > >Cell-id is an identifier of a geographical area which is mapped to > > >psap already in today's databases. If you'll make an IP based > > >emergency call on cellular, that will use now and for many > years to > > >come the cell-id to select the psap where to direct your > call. GAbor > > > > let's discuss this topic as its own thread. > > > > All (not just some or one) of the following questions need to be > > answered positively and definitively in order for your Cell-id > > scenario to work in IP. > > > > Where is the Cell-id to PSAP URI mapping done? > > > > What database has this information? > > > > What IP protocol is used to resolve this mapping of Cell-id to > > (appropriate) PSAP? > > > > Where is this IP-based server located? > > > > How can LoST be used to discover this? > > > > What LCP will give this Cell-id to a phone to include in a > SIP message? > > > > What SIP header is this information placed in? > > > > What form does this Cell-id have in the SIP header from the > previous > > question? > > > > What IETF document(s) specifies this header and Cell-id form? > > > > James > > > > > > _______________________________________________ > > 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 ecrit-bounces@ietf.org Wed Mar 5 13:01:40 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D4F43A6FA6; Wed, 5 Mar 2008 13:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.574 X-Spam-Level: X-Spam-Status: No, score=-0.574 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYOIXoB4VXA0; Wed, 5 Mar 2008 13:01:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92543A6F59; Wed, 5 Mar 2008 13:01:38 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CDC33A6A0D for ; Wed, 5 Mar 2008 13:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQZ6RO-VrGJC for ; Wed, 5 Mar 2008 13:01:36 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 8B87B28C756 for ; Wed, 5 Mar 2008 13:01:35 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JX0jn-0008W1-6v; Wed, 05 Mar 2008 15:01:19 -0600 From: "Brian Rosen" To: "'Marc Linsner'" , , References: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com> <00b401c87f02$89eafcc0$270d0d0a@cisco.com> Date: Wed, 5 Mar 2008 16:01:22 -0500 Message-ID: <019d01c87f04$12d67360$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <00b401c87f02$89eafcc0$270d0d0a@cisco.com> Thread-Index: Ach+9y5eI086D2zvSn+r/wfv6bnvUAAAtK2AAAD/tFAAAXbB4A== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Certainly. You can return a civic as the location of the cell. They do that in many cases now. > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Wednesday, March 05, 2008 3:50 PM > To: 'Brian Rosen'; Gabor.Bajko@nokia.com; ecrit@ietf.org > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > Of course there is no reason the operator couldn't provide civic location > (123 Main St.) in place of cell-id either (verses a geo location). The > main > objective is to have location information in the device such that it makes > sense to the consumer vs. every context having their own location > descriptions (cell-id, water meter number, telephone pole id, property tax > plat number, fire hydrant inventory id, msag address, etc.). > > -Marc- > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of Brian Rosen > > Sent: Wednesday, March 05, 2008 2:53 PM > > To: 'James M. Polk'; Gabor.Bajko@nokia.com; > > Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > The basic agreement we have made, in NENA, is that the > > operator will agree with the PSAP on a location for the > > cellid. This could be a point or a polygon. That location > > will be reported, in PIDF-LO form, from the LIS. > > There was a discussion about actually allowing a cell-id as > > an alternate form of location representation, but it was > > decided not to do that. A LIS could, of course, construct a > > location reference of the form sip:@opco.net, and > > send that. When dereferenced, it would return the > > agreed-upon location. > > > > Brian > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of James M. Polk > > > Sent: Wednesday, March 05, 2008 2:29 PM > > > To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > >Cell-id is an identifier of a geographical area which is mapped to > > > >psap already in today's databases. If you'll make an IP based > > > >emergency call on cellular, that will use now and for many > > years to > > > >come the cell-id to select the psap where to direct your > > call. GAbor > > > > > > let's discuss this topic as its own thread. > > > > > > All (not just some or one) of the following questions need to be > > > answered positively and definitively in order for your Cell-id > > > scenario to work in IP. > > > > > > Where is the Cell-id to PSAP URI mapping done? > > > > > > What database has this information? > > > > > > What IP protocol is used to resolve this mapping of Cell-id to > > > (appropriate) PSAP? > > > > > > Where is this IP-based server located? > > > > > > How can LoST be used to discover this? > > > > > > What LCP will give this Cell-id to a phone to include in a > > SIP message? > > > > > > What SIP header is this information placed in? > > > > > > What form does this Cell-id have in the SIP header from the > > previous > > > question? > > > > > > What IETF document(s) specifies this header and Cell-id form? > > > > > > James > > > > > > > > > _______________________________________________ > > > 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 ecrit-bounces@ietf.org Wed Mar 5 13:57:10 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531C328C6B7; Wed, 5 Mar 2008 13:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.486 X-Spam-Level: X-Spam-Status: No, score=-100.486 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ezqNAcKIOoj; Wed, 5 Mar 2008 13:57:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7878928C396; Wed, 5 Mar 2008 13:57:09 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ADA33A688E for ; Wed, 5 Mar 2008 13:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZFmSi+eb3im for ; Wed, 5 Mar 2008 13:57:04 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id A3D7B3A68B5 for ; Wed, 5 Mar 2008 13:57:04 -0800 (PST) X-SEF-Processed: 5_0_0_910__2008_03_05_16_09_34 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 05 Mar 2008 16:09:34 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Mar 2008 15:56:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 15:56:52 -0600 Message-ID: In-Reply-To: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) Thread-Index: Ach+9y5eI086D2zvSn+r/wfv6bnvUAAAtK2AAARnZSA= References: <47CAE9CA.9010901@gmx.net> <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "James M. Polk" , , , X-OriginalArrivalTime: 05 Mar 2008 21:56:54.0170 (UTC) FILETIME=[D30447A0:01C87F0B] Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If the Cell-ID is a full 3GPP CGI, then the country and network codes are included in the identifier. To that end a CGI is kind of URI already. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Thursday, 6 March 2008 6:53 AM > To: 'James M. Polk'; Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > The basic agreement we have made, in NENA, is that the operator will agree > with the PSAP on a location for the cellid. This could be a point or a > polygon. That location will be reported, in PIDF-LO form, from the LIS. > There was a discussion about actually allowing a cell-id as an alternate > form of location representation, but it was decided not to do that. A LIS > could, of course, construct a location reference of the form > sip:@opco.net, and send that. When dereferenced, it would return > the agreed-upon location. > > Brian > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > James M. Polk > > Sent: Wednesday, March 05, 2008 2:29 PM > > To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > >Cell-id is an identifier of a geographical area which is mapped to psap > > >already in today's databases. If you'll make an IP based emergency call > > >on cellular, that will use now and for many years to come the cell-id > to > > >select the psap where to direct your call. GAbor > > > > let's discuss this topic as its own thread. > > > > All (not just some or one) of the following questions need to be > > answered positively and definitively in order for your Cell-id > > scenario to work in IP. > > > > Where is the Cell-id to PSAP URI mapping done? > > > > What database has this information? > > > > What IP protocol is used to resolve this mapping of Cell-id to > > (appropriate) PSAP? > > > > Where is this IP-based server located? > > > > How can LoST be used to discover this? > > > > What LCP will give this Cell-id to a phone to include in a SIP message? > > > > What SIP header is this information placed in? > > > > What form does this Cell-id have in the SIP header from the previous > > question? > > > > What IETF document(s) specifies this header and Cell-id form? > > > > James > > > > > > _______________________________________________ > > 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 ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 5 14:20:59 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D4428C2EB; Wed, 5 Mar 2008 14:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.822 X-Spam-Level: X-Spam-Status: No, score=-100.822 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql2Ex+XliS4l; Wed, 5 Mar 2008 14:20:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0D093A685A; Wed, 5 Mar 2008 14:20:53 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9053A6884 for ; Wed, 5 Mar 2008 14:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S297gucyiL5M for ; Wed, 5 Mar 2008 14:20:51 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 30FE23A68E2 for ; Wed, 5 Mar 2008 14:20:51 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m25MKcR5008396; Wed, 5 Mar 2008 16:21:15 -0600 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 00:18:45 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Mar 2008 16:18:37 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 16:18:36 -0600 Message-ID: In-Reply-To: <00b401c87f02$89eafcc0$270d0d0a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) Thread-Index: Ach+9y5eI086D2zvSn+r/wfv6bnvUAAAtK2AAAD/tFAAA1W/wA== References: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com> <00b401c87f02$89eafcc0$270d0d0a@cisco.com> From: To: , , X-OriginalArrivalTime: 05 Mar 2008 22:18:37.0661 (UTC) FILETIME=[DBF538D0:01C87F0E] X-Nokia-AV: Clean Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Right. But that means relaxing the requirement "8. section 6.1 "Other forms of location representation must be mapped into either a geo or civic for use in emergency calls" in the draft and allow other type of location information, all those which make sense in their specific context. Gabor -----Original Message----- From: ext Marc Linsner [mailto:mlinsner@cisco.com] Sent: Wednesday, March 05, 2008 12:50 PM To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); ecrit@ietf.org Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) Of course there is no reason the operator couldn't provide civic location (123 Main St.) in place of cell-id either (verses a geo location). The main objective is to have location information in the device such that it makes sense to the consumer vs. every context having their own location descriptions (cell-id, water meter number, telephone pole id, property tax plat number, fire hydrant inventory id, msag address, etc.). -Marc- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Wednesday, March 05, 2008 2:53 PM > To: 'James M. Polk'; Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > The basic agreement we have made, in NENA, is that the operator will > agree with the PSAP on a location for the cellid. This could be a > point or a polygon. That location will be reported, in PIDF-LO form, > from the LIS. > There was a discussion about actually allowing a cell-id as an > alternate form of location representation, but it was decided not to > do that. A LIS could, of course, construct a location reference of > the form sip:@opco.net, and send that. When dereferenced, it > would return the agreed-upon location. > > Brian > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of James M. Polk > > Sent: Wednesday, March 05, 2008 2:29 PM > > To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > >Cell-id is an identifier of a geographical area which is mapped to > > >psap already in today's databases. If you'll make an IP based > > >emergency call on cellular, that will use now and for many > years to > > >come the cell-id to select the psap where to direct your > call. GAbor > > > > let's discuss this topic as its own thread. > > > > All (not just some or one) of the following questions need to be > > answered positively and definitively in order for your Cell-id > > scenario to work in IP. > > > > Where is the Cell-id to PSAP URI mapping done? > > > > What database has this information? > > > > What IP protocol is used to resolve this mapping of Cell-id to > > (appropriate) PSAP? > > > > Where is this IP-based server located? > > > > How can LoST be used to discover this? > > > > What LCP will give this Cell-id to a phone to include in a > SIP message? > > > > What SIP header is this information placed in? > > > > What form does this Cell-id have in the SIP header from the > previous > > question? > > > > What IETF document(s) specifies this header and Cell-id form? > > > > James > > > > > > _______________________________________________ > > 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 ecrit-bounces@ietf.org Wed Mar 5 14:42:56 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B55D828C80D; Wed, 5 Mar 2008 14:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.979 X-Spam-Level: X-Spam-Status: No, score=-100.979 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9s9KfB+Iyvj5; Wed, 5 Mar 2008 14:42:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 972963A685A; Wed, 5 Mar 2008 14:42:55 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D943A685A for ; Wed, 5 Mar 2008 14:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7N6VJ061K3xc for ; Wed, 5 Mar 2008 14:42:52 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 88D863A67B6 for ; Wed, 5 Mar 2008 14:42:52 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 05 Mar 2008 14:42:42 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m25Mgg9d004325; Wed, 5 Mar 2008 14:42:42 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m25MgZM1006197; Wed, 5 Mar 2008 22:42:40 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Mar 2008 14:42:37 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.80.13]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Mar 2008 14:42:36 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 05 Mar 2008 16:42:35 -0600 To: , , , From: "James M. Polk" In-Reply-To: References: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com> <00b401c87f02$89eafcc0$270d0d0a@cisco.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 05 Mar 2008 22:42:36.0802 (UTC) FILETIME=[35C0B620:01C87F12] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4377; t=1204756962; x=1205620962; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20WGLC=20on=20draft-ietf-ecrit- phonebcp-04=20(cell-id) |Sender:=20; bh=p7lfm2prwalGP61gCuhpbNVwexO3i+Pf1HXUv6r044Y=; b=Mgcn2vnh/QkNqrrhLXfT2aWyGfBBXTFFvWGtsNkcrBIhwSKDAvEuJ/894S UggUxvXnZNPBjqBl5oM171POq9Hq0747SPgnTpppIvoYNqEFAW8hdBdJnItw ConlDGBpkSrMSXAcMemclnb6sU61jbjmvKszCRSoJTd7f6VPvgCVk=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: >Right. But that means relaxing the requirement "8. section 6.1 >"Other forms of location representation must be mapped into either a geo >or civic for use in emergency calls" in the draft and allow other type >of location information, all those which make sense in their specific >context. I don't understand why you want anything relaxed. The requirement says PIDF-LO is the only location format to be used, and that the is geo or civic. This is a MUST for interoperability reasons. Cell-id doesn't accomplish this. >Gabor > >-----Original Message----- >From: ext Marc Linsner [mailto:mlinsner@cisco.com] >Sent: Wednesday, March 05, 2008 12:50 PM >To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); ecrit@ietf.org >Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > >Of course there is no reason the operator couldn't provide civic >location >(123 Main St.) in place of cell-id either (verses a geo location). The >main objective is to have location information in the device such that >it makes sense to the consumer vs. every context having their own >location descriptions (cell-id, water meter number, telephone pole id, >property tax plat number, fire hydrant inventory id, msag address, >etc.). > >-Marc- > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Brian Rosen > > Sent: Wednesday, March 05, 2008 2:53 PM > > To: 'James M. Polk'; Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > > > ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > The basic agreement we have made, in NENA, is that the operator will > > agree with the PSAP on a location for the cellid. This could be a > > point or a polygon. That location will be reported, in PIDF-LO form, > > from the LIS. > > There was a discussion about actually allowing a cell-id as an > > alternate form of location representation, but it was decided not to > > do that. A LIS could, of course, construct a location reference of > > the form sip:@opco.net, and send that. When dereferenced, it > > > would return the agreed-upon location. > > > > Brian > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of James M. Polk > > > Sent: Wednesday, March 05, 2008 2:29 PM > > > To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > >Cell-id is an identifier of a geographical area which is mapped to > > > >psap already in today's databases. If you'll make an IP based > > > >emergency call on cellular, that will use now and for many > > years to > > > >come the cell-id to select the psap where to direct your > > call. GAbor > > > > > > let's discuss this topic as its own thread. > > > > > > All (not just some or one) of the following questions need to be > > > answered positively and definitively in order for your Cell-id > > > scenario to work in IP. > > > > > > Where is the Cell-id to PSAP URI mapping done? > > > > > > What database has this information? > > > > > > What IP protocol is used to resolve this mapping of Cell-id to > > > (appropriate) PSAP? > > > > > > Where is this IP-based server located? > > > > > > How can LoST be used to discover this? > > > > > > What LCP will give this Cell-id to a phone to include in a > > SIP message? > > > > > > What SIP header is this information placed in? > > > > > > What form does this Cell-id have in the SIP header from the > > previous > > > question? > > > > > > What IETF document(s) specifies this header and Cell-id form? > > > > > > James > > > > > > > > > _______________________________________________ > > > 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 ecrit-bounces@ietf.org Wed Mar 5 14:51:36 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33DC33A6861; Wed, 5 Mar 2008 14:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.899 X-Spam-Level: X-Spam-Status: No, score=-100.899 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HySOKaeVq2tQ; Wed, 5 Mar 2008 14:51:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 389E728C381; Wed, 5 Mar 2008 14:51:35 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85DB628C47F for ; Wed, 5 Mar 2008 14:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uZpXIswB80e for ; Wed, 5 Mar 2008 14:51:32 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2DE003A689F for ; Wed, 5 Mar 2008 14:51:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,452,1199682000"; d="scan'208";a="597702" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 05 Mar 2008 17:51:20 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m25MpLQd032423; Wed, 5 Mar 2008 17:51:21 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m25MpLaZ029027; Wed, 5 Mar 2008 22:51:21 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Mar 2008 17:51:21 -0500 Received: from mlinsnerwxp02 ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Mar 2008 17:51:20 -0500 From: "Marc Linsner" To: , , Date: Wed, 5 Mar 2008 17:51:20 -0500 Message-ID: <00d001c87f13$6e09eeb0$270d0d0a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Ach+9y5eI086D2zvSn+r/wfv6bnvUAAAtK2AAAD/tFAAA1W/wAAB8UUQ In-Reply-To: X-OriginalArrivalTime: 05 Mar 2008 22:51:20.0883 (UTC) FILETIME=[6E212030:01C87F13] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4250; t=1204757481; x=1205621481; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20WGLC=20on=20draft-ietf-ecrit- phonebcp-04=20(cell-id) |Sender:=20 |To:=20,=20,=20; bh=C4FHk2jPXyFZmCVKzYi6EzLDt9Ix99TihCRGoOoe9bk=; b=cKljjKd4eBdB1j7tA1v6LDOLUq9x/ifjCnuXf4x16CwBgp5V7qvvjf87CI q4EMdysTjqL4/jmjKcF37Xs2qM/NIQHRNnMVJSB91Guhs8mtXzdHDKOyOqNx xMUmkfr4eP; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Gabor, Sorry, I think there is a misunderstanding. I meant to state that context specific location descriptions should NOT be allowed, which lines up with the requirement you cite. -Marc- > > Right. But that means relaxing the requirement "8. section > 6.1 "Other forms of location representation must be mapped > into either a geo or civic for use in emergency calls" in the > draft and allow other type of location information, all those > which make sense in their specific context. > > Gabor > > -----Original Message----- > From: ext Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Wednesday, March 05, 2008 12:50 PM > To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); ecrit@ietf.org > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > Of course there is no reason the operator couldn't provide > civic location > (123 Main St.) in place of cell-id either (verses a geo > location). The main objective is to have location > information in the device such that it makes sense to the > consumer vs. every context having their own location > descriptions (cell-id, water meter number, telephone pole id, > property tax plat number, fire hydrant inventory id, msag > address, etc.). > > -Marc- > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Brian Rosen > > Sent: Wednesday, March 05, 2008 2:53 PM > > To: 'James M. Polk'; Gabor.Bajko@nokia.com; > Hannes.Tschofenig@gmx.net; > > > ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > The basic agreement we have made, in NENA, is that the > operator will > > agree with the PSAP on a location for the cellid. This could be a > > point or a polygon. That location will be reported, in > PIDF-LO form, > > from the LIS. > > There was a discussion about actually allowing a cell-id as an > > alternate form of location representation, but it was > decided not to > > do that. A LIS could, of course, construct a location reference of > > the form sip:@opco.net, and send that. When > dereferenced, it > > > would return the agreed-upon location. > > > > Brian > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of James M. Polk > > > Sent: Wednesday, March 05, 2008 2:29 PM > > > To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > ecrit@ietf.org > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > (cell-id) > > > > > > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > >Cell-id is an identifier of a geographical area which is > mapped to > > > >psap already in today's databases. If you'll make an IP based > > > >emergency call on cellular, that will use now and for many > > years to > > > >come the cell-id to select the psap where to direct your > > call. GAbor > > > > > > let's discuss this topic as its own thread. > > > > > > All (not just some or one) of the following questions need to be > > > answered positively and definitively in order for your Cell-id > > > scenario to work in IP. > > > > > > Where is the Cell-id to PSAP URI mapping done? > > > > > > What database has this information? > > > > > > What IP protocol is used to resolve this mapping of Cell-id to > > > (appropriate) PSAP? > > > > > > Where is this IP-based server located? > > > > > > How can LoST be used to discover this? > > > > > > What LCP will give this Cell-id to a phone to include in a > > SIP message? > > > > > > What SIP header is this information placed in? > > > > > > What form does this Cell-id have in the SIP header from the > > previous > > > question? > > > > > > What IETF document(s) specifies this header and Cell-id form? > > > > > > James > > > > > > > > > _______________________________________________ > > > 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 ecrit-bounces@ietf.org Wed Mar 5 14:52:01 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A80263A68D0; Wed, 5 Mar 2008 14:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.574 X-Spam-Level: X-Spam-Status: No, score=-100.574 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liqr4y69YWfI; Wed, 5 Mar 2008 14:52:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74DE28C47F; Wed, 5 Mar 2008 14:52:00 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C6928C47F for ; Wed, 5 Mar 2008 14:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJZrtk-abAFq for ; Wed, 5 Mar 2008 14:51:59 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 2F6953A68D0 for ; Wed, 5 Mar 2008 14:51:59 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JX2Sb-00020J-TJ; Wed, 05 Mar 2008 16:51:42 -0600 From: "Brian Rosen" To: "'Winterbottom, James'" , "'James M. Polk'" , , , References: <47CAE9CA.9010901@gmx.net> <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com> Date: Wed, 5 Mar 2008 17:51:44 -0500 Message-ID: <01bd01c87f13$7ebb2800$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Ach+9y5eI086D2zvSn+r/wfv6bnvUAAAtK2AAARnZSAAAcbbMA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I assume this is just for our general knowledge, rather than part of a proposal to change -phonebcp. For one thing, emergency calls use sector as well as cell site. Generally, we don't recommend using some kind of construction rule where the recipient is supposed to break apart the URI and use the components. If parameters have to be passed, we use URI parameters. Also, I really would rather see "opaque" identifiers, but it's not all that important in the case we're discussing. At any rate MCC-MNC-CellId is not a URI, I don't think anyone is going to propose that we create a URI for it, and I don't read your response as suggesting a change in -phonebcp. Is that correct? Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Wednesday, March 05, 2008 4:57 PM > To: Brian Rosen; James M. Polk; Gabor.Bajko@nokia.com; > Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > If the Cell-ID is a full 3GPP CGI, then the country and network codes > are included in the identifier. To that end a CGI is kind of URI > already. > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Brian Rosen > > Sent: Thursday, 6 March 2008 6:53 AM > > To: 'James M. Polk'; Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > > ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > The basic agreement we have made, in NENA, is that the operator will > agree > > with the PSAP on a location for the cellid. This could be a point or > a > > polygon. That location will be reported, in PIDF-LO form, from the > LIS. > > There was a discussion about actually allowing a cell-id as an > alternate > > form of location representation, but it was decided not to do that. A > LIS > > could, of course, construct a location reference of the form > > sip:@opco.net, and send that. When dereferenced, it would > return > > the agreed-upon location. > > > > Brian > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > > Of > > > James M. Polk > > > Sent: Wednesday, March 05, 2008 2:29 PM > > > To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > >Cell-id is an identifier of a geographical area which is mapped to > psap > > > >already in today's databases. If you'll make an IP based emergency > call > > > >on cellular, that will use now and for many years to come the > cell-id > > to > > > >select the psap where to direct your call. GAbor > > > > > > let's discuss this topic as its own thread. > > > > > > All (not just some or one) of the following questions need to be > > > answered positively and definitively in order for your Cell-id > > > scenario to work in IP. > > > > > > Where is the Cell-id to PSAP URI mapping done? > > > > > > What database has this information? > > > > > > What IP protocol is used to resolve this mapping of Cell-id to > > > (appropriate) PSAP? > > > > > > Where is this IP-based server located? > > > > > > How can LoST be used to discover this? > > > > > > What LCP will give this Cell-id to a phone to include in a SIP > message? > > > > > > What SIP header is this information placed in? > > > > > > What form does this Cell-id have in the SIP header from the previous > > > question? > > > > > > What IETF document(s) specifies this header and Cell-id form? > > > > > > James > > > > > > > > > _______________________________________________ > > > 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 > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 5 15:04:03 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 695BD3A6959; Wed, 5 Mar 2008 15:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.486 X-Spam-Level: X-Spam-Status: No, score=-100.486 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bznOtldW4wSw; Wed, 5 Mar 2008 15:04:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E4D33A69A4; Wed, 5 Mar 2008 15:04:02 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A1C43A67B6 for ; Wed, 5 Mar 2008 15:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY58LiOXLAg5 for ; Wed, 5 Mar 2008 15:03:59 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 3EAE228C2EB for ; Wed, 5 Mar 2008 15:03:30 -0800 (PST) X-SEF-Processed: 5_0_0_910__2008_03_05_17_16_00 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 05 Mar 2008 17:16:00 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Mar 2008 17:03:20 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 17:03:18 -0600 Message-ID: In-Reply-To: <01bd01c87f13$7ebb2800$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) Thread-Index: Ach+9y5eI086D2zvSn+r/wfv6bnvUAAAtK2AAARnZSAAAcbbMAAARDZQ References: <47CAE9CA.9010901@gmx.net> <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com> <01bd01c87f13$7ebb2800$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "James M. Polk" , , , X-OriginalArrivalTime: 05 Mar 2008 23:03:20.0402 (UTC) FILETIME=[1AFF0320:01C87F15] Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yup, just general knowledge. The way in which this work, at least for GSM, is that each "sector" is in fact provisioned as a separate cell-id, so you get that for free. A URI by definition has to be broken apart to work out the different parts, so I am not sure I understand what it is you are trying to say. A particular URI type has ABNF which defines the parts and allows it to be easily pulled apart. The MCC-MNC-LAC-CELL form of a 3GPP Cell-id is like wise well understood in cellular circles. Cheers James > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, 6 March 2008 9:52 AM > To: Winterbottom, James; 'James M. Polk'; Gabor.Bajko@nokia.com; > Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > I assume this is just for our general knowledge, rather than part of a > proposal to change -phonebcp. For one thing, emergency calls use sector > as > well as cell site. Generally, we don't recommend using some kind of > construction rule where the recipient is supposed to break apart the URI > and > use the components. If parameters have to be passed, we use URI > parameters. > > Also, I really would rather see "opaque" identifiers, but it's not all > that > important in the case we're discussing. > > At any rate MCC-MNC-CellId is not a URI, I don't think anyone is going to > propose that we create a URI for it, and I don't read your response as > suggesting a change in -phonebcp. > > Is that correct? > > Brian > > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Wednesday, March 05, 2008 4:57 PM > > To: Brian Rosen; James M. Polk; Gabor.Bajko@nokia.com; > > Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > If the Cell-ID is a full 3GPP CGI, then the country and network codes > > are included in the identifier. To that end a CGI is kind of URI > > already. > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > Of > > > Brian Rosen > > > Sent: Thursday, 6 March 2008 6:53 AM > > > To: 'James M. Polk'; Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > > > ecrit@ietf.org > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > The basic agreement we have made, in NENA, is that the operator will > > agree > > > with the PSAP on a location for the cellid. This could be a point or > > a > > > polygon. That location will be reported, in PIDF-LO form, from the > > LIS. > > > There was a discussion about actually allowing a cell-id as an > > alternate > > > form of location representation, but it was decided not to do that. A > > LIS > > > could, of course, construct a location reference of the form > > > sip:@opco.net, and send that. When dereferenced, it would > > return > > > the agreed-upon location. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > Behalf > > > Of > > > > James M. Polk > > > > Sent: Wednesday, March 05, 2008 2:29 PM > > > > To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > > > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > > >Cell-id is an identifier of a geographical area which is mapped to > > psap > > > > >already in today's databases. If you'll make an IP based emergency > > call > > > > >on cellular, that will use now and for many years to come the > > cell-id > > > to > > > > >select the psap where to direct your call. GAbor > > > > > > > > let's discuss this topic as its own thread. > > > > > > > > All (not just some or one) of the following questions need to be > > > > answered positively and definitively in order for your Cell-id > > > > scenario to work in IP. > > > > > > > > Where is the Cell-id to PSAP URI mapping done? > > > > > > > > What database has this information? > > > > > > > > What IP protocol is used to resolve this mapping of Cell-id to > > > > (appropriate) PSAP? > > > > > > > > Where is this IP-based server located? > > > > > > > > How can LoST be used to discover this? > > > > > > > > What LCP will give this Cell-id to a phone to include in a SIP > > message? > > > > > > > > What SIP header is this information placed in? > > > > > > > > What form does this Cell-id have in the SIP header from the previous > > > > question? > > > > > > > > What IETF document(s) specifies this header and Cell-id form? > > > > > > > > James > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 5 16:24:39 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AC2C28C475; Wed, 5 Mar 2008 16:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.575 X-Spam-Level: X-Spam-Status: No, score=-100.575 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ut8ngwRzPDsS; Wed, 5 Mar 2008 16:24:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C262F28C4B6; Wed, 5 Mar 2008 16:24:37 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE9028C4B6 for ; Wed, 5 Mar 2008 16:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msr0Gh4+eBWZ for ; Wed, 5 Mar 2008 16:24:35 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id CECE828C800 for ; Wed, 5 Mar 2008 16:23:54 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JX3tY-0008WC-Kb; Wed, 05 Mar 2008 18:23:37 -0600 From: "Brian Rosen" To: "'Winterbottom, James'" , "'James M. Polk'" , , , References: <47CAE9CA.9010901@gmx.net> <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com> <01bd01c87f13$7ebb2800$640fa8c0@cis.neustar.com> Date: Wed, 5 Mar 2008 19:23:40 -0500 Message-ID: <01d301c87f20$561002b0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Ach+9y5eI086D2zvSn+r/wfv6bnvUAAAtK2AAARnZSAAAcbbMAAARDZQAALzc4A= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Okay, thanks, I didn't know the sector bit. All I meant was that we don't usually recommend something like expecting the client to construct a URI by concatenating mcc-mnc-lac-cell@opco.net, and expecting the server to parse the userpart of the URI to extract the components. There isn't anything wrong with the server constructing a URI any way it wants, even the example above, and giving it to the client for use as long as it's not expecting the client to be able to discern the components by parsing. I didn't think you were proposing that. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Wednesday, March 05, 2008 6:03 PM > To: Brian Rosen; James M. Polk; Gabor.Bajko@nokia.com; > Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > Yup, just general knowledge. > > The way in which this work, at least for GSM, is that each "sector" is > in fact provisioned as a separate cell-id, so you get that for free. > > A URI by definition has to be broken apart to work out the different > parts, so I am not sure I understand what it is you are trying to say. A > particular URI type has ABNF which defines the parts and allows it to be > easily pulled apart. The MCC-MNC-LAC-CELL form of a 3GPP Cell-id is like > wise well understood in cellular circles. > > Cheers > James > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, 6 March 2008 9:52 AM > > To: Winterbottom, James; 'James M. Polk'; Gabor.Bajko@nokia.com; > > Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > I assume this is just for our general knowledge, rather than part of a > > proposal to change -phonebcp. For one thing, emergency calls use > sector > > as > > well as cell site. Generally, we don't recommend using some kind of > > construction rule where the recipient is supposed to break apart the > URI > > and > > use the components. If parameters have to be passed, we use URI > > parameters. > > > > Also, I really would rather see "opaque" identifiers, but it's not all > > that > > important in the case we're discussing. > > > > At any rate MCC-MNC-CellId is not a URI, I don't think anyone is going > to > > propose that we create a URI for it, and I don't read your response as > > suggesting a change in -phonebcp. > > > > Is that correct? > > > > Brian > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Wednesday, March 05, 2008 4:57 PM > > > To: Brian Rosen; James M. Polk; Gabor.Bajko@nokia.com; > > > Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > If the Cell-ID is a full 3GPP CGI, then the country and network > codes > > > are included in the identifier. To that end a CGI is kind of URI > > > already. > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > > > Of > > > > Brian Rosen > > > > Sent: Thursday, 6 March 2008 6:53 AM > > > > To: 'James M. Polk'; Gabor.Bajko@nokia.com; > Hannes.Tschofenig@gmx.net; > > > > ecrit@ietf.org > > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > (cell-id) > > > > > > > > The basic agreement we have made, in NENA, is that the operator > will > > > agree > > > > with the PSAP on a location for the cellid. This could be a point > or > > > a > > > > polygon. That location will be reported, in PIDF-LO form, from > the > > > LIS. > > > > There was a discussion about actually allowing a cell-id as an > > > alternate > > > > form of location representation, but it was decided not to do > that. A > > > LIS > > > > could, of course, construct a location reference of the form > > > > sip:@opco.net, and send that. When dereferenced, it > would > > > return > > > > the agreed-upon location. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > > Behalf > > > > Of > > > > > James M. Polk > > > > > Sent: Wednesday, March 05, 2008 2:29 PM > > > > > To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > ecrit@ietf.org > > > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > (cell-id) > > > > > > > > > > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > > > >Cell-id is an identifier of a geographical area which is mapped > to > > > psap > > > > > >already in today's databases. If you'll make an IP based > emergency > > > call > > > > > >on cellular, that will use now and for many years to come the > > > cell-id > > > > to > > > > > >select the psap where to direct your call. GAbor > > > > > > > > > > let's discuss this topic as its own thread. > > > > > > > > > > All (not just some or one) of the following questions need to be > > > > > answered positively and definitively in order for your Cell-id > > > > > scenario to work in IP. > > > > > > > > > > Where is the Cell-id to PSAP URI mapping done? > > > > > > > > > > What database has this information? > > > > > > > > > > What IP protocol is used to resolve this mapping of Cell-id to > > > > > (appropriate) PSAP? > > > > > > > > > > Where is this IP-based server located? > > > > > > > > > > How can LoST be used to discover this? > > > > > > > > > > What LCP will give this Cell-id to a phone to include in a SIP > > > message? > > > > > > > > > > What SIP header is this information placed in? > > > > > > > > > > What form does this Cell-id have in the SIP header from the > previous > > > > > question? > > > > > > > > > > What IETF document(s) specifies this header and Cell-id form? > > > > > > > > > > James > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > [mf2] > > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 5 23:08:06 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D27C28C841; Wed, 5 Mar 2008 23:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.816 X-Spam-Level: X-Spam-Status: No, score=-100.816 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwtWN15QuaK9; Wed, 5 Mar 2008 23:08:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EFCB28C806; Wed, 5 Mar 2008 23:08:05 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5E2528C806 for ; Wed, 5 Mar 2008 23:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3OLq08cavZX for ; Wed, 5 Mar 2008 23:08:02 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 4290228C6C9 for ; Wed, 5 Mar 2008 23:08:02 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m2677bBn027898; Thu, 6 Mar 2008 09:07:40 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 09:06:22 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 01:06:20 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 01:06:19 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) Thread-Index: Ach/Ej7OZvJpRgrfRqW3DGUTIud3mQAMW7DA References: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com><00b401c87f02$89eafcc0$270d0d0a@cisco.com> From: To: , , , X-OriginalArrivalTime: 06 Mar 2008 07:06:20.0267 (UTC) FILETIME=[94577BB0:01C87F58] X-Nokia-AV: Clean Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The cell-id (cgi) is a global, well defined and understood in the cellular world. There are no interoperability issues with it. If you think otherwise, please give examples. Pidf-lo is an object which encapsulates preexisting location information but it does not define the format of it. - gabor -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of ext James M. Polk Sent: Wednesday, March 05, 2008 2:43 PM To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; br@brianrosen.net; ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: >Right. But that means relaxing the requirement "8. section 6.1 "Other >forms of location representation must be mapped into either a geo or >civic for use in emergency calls" in the draft and allow other type of >location information, all those which make sense in their specific >context. I don't understand why you want anything relaxed. The requirement says PIDF-LO is the only location format to be used, and that the is geo or civic. This is a MUST for interoperability reasons. Cell-id doesn't accomplish this. >Gabor > >-----Original Message----- >From: ext Marc Linsner [mailto:mlinsner@cisco.com] >Sent: Wednesday, March 05, 2008 12:50 PM >To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); ecrit@ietf.org >Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > >Of course there is no reason the operator couldn't provide civic >location >(123 Main St.) in place of cell-id either (verses a geo location). The >main objective is to have location information in the device such that >it makes sense to the consumer vs. every context having their own >location descriptions (cell-id, water meter number, telephone pole id, >property tax plat number, fire hydrant inventory id, msag address, >etc.). > >-Marc- > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > Behalf > > > Of Brian Rosen > > Sent: Wednesday, March 05, 2008 2:53 PM > > To: 'James M. Polk'; Gabor.Bajko@nokia.com; > > Hannes.Tschofenig@gmx.net; > > > ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > The basic agreement we have made, in NENA, is that the operator will > > agree with the PSAP on a location for the cellid. This could be a > > point or a polygon. That location will be reported, in PIDF-LO > > form, from the LIS. > > There was a discussion about actually allowing a cell-id as an > > alternate form of location representation, but it was decided not to > > do that. A LIS could, of course, construct a location reference of > > the form sip:@opco.net, and send that. When dereferenced, > > it > > > would return the agreed-upon location. > > > > Brian > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of James M. Polk > > > Sent: Wednesday, March 05, 2008 2:29 PM > > > To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > > > ecrit@ietf.org > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > (cell-id) > > > > > > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > >Cell-id is an identifier of a geographical area which is mapped > > > >to psap already in today's databases. If you'll make an IP based > > > >emergency call on cellular, that will use now and for many > > years to > > > >come the cell-id to select the psap where to direct your > > call. GAbor > > > > > > let's discuss this topic as its own thread. > > > > > > All (not just some or one) of the following questions need to be > > > answered positively and definitively in order for your Cell-id > > > scenario to work in IP. > > > > > > Where is the Cell-id to PSAP URI mapping done? > > > > > > What database has this information? > > > > > > What IP protocol is used to resolve this mapping of Cell-id to > > > (appropriate) PSAP? > > > > > > Where is this IP-based server located? > > > > > > How can LoST be used to discover this? > > > > > > What LCP will give this Cell-id to a phone to include in a > > SIP message? > > > > > > What SIP header is this information placed in? > > > > > > What form does this Cell-id have in the SIP header from the > > previous > > > question? > > > > > > What IETF document(s) specifies this header and Cell-id form? > > > > > > James > > > > > > > > > _______________________________________________ > > > 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 5 23:17:00 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C86CF28C76D; Wed, 5 Mar 2008 23:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.671 X-Spam-Level: X-Spam-Status: No, score=-100.671 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfMxuV-7xM46; Wed, 5 Mar 2008 23:16:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC8E128C64F; Wed, 5 Mar 2008 23:16:56 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFC293A686E for ; Wed, 5 Mar 2008 23:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVitSU1uhKXG for ; Wed, 5 Mar 2008 23:16:55 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 8145A28C489 for ; Wed, 5 Mar 2008 23:16:54 -0800 (PST) Received: (qmail 5075 invoked by uid 0); 6 Mar 2008 07:16:43 -0000 Received: from 192.100.124.219 by www169.gmx.net with HTTP; Thu, 06 Mar 2008 08:16:42 +0100 (CET) Date: Thu, 06 Mar 2008 08:16:42 +0100 From: "Hannes Tschofenig" In-Reply-To: <019d01c87f04$12d67360$640fa8c0@cis.neustar.com> Message-ID: <20080306071642.23460@gmx.net> MIME-Version: 1.0 References: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com> <00b401c87f02$89eafcc0$270d0d0a@cisco.com> <019d01c87f04$12d67360$640fa8c0@cis.neustar.com> To: "Brian Rosen" , ecrit@ietf.org, Gabor.Bajko@nokia.com, mlinsner@cisco.com X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX18YQI8AgWEYQCLZtvaXzT8A2rhNf7WNYQ3hVfTIQB 0BJDFaGK45z7Z+qhNApD/zX1j1kxr5eawpQw== X-GMX-UID: P/OqBkR9fW47Wsk5tWRopnBudmllcoVf Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org You might want to consider that cell-id information is already available in these networks today whereas using a protocol to translate cell-ids into location is not. -------- Original-Nachricht -------- > Datum: Wed, 5 Mar 2008 16:01:22 -0500 > Von: "Brian Rosen" > An: "\'Marc Linsner\'" , Gabor.Bajko@nokia.com, ecrit@ietf.org > Betreff: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > Certainly. You can return a civic as the location of the cell. They do > that in many cases now. > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Wednesday, March 05, 2008 3:50 PM > > To: 'Brian Rosen'; Gabor.Bajko@nokia.com; ecrit@ietf.org > > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > Of course there is no reason the operator couldn't provide civic > location > > (123 Main St.) in place of cell-id either (verses a geo location). The > > main > > objective is to have location information in the device such that it > makes > > sense to the consumer vs. every context having their own location > > descriptions (cell-id, water meter number, telephone pole id, property > tax > > plat number, fire hydrant inventory id, msag address, etc.). > > > > -Marc- > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > > On Behalf Of Brian Rosen > > > Sent: Wednesday, March 05, 2008 2:53 PM > > > To: 'James M. Polk'; Gabor.Bajko@nokia.com; > > > Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > The basic agreement we have made, in NENA, is that the > > > operator will agree with the PSAP on a location for the > > > cellid. This could be a point or a polygon. That location > > > will be reported, in PIDF-LO form, from the LIS. > > > There was a discussion about actually allowing a cell-id as > > > an alternate form of location representation, but it was > > > decided not to do that. A LIS could, of course, construct a > > > location reference of the form sip:@opco.net, and > > > send that. When dereferenced, it would return the > > > agreed-upon location. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of James M. Polk > > > > Sent: Wednesday, March 05, 2008 2:29 PM > > > > To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > > > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > > >Cell-id is an identifier of a geographical area which is mapped to > > > > >psap already in today's databases. If you'll make an IP based > > > > >emergency call on cellular, that will use now and for many > > > years to > > > > >come the cell-id to select the psap where to direct your > > > call. GAbor > > > > > > > > let's discuss this topic as its own thread. > > > > > > > > All (not just some or one) of the following questions need to be > > > > answered positively and definitively in order for your Cell-id > > > > scenario to work in IP. > > > > > > > > Where is the Cell-id to PSAP URI mapping done? > > > > > > > > What database has this information? > > > > > > > > What IP protocol is used to resolve this mapping of Cell-id to > > > > (appropriate) PSAP? > > > > > > > > Where is this IP-based server located? > > > > > > > > How can LoST be used to discover this? > > > > > > > > What LCP will give this Cell-id to a phone to include in a > > > SIP message? > > > > > > > > What SIP header is this information placed in? > > > > > > > > What form does this Cell-id have in the SIP header from the > > > previous > > > > question? > > > > > > > > What IETF document(s) specifies this header and Cell-id form? > > > > > > > > James > > > > > > > > > > > > _______________________________________________ > > > > 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 ecrit-bounces@ietf.org Wed Mar 5 23:20:25 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A3D828C489; Wed, 5 Mar 2008 23:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.68 X-Spam-Level: X-Spam-Status: No, score=-100.68 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUwyIN6KTXZO; Wed, 5 Mar 2008 23:20:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F7343A68D6; Wed, 5 Mar 2008 23:20:24 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0DDD3A686E for ; Wed, 5 Mar 2008 23:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2S4SJTXiNf+z for ; Wed, 5 Mar 2008 23:20:21 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1A5BB3A68D6 for ; Wed, 5 Mar 2008 23:20:20 -0800 (PST) Received: (qmail 19039 invoked by uid 0); 6 Mar 2008 07:20:10 -0000 Received: from 192.100.124.219 by www169.gmx.net with HTTP; Thu, 06 Mar 2008 08:20:09 +0100 (CET) Date: Thu, 06 Mar 2008 08:20:09 +0100 From: "Hannes Tschofenig" In-Reply-To: Message-ID: <20080306072009.23430@gmx.net> MIME-Version: 1.0 References: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com> <00b401c87f02$89eafcc0$270d0d0a@cisco.com> To: "James M. Polk" , ecrit@ietf.org, br@brianrosen.net, mlinsner@cisco.com, Gabor.Bajko@nokia.com X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1/DLRV23PfDJdbAT/Id7+vBgzH9U0gFacwOhbZuO8 9wxKAPsk9sFqPswABFh4+EOYkUfXDzSetSRQ== X-GMX-UID: GOH6L0xjZDIrGJ1QuGc2Znt5emhmYwGQ Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org There is no additional work needed from SIP Location Conveyance point of view. The 3GPP has already specified the ability to carry cell-ids in SIP. Ciao Hannes -------- Original-Nachricht -------- > Datum: Wed, 05 Mar 2008 16:42:35 -0600 > Von: "James M. Polk" > An: Gabor.Bajko@nokia.com, mlinsner@cisco.com, br@brianrosen.net, ecrit@ietf.org > Betreff: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > >Right. But that means relaxing the requirement "8. section 6.1 > >"Other forms of location representation must be mapped into either a geo > >or civic for use in emergency calls" in the draft and allow other type > >of location information, all those which make sense in their specific > >context. > > I don't understand why you want anything relaxed. The requirement > says PIDF-LO is the only location format to be used, and that the > is geo or civic. This is a MUST for interoperability > reasons. Cell-id doesn't accomplish this. > > > >Gabor > > > >-----Original Message----- > >From: ext Marc Linsner [mailto:mlinsner@cisco.com] > >Sent: Wednesday, March 05, 2008 12:50 PM > >To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); ecrit@ietf.org > >Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > >Of course there is no reason the operator couldn't provide civic > >location > >(123 Main St.) in place of cell-id either (verses a geo location). The > >main objective is to have location information in the device such that > >it makes sense to the consumer vs. every context having their own > >location descriptions (cell-id, water meter number, telephone pole id, > >property tax plat number, fire hydrant inventory id, msag address, > >etc.). > > > >-Marc- > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Brian Rosen > > > Sent: Wednesday, March 05, 2008 2:53 PM > > > To: 'James M. Polk'; Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > > > > > ecrit@ietf.org > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > The basic agreement we have made, in NENA, is that the operator will > > > agree with the PSAP on a location for the cellid. This could be a > > > point or a polygon. That location will be reported, in PIDF-LO form, > > > from the LIS. > > > There was a discussion about actually allowing a cell-id as an > > > alternate form of location representation, but it was decided not to > > > do that. A LIS could, of course, construct a location reference of > > > the form sip:@opco.net, and send that. When dereferenced, it > > > > > would return the agreed-upon location. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of James M. Polk > > > > Sent: Wednesday, March 05, 2008 2:29 PM > > > > To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > > > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > > >Cell-id is an identifier of a geographical area which is mapped to > > > > >psap already in today's databases. If you'll make an IP based > > > > >emergency call on cellular, that will use now and for many > > > years to > > > > >come the cell-id to select the psap where to direct your > > > call. GAbor > > > > > > > > let's discuss this topic as its own thread. > > > > > > > > All (not just some or one) of the following questions need to be > > > > answered positively and definitively in order for your Cell-id > > > > scenario to work in IP. > > > > > > > > Where is the Cell-id to PSAP URI mapping done? > > > > > > > > What database has this information? > > > > > > > > What IP protocol is used to resolve this mapping of Cell-id to > > > > (appropriate) PSAP? > > > > > > > > Where is this IP-based server located? > > > > > > > > How can LoST be used to discover this? > > > > > > > > What LCP will give this Cell-id to a phone to include in a > > > SIP message? > > > > > > > > What SIP header is this information placed in? > > > > > > > > What form does this Cell-id have in the SIP header from the > > > previous > > > > question? > > > > > > > > What IETF document(s) specifies this header and Cell-id form? > > > > > > > > James > > > > > > > > > > > > _______________________________________________ > > > > 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 5 23:26:35 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDDC928C64F; Wed, 5 Mar 2008 23:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.672 X-Spam-Level: X-Spam-Status: No, score=-100.672 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnXGBE7oqTas; Wed, 5 Mar 2008 23:26:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC1143A690D; Wed, 5 Mar 2008 23:26:34 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49EC73A690D for ; Wed, 5 Mar 2008 23:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJkPBWtMwvwV for ; Wed, 5 Mar 2008 23:26:33 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id EB0B03A686E for ; Wed, 5 Mar 2008 23:26:32 -0800 (PST) Received: (qmail 4055 invoked by uid 0); 6 Mar 2008 07:26:21 -0000 Received: from 192.100.124.219 by www056.gmx.net with HTTP; Thu, 06 Mar 2008 08:26:21 +0100 (CET) Date: Thu, 06 Mar 2008 08:26:21 +0100 From: "Hannes Tschofenig" In-Reply-To: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com> Message-ID: <20080306072621.23460@gmx.net> MIME-Version: 1.0 References: <47CAE9CA.9010901@gmx.net> <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com> To: "Brian Rosen" , ecrit@ietf.org, Gabor.Bajko@nokia.com, jmpolk@cisco.com X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX196TLY44C563LEAbuiVceaDKXSqrqLy+QRIRZzxCZ 8Bd7fhznf3hCUBSC3TYfeasikrlfsFgyfl9g== X-GMX-UID: 0umuI0Noa0A7SJIMtzAzrBQ/Njh6dM5y Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org We also discussed this topic in a face-to-face meeting between the 3GPP and the IETF in July 2006. I recall that we were not so negative about the idea of using Cell-IDs. Furthermore, there are two separate things to consider: * Cell-ID usage for LoST to obtain a PSAP URI * Cell-ID information as information for dispatch. Gabor is not proposing the second approach. > The basic agreement we have made, in NENA, is that the operator will agree > with the PSAP on a location for the cellid. This could be a point or a > polygon. That location will be reported, in PIDF-LO form, from the LIS. > There was a discussion about actually allowing a cell-id as an alternate > form of location representation, but it was decided not to do that. A LIS > could, of course, construct a location reference of the form > sip:@opco.net, and send that. When dereferenced, it would return > the agreed-upon location. > > Brian > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > James M. Polk > > Sent: Wednesday, March 05, 2008 2:29 PM > > To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > >Cell-id is an identifier of a geographical area which is mapped to psap > > >already in today's databases. If you'll make an IP based emergency call > > >on cellular, that will use now and for many years to come the cell-id > to > > >select the psap where to direct your call. GAbor > > > > let's discuss this topic as its own thread. > > > > All (not just some or one) of the following questions need to be > > answered positively and definitively in order for your Cell-id > > scenario to work in IP. > > > > Where is the Cell-id to PSAP URI mapping done? > > > > What database has this information? > > > > What IP protocol is used to resolve this mapping of Cell-id to > > (appropriate) PSAP? > > > > Where is this IP-based server located? > > > > How can LoST be used to discover this? > > > > What LCP will give this Cell-id to a phone to include in a SIP message? > > > > What SIP header is this information placed in? > > > > What form does this Cell-id have in the SIP header from the previous > > question? > > > > What IETF document(s) specifies this header and Cell-id form? > > > > James > > > > > > _______________________________________________ > > 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 ecrit-bounces@ietf.org Wed Mar 5 23:31:57 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8855D28C83E; Wed, 5 Mar 2008 23:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.666 X-Spam-Level: X-Spam-Status: No, score=-100.666 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2IgUL1aF+yZ; Wed, 5 Mar 2008 23:31:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E72428C806; Wed, 5 Mar 2008 23:31:56 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F14D928C806 for ; Wed, 5 Mar 2008 23:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jW6TQYRTRKa for ; Wed, 5 Mar 2008 23:31:52 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1942528C7D9 for ; Wed, 5 Mar 2008 23:31:51 -0800 (PST) Received: (qmail 24157 invoked by uid 0); 6 Mar 2008 07:31:41 -0000 Received: from 192.100.124.219 by www027.gmx.net with HTTP; Thu, 06 Mar 2008 08:31:41 +0100 (CET) Date: Thu, 06 Mar 2008 08:31:41 +0100 From: "Hannes Tschofenig" In-Reply-To: Message-ID: <20080306073141.23430@gmx.net> MIME-Version: 1.0 References: <47CAE9CA.9010901@gmx.net> To: "James M. Polk" , ecrit@ietf.org, Gabor.Bajko@nokia.com X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+mUdM2IBGmefHAVzeYk4J4BKFwMZM14p1WlsxZgO h0ttXKvwFZOQj85/r6C+iyi21W3clb8pBNzw== X-GMX-UID: 5a/2chxEeWUoRJsCsXRz0WwxU3U4N889 Subject: [Ecrit] Questions/Answers regarding Cell-IDs X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi James, > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > >Cell-id is an identifier of a geographical area which is mapped to psap > >already in today's databases. If you'll make an IP based emergency call > >on cellular, that will use now and for many years to come the cell-id to > >select the psap where to direct your call. GAbor > > let's discuss this topic as its own thread. > > All (not just some or one) of the following questions need to be > answered positively and definitively in order for your Cell-id > scenario to work in IP. > Anticipating what Gabor tries to say here... > Where is the Cell-id to PSAP URI mapping done? That information is in the LoST database. > > What database has this information? See above. > > What IP protocol is used to resolve this mapping of Cell-id to > (appropriate) PSAP? LoST > > Where is this IP-based server located? A LoST server could be located anywhere. It is easier and more robust to place a LoST server in the access or close to the access. > > How can LoST be used to discover this? Using the documents we wrote; you are co-author of that document > > What LCP will give this Cell-id to a phone to include in a SIP message? Cell-IDs are provided by the link layer. This is already done today > > What SIP header is this information placed in? If LoST is run at the end point then the Cell-ID does not need to be carried in SIP at all. However, there is a 3GPP specification that carries a cell-ID already today. I would have to search for it > > What form does this Cell-id have in the SIP header from the previous > question? Need to look it up. > > What IETF document(s) specifies this header and Cell-id form? Only 3GPP docs do at the moment. There may not be a need to carry them in SIP when LoST is run at the end point. Ciao Hannes > > James > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 6 05:12:57 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CCCC28C533; Thu, 6 Mar 2008 05:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.832 X-Spam-Level: X-Spam-Status: No, score=-100.832 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRDv9CRLluhJ; Thu, 6 Mar 2008 05:12:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E36028C48E; Thu, 6 Mar 2008 05:12:56 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C19DE28C3A5 for ; Thu, 6 Mar 2008 05:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImDVxL3vuPsu for ; Thu, 6 Mar 2008 05:12:53 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id EC24A3A6F14 for ; Thu, 6 Mar 2008 05:12:52 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m26DDG5A010851; Thu, 6 Mar 2008 07:13:33 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 15:11:48 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 15:11:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 15:11:46 +0200 Message-ID: In-Reply-To: <20080306073141.23430@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Questions/Answers regarding Cell-IDs Thread-Index: Ach/XCU1+FKVfti2QnatkeevsJWVtQALuZsg References: <47CAE9CA.9010901@gmx.net> <20080306073141.23430@gmx.net> From: To: , , , X-OriginalArrivalTime: 06 Mar 2008 13:11:47.0706 (UTC) FILETIME=[A21D25A0:01C87F8B] X-Nokia-AV: Clean Subject: Re: [Ecrit] Questions/Answers regarding Cell-IDs X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi, About carrying Cell-id information in SIP: Hannes Tschofenig wrote: > >> >> What SIP header is this information placed in? > >If LoST is run at the end point then the Cell-ID does not need >to be carried in SIP at all. > >However, there is a 3GPP specification that carries a cell-ID >already today. I would have to search for it > >> >> What form does this Cell-id have in the SIP header from the previous >> question? > >Need to look it up. >> >> What IETF document(s) specifies this header and Cell-id form? > >Only 3GPP docs do at the moment. >There may not be a need to carry them in SIP when LoST is run >at the end point. > I think this is all in IETF RFC 3455 (http://tools.ietf.org/html/rfc3455). It defines a header called P-Access-Network-Info, which can carry a Cell-id. The details can be found in the RFC. Markus _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 6 05:29:42 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E8AC28C618; Thu, 6 Mar 2008 05:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.901 X-Spam-Level: X-Spam-Status: No, score=-100.901 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irS0WnTdYVgn; Thu, 6 Mar 2008 05:29:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A5D728C51F; Thu, 6 Mar 2008 05:29:36 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F09393A6CEB for ; Thu, 6 Mar 2008 05:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7AgrnluYuCF for ; Thu, 6 Mar 2008 05:29:34 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C71E628C4C0 for ; Thu, 6 Mar 2008 05:28:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,455,1199682000"; d="scan'208";a="650600" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 06 Mar 2008 08:28:24 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m26DSPDl012097; Thu, 6 Mar 2008 08:28:25 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m26DSPaR029904; Thu, 6 Mar 2008 13:28:25 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 08:28:24 -0500 Received: from mlinsnerwxp02 ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 08:28:22 -0500 From: "Marc Linsner" To: "'Hannes Tschofenig'" , "'James M. Polk'" , , Date: Thu, 6 Mar 2008 08:28:21 -0500 Message-ID: <007401c87f8d$f4511550$270d0d0a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080306073141.23430@gmx.net> Thread-Index: Ach/XCe1QqsKlrK5RgeyuLill0AFewAMY5Gg X-OriginalArrivalTime: 06 Mar 2008 13:28:24.0713 (UTC) FILETIME=[F4605790:01C87F8D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2627; t=1204810105; x=1205674105; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20Questions/Answers=20regarding =20Cell-IDs |Sender:=20 |To:=20=22'Hannes=20Tschofenig'=22=20,=0A=20=20=20=20=20=20=20=20=22'James=20M.=20Polk'=22=2 0,=20,=0A=20=20=20=20=20=2 0=20=20; bh=uxnWN4jC9tBCJw9aWq6BzG1uD9nsKXW90tJOCF9WHbs=; b=n9bB9zVo0E1T4lCmZnvRwC9DMBNmtfSF/t/WTimoUE/HiVj4lLvsc6OT90 nMYztcS59U5zt04AbTPdebSeamQEMLYVbvZNC1s5rnfxKNTUQhIOrHCwRxjU OlgYzjyQAv; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Ecrit] Questions/Answers regarding Cell-IDs X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hannes, What pidf-lo tag gets populated with cell-id? -Marc- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Hannes Tschofenig > Sent: Thursday, March 06, 2008 2:32 AM > To: James M. Polk; ecrit@ietf.org; Gabor.Bajko@nokia.com > Subject: [Ecrit] Questions/Answers regarding Cell-IDs > > Hi James, > > > > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > >Cell-id is an identifier of a geographical area which is mapped to > > >psap already in today's databases. If you'll make an IP based > > >emergency call on cellular, that will use now and for many > years to > > >come the cell-id to select the psap where to direct your > call. GAbor > > > > let's discuss this topic as its own thread. > > > > All (not just some or one) of the following questions need to be > > answered positively and definitively in order for your Cell-id > > scenario to work in IP. > > > Anticipating what Gabor tries to say here... > > > Where is the Cell-id to PSAP URI mapping done? > > That information is in the LoST database. > > > > > What database has this information? > > See above. > > > > > What IP protocol is used to resolve this mapping of Cell-id to > > (appropriate) PSAP? > > LoST > > > > > Where is this IP-based server located? > > A LoST server could be located anywhere. > It is easier and more robust to place a LoST server in the > access or close to the access. > > > > > How can LoST be used to discover this? > > Using the documents we wrote; you are co-author of that document > > > > > What LCP will give this Cell-id to a phone to include in a > SIP message? > > Cell-IDs are provided by the link layer. This is already done today > > > > > > What SIP header is this information placed in? > > If LoST is run at the end point then the Cell-ID does not > need to be carried in SIP at all. > > However, there is a 3GPP specification that carries a cell-ID > already today. I would have to search for it > > > > > > What form does this Cell-id have in the SIP header from the > previous > > question? > > Need to look it up. > > > > What IETF document(s) specifies this header and Cell-id form? > > Only 3GPP docs do at the moment. > There may not be a need to carry them in SIP when LoST is run > at the end point. > > Ciao > Hannes > > > > > James > > > _______________________________________________ > 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 ecrit-bounces@ietf.org Thu Mar 6 05:59:48 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88AF428C2DA; Thu, 6 Mar 2008 05:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.573 X-Spam-Level: X-Spam-Status: No, score=-100.573 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPSupWYMEuIl; Thu, 6 Mar 2008 05:59:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87F5A3A6DD0; Thu, 6 Mar 2008 05:59:44 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 362F13A6DD0 for ; Thu, 6 Mar 2008 05:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRlTsSlBxVkM for ; Thu, 6 Mar 2008 05:59:42 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 1C2EB3A69F4 for ; Thu, 6 Mar 2008 05:59:42 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JXGd4-0002Kt-Pw; Thu, 06 Mar 2008 07:59:27 -0600 From: "Brian Rosen" To: "'Hannes Tschofenig'" , , , References: <47CAE9CA.9010901@gmx.net> <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com> <20080306072621.23460@gmx.net> Date: Thu, 6 Mar 2008 08:59:27 -0500 Message-ID: <027a01c87f92$4c949da0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080306072621.23460@gmx.net> Thread-Index: Ach/W2E5BLqkumqoTAmK9dEa6EYbgAANbnCw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Although I am very eager to get 3GPP and IETF to work on common requirements and mechanisms for emergency calls, and in general, everything is on the table, having had discussions on this subject in NENA, even the wireless carriers don't think this is a good idea. It means, among other things that they must maintain cell-id to actual location mappings in the LoST server, in any PSAP that could possibly handle the call (which is effectively all PSAPs) and in any other location application. Generally, they thought this was a bad idea. Cell IDs and the mapping to locations changes often enough that maintaining this mapping in lots of environments is difficult. The notion of using it as a HELD or SIP reference ID addresses all situations where someone thought it would be cool to use it. Unlike a civic or a geo, no one can directly use a cell-id as location; they have to turn it in to a civic or a geo to use it. Thus it is, by definition, a form of location reference. We have mechanisms to use location references. If you want to use it, we have the mechanisms for that, but then the carrier has to operate the dereference mechanism. If they want to provide that service, they can. In my discussions with them, they don't want to do that. YMMV > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Thursday, March 06, 2008 2:26 AM > To: Brian Rosen; ecrit@ietf.org; Gabor.Bajko@nokia.com; jmpolk@cisco.com > Subject: Re: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > We also discussed this topic in a face-to-face meeting between the 3GPP > and the IETF in July 2006. I recall that we were not so negative about the > idea of using Cell-IDs. > > Furthermore, there are two separate things to consider: > > * Cell-ID usage for LoST to obtain a PSAP URI > * Cell-ID information as information for dispatch. > > Gabor is not proposing the second approach. > > > > The basic agreement we have made, in NENA, is that the operator will > agree > > with the PSAP on a location for the cellid. This could be a point or a > > polygon. That location will be reported, in PIDF-LO form, from the LIS. > > There was a discussion about actually allowing a cell-id as an alternate > > form of location representation, but it was decided not to do that. A > LIS > > could, of course, construct a location reference of the form > > sip:@opco.net, and send that. When dereferenced, it would > return > > the agreed-upon location. > > > > Brian > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > Of > > > James M. Polk > > > Sent: Wednesday, March 05, 2008 2:29 PM > > > To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > >Cell-id is an identifier of a geographical area which is mapped to > psap > > > >already in today's databases. If you'll make an IP based emergency > call > > > >on cellular, that will use now and for many years to come the cell-id > > to > > > >select the psap where to direct your call. GAbor > > > > > > let's discuss this topic as its own thread. > > > > > > All (not just some or one) of the following questions need to be > > > answered positively and definitively in order for your Cell-id > > > scenario to work in IP. > > > > > > Where is the Cell-id to PSAP URI mapping done? > > > > > > What database has this information? > > > > > > What IP protocol is used to resolve this mapping of Cell-id to > > > (appropriate) PSAP? > > > > > > Where is this IP-based server located? > > > > > > How can LoST be used to discover this? > > > > > > What LCP will give this Cell-id to a phone to include in a SIP > message? > > > > > > What SIP header is this information placed in? > > > > > > What form does this Cell-id have in the SIP header from the previous > > > question? > > > > > > What IETF document(s) specifies this header and Cell-id form? > > > > > > James > > > > > > > > > _______________________________________________ > > > 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 ecrit-bounces@ietf.org Thu Mar 6 06:07:13 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F37A28C417; Thu, 6 Mar 2008 06:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.716 X-Spam-Level: X-Spam-Status: No, score=-100.716 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rToYUFUGz-e3; Thu, 6 Mar 2008 06:07:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11E933A6F2D; Thu, 6 Mar 2008 06:07:09 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86B9B3A6E28 for ; Thu, 6 Mar 2008 06:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORIc-eLCdOtG for ; Thu, 6 Mar 2008 06:07:06 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 011AC3A6DDB for ; Thu, 6 Mar 2008 06:07:05 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m26E6an3015900; Thu, 6 Mar 2008 16:06:48 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 16:06:46 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 16:06:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 16:06:44 +0200 Message-ID: In-Reply-To: <20080306072621.23460@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Cell-id in HELD and other parts of the emergency services framework? (Was: WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)) Thread-Index: Ach/W2VcM7tMpBrRQh+bdZonicypuAAMFQNg References: <47CAE9CA.9010901@gmx.net><016f01c87efa$76eb3930$640fa8c0@cis.neustar.com> <20080306072621.23460@gmx.net> From: To: , , , , X-OriginalArrivalTime: 06 Mar 2008 14:06:45.0700 (UTC) FILETIME=[4FDF1840:01C87F93] X-Nokia-AV: Clean Subject: [Ecrit] Cell-id in HELD and other parts of the emergency services framework? (Was: WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi, Talking about the different scenarios how Cell-id could be used in the IP emergency service framework, we also still have the "conventional" way of first mapping it into geo or civic location. The phonebcp draft currently says: Other forms of location representation must be mapped into either a geo or civic for use in emergency calls. So, how do we expect this to happen for Cell-id? One possibility I would see is that we could extend HELD so that the HELD request could carry Cell-id, and the HELD server could use the Cell-id in addition to IP address to determine the location of the mobile host. (This is what Google does already in their map application, so actually the server doing the mapping does not even have to be associated with the access network, although such association would probably make the mapping more reliable.) Would this seem like a sensible extension to HELD? Given how ubiquitous Cell-id already is in the cellular wireless infrastructure, I think we should actually develop protocols that allow it to be used in at least these ways: a) Use it as an input in LoST for mapping to PSAP URI. b) Use it as an input in HELD for mapping to geo/civic location. c) Carry it within the signaling protocol for various potential usages. I think this is already taken care by what is defined in RFC 3455, although I suppose it would be more inline with the rest of ECRIT/GEOPRIV work if it was actually carried within PIDF-LO in accordance to the SIP location conveyance. Markus >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Hannes Tschofenig >Sent: 06 March, 2008 09:26 >To: Brian Rosen; ecrit@ietf.org; Bajko Gabor >(Nokia-OCTO/MtView); jmpolk@cisco.com >Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > >We also discussed this topic in a face-to-face meeting between >the 3GPP and the IETF in July 2006. I recall that we were not >so negative about the idea of using Cell-IDs. > >Furthermore, there are two separate things to consider: > >* Cell-ID usage for LoST to obtain a PSAP URI >* Cell-ID information as information for dispatch. > >Gabor is not proposing the second approach. > > >> The basic agreement we have made, in NENA, is that the operator will >> agree with the PSAP on a location for the cellid. This could be a >> point or a polygon. That location will be reported, in >PIDF-LO form, from the LIS. >> There was a discussion about actually allowing a cell-id as an >> alternate form of location representation, but it was decided not to >> do that. A LIS could, of course, construct a location reference of >> the form sip:@opco.net, and send that. When >dereferenced, it >> would return the agreed-upon location. >> >> Brian >> >> > -----Original Message----- >> > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> > Behalf >> Of >> > James M. Polk >> > Sent: Wednesday, March 05, 2008 2:29 PM >> > To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; >ecrit@ietf.org >> > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) >> > >> > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: >> > >Cell-id is an identifier of a geographical area which is >mapped to >> > >psap already in today's databases. If you'll make an IP based >> > >emergency call on cellular, that will use now and for >many years to >> > >come the cell-id >> to >> > >select the psap where to direct your call. GAbor >> > >> > let's discuss this topic as its own thread. >> > >> > All (not just some or one) of the following questions need to be >> > answered positively and definitively in order for your Cell-id >> > scenario to work in IP. >> > >> > Where is the Cell-id to PSAP URI mapping done? >> > >> > What database has this information? >> > >> > What IP protocol is used to resolve this mapping of Cell-id to >> > (appropriate) PSAP? >> > >> > Where is this IP-based server located? >> > >> > How can LoST be used to discover this? >> > >> > What LCP will give this Cell-id to a phone to include in a >SIP message? >> > >> > What SIP header is this information placed in? >> > >> > What form does this Cell-id have in the SIP header from >the previous >> > question? >> > >> > What IETF document(s) specifies this header and Cell-id form? >> > >> > James >> > >> > >> > _______________________________________________ >> > 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 ecrit-bounces@ietf.org Thu Mar 6 10:15:45 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C21228C8F2; Thu, 6 Mar 2008 10:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.656 X-Spam-Level: X-Spam-Status: No, score=-100.656 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeArP-VOC6Qa; Thu, 6 Mar 2008 10:15:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 282953A6A35; Thu, 6 Mar 2008 10:15:44 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E6AE3A6A35 for ; Thu, 6 Mar 2008 10:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5I+j3T5+0O14 for ; Thu, 6 Mar 2008 10:15:42 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0FFCF3A681D for ; Thu, 6 Mar 2008 10:15:41 -0800 (PST) Received: (qmail invoked by alias); 06 Mar 2008 18:15:30 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp005) with SMTP; 06 Mar 2008 19:15:30 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+xCls8Ce2xFrSOR0qZ5r0l3z2RqPU8tGygTzLM+n /xX3kfooECV2yp Message-ID: <47D034C1.6050306@gmx.net> Date: Thu, 06 Mar 2008 20:15:29 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Marc Linsner References: <007401c87f8d$f4511550$270d0d0a@cisco.com> In-Reply-To: <007401c87f8d$f4511550$270d0d0a@cisco.com> X-Y-GMX-Trusted: 0 Cc: Gabor.Bajko@nokia.com, ecrit@ietf.org Subject: Re: [Ecrit] Questions/Answers regarding Cell-IDs X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Marc, here is one possible description: * You get a LbyR using an LbyR (for dispatch) * You have the cell-ID based on the link layer interaction. (for routing to the right PSAP) The cell-id is used for determining the PSAP URI. The PSAP uses the LbyR to obtain the precise location from the LIS for dispatch. Another possible use case is the following End point communicates cell-id in the SIP message (according to the 3GPP specifications). The proxy uses the cell-id to determine the the route towards the PSAP. The PSAP uses obtains an LbyR from the LIS in order to allow the PSAP to retrieve the precise location. Ciao Hannes Marc Linsner wrote: > Hannes, > > What pidf-lo tag gets populated with cell-id? > > -Marc- > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of Hannes Tschofenig >> Sent: Thursday, March 06, 2008 2:32 AM >> To: James M. Polk; ecrit@ietf.org; Gabor.Bajko@nokia.com >> Subject: [Ecrit] Questions/Answers regarding Cell-IDs >> >> Hi James, >> >> >> >>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: >>> >>>> Cell-id is an identifier of a geographical area which is mapped to >>>> psap already in today's databases. If you'll make an IP based >>>> emergency call on cellular, that will use now and for many >>>> >> years to >> >>>> come the cell-id to select the psap where to direct your >>>> >> call. GAbor >> >>> let's discuss this topic as its own thread. >>> >>> All (not just some or one) of the following questions need to be >>> answered positively and definitively in order for your Cell-id >>> scenario to work in IP. >>> >>> >> Anticipating what Gabor tries to say here... >> >> >>> Where is the Cell-id to PSAP URI mapping done? >>> >> That information is in the LoST database. >> >> >>> What database has this information? >>> >> See above. >> >> >>> What IP protocol is used to resolve this mapping of Cell-id to >>> (appropriate) PSAP? >>> >> LoST >> >> >>> Where is this IP-based server located? >>> >> A LoST server could be located anywhere. >> It is easier and more robust to place a LoST server in the >> access or close to the access. >> >> >>> How can LoST be used to discover this? >>> >> Using the documents we wrote; you are co-author of that document >> >> >>> What LCP will give this Cell-id to a phone to include in a >>> >> SIP message? >> >> Cell-IDs are provided by the link layer. This is already done today >> >> >> >>> What SIP header is this information placed in? >>> >> If LoST is run at the end point then the Cell-ID does not >> need to be carried in SIP at all. >> >> However, there is a 3GPP specification that carries a cell-ID >> already today. I would have to search for it >> >> >> >>> What form does this Cell-id have in the SIP header from the >>> >> previous >> >>> question? >>> >> Need to look it up. >> >>> What IETF document(s) specifies this header and Cell-id form? >>> >> Only 3GPP docs do at the moment. >> There may not be a need to carry them in SIP when LoST is run >> at the end point. >> >> Ciao >> Hannes >> >> >>> James >>> >>> >> _______________________________________________ >> 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 ecrit-bounces@ietf.org Thu Mar 6 10:38:25 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A13A328C977; Thu, 6 Mar 2008 10:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.485 X-Spam-Level: X-Spam-Status: No, score=-100.485 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIYo0lJVAGgI; Thu, 6 Mar 2008 10:38:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76C7928C979; Thu, 6 Mar 2008 10:38:24 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5608F28C8F0 for ; Thu, 6 Mar 2008 10:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbcntymIylUq for ; Thu, 6 Mar 2008 10:38:22 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 2EFF03A6CF0 for ; Thu, 6 Mar 2008 10:38:22 -0800 (PST) X-SEF-Processed: 5_0_0_910__2008_03_06_12_50_52 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 06 Mar 2008 12:50:52 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Mar 2008 12:38:11 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 12:37:27 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Cell-id in HELD and other parts of the emergency servicesframework? (Was: WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)) Thread-Index: Ach/W2VcM7tMpBrRQh+bdZonicypuAAMFQNgAAtZ1NI= References: <47CAE9CA.9010901@gmx.net><016f01c87efa$76eb3930$640fa8c0@cis.neustar.com><20080306072621.23460@gmx.net> From: "Winterbottom, James" To: , , , , , X-OriginalArrivalTime: 06 Mar 2008 18:38:11.0355 (UTC) FILETIME=[3AE0D6B0:01C87FB9] Subject: Re: [Ecrit] Cell-id in HELD and other parts of the emergency servicesframework? (Was: WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Markus, The framework to extend HELD in this direction has already been drined. Please look at http://tools.ietf.org/html/draft-thomson-geopriv-held-measurements-01 Cheers James -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Markus.Isomaki@nokia.com Sent: Thu 3/6/2008 8:06 AM To: Hannes.Tschofenig@gmx.net; br@brianrosen.net; ecrit@ietf.org; Gabor.Bajko@nokia.com; jmpolk@cisco.com Subject: [Ecrit] Cell-id in HELD and other parts of the emergency servicesframework? (Was: WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)) Hi, Talking about the different scenarios how Cell-id could be used in the IP emergency service framework, we also still have the "conventional" way of first mapping it into geo or civic location. The phonebcp draft currently says: Other forms of location representation must be mapped into either a geo or civic for use in emergency calls. So, how do we expect this to happen for Cell-id? One possibility I would see is that we could extend HELD so that the HELD request could carry Cell-id, and the HELD server could use the Cell-id in addition to IP address to determine the location of the mobile host. (This is what Google does already in their map application, so actually the server doing the mapping does not even have to be associated with the access network, although such association would probably make the mapping more reliable.) Would this seem like a sensible extension to HELD? Given how ubiquitous Cell-id already is in the cellular wireless infrastructure, I think we should actually develop protocols that allow it to be used in at least these ways: a) Use it as an input in LoST for mapping to PSAP URI. b) Use it as an input in HELD for mapping to geo/civic location. c) Carry it within the signaling protocol for various potential usages. I think this is already taken care by what is defined in RFC 3455, although I suppose it would be more inline with the rest of ECRIT/GEOPRIV work if it was actually carried within PIDF-LO in accordance to the SIP location conveyance. Markus >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Hannes Tschofenig >Sent: 06 March, 2008 09:26 >To: Brian Rosen; ecrit@ietf.org; Bajko Gabor >(Nokia-OCTO/MtView); jmpolk@cisco.com >Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > >We also discussed this topic in a face-to-face meeting between >the 3GPP and the IETF in July 2006. I recall that we were not >so negative about the idea of using Cell-IDs. > >Furthermore, there are two separate things to consider: > >* Cell-ID usage for LoST to obtain a PSAP URI >* Cell-ID information as information for dispatch. > >Gabor is not proposing the second approach. > > >> The basic agreement we have made, in NENA, is that the operator will >> agree with the PSAP on a location for the cellid. This could be a >> point or a polygon. That location will be reported, in >PIDF-LO form, from the LIS. >> There was a discussion about actually allowing a cell-id as an >> alternate form of location representation, but it was decided not to >> do that. A LIS could, of course, construct a location reference of >> the form sip:@opco.net, and send that. When >dereferenced, it >> would return the agreed-upon location. >> >> Brian >> >> > -----Original Message----- >> > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> > Behalf >> Of >> > James M. Polk >> > Sent: Wednesday, March 05, 2008 2:29 PM >> > To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; >ecrit@ietf.org >> > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) >> > >> > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: >> > >Cell-id is an identifier of a geographical area which is >mapped to >> > >psap already in today's databases. If you'll make an IP based >> > >emergency call on cellular, that will use now and for >many years to >> > >come the cell-id >> to >> > >select the psap where to direct your call. GAbor >> > >> > let's discuss this topic as its own thread. >> > >> > All (not just some or one) of the following questions need to be >> > answered positively and definitively in order for your Cell-id >> > scenario to work in IP. >> > >> > Where is the Cell-id to PSAP URI mapping done? >> > >> > What database has this information? >> > >> > What IP protocol is used to resolve this mapping of Cell-id to >> > (appropriate) PSAP? >> > >> > Where is this IP-based server located? >> > >> > How can LoST be used to discover this? >> > >> > What LCP will give this Cell-id to a phone to include in a >SIP message? >> > >> > What SIP header is this information placed in? >> > >> > What form does this Cell-id have in the SIP header from >the previous >> > question? >> > >> > What IETF document(s) specifies this header and Cell-id form? >> > >> > James >> > >> > >> > _______________________________________________ >> > 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 ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 6 11:09:52 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5D028C48A; Thu, 6 Mar 2008 11:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.897 X-Spam-Level: X-Spam-Status: No, score=-100.897 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKlRvoqaC6ky; Thu, 6 Mar 2008 11:09:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B4C13A69D8; Thu, 6 Mar 2008 11:09:48 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A1883A6AA9 for ; Thu, 6 Mar 2008 11:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52AegbCHkR8f for ; Thu, 6 Mar 2008 11:09:42 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 76C913A6A78 for ; Thu, 6 Mar 2008 11:09:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,457,1199692800"; d="scan'208";a="16325011" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 06 Mar 2008 11:09:31 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m26J9V87004771; Thu, 6 Mar 2008 11:09:31 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m26J9Un3026565; Thu, 6 Mar 2008 19:09:31 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 14:09:27 -0500 Received: from mlinsnerwxp02 ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 14:09:27 -0500 From: "Marc Linsner" To: "'Hannes Tschofenig'" Date: Thu, 6 Mar 2008 14:09:26 -0500 Message-ID: <00bb01c87fbd$98f2e1e0$270d0d0a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47D034C1.6050306@gmx.net> Thread-Index: Ach/tiO2LdTm8QtsRIOyEoN2l0DUmAAByeoA X-OriginalArrivalTime: 06 Mar 2008 19:09:27.0278 (UTC) FILETIME=[9903F8E0:01C87FBD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4336; t=1204830571; x=1205694571; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20Questions/Answers=20regarding =20Cell-IDs |Sender:=20; bh=TPPj+bFkviBbaQ77ifmjNFvCvmCHM26UZ0+nRt80+Xo=; b=KOb5skSCa5DUJfyTyrFlqWJFGKFx1jKtPJxY0WFxpbmzNq+BNFL7GAp+Fk N5vQCDM5XyP5aA7G1uGbefjTG4fBYNKMh2A78kV1KRPEfXK/cxExhWhLSWmS sX7cwKX5kbThfMWBqv5IMKchEtxzZjUNEY6hJW4MsKVmmUGcg5DW4=; Authentication-Results: sj-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: ecrit@ietf.org Subject: Re: [Ecrit] Questions/Answers regarding Cell-IDs X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hannes, I thought you implied below that you could use cell-id to lookup psap uri via LoST...?? Is there a tag in the LoST query for cell-id? -Marc- > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Thursday, March 06, 2008 1:15 PM > To: Marc Linsner > Cc: 'James M. Polk'; ecrit@ietf.org; Gabor.Bajko@nokia.com > Subject: Re: [Ecrit] Questions/Answers regarding Cell-IDs > > Hi Marc, > > here is one possible description: > > * You get a LbyR using an LbyR > (for dispatch) > * You have the cell-ID based on the link layer interaction. > (for routing to the right PSAP) > > The cell-id is used for determining the PSAP URI. > The PSAP uses the LbyR to obtain the precise location from > the LIS for dispatch. > > > Another possible use case is the following > > End point communicates cell-id in the SIP message (according > to the 3GPP > specifications). > The proxy uses the cell-id to determine the the route towards > the PSAP. > The PSAP uses obtains an LbyR from the LIS in order to allow > the PSAP to > retrieve the precise location. > > > Ciao > Hannes > > Marc Linsner wrote: > > Hannes, > > > > What pidf-lo tag gets populated with cell-id? > > > > -Marc- > > > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> On Behalf Of Hannes Tschofenig > >> Sent: Thursday, March 06, 2008 2:32 AM > >> To: James M. Polk; ecrit@ietf.org; Gabor.Bajko@nokia.com > >> Subject: [Ecrit] Questions/Answers regarding Cell-IDs > >> > >> Hi James, > >> > >> > >> > >>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > >>> > >>>> Cell-id is an identifier of a geographical area which is > mapped to > >>>> psap already in today's databases. If you'll make an IP based > >>>> emergency call on cellular, that will use now and for many > >>>> > >> years to > >> > >>>> come the cell-id to select the psap where to direct your > >>>> > >> call. GAbor > >> > >>> let's discuss this topic as its own thread. > >>> > >>> All (not just some or one) of the following questions need to be > >>> answered positively and definitively in order for your Cell-id > >>> scenario to work in IP. > >>> > >>> > >> Anticipating what Gabor tries to say here... > >> > >> > >>> Where is the Cell-id to PSAP URI mapping done? > >>> > >> That information is in the LoST database. > >> > >> > >>> What database has this information? > >>> > >> See above. > >> > >> > >>> What IP protocol is used to resolve this mapping of Cell-id to > >>> (appropriate) PSAP? > >>> > >> LoST > >> > >> > >>> Where is this IP-based server located? > >>> > >> A LoST server could be located anywhere. > >> It is easier and more robust to place a LoST server in the > >> access or close to the access. > >> > >> > >>> How can LoST be used to discover this? > >>> > >> Using the documents we wrote; you are co-author of that document > >> > >> > >>> What LCP will give this Cell-id to a phone to include in a > >>> > >> SIP message? > >> > >> Cell-IDs are provided by the link layer. This is already done today > >> > >> > >> > >>> What SIP header is this information placed in? > >>> > >> If LoST is run at the end point then the Cell-ID does not > >> need to be carried in SIP at all. > >> > >> However, there is a 3GPP specification that carries a cell-ID > >> already today. I would have to search for it > >> > >> > >> > >>> What form does this Cell-id have in the SIP header from the > >>> > >> previous > >> > >>> question? > >>> > >> Need to look it up. > >> > >>> What IETF document(s) specifies this header and Cell-id form? > >>> > >> Only 3GPP docs do at the moment. > >> There may not be a need to carry them in SIP when LoST is run > >> at the end point. > >> > >> Ciao > >> Hannes > >> > >> > >>> James > >>> > >>> > >> _______________________________________________ > >> 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 ecrit-bounces@ietf.org Thu Mar 6 11:49:32 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B6F28C940; Thu, 6 Mar 2008 11:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.843 X-Spam-Level: X-Spam-Status: No, score=-100.843 tagged_above=-999 required=5 tests=[AWL=-0.405, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xr4is3rTz93U; Thu, 6 Mar 2008 11:49:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E50A28C4FC; Thu, 6 Mar 2008 11:48:29 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 423EC28C4FC for ; Thu, 6 Mar 2008 11:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLE7pfu6OLTO for ; Thu, 6 Mar 2008 11:48:22 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 6E6673A6895 for ; Thu, 6 Mar 2008 11:48:22 -0800 (PST) Received: from col-dhcp33-244-152.bbn.com ([128.33.244.152] helo=localhost.localdomain) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JXM4Z-0003Fi-3v; Thu, 06 Mar 2008 14:48:11 -0500 Message-ID: <47D04A77.2020502@bbn.com> Date: Thu, 06 Mar 2008 14:48:07 -0500 From: Richard Barnes User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Gabor.Bajko@nokia.com References: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com><00b401c87f02$89eafcc0$270d0d0a@cisco.com> In-Reply-To: Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Gabor, If I have a cell-id, how do I figure out where that cell is? Is there a well-defined mechanism for doing that over IP? (I'm not trying to be rhetorical here, I just don't know.) My concern with using cell-id as a "pointer" to location in the Internet context is that there may not be a way to dereference that pointer (i.e., obtain the location of the cell) without going outside the Internet, e.g., to a 3GPP non-IP interface or some other database. --Richard Gabor.Bajko@nokia.com wrote: > The cell-id (cgi) is a global, well defined and understood in the > cellular world. There are no interoperability issues with it. If you > think otherwise, please give examples. > > Pidf-lo is an object which encapsulates preexisting location information > but it does not define the format of it. > > - gabor > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of ext James M. Polk > Sent: Wednesday, March 05, 2008 2:43 PM > To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; > br@brianrosen.net; ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: >> Right. But that means relaxing the requirement "8. section 6.1 "Other >> forms of location representation must be mapped into either a geo or >> civic for use in emergency calls" in the draft and allow other type of >> location information, all those which make sense in their specific >> context. > > I don't understand why you want anything relaxed. The requirement says > PIDF-LO is the only location format to be used, and that the > is geo or civic. This is a MUST for interoperability > reasons. Cell-id doesn't accomplish this. > > >> Gabor >> >> -----Original Message----- >> From: ext Marc Linsner [mailto:mlinsner@cisco.com] >> Sent: Wednesday, March 05, 2008 12:50 PM >> To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); ecrit@ietf.org >> Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) >> >> Of course there is no reason the operator couldn't provide civic >> location >> (123 Main St.) in place of cell-id either (verses a geo location). The > >> main objective is to have location information in the device such that >> it makes sense to the consumer vs. every context having their own >> location descriptions (cell-id, water meter number, telephone pole id, >> property tax plat number, fire hydrant inventory id, msag address, >> etc.). >> >> -Marc- >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> Behalf >>> Of Brian Rosen >>> Sent: Wednesday, March 05, 2008 2:53 PM >>> To: 'James M. Polk'; Gabor.Bajko@nokia.com; >>> Hannes.Tschofenig@gmx.net; >>> ecrit@ietf.org >>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) >>> >>> The basic agreement we have made, in NENA, is that the operator will > >>> agree with the PSAP on a location for the cellid. This could be a >>> point or a polygon. That location will be reported, in PIDF-LO >>> form, from the LIS. >>> There was a discussion about actually allowing a cell-id as an >>> alternate form of location representation, but it was decided not to > >>> do that. A LIS could, of course, construct a location reference of >>> the form sip:@opco.net, and send that. When dereferenced, >>> it >>> would return the agreed-upon location. >>> >>> Brian >>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org >>> [mailto:ecrit-bounces@ietf.org] On Behalf >>>> Of James M. Polk >>>> Sent: Wednesday, March 05, 2008 2:29 PM >>>> To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; >>>> ecrit@ietf.org >>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 >>>> (cell-id) >>>> >>>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: >>>>> Cell-id is an identifier of a geographical area which is mapped >>>>> to psap already in today's databases. If you'll make an IP based >>>>> emergency call on cellular, that will use now and for many >>> years to >>>>> come the cell-id to select the psap where to direct your >>> call. GAbor >>>> let's discuss this topic as its own thread. >>>> >>>> All (not just some or one) of the following questions need to be >>>> answered positively and definitively in order for your Cell-id >>>> scenario to work in IP. >>>> >>>> Where is the Cell-id to PSAP URI mapping done? >>>> >>>> What database has this information? >>>> >>>> What IP protocol is used to resolve this mapping of Cell-id to >>>> (appropriate) PSAP? >>>> >>>> Where is this IP-based server located? >>>> >>>> How can LoST be used to discover this? >>>> >>>> What LCP will give this Cell-id to a phone to include in a >>> SIP message? >>>> What SIP header is this information placed in? >>>> >>>> What form does this Cell-id have in the SIP header from the >>> previous >>>> question? >>>> >>>> What IETF document(s) specifies this header and Cell-id form? >>>> >>>> James >>>> >>>> >>>> _______________________________________________ >>>> 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 > _______________________________________________ > 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 ecrit-bounces@ietf.org Thu Mar 6 12:19:46 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2BF528C977; Thu, 6 Mar 2008 12:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.606 X-Spam-Level: X-Spam-Status: No, score=-100.606 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqcYbKBVQhAD; Thu, 6 Mar 2008 12:19:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46AE328C9A3; Thu, 6 Mar 2008 12:19:40 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C9528C811 for ; Thu, 6 Mar 2008 12:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5xdRl0Pi-Fe for ; Thu, 6 Mar 2008 12:19:32 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0C6CB28C9C6 for ; Thu, 6 Mar 2008 12:19:04 -0800 (PST) Received: (qmail invoked by alias); 06 Mar 2008 20:18:53 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp014) with SMTP; 06 Mar 2008 21:18:53 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/BpjtWMPPByrj27jAUjbUdWtEMrsYE7c+Ufzmbaz MNL5Em/M/32rZF Message-ID: <47D051AC.5080108@gmx.net> Date: Thu, 06 Mar 2008 22:18:52 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Richard Barnes References: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com><00b401c87f02$89eafcc0$270d0d0a@cisco.com> <47D04A77.2020502@bbn.com> In-Reply-To: <47D04A77.2020502@bbn.com> X-Y-GMX-Trusted: 0 Cc: Gabor.Bajko@nokia.com, ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Richard, there are two cases: 1) The LoST server is somewhere close to the access. Then, the cell-ids are sort of local and known to the LoST server (i.e., the location of the cell). 2) Some companies have global cell-id databases. I have some time ago sent a mail to the list about the approach Google is using that does not require any coorporation from the access provider to determine your rough location. Ciao Hannes Richard Barnes wrote: > Gabor, > > If I have a cell-id, how do I figure out where that cell is? Is there a > well-defined mechanism for doing that over IP? (I'm not trying to be > rhetorical here, I just don't know.) > > My concern with using cell-id as a "pointer" to location in the Internet > context is that there may not be a way to dereference that pointer > (i.e., obtain the location of the cell) without going outside the > Internet, e.g., to a 3GPP non-IP interface or some other database. > > --Richard > > > > > > Gabor.Bajko@nokia.com wrote: > >> The cell-id (cgi) is a global, well defined and understood in the >> cellular world. There are no interoperability issues with it. If you >> think otherwise, please give examples. >> >> Pidf-lo is an object which encapsulates preexisting location information >> but it does not define the format of it. >> >> - gabor >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of ext James M. Polk >> Sent: Wednesday, March 05, 2008 2:43 PM >> To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; >> br@brianrosen.net; ecrit@ietf.org >> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) >> >> At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: >> >>> Right. But that means relaxing the requirement "8. section 6.1 "Other >>> forms of location representation must be mapped into either a geo or >>> civic for use in emergency calls" in the draft and allow other type of >>> location information, all those which make sense in their specific >>> context. >>> >> I don't understand why you want anything relaxed. The requirement says >> PIDF-LO is the only location format to be used, and that the >> is geo or civic. This is a MUST for interoperability >> reasons. Cell-id doesn't accomplish this. >> >> >> >>> Gabor >>> >>> -----Original Message----- >>> From: ext Marc Linsner [mailto:mlinsner@cisco.com] >>> Sent: Wednesday, March 05, 2008 12:50 PM >>> To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); ecrit@ietf.org >>> Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) >>> >>> Of course there is no reason the operator couldn't provide civic >>> location >>> (123 Main St.) in place of cell-id either (verses a geo location). The >>> >>> main objective is to have location information in the device such that >>> it makes sense to the consumer vs. every context having their own >>> location descriptions (cell-id, water meter number, telephone pole id, >>> property tax plat number, fire hydrant inventory id, msag address, >>> etc.). >>> >>> -Marc- >>> >>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>> Behalf >>>> Of Brian Rosen >>>> Sent: Wednesday, March 05, 2008 2:53 PM >>>> To: 'James M. Polk'; Gabor.Bajko@nokia.com; >>>> Hannes.Tschofenig@gmx.net; >>>> ecrit@ietf.org >>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) >>>> >>>> The basic agreement we have made, in NENA, is that the operator will >>>> >>>> agree with the PSAP on a location for the cellid. This could be a >>>> point or a polygon. That location will be reported, in PIDF-LO >>>> form, from the LIS. >>>> There was a discussion about actually allowing a cell-id as an >>>> alternate form of location representation, but it was decided not to >>>> >>>> do that. A LIS could, of course, construct a location reference of >>>> the form sip:@opco.net, and send that. When dereferenced, >>>> it >>>> would return the agreed-upon location. >>>> >>>> Brian >>>> >>>> >>>>> -----Original Message----- >>>>> From: ecrit-bounces@ietf.org >>>>> >>>> [mailto:ecrit-bounces@ietf.org] On Behalf >>>> >>>>> Of James M. Polk >>>>> Sent: Wednesday, March 05, 2008 2:29 PM >>>>> To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; >>>>> ecrit@ietf.org >>>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 >>>>> (cell-id) >>>>> >>>>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: >>>>> >>>>>> Cell-id is an identifier of a geographical area which is mapped >>>>>> to psap already in today's databases. If you'll make an IP based >>>>>> emergency call on cellular, that will use now and for many >>>>>> >>>> years to >>>> >>>>>> come the cell-id to select the psap where to direct your >>>>>> >>>> call. GAbor >>>> >>>>> let's discuss this topic as its own thread. >>>>> >>>>> All (not just some or one) of the following questions need to be >>>>> answered positively and definitively in order for your Cell-id >>>>> scenario to work in IP. >>>>> >>>>> Where is the Cell-id to PSAP URI mapping done? >>>>> >>>>> What database has this information? >>>>> >>>>> What IP protocol is used to resolve this mapping of Cell-id to >>>>> (appropriate) PSAP? >>>>> >>>>> Where is this IP-based server located? >>>>> >>>>> How can LoST be used to discover this? >>>>> >>>>> What LCP will give this Cell-id to a phone to include in a >>>>> >>>> SIP message? >>>> >>>>> What SIP header is this information placed in? >>>>> >>>>> What form does this Cell-id have in the SIP header from the >>>>> >>>> previous >>>> >>>>> question? >>>>> >>>>> What IETF document(s) specifies this header and Cell-id form? >>>>> >>>>> James >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> _______________________________________________ >> 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 ecrit-bounces@ietf.org Thu Mar 6 12:34:55 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A21328C42C; Thu, 6 Mar 2008 12:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.617 X-Spam-Level: X-Spam-Status: No, score=-100.617 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yUV9Q8RSKJJ; Thu, 6 Mar 2008 12:34:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F0AF28C9E5; Thu, 6 Mar 2008 12:34:41 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABD7128C4EA for ; Thu, 6 Mar 2008 12:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IekL1F3BHuFQ for ; Thu, 6 Mar 2008 12:34:39 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 1582628C8F0 for ; Thu, 6 Mar 2008 12:33:38 -0800 (PST) Received: from dynamic-acs-24-154-127-115.zoominternet.net ([24.154.127.115] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JXMmG-0003eG-Iu; Thu, 06 Mar 2008 14:33:21 -0600 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'Richard Barnes'" References: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com><00b401c87f02$89eafcc0$270d0d0a@cisco.com> <47D04A77.2020502@bbn.com> <47D051AC.5080108@gmx.net> Date: Thu, 6 Mar 2008 15:33:23 -0500 Message-ID: <007c01c87fc9$55217830$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47D051AC.5080108@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Ach/x2UDJediq1syTUGw9m4XJW1SmAAAD4iA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: Gabor.Bajko@nokia.com, ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think we can dismiss the LoST query; LoST needs actual location (geo or civic) to make the query work. We went through the discussion several times about the advisability of sending an indirect location (reference) to LoST and have LoST translate that to geo or civic. We decided not to do that. So, unless there are new arguments to why LoST should do the indirect cell-id to geo/civic dereference, I think whoever queries LoST has to do the dereference. In North America, at least, the LoST server will be the responsibility of the local 9-1-1 Authority. It can facilitate a carrier or access network maintaining a local copy of the server, but the data comes from the 9-1-1 Authority. For LoST to have the ability to map from cell id to geo/civic, the 9-1-1 Authority would have to have the mappings. The operators did not want to provide that data. Routing of emergency calls based on cell site/sector is a decision process: the PSAPs and the carriers decide, for each site/sector, which PSAP gets the call. Today, they do that by picking a geo/civic that represents a site/sector and routing on that. If you want to change that, we need to do a fair amount of work, not only protocol, but process and data flow. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Thursday, March 06, 2008 3:19 PM > To: Richard Barnes > Cc: Gabor.Bajko@nokia.com; ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > Hi Richard, > > there are two cases: > > 1) The LoST server is somewhere close to the access. Then, the cell-ids > are sort of local and known to the LoST server (i.e., the location of > the cell). > > 2) Some companies have global cell-id databases. I have some time ago > sent a mail to the list about the approach Google is using that does not > require any coorporation from the access provider to determine your > rough location. > > Ciao > Hannes > > > Richard Barnes wrote: > > Gabor, > > > > If I have a cell-id, how do I figure out where that cell is? Is there a > > well-defined mechanism for doing that over IP? (I'm not trying to be > > rhetorical here, I just don't know.) > > > > My concern with using cell-id as a "pointer" to location in the Internet > > context is that there may not be a way to dereference that pointer > > (i.e., obtain the location of the cell) without going outside the > > Internet, e.g., to a 3GPP non-IP interface or some other database. > > > > --Richard > > > > > > > > > > > > Gabor.Bajko@nokia.com wrote: > > > >> The cell-id (cgi) is a global, well defined and understood in the > >> cellular world. There are no interoperability issues with it. If you > >> think otherwise, please give examples. > >> > >> Pidf-lo is an object which encapsulates preexisting location > information > >> but it does not define the format of it. > >> > >> - gabor > >> > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >> Of ext James M. Polk > >> Sent: Wednesday, March 05, 2008 2:43 PM > >> To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; > >> br@brianrosen.net; ecrit@ietf.org > >> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > >> > >> At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > >> > >>> Right. But that means relaxing the requirement "8. section 6.1 "Other > >>> forms of location representation must be mapped into either a geo or > >>> civic for use in emergency calls" in the draft and allow other type of > >>> location information, all those which make sense in their specific > >>> context. > >>> > >> I don't understand why you want anything relaxed. The requirement says > >> PIDF-LO is the only location format to be used, and that the > >> is geo or civic. This is a MUST for interoperability > >> reasons. Cell-id doesn't accomplish this. > >> > >> > >> > >>> Gabor > >>> > >>> -----Original Message----- > >>> From: ext Marc Linsner [mailto:mlinsner@cisco.com] > >>> Sent: Wednesday, March 05, 2008 12:50 PM > >>> To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); ecrit@ietf.org > >>> Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > >>> > >>> Of course there is no reason the operator couldn't provide civic > >>> location > >>> (123 Main St.) in place of cell-id either (verses a geo location). > The > >>> > >>> main objective is to have location information in the device such that > >>> it makes sense to the consumer vs. every context having their own > >>> location descriptions (cell-id, water meter number, telephone pole id, > >>> property tax plat number, fire hydrant inventory id, msag address, > >>> etc.). > >>> > >>> -Marc- > >>> > >>> > >>>> -----Original Message----- > >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>>> Behalf > >>>> Of Brian Rosen > >>>> Sent: Wednesday, March 05, 2008 2:53 PM > >>>> To: 'James M. Polk'; Gabor.Bajko@nokia.com; > >>>> Hannes.Tschofenig@gmx.net; > >>>> ecrit@ietf.org > >>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > >>>> > >>>> The basic agreement we have made, in NENA, is that the operator will > >>>> > >>>> agree with the PSAP on a location for the cellid. This could be a > >>>> point or a polygon. That location will be reported, in PIDF-LO > >>>> form, from the LIS. > >>>> There was a discussion about actually allowing a cell-id as an > >>>> alternate form of location representation, but it was decided not to > >>>> > >>>> do that. A LIS could, of course, construct a location reference of > >>>> the form sip:@opco.net, and send that. When dereferenced, > >>>> it > >>>> would return the agreed-upon location. > >>>> > >>>> Brian > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: ecrit-bounces@ietf.org > >>>>> > >>>> [mailto:ecrit-bounces@ietf.org] On Behalf > >>>> > >>>>> Of James M. Polk > >>>>> Sent: Wednesday, March 05, 2008 2:29 PM > >>>>> To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > >>>>> ecrit@ietf.org > >>>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > >>>>> (cell-id) > >>>>> > >>>>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > >>>>> > >>>>>> Cell-id is an identifier of a geographical area which is mapped > >>>>>> to psap already in today's databases. If you'll make an IP based > >>>>>> emergency call on cellular, that will use now and for many > >>>>>> > >>>> years to > >>>> > >>>>>> come the cell-id to select the psap where to direct your > >>>>>> > >>>> call. GAbor > >>>> > >>>>> let's discuss this topic as its own thread. > >>>>> > >>>>> All (not just some or one) of the following questions need to be > >>>>> answered positively and definitively in order for your Cell-id > >>>>> scenario to work in IP. > >>>>> > >>>>> Where is the Cell-id to PSAP URI mapping done? > >>>>> > >>>>> What database has this information? > >>>>> > >>>>> What IP protocol is used to resolve this mapping of Cell-id to > >>>>> (appropriate) PSAP? > >>>>> > >>>>> Where is this IP-based server located? > >>>>> > >>>>> How can LoST be used to discover this? > >>>>> > >>>>> What LCP will give this Cell-id to a phone to include in a > >>>>> > >>>> SIP message? > >>>> > >>>>> What SIP header is this information placed in? > >>>>> > >>>>> What form does this Cell-id have in the SIP header from the > >>>>> > >>>> previous > >>>> > >>>>> question? > >>>>> > >>>>> What IETF document(s) specifies this header and Cell-id form? > >>>>> > >>>>> James > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >> _______________________________________________ > >> 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 ecrit-bounces@ietf.org Thu Mar 6 12:52:21 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708503A6F13; Thu, 6 Mar 2008 12:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.606 X-Spam-Level: X-Spam-Status: No, score=-100.606 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecvaibuIkogc; Thu, 6 Mar 2008 12:52:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD573A6D83; Thu, 6 Mar 2008 12:52:20 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABE0428C2AC for ; Thu, 6 Mar 2008 12:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBjMmNA4tJkO for ; Thu, 6 Mar 2008 12:52:17 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C1B8F3A6A0B for ; Thu, 6 Mar 2008 12:52:16 -0800 (PST) Received: (qmail invoked by alias); 06 Mar 2008 20:52:05 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp027) with SMTP; 06 Mar 2008 21:52:05 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18mrVBHmFMmndPuSfkzkCgAI6y3qn+rKtx0CZq8DH 0kjC7eKfxuIoIh Message-ID: <47D05973.7040702@gmx.net> Date: Thu, 06 Mar 2008 22:52:03 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Brian Rosen References: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com><00b401c87f02$89eafcc0$270d0d0a@cisco.com> <47D04A77.2020502@bbn.com> <47D051AC.5080108@gmx.net> <007c01c87fc9$55217830$640fa8c0@cis.neustar.com> In-Reply-To: <007c01c87fc9$55217830$640fa8c0@cis.neustar.com> X-Y-GMX-Trusted: 0 Cc: Gabor.Bajko@nokia.com, ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org So, it seems that you would rather be in favor of using an LCP to obtain location based on the cell-ID and then todo the LoST lookup. Theoretically this would be a nice solution. However, can you imagine that cellular operators are going to like it to essentially give their cell-id to location mapping away for free? While this information is currently available to Google and other large companies it did cost them a HUGE amount of money to get hold of that data. I doubt that Google would share it with other people for free either. So, do you see a practical problem? Ciao Hannes Brian Rosen wrote: > I think we can dismiss the LoST query; LoST needs actual location (geo or > civic) to make the query work. We went through the discussion several times > about the advisability of sending an indirect location (reference) to LoST > and have LoST translate that to geo or civic. We decided not to do that. > So, unless there are new arguments to why LoST should do the indirect > cell-id to geo/civic dereference, I think whoever queries LoST has to do the > dereference. > > In North America, at least, the LoST server will be the responsibility of > the local 9-1-1 Authority. It can facilitate a carrier or access network > maintaining a local copy of the server, but the data comes from the 9-1-1 > Authority. For LoST to have the ability to map from cell id to geo/civic, > the 9-1-1 Authority would have to have the mappings. The operators did not > want to provide that data. > > Routing of emergency calls based on cell site/sector is a decision process: > the PSAPs and the carriers decide, for each site/sector, which PSAP gets the > call. Today, they do that by picking a geo/civic that represents a > site/sector and routing on that. If you want to change that, we need to do > a fair amount of work, not only protocol, but process and data flow. > > Brian > > > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> Hannes Tschofenig >> Sent: Thursday, March 06, 2008 3:19 PM >> To: Richard Barnes >> Cc: Gabor.Bajko@nokia.com; ecrit@ietf.org >> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) >> >> Hi Richard, >> >> there are two cases: >> >> 1) The LoST server is somewhere close to the access. Then, the cell-ids >> are sort of local and known to the LoST server (i.e., the location of >> the cell). >> >> 2) Some companies have global cell-id databases. I have some time ago >> sent a mail to the list about the approach Google is using that does not >> require any coorporation from the access provider to determine your >> rough location. >> >> Ciao >> Hannes >> >> >> Richard Barnes wrote: >> >>> Gabor, >>> >>> If I have a cell-id, how do I figure out where that cell is? Is there a >>> well-defined mechanism for doing that over IP? (I'm not trying to be >>> rhetorical here, I just don't know.) >>> >>> My concern with using cell-id as a "pointer" to location in the Internet >>> context is that there may not be a way to dereference that pointer >>> (i.e., obtain the location of the cell) without going outside the >>> Internet, e.g., to a 3GPP non-IP interface or some other database. >>> >>> --Richard >>> >>> >>> >>> >>> >>> Gabor.Bajko@nokia.com wrote: >>> >>> >>>> The cell-id (cgi) is a global, well defined and understood in the >>>> cellular world. There are no interoperability issues with it. If you >>>> think otherwise, please give examples. >>>> >>>> Pidf-lo is an object which encapsulates preexisting location >>>> >> information >> >>>> but it does not define the format of it. >>>> >>>> - gabor >>>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>>> Of ext James M. Polk >>>> Sent: Wednesday, March 05, 2008 2:43 PM >>>> To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; >>>> br@brianrosen.net; ecrit@ietf.org >>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) >>>> >>>> At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: >>>> >>>> >>>>> Right. But that means relaxing the requirement "8. section 6.1 "Other >>>>> forms of location representation must be mapped into either a geo or >>>>> civic for use in emergency calls" in the draft and allow other type of >>>>> location information, all those which make sense in their specific >>>>> context. >>>>> >>>>> >>>> I don't understand why you want anything relaxed. The requirement says >>>> PIDF-LO is the only location format to be used, and that the >>>> is geo or civic. This is a MUST for interoperability >>>> reasons. Cell-id doesn't accomplish this. >>>> >>>> >>>> >>>> >>>>> Gabor >>>>> >>>>> -----Original Message----- >>>>> From: ext Marc Linsner [mailto:mlinsner@cisco.com] >>>>> Sent: Wednesday, March 05, 2008 12:50 PM >>>>> To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); ecrit@ietf.org >>>>> Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) >>>>> >>>>> Of course there is no reason the operator couldn't provide civic >>>>> location >>>>> (123 Main St.) in place of cell-id either (verses a geo location). >>>>> >> The >> >>>>> main objective is to have location information in the device such that >>>>> it makes sense to the consumer vs. every context having their own >>>>> location descriptions (cell-id, water meter number, telephone pole id, >>>>> property tax plat number, fire hydrant inventory id, msag address, >>>>> etc.). >>>>> >>>>> -Marc- >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>>>> Behalf >>>>>> Of Brian Rosen >>>>>> Sent: Wednesday, March 05, 2008 2:53 PM >>>>>> To: 'James M. Polk'; Gabor.Bajko@nokia.com; >>>>>> Hannes.Tschofenig@gmx.net; >>>>>> ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) >>>>>> >>>>>> The basic agreement we have made, in NENA, is that the operator will >>>>>> >>>>>> agree with the PSAP on a location for the cellid. This could be a >>>>>> point or a polygon. That location will be reported, in PIDF-LO >>>>>> form, from the LIS. >>>>>> There was a discussion about actually allowing a cell-id as an >>>>>> alternate form of location representation, but it was decided not to >>>>>> >>>>>> do that. A LIS could, of course, construct a location reference of >>>>>> the form sip:@opco.net, and send that. When dereferenced, >>>>>> it >>>>>> would return the agreed-upon location. >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ecrit-bounces@ietf.org >>>>>>> >>>>>>> >>>>>> [mailto:ecrit-bounces@ietf.org] On Behalf >>>>>> >>>>>> >>>>>>> Of James M. Polk >>>>>>> Sent: Wednesday, March 05, 2008 2:29 PM >>>>>>> To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; >>>>>>> ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 >>>>>>> (cell-id) >>>>>>> >>>>>>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: >>>>>>> >>>>>>> >>>>>>>> Cell-id is an identifier of a geographical area which is mapped >>>>>>>> to psap already in today's databases. If you'll make an IP based >>>>>>>> emergency call on cellular, that will use now and for many >>>>>>>> >>>>>>>> >>>>>> years to >>>>>> >>>>>> >>>>>>>> come the cell-id to select the psap where to direct your >>>>>>>> >>>>>>>> >>>>>> call. GAbor >>>>>> >>>>>> >>>>>>> let's discuss this topic as its own thread. >>>>>>> >>>>>>> All (not just some or one) of the following questions need to be >>>>>>> answered positively and definitively in order for your Cell-id >>>>>>> scenario to work in IP. >>>>>>> >>>>>>> Where is the Cell-id to PSAP URI mapping done? >>>>>>> >>>>>>> What database has this information? >>>>>>> >>>>>>> What IP protocol is used to resolve this mapping of Cell-id to >>>>>>> (appropriate) PSAP? >>>>>>> >>>>>>> Where is this IP-based server located? >>>>>>> >>>>>>> How can LoST be used to discover this? >>>>>>> >>>>>>> What LCP will give this Cell-id to a phone to include in a >>>>>>> >>>>>>> >>>>>> SIP message? >>>>>> >>>>>> >>>>>>> What SIP header is this information placed in? >>>>>>> >>>>>>> What form does this Cell-id have in the SIP header from the >>>>>>> >>>>>>> >>>>>> previous >>>>>> >>>>>> >>>>>>> question? >>>>>>> >>>>>>> What IETF document(s) specifies this header and Cell-id form? >>>>>>> >>>>>>> James >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> _______________________________________________ >>>> 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 ecrit-bounces@ietf.org Thu Mar 6 13:03:22 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B0BC28C5FE; Thu, 6 Mar 2008 13:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.643 X-Spam-Level: X-Spam-Status: No, score=-100.643 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWnZIiCjJkgs; Thu, 6 Mar 2008 13:03:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10FCE28C905; Thu, 6 Mar 2008 13:03:21 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8457C28C905 for ; Thu, 6 Mar 2008 13:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nqExb2Px82U for ; Thu, 6 Mar 2008 13:03:16 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 01ABB28C92B for ; Thu, 6 Mar 2008 13:03:16 -0800 (PST) Received: from dynamic-acs-24-154-127-115.zoominternet.net ([24.154.127.115] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JXNEw-0006th-JO; Thu, 06 Mar 2008 15:02:58 -0600 From: "Brian Rosen" To: "'Hannes Tschofenig'" References: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com><00b401c87f02$89eafcc0$270d0d0a@cisco.com> <47D04A77.2020502@bbn.com> <47D051AC.5080108@gmx.net> <007c01c87fc9$55217830$640fa8c0@cis.neustar.com> <47D05973.7040702@gmx.net> Date: Thu, 6 Mar 2008 16:02:59 -0500 Message-ID: <008401c87fcd$776c2b20$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47D05973.7040702@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Ach/y+4c56gimAXDSp2A/2UWnZwwqAAASkUw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: Gabor.Bajko@nokia.com, ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org What networks are we talking about? All the ones I know that are in to location hiding either do proxy insertion of location at an E-CSCF or hand out an opaque reference that will return some location that routes to the correct PSAP to the endpoint, and the best location available at the time of dereference to the PSAP. They don't need anything else. What kind of networks were you thinking about? Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Thursday, March 06, 2008 3:52 PM > To: Brian Rosen > Cc: 'Richard Barnes'; Gabor.Bajko@nokia.com; ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > So, it seems that you would rather be in favor of using an LCP to obtain > location based on the cell-ID and then todo the LoST lookup. > Theoretically this would be a nice solution. > > However, can you imagine that cellular operators are going to like it to > essentially give their cell-id to location mapping away for free? > While this information is currently available to Google and other large > companies it did cost them a HUGE amount of money to get hold of that > data. > I doubt that Google would share it with other people for free either. > > So, do you see a practical problem? > > Ciao > Hannes > > Brian Rosen wrote: > > I think we can dismiss the LoST query; LoST needs actual location (geo > or > > civic) to make the query work. We went through the discussion several > times > > about the advisability of sending an indirect location (reference) to > LoST > > and have LoST translate that to geo or civic. We decided not to do > that. > > So, unless there are new arguments to why LoST should do the indirect > > cell-id to geo/civic dereference, I think whoever queries LoST has to do > the > > dereference. > > > > In North America, at least, the LoST server will be the responsibility > of > > the local 9-1-1 Authority. It can facilitate a carrier or access > network > > maintaining a local copy of the server, but the data comes from the 9-1- > 1 > > Authority. For LoST to have the ability to map from cell id to > geo/civic, > > the 9-1-1 Authority would have to have the mappings. The operators did > not > > want to provide that data. > > > > Routing of emergency calls based on cell site/sector is a decision > process: > > the PSAPs and the carriers decide, for each site/sector, which PSAP gets > the > > call. Today, they do that by picking a geo/civic that represents a > > site/sector and routing on that. If you want to change that, we need to > do > > a fair amount of work, not only protocol, but process and data flow. > > > > Brian > > > > > > > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > >> Hannes Tschofenig > >> Sent: Thursday, March 06, 2008 3:19 PM > >> To: Richard Barnes > >> Cc: Gabor.Bajko@nokia.com; ecrit@ietf.org > >> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > >> > >> Hi Richard, > >> > >> there are two cases: > >> > >> 1) The LoST server is somewhere close to the access. Then, the cell-ids > >> are sort of local and known to the LoST server (i.e., the location of > >> the cell). > >> > >> 2) Some companies have global cell-id databases. I have some time ago > >> sent a mail to the list about the approach Google is using that does > not > >> require any coorporation from the access provider to determine your > >> rough location. > >> > >> Ciao > >> Hannes > >> > >> > >> Richard Barnes wrote: > >> > >>> Gabor, > >>> > >>> If I have a cell-id, how do I figure out where that cell is? Is there > a > >>> well-defined mechanism for doing that over IP? (I'm not trying to be > >>> rhetorical here, I just don't know.) > >>> > >>> My concern with using cell-id as a "pointer" to location in the > Internet > >>> context is that there may not be a way to dereference that pointer > >>> (i.e., obtain the location of the cell) without going outside the > >>> Internet, e.g., to a 3GPP non-IP interface or some other database. > >>> > >>> --Richard > >>> > >>> > >>> > >>> > >>> > >>> Gabor.Bajko@nokia.com wrote: > >>> > >>> > >>>> The cell-id (cgi) is a global, well defined and understood in the > >>>> cellular world. There are no interoperability issues with it. If you > >>>> think otherwise, please give examples. > >>>> > >>>> Pidf-lo is an object which encapsulates preexisting location > >>>> > >> information > >> > >>>> but it does not define the format of it. > >>>> > >>>> - gabor > >>>> > >>>> -----Original Message----- > >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > >>>> Of ext James M. Polk > >>>> Sent: Wednesday, March 05, 2008 2:43 PM > >>>> To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; > >>>> br@brianrosen.net; ecrit@ietf.org > >>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > >>>> > >>>> At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > >>>> > >>>> > >>>>> Right. But that means relaxing the requirement "8. section 6.1 > "Other > >>>>> forms of location representation must be mapped into either a geo or > >>>>> civic for use in emergency calls" in the draft and allow other type > of > >>>>> location information, all those which make sense in their specific > >>>>> context. > >>>>> > >>>>> > >>>> I don't understand why you want anything relaxed. The requirement > says > >>>> PIDF-LO is the only location format to be used, and that the > >>>> is geo or civic. This is a MUST for interoperability > >>>> reasons. Cell-id doesn't accomplish this. > >>>> > >>>> > >>>> > >>>> > >>>>> Gabor > >>>>> > >>>>> -----Original Message----- > >>>>> From: ext Marc Linsner [mailto:mlinsner@cisco.com] > >>>>> Sent: Wednesday, March 05, 2008 12:50 PM > >>>>> To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); ecrit@ietf.org > >>>>> Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > >>>>> > >>>>> Of course there is no reason the operator couldn't provide civic > >>>>> location > >>>>> (123 Main St.) in place of cell-id either (verses a geo location). > >>>>> > >> The > >> > >>>>> main objective is to have location information in the device such > that > >>>>> it makes sense to the consumer vs. every context having their own > >>>>> location descriptions (cell-id, water meter number, telephone pole > id, > >>>>> property tax plat number, fire hydrant inventory id, msag address, > >>>>> etc.). > >>>>> > >>>>> -Marc- > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>>>>> Behalf > >>>>>> Of Brian Rosen > >>>>>> Sent: Wednesday, March 05, 2008 2:53 PM > >>>>>> To: 'James M. Polk'; Gabor.Bajko@nokia.com; > >>>>>> Hannes.Tschofenig@gmx.net; > >>>>>> ecrit@ietf.org > >>>>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > >>>>>> > >>>>>> The basic agreement we have made, in NENA, is that the operator > will > >>>>>> > >>>>>> agree with the PSAP on a location for the cellid. This could be a > >>>>>> point or a polygon. That location will be reported, in PIDF-LO > >>>>>> form, from the LIS. > >>>>>> There was a discussion about actually allowing a cell-id as an > >>>>>> alternate form of location representation, but it was decided not > to > >>>>>> > >>>>>> do that. A LIS could, of course, construct a location reference of > >>>>>> the form sip:@opco.net, and send that. When dereferenced, > >>>>>> it > >>>>>> would return the agreed-upon location. > >>>>>> > >>>>>> Brian > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: ecrit-bounces@ietf.org > >>>>>>> > >>>>>>> > >>>>>> [mailto:ecrit-bounces@ietf.org] On Behalf > >>>>>> > >>>>>> > >>>>>>> Of James M. Polk > >>>>>>> Sent: Wednesday, March 05, 2008 2:29 PM > >>>>>>> To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > >>>>>>> ecrit@ietf.org > >>>>>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > >>>>>>> (cell-id) > >>>>>>> > >>>>>>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > >>>>>>> > >>>>>>> > >>>>>>>> Cell-id is an identifier of a geographical area which is mapped > >>>>>>>> to psap already in today's databases. If you'll make an IP based > >>>>>>>> emergency call on cellular, that will use now and for many > >>>>>>>> > >>>>>>>> > >>>>>> years to > >>>>>> > >>>>>> > >>>>>>>> come the cell-id to select the psap where to direct your > >>>>>>>> > >>>>>>>> > >>>>>> call. GAbor > >>>>>> > >>>>>> > >>>>>>> let's discuss this topic as its own thread. > >>>>>>> > >>>>>>> All (not just some or one) of the following questions need to be > >>>>>>> answered positively and definitively in order for your Cell-id > >>>>>>> scenario to work in IP. > >>>>>>> > >>>>>>> Where is the Cell-id to PSAP URI mapping done? > >>>>>>> > >>>>>>> What database has this information? > >>>>>>> > >>>>>>> What IP protocol is used to resolve this mapping of Cell-id to > >>>>>>> (appropriate) PSAP? > >>>>>>> > >>>>>>> Where is this IP-based server located? > >>>>>>> > >>>>>>> How can LoST be used to discover this? > >>>>>>> > >>>>>>> What LCP will give this Cell-id to a phone to include in a > >>>>>>> > >>>>>>> > >>>>>> SIP message? > >>>>>> > >>>>>> > >>>>>>> What SIP header is this information placed in? > >>>>>>> > >>>>>>> What form does this Cell-id have in the SIP header from the > >>>>>>> > >>>>>>> > >>>>>> previous > >>>>>> > >>>>>> > >>>>>>> question? > >>>>>>> > >>>>>>> What IETF document(s) specifies this header and Cell-id form? > >>>>>>> > >>>>>>> James > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>> _______________________________________________ > >>>> 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 ecrit-bounces@ietf.org Thu Mar 6 13:45:32 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D3603A6F4C; Thu, 6 Mar 2008 13:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.623 X-Spam-Level: X-Spam-Status: No, score=-100.623 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOGdnc+x4X1q; Thu, 6 Mar 2008 13:45:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D53503A6E3C; Thu, 6 Mar 2008 13:45:13 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7513A68AE for ; Thu, 6 Mar 2008 13:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qetnsN46TJkA for ; Thu, 6 Mar 2008 13:45:08 -0800 (PST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id B89753A6821 for ; Thu, 6 Mar 2008 13:45:07 -0800 (PST) Received: from dhcp1.cs.columbia.edu (dhcp1.cs.columbia.edu [128.59.19.201]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m26Lip59003757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 6 Mar 2008 16:44:51 -0500 (EST) Message-Id: From: Henning Schulzrinne To: Hannes Tschofenig In-Reply-To: <47D05973.7040702@gmx.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 6 Mar 2008 16:44:51 -0500 References: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com><00b401c87f02$89eafcc0$270d0d0a@cisco.com> <47D04A77.2020502@bbn.com> <47D051AC.5080108@gmx.net> <007c01c87fc9$55217830$640fa8c0@cis.neustar.com> <47D05973.7040702@gmx.net> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6 Cc: Gabor.Bajko@nokia.com, ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org First two results in Google http://client338.lab.telin.nl:8080/wasp/jsp/CellStats.jsp http://www.cellspotting.com/webpages/cellspotting.html Another selling-location-idea bites the dust :-) On Mar 6, 2008, at 3:52 PM, Hannes Tschofenig wrote: > So, it seems that you would rather be in favor of using an LCP to > obtain > location based on the cell-ID and then todo the LoST lookup. > Theoretically this would be a nice solution. > > However, can you imagine that cellular operators are going to like > it to > essentially give their cell-id to location mapping away for free? > While this information is currently available to Google and other > large > companies it did cost them a HUGE amount of money to get hold of > that data. > I doubt that Google would share it with other people for free either. > > So, do you see a practical problem? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 6 14:15:04 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36613A6EA4; Thu, 6 Mar 2008 14:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.486 X-Spam-Level: X-Spam-Status: No, score=-100.486 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRQhYoem4Ijx; Thu, 6 Mar 2008 14:15:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E08628C8E1; Thu, 6 Mar 2008 14:14:43 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7653A6AFE for ; Thu, 6 Mar 2008 14:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfZaZSaPwlca for ; Thu, 6 Mar 2008 14:14:40 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 8C54D3A6B7C for ; Thu, 6 Mar 2008 14:14:14 -0800 (PST) X-SEF-Processed: 5_0_0_910__2008_03_06_16_26_45 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 06 Mar 2008 16:26:44 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Mar 2008 16:14:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 16:09:52 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) Thread-Index: Ach/wzBRtxbESMZqTD+ZYu8cdpsIsQAE5z0j References: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com><00b401c87f02$89eafcc0$270d0d0a@cisco.com> <47D04A77.2020502@bbn.com> From: "Winterbottom, James" To: "Richard Barnes" , X-OriginalArrivalTime: 06 Mar 2008 22:14:03.0822 (UTC) FILETIME=[632674E0:01C87FD7] Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Richard, The Cell-ID is made up of 4 parts: MCC = Mobile Country Code MNC = Mobile Network Code (the operator) LAC = Local Area Code Cell = The number of the cell So with this, it is actually possible to easily work out where the operator is at least to a national level, and who the operator is. The other components are assigned by the operator and and would need the operator to either provide this information to LoST directly, or provide an interface to a specific LoST server to query. Given the operator sensitivity to this information being generally public, and the amount of cell-id movement that goes on, this may actually become quite impractical quite quickly. Some operators I deal with for example have more than 400k cells in just one country. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Richard Barnes Sent: Thu 3/6/2008 1:48 PM To: Gabor.Bajko@nokia.com Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) Gabor, If I have a cell-id, how do I figure out where that cell is? Is there a well-defined mechanism for doing that over IP? (I'm not trying to be rhetorical here, I just don't know.) My concern with using cell-id as a "pointer" to location in the Internet context is that there may not be a way to dereference that pointer (i.e., obtain the location of the cell) without going outside the Internet, e.g., to a 3GPP non-IP interface or some other database. --Richard Gabor.Bajko@nokia.com wrote: > The cell-id (cgi) is a global, well defined and understood in the > cellular world. There are no interoperability issues with it. If you > think otherwise, please give examples. > > Pidf-lo is an object which encapsulates preexisting location information > but it does not define the format of it. > > - gabor > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of ext James M. Polk > Sent: Wednesday, March 05, 2008 2:43 PM > To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; > br@brianrosen.net; ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: >> Right. But that means relaxing the requirement "8. section 6.1 "Other >> forms of location representation must be mapped into either a geo or >> civic for use in emergency calls" in the draft and allow other type of >> location information, all those which make sense in their specific >> context. > > I don't understand why you want anything relaxed. The requirement says > PIDF-LO is the only location format to be used, and that the > is geo or civic. This is a MUST for interoperability > reasons. Cell-id doesn't accomplish this. > > >> Gabor >> >> -----Original Message----- >> From: ext Marc Linsner [mailto:mlinsner@cisco.com] >> Sent: Wednesday, March 05, 2008 12:50 PM >> To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); ecrit@ietf.org >> Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) >> >> Of course there is no reason the operator couldn't provide civic >> location >> (123 Main St.) in place of cell-id either (verses a geo location). The > >> main objective is to have location information in the device such that >> it makes sense to the consumer vs. every context having their own >> location descriptions (cell-id, water meter number, telephone pole id, >> property tax plat number, fire hydrant inventory id, msag address, >> etc.). >> >> -Marc- >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> Behalf >>> Of Brian Rosen >>> Sent: Wednesday, March 05, 2008 2:53 PM >>> To: 'James M. Polk'; Gabor.Bajko@nokia.com; >>> Hannes.Tschofenig@gmx.net; >>> ecrit@ietf.org >>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) >>> >>> The basic agreement we have made, in NENA, is that the operator will > >>> agree with the PSAP on a location for the cellid. This could be a >>> point or a polygon. That location will be reported, in PIDF-LO >>> form, from the LIS. >>> There was a discussion about actually allowing a cell-id as an >>> alternate form of location representation, but it was decided not to > >>> do that. A LIS could, of course, construct a location reference of >>> the form sip:@opco.net, and send that. When dereferenced, >>> it >>> would return the agreed-upon location. >>> >>> Brian >>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org >>> [mailto:ecrit-bounces@ietf.org] On Behalf >>>> Of James M. Polk >>>> Sent: Wednesday, March 05, 2008 2:29 PM >>>> To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; >>>> ecrit@ietf.org >>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 >>>> (cell-id) >>>> >>>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: >>>>> Cell-id is an identifier of a geographical area which is mapped >>>>> to psap already in today's databases. If you'll make an IP based >>>>> emergency call on cellular, that will use now and for many >>> years to >>>>> come the cell-id to select the psap where to direct your >>> call. GAbor >>>> let's discuss this topic as its own thread. >>>> >>>> All (not just some or one) of the following questions need to be >>>> answered positively and definitively in order for your Cell-id >>>> scenario to work in IP. >>>> >>>> Where is the Cell-id to PSAP URI mapping done? >>>> >>>> What database has this information? >>>> >>>> What IP protocol is used to resolve this mapping of Cell-id to >>>> (appropriate) PSAP? >>>> >>>> Where is this IP-based server located? >>>> >>>> How can LoST be used to discover this? >>>> >>>> What LCP will give this Cell-id to a phone to include in a >>> SIP message? >>>> What SIP header is this information placed in? >>>> >>>> What form does this Cell-id have in the SIP header from the >>> previous >>>> question? >>>> >>>> What IETF document(s) specifies this header and Cell-id form? >>>> >>>> James >>>> >>>> >>>> _______________________________________________ >>>> 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 > _______________________________________________ > 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 ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 6 15:17:13 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5693A685C; Thu, 6 Mar 2008 15:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.369 X-Spam-Level: X-Spam-Status: No, score=-100.369 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpUxLp8-JG5g; Thu, 6 Mar 2008 15:17:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B47DB28C28E; Thu, 6 Mar 2008 15:17:12 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF7573A6B94 for ; Thu, 6 Mar 2008 15:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bw5nW+GAnBF for ; Thu, 6 Mar 2008 15:17:09 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id A58193A685C for ; Thu, 6 Mar 2008 15:17:09 -0800 (PST) X-SEF-Processed: 5_0_0_910__2008_03_06_17_29_37 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 06 Mar 2008 17:29:37 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Mar 2008 17:16:52 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 17:16:46 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Cell-id in HELD and other parts of the emergency servicesframework? (Was: WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)) Thread-Index: Ach/W2VcM7tMpBrRQh+bdZonicypuAAMFQNgABRrk1A= References: <47CAE9CA.9010901@gmx.net><016f01c87efa$76eb3930$640fa8c0@cis.neustar.com><20080306072621.23460@gmx.net> From: "Thomson, Martin" To: , , , , , X-OriginalArrivalTime: 06 Mar 2008 23:16:52.0992 (UTC) FILETIME=[29C02800:01C87FE0] Subject: Re: [Ecrit] Cell-id in HELD and other parts of the emergency servicesframework? (Was: WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Extend away, but try to understand where the information is going to be consumed. I am not comfortable with a cell identifier escaping the access network context. In fact, I'd argue that a cell identifier is not a form of location, but a parameter that can be used to derive location information when combined with contextual information. The carrier that puts the cell in place knows where the cell is, but it is unreasonable to expect others to know this. (3GPP & OMA evidently agree: see Lr interface and the concepts of V-GMLC and V-SLP) To extend the analogy, would you also mandate that LoST servers also have a database of WiFi access points, WiMAX base stations, cable network head-ends, and so forth? One of the main reasons for having a LIS is to provide the translation from network-specific information (cell-ID) into something more global (lat/long, civic). This means that services can be implemented to use access-agnostic information. I have no objection to someone describing its use, but to expect that a LoST server also have a database that maps cell-ID to location is unreasonable (such a database is necessary for dispatch, even if a routing database also exists). The two accepted forms for location are geodetic and civic and these should be the only mandatory forms. Cheers, Martin (A question from the side-lines: for UMTS would you use the UTRAN cell identifier, the SAI, or allow for both?) > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Markus.Isomaki@nokia.com > Sent: Friday, 7 March 2008 1:07 AM > To: Hannes.Tschofenig@gmx.net; br@brianrosen.net; ecrit@ietf.org; > Gabor.Bajko@nokia.com; jmpolk@cisco.com > Subject: [Ecrit] Cell-id in HELD and other parts of the emergency > servicesframework? (Was: WGLC on draft-ietf-ecrit-phonebcp-04 (cell- > id)) > > Hi, > > Talking about the different scenarios how Cell-id could be used in the > IP emergency service framework, we also still have the "conventional" > way of first mapping it into geo or civic location. > > The phonebcp draft currently says: > > Other forms of > location representation must be mapped into either a geo or civic > for > use in emergency calls. > > So, how do we expect this to happen for Cell-id? One possibility I > would > see is that we could extend HELD so that the HELD request could carry > Cell-id, and the HELD server could use the Cell-id in addition to IP > address to determine the location of the mobile host. (This is what > Google does already in their map application, so actually the server > doing the mapping does not even have to be associated with the access > network, although such association would probably make the mapping more > reliable.) > > Would this seem like a sensible extension to HELD? > > Given how ubiquitous Cell-id already is in the cellular wireless > infrastructure, I think we should actually develop protocols that allow > it to be used in at least these ways: > > a) Use it as an input in LoST for mapping to PSAP URI. > b) Use it as an input in HELD for mapping to geo/civic location. > c) Carry it within the signaling protocol for various potential usages. > I think this is already taken care by what is defined in RFC 3455, > although I suppose it would be more inline with the rest of > ECRIT/GEOPRIV work if it was actually carried within PIDF-LO in > accordance to the SIP location conveyance. > > Markus > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of ext Hannes Tschofenig > >Sent: 06 March, 2008 09:26 > >To: Brian Rosen; ecrit@ietf.org; Bajko Gabor > >(Nokia-OCTO/MtView); jmpolk@cisco.com > >Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > >We also discussed this topic in a face-to-face meeting between > >the 3GPP and the IETF in July 2006. I recall that we were not > >so negative about the idea of using Cell-IDs. > > > >Furthermore, there are two separate things to consider: > > > >* Cell-ID usage for LoST to obtain a PSAP URI > >* Cell-ID information as information for dispatch. > > > >Gabor is not proposing the second approach. > > > > > >> The basic agreement we have made, in NENA, is that the operator will > >> agree with the PSAP on a location for the cellid. This could be a > >> point or a polygon. That location will be reported, in > >PIDF-LO form, from the LIS. > >> There was a discussion about actually allowing a cell-id as an > >> alternate form of location representation, but it was decided not to > >> do that. A LIS could, of course, construct a location reference of > >> the form sip:@opco.net, and send that. When > >dereferenced, it > >> would return the agreed-upon location. > >> > >> Brian > >> > >> > -----Original Message----- > >> > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> > Behalf > >> Of > >> > James M. Polk > >> > Sent: Wednesday, March 05, 2008 2:29 PM > >> > To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > >ecrit@ietf.org > >> > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell- > id) > >> > > >> > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > >> > >Cell-id is an identifier of a geographical area which is > >mapped to > >> > >psap already in today's databases. If you'll make an IP based > >> > >emergency call on cellular, that will use now and for > >many years to > >> > >come the cell-id > >> to > >> > >select the psap where to direct your call. GAbor > >> > > >> > let's discuss this topic as its own thread. > >> > > >> > All (not just some or one) of the following questions need to be > >> > answered positively and definitively in order for your Cell-id > >> > scenario to work in IP. > >> > > >> > Where is the Cell-id to PSAP URI mapping done? > >> > > >> > What database has this information? > >> > > >> > What IP protocol is used to resolve this mapping of Cell-id to > >> > (appropriate) PSAP? > >> > > >> > Where is this IP-based server located? > >> > > >> > How can LoST be used to discover this? > >> > > >> > What LCP will give this Cell-id to a phone to include in a > >SIP message? > >> > > >> > What SIP header is this information placed in? > >> > > >> > What form does this Cell-id have in the SIP header from > >the previous > >> > question? > >> > > >> > What IETF document(s) specifies this header and Cell-id form? > >> > > >> > James > >> > > >> > > >> > _______________________________________________ > >> > 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 ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 7 01:08:05 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3A9A3A69E1; Fri, 7 Mar 2008 01:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.245 X-Spam-Level: X-Spam-Status: No, score=-100.245 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsaA0xsgymNt; Fri, 7 Mar 2008 01:08:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 009633A6AC6; Fri, 7 Mar 2008 01:08:02 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794063A6AC6 for ; Fri, 7 Mar 2008 01:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBvxB-NwG49M for ; Fri, 7 Mar 2008 01:08:00 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id 34A273A6A91 for ; Fri, 7 Mar 2008 01:07:59 -0800 (PST) Received: from localhost [127.0.0.1] by mail.sbg.nic.at with XWall v3.41 ; Fri, 7 Mar 2008 10:07:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Mar 2008 10:07:47 +0100 Message-ID: <8BC845943058D844ABFC73D2220D4665072B2AD9@nics-mail.sbg.nic.at> In-Reply-To: <47D05973.7040702@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) Thread-Index: Ach/y/mRjpfFRrUdR8e9QRmLCPyo0AAZko+w References: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com><00b401c87f02$89eafcc0$270d0d0a@cisco.com> <47D04A77.2020502@bbn.com><47D051AC.5080108@gmx.net><007c01c87fc9$55217830$640fa8c0@cis.neustar.com> <47D05973.7040702@gmx.net> From: "Alexander Mayrhofer" To: "Hannes Tschofenig" , "Brian Rosen" Cc: Gabor.Bajko@nokia.com, ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > However, can you imagine that cellular operators are going to > like it to > essentially give their cell-id to location mapping away for free? > While this information is currently available to Google and > other large > companies it did cost them a HUGE amount of money to get hold > of that data. > I doubt that Google would share it with other people for free either. Another option is "crowdsourcing" of WLAN SSIDs / MAC addresses. For our office location in Vienna, Loki (www.loki.com) returns a much more precise location than Google's "My Location". Loki claims to use a (proprietory) database of 23 millions access points (provided by www.skyhookwireless.com) - i guess it's just a matter of time until some open alternative database becomes available... cheers Alex _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 7 02:49:46 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6F2528C4BF; Fri, 7 Mar 2008 02:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.73 X-Spam-Level: X-Spam-Status: No, score=-100.73 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFml18KUNmzy; Fri, 7 Mar 2008 02:49:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E286028C493; Fri, 7 Mar 2008 02:49:42 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35C7728C398 for ; Fri, 7 Mar 2008 02:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuw0qsp5x7mK for ; Fri, 7 Mar 2008 02:49:40 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 8B4B728C3B8 for ; Fri, 7 Mar 2008 02:48:44 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m27Am5b5015355; Fri, 7 Mar 2008 12:48:17 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Mar 2008 12:48:03 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Mar 2008 12:48:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Mar 2008 12:48:02 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Cell-id in HELD and other parts of the emergency servicesframework? (Was: WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)) Thread-Index: Ach/W2VcM7tMpBrRQh+bdZonicypuAAMFQNgABRrk1AAGFqMoA== References: <47CAE9CA.9010901@gmx.net><016f01c87efa$76eb3930$640fa8c0@cis.neustar.com><20080306072621.23460@gmx.net> From: To: , , , , , X-OriginalArrivalTime: 07 Mar 2008 10:48:03.0213 (UTC) FILETIME=[B7EDB3D0:01C88040] X-Nokia-AV: Clean Subject: Re: [Ecrit] Cell-id in HELD and other parts of the emergency servicesframework? (Was: WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Martin, Martin Thomson wrote: >One of the main reasons for having a LIS is to provide the >translation from network-specific information (cell-ID) into >something more global (lat/long, civic). This means that >services can be implemented to use access-agnostic information. How do you think this should be done in practice? Would the mobile host use HELD to get its location or reference to it, as usual? How does the mapping from the host's current IP address to one of the location formats happen in practice? I suppose the mobile operator would have AAA server of some sort which can keep track of which IP address is given to which user, but I don't know the rest of the backend infra well enough to understand how the LIS obtains the information it needs to respond to a HELD query. The reason I'm asking is that I'm trying to understand where the Cell-id would fit wrt. HELD and LIS. In practice, would it be useful for the HELD client to tell the LIS what it's Cell-id is directly, or do you expect the backend infra to do all the necessary correlations starting from the IP address? Markus >-----Original Message----- >From: ext Thomson, Martin [mailto:Martin.Thomson@andrew.com] >Sent: 07 March, 2008 01:17 >To: Isomaki Markus (Nokia-OCTO/Espoo); >Hannes.Tschofenig@gmx.net; br@brianrosen.net; ecrit@ietf.org; >Bajko Gabor (Nokia-OCTO/MtView); jmpolk@cisco.com >Subject: RE: [Ecrit] Cell-id in HELD and other parts of the >emergency servicesframework? (Was: WGLC on >draft-ietf-ecrit-phonebcp-04 (cell-id)) > >Extend away, but try to understand where the information is >going to be consumed. > >I am not comfortable with a cell identifier escaping the >access network context. In fact, I'd argue that a cell >identifier is not a form of location, but a parameter that can >be used to derive location information when combined with >contextual information. > >The carrier that puts the cell in place knows where the cell >is, but it is unreasonable to expect others to know this. >(3GPP & OMA evidently >agree: see Lr interface and the concepts of V-GMLC and V-SLP) > >To extend the analogy, would you also mandate that LoST >servers also have a database of WiFi access points, WiMAX base >stations, cable network head-ends, and so forth? > >One of the main reasons for having a LIS is to provide the >translation from network-specific information (cell-ID) into >something more global (lat/long, civic). This means that >services can be implemented to use access-agnostic information. > >I have no objection to someone describing its use, but to >expect that a LoST server also have a database that maps >cell-ID to location is unreasonable (such a database is >necessary for dispatch, even if a routing database also >exists). The two accepted forms for location are geodetic and >civic and these should be the only mandatory forms. > >Cheers, >Martin > > (A question from the side-lines: for UMTS would you use the >UTRAN cell identifier, the SAI, or allow for both?) > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Markus.Isomaki@nokia.com >> Sent: Friday, 7 March 2008 1:07 AM >> To: Hannes.Tschofenig@gmx.net; br@brianrosen.net; ecrit@ietf.org; >> Gabor.Bajko@nokia.com; jmpolk@cisco.com >> Subject: [Ecrit] Cell-id in HELD and other parts of the emergency >> servicesframework? (Was: WGLC on draft-ietf-ecrit-phonebcp-04 (cell- >> id)) >> >> Hi, >> >> Talking about the different scenarios how Cell-id could be >used in the >> IP emergency service framework, we also still have the "conventional" >> way of first mapping it into geo or civic location. >> >> The phonebcp draft currently says: >> >> Other forms of >> location representation must be mapped into either a geo or civic >> for >> use in emergency calls. >> >> So, how do we expect this to happen for Cell-id? One possibility I >> would see is that we could extend HELD so that the HELD >request could >> carry Cell-id, and the HELD server could use the Cell-id in addition >> to IP address to determine the location of the mobile host. (This is >> what Google does already in their map application, so actually the >> server doing the mapping does not even have to be associated >with the >> access network, although such association would probably make the >> mapping >more >> reliable.) >> >> Would this seem like a sensible extension to HELD? >> >> Given how ubiquitous Cell-id already is in the cellular wireless >> infrastructure, I think we should actually develop protocols that >allow >> it to be used in at least these ways: >> >> a) Use it as an input in LoST for mapping to PSAP URI. >> b) Use it as an input in HELD for mapping to geo/civic location. >> c) Carry it within the signaling protocol for various potential >usages. >> I think this is already taken care by what is defined in RFC 3455, >> although I suppose it would be more inline with the rest of >> ECRIT/GEOPRIV work if it was actually carried within PIDF-LO in >> accordance to the SIP location conveyance. >> >> Markus >> >> >> >-----Original Message----- >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> >Behalf Of ext Hannes Tschofenig >> >Sent: 06 March, 2008 09:26 >> >To: Brian Rosen; ecrit@ietf.org; Bajko Gabor (Nokia-OCTO/MtView); >> >jmpolk@cisco.com >> >Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) >> > >> >We also discussed this topic in a face-to-face meeting between the >> >3GPP and the IETF in July 2006. I recall that we were not >so negative >> >about the idea of using Cell-IDs. >> > >> >Furthermore, there are two separate things to consider: >> > >> >* Cell-ID usage for LoST to obtain a PSAP URI >> >* Cell-ID information as information for dispatch. >> > >> >Gabor is not proposing the second approach. >> > >> > >> >> The basic agreement we have made, in NENA, is that the operator >will >> >> agree with the PSAP on a location for the cellid. This >could be a >> >> point or a polygon. That location will be reported, in >> >PIDF-LO form, from the LIS. >> >> There was a discussion about actually allowing a cell-id as an >> >> alternate form of location representation, but it was decided not >to >> >> do that. A LIS could, of course, construct a location >reference of >> >> the form sip:@opco.net, and send that. When >> >dereferenced, it >> >> would return the agreed-upon location. >> >> >> >> Brian >> >> >> >> > -----Original Message----- >> >> > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> >> > Behalf >> >> Of >> >> > James M. Polk >> >> > Sent: Wednesday, March 05, 2008 2:29 PM >> >> > To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; >> >ecrit@ietf.org >> >> > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell- >> id) >> >> > >> >> > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: >> >> > >Cell-id is an identifier of a geographical area which is >> >mapped to >> >> > >psap already in today's databases. If you'll make an IP based >> >> > >emergency call on cellular, that will use now and for >> >many years to >> >> > >come the cell-id >> >> to >> >> > >select the psap where to direct your call. GAbor >> >> > >> >> > let's discuss this topic as its own thread. >> >> > >> >> > All (not just some or one) of the following questions >need to be >> >> > answered positively and definitively in order for your Cell-id >> >> > scenario to work in IP. >> >> > >> >> > Where is the Cell-id to PSAP URI mapping done? >> >> > >> >> > What database has this information? >> >> > >> >> > What IP protocol is used to resolve this mapping of Cell-id to >> >> > (appropriate) PSAP? >> >> > >> >> > Where is this IP-based server located? >> >> > >> >> > How can LoST be used to discover this? >> >> > >> >> > What LCP will give this Cell-id to a phone to include in a >> >SIP message? >> >> > >> >> > What SIP header is this information placed in? >> >> > >> >> > What form does this Cell-id have in the SIP header from >> >the previous >> >> > question? >> >> > >> >> > What IETF document(s) specifies this header and Cell-id form? >> >> > >> >> > James >> >> > >> >> > >> >> > _______________________________________________ >> >> > 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 > >--------------------------------------------------------------- >--------------------------------- >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >--------------------------------------------------------------- >--------------------------------- >[mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 7 03:35:16 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18B7528C382; Fri, 7 Mar 2008 03:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.687 X-Spam-Level: X-Spam-Status: No, score=-100.687 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRqegjHuVrUV; Fri, 7 Mar 2008 03:35:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48FD83A6D02; Fri, 7 Mar 2008 03:35:12 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D77ED3A6AE0 for ; Fri, 7 Mar 2008 03:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WObrMfjwCd1Y for ; Fri, 7 Mar 2008 03:35:09 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 8ABCB3A6BEC for ; Fri, 7 Mar 2008 03:35:09 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m27BYljT021105; Fri, 7 Mar 2008 05:36:34 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Mar 2008 13:34:07 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Mar 2008 13:34:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Mar 2008 13:34:07 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) Thread-Index: Ach/03o6r9jqESAwQTSX4sCufhuIHwAcWhWw References: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com><00b401c87f02$89eafcc0$270d0d0a@cisco.com> <47D04A77.2020502@bbn.com><47D051AC.5080108@gmx.net><007c01c87fc9$55217830$640fa8c0@cis.neustar.com><47D05973.7040702@gmx.net> From: To: , , X-OriginalArrivalTime: 07 Mar 2008 11:34:07.0798 (UTC) FILETIME=[27BFE560:01C88047] X-Nokia-AV: Clean Cc: Gabor.Bajko@nokia.com, ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Henning, Alexander, Henning Schulzrinne wrote: > >First two results in Google > >http://client338.lab.telin.nl:8080/wasp/jsp/CellStats.jsp >http://www.cellspotting.com/webpages/cellspotting.html > >Another selling-location-idea bites the dust :-) > Alexander Mayrhofer wrote: >Another option is "crowdsourcing" of WLAN SSIDs / MAC >addresses. For our office location in Vienna, Loki >(www.loki.com) returns a much more precise location than >Google's "My Location". Loki claims to use a >(proprietory) database of 23 millions access points (provided by >www.skyhookwireless.com) - i guess it's just a matter of time >until some open alternative database becomes available... I have no doubt that these kind of things together with GPS in the handsets will be the future of most if not all commercial location-based services. This is why I'm wondering if all this access-network based LCP stuff that we do in GEOPRIV/ECRIT will be quite irrelevant in the real world. Perhaps we should think how to develop open standards for accessing these type of global databases (at least reading info, but also writing/contributing)? Or perhaps it's enough if they just publich open web service APIs, in case they want to be open? It's interesting, however, how these would be related to emergency services. So, do we still need access-network provided location to address the liability issues? Is the only way to get something like HELD deployed that the regulator starts mandating it? I don't see any other incentive, at least. Markus _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 7 07:16:29 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8F73A6F59; Fri, 7 Mar 2008 07:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.572 X-Spam-Level: X-Spam-Status: No, score=-100.572 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuBqB1FuCHVu; Fri, 7 Mar 2008 07:16:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F245A3A6F54; Fri, 7 Mar 2008 07:16:22 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11453A6F52 for ; Fri, 7 Mar 2008 07:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe6Ww5liVdms for ; Fri, 7 Mar 2008 07:16:20 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 160293A6F35 for ; Fri, 7 Mar 2008 07:16:20 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JXeIm-00029p-8E; Fri, 07 Mar 2008 09:16:04 -0600 From: "Brian Rosen" To: , , , References: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com><00b401c87f02$89eafcc0$270d0d0a@cisco.com> <47D04A77.2020502@bbn.com><47D051AC.5080108@gmx.net><007c01c87fc9$55217830$640fa8c0@cis.neustar.com><47D05973.7040702@gmx.net> Date: Fri, 7 Mar 2008 10:16:05 -0500 Message-ID: <00cf01c88066$2b6fb5e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Ach/03o6r9jqESAwQTSX4sCufhuIHwAcWhWwAAgVs8A= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: Gabor.Bajko@nokia.com, ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think it's the case that most carriers will persist in believing that they can make money from location, and will not facilitate acquisition of high accuracy location information unless they are compensated. There is a regulatory imperative to provide location for emergency calls in most areas. Cell based routing of an emergency call where the device can measure location but the measuring mechanism is not turned on, and thus will take time, or for some reason, no measurement is available, perhaps due to low signal level, will persist. You are asking a reasonable question: will operators send cell id around, and expect some downstream device to have the cell id and need to turn it into location? Mobile IMS systems don't seem to need to do this: the E-CSCF can obtain location using identifiers it has available to it. Are there other mobile cellular networks which: 1) Won't provide good location to endpoints for free 2) Will make cell id information available in the signaling 3) Will need some downstream element to be able to translate Cell Id to location I don't know of any. Do you? Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Markus.Isomaki@nokia.com > Sent: Friday, March 07, 2008 6:34 AM > To: hgs@cs.columbia.edu; Hannes.Tschofenig@gmx.net; > alexander.mayrhofer@nic.at > Cc: Gabor.Bajko@nokia.com; ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > Henning, Alexander, > > Henning Schulzrinne wrote: > > > >First two results in Google > > > >http://client338.lab.telin.nl:8080/wasp/jsp/CellStats.jsp > >http://www.cellspotting.com/webpages/cellspotting.html > > > >Another selling-location-idea bites the dust :-) > > > > Alexander Mayrhofer wrote: > >Another option is "crowdsourcing" of WLAN SSIDs / MAC > >addresses. For our office location in Vienna, Loki > >(www.loki.com) returns a much more precise location than > >Google's "My Location". Loki claims to use a > >(proprietory) database of 23 millions access points (provided by > >www.skyhookwireless.com) - i guess it's just a matter of time > >until some open alternative database becomes available... > > I have no doubt that these kind of things together with GPS in the > handsets will be the future of most if not all commercial location-based > services. This is why I'm wondering if all this access-network based LCP > stuff that we do in GEOPRIV/ECRIT will be quite irrelevant in the real > world. Perhaps we should think how to develop open standards for > accessing these type of global databases (at least reading info, but > also writing/contributing)? Or perhaps it's enough if they just publich > open web service APIs, in case they want to be open? > > It's interesting, however, how these would be related to emergency > services. So, do we still need access-network provided location to > address the liability issues? Is the only way to get something like HELD > deployed that the regulator starts mandating it? I don't see any other > incentive, at least. > > Markus > > > > _______________________________________________ > 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 ecrit-bounces@ietf.org Sat Mar 8 12:46:19 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3CF43A6B9D; Sat, 8 Mar 2008 12:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBj1jAQe9UuJ; Sat, 8 Mar 2008 12:46:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE7843A6BA4; Sat, 8 Mar 2008 12:46:18 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A07203A6ADD for ; Sat, 8 Mar 2008 12:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FD9JIdlRr4V for ; Sat, 8 Mar 2008 12:46:18 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B87C63A6B61 for ; Sat, 8 Mar 2008 12:46:17 -0800 (PST) Received: (qmail invoked by alias); 08 Mar 2008 20:43:54 -0000 Received: from dhcp-3356.ietf71.ietf.org (EHLO [130.129.51.86]) [130.129.51.86] by mail.gmx.net (mp058) with SMTP; 08 Mar 2008 21:43:54 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+OvG1ecaOOtPWC0/6UEKmXV/9eVsMcZV5c2p394Y dU8lSH0uDp0eqg Message-ID: <47D2FA88.9040902@gmx.net> Date: Sat, 08 Mar 2008 22:43:52 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] Slides X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Please sent your slides to Roger so that he can upload them to the webpage. Thanks _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 9 15:12:41 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F155B3A6898; Sun, 9 Mar 2008 15:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.811 X-Spam-Level: X-Spam-Status: No, score=-100.811 tagged_above=-999 required=5 tests=[AWL=-0.374, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFZzv4JrcFXb; Sun, 9 Mar 2008 15:12:40 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE60F28C17A; Sun, 9 Mar 2008 15:12:40 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C56828C1B1 for ; Sun, 9 Mar 2008 15:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUZ+Ab6FSNvy for ; Sun, 9 Mar 2008 15:12:38 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 846703A67FA for ; Sun, 9 Mar 2008 15:12:38 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m29MB2Tr018311; Sun, 9 Mar 2008 17:11:54 -0500 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 00:10:02 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Mar 2008 17:10:00 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 9 Mar 2008 17:09:56 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) Thread-Index: Ach/wzBRtxbESMZqTD+ZYu8cdpsIsQAE5z0jAI2iEhA= References: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com><00b401c87f02$89eafcc0$270d0d0a@cisco.com> <47D04A77.2020502@bbn.com> From: To: , X-OriginalArrivalTime: 09 Mar 2008 22:10:00.0359 (UTC) FILETIME=[51463370:01C88232] X-Nokia-AV: Clean Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The cell-id to psap mapping database one operator has could become the LoST server of that operator. When an end device attaches to a cellular network, it learns its cell-id and then it could use LoST to translate its cell-id to the psap uri, as the operator can always translate its own cell-id to the correct psap uri. There is no need for a global database for this, the operator needs to keep its own database up to date anyways, regardless of the amount of cell-id movement. What is needed is that the operator's (currently existing) database supports LoST and LoST carries cell-id. An extension to the latter one could be done, but first lets fix the requirement. All the rest is just reuse of existing staff. - gabor -----Original Message----- From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Thursday, March 06, 2008 2:10 PM To: Richard Barnes; Bajko Gabor (Nokia-OCTO/MtView) Cc: ecrit@ietf.org Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) Hi Richard, The Cell-ID is made up of 4 parts: MCC = Mobile Country Code MNC = Mobile Network Code (the operator) LAC = Local Area Code Cell = The number of the cell So with this, it is actually possible to easily work out where the operator is at least to a national level, and who the operator is. The other components are assigned by the operator and and would need the operator to either provide this information to LoST directly, or provide an interface to a specific LoST server to query. Given the operator sensitivity to this information being generally public, and the amount of cell-id movement that goes on, this may actually become quite impractical quite quickly. Some operators I deal with for example have more than 400k cells in just one country. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Richard Barnes Sent: Thu 3/6/2008 1:48 PM To: Gabor.Bajko@nokia.com Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) Gabor, If I have a cell-id, how do I figure out where that cell is? Is there a well-defined mechanism for doing that over IP? (I'm not trying to be rhetorical here, I just don't know.) My concern with using cell-id as a "pointer" to location in the Internet context is that there may not be a way to dereference that pointer (i.e., obtain the location of the cell) without going outside the Internet, e.g., to a 3GPP non-IP interface or some other database. --Richard Gabor.Bajko@nokia.com wrote: > The cell-id (cgi) is a global, well defined and understood in the > cellular world. There are no interoperability issues with it. If you > think otherwise, please give examples. > > Pidf-lo is an object which encapsulates preexisting location > information but it does not define the format of it. > > - gabor > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of ext James M. Polk > Sent: Wednesday, March 05, 2008 2:43 PM > To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; > br@brianrosen.net; ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: >> Right. But that means relaxing the requirement "8. section 6.1 "Other >> forms of location representation must be mapped into either a geo or >> civic for use in emergency calls" in the draft and allow other type >> of location information, all those which make sense in their specific >> context. > > I don't understand why you want anything relaxed. The requirement > says PIDF-LO is the only location format to be used, and that the > is geo or civic. This is a MUST for interoperability > reasons. Cell-id doesn't accomplish this. > > >> Gabor >> >> -----Original Message----- >> From: ext Marc Linsner [mailto:mlinsner@cisco.com] >> Sent: Wednesday, March 05, 2008 12:50 PM >> To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); ecrit@ietf.org >> Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) >> >> Of course there is no reason the operator couldn't provide civic >> location >> (123 Main St.) in place of cell-id either (verses a geo location). >> The > >> main objective is to have location information in the device such >> that it makes sense to the consumer vs. every context having their >> own location descriptions (cell-id, water meter number, telephone >> pole id, property tax plat number, fire hydrant inventory id, msag >> address, etc.). >> >> -Marc- >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> Behalf Of Brian Rosen >>> Sent: Wednesday, March 05, 2008 2:53 PM >>> To: 'James M. Polk'; Gabor.Bajko@nokia.com; >>> Hannes.Tschofenig@gmx.net; ecrit@ietf.org >>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) >>> >>> The basic agreement we have made, in NENA, is that the operator will > >>> agree with the PSAP on a location for the cellid. This could be a >>> point or a polygon. That location will be reported, in PIDF-LO >>> form, from the LIS. >>> There was a discussion about actually allowing a cell-id as an >>> alternate form of location representation, but it was decided not to > >>> do that. A LIS could, of course, construct a location reference of >>> the form sip:@opco.net, and send that. When dereferenced, >>> it would return the agreed-upon location. >>> >>> Brian >>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org >>> [mailto:ecrit-bounces@ietf.org] On Behalf >>>> Of James M. Polk >>>> Sent: Wednesday, March 05, 2008 2:29 PM >>>> To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; >>>> ecrit@ietf.org >>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 >>>> (cell-id) >>>> >>>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: >>>>> Cell-id is an identifier of a geographical area which is mapped to >>>>> psap already in today's databases. If you'll make an IP based >>>>> emergency call on cellular, that will use now and for many >>> years to >>>>> come the cell-id to select the psap where to direct your >>> call. GAbor >>>> let's discuss this topic as its own thread. >>>> >>>> All (not just some or one) of the following questions need to be >>>> answered positively and definitively in order for your Cell-id >>>> scenario to work in IP. >>>> >>>> Where is the Cell-id to PSAP URI mapping done? >>>> >>>> What database has this information? >>>> >>>> What IP protocol is used to resolve this mapping of Cell-id to >>>> (appropriate) PSAP? >>>> >>>> Where is this IP-based server located? >>>> >>>> How can LoST be used to discover this? >>>> >>>> What LCP will give this Cell-id to a phone to include in a >>> SIP message? >>>> What SIP header is this information placed in? >>>> >>>> What form does this Cell-id have in the SIP header from the >>> previous >>>> question? >>>> >>>> What IETF document(s) specifies this header and Cell-id form? >>>> >>>> James >>>> >>>> >>>> _______________________________________________ >>>> 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 > _______________________________________________ > 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 ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 9 16:33:22 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08C9628C271; Sun, 9 Mar 2008 16:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.375 X-Spam-Level: X-Spam-Status: No, score=-100.375 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9q60q6kN+eL; Sun, 9 Mar 2008 16:33:20 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86C133A6C95; Sun, 9 Mar 2008 16:33:20 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EBC528C141 for ; Sun, 9 Mar 2008 16:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUj08GE4qJHK for ; Sun, 9 Mar 2008 16:33:16 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 9FFE63A68CA for ; Sun, 9 Mar 2008 16:33:16 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_03_09_18_43_39 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 09 Mar 2008 18:43:39 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 9 Mar 2008 18:30:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 9 Mar 2008 18:30:30 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Cell-id in HELD and other parts of the emergency servicesframework? (Was: WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)) Thread-Index: Ach/W2VcM7tMpBrRQh+bdZonicypuAAMFQNgABRrk1AAGFqMoAB+z+Pw References: <47CAE9CA.9010901@gmx.net><016f01c87efa$76eb3930$640fa8c0@cis.neustar.com><20080306072621.23460@gmx.net> From: "Thomson, Martin" To: , , , , , X-OriginalArrivalTime: 09 Mar 2008 23:30:54.0389 (UTC) FILETIME=[9E806650:01C8823D] Subject: Re: [Ecrit] Cell-id in HELD and other parts of the emergency servicesframework? (Was: WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The mobile host could use HELD to get location. If you consider the fact that the host may be unaware of the specifics of its connection to the Internet, it employs the usual methods for determining its location. As to determining location based on IP in a cellular network, this question has already been asked ;) The first step is to determine MSISDN/IMSI from the network infrastructure. Apparently this is expected of SUPL location platforms [1], but the method for solving the problem is unspecified. The options that we discovered included AAA servers (which at the time involved proprietary methods), the GGSN (another proprietary interface required), or the DHCP server (apparently there are "conventions" used for filling out certain DHCP headers, and you can use DHCP lease query now). I'm not aware of any standard methods, although I've not been following 3GPP that closely of late. Alternatively, a LIS could sweep the whole thing under the carpet and provide an IP address to a GMLC over MLP. Of course, the GMLC would have to use the same methods. If the host is aware of the nature of its network access, it could provide this information in a HELD request. I've written an extension to HELD that enables the use of device-provided information [2]. Cell identifiers would be a reasonable addition to that document (right now, I can't remember why I didn't add them in the first place), or a similar document. It would not be unreasonable for the LIS to have access to a cell location database. Cheers, Martin [1] http://www.openmobilealliance.org/Technical/release_program/supl_v1_0.as px [2] http://tools.ietf.org/html/draft-thomson-geopriv-held-measurements-01 > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Friday, 7 March 2008 9:48 PM > To: Thomson, Martin; Hannes.Tschofenig@gmx.net; br@brianrosen.net; > ecrit@ietf.org; Gabor.Bajko@nokia.com; jmpolk@cisco.com > Subject: RE: [Ecrit] Cell-id in HELD and other parts of the emergency > servicesframework? (Was: WGLC on draft-ietf-ecrit-phonebcp-04 (cell- > id)) > > Hi Martin, > > Martin Thomson wrote: > >One of the main reasons for having a LIS is to provide the > >translation from network-specific information (cell-ID) into > >something more global (lat/long, civic). This means that > >services can be implemented to use access-agnostic information. > > How do you think this should be done in practice? Would the mobile host > use HELD to get its location or reference to it, as usual? How does the > mapping from the host's current IP address to one of the location > formats happen in practice? I suppose the mobile operator would have > AAA > server of some sort which can keep track of which IP address is given > to > which user, but I don't know the rest of the backend infra well enough > to understand how the LIS obtains the information it needs to respond > to > a HELD query. > > The reason I'm asking is that I'm trying to understand where the Cell- > id > would fit wrt. HELD and LIS. In practice, would it be useful for the > HELD client to tell the LIS what it's Cell-id is directly, or do you > expect the backend infra to do all the necessary correlations starting > from the IP address? > > Markus > > > >-----Original Message----- > >From: ext Thomson, Martin [mailto:Martin.Thomson@andrew.com] > >Sent: 07 March, 2008 01:17 > >To: Isomaki Markus (Nokia-OCTO/Espoo); > >Hannes.Tschofenig@gmx.net; br@brianrosen.net; ecrit@ietf.org; > >Bajko Gabor (Nokia-OCTO/MtView); jmpolk@cisco.com > >Subject: RE: [Ecrit] Cell-id in HELD and other parts of the > >emergency servicesframework? (Was: WGLC on > >draft-ietf-ecrit-phonebcp-04 (cell-id)) > > > >Extend away, but try to understand where the information is > >going to be consumed. > > > >I am not comfortable with a cell identifier escaping the > >access network context. In fact, I'd argue that a cell > >identifier is not a form of location, but a parameter that can > >be used to derive location information when combined with > >contextual information. > > > >The carrier that puts the cell in place knows where the cell > >is, but it is unreasonable to expect others to know this. > >(3GPP & OMA evidently > >agree: see Lr interface and the concepts of V-GMLC and V-SLP) > > > >To extend the analogy, would you also mandate that LoST > >servers also have a database of WiFi access points, WiMAX base > >stations, cable network head-ends, and so forth? > > > >One of the main reasons for having a LIS is to provide the > >translation from network-specific information (cell-ID) into > >something more global (lat/long, civic). This means that > >services can be implemented to use access-agnostic information. > > > >I have no objection to someone describing its use, but to > >expect that a LoST server also have a database that maps > >cell-ID to location is unreasonable (such a database is > >necessary for dispatch, even if a routing database also > >exists). The two accepted forms for location are geodetic and > >civic and these should be the only mandatory forms. > > > >Cheers, > >Martin > > > > (A question from the side-lines: for UMTS would you use the > >UTRAN cell identifier, the SAI, or allow for both?) > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf > >> Of Markus.Isomaki@nokia.com > >> Sent: Friday, 7 March 2008 1:07 AM > >> To: Hannes.Tschofenig@gmx.net; br@brianrosen.net; ecrit@ietf.org; > >> Gabor.Bajko@nokia.com; jmpolk@cisco.com > >> Subject: [Ecrit] Cell-id in HELD and other parts of the emergency > >> servicesframework? (Was: WGLC on draft-ietf-ecrit-phonebcp-04 (cell- > >> id)) > >> > >> Hi, > >> > >> Talking about the different scenarios how Cell-id could be > >used in the > >> IP emergency service framework, we also still have the > "conventional" > >> way of first mapping it into geo or civic location. > >> > >> The phonebcp draft currently says: > >> > >> Other forms of > >> location representation must be mapped into either a geo or civic > >> for > >> use in emergency calls. > >> > >> So, how do we expect this to happen for Cell-id? One possibility I > >> would see is that we could extend HELD so that the HELD > >request could > >> carry Cell-id, and the HELD server could use the Cell-id in addition > >> to IP address to determine the location of the mobile host. (This is > >> what Google does already in their map application, so actually the > >> server doing the mapping does not even have to be associated > >with the > >> access network, although such association would probably make the > >> mapping > >more > >> reliable.) > >> > >> Would this seem like a sensible extension to HELD? > >> > >> Given how ubiquitous Cell-id already is in the cellular wireless > >> infrastructure, I think we should actually develop protocols that > >allow > >> it to be used in at least these ways: > >> > >> a) Use it as an input in LoST for mapping to PSAP URI. > >> b) Use it as an input in HELD for mapping to geo/civic location. > >> c) Carry it within the signaling protocol for various potential > >usages. > >> I think this is already taken care by what is defined in RFC 3455, > >> although I suppose it would be more inline with the rest of > >> ECRIT/GEOPRIV work if it was actually carried within PIDF-LO in > >> accordance to the SIP location conveyance. > >> > >> Markus > >> > >> > >> >-----Original Message----- > >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> >Behalf Of ext Hannes Tschofenig > >> >Sent: 06 March, 2008 09:26 > >> >To: Brian Rosen; ecrit@ietf.org; Bajko Gabor (Nokia-OCTO/MtView); > >> >jmpolk@cisco.com > >> >Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > >> > > >> >We also discussed this topic in a face-to-face meeting between the > >> >3GPP and the IETF in July 2006. I recall that we were not > >so negative > >> >about the idea of using Cell-IDs. > >> > > >> >Furthermore, there are two separate things to consider: > >> > > >> >* Cell-ID usage for LoST to obtain a PSAP URI > >> >* Cell-ID information as information for dispatch. > >> > > >> >Gabor is not proposing the second approach. > >> > > >> > > >> >> The basic agreement we have made, in NENA, is that the operator > >will > >> >> agree with the PSAP on a location for the cellid. This > >could be a > >> >> point or a polygon. That location will be reported, in > >> >PIDF-LO form, from the LIS. > >> >> There was a discussion about actually allowing a cell-id as an > >> >> alternate form of location representation, but it was decided not > >to > >> >> do that. A LIS could, of course, construct a location > >reference of > >> >> the form sip:@opco.net, and send that. When > >> >dereferenced, it > >> >> would return the agreed-upon location. > >> >> > >> >> Brian > >> >> > >> >> > -----Original Message----- > >> >> > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> >> > Behalf > >> >> Of > >> >> > James M. Polk > >> >> > Sent: Wednesday, March 05, 2008 2:29 PM > >> >> > To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > >> >ecrit@ietf.org > >> >> > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > (cell- > >> id) > >> >> > > >> >> > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > >> >> > >Cell-id is an identifier of a geographical area which is > >> >mapped to > >> >> > >psap already in today's databases. If you'll make an IP based > >> >> > >emergency call on cellular, that will use now and for > >> >many years to > >> >> > >come the cell-id > >> >> to > >> >> > >select the psap where to direct your call. GAbor > >> >> > > >> >> > let's discuss this topic as its own thread. > >> >> > > >> >> > All (not just some or one) of the following questions > >need to be > >> >> > answered positively and definitively in order for your Cell-id > >> >> > scenario to work in IP. > >> >> > > >> >> > Where is the Cell-id to PSAP URI mapping done? > >> >> > > >> >> > What database has this information? > >> >> > > >> >> > What IP protocol is used to resolve this mapping of Cell-id to > >> >> > (appropriate) PSAP? > >> >> > > >> >> > Where is this IP-based server located? > >> >> > > >> >> > How can LoST be used to discover this? > >> >> > > >> >> > What LCP will give this Cell-id to a phone to include in a > >> >SIP message? > >> >> > > >> >> > What SIP header is this information placed in? > >> >> > > >> >> > What form does this Cell-id have in the SIP header from > >> >the previous > >> >> > question? > >> >> > > >> >> > What IETF document(s) specifies this header and Cell-id form? > >> >> > > >> >> > James > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > 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 > > > >--------------------------------------------------------------- > >--------------------------------- > >This message is for the designated recipient only and may > >contain privileged, proprietary, or otherwise private information. > >If you have received it in error, please notify the sender > >immediately and delete the original. Any unauthorized use of > >this email is prohibited. > >--------------------------------------------------------------- > >--------------------------------- > >[mf2] > > > > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 9 20:13:42 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0377C3A6C66; Sun, 9 Mar 2008 20:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.678 X-Spam-Level: X-Spam-Status: No, score=-100.678 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AGYCD7wYBbe; Sun, 9 Mar 2008 20:13:41 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED1F23A6AC9; Sun, 9 Mar 2008 20:13:40 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4BD53A6AC9 for ; Sun, 9 Mar 2008 20:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIsBQhJ2xf34 for ; Sun, 9 Mar 2008 20:13:38 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id A85863A68B4 for ; Sun, 9 Mar 2008 20:13:38 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Sun, 9 Mar 2008 20:11:17 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 9 Mar 2008 20:11:11 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657509543153@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <47D2FA88.9040902@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Slides Thread-Index: AciBXSKoB9biovfvQDONorsd/t2hXwA/CIKA References: <47D2FA88.9040902@gmx.net> From: "Roger Marshall" To: , "Marc Linsner" , Subject: Re: [Ecrit] Slides X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I have not yet received slides for the ecrit meeting tomorrow afternoon. I need the slides ahead of time, so I can post them. Please send them. Thanks in advance. -roger marshall. rmarshall@telecomsys.com > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Hannes Tschofenig > Sent: Saturday, March 08, 2008 12:44 PM > To: ecrit@ietf.org > Subject: [Ecrit] Slides > > Please sent your slides to Roger so that he can upload them > to the webpage. > > Thanks > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > 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. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 9 21:04:05 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89CC028C2E9; Sun, 9 Mar 2008 21:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.638 X-Spam-Level: X-Spam-Status: No, score=-100.638 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwkQb3DWtsrG; Sun, 9 Mar 2008 21:04:05 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD20A28C320; Sun, 9 Mar 2008 21:03:15 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FB6D28C306 for ; Sun, 9 Mar 2008 21:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nVOkacbneKH for ; Sun, 9 Mar 2008 21:03:12 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 6C98428C327 for ; Sun, 9 Mar 2008 21:01:18 -0700 (PDT) Received: from [128.89.253.196] (helo=localhost.localdomain) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JYZA6-00020Q-5x; Sun, 09 Mar 2008 23:58:55 -0400 Message-ID: <47D4B1FD.2080309@bbn.com> Date: Sun, 09 Mar 2008 23:58:53 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Gabor.Bajko@nokia.com References: <016f01c87efa$76eb3930$640fa8c0@cis.neustar.com><00b401c87f02$89eafcc0$270d0d0a@cisco.com> <47D04A77.2020502@bbn.com> In-Reply-To: Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Gabor, I still don't understand how all these entities find each other. If I've got a cell-id, how do I figure out which LoST server to send it to? Notionally, I suppose the MNC identifies the operator, which could lead me to it, but you would need some mechanism for this. My point is that the cell-id is neither a location datum (by value) nor a location reference in the sense in which these terms have been previously used. It is not a location value because it does not directly represent a physical position (via public information such as a Coordinate Reference System). It is not a location reference because there is no single protocol that can be used to obtain the location to which it refers (just a set of proprietary database queries). So before cell-ids can be used to represent location, they need to be tied to some uniform protocol mechanism that authorized parties can use to obtain the associated location information. --RB Gabor.Bajko@nokia.com wrote: > The cell-id to psap mapping database one operator has could become the > LoST server of that operator. When an end device attaches to a cellular > network, it learns its cell-id and then it could use LoST to translate > its cell-id to the psap uri, as the operator can always translate its > own cell-id to the correct psap uri. There is no need for a global > database for this, the operator needs to keep its own database up to > date anyways, regardless of the amount of cell-id movement. > What is needed is that the operator's (currently existing) database > supports LoST and LoST carries cell-id. An extension to the latter one > could be done, but first lets fix the requirement. All the rest is just > reuse of existing staff. > > - gabor > > > -----Original Message----- > From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Thursday, March 06, 2008 2:10 PM > To: Richard Barnes; Bajko Gabor (Nokia-OCTO/MtView) > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > Hi Richard, > > The Cell-ID is made up of 4 parts: > > MCC = Mobile Country Code > MNC = Mobile Network Code (the operator) > LAC = Local Area Code > Cell = The number of the cell > > So with this, it is actually possible to easily work out where the > operator is at least to a national level, and who the operator is. The > other components are assigned by the operator and and would need the > operator to either provide this information to LoST directly, or provide > an interface to a specific LoST server to query. > > Given the operator sensitivity to this information being generally > public, and the amount of cell-id movement that goes on, this may > actually become quite impractical quite quickly. Some operators I deal > with for example have more than 400k cells in just one country. > > Cheers > James > > > > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of Richard Barnes > Sent: Thu 3/6/2008 1:48 PM > To: Gabor.Bajko@nokia.com > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > Gabor, > > If I have a cell-id, how do I figure out where that cell is? Is there a > well-defined mechanism for doing that over IP? (I'm not trying to be > rhetorical here, I just don't know.) > > My concern with using cell-id as a "pointer" to location in the Internet > context is that there may not be a way to dereference that pointer > (i.e., obtain the location of the cell) without going outside the > Internet, e.g., to a 3GPP non-IP interface or some other database. > > --Richard > > > > > > Gabor.Bajko@nokia.com wrote: >> The cell-id (cgi) is a global, well defined and understood in the >> cellular world. There are no interoperability issues with it. If you >> think otherwise, please give examples. >> >> Pidf-lo is an object which encapsulates preexisting location >> information but it does not define the format of it. >> >> - gabor >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >> Of ext James M. Polk >> Sent: Wednesday, March 05, 2008 2:43 PM >> To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; >> br@brianrosen.net; ecrit@ietf.org >> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) >> >> At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: >>> Right. But that means relaxing the requirement "8. section 6.1 "Other > >>> forms of location representation must be mapped into either a geo or >>> civic for use in emergency calls" in the draft and allow other type >>> of location information, all those which make sense in their specific > >>> context. >> I don't understand why you want anything relaxed. The requirement >> says PIDF-LO is the only location format to be used, and that the >> is geo or civic. This is a MUST for interoperability >> reasons. Cell-id doesn't accomplish this. >> >> >>> Gabor >>> >>> -----Original Message----- >>> From: ext Marc Linsner [mailto:mlinsner@cisco.com] >>> Sent: Wednesday, March 05, 2008 12:50 PM >>> To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); ecrit@ietf.org >>> Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) >>> >>> Of course there is no reason the operator couldn't provide civic >>> location >>> (123 Main St.) in place of cell-id either (verses a geo location). >>> The >>> main objective is to have location information in the device such >>> that it makes sense to the consumer vs. every context having their >>> own location descriptions (cell-id, water meter number, telephone >>> pole id, property tax plat number, fire hydrant inventory id, msag >>> address, etc.). >>> >>> -Marc- >>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>> Behalf Of Brian Rosen >>>> Sent: Wednesday, March 05, 2008 2:53 PM >>>> To: 'James M. Polk'; Gabor.Bajko@nokia.com; >>>> Hannes.Tschofenig@gmx.net; ecrit@ietf.org >>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) >>>> >>>> The basic agreement we have made, in NENA, is that the operator will >>>> agree with the PSAP on a location for the cellid. This could be a >>>> point or a polygon. That location will be reported, in PIDF-LO >>>> form, from the LIS. >>>> There was a discussion about actually allowing a cell-id as an >>>> alternate form of location representation, but it was decided not to >>>> do that. A LIS could, of course, construct a location reference of >>>> the form sip:@opco.net, and send that. When dereferenced, >>>> it would return the agreed-upon location. >>>> >>>> Brian >>>> >>>>> -----Original Message----- >>>>> From: ecrit-bounces@ietf.org >>>> [mailto:ecrit-bounces@ietf.org] On Behalf >>>>> Of James M. Polk >>>>> Sent: Wednesday, March 05, 2008 2:29 PM >>>>> To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; >>>>> ecrit@ietf.org >>>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 >>>>> (cell-id) >>>>> >>>>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: >>>>>> Cell-id is an identifier of a geographical area which is mapped to > >>>>>> psap already in today's databases. If you'll make an IP based >>>>>> emergency call on cellular, that will use now and for many >>>> years to >>>>>> come the cell-id to select the psap where to direct your >>>> call. GAbor >>>>> let's discuss this topic as its own thread. >>>>> >>>>> All (not just some or one) of the following questions need to be >>>>> answered positively and definitively in order for your Cell-id >>>>> scenario to work in IP. >>>>> >>>>> Where is the Cell-id to PSAP URI mapping done? >>>>> >>>>> What database has this information? >>>>> >>>>> What IP protocol is used to resolve this mapping of Cell-id to >>>>> (appropriate) PSAP? >>>>> >>>>> Where is this IP-based server located? >>>>> >>>>> How can LoST be used to discover this? >>>>> >>>>> What LCP will give this Cell-id to a phone to include in a >>>> SIP message? >>>>> What SIP header is this information placed in? >>>>> >>>>> What form does this Cell-id have in the SIP header from the >>>> previous >>>>> question? >>>>> >>>>> What IETF document(s) specifies this header and Cell-id form? >>>>> >>>>> James >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> _______________________________________________ >> 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 > > > ------------------------------------------------------------------------ > ------------------------ > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender immediately > and delete the original. Any unauthorized use of this email is > prohibited. > ------------------------------------------------------------------------ > ------------------------ > [mf2] > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 10 07:15:26 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B752293E2E; Mon, 10 Mar 2008 07:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.379 X-Spam-Level: X-Spam-Status: No, score=-99.379 tagged_above=-999 required=5 tests=[AWL=-1.540, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nv-MK38qGYFL; Mon, 10 Mar 2008 07:15:25 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780F8293BD5; Mon, 10 Mar 2008 07:11:27 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFC5B28E0A6 for ; Mon, 10 Mar 2008 07:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytLXiN7hfO3F for ; Mon, 10 Mar 2008 07:11:13 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 85F82293E3E for ; Mon, 10 Mar 2008 06:53:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,474,1199682000"; d="scan'208";a="1157858" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Mar 2008 09:50:57 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m2ADovm1017868; Mon, 10 Mar 2008 09:50:57 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m2ADonaV007932; Mon, 10 Mar 2008 13:50:57 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 09:50:46 -0400 Received: from mlinsnerwxp02 ([10.82.232.210]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 09:50:45 -0400 From: "Marc Linsner" To: Date: Mon, 10 Mar 2008 09:50:45 -0400 Message-ID: <000a01c882b5$bd39c370$d2e8520a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Ach/wzBRtxbESMZqTD+ZYu8cdpsIsQAE5z0jAI2iEhAAKbgrkA== X-OriginalArrivalTime: 10 Mar 2008 13:50:45.0749 (UTC) FILETIME=[BD593250:01C882B5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9772; t=1205157057; x=1206021057; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20WGLC=20on=20draft-ietf-ecrit- phonebcp-04=20(cell-id) |Sender:=20 |To:=20; bh=O9Nse7eFPN3WaQXnYBr6+MwmWGty2MPoAg5tqxPZqas=; b=JGz4+xfAz2diO4CxGCFrVM90PuFiPnXbysTiGk2HgWsOgz+m6WVGS+pdNR NxT67AITbbTfB4nCMr8SPYfII6w96/v+Q7WUATJMS6TDHNiPCpVqiq7ekr1j 7eOVJygsrU; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Gabor, 1) There is no guarantee the end host will use the cell operator's LoST service (even if known). The end host may use a LoST service associated with it's VoIP provider or Aor domain provider. 2) If in fact the operator maintains a db of cell-id to psap uri, would it not be easier to maintain a db of cell-id to common-use location then simply advise the end host of the common-use location? (cell-id 123 = 0000 N. Main St.) -Marc- > > The cell-id to psap mapping database one operator has could > become the LoST server of that operator. When an end device > attaches to a cellular network, it learns its cell-id and > then it could use LoST to translate its cell-id to the psap > uri, as the operator can always translate its own cell-id to > the correct psap uri. There is no need for a global database > for this, the operator needs to keep its own database up to > date anyways, regardless of the amount of cell-id movement. > What is needed is that the operator's (currently existing) > database supports LoST and LoST carries cell-id. An extension > to the latter one could be done, but first lets fix the > requirement. All the rest is just reuse of existing staff. > > - gabor > > > -----Original Message----- > From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Thursday, March 06, 2008 2:10 PM > To: Richard Barnes; Bajko Gabor (Nokia-OCTO/MtView) > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > Hi Richard, > > The Cell-ID is made up of 4 parts: > > MCC = Mobile Country Code > MNC = Mobile Network Code (the operator) LAC = Local Area > Code Cell = The number of the cell > > So with this, it is actually possible to easily work out > where the operator is at least to a national level, and who > the operator is. The other components are assigned by the > operator and and would need the operator to either provide > this information to LoST directly, or provide an interface to > a specific LoST server to query. > > Given the operator sensitivity to this information being > generally public, and the amount of cell-id movement that > goes on, this may actually become quite impractical quite > quickly. Some operators I deal with for example have more > than 400k cells in just one country. > > Cheers > James > > > > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of Richard Barnes > Sent: Thu 3/6/2008 1:48 PM > To: Gabor.Bajko@nokia.com > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > Gabor, > > If I have a cell-id, how do I figure out where that cell is? > Is there a well-defined mechanism for doing that over IP? > (I'm not trying to be rhetorical here, I just don't know.) > > My concern with using cell-id as a "pointer" to location in > the Internet context is that there may not be a way to > dereference that pointer (i.e., obtain the location of the > cell) without going outside the Internet, e.g., to a 3GPP > non-IP interface or some other database. > > --Richard > > > > > > Gabor.Bajko@nokia.com wrote: > > The cell-id (cgi) is a global, well defined and understood in the > > cellular world. There are no interoperability issues with > it. If you > > think otherwise, please give examples. > > > > Pidf-lo is an object which encapsulates preexisting location > > information but it does not define the format of it. > > > > - gabor > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of ext James M. Polk > > Sent: Wednesday, March 05, 2008 2:43 PM > > To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; > > br@brianrosen.net; ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > >> Right. But that means relaxing the requirement "8. section > 6.1 "Other > > >> forms of location representation must be mapped into > either a geo or > >> civic for use in emergency calls" in the draft and allow > other type > >> of location information, all those which make sense in > their specific > > >> context. > > > > I don't understand why you want anything relaxed. The requirement > > says PIDF-LO is the only location format to be used, and that the > > is geo or civic. This is a MUST for > interoperability > > reasons. Cell-id doesn't accomplish this. > > > > > >> Gabor > >> > >> -----Original Message----- > >> From: ext Marc Linsner [mailto:mlinsner@cisco.com] > >> Sent: Wednesday, March 05, 2008 12:50 PM > >> To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); ecrit@ietf.org > >> Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > >> > >> Of course there is no reason the operator couldn't provide civic > >> location > >> (123 Main St.) in place of cell-id either (verses a geo > location). > >> The > > > >> main objective is to have location information in the device such > >> that it makes sense to the consumer vs. every context having their > >> own location descriptions (cell-id, water meter number, telephone > >> pole id, property tax plat number, fire hydrant inventory id, msag > >> address, etc.). > >> > >> -Marc- > >> > >>> -----Original Message----- > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>> Behalf Of Brian Rosen > >>> Sent: Wednesday, March 05, 2008 2:53 PM > >>> To: 'James M. Polk'; Gabor.Bajko@nokia.com; > >>> Hannes.Tschofenig@gmx.net; ecrit@ietf.org > >>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > (cell-id) > >>> > >>> The basic agreement we have made, in NENA, is that the > operator will > > > >>> agree with the PSAP on a location for the cellid. This > could be a > >>> point or a polygon. That location will be reported, in PIDF-LO > >>> form, from the LIS. > >>> There was a discussion about actually allowing a cell-id as an > >>> alternate form of location representation, but it was > decided not to > > > >>> do that. A LIS could, of course, construct a location > reference of > >>> the form sip:@opco.net, and send that. When > dereferenced, > >>> it would return the agreed-upon location. > >>> > >>> Brian > >>> > >>>> -----Original Message----- > >>>> From: ecrit-bounces@ietf.org > >>> [mailto:ecrit-bounces@ietf.org] On Behalf > >>>> Of James M. Polk > >>>> Sent: Wednesday, March 05, 2008 2:29 PM > >>>> To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > >>>> ecrit@ietf.org > >>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > >>>> (cell-id) > >>>> > >>>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > >>>>> Cell-id is an identifier of a geographical area which > is mapped to > > >>>>> psap already in today's databases. If you'll make an IP based > >>>>> emergency call on cellular, that will use now and for many > >>> years to > >>>>> come the cell-id to select the psap where to direct your > >>> call. GAbor > >>>> let's discuss this topic as its own thread. > >>>> > >>>> All (not just some or one) of the following questions need to be > >>>> answered positively and definitively in order for your Cell-id > >>>> scenario to work in IP. > >>>> > >>>> Where is the Cell-id to PSAP URI mapping done? > >>>> > >>>> What database has this information? > >>>> > >>>> What IP protocol is used to resolve this mapping of Cell-id to > >>>> (appropriate) PSAP? > >>>> > >>>> Where is this IP-based server located? > >>>> > >>>> How can LoST be used to discover this? > >>>> > >>>> What LCP will give this Cell-id to a phone to include in a > >>> SIP message? > >>>> What SIP header is this information placed in? > >>>> > >>>> What form does this Cell-id have in the SIP header from the > >>> previous > >>>> question? > >>>> > >>>> What IETF document(s) specifies this header and Cell-id form? > >>>> > >>>> James > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > > _______________________________________________ > > 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 > > > -------------------------------------------------------------- > ---------- > ------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------- > ------------------------ > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 10 08:22:48 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFE0B28C32A; Mon, 10 Mar 2008 08:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.565 X-Spam-Level: X-Spam-Status: No, score=-100.565 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXiYXWQ78zYy; Mon, 10 Mar 2008 08:22:44 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E3D728D171; Mon, 10 Mar 2008 08:02:08 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF6628D657 for ; Mon, 10 Mar 2008 08:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzWw-OQtoudM for ; Mon, 10 Mar 2008 08:02:05 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id B94E028CD73 for ; Mon, 10 Mar 2008 07:31:20 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_03_10_09_41_45 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 10 Mar 2008 09:41:44 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Mar 2008 09:28:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 10 Mar 2008 09:28:57 -0500 Message-ID: In-Reply-To: <000a01c882b5$bd39c370$d2e8520a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) Thread-Index: Ach/wzBRtxbESMZqTD+ZYu8cdpsIsQAE5z0jAI2iEhAAKbgrkAABkW8w References: <000a01c882b5$bd39c370$d2e8520a@cisco.com> From: "Winterbottom, James" To: "Marc Linsner" , X-OriginalArrivalTime: 10 Mar 2008 14:28:58.0808 (UTC) FILETIME=[141E3B80:01C882BB] Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I know for a fact that quite a number of operators (not in the US) will not provide a public cell-id to location DB or make that data generally available. They view providing it, rightly or wrongly, as a security risk, so a solution that was dependent on this method would certainly not be universally deployable. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Marc Linsner > Sent: Tuesday, 11 March 2008 12:51 AM > To: Gabor.Bajko@nokia.com > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > Gabor, > > 1) There is no guarantee the end host will use the cell operator's LoST > service (even if known). The end host may use a LoST service associated > with it's VoIP provider or Aor domain provider. > > 2) If in fact the operator maintains a db of cell-id to psap uri, would it > not be easier to maintain a db of cell-id to common-use location then > simply > advise the end host of the common-use location? (cell-id 123 = 0000 N. > Main > St.) > > -Marc- > > > > > > > > The cell-id to psap mapping database one operator has could > > become the LoST server of that operator. When an end device > > attaches to a cellular network, it learns its cell-id and > > then it could use LoST to translate its cell-id to the psap > > uri, as the operator can always translate its own cell-id to > > the correct psap uri. There is no need for a global database > > for this, the operator needs to keep its own database up to > > date anyways, regardless of the amount of cell-id movement. > > What is needed is that the operator's (currently existing) > > database supports LoST and LoST carries cell-id. An extension > > to the latter one could be done, but first lets fix the > > requirement. All the rest is just reuse of existing staff. > > > > - gabor > > > > > > -----Original Message----- > > From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Thursday, March 06, 2008 2:10 PM > > To: Richard Barnes; Bajko Gabor (Nokia-OCTO/MtView) > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > Hi Richard, > > > > The Cell-ID is made up of 4 parts: > > > > MCC = Mobile Country Code > > MNC = Mobile Network Code (the operator) LAC = Local Area > > Code Cell = The number of the cell > > > > So with this, it is actually possible to easily work out > > where the operator is at least to a national level, and who > > the operator is. The other components are assigned by the > > operator and and would need the operator to either provide > > this information to LoST directly, or provide an interface to > > a specific LoST server to query. > > > > Given the operator sensitivity to this information being > > generally public, and the amount of cell-id movement that > > goes on, this may actually become quite impractical quite > > quickly. Some operators I deal with for example have more > > than 400k cells in just one country. > > > > Cheers > > James > > > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org on behalf of Richard Barnes > > Sent: Thu 3/6/2008 1:48 PM > > To: Gabor.Bajko@nokia.com > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > Gabor, > > > > If I have a cell-id, how do I figure out where that cell is? > > Is there a well-defined mechanism for doing that over IP? > > (I'm not trying to be rhetorical here, I just don't know.) > > > > My concern with using cell-id as a "pointer" to location in > > the Internet context is that there may not be a way to > > dereference that pointer (i.e., obtain the location of the > > cell) without going outside the Internet, e.g., to a 3GPP > > non-IP interface or some other database. > > > > --Richard > > > > > > > > > > > > Gabor.Bajko@nokia.com wrote: > > > The cell-id (cgi) is a global, well defined and understood in the > > > cellular world. There are no interoperability issues with > > it. If you > > > think otherwise, please give examples. > > > > > > Pidf-lo is an object which encapsulates preexisting location > > > information but it does not define the format of it. > > > > > > - gabor > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of ext James M. Polk > > > Sent: Wednesday, March 05, 2008 2:43 PM > > > To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; > > > br@brianrosen.net; ecrit@ietf.org > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > >> Right. But that means relaxing the requirement "8. section > > 6.1 "Other > > > > >> forms of location representation must be mapped into > > either a geo or > > >> civic for use in emergency calls" in the draft and allow > > other type > > >> of location information, all those which make sense in > > their specific > > > > >> context. > > > > > > I don't understand why you want anything relaxed. The requirement > > > says PIDF-LO is the only location format to be used, and that the > > > is geo or civic. This is a MUST for > > interoperability > > > reasons. Cell-id doesn't accomplish this. > > > > > > > > >> Gabor > > >> > > >> -----Original Message----- > > >> From: ext Marc Linsner [mailto:mlinsner@cisco.com] > > >> Sent: Wednesday, March 05, 2008 12:50 PM > > >> To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); ecrit@ietf.org > > >> Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > >> > > >> Of course there is no reason the operator couldn't provide civic > > >> location > > >> (123 Main St.) in place of cell-id either (verses a geo > > location). > > >> The > > > > > >> main objective is to have location information in the device such > > >> that it makes sense to the consumer vs. every context having their > > >> own location descriptions (cell-id, water meter number, telephone > > >> pole id, property tax plat number, fire hydrant inventory id, msag > > >> address, etc.). > > >> > > >> -Marc- > > >> > > >>> -----Original Message----- > > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > >>> Behalf Of Brian Rosen > > >>> Sent: Wednesday, March 05, 2008 2:53 PM > > >>> To: 'James M. Polk'; Gabor.Bajko@nokia.com; > > >>> Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > >>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > (cell-id) > > >>> > > >>> The basic agreement we have made, in NENA, is that the > > operator will > > > > > >>> agree with the PSAP on a location for the cellid. This > > could be a > > >>> point or a polygon. That location will be reported, in PIDF-LO > > >>> form, from the LIS. > > >>> There was a discussion about actually allowing a cell-id as an > > >>> alternate form of location representation, but it was > > decided not to > > > > > >>> do that. A LIS could, of course, construct a location > > reference of > > >>> the form sip:@opco.net, and send that. When > > dereferenced, > > >>> it would return the agreed-upon location. > > >>> > > >>> Brian > > >>> > > >>>> -----Original Message----- > > >>>> From: ecrit-bounces@ietf.org > > >>> [mailto:ecrit-bounces@ietf.org] On Behalf > > >>>> Of James M. Polk > > >>>> Sent: Wednesday, March 05, 2008 2:29 PM > > >>>> To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > > >>>> ecrit@ietf.org > > >>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > >>>> (cell-id) > > >>>> > > >>>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > >>>>> Cell-id is an identifier of a geographical area which > > is mapped to > > > > >>>>> psap already in today's databases. If you'll make an IP based > > >>>>> emergency call on cellular, that will use now and for many > > >>> years to > > >>>>> come the cell-id to select the psap where to direct your > > >>> call. GAbor > > >>>> let's discuss this topic as its own thread. > > >>>> > > >>>> All (not just some or one) of the following questions need to be > > >>>> answered positively and definitively in order for your Cell-id > > >>>> scenario to work in IP. > > >>>> > > >>>> Where is the Cell-id to PSAP URI mapping done? > > >>>> > > >>>> What database has this information? > > >>>> > > >>>> What IP protocol is used to resolve this mapping of Cell-id to > > >>>> (appropriate) PSAP? > > >>>> > > >>>> Where is this IP-based server located? > > >>>> > > >>>> How can LoST be used to discover this? > > >>>> > > >>>> What LCP will give this Cell-id to a phone to include in a > > >>> SIP message? > > >>>> What SIP header is this information placed in? > > >>>> > > >>>> What form does this Cell-id have in the SIP header from the > > >>> previous > > >>>> question? > > >>>> > > >>>> What IETF document(s) specifies this header and Cell-id form? > > >>>> > > >>>> James > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> 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 > > > _______________________________________________ > > > 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 > > > > > > -------------------------------------------------------------- > > ---------- > > ------------------------ > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > ---------- > > ------------------------ > > [mf2] > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 10 08:33:52 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75F5828CCEE; Mon, 10 Mar 2008 08:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.018 X-Spam-Level: X-Spam-Status: No, score=-102.018 tagged_above=-999 required=5 tests=[AWL=-1.581, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7XhF24GAK4i; Mon, 10 Mar 2008 08:33:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FBBF28D92A; Mon, 10 Mar 2008 08:07:50 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B5963A71AC for ; Mon, 10 Mar 2008 08:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwrPRaMfUoNc for ; Mon, 10 Mar 2008 08:07:47 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 3049128D964 for ; Mon, 10 Mar 2008 07:40:27 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m2AEdFjY019335; Mon, 10 Mar 2008 09:39:52 -0500 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 16:37:22 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 09:37:07 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 10 Mar 2008 09:37:06 -0500 Message-ID: In-Reply-To: <000a01c882b5$bd39c370$d2e8520a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) Thread-Index: Ach/wzBRtxbESMZqTD+ZYu8cdpsIsQAE5z0jAI2iEhAAKbgrkAAByrsw References: <000a01c882b5$bd39c370$d2e8520a@cisco.com> From: To: X-OriginalArrivalTime: 10 Mar 2008 14:37:07.0766 (UTC) FILETIME=[378F4D60:01C882BC] X-Nokia-AV: Clean Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Marc, > 1) There is no guarantee the end host will use the cell operator's LoST service (even if known) It will, if the LoST server discovery mechanism will provision the device with the operator's LoST server. > 2) If in fact the operator maintains a db of cell-id to psap uri, would it not be easier to maintain a db of cell-id to common-use location See James W. answer. We are currently talking about cell-id usage only for emergency services. There is no reason to use the VoIP provider's LoST server, when you can get the required information (ie psap uri) locally from the access provider. - gabor -----Original Message----- From: ext Marc Linsner [mailto:mlinsner@cisco.com] Sent: Monday, March 10, 2008 6:51 AM To: Bajko Gabor (Nokia-OCTO/MtView) Cc: ecrit@ietf.org Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) Gabor, 1) There is no guarantee the end host will use the cell operator's LoST service (even if known). The end host may use a LoST service associated with it's VoIP provider or Aor domain provider. 2) If in fact the operator maintains a db of cell-id to psap uri, would it not be easier to maintain a db of cell-id to common-use location then simply advise the end host of the common-use location? (cell-id 123 = 0000 N. Main St.) -Marc- > > The cell-id to psap mapping database one operator has could become the > LoST server of that operator. When an end device attaches to a > cellular network, it learns its cell-id and then it could use LoST to > translate its cell-id to the psap uri, as the operator can always > translate its own cell-id to the correct psap uri. There is no need > for a global database for this, the operator needs to keep its own > database up to date anyways, regardless of the amount of cell-id > movement. > What is needed is that the operator's (currently existing) database > supports LoST and LoST carries cell-id. An extension to the latter one > could be done, but first lets fix the requirement. All the rest is > just reuse of existing staff. > > - gabor > > > -----Original Message----- > From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Thursday, March 06, 2008 2:10 PM > To: Richard Barnes; Bajko Gabor (Nokia-OCTO/MtView) > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > Hi Richard, > > The Cell-ID is made up of 4 parts: > > MCC = Mobile Country Code > MNC = Mobile Network Code (the operator) LAC = Local Area Code Cell = > The number of the cell > > So with this, it is actually possible to easily work out where the > operator is at least to a national level, and who the operator is. The > other components are assigned by the operator and and would need the > operator to either provide this information to LoST directly, or > provide an interface to a specific LoST server to query. > > Given the operator sensitivity to this information being generally > public, and the amount of cell-id movement that goes on, this may > actually become quite impractical quite quickly. Some operators I > deal with for example have more than 400k cells in just one country. > > Cheers > James > > > > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of Richard Barnes > Sent: Thu 3/6/2008 1:48 PM > To: Gabor.Bajko@nokia.com > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > Gabor, > > If I have a cell-id, how do I figure out where that cell is? > Is there a well-defined mechanism for doing that over IP? > (I'm not trying to be rhetorical here, I just don't know.) > > My concern with using cell-id as a "pointer" to location in the > Internet context is that there may not be a way to dereference that > pointer (i.e., obtain the location of the > cell) without going outside the Internet, e.g., to a 3GPP non-IP > interface or some other database. > > --Richard > > > > > > Gabor.Bajko@nokia.com wrote: > > The cell-id (cgi) is a global, well defined and understood in the > > cellular world. There are no interoperability issues with > it. If you > > think otherwise, please give examples. > > > > Pidf-lo is an object which encapsulates preexisting location > > information but it does not define the format of it. > > > > - gabor > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of ext James M. Polk > > Sent: Wednesday, March 05, 2008 2:43 PM > > To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; > > br@brianrosen.net; ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > >> Right. But that means relaxing the requirement "8. section > 6.1 "Other > > >> forms of location representation must be mapped into > either a geo or > >> civic for use in emergency calls" in the draft and allow > other type > >> of location information, all those which make sense in > their specific > > >> context. > > > > I don't understand why you want anything relaxed. The requirement > > says PIDF-LO is the only location format to be used, and that the > > is geo or civic. This is a MUST for > interoperability > > reasons. Cell-id doesn't accomplish this. > > > > > >> Gabor > >> > >> -----Original Message----- > >> From: ext Marc Linsner [mailto:mlinsner@cisco.com] > >> Sent: Wednesday, March 05, 2008 12:50 PM > >> To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); ecrit@ietf.org > >> Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > >> > >> Of course there is no reason the operator couldn't provide civic > >> location > >> (123 Main St.) in place of cell-id either (verses a geo > location). > >> The > > > >> main objective is to have location information in the device such > >> that it makes sense to the consumer vs. every context having their > >> own location descriptions (cell-id, water meter number, telephone > >> pole id, property tax plat number, fire hydrant inventory id, msag > >> address, etc.). > >> > >> -Marc- > >> > >>> -----Original Message----- > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>> Behalf Of Brian Rosen > >>> Sent: Wednesday, March 05, 2008 2:53 PM > >>> To: 'James M. Polk'; Gabor.Bajko@nokia.com; > >>> Hannes.Tschofenig@gmx.net; ecrit@ietf.org > >>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > (cell-id) > >>> > >>> The basic agreement we have made, in NENA, is that the > operator will > > > >>> agree with the PSAP on a location for the cellid. This > could be a > >>> point or a polygon. That location will be reported, in PIDF-LO > >>> form, from the LIS. > >>> There was a discussion about actually allowing a cell-id as an > >>> alternate form of location representation, but it was > decided not to > > > >>> do that. A LIS could, of course, construct a location > reference of > >>> the form sip:@opco.net, and send that. When > dereferenced, > >>> it would return the agreed-upon location. > >>> > >>> Brian > >>> > >>>> -----Original Message----- > >>>> From: ecrit-bounces@ietf.org > >>> [mailto:ecrit-bounces@ietf.org] On Behalf > >>>> Of James M. Polk > >>>> Sent: Wednesday, March 05, 2008 2:29 PM > >>>> To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > >>>> ecrit@ietf.org > >>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > >>>> (cell-id) > >>>> > >>>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > >>>>> Cell-id is an identifier of a geographical area which > is mapped to > > >>>>> psap already in today's databases. If you'll make an IP based > >>>>> emergency call on cellular, that will use now and for many > >>> years to > >>>>> come the cell-id to select the psap where to direct your > >>> call. GAbor > >>>> let's discuss this topic as its own thread. > >>>> > >>>> All (not just some or one) of the following questions need to be > >>>> answered positively and definitively in order for your Cell-id > >>>> scenario to work in IP. > >>>> > >>>> Where is the Cell-id to PSAP URI mapping done? > >>>> > >>>> What database has this information? > >>>> > >>>> What IP protocol is used to resolve this mapping of Cell-id to > >>>> (appropriate) PSAP? > >>>> > >>>> Where is this IP-based server located? > >>>> > >>>> How can LoST be used to discover this? > >>>> > >>>> What LCP will give this Cell-id to a phone to include in a > >>> SIP message? > >>>> What SIP header is this information placed in? > >>>> > >>>> What form does this Cell-id have in the SIP header from the > >>> previous > >>>> question? > >>>> > >>>> What IETF document(s) specifies this header and Cell-id form? > >>>> > >>>> James > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > > _______________________________________________ > > 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 > > > -------------------------------------------------------------- > ---------- > ------------------------ > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender immediately > and delete the original. Any unauthorized use of this email is > prohibited. > -------------------------------------------------------------- > ---------- > ------------------------ > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 10 08:35:23 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FB8028CD50; Mon, 10 Mar 2008 08:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.328 X-Spam-Level: X-Spam-Status: No, score=-101.328 tagged_above=-999 required=5 tests=[AWL=-0.891, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgjkLvqINfYl; Mon, 10 Mar 2008 08:35:21 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A495228CA89; Mon, 10 Mar 2008 08:09:12 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A91928CF94 for ; Mon, 10 Mar 2008 08:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QU9REW2pbqLC for ; Mon, 10 Mar 2008 08:09:04 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D0E9128CB26 for ; Mon, 10 Mar 2008 07:43:26 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 10 Mar 2008 07:41:06 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2AEf6Ii008904; Mon, 10 Mar 2008 07:41:06 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m2AEeonR006880; Mon, 10 Mar 2008 14:41:06 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 10:40:26 -0400 Received: from mlinsnerwxp02 ([10.82.232.210]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 10:40:25 -0400 From: "Marc Linsner" To: "'Winterbottom, James'" Date: Mon, 10 Mar 2008 10:40:25 -0400 Message-ID: <001401c882bc$ad87f490$d2e8520a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Ach/wzBRtxbESMZqTD+ZYu8cdpsIsQAE5z0jAI2iEhAAKbgrkAABkW8wAABL+BA= X-OriginalArrivalTime: 10 Mar 2008 14:40:25.0755 (UTC) FILETIME=[AD9206B0:01C882BC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12626; t=1205160066; x=1206024066; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20WGLC=20on=20draft-ietf-ecrit- phonebcp-04=20(cell-id) |Sender:=20; bh=dTFoGB6zlQTo+mEld2jX5gkF06eB7Q+aok1jr2CyVoE=; b=F7Ml3NcTVBKbwT9QKRDpKopB4fYSftK/NEw+1J3O4XJwxL/lVY6tbXWM09 /mMExrZqmj9ejGpBpryaEmLfhUc7kGigse8hKAMPwhBJNz4nGZgkncAWPvkY vevQL/Ypre; Authentication-Results: sj-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James, The cell-id to common-use location doesn't need to identify the location of the cell tower, it only needs to provide a common-use location that lies within the jurisdiction of the PSAP that emergency calls need to be routed to. The actual tower location *could* be miles away. -Marc- > > I know for a fact that quite a number of operators (not in > the US) will not provide a public cell-id to location DB or > make that data generally available. They view providing it, > rightly or wrongly, as a security risk, so a solution that > was dependent on this method would certainly not be > universally deployable. > > Cheers > James > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Marc Linsner > > Sent: Tuesday, 11 March 2008 12:51 AM > > To: Gabor.Bajko@nokia.com > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > Gabor, > > > > 1) There is no guarantee the end host will use the cell operator's > LoST > > service (even if known). The end host may use a LoST service > associated > > with it's VoIP provider or Aor domain provider. > > > > 2) If in fact the operator maintains a db of cell-id to psap uri, > would it > > not be easier to maintain a db of cell-id to common-use > location then > > simply advise the end host of the common-use location? > (cell-id 123 = > > 0000 > N. > > Main > > St.) > > > > -Marc- > > > > > > > > > > > > > > The cell-id to psap mapping database one operator has > could become > > > the LoST server of that operator. When an end device > attaches to a > > > cellular network, it learns its cell-id and then it could > use LoST > > > to translate its cell-id to the psap uri, as the operator > can always > > > translate its own cell-id to the correct psap uri. There > is no need > > > for a global database for this, the operator needs to > keep its own > > > database up to date anyways, regardless of the amount of cell-id > > > movement. > > > What is needed is that the operator's (currently > existing) database > > > supports LoST and LoST carries cell-id. An extension to > the latter > > > one could be done, but first lets fix the requirement. > All the rest > > > is just reuse of existing staff. > > > > > > - gabor > > > > > > > > > -----Original Message----- > > > From: ext Winterbottom, James > [mailto:James.Winterbottom@andrew.com] > > > Sent: Thursday, March 06, 2008 2:10 PM > > > To: Richard Barnes; Bajko Gabor (Nokia-OCTO/MtView) > > > Cc: ecrit@ietf.org > > > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > (cell-id) > > > > > > Hi Richard, > > > > > > The Cell-ID is made up of 4 parts: > > > > > > MCC = Mobile Country Code > > > MNC = Mobile Network Code (the operator) LAC = Local Area > Code Cell > > > = The number of the cell > > > > > > So with this, it is actually possible to easily work out > where the > > > operator is at least to a national level, and who the > operator is. > > > The other components are assigned by the operator and and > would need > > > the operator to either provide this information to LoST > directly, or > > > provide an interface to a specific LoST server to query. > > > > > > Given the operator sensitivity to this information being > generally > > > public, and the amount of cell-id movement that goes on, this may > > > actually become quite impractical quite quickly. Some > operators I > > > deal with for example have more than 400k cells in just > one country. > > > > > > Cheers > > > James > > > > > > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org on behalf of Richard Barnes > > > Sent: Thu 3/6/2008 1:48 PM > > > To: Gabor.Bajko@nokia.com > > > Cc: ecrit@ietf.org > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > (cell-id) > > > > > > Gabor, > > > > > > If I have a cell-id, how do I figure out where that cell is? > > > Is there a well-defined mechanism for doing that over IP? > > > (I'm not trying to be rhetorical here, I just don't know.) > > > > > > My concern with using cell-id as a "pointer" to location in the > > > Internet context is that there may not be a way to > dereference that > > > pointer (i.e., obtain the location of the > > > cell) without going outside the Internet, e.g., to a 3GPP non-IP > > > interface or some other database. > > > > > > --Richard > > > > > > > > > > > > > > > > > > Gabor.Bajko@nokia.com wrote: > > > > The cell-id (cgi) is a global, well defined and > understood in the > > > > cellular world. There are no interoperability issues with > > > it. If you > > > > think otherwise, please give examples. > > > > > > > > Pidf-lo is an object which encapsulates preexisting location > > > > information but it does not define the format of it. > > > > > > > > - gabor > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > Of ext James M. Polk > > > > Sent: Wednesday, March 05, 2008 2:43 PM > > > > To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; > > > > br@brianrosen.net; ecrit@ietf.org > > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > (cell-id) > > > > > > > > At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > >> Right. But that means relaxing the requirement "8. section > > > 6.1 "Other > > > > > > >> forms of location representation must be mapped into > > > either a geo or > > > >> civic for use in emergency calls" in the draft and allow > > > other type > > > >> of location information, all those which make sense in > > > their specific > > > > > > >> context. > > > > > > > > I don't understand why you want anything relaxed. The > requirement > > > > says PIDF-LO is the only location format to be used, > and that the > > > > is geo or civic. This is a MUST for > > > interoperability > > > > reasons. Cell-id doesn't accomplish this. > > > > > > > > > > > >> Gabor > > > >> > > > >> -----Original Message----- > > > >> From: ext Marc Linsner [mailto:mlinsner@cisco.com] > > > >> Sent: Wednesday, March 05, 2008 12:50 PM > > > >> To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); > ecrit@ietf.org > > > >> Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > (cell-id) > > > >> > > > >> Of course there is no reason the operator couldn't > provide civic > > > >> location > > > >> (123 Main St.) in place of cell-id either (verses a geo > > > location). > > > >> The > > > > > > > >> main objective is to have location information in the > device such > > > >> that it makes sense to the consumer vs. every context having > their > > > >> own location descriptions (cell-id, water meter > number, telephone > > > >> pole id, property tax plat number, fire hydrant inventory id, > msag > > > >> address, etc.). > > > >> > > > >> -Marc- > > > >> > > > >>> -----Original Message----- > > > >>> From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On > > > >>> Behalf Of Brian Rosen > > > >>> Sent: Wednesday, March 05, 2008 2:53 PM > > > >>> To: 'James M. Polk'; Gabor.Bajko@nokia.com; > > > >>> Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > > >>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > (cell-id) > > > >>> > > > >>> The basic agreement we have made, in NENA, is that the > > > operator will > > > > > > > >>> agree with the PSAP on a location for the cellid. This > > > could be a > > > >>> point or a polygon. That location will be reported, > in PIDF-LO > > > >>> form, from the LIS. > > > >>> There was a discussion about actually allowing a > cell-id as an > > > >>> alternate form of location representation, but it was > > > decided not to > > > > > > > >>> do that. A LIS could, of course, construct a location > > > reference of > > > >>> the form sip:@opco.net, and send that. When > > > dereferenced, > > > >>> it would return the agreed-upon location. > > > >>> > > > >>> Brian > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: ecrit-bounces@ietf.org > > > >>> [mailto:ecrit-bounces@ietf.org] On Behalf > > > >>>> Of James M. Polk > > > >>>> Sent: Wednesday, March 05, 2008 2:29 PM > > > >>>> To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > > > >>>> ecrit@ietf.org > > > >>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > >>>> (cell-id) > > > >>>> > > > >>>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > >>>>> Cell-id is an identifier of a geographical area which > > > is mapped to > > > > > > >>>>> psap already in today's databases. If you'll make > an IP based > > > >>>>> emergency call on cellular, that will use now and for many > > > >>> years to > > > >>>>> come the cell-id to select the psap where to direct your > > > >>> call. GAbor > > > >>>> let's discuss this topic as its own thread. > > > >>>> > > > >>>> All (not just some or one) of the following questions need to > be > > > >>>> answered positively and definitively in order for > your Cell-id > > > >>>> scenario to work in IP. > > > >>>> > > > >>>> Where is the Cell-id to PSAP URI mapping done? > > > >>>> > > > >>>> What database has this information? > > > >>>> > > > >>>> What IP protocol is used to resolve this mapping of > Cell-id to > > > >>>> (appropriate) PSAP? > > > >>>> > > > >>>> Where is this IP-based server located? > > > >>>> > > > >>>> How can LoST be used to discover this? > > > >>>> > > > >>>> What LCP will give this Cell-id to a phone to include in a > > > >>> SIP message? > > > >>>> What SIP header is this information placed in? > > > >>>> > > > >>>> What form does this Cell-id have in the SIP header from the > > > >>> previous > > > >>>> question? > > > >>>> > > > >>>> What IETF document(s) specifies this header and Cell-id form? > > > >>>> > > > >>>> James > > > >>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> 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 > > > > _______________________________________________ > > > > 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 > > > > > > > > > -------------------------------------------------------------- > > > ---------- > > > ------------------------ > > > This message is for the designated recipient only and may contain > > > privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized > use of this > > > email is prohibited. > > > -------------------------------------------------------------- > > > ---------- > > > ------------------------ > > > [mf2] > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 10 08:41:38 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6EA328CAF0; Mon, 10 Mar 2008 08:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.522 X-Spam-Level: X-Spam-Status: No, score=-100.522 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RgxSbiUWpwM; Mon, 10 Mar 2008 08:41:38 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4FF628D47B; Mon, 10 Mar 2008 08:17:19 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C716C28D400 for ; Mon, 10 Mar 2008 08:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3OEDz5p4Naw for ; Mon, 10 Mar 2008 08:17:13 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 13D6E28CD0C for ; Mon, 10 Mar 2008 07:56:43 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_03_10_10_07_07 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 10 Mar 2008 10:07:07 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Mar 2008 09:54:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 10 Mar 2008 09:54:21 -0500 Message-ID: In-Reply-To: <001401c882bc$ad87f490$d2e8520a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) Thread-Index: Ach/wzBRtxbESMZqTD+ZYu8cdpsIsQAE5z0jAI2iEhAAKbgrkAABkW8wAABL+BAAAHD04A== References: <001401c882bc$ad87f490$d2e8520a@cisco.com> From: "Winterbottom, James" To: "Marc Linsner" X-OriginalArrivalTime: 10 Mar 2008 14:54:22.0368 (UTC) FILETIME=[A03B0A00:01C882BE] Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yeah I guess that is true. In many cases though the LAC-Cell-id component will be moot since the MCC (country code) is good enough to identify the PSAP, and the MNC (Network code) is good enough to identify the access provider. So if the proposition now something like: 1) Fred enters network run by dodgey-cells inc (DCI). 2) Fred discovers LIS in DCI's network 3) Fred uses HELD (or whatever) + Cell-id + emergencyRouting to LIS 4) LIS sends back location able to provide emergencyRouting 5) Fred does LoST lookup using location, gets PSAP URI 6) Fred can make emergency calls if need be Or are you proposing that something new needs to be done to find a local Cell-id to PSAP location DB, and a new protocol to query the PSAP location DC. I guess I could see the former as Geopriv/ecrit problem. The latter doesn't seem to make much sense to do in the IETF to me. Cheers James > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Tuesday, 11 March 2008 1:40 AM > To: Winterbottom, James > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > James, > > The cell-id to common-use location doesn't need to identify the location > of > the cell tower, it only needs to provide a common-use location that lies > within the jurisdiction of the PSAP that emergency calls need to be routed > to. The actual tower location *could* be miles away. > > -Marc- > > > > > I know for a fact that quite a number of operators (not in > > the US) will not provide a public cell-id to location DB or > > make that data generally available. They view providing it, > > rightly or wrongly, as a security risk, so a solution that > > was dependent on this method would certainly not be > > universally deployable. > > > > Cheers > > James > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of > > > Marc Linsner > > > Sent: Tuesday, 11 March 2008 12:51 AM > > > To: Gabor.Bajko@nokia.com > > > Cc: ecrit@ietf.org > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > Gabor, > > > > > > 1) There is no guarantee the end host will use the cell operator's > > LoST > > > service (even if known). The end host may use a LoST service > > associated > > > with it's VoIP provider or Aor domain provider. > > > > > > 2) If in fact the operator maintains a db of cell-id to psap uri, > > would it > > > not be easier to maintain a db of cell-id to common-use > > location then > > > simply advise the end host of the common-use location? > > (cell-id 123 = > > > 0000 > > N. > > > Main > > > St.) > > > > > > -Marc- > > > > > > > > > > > > > > > > > > > > The cell-id to psap mapping database one operator has > > could become > > > > the LoST server of that operator. When an end device > > attaches to a > > > > cellular network, it learns its cell-id and then it could > > use LoST > > > > to translate its cell-id to the psap uri, as the operator > > can always > > > > translate its own cell-id to the correct psap uri. There > > is no need > > > > for a global database for this, the operator needs to > > keep its own > > > > database up to date anyways, regardless of the amount of cell-id > > > > movement. > > > > What is needed is that the operator's (currently > > existing) database > > > > supports LoST and LoST carries cell-id. An extension to > > the latter > > > > one could be done, but first lets fix the requirement. > > All the rest > > > > is just reuse of existing staff. > > > > > > > > - gabor > > > > > > > > > > > > -----Original Message----- > > > > From: ext Winterbottom, James > > [mailto:James.Winterbottom@andrew.com] > > > > Sent: Thursday, March 06, 2008 2:10 PM > > > > To: Richard Barnes; Bajko Gabor (Nokia-OCTO/MtView) > > > > Cc: ecrit@ietf.org > > > > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > (cell-id) > > > > > > > > Hi Richard, > > > > > > > > The Cell-ID is made up of 4 parts: > > > > > > > > MCC = Mobile Country Code > > > > MNC = Mobile Network Code (the operator) LAC = Local Area > > Code Cell > > > > = The number of the cell > > > > > > > > So with this, it is actually possible to easily work out > > where the > > > > operator is at least to a national level, and who the > > operator is. > > > > The other components are assigned by the operator and and > > would need > > > > the operator to either provide this information to LoST > > directly, or > > > > provide an interface to a specific LoST server to query. > > > > > > > > Given the operator sensitivity to this information being > > generally > > > > public, and the amount of cell-id movement that goes on, this may > > > > actually become quite impractical quite quickly. Some > > operators I > > > > deal with for example have more than 400k cells in just > > one country. > > > > > > > > Cheers > > > > James > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org on behalf of Richard Barnes > > > > Sent: Thu 3/6/2008 1:48 PM > > > > To: Gabor.Bajko@nokia.com > > > > Cc: ecrit@ietf.org > > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > (cell-id) > > > > > > > > Gabor, > > > > > > > > If I have a cell-id, how do I figure out where that cell is? > > > > Is there a well-defined mechanism for doing that over IP? > > > > (I'm not trying to be rhetorical here, I just don't know.) > > > > > > > > My concern with using cell-id as a "pointer" to location in the > > > > Internet context is that there may not be a way to > > dereference that > > > > pointer (i.e., obtain the location of the > > > > cell) without going outside the Internet, e.g., to a 3GPP non-IP > > > > interface or some other database. > > > > > > > > --Richard > > > > > > > > > > > > > > > > > > > > > > > > Gabor.Bajko@nokia.com wrote: > > > > > The cell-id (cgi) is a global, well defined and > > understood in the > > > > > cellular world. There are no interoperability issues with > > > > it. If you > > > > > think otherwise, please give examples. > > > > > > > > > > Pidf-lo is an object which encapsulates preexisting location > > > > > information but it does not define the format of it. > > > > > > > > > > - gabor > > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > > > Of ext James M. Polk > > > > > Sent: Wednesday, March 05, 2008 2:43 PM > > > > > To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; > > > > > br@brianrosen.net; ecrit@ietf.org > > > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > (cell-id) > > > > > > > > > > At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > > >> Right. But that means relaxing the requirement "8. section > > > > 6.1 "Other > > > > > > > > >> forms of location representation must be mapped into > > > > either a geo or > > > > >> civic for use in emergency calls" in the draft and allow > > > > other type > > > > >> of location information, all those which make sense in > > > > their specific > > > > > > > > >> context. > > > > > > > > > > I don't understand why you want anything relaxed. The > > requirement > > > > > says PIDF-LO is the only location format to be used, > > and that the > > > > > is geo or civic. This is a MUST for > > > > interoperability > > > > > reasons. Cell-id doesn't accomplish this. > > > > > > > > > > > > > > >> Gabor > > > > >> > > > > >> -----Original Message----- > > > > >> From: ext Marc Linsner [mailto:mlinsner@cisco.com] > > > > >> Sent: Wednesday, March 05, 2008 12:50 PM > > > > >> To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); > > ecrit@ietf.org > > > > >> Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > (cell-id) > > > > >> > > > > >> Of course there is no reason the operator couldn't > > provide civic > > > > >> location > > > > >> (123 Main St.) in place of cell-id either (verses a geo > > > > location). > > > > >> The > > > > > > > > > >> main objective is to have location information in the > > device such > > > > >> that it makes sense to the consumer vs. every context having > > their > > > > >> own location descriptions (cell-id, water meter > > number, telephone > > > > >> pole id, property tax plat number, fire hydrant inventory id, > > msag > > > > >> address, etc.). > > > > >> > > > > >> -Marc- > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On > > > > >>> Behalf Of Brian Rosen > > > > >>> Sent: Wednesday, March 05, 2008 2:53 PM > > > > >>> To: 'James M. Polk'; Gabor.Bajko@nokia.com; > > > > >>> Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > > > >>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > > (cell-id) > > > > >>> > > > > >>> The basic agreement we have made, in NENA, is that the > > > > operator will > > > > > > > > > >>> agree with the PSAP on a location for the cellid. This > > > > could be a > > > > >>> point or a polygon. That location will be reported, > > in PIDF-LO > > > > >>> form, from the LIS. > > > > >>> There was a discussion about actually allowing a > > cell-id as an > > > > >>> alternate form of location representation, but it was > > > > decided not to > > > > > > > > > >>> do that. A LIS could, of course, construct a location > > > > reference of > > > > >>> the form sip:@opco.net, and send that. When > > > > dereferenced, > > > > >>> it would return the agreed-upon location. > > > > >>> > > > > >>> Brian > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: ecrit-bounces@ietf.org > > > > >>> [mailto:ecrit-bounces@ietf.org] On Behalf > > > > >>>> Of James M. Polk > > > > >>>> Sent: Wednesday, March 05, 2008 2:29 PM > > > > >>>> To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > > > > >>>> ecrit@ietf.org > > > > >>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > > >>>> (cell-id) > > > > >>>> > > > > >>>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > > >>>>> Cell-id is an identifier of a geographical area which > > > > is mapped to > > > > > > > > >>>>> psap already in today's databases. If you'll make > > an IP based > > > > >>>>> emergency call on cellular, that will use now and for many > > > > >>> years to > > > > >>>>> come the cell-id to select the psap where to direct your > > > > >>> call. GAbor > > > > >>>> let's discuss this topic as its own thread. > > > > >>>> > > > > >>>> All (not just some or one) of the following questions need to > > be > > > > >>>> answered positively and definitively in order for > > your Cell-id > > > > >>>> scenario to work in IP. > > > > >>>> > > > > >>>> Where is the Cell-id to PSAP URI mapping done? > > > > >>>> > > > > >>>> What database has this information? > > > > >>>> > > > > >>>> What IP protocol is used to resolve this mapping of > > Cell-id to > > > > >>>> (appropriate) PSAP? > > > > >>>> > > > > >>>> Where is this IP-based server located? > > > > >>>> > > > > >>>> How can LoST be used to discover this? > > > > >>>> > > > > >>>> What LCP will give this Cell-id to a phone to include in a > > > > >>> SIP message? > > > > >>>> What SIP header is this information placed in? > > > > >>>> > > > > >>>> What form does this Cell-id have in the SIP header from the > > > > >>> previous > > > > >>>> question? > > > > >>>> > > > > >>>> What IETF document(s) specifies this header and Cell-id form? > > > > >>>> > > > > >>>> James > > > > >>>> > > > > >>>> > > > > >>>> _______________________________________________ > > > > >>>> 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 > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > > > -------------------------------------------------------------- > > > > ---------- > > > > ------------------------ > > > > This message is for the designated recipient only and may contain > > > > privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized > > use of this > > > > email is prohibited. > > > > -------------------------------------------------------------- > > > > ---------- > > > > ------------------------ > > > > [mf2] > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] > > > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 10 08:51:08 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DA813A7045; Mon, 10 Mar 2008 08:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.971 X-Spam-Level: X-Spam-Status: No, score=-100.971 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUwvSf1M1b0M; Mon, 10 Mar 2008 08:51:06 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA6728CABC; Mon, 10 Mar 2008 08:30:21 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BE1328C7D6 for ; Mon, 10 Mar 2008 08:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33JmD7aB3f5l for ; Mon, 10 Mar 2008 08:30:16 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 280D528D1C3 for ; Mon, 10 Mar 2008 08:05:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,474,1199682000"; d="scan'208";a="1172277" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Mar 2008 11:03:33 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m2AF3WQT005177; Mon, 10 Mar 2008 11:03:32 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m2AF3TaX013901; Mon, 10 Mar 2008 15:03:30 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 11:03:28 -0400 Received: from mlinsnerwxp02 ([10.82.232.210]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 11:03:27 -0400 From: "Marc Linsner" To: Date: Mon, 10 Mar 2008 11:03:27 -0400 Message-ID: <001601c882bf$e5350240$d2e8520a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Ach/wzBRtxbESMZqTD+ZYu8cdpsIsQAE5z0jAI2iEhAAKbgrkAAByrswAACAswA= X-OriginalArrivalTime: 10 Mar 2008 15:03:27.0679 (UTC) FILETIME=[E542E4F0:01C882BF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11948; t=1205161412; x=1206025412; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20WGLC=20on=20draft-ietf-ecrit- phonebcp-04=20(cell-id) |Sender:=20 |To:=20; bh=UwXArs0ELKg2W8sxuLyEFxXdv/kCg3adtdtVxmy/9E0=; b=bbVGRukYJQHyakJPfhR/8cUtQBbt8g0wuOvf6llhdZ/ujUW3gQH5yN4AV2 R3YVuwrTGhctNAhylfNfsgb5Cy6w/hL0QdezoffJnAwZxrbVvV/TMseValX9 BiaFGS61Bm; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Gabor, > > > 1) There is no guarantee the end host will use the cell operator's > LoST service (even if known) > It will, if the LoST server discovery mechanism will > provision the device with the operator's LoST server. I believe that's my point, just as with any configuration data that DHCP delivers, the host has the choice whether to use it or discard it (I don't have to use the DNS servers that DHCP recommends). Since the VoIP provider is ultimately responsible for routing an emergency call, they may very well want their clients to utilize their LoST service and configure their clients accordingly which in turn will disregard the access provider information and/or never run a LoST server discovery function. Common-use location crosses provider boundaries, proprietary location information doesn't have the same benefit. -Marc- > > > 2) If in fact the operator maintains a db of cell-id to psap uri, > would it not be easier to maintain a db of cell-id to > common-use location See James W. answer. > > We are currently talking about cell-id usage only for > emergency services. There is no reason to use the VoIP > provider's LoST server, when you can get the required > information (ie psap uri) locally from the access provider. > > - gabor > > -----Original Message----- > From: ext Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Monday, March 10, 2008 6:51 AM > To: Bajko Gabor (Nokia-OCTO/MtView) > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > Gabor, > > 1) There is no guarantee the end host will use the cell > operator's LoST service (even if known). The end host may > use a LoST service associated with it's VoIP provider or Aor > domain provider. > > 2) If in fact the operator maintains a db of cell-id to psap > uri, would it not be easier to maintain a db of cell-id to > common-use location then simply advise the end host of the > common-use location? (cell-id 123 = 0000 N. Main > St.) > > -Marc- > > > > > > > > The cell-id to psap mapping database one operator has could > become the > > > LoST server of that operator. When an end device attaches to a > > cellular network, it learns its cell-id and then it could > use LoST to > > translate its cell-id to the psap uri, as the operator can always > > translate its own cell-id to the correct psap uri. There is no need > > for a global database for this, the operator needs to keep its own > > database up to date anyways, regardless of the amount of cell-id > > movement. > > What is needed is that the operator's (currently existing) database > > supports LoST and LoST carries cell-id. An extension to the > latter one > > > could be done, but first lets fix the requirement. All the rest is > > just reuse of existing staff. > > > > - gabor > > > > > > -----Original Message----- > > From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Thursday, March 06, 2008 2:10 PM > > To: Richard Barnes; Bajko Gabor (Nokia-OCTO/MtView) > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > Hi Richard, > > > > The Cell-ID is made up of 4 parts: > > > > MCC = Mobile Country Code > > MNC = Mobile Network Code (the operator) LAC = Local Area > Code Cell = > > The number of the cell > > > > So with this, it is actually possible to easily work out where the > > operator is at least to a national level, and who the > operator is. The > > > other components are assigned by the operator and and would > need the > > operator to either provide this information to LoST directly, or > > provide an interface to a specific LoST server to query. > > > > Given the operator sensitivity to this information being generally > > public, and the amount of cell-id movement that goes on, this may > > actually become quite impractical quite quickly. Some operators I > > deal with for example have more than 400k cells in just one country. > > > > Cheers > > James > > > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org on behalf of Richard Barnes > > Sent: Thu 3/6/2008 1:48 PM > > To: Gabor.Bajko@nokia.com > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > Gabor, > > > > If I have a cell-id, how do I figure out where that cell is? > > Is there a well-defined mechanism for doing that over IP? > > (I'm not trying to be rhetorical here, I just don't know.) > > > > My concern with using cell-id as a "pointer" to location in the > > Internet context is that there may not be a way to dereference that > > pointer (i.e., obtain the location of the > > cell) without going outside the Internet, e.g., to a 3GPP non-IP > > interface or some other database. > > > > --Richard > > > > > > > > > > > > Gabor.Bajko@nokia.com wrote: > > > The cell-id (cgi) is a global, well defined and understood in the > > > cellular world. There are no interoperability issues with > > it. If you > > > think otherwise, please give examples. > > > > > > Pidf-lo is an object which encapsulates preexisting location > > > information but it does not define the format of it. > > > > > > - gabor > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of ext James M. Polk > > > Sent: Wednesday, March 05, 2008 2:43 PM > > > To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; > > > br@brianrosen.net; ecrit@ietf.org > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > (cell-id) > > > > > > At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > >> Right. But that means relaxing the requirement "8. section > > 6.1 "Other > > > > >> forms of location representation must be mapped into > > either a geo or > > >> civic for use in emergency calls" in the draft and allow > > other type > > >> of location information, all those which make sense in > > their specific > > > > >> context. > > > > > > I don't understand why you want anything relaxed. The > requirement > > > says PIDF-LO is the only location format to be used, and that the > > > is geo or civic. This is a MUST for > > interoperability > > > reasons. Cell-id doesn't accomplish this. > > > > > > > > >> Gabor > > >> > > >> -----Original Message----- > > >> From: ext Marc Linsner [mailto:mlinsner@cisco.com] > > >> Sent: Wednesday, March 05, 2008 12:50 PM > > >> To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); > ecrit@ietf.org > > >> Subject: RE: [Ecrit] WGLC on > draft-ietf-ecrit-phonebcp-04 (cell-id) > > >> > > >> Of course there is no reason the operator couldn't provide civic > > >> location > > >> (123 Main St.) in place of cell-id either (verses a geo > > location). > > >> The > > > > > >> main objective is to have location information in the > device such > > >> that it makes sense to the consumer vs. every context > having their > > >> own location descriptions (cell-id, water meter number, > telephone > > >> pole id, property tax plat number, fire hydrant > inventory id, msag > > >> address, etc.). > > >> > > >> -Marc- > > >> > > >>> -----Original Message----- > > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > >>> Behalf Of Brian Rosen > > >>> Sent: Wednesday, March 05, 2008 2:53 PM > > >>> To: 'James M. Polk'; Gabor.Bajko@nokia.com; > > >>> Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > >>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > (cell-id) > > >>> > > >>> The basic agreement we have made, in NENA, is that the > > operator will > > > > > >>> agree with the PSAP on a location for the cellid. This > > could be a > > >>> point or a polygon. That location will be reported, in PIDF-LO > > >>> form, from the LIS. > > >>> There was a discussion about actually allowing a cell-id as an > > >>> alternate form of location representation, but it was > > decided not to > > > > > >>> do that. A LIS could, of course, construct a location > > reference of > > >>> the form sip:@opco.net, and send that. When > > dereferenced, > > >>> it would return the agreed-upon location. > > >>> > > >>> Brian > > >>> > > >>>> -----Original Message----- > > >>>> From: ecrit-bounces@ietf.org > > >>> [mailto:ecrit-bounces@ietf.org] On Behalf > > >>>> Of James M. Polk > > >>>> Sent: Wednesday, March 05, 2008 2:29 PM > > >>>> To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > > >>>> ecrit@ietf.org > > >>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > >>>> (cell-id) > > >>>> > > >>>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > >>>>> Cell-id is an identifier of a geographical area which > > is mapped to > > > > >>>>> psap already in today's databases. If you'll make an IP based > > >>>>> emergency call on cellular, that will use now and for many > > >>> years to > > >>>>> come the cell-id to select the psap where to direct your > > >>> call. GAbor > > >>>> let's discuss this topic as its own thread. > > >>>> > > >>>> All (not just some or one) of the following questions > need to be > > >>>> answered positively and definitively in order for your Cell-id > > >>>> scenario to work in IP. > > >>>> > > >>>> Where is the Cell-id to PSAP URI mapping done? > > >>>> > > >>>> What database has this information? > > >>>> > > >>>> What IP protocol is used to resolve this mapping of Cell-id to > > >>>> (appropriate) PSAP? > > >>>> > > >>>> Where is this IP-based server located? > > >>>> > > >>>> How can LoST be used to discover this? > > >>>> > > >>>> What LCP will give this Cell-id to a phone to include in a > > >>> SIP message? > > >>>> What SIP header is this information placed in? > > >>>> > > >>>> What form does this Cell-id have in the SIP header from the > > >>> previous > > >>>> question? > > >>>> > > >>>> What IETF document(s) specifies this header and Cell-id form? > > >>>> > > >>>> James > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> 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 > > > _______________________________________________ > > > 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 > > > > > > -------------------------------------------------------------- > > ---------- > > ------------------------ > > This message is for the designated recipient only and may contain > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > immediately > > > and delete the original. Any unauthorized use of this email is > > prohibited. > > -------------------------------------------------------------- > > ---------- > > ------------------------ > > [mf2] > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 10 10:33:10 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ECEA3A6A0C; Mon, 10 Mar 2008 10:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.617 X-Spam-Level: X-Spam-Status: No, score=-100.617 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHI2GGtfA+pt; Mon, 10 Mar 2008 10:33:05 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A665F3A6885; Mon, 10 Mar 2008 10:33:04 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A0063A67F8 for ; Mon, 10 Mar 2008 10:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIq-OmXqIoPA for ; Mon, 10 Mar 2008 10:33:01 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 2CB873A6976 for ; Mon, 10 Mar 2008 10:32:15 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JYlon-0006ef-OF; Mon, 10 Mar 2008 12:29:49 -0500 From: "Brian Rosen" To: , References: <000a01c882b5$bd39c370$d2e8520a@cisco.com> Date: Mon, 10 Mar 2008 13:29:47 -0400 Message-ID: <021201c882d4$58d71f30$6168f444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: Ach/wzBRtxbESMZqTD+ZYu8cdpsIsQAE5z0jAI2iEhAAKbgrkAAByrswAAYpzyA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This still seems to me to be a solution in search of a problem. IMS networks have mechanisms that don't need IETF work to allow a cell id as a location representation. I don't know of any networks that have this problem. If there are, please cite them. If there aren't, we don't need to keep talking about the solution. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Gabor.Bajko@nokia.com > Sent: Monday, March 10, 2008 10:37 AM > To: mlinsner@cisco.com > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > Hi Marc, > > > 1) There is no guarantee the end host will use the cell operator's > LoST service (even if known) > It will, if the LoST server discovery mechanism will provision the > device with the operator's LoST server. > > > 2) If in fact the operator maintains a db of cell-id to psap uri, > would it not be easier to maintain a db of cell-id to common-use > location > See James W. answer. > > We are currently talking about cell-id usage only for emergency > services. There is no reason to use the VoIP provider's LoST server, > when you can get the required information (ie psap uri) locally from the > access provider. > > - gabor > > -----Original Message----- > From: ext Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Monday, March 10, 2008 6:51 AM > To: Bajko Gabor (Nokia-OCTO/MtView) > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > Gabor, > > 1) There is no guarantee the end host will use the cell operator's LoST > service (even if known). The end host may use a LoST service associated > with it's VoIP provider or Aor domain provider. > > 2) If in fact the operator maintains a db of cell-id to psap uri, would > it not be easier to maintain a db of cell-id to common-use location then > simply advise the end host of the common-use location? (cell-id 123 = > 0000 N. Main > St.) > > -Marc- > > > > > > > > The cell-id to psap mapping database one operator has could become the > > > LoST server of that operator. When an end device attaches to a > > cellular network, it learns its cell-id and then it could use LoST to > > translate its cell-id to the psap uri, as the operator can always > > translate its own cell-id to the correct psap uri. There is no need > > for a global database for this, the operator needs to keep its own > > database up to date anyways, regardless of the amount of cell-id > > movement. > > What is needed is that the operator's (currently existing) database > > supports LoST and LoST carries cell-id. An extension to the latter one > > > could be done, but first lets fix the requirement. All the rest is > > just reuse of existing staff. > > > > - gabor > > > > > > -----Original Message----- > > From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Thursday, March 06, 2008 2:10 PM > > To: Richard Barnes; Bajko Gabor (Nokia-OCTO/MtView) > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > Hi Richard, > > > > The Cell-ID is made up of 4 parts: > > > > MCC = Mobile Country Code > > MNC = Mobile Network Code (the operator) LAC = Local Area Code Cell = > > The number of the cell > > > > So with this, it is actually possible to easily work out where the > > operator is at least to a national level, and who the operator is. The > > > other components are assigned by the operator and and would need the > > operator to either provide this information to LoST directly, or > > provide an interface to a specific LoST server to query. > > > > Given the operator sensitivity to this information being generally > > public, and the amount of cell-id movement that goes on, this may > > actually become quite impractical quite quickly. Some operators I > > deal with for example have more than 400k cells in just one country. > > > > Cheers > > James > > > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org on behalf of Richard Barnes > > Sent: Thu 3/6/2008 1:48 PM > > To: Gabor.Bajko@nokia.com > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > Gabor, > > > > If I have a cell-id, how do I figure out where that cell is? > > Is there a well-defined mechanism for doing that over IP? > > (I'm not trying to be rhetorical here, I just don't know.) > > > > My concern with using cell-id as a "pointer" to location in the > > Internet context is that there may not be a way to dereference that > > pointer (i.e., obtain the location of the > > cell) without going outside the Internet, e.g., to a 3GPP non-IP > > interface or some other database. > > > > --Richard > > > > > > > > > > > > Gabor.Bajko@nokia.com wrote: > > > The cell-id (cgi) is a global, well defined and understood in the > > > cellular world. There are no interoperability issues with > > it. If you > > > think otherwise, please give examples. > > > > > > Pidf-lo is an object which encapsulates preexisting location > > > information but it does not define the format of it. > > > > > > - gabor > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of ext James M. Polk > > > Sent: Wednesday, March 05, 2008 2:43 PM > > > To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; > > > br@brianrosen.net; ecrit@ietf.org > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > >> Right. But that means relaxing the requirement "8. section > > 6.1 "Other > > > > >> forms of location representation must be mapped into > > either a geo or > > >> civic for use in emergency calls" in the draft and allow > > other type > > >> of location information, all those which make sense in > > their specific > > > > >> context. > > > > > > I don't understand why you want anything relaxed. The requirement > > > says PIDF-LO is the only location format to be used, and that the > > > is geo or civic. This is a MUST for > > interoperability > > > reasons. Cell-id doesn't accomplish this. > > > > > > > > >> Gabor > > >> > > >> -----Original Message----- > > >> From: ext Marc Linsner [mailto:mlinsner@cisco.com] > > >> Sent: Wednesday, March 05, 2008 12:50 PM > > >> To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); ecrit@ietf.org > > >> Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > >> > > >> Of course there is no reason the operator couldn't provide civic > > >> location > > >> (123 Main St.) in place of cell-id either (verses a geo > > location). > > >> The > > > > > >> main objective is to have location information in the device such > > >> that it makes sense to the consumer vs. every context having their > > >> own location descriptions (cell-id, water meter number, telephone > > >> pole id, property tax plat number, fire hydrant inventory id, msag > > >> address, etc.). > > >> > > >> -Marc- > > >> > > >>> -----Original Message----- > > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > >>> Behalf Of Brian Rosen > > >>> Sent: Wednesday, March 05, 2008 2:53 PM > > >>> To: 'James M. Polk'; Gabor.Bajko@nokia.com; > > >>> Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > >>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > (cell-id) > > >>> > > >>> The basic agreement we have made, in NENA, is that the > > operator will > > > > > >>> agree with the PSAP on a location for the cellid. This > > could be a > > >>> point or a polygon. That location will be reported, in PIDF-LO > > >>> form, from the LIS. > > >>> There was a discussion about actually allowing a cell-id as an > > >>> alternate form of location representation, but it was > > decided not to > > > > > >>> do that. A LIS could, of course, construct a location > > reference of > > >>> the form sip:@opco.net, and send that. When > > dereferenced, > > >>> it would return the agreed-upon location. > > >>> > > >>> Brian > > >>> > > >>>> -----Original Message----- > > >>>> From: ecrit-bounces@ietf.org > > >>> [mailto:ecrit-bounces@ietf.org] On Behalf > > >>>> Of James M. Polk > > >>>> Sent: Wednesday, March 05, 2008 2:29 PM > > >>>> To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > > >>>> ecrit@ietf.org > > >>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > >>>> (cell-id) > > >>>> > > >>>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > >>>>> Cell-id is an identifier of a geographical area which > > is mapped to > > > > >>>>> psap already in today's databases. If you'll make an IP based > > >>>>> emergency call on cellular, that will use now and for many > > >>> years to > > >>>>> come the cell-id to select the psap where to direct your > > >>> call. GAbor > > >>>> let's discuss this topic as its own thread. > > >>>> > > >>>> All (not just some or one) of the following questions need to be > > >>>> answered positively and definitively in order for your Cell-id > > >>>> scenario to work in IP. > > >>>> > > >>>> Where is the Cell-id to PSAP URI mapping done? > > >>>> > > >>>> What database has this information? > > >>>> > > >>>> What IP protocol is used to resolve this mapping of Cell-id to > > >>>> (appropriate) PSAP? > > >>>> > > >>>> Where is this IP-based server located? > > >>>> > > >>>> How can LoST be used to discover this? > > >>>> > > >>>> What LCP will give this Cell-id to a phone to include in a > > >>> SIP message? > > >>>> What SIP header is this information placed in? > > >>>> > > >>>> What form does this Cell-id have in the SIP header from the > > >>> previous > > >>>> question? > > >>>> > > >>>> What IETF document(s) specifies this header and Cell-id form? > > >>>> > > >>>> James > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> 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 > > > _______________________________________________ > > > 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 > > > > > > -------------------------------------------------------------- > > ---------- > > ------------------------ > > This message is for the designated recipient only and may contain > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender immediately > > > and delete the original. Any unauthorized use of this email is > > prohibited. > > -------------------------------------------------------------- > > ---------- > > ------------------------ > > [mf2] > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://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 ecrit-bounces@ietf.org Mon Mar 10 11:13:02 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A1553A6CD9; Mon, 10 Mar 2008 11:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.228 X-Spam-Level: X-Spam-Status: No, score=-101.228 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fc21qWKwVeml; Mon, 10 Mar 2008 11:12:58 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEADE3A68EC; Mon, 10 Mar 2008 11:12:58 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7A5A3A6A2D for ; Mon, 10 Mar 2008 11:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOgMgjdx9Rrk for ; Mon, 10 Mar 2008 11:12:54 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 1EAB93A68EC for ; Mon, 10 Mar 2008 11:12:54 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m2AIBBNi020516; Mon, 10 Mar 2008 13:12:15 -0500 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 20:10:12 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 13:10:06 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 10 Mar 2008 13:09:10 -0500 Message-ID: In-Reply-To: <021201c882d4$58d71f30$6168f444@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) Thread-Index: Ach/wzBRtxbESMZqTD+ZYu8cdpsIsQAE5z0jAI2iEhAAKbgrkAAByrswAAYpzyAAATYUYA== References: <000a01c882b5$bd39c370$d2e8520a@cisco.com> <021201c882d4$58d71f30$6168f444@cis.neustar.com> From: To: , X-OriginalArrivalTime: 10 Mar 2008 18:10:06.0665 (UTC) FILETIME=[F8608B90:01C882D9] X-Nokia-AV: Clean Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The problem is there. In IMS, the UA needs to include its cell-id into the P-Access-Network header. If it doesn't know its geolocation (which is very probable), then there is no other location info included in the invite. Thus, mapping is done based on the cell-id. They will keep doing this regardless of the LoST spec. But this effort is to harmonize between ietf and 3gpp. If usage of cell-id will be allowed, then 3gpp would use the protocols as defined in ietf. Otherwise, they will use it as they think fits better for their needs. Probably I should have started with this problem statement. I just assumed noone thinks I am sending all these mails for fun. - gabor -----Original Message----- From: ext Brian Rosen [mailto:br@brianrosen.net] Sent: Monday, March 10, 2008 10:30 AM To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com Cc: ecrit@ietf.org Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) This still seems to me to be a solution in search of a problem. IMS networks have mechanisms that don't need IETF work to allow a cell id as a location representation. I don't know of any networks that have this problem. If there are, please cite them. If there aren't, we don't need to keep talking about the solution. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Gabor.Bajko@nokia.com > Sent: Monday, March 10, 2008 10:37 AM > To: mlinsner@cisco.com > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > Hi Marc, > > > 1) There is no guarantee the end host will use the cell operator's > LoST service (even if known) > It will, if the LoST server discovery mechanism will provision the > device with the operator's LoST server. > > > 2) If in fact the operator maintains a db of cell-id to psap uri, > would it not be easier to maintain a db of cell-id to common-use > location See James W. answer. > > We are currently talking about cell-id usage only for emergency > services. There is no reason to use the VoIP provider's LoST server, > when you can get the required information (ie psap uri) locally from > the access provider. > > - gabor > > -----Original Message----- > From: ext Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Monday, March 10, 2008 6:51 AM > To: Bajko Gabor (Nokia-OCTO/MtView) > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > Gabor, > > 1) There is no guarantee the end host will use the cell operator's > LoST service (even if known). The end host may use a LoST service > associated with it's VoIP provider or Aor domain provider. > > 2) If in fact the operator maintains a db of cell-id to psap uri, > would it not be easier to maintain a db of cell-id to common-use > location then simply advise the end host of the common-use location? > (cell-id 123 = 0000 N. Main > St.) > > -Marc- > > > > > > > > The cell-id to psap mapping database one operator has could become > > the > > > LoST server of that operator. When an end device attaches to a > > cellular network, it learns its cell-id and then it could use LoST > > to translate its cell-id to the psap uri, as the operator can always > > translate its own cell-id to the correct psap uri. There is no need > > for a global database for this, the operator needs to keep its own > > database up to date anyways, regardless of the amount of cell-id > > movement. > > What is needed is that the operator's (currently existing) database > > supports LoST and LoST carries cell-id. An extension to the latter > > one > > > could be done, but first lets fix the requirement. All the rest is > > just reuse of existing staff. > > > > - gabor > > > > > > -----Original Message----- > > From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Thursday, March 06, 2008 2:10 PM > > To: Richard Barnes; Bajko Gabor (Nokia-OCTO/MtView) > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > Hi Richard, > > > > The Cell-ID is made up of 4 parts: > > > > MCC = Mobile Country Code > > MNC = Mobile Network Code (the operator) LAC = Local Area Code Cell > > = The number of the cell > > > > So with this, it is actually possible to easily work out where the > > operator is at least to a national level, and who the operator is. > > The > > > other components are assigned by the operator and and would need the > > operator to either provide this information to LoST directly, or > > provide an interface to a specific LoST server to query. > > > > Given the operator sensitivity to this information being generally > > public, and the amount of cell-id movement that goes on, this may > > actually become quite impractical quite quickly. Some operators I > > deal with for example have more than 400k cells in just one country. > > > > Cheers > > James > > > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org on behalf of Richard Barnes > > Sent: Thu 3/6/2008 1:48 PM > > To: Gabor.Bajko@nokia.com > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > Gabor, > > > > If I have a cell-id, how do I figure out where that cell is? > > Is there a well-defined mechanism for doing that over IP? > > (I'm not trying to be rhetorical here, I just don't know.) > > > > My concern with using cell-id as a "pointer" to location in the > > Internet context is that there may not be a way to dereference that > > pointer (i.e., obtain the location of the > > cell) without going outside the Internet, e.g., to a 3GPP non-IP > > interface or some other database. > > > > --Richard > > > > > > > > > > > > Gabor.Bajko@nokia.com wrote: > > > The cell-id (cgi) is a global, well defined and understood in the > > > cellular world. There are no interoperability issues with > > it. If you > > > think otherwise, please give examples. > > > > > > Pidf-lo is an object which encapsulates preexisting location > > > information but it does not define the format of it. > > > > > > - gabor > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of ext James M. Polk > > > Sent: Wednesday, March 05, 2008 2:43 PM > > > To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; > > > br@brianrosen.net; ecrit@ietf.org > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > (cell-id) > > > > > > At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > >> Right. But that means relaxing the requirement "8. section > > 6.1 "Other > > > > >> forms of location representation must be mapped into > > either a geo or > > >> civic for use in emergency calls" in the draft and allow > > other type > > >> of location information, all those which make sense in > > their specific > > > > >> context. > > > > > > I don't understand why you want anything relaxed. The requirement > > > says PIDF-LO is the only location format to be used, and that the > > > is geo or civic. This is a MUST for > > interoperability > > > reasons. Cell-id doesn't accomplish this. > > > > > > > > >> Gabor > > >> > > >> -----Original Message----- > > >> From: ext Marc Linsner [mailto:mlinsner@cisco.com] > > >> Sent: Wednesday, March 05, 2008 12:50 PM > > >> To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); > > >> ecrit@ietf.org > > >> Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > >> (cell-id) > > >> > > >> Of course there is no reason the operator couldn't provide civic > > >> location > > >> (123 Main St.) in place of cell-id either (verses a geo > > location). > > >> The > > > > > >> main objective is to have location information in the device such > > >> that it makes sense to the consumer vs. every context having > > >> their own location descriptions (cell-id, water meter number, > > >> telephone pole id, property tax plat number, fire hydrant > > >> inventory id, msag address, etc.). > > >> > > >> -Marc- > > >> > > >>> -----Original Message----- > > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > >>> Behalf Of Brian Rosen > > >>> Sent: Wednesday, March 05, 2008 2:53 PM > > >>> To: 'James M. Polk'; Gabor.Bajko@nokia.com; > > >>> Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > >>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > (cell-id) > > >>> > > >>> The basic agreement we have made, in NENA, is that the > > operator will > > > > > >>> agree with the PSAP on a location for the cellid. This > > could be a > > >>> point or a polygon. That location will be reported, in PIDF-LO > > >>> form, from the LIS. > > >>> There was a discussion about actually allowing a cell-id as an > > >>> alternate form of location representation, but it was > > decided not to > > > > > >>> do that. A LIS could, of course, construct a location > > reference of > > >>> the form sip:@opco.net, and send that. When > > dereferenced, > > >>> it would return the agreed-upon location. > > >>> > > >>> Brian > > >>> > > >>>> -----Original Message----- > > >>>> From: ecrit-bounces@ietf.org > > >>> [mailto:ecrit-bounces@ietf.org] On Behalf > > >>>> Of James M. Polk > > >>>> Sent: Wednesday, March 05, 2008 2:29 PM > > >>>> To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > > >>>> ecrit@ietf.org > > >>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > >>>> (cell-id) > > >>>> > > >>>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > >>>>> Cell-id is an identifier of a geographical area which > > is mapped to > > > > >>>>> psap already in today's databases. If you'll make an IP based > > >>>>> emergency call on cellular, that will use now and for many > > >>> years to > > >>>>> come the cell-id to select the psap where to direct your > > >>> call. GAbor > > >>>> let's discuss this topic as its own thread. > > >>>> > > >>>> All (not just some or one) of the following questions need to > > >>>> be answered positively and definitively in order for your > > >>>> Cell-id scenario to work in IP. > > >>>> > > >>>> Where is the Cell-id to PSAP URI mapping done? > > >>>> > > >>>> What database has this information? > > >>>> > > >>>> What IP protocol is used to resolve this mapping of Cell-id to > > >>>> (appropriate) PSAP? > > >>>> > > >>>> Where is this IP-based server located? > > >>>> > > >>>> How can LoST be used to discover this? > > >>>> > > >>>> What LCP will give this Cell-id to a phone to include in a > > >>> SIP message? > > >>>> What SIP header is this information placed in? > > >>>> > > >>>> What form does this Cell-id have in the SIP header from the > > >>> previous > > >>>> question? > > >>>> > > >>>> What IETF document(s) specifies this header and Cell-id form? > > >>>> > > >>>> James > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> 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 > > > _______________________________________________ > > > 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 > > > > > > -------------------------------------------------------------- > > ---------- > > ------------------------ > > This message is for the designated recipient only and may contain > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately > > > and delete the original. Any unauthorized use of this email is > > prohibited. > > -------------------------------------------------------------- > > ---------- > > ------------------------ > > [mf2] > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://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 ecrit-bounces@ietf.org Mon Mar 10 11:42:55 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8F428C384; Mon, 10 Mar 2008 11:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.518 X-Spam-Level: X-Spam-Status: No, score=-101.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EMuIjrIn3vB; Mon, 10 Mar 2008 11:42:53 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF4A3A69C6; Mon, 10 Mar 2008 11:42:50 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27CE03A690D for ; Mon, 10 Mar 2008 11:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmFHAXP2OMC2 for ; Mon, 10 Mar 2008 11:42:47 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 8C1203A6AAB for ; Mon, 10 Mar 2008 11:41:59 -0700 (PDT) Received: from 99-201-6-156.area3.spcsdns.net ([99.201.6.156] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JYmu1-0004Zs-1s; Mon, 10 Mar 2008 13:39:33 -0500 From: "Brian Rosen" To: , References: <000a01c882b5$bd39c370$d2e8520a@cisco.com> <021201c882d4$58d71f30$6168f444@cis.neustar.com> Date: Mon, 10 Mar 2008 14:39:12 -0400 Message-ID: <022901c882de$0cdefcb0$6168f444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: Ach/wzBRtxbESMZqTD+ZYu8cdpsIsQAE5z0jAI2iEhAAKbgrkAAByrswAAYpzyAAATYUYAABKpfQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The E-CSCF has access to the translation from cell-id to location. That is local to the visited network. It queries LoST with the location and routes the call. It's all inside the E-CSCF (well, it could be in the RDF, but that's another argument about whether the E-CSCF queries LoST or the E-CSCF queries the RDF and the RDF queries LoST). Brian > -----Original Message----- > From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] > Sent: Monday, March 10, 2008 2:09 PM > To: br@brianrosen.net; mlinsner@cisco.com > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > The problem is there. In IMS, the UA needs to include its cell-id into > the P-Access-Network header. If it doesn't know its geolocation (which > is very probable), then there is no other location info included in the > invite. Thus, mapping is done based on the cell-id. > > They will keep doing this regardless of the LoST spec. But this effort > is to harmonize between ietf and 3gpp. If usage of cell-id will be > allowed, then 3gpp would use the protocols as defined in ietf. > Otherwise, they will use it as they think fits better for their needs. > > Probably I should have started with this problem statement. I just > assumed noone thinks I am sending all these mails for fun. > > - gabor > > -----Original Message----- > From: ext Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, March 10, 2008 10:30 AM > To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > This still seems to me to be a solution in search of a problem. IMS > networks have mechanisms that don't need IETF work to allow a cell id as > a location representation. I don't know of any networks that have this > problem. If there are, please cite them. If there aren't, we don't > need to keep talking about the solution. > > Brian > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Gabor.Bajko@nokia.com > > Sent: Monday, March 10, 2008 10:37 AM > > To: mlinsner@cisco.com > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > Hi Marc, > > > > > 1) There is no guarantee the end host will use the cell operator's > > LoST service (even if known) > > It will, if the LoST server discovery mechanism will provision the > > device with the operator's LoST server. > > > > > 2) If in fact the operator maintains a db of cell-id to psap uri, > > would it not be easier to maintain a db of cell-id to common-use > > location See James W. answer. > > > > We are currently talking about cell-id usage only for emergency > > services. There is no reason to use the VoIP provider's LoST server, > > when you can get the required information (ie psap uri) locally from > > the access provider. > > > > - gabor > > > > -----Original Message----- > > From: ext Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Monday, March 10, 2008 6:51 AM > > To: Bajko Gabor (Nokia-OCTO/MtView) > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > Gabor, > > > > 1) There is no guarantee the end host will use the cell operator's > > LoST service (even if known). The end host may use a LoST service > > associated with it's VoIP provider or Aor domain provider. > > > > 2) If in fact the operator maintains a db of cell-id to psap uri, > > would it not be easier to maintain a db of cell-id to common-use > > location then simply advise the end host of the common-use location? > > (cell-id 123 = 0000 N. Main > > St.) > > > > -Marc- > > > > > > > > > > > > > > The cell-id to psap mapping database one operator has could become > > > the > > > > > LoST server of that operator. When an end device attaches to a > > > cellular network, it learns its cell-id and then it could use LoST > > > to translate its cell-id to the psap uri, as the operator can always > > > > translate its own cell-id to the correct psap uri. There is no need > > > for a global database for this, the operator needs to keep its own > > > database up to date anyways, regardless of the amount of cell-id > > > movement. > > > What is needed is that the operator's (currently existing) database > > > supports LoST and LoST carries cell-id. An extension to the latter > > > one > > > > > could be done, but first lets fix the requirement. All the rest is > > > just reuse of existing staff. > > > > > > - gabor > > > > > > > > > -----Original Message----- > > > From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Thursday, March 06, 2008 2:10 PM > > > To: Richard Barnes; Bajko Gabor (Nokia-OCTO/MtView) > > > Cc: ecrit@ietf.org > > > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > Hi Richard, > > > > > > The Cell-ID is made up of 4 parts: > > > > > > MCC = Mobile Country Code > > > MNC = Mobile Network Code (the operator) LAC = Local Area Code Cell > > > = The number of the cell > > > > > > So with this, it is actually possible to easily work out where the > > > operator is at least to a national level, and who the operator is. > > > The > > > > > other components are assigned by the operator and and would need the > > > > operator to either provide this information to LoST directly, or > > > provide an interface to a specific LoST server to query. > > > > > > Given the operator sensitivity to this information being generally > > > public, and the amount of cell-id movement that goes on, this may > > > actually become quite impractical quite quickly. Some operators I > > > deal with for example have more than 400k cells in just one country. > > > > > > Cheers > > > James > > > > > > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org on behalf of Richard Barnes > > > Sent: Thu 3/6/2008 1:48 PM > > > To: Gabor.Bajko@nokia.com > > > Cc: ecrit@ietf.org > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > Gabor, > > > > > > If I have a cell-id, how do I figure out where that cell is? > > > Is there a well-defined mechanism for doing that over IP? > > > (I'm not trying to be rhetorical here, I just don't know.) > > > > > > My concern with using cell-id as a "pointer" to location in the > > > Internet context is that there may not be a way to dereference that > > > pointer (i.e., obtain the location of the > > > cell) without going outside the Internet, e.g., to a 3GPP non-IP > > > interface or some other database. > > > > > > --Richard > > > > > > > > > > > > > > > > > > Gabor.Bajko@nokia.com wrote: > > > > The cell-id (cgi) is a global, well defined and understood in the > > > > cellular world. There are no interoperability issues with > > > it. If you > > > > think otherwise, please give examples. > > > > > > > > Pidf-lo is an object which encapsulates preexisting location > > > > information but it does not define the format of it. > > > > > > > > - gabor > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > Of ext James M. Polk > > > > Sent: Wednesday, March 05, 2008 2:43 PM > > > > To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; > > > > br@brianrosen.net; ecrit@ietf.org > > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > > (cell-id) > > > > > > > > At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > >> Right. But that means relaxing the requirement "8. section > > > 6.1 "Other > > > > > > >> forms of location representation must be mapped into > > > either a geo or > > > >> civic for use in emergency calls" in the draft and allow > > > other type > > > >> of location information, all those which make sense in > > > their specific > > > > > > >> context. > > > > > > > > I don't understand why you want anything relaxed. The requirement > > > > > says PIDF-LO is the only location format to be used, and that the > > > > is geo or civic. This is a MUST for > > > interoperability > > > > reasons. Cell-id doesn't accomplish this. > > > > > > > > > > > >> Gabor > > > >> > > > >> -----Original Message----- > > > >> From: ext Marc Linsner [mailto:mlinsner@cisco.com] > > > >> Sent: Wednesday, March 05, 2008 12:50 PM > > > >> To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); > > > >> ecrit@ietf.org > > > >> Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > >> (cell-id) > > > >> > > > >> Of course there is no reason the operator couldn't provide civic > > > >> location > > > >> (123 Main St.) in place of cell-id either (verses a geo > > > location). > > > >> The > > > > > > > >> main objective is to have location information in the device such > > > > >> that it makes sense to the consumer vs. every context having > > > >> their own location descriptions (cell-id, water meter number, > > > >> telephone pole id, property tax plat number, fire hydrant > > > >> inventory id, msag address, etc.). > > > >> > > > >> -Marc- > > > >> > > > >>> -----Original Message----- > > > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > > >>> Behalf Of Brian Rosen > > > >>> Sent: Wednesday, March 05, 2008 2:53 PM > > > >>> To: 'James M. Polk'; Gabor.Bajko@nokia.com; > > > >>> Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > > >>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > (cell-id) > > > >>> > > > >>> The basic agreement we have made, in NENA, is that the > > > operator will > > > > > > > >>> agree with the PSAP on a location for the cellid. This > > > could be a > > > >>> point or a polygon. That location will be reported, in PIDF-LO > > > >>> form, from the LIS. > > > >>> There was a discussion about actually allowing a cell-id as an > > > >>> alternate form of location representation, but it was > > > decided not to > > > > > > > >>> do that. A LIS could, of course, construct a location > > > reference of > > > >>> the form sip:@opco.net, and send that. When > > > dereferenced, > > > >>> it would return the agreed-upon location. > > > >>> > > > >>> Brian > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: ecrit-bounces@ietf.org > > > >>> [mailto:ecrit-bounces@ietf.org] On Behalf > > > >>>> Of James M. Polk > > > >>>> Sent: Wednesday, March 05, 2008 2:29 PM > > > >>>> To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > > > >>>> ecrit@ietf.org > > > >>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > >>>> (cell-id) > > > >>>> > > > >>>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > >>>>> Cell-id is an identifier of a geographical area which > > > is mapped to > > > > > > >>>>> psap already in today's databases. If you'll make an IP based > > > >>>>> emergency call on cellular, that will use now and for many > > > >>> years to > > > >>>>> come the cell-id to select the psap where to direct your > > > >>> call. GAbor > > > >>>> let's discuss this topic as its own thread. > > > >>>> > > > >>>> All (not just some or one) of the following questions need to > > > >>>> be answered positively and definitively in order for your > > > >>>> Cell-id scenario to work in IP. > > > >>>> > > > >>>> Where is the Cell-id to PSAP URI mapping done? > > > >>>> > > > >>>> What database has this information? > > > >>>> > > > >>>> What IP protocol is used to resolve this mapping of Cell-id to > > > >>>> (appropriate) PSAP? > > > >>>> > > > >>>> Where is this IP-based server located? > > > >>>> > > > >>>> How can LoST be used to discover this? > > > >>>> > > > >>>> What LCP will give this Cell-id to a phone to include in a > > > >>> SIP message? > > > >>>> What SIP header is this information placed in? > > > >>>> > > > >>>> What form does this Cell-id have in the SIP header from the > > > >>> previous > > > >>>> question? > > > >>>> > > > >>>> What IETF document(s) specifies this header and Cell-id form? > > > >>>> > > > >>>> James > > > >>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> 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 > > > > _______________________________________________ > > > > 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 > > > > > > > > > -------------------------------------------------------------- > > > ---------- > > > ------------------------ > > > This message is for the designated recipient only and may contain > > > privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately > > > > > and delete the original. Any unauthorized use of this email is > > > prohibited. > > > -------------------------------------------------------------- > > > ---------- > > > ------------------------ > > > [mf2] > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://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 ecrit-bounces@ietf.org Mon Mar 10 12:10:12 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 063853A6D7D; Mon, 10 Mar 2008 12:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q85yC+QgG1GA; Mon, 10 Mar 2008 12:10:02 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4074A3A6D42; Mon, 10 Mar 2008 12:09:37 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80F0B3A6BDF for ; Mon, 10 Mar 2008 12:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsopepXIjute for ; Mon, 10 Mar 2008 12:09:34 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A1D4F3A6CAB for ; Mon, 10 Mar 2008 12:07:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,475,1199682000"; d="scan'208";a="1179803" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Mar 2008 15:05:36 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2AJ5a8D012917; Mon, 10 Mar 2008 15:05:36 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m2AJ5Yjd019074; Mon, 10 Mar 2008 19:05:35 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 15:05:35 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.102]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 15:05:35 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Mar 2008 13:28:17 -0500 To: "Hannes Tschofenig" , ecrit@ietf.org, Gabor.Bajko@nokia.com From: "James M. Polk" In-Reply-To: <20080306073141.23430@gmx.net> References: <47CAE9CA.9010901@gmx.net> <20080306073141.23430@gmx.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 10 Mar 2008 19:05:35.0443 (UTC) FILETIME=[B87BC230:01C882E1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3510; t=1205175936; x=1206039936; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20Questions/Answers=20regarding=20Cell-ID s |Sender:=20 |To:=20=22Hannes=20Tschofenig=22=20,=20ecrit@ietf.org,=0A=20=20=20=20=20=20=20=20Gabor.Bajko @nokia.com; bh=Pu6sV+nEOJoXqADMHeHtDlpIIjHoVdIgqn2jgKfqLfI=; b=nXbZDhM69tHhiGIkZPNsujGGxbMQncPgui1bsFKv98D8FeHxI7bnNv2Hyl S2HgHpuUUpoaskbtkElYxvlB+vNrTKK6Cn4cUYpFf3D3nM2vhkU5OGkWU6d0 63NKyhYgH3; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [From ecrit-bounces@ietf.org Mon Mar 10 12:10:12 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3954C28C300; Mon, 10 Mar 2008 12:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.363 X-Spam-Level: X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=-1.926, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbQrV6l6lUFF; Mon, 10 Mar 2008 12:10:03 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 843C53A6E7C; Mon, 10 Mar 2008 12:09:38 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35F083A6C91 for ; Mon, 10 Mar 2008 12:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjTyRFlcPXAC for ; Mon, 10 Mar 2008 12:09:34 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3BAAC3A6D4E for ; Mon, 10 Mar 2008 12:08:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,475,1199682000"; d="scan'208";a="1213323" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Mar 2008 15:05:38 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2AJ5euu012955; Mon, 10 Mar 2008 15:05:40 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m2AJ5Hk1018913; Mon, 10 Mar 2008 19:05:40 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 15:05:36 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.102]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 15:05:36 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Mar 2008 13:29:40 -0500 To: , , , From: "James M. Polk" In-Reply-To: References: <47CAE9CA.9010901@gmx.net> <20080306073141.23430@gmx.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 10 Mar 2008 19:05:36.0240 (UTC) FILETIME=[B8F55F00:01C882E1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=546; t=1205175940; x=1206039940; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Ecrit]=20Questions/Answers=20regarding =20Cell-IDs |Sender:=20 |To:=20,=20,=20,=0A=20=20=20=20=20=20=20=20; bh=Rx1wzEubxTaDxUWlLIEa79DPbul5r5NrFH/3uLue6EI=; b=lURBj2+68+U/XSrvSs7YiviYejRq0C+++BqF6nqcSdL8i105zCfxllu/px OlYuZ3In6l3Ni+xvfWunGcCcklC0x8CLPpscYjzH8bofCkiYlB3ykWX635Xb 8xrhxewqqx; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Ecrit] Questions/Answers regarding Cell-IDs X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 08:11 AM 3/6/2008, Markus.Isomaki@nokia.com wrote: >Hi, > >About carrying Cell-id information in SIP: > >Hannes Tschofenig wrote: > >Only 3GPP docs do at the moment. > >There may not be a need to carry them in SIP when LoST is run > >at the end point. > > > >I think this is all in IETF RFC 3455 >(http://tools.ietf.org/html/rfc3455). It defines a header called >P-Access-Network-Info, which can carry a Cell-id. The details can be >found in the RFC. but this isn't used by LoST or SIP or any LCP or Presence... >Markus _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit Ecrit] Questions/Answers regarding Cell-IDs X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hannes At 02:31 AM 3/6/2008, Hannes Tschofenig wrote: >Hi James, > > > At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > >Cell-id is an identifier of a geographical area which is mapped to psap > > >already in today's databases. If you'll make an IP based emergency call > > >on cellular, that will use now and for many years to come the cell-id to > > >select the psap where to direct your call. GAbor > > > > let's discuss this topic as its own thread. > > > > All (not just some or one) of the following questions need to be > > answered positively and definitively in order for your Cell-id > > scenario to work in IP. > > >Anticipating what Gabor tries to say here... > > > Where is the Cell-id to PSAP URI mapping done? > >That information is in the LoST database. I don't believe it is, since you are assuming (on another thread) that there is an inherent proximity between the LoST server location and the Access provider, and I don't believe that's going to always be the case. The what do you do? Do you punt? > > > > What database has this information? > >See above. see above - i.e., I think this won't be common > > > > What IP protocol is used to resolve this mapping of Cell-id to > > (appropriate) PSAP? > >LoST given: MCC = Mobile Country Code MNC = Mobile Network Code (the operator) LAC = Local Area Code Cell = The number of the cell then how does http:mmc-mnc-lac-cell@ turn into a viable LoST response? I don't believe this is/will be true for each LoST server, where we are all (I believe) thinking the LoST db will be the same in each LoST server.... Why doesn't a LocationURI solve this without a Cell-ID, provided by the LCP? > > > > Where is this IP-based server located? > >A LoST server could be located anywhere. meaning there is a every-cell-tower to PSAP uri mapping maintained? By who? >It is easier and more robust to place a LoST server in the access or >close to the access. while practical, we cannot assume that, therefore the protocols we use have to operate when this isn't the case. > > > > How can LoST be used to discover this? > >Using the documents we wrote; you are co-author of that document blah ;-) > > > > What LCP will give this Cell-id to a phone to include in a SIP message? > >Cell-IDs are provided by the link layer. This is already done today fair, but the argument is being made by several of us that cell-id to psap-uri mapping doesn't exist anywhere. Who will build that db and maintain it? BTW - there are 100X more cell towers than PSAPs, so this is a large problem. > > > > What SIP header is this information placed in? > >If LoST is run at the end point then the Cell-ID does not need to be >carried in SIP at all. > >However, there is a 3GPP specification that carries a cell-ID >already today. I would have to search for it I know there is, but id doesn't get them the PSAP URI when including it in a SIP message. This is what Gabor wants, and this is what many have voiced concerns with attempting to achieve. > > > > What form does this Cell-id have in the SIP header from the previous > > question? > >Need to look it up. > > > > What IETF document(s) specifies this header and Cell-id form? > >Only 3GPP docs do at the moment. >There may not be a need to carry them in SIP when LoST is run at the >end point. > >Ciao >Hannes > > > > > James > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 10 12:10:13 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99D8528C3C4; Mon, 10 Mar 2008 12:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.248 X-Spam-Level: X-Spam-Status: No, score=-101.248 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5dtaIzuUQeT; Mon, 10 Mar 2008 12:10:12 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D05CB3A6E87; Mon, 10 Mar 2008 12:09:38 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 515803A6D42 for ; Mon, 10 Mar 2008 12:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2dLdR0mREJS for ; Mon, 10 Mar 2008 12:09:35 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 49C3F28C275 for ; Mon, 10 Mar 2008 12:08:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,475,1199682000"; d="scan'208";a="1179819" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Mar 2008 15:05:44 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2AJ5iF0012981; Mon, 10 Mar 2008 15:05:44 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m2AJ5Ujn019007; Mon, 10 Mar 2008 19:05:40 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 15:05:38 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.102]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 15:05:37 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Mar 2008 13:34:55 -0500 To: "Roger Marshall" , , "Marc Linsner" , From: "James M. Polk" In-Reply-To: <8C837214C95C864C9F34F3635C2A657509543153@SEA-EXCHVS-2.tele comsys.com> References: <47D2FA88.9040902@gmx.net> <8C837214C95C864C9F34F3635C2A657509543153@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 10 Mar 2008 19:05:37.0943 (UTC) FILETIME=[B9F93A70:01C882E1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1506; t=1205175944; x=1206039944; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Slides |Sender:=20 |To:=20=22Roger=20Marshall=22=20, =20,=0A=20=20=20=20=20=20=20=20=22Marc=20Lin sner=22=20,=20; bh=MBV6uC6ci9RyhzhP4Q40e93rF+nqUch1LESJEMTeSao=; b=HbF+4Wkj3YJeRqhPh/U7V7xw3M2v8xFk+1Spr2/auAgLxDumqXBhRoo2dE LjyUJwPpXL+yPczIdNM3AvUIWuZoKKUCkCSTkbUkw2VBCUQhTNfxRBt7i4CK kR/xwqUWKP; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Ecrit] Slides X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I didn't ever see an agenda posted to know which presentations to expect... At 10:11 PM 3/9/2008, Roger Marshall wrote: >I have not yet received slides for the ecrit meeting tomorrow afternoon. > >I need the slides ahead of time, so I can post them. Please send them. > >Thanks in advance. > >-roger marshall. >rmarshall@telecomsys.com > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of Hannes Tschofenig > > Sent: Saturday, March 08, 2008 12:44 PM > > To: ecrit@ietf.org > > Subject: [Ecrit] Slides > > > > Please sent your slides to Roger so that he can upload them > > to the webpage. > > > > Thanks > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > >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. > >_______________________________________________ >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 ecrit-bounces@ietf.org Mon Mar 10 12:10:17 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E52E728C41C; Mon, 10 Mar 2008 12:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.03 X-Spam-Level: X-Spam-Status: No, score=-101.03 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztHEuXxU6sW6; Mon, 10 Mar 2008 12:10:13 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 828D33A6A2D; Mon, 10 Mar 2008 12:09:40 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 919343A6E98 for ; Mon, 10 Mar 2008 12:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xZLrZPhJTRV for ; Mon, 10 Mar 2008 12:09:35 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 240A43A6D4C for ; Mon, 10 Mar 2008 12:08:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,475,1199682000"; d="scan'208";a="1179813" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 10 Mar 2008 15:05:40 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m2AJ5eML025950; Mon, 10 Mar 2008 15:05:40 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m2AJ5Ujl019007; Mon, 10 Mar 2008 19:05:40 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 15:05:37 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.102]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 15:05:37 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Mar 2008 13:33:33 -0500 To: Hannes Tschofenig , Marc Linsner From: "James M. Polk" In-Reply-To: <47D034C1.6050306@gmx.net> References: <007401c87f8d$f4511550$270d0d0a@cisco.com> <47D034C1.6050306@gmx.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 10 Mar 2008 19:05:37.0131 (UTC) FILETIME=[B97D53B0:01C882E1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3821; t=1205175940; x=1206039940; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Questions/Answers=20regarding =20Cell-IDs |Sender:=20 |To:=20Hannes=20Tschofenig=20,=0 A=20=20=20=20=20=20=20=20Marc=20Linsner=20; bh=XTVmEm+a81wgmA5yRkQfafokgD8yFbMNCDwRs2NtkIs=; b=E4k62s+jXG4XV/WQjPJeeYEDsjyLJGL/74rtF2qucAXqDRxFLfDOm7nEHy k4rsQZwJ7/WrYme6tsHdwzM3OCIcYJ1Z7keXmA2NNZl6fwgRK3AnJ2JFDO3X 6/Tvvm8cpl; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Gabor.Bajko@nokia.com, ecrit@ietf.org Subject: Re: [Ecrit] Questions/Answers regarding Cell-IDs X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 01:15 PM 3/6/2008, Hannes Tschofenig wrote: >Hi Marc, > >here is one possible description: > >* You get a LbyR using an LbyR >(for dispatch) I think you mistyped >* You have the cell-ID based on the link layer interaction. >(for routing to the right PSAP) > >The cell-id is used for determining the PSAP URI. >The PSAP uses the LbyR to obtain the precise location from the LIS >for dispatch. how does a SIP proxy server use a cell-id for making routing decisions? >Another possible use case is the following > >End point communicates cell-id in the SIP message (according to the >3GPP specifications). >The proxy uses the cell-id to determine the the route towards the PSAP. how? This is not going to happen in regular SIP, which is what we *have* to rely on >The PSAP uses obtains an LbyR from the LIS in order to allow the >PSAP to retrieve the precise location. If the PSAP doesn't have a locationURI, how does it ask for one from the LIS, and how does the PSAP know which LIS to ask to get this locationURI? You are putting the cart before the horse here >Ciao >Hannes > >Marc Linsner wrote: >>Hannes, >> >>What pidf-lo tag gets populated with cell-id? >> >>-Marc- >> >>>-----Original Message----- >>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>Behalf Of Hannes Tschofenig >>>Sent: Thursday, March 06, 2008 2:32 AM >>>To: James M. Polk; ecrit@ietf.org; Gabor.Bajko@nokia.com >>>Subject: [Ecrit] Questions/Answers regarding Cell-IDs >>> >>>Hi James, >>> >>> >>>>At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: >>>> >>>>>Cell-id is an identifier of a geographical area which is mapped >>>>>to psap already in today's databases. If you'll make an IP based >>>>>emergency call on cellular, that will use now and for many >>>years to >>>>>come the cell-id to select the psap where to direct your >>>call. GAbor >>> >>>>let's discuss this topic as its own thread. >>>> >>>>All (not just some or one) of the following questions need to be >>>>answered positively and definitively in order for your Cell-id >>>>scenario to work in IP. >>>> >>>> >>>Anticipating what Gabor tries to say here... >>> >>> >>>>Where is the Cell-id to PSAP URI mapping done? >>>> >>>That information is in the LoST database. >>> >>>>What database has this information? >>>> >>>See above. >>> >>>>What IP protocol is used to resolve this mapping of Cell-id to >>>>(appropriate) PSAP? >>>> >>>LoST >>> >>> >>>>Where is this IP-based server located? >>>> >>>A LoST server could be located anywhere. It is easier and more >>>robust to place a LoST server in the access or close to the access. >>> >>>>How can LoST be used to discover this? >>>> >>>Using the documents we wrote; you are co-author of that document >>> >>>>What LCP will give this Cell-id to a phone to include in a >>>SIP message? >>> >>>Cell-IDs are provided by the link layer. This is already done today >>> >>> >>> >>>>What SIP header is this information placed in? >>>> >>>If LoST is run at the end point then the Cell-ID does not need to >>>be carried in SIP at all. >>>However, there is a 3GPP specification that carries a cell-ID >>>already today. I would have to search for it >>> >>> >>>>What form does this Cell-id have in the SIP header from the >>>previous >>>>question? >>>> >>>Need to look it up. >>>>What IETF document(s) specifies this header and Cell-id form? >>>> >>>Only 3GPP docs do at the moment. There may not be a need to carry >>>them in SIP when LoST is run at the end point. >>>Ciao >>>Hannes >>> >>> >>>> James >>>> >>>> >>>_______________________________________________ >>>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 ecrit-bounces@ietf.org Mon Mar 10 15:53:40 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A9AA28C35D; Mon, 10 Mar 2008 15:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.629 X-Spam-Level: X-Spam-Status: No, score=-100.629 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIlGXOc5aqIi; Mon, 10 Mar 2008 15:53:39 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118393A6954; Mon, 10 Mar 2008 15:53:39 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70DD53A687B for ; Mon, 10 Mar 2008 15:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-bBrq-+vLYI for ; Mon, 10 Mar 2008 15:53:36 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id B036C28C1A9 for ; Mon, 10 Mar 2008 15:53:35 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_03_10_18_03_57 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 10 Mar 2008 18:03:57 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Mar 2008 17:51:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 10 Mar 2008 17:51:10 -0500 Message-ID: In-Reply-To: <021201c882d4$58d71f30$6168f444@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) Thread-Index: Ach/wzBRtxbESMZqTD+ZYu8cdpsIsQAE5z0jAI2iEhAAKbgrkAAByrswAAYpzyAACvGZAA== References: <000a01c882b5$bd39c370$d2e8520a@cisco.com> <021201c882d4$58d71f30$6168f444@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , , X-OriginalArrivalTime: 10 Mar 2008 22:51:11.0207 (UTC) FILETIME=[3C6D6F70:01C88301] Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Indeed - and I'm actually puzzled that so much bandwidth is being spent on the specific topic of "cell-id". * This is just one parameter for one type of network * DSL networks have L2TP tunnel identifiers, or ATM PVC identifiers, WiMAX networks have serving base station identifiers. * For many networks the device doesn't even get to see these identifiers. It's an accident of history that cellular devices see cell-ids; it's not the basis for a generic approach to IP location. * We actually want networks to provide a consistent query interface that provides location so network parameters don't need to be seen in the application space. * Cell-ID is not actually adequate for reliable emergency call routing in the US. That's why the CRDB exists for IS-41 networks and why GMLC-assigned ESRK was introduced into GSM specs in 2004. Estimates of 30% misroutes based on cell-ID were the anecdotal standard prior to that. You need to add timing measurements or other enhancements to get decent routing. I believe we want to rely on the access networks to provide ubiquitous and reliable *location* determination so the clients and application layers have a consistent basis for implementation and a consistent experience regardless of access technology. Talking about devices knowing they are on a cellular network, getting a cell-ID, and then LoST knowing what to do with cell-IDs is giving me the heebee jeebies... Let the cellular networks deal with cell-IDs so the rest of the world doesn't have to. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, 11 March 2008 4:30 AM To: Gabor.Bajko@nokia.com; mlinsner@cisco.com Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) This still seems to me to be a solution in search of a problem. IMS networks have mechanisms that don't need IETF work to allow a cell id as a location representation. I don't know of any networks that have this problem. If there are, please cite them. If there aren't, we don't need to keep talking about the solution. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Gabor.Bajko@nokia.com > Sent: Monday, March 10, 2008 10:37 AM > To: mlinsner@cisco.com > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > Hi Marc, > > > 1) There is no guarantee the end host will use the cell operator's > LoST service (even if known) > It will, if the LoST server discovery mechanism will provision the > device with the operator's LoST server. > > > 2) If in fact the operator maintains a db of cell-id to psap uri, > would it not be easier to maintain a db of cell-id to common-use > location > See James W. answer. > > We are currently talking about cell-id usage only for emergency > services. There is no reason to use the VoIP provider's LoST server, > when you can get the required information (ie psap uri) locally from the > access provider. > > - gabor > > -----Original Message----- > From: ext Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Monday, March 10, 2008 6:51 AM > To: Bajko Gabor (Nokia-OCTO/MtView) > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > Gabor, > > 1) There is no guarantee the end host will use the cell operator's LoST > service (even if known). The end host may use a LoST service associated > with it's VoIP provider or Aor domain provider. > > 2) If in fact the operator maintains a db of cell-id to psap uri, would > it not be easier to maintain a db of cell-id to common-use location then > simply advise the end host of the common-use location? (cell-id 123 = > 0000 N. Main > St.) > > -Marc- > > > > > > > > The cell-id to psap mapping database one operator has could become the > > > LoST server of that operator. When an end device attaches to a > > cellular network, it learns its cell-id and then it could use LoST to > > translate its cell-id to the psap uri, as the operator can always > > translate its own cell-id to the correct psap uri. There is no need > > for a global database for this, the operator needs to keep its own > > database up to date anyways, regardless of the amount of cell-id > > movement. > > What is needed is that the operator's (currently existing) database > > supports LoST and LoST carries cell-id. An extension to the latter one > > > could be done, but first lets fix the requirement. All the rest is > > just reuse of existing staff. > > > > - gabor > > > > > > -----Original Message----- > > From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Thursday, March 06, 2008 2:10 PM > > To: Richard Barnes; Bajko Gabor (Nokia-OCTO/MtView) > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > Hi Richard, > > > > The Cell-ID is made up of 4 parts: > > > > MCC = Mobile Country Code > > MNC = Mobile Network Code (the operator) LAC = Local Area Code Cell = > > The number of the cell > > > > So with this, it is actually possible to easily work out where the > > operator is at least to a national level, and who the operator is. The > > > other components are assigned by the operator and and would need the > > operator to either provide this information to LoST directly, or > > provide an interface to a specific LoST server to query. > > > > Given the operator sensitivity to this information being generally > > public, and the amount of cell-id movement that goes on, this may > > actually become quite impractical quite quickly. Some operators I > > deal with for example have more than 400k cells in just one country. > > > > Cheers > > James > > > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org on behalf of Richard Barnes > > Sent: Thu 3/6/2008 1:48 PM > > To: Gabor.Bajko@nokia.com > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > Gabor, > > > > If I have a cell-id, how do I figure out where that cell is? > > Is there a well-defined mechanism for doing that over IP? > > (I'm not trying to be rhetorical here, I just don't know.) > > > > My concern with using cell-id as a "pointer" to location in the > > Internet context is that there may not be a way to dereference that > > pointer (i.e., obtain the location of the > > cell) without going outside the Internet, e.g., to a 3GPP non-IP > > interface or some other database. > > > > --Richard > > > > > > > > > > > > Gabor.Bajko@nokia.com wrote: > > > The cell-id (cgi) is a global, well defined and understood in the > > > cellular world. There are no interoperability issues with > > it. If you > > > think otherwise, please give examples. > > > > > > Pidf-lo is an object which encapsulates preexisting location > > > information but it does not define the format of it. > > > > > > - gabor > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of ext James M. Polk > > > Sent: Wednesday, March 05, 2008 2:43 PM > > > To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; > > > br@brianrosen.net; ecrit@ietf.org > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > >> Right. But that means relaxing the requirement "8. section > > 6.1 "Other > > > > >> forms of location representation must be mapped into > > either a geo or > > >> civic for use in emergency calls" in the draft and allow > > other type > > >> of location information, all those which make sense in > > their specific > > > > >> context. > > > > > > I don't understand why you want anything relaxed. The requirement > > > says PIDF-LO is the only location format to be used, and that the > > > is geo or civic. This is a MUST for > > interoperability > > > reasons. Cell-id doesn't accomplish this. > > > > > > > > >> Gabor > > >> > > >> -----Original Message----- > > >> From: ext Marc Linsner [mailto:mlinsner@cisco.com] > > >> Sent: Wednesday, March 05, 2008 12:50 PM > > >> To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); ecrit@ietf.org > > >> Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > >> > > >> Of course there is no reason the operator couldn't provide civic > > >> location > > >> (123 Main St.) in place of cell-id either (verses a geo > > location). > > >> The > > > > > >> main objective is to have location information in the device such > > >> that it makes sense to the consumer vs. every context having their > > >> own location descriptions (cell-id, water meter number, telephone > > >> pole id, property tax plat number, fire hydrant inventory id, msag > > >> address, etc.). > > >> > > >> -Marc- > > >> > > >>> -----Original Message----- > > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > >>> Behalf Of Brian Rosen > > >>> Sent: Wednesday, March 05, 2008 2:53 PM > > >>> To: 'James M. Polk'; Gabor.Bajko@nokia.com; > > >>> Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > >>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > (cell-id) > > >>> > > >>> The basic agreement we have made, in NENA, is that the > > operator will > > > > > >>> agree with the PSAP on a location for the cellid. This > > could be a > > >>> point or a polygon. That location will be reported, in PIDF-LO > > >>> form, from the LIS. > > >>> There was a discussion about actually allowing a cell-id as an > > >>> alternate form of location representation, but it was > > decided not to > > > > > >>> do that. A LIS could, of course, construct a location > > reference of > > >>> the form sip:@opco.net, and send that. When > > dereferenced, > > >>> it would return the agreed-upon location. > > >>> > > >>> Brian > > >>> > > >>>> -----Original Message----- > > >>>> From: ecrit-bounces@ietf.org > > >>> [mailto:ecrit-bounces@ietf.org] On Behalf > > >>>> Of James M. Polk > > >>>> Sent: Wednesday, March 05, 2008 2:29 PM > > >>>> To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > > >>>> ecrit@ietf.org > > >>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > >>>> (cell-id) > > >>>> > > >>>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > >>>>> Cell-id is an identifier of a geographical area which > > is mapped to > > > > >>>>> psap already in today's databases. If you'll make an IP based > > >>>>> emergency call on cellular, that will use now and for many > > >>> years to > > >>>>> come the cell-id to select the psap where to direct your > > >>> call. GAbor > > >>>> let's discuss this topic as its own thread. > > >>>> > > >>>> All (not just some or one) of the following questions need to be > > >>>> answered positively and definitively in order for your Cell-id > > >>>> scenario to work in IP. > > >>>> > > >>>> Where is the Cell-id to PSAP URI mapping done? > > >>>> > > >>>> What database has this information? > > >>>> > > >>>> What IP protocol is used to resolve this mapping of Cell-id to > > >>>> (appropriate) PSAP? > > >>>> > > >>>> Where is this IP-based server located? > > >>>> > > >>>> How can LoST be used to discover this? > > >>>> > > >>>> What LCP will give this Cell-id to a phone to include in a > > >>> SIP message? > > >>>> What SIP header is this information placed in? > > >>>> > > >>>> What form does this Cell-id have in the SIP header from the > > >>> previous > > >>>> question? > > >>>> > > >>>> What IETF document(s) specifies this header and Cell-id form? > > >>>> > > >>>> James > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> 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 > > > _______________________________________________ > > > 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 > > > > > > -------------------------------------------------------------- > > ---------- > > ------------------------ > > This message is for the designated recipient only and may contain > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender immediately > > > and delete the original. Any unauthorized use of this email is > > prohibited. > > -------------------------------------------------------------- > > ---------- > > ------------------------ > > [mf2] > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://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 ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 10 16:04:11 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5AC3A6D78; Mon, 10 Mar 2008 16:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.934 X-Spam-Level: X-Spam-Status: No, score=-101.934 tagged_above=-999 required=5 tests=[AWL=-1.541, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFE-6U8WLw2e; Mon, 10 Mar 2008 16:04:10 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2EA73A6D05; Mon, 10 Mar 2008 16:04:08 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA1A3A6813 for ; Mon, 10 Mar 2008 16:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5rIwbB6eP8q for ; Mon, 10 Mar 2008 16:04:04 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id AF5D63A6CDB for ; Mon, 10 Mar 2008 16:04:03 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 10 Mar 2008 16:01:44 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m2AN1hkV006916; Mon, 10 Mar 2008 16:01:43 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id m2AN1cpj007600; Mon, 10 Mar 2008 23:01:38 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 16:01:34 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.124.245]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 16:01:34 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Mar 2008 14:43:52 -0500 To: , , From: "James M. Polk" In-Reply-To: References: <000a01c882b5$bd39c370$d2e8520a@cisco.com> <021201c882d4$58d71f30$6168f444@cis.neustar.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 10 Mar 2008 23:01:34.0682 (UTC) FILETIME=[B00C2BA0:01C88302] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14671; t=1205190103; x=1206054103; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20WGLC=20on=20draft-ietf-ecrit- phonebcp-04=20(cell-id) |Sender:=20; bh=9bMR/OJ+XOPDe9bftr0dVYQQKxOFOwVDDY/ddYqJR8w=; b=SIIn12UD7WJQ4Zf0WCQwKD2R6Xgh+/0+7D0f8Xyj+Ex3A/gygLFbZSVp42 UAO9miaI0788ByYxIxmHzMJaa5yW+WZVIzTgiwoRDq35cwPJI3r7qdWvhFM2 8x77EBdqxuJ1E9djz3UutTZmHIzku9jKiSMW9z8dpvfK+SsNlmLfI=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 01:09 PM 3/10/2008, Gabor.Bajko@nokia.com wrote: >The problem is there. In IMS, the UA needs to include its cell-id into >the P-Access-Network header. If it doesn't know its geolocation (which >is very probable), then there is no other location info included in the >invite. Thus, mapping is done based on the cell-id. this is likely not going to be true. IMS operators don't like the idea of giving location-by-value to a UA, because they see value in this information, because they can change for its use. This is why the *entire* locationURI discussion came about. For SPs that do not want to give the raw location information - that can then be used by competing application services providers for their purposes. If the UA receives a locationURI, the IMS SP is not giving location away, since they can charge for its dereference. Therefore, location will be in SIP Location Conveyance, and about no one (as in zero) have said they aren't going down that document's path. >They will keep doing this regardless of the LoST spec. But this effort >is to harmonize between ietf and 3gpp. If usage of cell-id will be >allowed, then 3gpp would use the protocols as defined in ietf. >Otherwise, they will use it as they think fits better for their needs. Are you involved in the IETF-3GPP talks that have occurred over the past few years? This hasn't been a problem/obstacle in those talks to my knowledge (though I haven't been at every one of them)... >Probably I should have started with this problem statement. I just >assumed noone thinks I am sending all these mails for fun. > >- gabor > >-----Original Message----- >From: ext Brian Rosen [mailto:br@brianrosen.net] >Sent: Monday, March 10, 2008 10:30 AM >To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > >This still seems to me to be a solution in search of a problem. IMS >networks have mechanisms that don't need IETF work to allow a cell id as >a location representation. I don't know of any networks that have this >problem. If there are, please cite them. If there aren't, we don't >need to keep talking about the solution. > >Brian > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Gabor.Bajko@nokia.com > > Sent: Monday, March 10, 2008 10:37 AM > > To: mlinsner@cisco.com > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > Hi Marc, > > > > > 1) There is no guarantee the end host will use the cell operator's > > LoST service (even if known) > > It will, if the LoST server discovery mechanism will provision the > > device with the operator's LoST server. > > > > > 2) If in fact the operator maintains a db of cell-id to psap uri, > > would it not be easier to maintain a db of cell-id to common-use > > location See James W. answer. > > > > We are currently talking about cell-id usage only for emergency > > services. There is no reason to use the VoIP provider's LoST server, > > when you can get the required information (ie psap uri) locally from > > the access provider. > > > > - gabor > > > > -----Original Message----- > > From: ext Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Monday, March 10, 2008 6:51 AM > > To: Bajko Gabor (Nokia-OCTO/MtView) > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > Gabor, > > > > 1) There is no guarantee the end host will use the cell operator's > > LoST service (even if known). The end host may use a LoST service > > associated with it's VoIP provider or Aor domain provider. > > > > 2) If in fact the operator maintains a db of cell-id to psap uri, > > would it not be easier to maintain a db of cell-id to common-use > > location then simply advise the end host of the common-use location? > > (cell-id 123 = 0000 N. Main > > St.) > > > > -Marc- > > > > > > > > > > > > > > The cell-id to psap mapping database one operator has could become > > > the > > > > > LoST server of that operator. When an end device attaches to a > > > cellular network, it learns its cell-id and then it could use LoST > > > to translate its cell-id to the psap uri, as the operator can always > > > > translate its own cell-id to the correct psap uri. There is no need > > > for a global database for this, the operator needs to keep its own > > > database up to date anyways, regardless of the amount of cell-id > > > movement. > > > What is needed is that the operator's (currently existing) database > > > supports LoST and LoST carries cell-id. An extension to the latter > > > one > > > > > could be done, but first lets fix the requirement. All the rest is > > > just reuse of existing staff. > > > > > > - gabor > > > > > > > > > -----Original Message----- > > > From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Thursday, March 06, 2008 2:10 PM > > > To: Richard Barnes; Bajko Gabor (Nokia-OCTO/MtView) > > > Cc: ecrit@ietf.org > > > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > Hi Richard, > > > > > > The Cell-ID is made up of 4 parts: > > > > > > MCC = Mobile Country Code > > > MNC = Mobile Network Code (the operator) LAC = Local Area Code Cell > > > = The number of the cell > > > > > > So with this, it is actually possible to easily work out where the > > > operator is at least to a national level, and who the operator is. > > > The > > > > > other components are assigned by the operator and and would need the > > > > operator to either provide this information to LoST directly, or > > > provide an interface to a specific LoST server to query. > > > > > > Given the operator sensitivity to this information being generally > > > public, and the amount of cell-id movement that goes on, this may > > > actually become quite impractical quite quickly. Some operators I > > > deal with for example have more than 400k cells in just one country. > > > > > > Cheers > > > James > > > > > > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org on behalf of Richard Barnes > > > Sent: Thu 3/6/2008 1:48 PM > > > To: Gabor.Bajko@nokia.com > > > Cc: ecrit@ietf.org > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > Gabor, > > > > > > If I have a cell-id, how do I figure out where that cell is? > > > Is there a well-defined mechanism for doing that over IP? > > > (I'm not trying to be rhetorical here, I just don't know.) > > > > > > My concern with using cell-id as a "pointer" to location in the > > > Internet context is that there may not be a way to dereference that > > > pointer (i.e., obtain the location of the > > > cell) without going outside the Internet, e.g., to a 3GPP non-IP > > > interface or some other database. > > > > > > --Richard > > > > > > > > > > > > > > > > > > Gabor.Bajko@nokia.com wrote: > > > > The cell-id (cgi) is a global, well defined and understood in the > > > > cellular world. There are no interoperability issues with > > > it. If you > > > > think otherwise, please give examples. > > > > > > > > Pidf-lo is an object which encapsulates preexisting location > > > > information but it does not define the format of it. > > > > > > > > - gabor > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > Of ext James M. Polk > > > > Sent: Wednesday, March 05, 2008 2:43 PM > > > > To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; > > > > br@brianrosen.net; ecrit@ietf.org > > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > > (cell-id) > > > > > > > > At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > >> Right. But that means relaxing the requirement "8. section > > > 6.1 "Other > > > > > > >> forms of location representation must be mapped into > > > either a geo or > > > >> civic for use in emergency calls" in the draft and allow > > > other type > > > >> of location information, all those which make sense in > > > their specific > > > > > > >> context. > > > > > > > > I don't understand why you want anything relaxed. The requirement > > > > > says PIDF-LO is the only location format to be used, and that the > > > > is geo or civic. This is a MUST for > > > interoperability > > > > reasons. Cell-id doesn't accomplish this. > > > > > > > > > > > >> Gabor > > > >> > > > >> -----Original Message----- > > > >> From: ext Marc Linsner [mailto:mlinsner@cisco.com] > > > >> Sent: Wednesday, March 05, 2008 12:50 PM > > > >> To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); > > > >> ecrit@ietf.org > > > >> Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > >> (cell-id) > > > >> > > > >> Of course there is no reason the operator couldn't provide civic > > > >> location > > > >> (123 Main St.) in place of cell-id either (verses a geo > > > location). > > > >> The > > > > > > > >> main objective is to have location information in the device such > > > > >> that it makes sense to the consumer vs. every context having > > > >> their own location descriptions (cell-id, water meter number, > > > >> telephone pole id, property tax plat number, fire hydrant > > > >> inventory id, msag address, etc.). > > > >> > > > >> -Marc- > > > >> > > > >>> -----Original Message----- > > > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > > >>> Behalf Of Brian Rosen > > > >>> Sent: Wednesday, March 05, 2008 2:53 PM > > > >>> To: 'James M. Polk'; Gabor.Bajko@nokia.com; > > > >>> Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > > >>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > (cell-id) > > > >>> > > > >>> The basic agreement we have made, in NENA, is that the > > > operator will > > > > > > > >>> agree with the PSAP on a location for the cellid. This > > > could be a > > > >>> point or a polygon. That location will be reported, in PIDF-LO > > > >>> form, from the LIS. > > > >>> There was a discussion about actually allowing a cell-id as an > > > >>> alternate form of location representation, but it was > > > decided not to > > > > > > > >>> do that. A LIS could, of course, construct a location > > > reference of > > > >>> the form sip:@opco.net, and send that. When > > > dereferenced, > > > >>> it would return the agreed-upon location. > > > >>> > > > >>> Brian > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: ecrit-bounces@ietf.org > > > >>> [mailto:ecrit-bounces@ietf.org] On Behalf > > > >>>> Of James M. Polk > > > >>>> Sent: Wednesday, March 05, 2008 2:29 PM > > > >>>> To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > > > >>>> ecrit@ietf.org > > > >>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > >>>> (cell-id) > > > >>>> > > > >>>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > >>>>> Cell-id is an identifier of a geographical area which > > > is mapped to > > > > > > >>>>> psap already in today's databases. If you'll make an IP based > > > >>>>> emergency call on cellular, that will use now and for many > > > >>> years to > > > >>>>> come the cell-id to select the psap where to direct your > > > >>> call. GAbor > > > >>>> let's discuss this topic as its own thread. > > > >>>> > > > >>>> All (not just some or one) of the following questions need to > > > >>>> be answered positively and definitively in order for your > > > >>>> Cell-id scenario to work in IP. > > > >>>> > > > >>>> Where is the Cell-id to PSAP URI mapping done? > > > >>>> > > > >>>> What database has this information? > > > >>>> > > > >>>> What IP protocol is used to resolve this mapping of Cell-id to > > > >>>> (appropriate) PSAP? > > > >>>> > > > >>>> Where is this IP-based server located? > > > >>>> > > > >>>> How can LoST be used to discover this? > > > >>>> > > > >>>> What LCP will give this Cell-id to a phone to include in a > > > >>> SIP message? > > > >>>> What SIP header is this information placed in? > > > >>>> > > > >>>> What form does this Cell-id have in the SIP header from the > > > >>> previous > > > >>>> question? > > > >>>> > > > >>>> What IETF document(s) specifies this header and Cell-id form? > > > >>>> > > > >>>> James > > > >>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> 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 > > > > _______________________________________________ > > > > 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 > > > > > > > > > -------------------------------------------------------------- > > > ---------- > > > ------------------------ > > > This message is for the designated recipient only and may contain > > > privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately > > > > > and delete the original. Any unauthorized use of this email is > > > prohibited. > > > -------------------------------------------------------------- > > > ---------- > > > ------------------------ > > > [mf2] > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://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 ecrit-bounces@ietf.org Mon Mar 10 16:18:30 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 513823A6ACD; Mon, 10 Mar 2008 16:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.514 X-Spam-Level: X-Spam-Status: No, score=-100.514 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6+YZOYU16gR; Mon, 10 Mar 2008 16:18:28 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F943A694E; Mon, 10 Mar 2008 16:18:28 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129F93A67EF for ; Mon, 10 Mar 2008 16:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kz4Jm5ptTmEw for ; Mon, 10 Mar 2008 16:18:23 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 41DDA3A63CA for ; Mon, 10 Mar 2008 16:18:23 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_03_10_18_28_48 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 10 Mar 2008 18:28:48 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Mar 2008 18:16:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 10 Mar 2008 18:16:00 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) Thread-Index: AciDAsA4OFzugZvZT32LgOaN6IUGIAAAb13w References: <000a01c882b5$bd39c370$d2e8520a@cisco.com><021201c882d4$58d71f30$6168f444@cis.neustar.com> From: "Dawson, Martin" To: "James M. Polk" , , , X-OriginalArrivalTime: 10 Mar 2008 23:16:01.0866 (UTC) FILETIME=[B4EDF2A0:01C88304] Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org From my perspective the "entire locationURI discussion" came about because the i2 architecture needed a way for the VPC to obtain location updates without relying on the end device. The "location hiding" aspect emerged later. I still regard the former as the most important driver. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James M. Polk Sent: Tuesday, 11 March 2008 6:44 AM To: Gabor.Bajko@nokia.com; br@brianrosen.net; mlinsner@cisco.com Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) At 01:09 PM 3/10/2008, Gabor.Bajko@nokia.com wrote: >The problem is there. In IMS, the UA needs to include its cell-id into >the P-Access-Network header. If it doesn't know its geolocation (which >is very probable), then there is no other location info included in the >invite. Thus, mapping is done based on the cell-id. this is likely not going to be true. IMS operators don't like the idea of giving location-by-value to a UA, because they see value in this information, because they can change for its use. This is why the *entire* locationURI discussion came about. For SPs that do not want to give the raw location information - that can then be used by competing application services providers for their purposes. If the UA receives a locationURI, the IMS SP is not giving location away, since they can charge for its dereference. Therefore, location will be in SIP Location Conveyance, and about no one (as in zero) have said they aren't going down that document's path. >They will keep doing this regardless of the LoST spec. But this effort >is to harmonize between ietf and 3gpp. If usage of cell-id will be >allowed, then 3gpp would use the protocols as defined in ietf. >Otherwise, they will use it as they think fits better for their needs. Are you involved in the IETF-3GPP talks that have occurred over the past few years? This hasn't been a problem/obstacle in those talks to my knowledge (though I haven't been at every one of them)... >Probably I should have started with this problem statement. I just >assumed noone thinks I am sending all these mails for fun. > >- gabor > >-----Original Message----- >From: ext Brian Rosen [mailto:br@brianrosen.net] >Sent: Monday, March 10, 2008 10:30 AM >To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > >This still seems to me to be a solution in search of a problem. IMS >networks have mechanisms that don't need IETF work to allow a cell id as >a location representation. I don't know of any networks that have this >problem. If there are, please cite them. If there aren't, we don't >need to keep talking about the solution. > >Brian > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Gabor.Bajko@nokia.com > > Sent: Monday, March 10, 2008 10:37 AM > > To: mlinsner@cisco.com > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > Hi Marc, > > > > > 1) There is no guarantee the end host will use the cell operator's > > LoST service (even if known) > > It will, if the LoST server discovery mechanism will provision the > > device with the operator's LoST server. > > > > > 2) If in fact the operator maintains a db of cell-id to psap uri, > > would it not be easier to maintain a db of cell-id to common-use > > location See James W. answer. > > > > We are currently talking about cell-id usage only for emergency > > services. There is no reason to use the VoIP provider's LoST server, > > when you can get the required information (ie psap uri) locally from > > the access provider. > > > > - gabor > > > > -----Original Message----- > > From: ext Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Monday, March 10, 2008 6:51 AM > > To: Bajko Gabor (Nokia-OCTO/MtView) > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > Gabor, > > > > 1) There is no guarantee the end host will use the cell operator's > > LoST service (even if known). The end host may use a LoST service > > associated with it's VoIP provider or Aor domain provider. > > > > 2) If in fact the operator maintains a db of cell-id to psap uri, > > would it not be easier to maintain a db of cell-id to common-use > > location then simply advise the end host of the common-use location? > > (cell-id 123 = 0000 N. Main > > St.) > > > > -Marc- > > > > > > > > > > > > > > The cell-id to psap mapping database one operator has could become > > > the > > > > > LoST server of that operator. When an end device attaches to a > > > cellular network, it learns its cell-id and then it could use LoST > > > to translate its cell-id to the psap uri, as the operator can always > > > > translate its own cell-id to the correct psap uri. There is no need > > > for a global database for this, the operator needs to keep its own > > > database up to date anyways, regardless of the amount of cell-id > > > movement. > > > What is needed is that the operator's (currently existing) database > > > supports LoST and LoST carries cell-id. An extension to the latter > > > one > > > > > could be done, but first lets fix the requirement. All the rest is > > > just reuse of existing staff. > > > > > > - gabor > > > > > > > > > -----Original Message----- > > > From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Thursday, March 06, 2008 2:10 PM > > > To: Richard Barnes; Bajko Gabor (Nokia-OCTO/MtView) > > > Cc: ecrit@ietf.org > > > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > Hi Richard, > > > > > > The Cell-ID is made up of 4 parts: > > > > > > MCC = Mobile Country Code > > > MNC = Mobile Network Code (the operator) LAC = Local Area Code Cell > > > = The number of the cell > > > > > > So with this, it is actually possible to easily work out where the > > > operator is at least to a national level, and who the operator is. > > > The > > > > > other components are assigned by the operator and and would need the > > > > operator to either provide this information to LoST directly, or > > > provide an interface to a specific LoST server to query. > > > > > > Given the operator sensitivity to this information being generally > > > public, and the amount of cell-id movement that goes on, this may > > > actually become quite impractical quite quickly. Some operators I > > > deal with for example have more than 400k cells in just one country. > > > > > > Cheers > > > James > > > > > > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org on behalf of Richard Barnes > > > Sent: Thu 3/6/2008 1:48 PM > > > To: Gabor.Bajko@nokia.com > > > Cc: ecrit@ietf.org > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > Gabor, > > > > > > If I have a cell-id, how do I figure out where that cell is? > > > Is there a well-defined mechanism for doing that over IP? > > > (I'm not trying to be rhetorical here, I just don't know.) > > > > > > My concern with using cell-id as a "pointer" to location in the > > > Internet context is that there may not be a way to dereference that > > > pointer (i.e., obtain the location of the > > > cell) without going outside the Internet, e.g., to a 3GPP non-IP > > > interface or some other database. > > > > > > --Richard > > > > > > > > > > > > > > > > > > Gabor.Bajko@nokia.com wrote: > > > > The cell-id (cgi) is a global, well defined and understood in the > > > > cellular world. There are no interoperability issues with > > > it. If you > > > > think otherwise, please give examples. > > > > > > > > Pidf-lo is an object which encapsulates preexisting location > > > > information but it does not define the format of it. > > > > > > > > - gabor > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > Of ext James M. Polk > > > > Sent: Wednesday, March 05, 2008 2:43 PM > > > > To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; > > > > br@brianrosen.net; ecrit@ietf.org > > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > > (cell-id) > > > > > > > > At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > >> Right. But that means relaxing the requirement "8. section > > > 6.1 "Other > > > > > > >> forms of location representation must be mapped into > > > either a geo or > > > >> civic for use in emergency calls" in the draft and allow > > > other type > > > >> of location information, all those which make sense in > > > their specific > > > > > > >> context. > > > > > > > > I don't understand why you want anything relaxed. The requirement > > > > > says PIDF-LO is the only location format to be used, and that the > > > > is geo or civic. This is a MUST for > > > interoperability > > > > reasons. Cell-id doesn't accomplish this. > > > > > > > > > > > >> Gabor > > > >> > > > >> -----Original Message----- > > > >> From: ext Marc Linsner [mailto:mlinsner@cisco.com] > > > >> Sent: Wednesday, March 05, 2008 12:50 PM > > > >> To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); > > > >> ecrit@ietf.org > > > >> Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > >> (cell-id) > > > >> > > > >> Of course there is no reason the operator couldn't provide civic > > > >> location > > > >> (123 Main St.) in place of cell-id either (verses a geo > > > location). > > > >> The > > > > > > > >> main objective is to have location information in the device such > > > > >> that it makes sense to the consumer vs. every context having > > > >> their own location descriptions (cell-id, water meter number, > > > >> telephone pole id, property tax plat number, fire hydrant > > > >> inventory id, msag address, etc.). > > > >> > > > >> -Marc- > > > >> > > > >>> -----Original Message----- > > > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > > >>> Behalf Of Brian Rosen > > > >>> Sent: Wednesday, March 05, 2008 2:53 PM > > > >>> To: 'James M. Polk'; Gabor.Bajko@nokia.com; > > > >>> Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > > >>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > (cell-id) > > > >>> > > > >>> The basic agreement we have made, in NENA, is that the > > > operator will > > > > > > > >>> agree with the PSAP on a location for the cellid. This > > > could be a > > > >>> point or a polygon. That location will be reported, in PIDF-LO > > > >>> form, from the LIS. > > > >>> There was a discussion about actually allowing a cell-id as an > > > >>> alternate form of location representation, but it was > > > decided not to > > > > > > > >>> do that. A LIS could, of course, construct a location > > > reference of > > > >>> the form sip:@opco.net, and send that. When > > > dereferenced, > > > >>> it would return the agreed-upon location. > > > >>> > > > >>> Brian > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: ecrit-bounces@ietf.org > > > >>> [mailto:ecrit-bounces@ietf.org] On Behalf > > > >>>> Of James M. Polk > > > >>>> Sent: Wednesday, March 05, 2008 2:29 PM > > > >>>> To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > > > >>>> ecrit@ietf.org > > > >>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > >>>> (cell-id) > > > >>>> > > > >>>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > >>>>> Cell-id is an identifier of a geographical area which > > > is mapped to > > > > > > >>>>> psap already in today's databases. If you'll make an IP based > > > >>>>> emergency call on cellular, that will use now and for many > > > >>> years to > > > >>>>> come the cell-id to select the psap where to direct your > > > >>> call. GAbor > > > >>>> let's discuss this topic as its own thread. > > > >>>> > > > >>>> All (not just some or one) of the following questions need to > > > >>>> be answered positively and definitively in order for your > > > >>>> Cell-id scenario to work in IP. > > > >>>> > > > >>>> Where is the Cell-id to PSAP URI mapping done? > > > >>>> > > > >>>> What database has this information? > > > >>>> > > > >>>> What IP protocol is used to resolve this mapping of Cell-id to > > > >>>> (appropriate) PSAP? > > > >>>> > > > >>>> Where is this IP-based server located? > > > >>>> > > > >>>> How can LoST be used to discover this? > > > >>>> > > > >>>> What LCP will give this Cell-id to a phone to include in a > > > >>> SIP message? > > > >>>> What SIP header is this information placed in? > > > >>>> > > > >>>> What form does this Cell-id have in the SIP header from the > > > >>> previous > > > >>>> question? > > > >>>> > > > >>>> What IETF document(s) specifies this header and Cell-id form? > > > >>>> > > > >>>> James > > > >>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> 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 > > > > _______________________________________________ > > > > 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 > > > > > > > > > -------------------------------------------------------------- > > > ---------- > > > ------------------------ > > > This message is for the designated recipient only and may contain > > > privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately > > > > > and delete the original. Any unauthorized use of this email is > > > prohibited. > > > -------------------------------------------------------------- > > > ---------- > > > ------------------------ > > > [mf2] > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://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 ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 10 16:27:20 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7473A67EF; Mon, 10 Mar 2008 16:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.989 X-Spam-Level: X-Spam-Status: No, score=-100.989 tagged_above=-999 required=5 tests=[AWL=-0.552, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEjCMyPM6mkI; Mon, 10 Mar 2008 16:27:18 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 797B128C31E; Mon, 10 Mar 2008 16:26:53 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57C5F3A6BB5 for ; Mon, 10 Mar 2008 16:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMPONycX0lC8 for ; Mon, 10 Mar 2008 16:26:50 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E26B53A67EF for ; Mon, 10 Mar 2008 16:26:49 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 10 Mar 2008 16:24:30 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m2ANOS1H011249; Mon, 10 Mar 2008 16:24:28 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m2ANOOLl014390; Mon, 10 Mar 2008 23:24:28 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 16:24:27 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.124.245]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 16:24:27 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Mar 2008 18:24:25 -0500 To: "Dawson, Martin" , , , From: "James M. Polk" In-Reply-To: References: <000a01c882b5$bd39c370$d2e8520a@cisco.com> <021201c882d4$58d71f30$6168f444@cis.neustar.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 10 Mar 2008 23:24:27.0228 (UTC) FILETIME=[E22611C0:01C88305] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=17429; t=1205191468; x=1206055468; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Ecrit]=20WGLC=20on=20draft-ietf-ecrit- phonebcp-04=20(cell-id) |Sender:=20; bh=j/eCaT8+koxuLIDWLUVaSjodgeqAYnDdjb4KH9DuHN8=; b=E17tHUQPA2QeMFY6i2FUIjgXV7dmnTPlKLu8anP4XAYzyWVWGgBorxZ7dh XCbltcESP40YOvoY1lPfTyBUSybw5UOPCBKxCfBoEMx0KB9llULoRa+b7vQ0 O6I5KmFju5; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Martin We can agree to disagree, and I have no problems with that on this one. I just know when and why it impacted Location Conveyance (as that author), which is where it had to be put, and it had little - if anything - to do with i2. i2 came in later to that discussion. From my perspective, it was all about IMS not wanting to give location to UEs (i.e., UAs or the endpoint) because #1 they didn't trust the endpoint to ever provide valid location information, and #2 they didn't want the endpoint to give location information to the endpoint to use for any other use (specifically for those uses not on their networks they can charge for) At 06:16 PM 3/10/2008, Dawson, Martin wrote: > From my perspective the "entire locationURI discussion" came about >because the i2 architecture needed a way for the VPC to obtain location >updates without relying on the end device. The "location hiding" aspect >emerged later. I still regard the former as the most important driver. > >Cheers, >Martin > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of James M. Polk >Sent: Tuesday, 11 March 2008 6:44 AM >To: Gabor.Bajko@nokia.com; br@brianrosen.net; mlinsner@cisco.com >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > >At 01:09 PM 3/10/2008, Gabor.Bajko@nokia.com wrote: > >The problem is there. In IMS, the UA needs to include its cell-id into > >the P-Access-Network header. If it doesn't know its geolocation (which > >is very probable), then there is no other location info included in the > >invite. Thus, mapping is done based on the cell-id. > >this is likely not going to be true. IMS operators don't like the >idea of giving location-by-value to a UA, because they see value in >this information, because they can change for its use. This is why >the *entire* locationURI discussion came about. For SPs that do not >want to give the raw location information - that can then be used by >competing application services providers for their purposes. If the >UA receives a locationURI, the IMS SP is not giving location away, >since they can charge for its dereference. > >Therefore, location will be in SIP Location Conveyance, and about no >one (as in zero) have said they aren't going down that document's path. > > > >They will keep doing this regardless of the LoST spec. But this effort > >is to harmonize between ietf and 3gpp. If usage of cell-id will be > >allowed, then 3gpp would use the protocols as defined in ietf. > >Otherwise, they will use it as they think fits better for their needs. > >Are you involved in the IETF-3GPP talks that have occurred over the >past few years? This hasn't been a problem/obstacle in those talks >to my knowledge (though I haven't been at every one of them)... > > > >Probably I should have started with this problem statement. I just > >assumed noone thinks I am sending all these mails for fun. > > > >- gabor > > > >-----Original Message----- > >From: ext Brian Rosen [mailto:br@brianrosen.net] > >Sent: Monday, March 10, 2008 10:30 AM > >To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com > >Cc: ecrit@ietf.org > >Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > >This still seems to me to be a solution in search of a problem. IMS > >networks have mechanisms that don't need IETF work to allow a cell id >as > >a location representation. I don't know of any networks that have this > >problem. If there are, please cite them. If there aren't, we don't > >need to keep talking about the solution. > > > >Brian > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >Behalf > > > > > Of Gabor.Bajko@nokia.com > > > Sent: Monday, March 10, 2008 10:37 AM > > > To: mlinsner@cisco.com > > > Cc: ecrit@ietf.org > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > Hi Marc, > > > > > > > 1) There is no guarantee the end host will use the cell operator's > > > LoST service (even if known) > > > It will, if the LoST server discovery mechanism will provision the > > > device with the operator's LoST server. > > > > > > > 2) If in fact the operator maintains a db of cell-id to psap uri, > > > would it not be easier to maintain a db of cell-id to common-use > > > location See James W. answer. > > > > > > We are currently talking about cell-id usage only for emergency > > > services. There is no reason to use the VoIP provider's LoST server, > > > when you can get the required information (ie psap uri) locally from > > > the access provider. > > > > > > - gabor > > > > > > -----Original Message----- > > > From: ext Marc Linsner [mailto:mlinsner@cisco.com] > > > Sent: Monday, March 10, 2008 6:51 AM > > > To: Bajko Gabor (Nokia-OCTO/MtView) > > > Cc: ecrit@ietf.org > > > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id) > > > > > > Gabor, > > > > > > 1) There is no guarantee the end host will use the cell operator's > > > LoST service (even if known). The end host may use a LoST service > > > associated with it's VoIP provider or Aor domain provider. > > > > > > 2) If in fact the operator maintains a db of cell-id to psap uri, > > > would it not be easier to maintain a db of cell-id to common-use > > > location then simply advise the end host of the common-use location? > > > (cell-id 123 = 0000 N. Main > > > St.) > > > > > > -Marc- > > > > > > > > > > > > > > > > > > > > The cell-id to psap mapping database one operator has could become > > > > the > > > > > > > LoST server of that operator. When an end device attaches to a > > > > cellular network, it learns its cell-id and then it could use LoST > > > > to translate its cell-id to the psap uri, as the operator can >always > > > > > > translate its own cell-id to the correct psap uri. There is no >need > > > > for a global database for this, the operator needs to keep its own > > > > database up to date anyways, regardless of the amount of cell-id > > > > movement. > > > > What is needed is that the operator's (currently existing) >database > > > > supports LoST and LoST carries cell-id. An extension to the latter > > > > one > > > > > > > could be done, but first lets fix the requirement. All the rest is > > > > just reuse of existing staff. > > > > > > > > - gabor > > > > > > > > > > > > -----Original Message----- > > > > From: ext Winterbottom, James >[mailto:James.Winterbottom@andrew.com] > > > > Sent: Thursday, March 06, 2008 2:10 PM > > > > To: Richard Barnes; Bajko Gabor (Nokia-OCTO/MtView) > > > > Cc: ecrit@ietf.org > > > > Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 >(cell-id) > > > > > > > > Hi Richard, > > > > > > > > The Cell-ID is made up of 4 parts: > > > > > > > > MCC = Mobile Country Code > > > > MNC = Mobile Network Code (the operator) LAC = Local Area Code >Cell > > > > = The number of the cell > > > > > > > > So with this, it is actually possible to easily work out where the > > > > operator is at least to a national level, and who the operator is. > > > > The > > > > > > > other components are assigned by the operator and and would need >the > > > > > > operator to either provide this information to LoST directly, or > > > > provide an interface to a specific LoST server to query. > > > > > > > > Given the operator sensitivity to this information being generally > > > > public, and the amount of cell-id movement that goes on, this may > > > > actually become quite impractical quite quickly. Some operators I > > > > deal with for example have more than 400k cells in just one >country. > > > > > > > > Cheers > > > > James > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org on behalf of Richard Barnes > > > > Sent: Thu 3/6/2008 1:48 PM > > > > To: Gabor.Bajko@nokia.com > > > > Cc: ecrit@ietf.org > > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 >(cell-id) > > > > > > > > Gabor, > > > > > > > > If I have a cell-id, how do I figure out where that cell is? > > > > Is there a well-defined mechanism for doing that over IP? > > > > (I'm not trying to be rhetorical here, I just don't know.) > > > > > > > > My concern with using cell-id as a "pointer" to location in the > > > > Internet context is that there may not be a way to dereference >that > > > > pointer (i.e., obtain the location of the > > > > cell) without going outside the Internet, e.g., to a 3GPP non-IP > > > > interface or some other database. > > > > > > > > --Richard > > > > > > > > > > > > > > > > > > > > > > > > Gabor.Bajko@nokia.com wrote: > > > > > The cell-id (cgi) is a global, well defined and understood in >the > > > > > cellular world. There are no interoperability issues with > > > > it. If you > > > > > think otherwise, please give examples. > > > > > > > > > > Pidf-lo is an object which encapsulates preexisting location > > > > > information but it does not define the format of it. > > > > > > > > > > - gabor > > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > > > Of ext James M. Polk > > > > > Sent: Wednesday, March 05, 2008 2:43 PM > > > > > To: Bajko Gabor (Nokia-OCTO/MtView); mlinsner@cisco.com; > > > > > br@brianrosen.net; ecrit@ietf.org > > > > > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > > > (cell-id) > > > > > > > > > > At 04:18 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > > >> Right. But that means relaxing the requirement "8. section > > > > 6.1 "Other > > > > > > > > >> forms of location representation must be mapped into > > > > either a geo or > > > > >> civic for use in emergency calls" in the draft and allow > > > > other type > > > > >> of location information, all those which make sense in > > > > their specific > > > > > > > > >> context. > > > > > > > > > > I don't understand why you want anything relaxed. The >requirement > > > > > > > says PIDF-LO is the only location format to be used, and that >the > > > > > is geo or civic. This is a MUST for > > > > interoperability > > > > > reasons. Cell-id doesn't accomplish this. > > > > > > > > > > > > > > >> Gabor > > > > >> > > > > >> -----Original Message----- > > > > >> From: ext Marc Linsner [mailto:mlinsner@cisco.com] > > > > >> Sent: Wednesday, March 05, 2008 12:50 PM > > > > >> To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); > > > > >> ecrit@ietf.org > > > > >> Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > > >> (cell-id) > > > > >> > > > > >> Of course there is no reason the operator couldn't provide >civic > > > > >> location > > > > >> (123 Main St.) in place of cell-id either (verses a geo > > > > location). > > > > >> The > > > > > > > > > >> main objective is to have location information in the device >such > > > > > > >> that it makes sense to the consumer vs. every context having > > > > >> their own location descriptions (cell-id, water meter number, > > > > >> telephone pole id, property tax plat number, fire hydrant > > > > >> inventory id, msag address, etc.). > > > > >> > > > > >> -Marc- > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On > > > > >>> Behalf Of Brian Rosen > > > > >>> Sent: Wednesday, March 05, 2008 2:53 PM > > > > >>> To: 'James M. Polk'; Gabor.Bajko@nokia.com; > > > > >>> Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > > > >>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > > (cell-id) > > > > >>> > > > > >>> The basic agreement we have made, in NENA, is that the > > > > operator will > > > > > > > > > >>> agree with the PSAP on a location for the cellid. This > > > > could be a > > > > >>> point or a polygon. That location will be reported, in >PIDF-LO > > > > >>> form, from the LIS. > > > > >>> There was a discussion about actually allowing a cell-id as an > > > > >>> alternate form of location representation, but it was > > > > decided not to > > > > > > > > > >>> do that. A LIS could, of course, construct a location > > > > reference of > > > > >>> the form sip:@opco.net, and send that. When > > > > dereferenced, > > > > >>> it would return the agreed-upon location. > > > > >>> > > > > >>> Brian > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: ecrit-bounces@ietf.org > > > > >>> [mailto:ecrit-bounces@ietf.org] On Behalf > > > > >>>> Of James M. Polk > > > > >>>> Sent: Wednesday, March 05, 2008 2:29 PM > > > > >>>> To: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; > > > > >>>> ecrit@ietf.org > > > > >>>> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > > > >>>> (cell-id) > > > > >>>> > > > > >>>> At 01:04 PM 3/5/2008, Gabor.Bajko@nokia.com wrote: > > > > >>>>> Cell-id is an identifier of a geographical area which > > > > is mapped to > > > > > > > > >>>>> psap already in today's databases. If you'll make an IP >based > > > > >>>>> emergency call on cellular, that will use now and for many > > > > >>> years to > > > > >>>>> come the cell-id to select the psap where to direct your > > > > >>> call. GAbor > > > > >>>> let's discuss this topic as its own thread. > > > > >>>> > > > > >>>> All (not just some or one) of the following questions need to > > > > >>>> be answered positively and definitively in order for your > > > > >>>> Cell-id scenario to work in IP. > > > > >>>> > > > > >>>> Where is the Cell-id to PSAP URI mapping done? > > > > >>>> > > > > >>>> What database has this information? > > > > >>>> > > > > >>>> What IP protocol is used to resolve this mapping of Cell-id >to > > > > >>>> (appropriate) PSAP? > > > > >>>> > > > > >>>> Where is this IP-based server located? > > > > >>>> > > > > >>>> How can LoST be used to discover this? > > > > >>>> > > > > >>>> What LCP will give this Cell-id to a phone to include in a > > > > >>> SIP message? > > > > >>>> What SIP header is this information placed in? > > > > >>>> > > > > >>>> What form does this Cell-id have in the SIP header from the > > > > >>> previous > > > > >>>> question? > > > > >>>> > > > > >>>> What IETF document(s) specifies this header and Cell-id form? > > > > >>>> > > > > >>>> James > > > > >>>> > > > > >>>> > > > > >>>> _______________________________________________ > > > > >>>> 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 > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > > > -------------------------------------------------------------- > > > > ---------- > > > > ------------------------ > > > > This message is for the designated recipient only and may contain > > > > privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > > immediately > > > > > > > and delete the original. Any unauthorized use of this email is > > > > prohibited. > > > > -------------------------------------------------------------- > > > > ---------- > > > > ------------------------ > > > > [mf2] > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://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 > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 14 06:42:53 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2085628C94F; Fri, 14 Mar 2008 06:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.444 X-Spam-Level: X-Spam-Status: No, score=-100.444 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRjxkcLxMROi; Fri, 14 Mar 2008 06:42:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 224FE3A6F45; Fri, 14 Mar 2008 06:42:52 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 974CD3A69AE for ; Fri, 14 Mar 2008 06:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOSskTSK+X1I for ; Fri, 14 Mar 2008 06:42:49 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 71BDB3A6F5B for ; Fri, 14 Mar 2008 06:42:06 -0700 (PDT) Received: (qmail invoked by alias); 14 Mar 2008 13:39:48 -0000 Received: from dhcp-1438.ietf71.ietf.org (EHLO [130.129.20.56]) [130.129.20.56] by mail.gmx.net (mp019) with SMTP; 14 Mar 2008 14:39:48 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18vYLEuUzEvfG0ocLzJpkODEA2vtV1WEb4LdalcCD r1mcKWFp6uVlod Message-ID: <47DA8026.3020308@gmx.net> Date: Fri, 14 Mar 2008 15:39:50 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: GEOPRIV , ecrit@ietf.org, dime@ietf.org, hokey@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] Friday Chillout X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Who of you is going to be around this evening and is willing to hang around with other IETF folks? Please drop me a note. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 18 10:46:43 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5E228C332; Tue, 18 Mar 2008 10:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.1 X-Spam-Level: X-Spam-Status: No, score=-99.1 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymislTgltZ1Y; Tue, 18 Mar 2008 10:46:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 896A428C667; Tue, 18 Mar 2008 10:46:38 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1FB73A6B55; Tue, 18 Mar 2008 10:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfDUjFWYf5Lb; Tue, 18 Mar 2008 10:46:36 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 7B07E28C5EB; Tue, 18 Mar 2008 10:46:11 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_03_18_12_56_49 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 18 Mar 2008 12:56:49 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Mar 2008 12:43:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Mar 2008 12:43:50 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HELD Implementers mailing list Thread-Index: AciJH6B/XbFVwWEpQXe16mUjf1FqRg== From: "Winterbottom, James" To: "GEOPRIV" , X-OriginalArrivalTime: 18 Mar 2008 17:43:53.0912 (UTC) FILETIME=[A23F7B80:01C8891F] Subject: [Ecrit] HELD Implementers mailing list X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1530475778==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1530475778== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8891F.A21381D8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8891F.A21381D8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All,=0D=0A=0D=0A=20=0D=0A=0D=0AI have created a HELD implementers emaili= ng list, for those people=0D=0Ainterested in, or already implementing HELD.=0D= =0A=0D=0A=20=0D=0A=0D=0AYou can subscribe to the list here:=0D=0A=0D=0Ahttp= s://lists.sourceforge.net/lists/listinfo/held-location-implementers=0D=0A=0D= =0A=20=0D=0A=0D=0ACheers=0D=0A=0D=0AJames=0D=0A=0D=0A=20=0D=0A=0D=0A-------= ---------------------------------------------------------------------------= --------------=0D=0AThis message is for the designated recipient only and m= ay=0D=0Acontain privileged, proprietary, or otherwise private information. = =20=0D=0AIf you have received it in error, please notify the sender=0D=0Aim= mediately and delete the original. Any unauthorized use of=0D=0Athis email= is prohibited.=0D=0A------------------------------------------------------= ------------------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C8891F.A21381D8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =0D=0A=0D=0A
=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'> 

=0D= =0A=0D=0A

I have created a HELD implementers emailin= g list, for those people interested=0D=0Ain, or already implementing HELD.<= o:p>

=0D=0A=0D=0A

 

=0D=0A=0D=0A

You can subscribe= to the list here:

=0D=0A=0D=0A

https://lists.sourceforge.net/lists/listinfo/held-loc= ation-implementers

=0D=0A=0D=0A

 

=0D= =0A=0D=0A

Cheers=

=0D=0A=0D=0A

James

=0D=0A=0D=0A

 

=0D=0A=0D=0A
=0D= =0A=0D=0A


-= ---------------------------------------------------------------------------= --------------------
=0D=0AThis message is for the&n= bsp;designated recipient only and may
=0D=0Acontain&= nbsp;privileged, proprietary, or otherwise private = ;information.  
=0D=0AIf you have received = ;it in error, please notify the sender
=0D= =0Aimmediately and delete the original.  Any&= nbsp;unauthorized use of
=0D=0Athis email is pr= ohibited.
=0D=0A--------------------------------------------------------= ----------------------------------------
=0D=0A[mf2]
=0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01C8891F.A21381D8-- --===============1530475778== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1530475778==-- From ecrit-bounces@ietf.org Tue Mar 18 13:22:30 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 749493A6840; Tue, 18 Mar 2008 13:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.868 X-Spam-Level: X-Spam-Status: No, score=-100.868 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pe9N0N0Pa3vL; Tue, 18 Mar 2008 13:22:29 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 828343A6E2E; Tue, 18 Mar 2008 13:22:29 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 503EC3A6E2E for ; Tue, 18 Mar 2008 13:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Df+oRfW7YCe for ; Tue, 18 Mar 2008 13:22:27 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DB8343A6840 for ; Tue, 18 Mar 2008 13:22:26 -0700 (PDT) Received: (qmail invoked by alias); 18 Mar 2008 20:20:07 -0000 Received: from 85-156-144-15.elisa-mobile.fi (EHLO [85.156.144.15]) [85.156.144.15] by mail.gmx.net (mp003) with SMTP; 18 Mar 2008 21:20:07 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+B7uJWgvmBIpIdEIVClwHwgHsyXjCkPN4rpAtF7f B9AbBsapbCbzbm Message-ID: <47E023F9.8040900@gmx.net> Date: Tue, 18 Mar 2008 22:20:09 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] LoST & U-NAPTR Usage X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi folks, prior to IETF#71 we received a lot of IESG comments and particular one comment from Sam Hartman triggered some discussion. The topic of discussion referred to the way how two pieces of information are matched against each other, namely: 1) the content of the identity information carried in the certificate exchanged as part of a TLS handshake between a LoST client and a LoST server 2) information that is provided as input or obtained as output of the U-NAPTR DNS discovery mechanism. The 2nd mechanism triggered some discussion since the current text in the draft uses the output of the U-NAPTR mechanism for comparison against (1). During the ECRIT session at IETF#71 I asked for an opinion of the working group whether they would like to go for using the a) the input to the U-NAPTR process OR b) the output of the U-NAPTR process to be matched against (1). To illustrate the issue please consider Section 4 of the LoST specification since it provides an example. The complexity of the issue is hidden in the deployment story. There are three deployment cases that need to be considered: Case 1: Pre-Configured URI of the LoST server In this case the LoST client is configured with the LoST server URI and hence there is no need for the U-NAPTR mechanism. Example: https://lostserver.example.com The usage of the SIP config framework is a possible tool for providing this information to the LoST client. Case 2: VoIP provider runs a LoST server and uses U-NAPTR In this case the U-NAPTR mechanism is used and the LoST client is only configured with the domain of it's VoIP provider, here example.com. An example of this configuration can be found in the document: ------------------------------------------------------------------------ example.com. IN NAPTR 100 10 "u" "LoST:https" "!.*!https://lostserver.example.com/secure!" "" IN NAPTR 200 10 "u" "LoST:http" "!.*!http://lostserver.example.com!" "" ------------------------------------------------------------------------ In this case matching the output of the U-NAPTR introduces problems since the translation step from example.com to https://lostserver.example.com/secure is only secure if DNSSEC is used. Without DNSSEC an adversary would be able to intercept the response and provide a different answer back or make use of DNS cache poisioning. Case 3: VoIP provider points to a LoST server and uses U-NAPTR This case is the most likely one based on the current thinking of the deployment models. Here, the VoIP provider itself does not run the LoST server but just points to it using the U-NAPTR mechanism. This might be, for example, the case when enterprises in one state point to a LoST server operated by the government. The following configuration shows this example: ------------------------------------------------------------------------ enterprise-example.com. IN NAPTR 100 10 "u" "LoST:https" "!.*!https://lostserver.state-psap.gov/secure!" "" IN NAPTR 200 10 "u" "LoST:http" "!.*!http://lostserver.state-psap.gov!" "" ------------------------------------------------------------------------ In this case the government operating the LoST server provides their service for a large number of enterprise networks within a particular state. In fact, they might even be unaware of the number of enterprising pointing to their LoST server at a given point in time. Using the output of the U-NAPTR process for comparison against (1) makes a lot of sense in this deployment case. Using the input would require the LoST server operated by the government to have certificates for each of the enterprise networks the LoST server is providing services for. Case 4: DHCP-based Discovery In the DHCP-based discovery the DHCP client is provided with the domain name of the LoST server. Then, the client uses the U-NAPTR mechanism as described above. The considerations of Case 2 and Case 4 apply. The security of the DHCP-based discovery is determined by the level of security provided by DHCP and additionally by the security of the U-NAPTR procedure. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 18 13:29:12 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AA0128C25D; Tue, 18 Mar 2008 13:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.586 X-Spam-Level: X-Spam-Status: No, score=-100.586 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbLj1+m9OR0x; Tue, 18 Mar 2008 13:29:08 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 897AD28C1DA; Tue, 18 Mar 2008 13:29:08 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27BF128C15A for ; Tue, 18 Mar 2008 13:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEnlAwhR1djT for ; Tue, 18 Mar 2008 13:29:06 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E9C9928C190 for ; Tue, 18 Mar 2008 13:29:05 -0700 (PDT) Received: (qmail invoked by alias); 18 Mar 2008 20:26:44 -0000 Received: from 85-156-144-15.elisa-mobile.fi (EHLO [85.156.144.15]) [85.156.144.15] by mail.gmx.net (mp026) with SMTP; 18 Mar 2008 21:26:44 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19/kWtfM55/ZUQxES6Cq/e5atM3RT/oChjLbfz5BS 73aacOD/wLSPzG Message-ID: <47E02587.5000208@gmx.net> Date: Tue, 18 Mar 2008 22:26:47 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] Consensus Call on U-NAPTR usage for LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, I have just distributed a mail about a more detailed description on the usage of U-NAPTR for LoST discovery. During the IETF#71 ECRIT session I asked the group for a hum whether the group wants to use a) the input to the U-NAPTR process OR b) the output of the U-NAPTR process to be matched against the content of the identity information carried in the certificate exchanged as part of a TLS handshake between a LoST client and a LoST server. There was strong consensus in the room for (b), as it is currently defined in the LoST document. This mail aims to confirm that decision on the mailing list. Please post your opinion to the list. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 18 13:47:14 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1C433A689E; Tue, 18 Mar 2008 13:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.518 X-Spam-Level: X-Spam-Status: No, score=-100.518 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzCNyM8qHmSL; Tue, 18 Mar 2008 13:47:06 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B43F728C29A; Tue, 18 Mar 2008 13:47:06 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09BF128C29A for ; Tue, 18 Mar 2008 13:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52Ta3Jj0GuyR for ; Tue, 18 Mar 2008 13:46:54 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id DD07428C15A for ; Tue, 18 Mar 2008 13:46:53 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jbifd-00087M-Q0; Tue, 18 Mar 2008 15:44:30 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , References: <47E023F9.8040900@gmx.net> Date: Tue, 18 Mar 2008 16:44:33 -0400 Message-ID: <045701c88938$e0bdd410$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciJNXbUnVfsSsgdRqWVaThFGwH1EgAAnvhQ In-Reply-To: <47E023F9.8040900@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] LoST & U-NAPTR Usage X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Even in an enterprise environment, the VoIP provider is unlikely to know the best LoST server. The access network provider is much more likely to be able to do that. Consider a telecommuter for example; enterprise = clueless, access (broadband) supplier=likely to have correct data. Doesn't really affect your discussion, although the DHCP case is more likely for that. When we finish this, we probably need words in phonebcp about this, and especially what to do when the access network says one thing and the calling network says another. In the U.S., we're likely to have well behaved LoST servers hooked up to a comprehensive forest guide network, so any LoST server should be able to get you to the right one. That may not be true in other places. The access network is roughly never wrong (because it's local). The calling network may well be, because it doesn't know where you are. Of course if the calling network and the access network are the same entity, it probably doesn't matter. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, March 18, 2008 4:20 PM To: ecrit@ietf.org Subject: [Ecrit] LoST & U-NAPTR Usage Hi folks, prior to IETF#71 we received a lot of IESG comments and particular one comment from Sam Hartman triggered some discussion. The topic of discussion referred to the way how two pieces of information are matched against each other, namely: 1) the content of the identity information carried in the certificate exchanged as part of a TLS handshake between a LoST client and a LoST server 2) information that is provided as input or obtained as output of the U-NAPTR DNS discovery mechanism. The 2nd mechanism triggered some discussion since the current text in the draft uses the output of the U-NAPTR mechanism for comparison against (1). During the ECRIT session at IETF#71 I asked for an opinion of the working group whether they would like to go for using the a) the input to the U-NAPTR process OR b) the output of the U-NAPTR process to be matched against (1). To illustrate the issue please consider Section 4 of the LoST specification since it provides an example. The complexity of the issue is hidden in the deployment story. There are three deployment cases that need to be considered: Case 1: Pre-Configured URI of the LoST server In this case the LoST client is configured with the LoST server URI and hence there is no need for the U-NAPTR mechanism. Example: https://lostserver.example.com The usage of the SIP config framework is a possible tool for providing this information to the LoST client. Case 2: VoIP provider runs a LoST server and uses U-NAPTR In this case the U-NAPTR mechanism is used and the LoST client is only configured with the domain of it's VoIP provider, here example.com. An example of this configuration can be found in the document: ------------------------------------------------------------------------ example.com. IN NAPTR 100 10 "u" "LoST:https" "!.*!https://lostserver.example.com/secure!" "" IN NAPTR 200 10 "u" "LoST:http" "!.*!http://lostserver.example.com!" "" ------------------------------------------------------------------------ In this case matching the output of the U-NAPTR introduces problems since the translation step from example.com to https://lostserver.example.com/secure is only secure if DNSSEC is used. Without DNSSEC an adversary would be able to intercept the response and provide a different answer back or make use of DNS cache poisioning. Case 3: VoIP provider points to a LoST server and uses U-NAPTR This case is the most likely one based on the current thinking of the deployment models. Here, the VoIP provider itself does not run the LoST server but just points to it using the U-NAPTR mechanism. This might be, for example, the case when enterprises in one state point to a LoST server operated by the government. The following configuration shows this example: ------------------------------------------------------------------------ enterprise-example.com. IN NAPTR 100 10 "u" "LoST:https" "!.*!https://lostserver.state-psap.gov/secure!" "" IN NAPTR 200 10 "u" "LoST:http" "!.*!http://lostserver.state-psap.gov!" "" ------------------------------------------------------------------------ In this case the government operating the LoST server provides their service for a large number of enterprise networks within a particular state. In fact, they might even be unaware of the number of enterprising pointing to their LoST server at a given point in time. Using the output of the U-NAPTR process for comparison against (1) makes a lot of sense in this deployment case. Using the input would require the LoST server operated by the government to have certificates for each of the enterprise networks the LoST server is providing services for. Case 4: DHCP-based Discovery In the DHCP-based discovery the DHCP client is provided with the domain name of the LoST server. Then, the client uses the U-NAPTR mechanism as described above. The considerations of Case 2 and Case 4 apply. The security of the DHCP-based discovery is determined by the level of security provided by DHCP and additionally by the security of the U-NAPTR procedure. 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 ecrit-bounces@ietf.org Tue Mar 18 13:50:18 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D20CC3A6A56; Tue, 18 Mar 2008 13:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.816 X-Spam-Level: X-Spam-Status: No, score=-99.816 tagged_above=-999 required=5 tests=[AWL=0.621, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Z1qO7+FzaqX; Tue, 18 Mar 2008 13:50:17 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B904228C15A; Tue, 18 Mar 2008 13:50:17 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3997328C144 for ; Tue, 18 Mar 2008 13:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRii2BX5Udhv for ; Tue, 18 Mar 2008 13:50:15 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 122A93A6812 for ; Tue, 18 Mar 2008 13:50:15 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_03_18_16_00_53 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 18 Mar 2008 16:00:52 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Mar 2008 15:47:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Mar 2008 15:47:57 -0500 Message-ID: In-Reply-To: <045701c88938$e0bdd410$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST & U-NAPTR Usage Thread-Index: AciJNXbUnVfsSsgdRqWVaThFGwH1EgAAnvhQAABOrfA= References: <47E023F9.8040900@gmx.net> <045701c88938$e0bdd410$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Hannes Tschofenig" , X-OriginalArrivalTime: 18 Mar 2008 20:47:56.0655 (UTC) FILETIME=[583C57F0:01C88939] Subject: Re: [Ecrit] LoST & U-NAPTR Usage X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Actually I think for the enterprise case you will just have a hard-coded LoST server in your calling client. This does of course assume that LoST servers are widely deployed and have a good peering relationship going. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Wednesday, 19 March 2008 7:45 AM > To: 'Hannes Tschofenig'; ecrit@ietf.org > Subject: Re: [Ecrit] LoST & U-NAPTR Usage > > Even in an enterprise environment, the VoIP provider is unlikely to know > the > best LoST server. The access network provider is much more likely to be > able to do that. Consider a telecommuter for example; enterprise = > clueless, access (broadband) supplier=likely to have correct data. > > Doesn't really affect your discussion, although the DHCP case is more > likely > for that. When we finish this, we probably need words in phonebcp about > this, and especially what to do when the access network says one thing and > the calling network says another. In the U.S., we're likely to have well > behaved LoST servers hooked up to a comprehensive forest guide network, so > any LoST server should be able to get you to the right one. That may not > be > true in other places. The access network is roughly never wrong (because > it's local). The calling network may well be, because it doesn't know > where > you are. > > Of course if the calling network and the access network are the same > entity, > it probably doesn't matter. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Tuesday, March 18, 2008 4:20 PM > To: ecrit@ietf.org > Subject: [Ecrit] LoST & U-NAPTR Usage > > Hi folks, > > prior to IETF#71 we received a lot of IESG comments and particular one > comment from Sam Hartman triggered some discussion. The topic of > discussion referred to the way how two pieces of information are matched > against each other, namely: > 1) the content of the identity information carried in the certificate > exchanged as part of a TLS handshake between a LoST client and a LoST > server > 2) information that is provided as input or obtained as output of the > U-NAPTR DNS discovery mechanism. > > The 2nd mechanism triggered some discussion since the current text in > the draft uses the output of the U-NAPTR mechanism for comparison > against (1). > > During the ECRIT session at IETF#71 I asked for an opinion of the > working group whether they would like to go for using the > a) the input to the U-NAPTR process OR > b) the output of the U-NAPTR process > to be matched against (1). > > To illustrate the issue please consider Section 4 of the LoST > specification since it provides an example. > > The complexity of the issue is hidden in the deployment story. There are > three deployment cases that need to be considered: > > Case 1: Pre-Configured URI of the LoST server > > In this case the LoST client is configured with the LoST server URI and > hence there is no need for the U-NAPTR mechanism. > > Example: https://lostserver.example.com > > The usage of the SIP config framework is a possible tool for providing > this information to the LoST client. > > Case 2: VoIP provider runs a LoST server and uses U-NAPTR > > In this case the U-NAPTR mechanism is used and the LoST client is only > configured with the domain of it's VoIP provider, here > example.com. An example of this configuration can be found in the > document: > > ------------------------------------------------------------------------ > > example.com. > > IN NAPTR 100 10 "u" "LoST:https" > "!.*!https://lostserver.example.com/secure!" "" > > IN NAPTR 200 10 "u" "LoST:http" > "!.*!http://lostserver.example.com!" "" > > > ------------------------------------------------------------------------ > > In this case matching the output of the U-NAPTR introduces problems > since the translation step from example.com to > https://lostserver.example.com/secure is only secure if DNSSEC is used. > Without DNSSEC an adversary would be able to intercept the response and > provide a different answer back or make use of DNS cache poisioning. > > > > Case 3: VoIP provider points to a LoST server and uses U-NAPTR > > This case is the most likely one based on the current thinking of the > deployment models. Here, the VoIP provider itself does not run the LoST > server but just points to it using the U-NAPTR mechanism. This might be, > for example, the case when enterprises in one state point to a LoST > server operated by the government. > > The following configuration shows this example: > > ------------------------------------------------------------------------ > > enterprise-example.com. > > IN NAPTR 100 10 "u" "LoST:https" > "!.*!https://lostserver.state-psap.gov/secure!" "" > > IN NAPTR 200 10 "u" "LoST:http" > "!.*!http://lostserver.state-psap.gov!" "" > > > ------------------------------------------------------------------------ > > In this case the government operating the LoST server provides their > service for a large number of enterprise networks within a particular > state. In fact, they might even be unaware of the number of enterprising > pointing to their LoST server at a given point in time. > > Using the output of the U-NAPTR process for comparison against (1) makes > a lot of sense in this deployment case. Using the input would require > the LoST server operated by the government to have certificates for each > of the enterprise networks the LoST server is providing services for. > > Case 4: DHCP-based Discovery > > In the DHCP-based discovery the DHCP client is provided with the domain > name of the LoST server. Then, the client uses the U-NAPTR mechanism as > described above. The considerations of Case 2 and Case 4 apply. > > The security of the DHCP-based discovery is determined by the level of > security provided by DHCP and additionally by the security of the > U-NAPTR procedure. > > > 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 ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 18 14:10:33 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DECF28C61D; Tue, 18 Mar 2008 14:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.532 X-Spam-Level: X-Spam-Status: No, score=-100.532 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Nd5LEn5U82Y; Tue, 18 Mar 2008 14:10:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9C7B28C637; Tue, 18 Mar 2008 14:10:31 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B352228C61D for ; Tue, 18 Mar 2008 14:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9n6yqWUn6io for ; Tue, 18 Mar 2008 14:10:29 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id B5CDC28C5B4 for ; Tue, 18 Mar 2008 14:10:28 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jbj2S-0001zG-Oj; Tue, 18 Mar 2008 16:08:05 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Hannes Tschofenig'" , References: <47E023F9.8040900@gmx.net> <045701c88938$e0bdd410$640fa8c0@cis.neustar.com> Date: Tue, 18 Mar 2008 17:08:08 -0400 Message-ID: <047201c8893c$2c336d30$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciJNXbUnVfsSsgdRqWVaThFGwH1EgAAnvhQAABOrfAAAK7NsA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] LoST & U-NAPTR Usage X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is the question I'm raising. Suppose you have an enterprise client and you take it to Paris (or Sierra Leone). Your hardwired LoST server is likely wrong. You MAY be able to follow the forest guides to the right server, but maybe not. If the access network gave you a LoST server via DHCP, you should probably use that in preference to your configured server in the client. Brian -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Tuesday, March 18, 2008 4:48 PM To: Brian Rosen; Hannes Tschofenig; ecrit@ietf.org Subject: RE: [Ecrit] LoST & U-NAPTR Usage Actually I think for the enterprise case you will just have a hard-coded LoST server in your calling client. This does of course assume that LoST servers are widely deployed and have a good peering relationship going. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Wednesday, 19 March 2008 7:45 AM > To: 'Hannes Tschofenig'; ecrit@ietf.org > Subject: Re: [Ecrit] LoST & U-NAPTR Usage > > Even in an enterprise environment, the VoIP provider is unlikely to know > the > best LoST server. The access network provider is much more likely to be > able to do that. Consider a telecommuter for example; enterprise = > clueless, access (broadband) supplier=likely to have correct data. > > Doesn't really affect your discussion, although the DHCP case is more > likely > for that. When we finish this, we probably need words in phonebcp about > this, and especially what to do when the access network says one thing and > the calling network says another. In the U.S., we're likely to have well > behaved LoST servers hooked up to a comprehensive forest guide network, so > any LoST server should be able to get you to the right one. That may not > be > true in other places. The access network is roughly never wrong (because > it's local). The calling network may well be, because it doesn't know > where > you are. > > Of course if the calling network and the access network are the same > entity, > it probably doesn't matter. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Tuesday, March 18, 2008 4:20 PM > To: ecrit@ietf.org > Subject: [Ecrit] LoST & U-NAPTR Usage > > Hi folks, > > prior to IETF#71 we received a lot of IESG comments and particular one > comment from Sam Hartman triggered some discussion. The topic of > discussion referred to the way how two pieces of information are matched > against each other, namely: > 1) the content of the identity information carried in the certificate > exchanged as part of a TLS handshake between a LoST client and a LoST > server > 2) information that is provided as input or obtained as output of the > U-NAPTR DNS discovery mechanism. > > The 2nd mechanism triggered some discussion since the current text in > the draft uses the output of the U-NAPTR mechanism for comparison > against (1). > > During the ECRIT session at IETF#71 I asked for an opinion of the > working group whether they would like to go for using the > a) the input to the U-NAPTR process OR > b) the output of the U-NAPTR process > to be matched against (1). > > To illustrate the issue please consider Section 4 of the LoST > specification since it provides an example. > > The complexity of the issue is hidden in the deployment story. There are > three deployment cases that need to be considered: > > Case 1: Pre-Configured URI of the LoST server > > In this case the LoST client is configured with the LoST server URI and > hence there is no need for the U-NAPTR mechanism. > > Example: https://lostserver.example.com > > The usage of the SIP config framework is a possible tool for providing > this information to the LoST client. > > Case 2: VoIP provider runs a LoST server and uses U-NAPTR > > In this case the U-NAPTR mechanism is used and the LoST client is only > configured with the domain of it's VoIP provider, here > example.com. An example of this configuration can be found in the > document: > > ------------------------------------------------------------------------ > > example.com. > > IN NAPTR 100 10 "u" "LoST:https" > "!.*!https://lostserver.example.com/secure!" "" > > IN NAPTR 200 10 "u" "LoST:http" > "!.*!http://lostserver.example.com!" "" > > > ------------------------------------------------------------------------ > > In this case matching the output of the U-NAPTR introduces problems > since the translation step from example.com to > https://lostserver.example.com/secure is only secure if DNSSEC is used. > Without DNSSEC an adversary would be able to intercept the response and > provide a different answer back or make use of DNS cache poisioning. > > > > Case 3: VoIP provider points to a LoST server and uses U-NAPTR > > This case is the most likely one based on the current thinking of the > deployment models. Here, the VoIP provider itself does not run the LoST > server but just points to it using the U-NAPTR mechanism. This might be, > for example, the case when enterprises in one state point to a LoST > server operated by the government. > > The following configuration shows this example: > > ------------------------------------------------------------------------ > > enterprise-example.com. > > IN NAPTR 100 10 "u" "LoST:https" > "!.*!https://lostserver.state-psap.gov/secure!" "" > > IN NAPTR 200 10 "u" "LoST:http" > "!.*!http://lostserver.state-psap.gov!" "" > > > ------------------------------------------------------------------------ > > In this case the government operating the LoST server provides their > service for a large number of enterprise networks within a particular > state. In fact, they might even be unaware of the number of enterprising > pointing to their LoST server at a given point in time. > > Using the output of the U-NAPTR process for comparison against (1) makes > a lot of sense in this deployment case. Using the input would require > the LoST server operated by the government to have certificates for each > of the enterprise networks the LoST server is providing services for. > > Case 4: DHCP-based Discovery > > In the DHCP-based discovery the DHCP client is provided with the domain > name of the LoST server. Then, the client uses the U-NAPTR mechanism as > described above. The considerations of Case 2 and Case 4 apply. > > The security of the DHCP-based discovery is determined by the level of > security provided by DHCP and additionally by the security of the > U-NAPTR procedure. > > > 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 ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 18 14:24:23 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1537E28C541; Tue, 18 Mar 2008 14:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.927 X-Spam-Level: X-Spam-Status: No, score=-99.927 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjrsCOynUpHE; Tue, 18 Mar 2008 14:24:21 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C573728C578; Tue, 18 Mar 2008 14:24:21 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 060F828C1DA for ; Tue, 18 Mar 2008 14:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pognkASx7tOA for ; Tue, 18 Mar 2008 14:24:19 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 9309028C332 for ; Tue, 18 Mar 2008 14:24:18 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_03_18_16_34_55 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 18 Mar 2008 16:34:55 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Mar 2008 16:21:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Mar 2008 16:21:57 -0500 Message-ID: In-Reply-To: <047201c8893c$2c336d30$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST & U-NAPTR Usage Thread-Index: AciJNXbUnVfsSsgdRqWVaThFGwH1EgAAnvhQAABOrfAAAK7NsAAAM/jg References: <47E023F9.8040900@gmx.net> <045701c88938$e0bdd410$640fa8c0@cis.neustar.com> <047201c8893c$2c336d30$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Hannes Tschofenig" , X-OriginalArrivalTime: 18 Mar 2008 21:21:59.0230 (UTC) FILETIME=[19B48DE0:01C8893E] Subject: Re: [Ecrit] LoST & U-NAPTR Usage X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Okay you have forced me to go and read LoST. Good thing too, because in the introduction there is talk about PIDL-LO profile. Maybe I have it wrong, but I thought that it was the LoST server that would talk to the FG, and not the end-device. In this way I could get some degree of transitive trust across the network between the FGs and the various LoST servers that contained the service mappings I was after. It is definitely true that the a relatively good mesh of FGs to LoST servers has to exist for this to work. However, if the VSP in Sierra Leone is going to check that your destination URI is really that of a PSAP, then this mesh will have to exist anyway. Of course if the VSP is going to pass the call in any event, then simply providing the PSAP URI directly over the LCP works just was well.... ;) (okay bait off now). Cheers James > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, 19 March 2008 8:08 AM > To: Winterbottom, James; 'Hannes Tschofenig'; ecrit@ietf.org > Subject: RE: [Ecrit] LoST & U-NAPTR Usage > > This is the question I'm raising. > > Suppose you have an enterprise client and you take it to Paris (or Sierra > Leone). Your hardwired LoST server is likely wrong. You MAY be able to > follow the forest guides to the right server, but maybe not. If the > access > network gave you a LoST server via DHCP, you should probably use that in > preference to your configured server in the client. > > Brian > > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Tuesday, March 18, 2008 4:48 PM > To: Brian Rosen; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] LoST & U-NAPTR Usage > > Actually I think for the enterprise case you will just have a hard-coded > LoST server in your calling client. This does of course assume that LoST > servers are widely deployed and have a good peering relationship going. > > Cheers > James > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Brian Rosen > > Sent: Wednesday, 19 March 2008 7:45 AM > > To: 'Hannes Tschofenig'; ecrit@ietf.org > > Subject: Re: [Ecrit] LoST & U-NAPTR Usage > > > > Even in an enterprise environment, the VoIP provider is unlikely to > know > > the > > best LoST server. The access network provider is much more likely to > be > > able to do that. Consider a telecommuter for example; enterprise = > > clueless, access (broadband) supplier=likely to have correct data. > > > > Doesn't really affect your discussion, although the DHCP case is more > > likely > > for that. When we finish this, we probably need words in phonebcp > about > > this, and especially what to do when the access network says one thing > and > > the calling network says another. In the U.S., we're likely to have > well > > behaved LoST servers hooked up to a comprehensive forest guide > network, so > > any LoST server should be able to get you to the right one. That may > not > > be > > true in other places. The access network is roughly never wrong > (because > > it's local). The calling network may well be, because it doesn't know > > where > > you are. > > > > Of course if the calling network and the access network are the same > > entity, > > it probably doesn't matter. > > > > Brian > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Hannes Tschofenig > > Sent: Tuesday, March 18, 2008 4:20 PM > > To: ecrit@ietf.org > > Subject: [Ecrit] LoST & U-NAPTR Usage > > > > Hi folks, > > > > prior to IETF#71 we received a lot of IESG comments and particular one > > comment from Sam Hartman triggered some discussion. The topic of > > discussion referred to the way how two pieces of information are > matched > > against each other, namely: > > 1) the content of the identity information carried in the certificate > > exchanged as part of a TLS handshake between a LoST client and a LoST > > server > > 2) information that is provided as input or obtained as output of the > > U-NAPTR DNS discovery mechanism. > > > > The 2nd mechanism triggered some discussion since the current text in > > the draft uses the output of the U-NAPTR mechanism for comparison > > against (1). > > > > During the ECRIT session at IETF#71 I asked for an opinion of the > > working group whether they would like to go for using the > > a) the input to the U-NAPTR process OR > > b) the output of the U-NAPTR process > > to be matched against (1). > > > > To illustrate the issue please consider Section 4 of the LoST > > specification since it provides an example. > > > > The complexity of the issue is hidden in the deployment story. There > are > > three deployment cases that need to be considered: > > > > Case 1: Pre-Configured URI of the LoST server > > > > In this case the LoST client is configured with the LoST server URI > and > > hence there is no need for the U-NAPTR mechanism. > > > > Example: https://lostserver.example.com > > > > The usage of the SIP config framework is a possible tool for providing > > this information to the LoST client. > > > > Case 2: VoIP provider runs a LoST server and uses U-NAPTR > > > > In this case the U-NAPTR mechanism is used and the LoST client is only > > configured with the domain of it's VoIP provider, here > > example.com. An example of this configuration can be found in the > > document: > > > > > ------------------------------------------------------------------------ > > > > example.com. > > > > IN NAPTR 100 10 "u" "LoST:https" > > "!.*!https://lostserver.example.com/secure!" "" > > > > IN NAPTR 200 10 "u" "LoST:http" > > "!.*!http://lostserver.example.com!" "" > > > > > > > ------------------------------------------------------------------------ > > > > In this case matching the output of the U-NAPTR introduces problems > > since the translation step from example.com to > > https://lostserver.example.com/secure is only secure if DNSSEC is > used. > > Without DNSSEC an adversary would be able to intercept the response > and > > provide a different answer back or make use of DNS cache poisioning. > > > > > > > > Case 3: VoIP provider points to a LoST server and uses U-NAPTR > > > > This case is the most likely one based on the current thinking of the > > deployment models. Here, the VoIP provider itself does not run the > LoST > > server but just points to it using the U-NAPTR mechanism. This might > be, > > for example, the case when enterprises in one state point to a LoST > > server operated by the government. > > > > The following configuration shows this example: > > > > > ------------------------------------------------------------------------ > > > > enterprise-example.com. > > > > IN NAPTR 100 10 "u" "LoST:https" > > "!.*!https://lostserver.state-psap.gov/secure!" "" > > > > IN NAPTR 200 10 "u" "LoST:http" > > "!.*!http://lostserver.state-psap.gov!" "" > > > > > > > ------------------------------------------------------------------------ > > > > In this case the government operating the LoST server provides their > > service for a large number of enterprise networks within a particular > > state. In fact, they might even be unaware of the number of > enterprising > > pointing to their LoST server at a given point in time. > > > > Using the output of the U-NAPTR process for comparison against (1) > makes > > a lot of sense in this deployment case. Using the input would require > > the LoST server operated by the government to have certificates for > each > > of the enterprise networks the LoST server is providing services for. > > > > Case 4: DHCP-based Discovery > > > > In the DHCP-based discovery the DHCP client is provided with the > domain > > name of the LoST server. Then, the client uses the U-NAPTR mechanism > as > > described above. The considerations of Case 2 and Case 4 apply. > > > > The security of the DHCP-based discovery is determined by the level of > > security provided by DHCP and additionally by the security of the > > U-NAPTR procedure. > > > > > > 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 > > ------------------------------------------------------------------------ -- > -- > -------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > -- > -------------------- > [mf2] > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 18 14:39:55 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D77253A6AFB; Tue, 18 Mar 2008 14:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.542 X-Spam-Level: X-Spam-Status: No, score=-100.542 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLYJn5k88LSb; Tue, 18 Mar 2008 14:39:54 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D8CD3A6C90; Tue, 18 Mar 2008 14:39:54 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1D8828C1CD for ; Tue, 18 Mar 2008 14:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1nKbBzxDMKl for ; Tue, 18 Mar 2008 14:39:52 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 4620F3A6AFB for ; Tue, 18 Mar 2008 14:39:52 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JbjUu-00054i-AY; Tue, 18 Mar 2008 16:37:28 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Hannes Tschofenig'" , References: <47E023F9.8040900@gmx.net> <045701c88938$e0bdd410$640fa8c0@cis.neustar.com> <047201c8893c$2c336d30$640fa8c0@cis.neustar.com> Date: Tue, 18 Mar 2008 17:37:31 -0400 Message-ID: <047301c88940$4778f200$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciJNXbUnVfsSsgdRqWVaThFGwH1EgAAnvhQAABOrfAAAK7NsAAAM/jgAACvHMA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] LoST & U-NAPTR Usage X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yeah, I assume it's the server that consults the FG. If the server you are directed to is well connected, you won't have a problem. I worry about things going wrong. In theory, if all countries have FGs, and they are interconnected, no problem. But, is that a reasonable assumption? Wouldn't it be better if we advised the access network to provide a local service, and suggest that the client of the LoST server use that server, rather than what the VoIP network provides? I would think that would work better. Brian -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Tuesday, March 18, 2008 5:22 PM To: Brian Rosen; Hannes Tschofenig; ecrit@ietf.org Subject: RE: [Ecrit] LoST & U-NAPTR Usage Okay you have forced me to go and read LoST. Good thing too, because in the introduction there is talk about PIDL-LO profile. Maybe I have it wrong, but I thought that it was the LoST server that would talk to the FG, and not the end-device. In this way I could get some degree of transitive trust across the network between the FGs and the various LoST servers that contained the service mappings I was after. It is definitely true that the a relatively good mesh of FGs to LoST servers has to exist for this to work. However, if the VSP in Sierra Leone is going to check that your destination URI is really that of a PSAP, then this mesh will have to exist anyway. Of course if the VSP is going to pass the call in any event, then simply providing the PSAP URI directly over the LCP works just was well.... ;) (okay bait off now). Cheers James > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, 19 March 2008 8:08 AM > To: Winterbottom, James; 'Hannes Tschofenig'; ecrit@ietf.org > Subject: RE: [Ecrit] LoST & U-NAPTR Usage > > This is the question I'm raising. > > Suppose you have an enterprise client and you take it to Paris (or Sierra > Leone). Your hardwired LoST server is likely wrong. You MAY be able to > follow the forest guides to the right server, but maybe not. If the > access > network gave you a LoST server via DHCP, you should probably use that in > preference to your configured server in the client. > > Brian > > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Tuesday, March 18, 2008 4:48 PM > To: Brian Rosen; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] LoST & U-NAPTR Usage > > Actually I think for the enterprise case you will just have a hard-coded > LoST server in your calling client. This does of course assume that LoST > servers are widely deployed and have a good peering relationship going. > > Cheers > James > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Brian Rosen > > Sent: Wednesday, 19 March 2008 7:45 AM > > To: 'Hannes Tschofenig'; ecrit@ietf.org > > Subject: Re: [Ecrit] LoST & U-NAPTR Usage > > > > Even in an enterprise environment, the VoIP provider is unlikely to > know > > the > > best LoST server. The access network provider is much more likely to > be > > able to do that. Consider a telecommuter for example; enterprise = > > clueless, access (broadband) supplier=likely to have correct data. > > > > Doesn't really affect your discussion, although the DHCP case is more > > likely > > for that. When we finish this, we probably need words in phonebcp > about > > this, and especially what to do when the access network says one thing > and > > the calling network says another. In the U.S., we're likely to have > well > > behaved LoST servers hooked up to a comprehensive forest guide > network, so > > any LoST server should be able to get you to the right one. That may > not > > be > > true in other places. The access network is roughly never wrong > (because > > it's local). The calling network may well be, because it doesn't know > > where > > you are. > > > > Of course if the calling network and the access network are the same > > entity, > > it probably doesn't matter. > > > > Brian > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Hannes Tschofenig > > Sent: Tuesday, March 18, 2008 4:20 PM > > To: ecrit@ietf.org > > Subject: [Ecrit] LoST & U-NAPTR Usage > > > > Hi folks, > > > > prior to IETF#71 we received a lot of IESG comments and particular one > > comment from Sam Hartman triggered some discussion. The topic of > > discussion referred to the way how two pieces of information are > matched > > against each other, namely: > > 1) the content of the identity information carried in the certificate > > exchanged as part of a TLS handshake between a LoST client and a LoST > > server > > 2) information that is provided as input or obtained as output of the > > U-NAPTR DNS discovery mechanism. > > > > The 2nd mechanism triggered some discussion since the current text in > > the draft uses the output of the U-NAPTR mechanism for comparison > > against (1). > > > > During the ECRIT session at IETF#71 I asked for an opinion of the > > working group whether they would like to go for using the > > a) the input to the U-NAPTR process OR > > b) the output of the U-NAPTR process > > to be matched against (1). > > > > To illustrate the issue please consider Section 4 of the LoST > > specification since it provides an example. > > > > The complexity of the issue is hidden in the deployment story. There > are > > three deployment cases that need to be considered: > > > > Case 1: Pre-Configured URI of the LoST server > > > > In this case the LoST client is configured with the LoST server URI > and > > hence there is no need for the U-NAPTR mechanism. > > > > Example: https://lostserver.example.com > > > > The usage of the SIP config framework is a possible tool for providing > > this information to the LoST client. > > > > Case 2: VoIP provider runs a LoST server and uses U-NAPTR > > > > In this case the U-NAPTR mechanism is used and the LoST client is only > > configured with the domain of it's VoIP provider, here > > example.com. An example of this configuration can be found in the > > document: > > > > > ------------------------------------------------------------------------ > > > > example.com. > > > > IN NAPTR 100 10 "u" "LoST:https" > > "!.*!https://lostserver.example.com/secure!" "" > > > > IN NAPTR 200 10 "u" "LoST:http" > > "!.*!http://lostserver.example.com!" "" > > > > > > > ------------------------------------------------------------------------ > > > > In this case matching the output of the U-NAPTR introduces problems > > since the translation step from example.com to > > https://lostserver.example.com/secure is only secure if DNSSEC is > used. > > Without DNSSEC an adversary would be able to intercept the response > and > > provide a different answer back or make use of DNS cache poisioning. > > > > > > > > Case 3: VoIP provider points to a LoST server and uses U-NAPTR > > > > This case is the most likely one based on the current thinking of the > > deployment models. Here, the VoIP provider itself does not run the > LoST > > server but just points to it using the U-NAPTR mechanism. This might > be, > > for example, the case when enterprises in one state point to a LoST > > server operated by the government. > > > > The following configuration shows this example: > > > > > ------------------------------------------------------------------------ > > > > enterprise-example.com. > > > > IN NAPTR 100 10 "u" "LoST:https" > > "!.*!https://lostserver.state-psap.gov/secure!" "" > > > > IN NAPTR 200 10 "u" "LoST:http" > > "!.*!http://lostserver.state-psap.gov!" "" > > > > > > > ------------------------------------------------------------------------ > > > > In this case the government operating the LoST server provides their > > service for a large number of enterprise networks within a particular > > state. In fact, they might even be unaware of the number of > enterprising > > pointing to their LoST server at a given point in time. > > > > Using the output of the U-NAPTR process for comparison against (1) > makes > > a lot of sense in this deployment case. Using the input would require > > the LoST server operated by the government to have certificates for > each > > of the enterprise networks the LoST server is providing services for. > > > > Case 4: DHCP-based Discovery > > > > In the DHCP-based discovery the DHCP client is provided with the > domain > > name of the LoST server. Then, the client uses the U-NAPTR mechanism > as > > described above. The considerations of Case 2 and Case 4 apply. > > > > The security of the DHCP-based discovery is determined by the level of > > security provided by DHCP and additionally by the security of the > > U-NAPTR procedure. > > > > > > 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 > > ------------------------------------------------------------------------ -- > -- > -------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > -- > -------------------- > [mf2] > ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 18 16:08:54 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 016BA28C5D5; Tue, 18 Mar 2008 16:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.514 X-Spam-Level: X-Spam-Status: No, score=-100.514 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsJOT2Xl2dlG; Tue, 18 Mar 2008 16:08:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609EF3A6C19; Tue, 18 Mar 2008 16:08:52 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AB1B3A6C19 for ; Tue, 18 Mar 2008 16:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRvKjgmj4rPZ for ; Tue, 18 Mar 2008 16:08:49 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id D770C3A6A1B for ; Tue, 18 Mar 2008 16:08:48 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_03_18_18_19_22 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 18 Mar 2008 18:19:22 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Mar 2008 18:06:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Mar 2008 18:06:22 -0500 Message-ID: In-Reply-To: <047301c88940$4778f200$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST & U-NAPTR Usage Thread-Index: AciJNXbUnVfsSsgdRqWVaThFGwH1EgAAnvhQAABOrfAAAK7NsAAAM/jgAACvHMAAAyqScA== References: <47E023F9.8040900@gmx.net><045701c88938$e0bdd410$640fa8c0@cis.neustar.com><047201c8893c$2c336d30$640fa8c0@cis.neustar.com> <047301c88940$4778f200$640fa8c0@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , "Winterbottom, James" , "Hannes Tschofenig" , X-OriginalArrivalTime: 18 Mar 2008 23:06:26.0892 (UTC) FILETIME=[B185E0C0:01C8894C] Subject: Re: [Ecrit] LoST & U-NAPTR Usage X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I definitely agree. As with the LIS, a reliable and readily implementable discovery process needs to exist that access networks of all descriptions can implement consistently. LoST has to be implemented on a local basis because by definition it provides a local service. Having decided to implement LoST, local jurisdictions will have much more control over the reliability of the service if there is no assumed dependency on some global web of relationships. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, 19 March 2008 8:38 AM To: Winterbottom, James; 'Hannes Tschofenig'; ecrit@ietf.org Subject: Re: [Ecrit] LoST & U-NAPTR Usage Yeah, I assume it's the server that consults the FG. If the server you are directed to is well connected, you won't have a problem. I worry about things going wrong. In theory, if all countries have FGs, and they are interconnected, no problem. But, is that a reasonable assumption? Wouldn't it be better if we advised the access network to provide a local service, and suggest that the client of the LoST server use that server, rather than what the VoIP network provides? I would think that would work better. Brian -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Tuesday, March 18, 2008 5:22 PM To: Brian Rosen; Hannes Tschofenig; ecrit@ietf.org Subject: RE: [Ecrit] LoST & U-NAPTR Usage Okay you have forced me to go and read LoST. Good thing too, because in the introduction there is talk about PIDL-LO profile. Maybe I have it wrong, but I thought that it was the LoST server that would talk to the FG, and not the end-device. In this way I could get some degree of transitive trust across the network between the FGs and the various LoST servers that contained the service mappings I was after. It is definitely true that the a relatively good mesh of FGs to LoST servers has to exist for this to work. However, if the VSP in Sierra Leone is going to check that your destination URI is really that of a PSAP, then this mesh will have to exist anyway. Of course if the VSP is going to pass the call in any event, then simply providing the PSAP URI directly over the LCP works just was well.... ;) (okay bait off now). Cheers James > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, 19 March 2008 8:08 AM > To: Winterbottom, James; 'Hannes Tschofenig'; ecrit@ietf.org > Subject: RE: [Ecrit] LoST & U-NAPTR Usage > > This is the question I'm raising. > > Suppose you have an enterprise client and you take it to Paris (or Sierra > Leone). Your hardwired LoST server is likely wrong. You MAY be able to > follow the forest guides to the right server, but maybe not. If the > access > network gave you a LoST server via DHCP, you should probably use that in > preference to your configured server in the client. > > Brian > > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Tuesday, March 18, 2008 4:48 PM > To: Brian Rosen; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] LoST & U-NAPTR Usage > > Actually I think for the enterprise case you will just have a hard-coded > LoST server in your calling client. This does of course assume that LoST > servers are widely deployed and have a good peering relationship going. > > Cheers > James > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Brian Rosen > > Sent: Wednesday, 19 March 2008 7:45 AM > > To: 'Hannes Tschofenig'; ecrit@ietf.org > > Subject: Re: [Ecrit] LoST & U-NAPTR Usage > > > > Even in an enterprise environment, the VoIP provider is unlikely to > know > > the > > best LoST server. The access network provider is much more likely to > be > > able to do that. Consider a telecommuter for example; enterprise = > > clueless, access (broadband) supplier=likely to have correct data. > > > > Doesn't really affect your discussion, although the DHCP case is more > > likely > > for that. When we finish this, we probably need words in phonebcp > about > > this, and especially what to do when the access network says one thing > and > > the calling network says another. In the U.S., we're likely to have > well > > behaved LoST servers hooked up to a comprehensive forest guide > network, so > > any LoST server should be able to get you to the right one. That may > not > > be > > true in other places. The access network is roughly never wrong > (because > > it's local). The calling network may well be, because it doesn't know > > where > > you are. > > > > Of course if the calling network and the access network are the same > > entity, > > it probably doesn't matter. > > > > Brian > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Hannes Tschofenig > > Sent: Tuesday, March 18, 2008 4:20 PM > > To: ecrit@ietf.org > > Subject: [Ecrit] LoST & U-NAPTR Usage > > > > Hi folks, > > > > prior to IETF#71 we received a lot of IESG comments and particular one > > comment from Sam Hartman triggered some discussion. The topic of > > discussion referred to the way how two pieces of information are > matched > > against each other, namely: > > 1) the content of the identity information carried in the certificate > > exchanged as part of a TLS handshake between a LoST client and a LoST > > server > > 2) information that is provided as input or obtained as output of the > > U-NAPTR DNS discovery mechanism. > > > > The 2nd mechanism triggered some discussion since the current text in > > the draft uses the output of the U-NAPTR mechanism for comparison > > against (1). > > > > During the ECRIT session at IETF#71 I asked for an opinion of the > > working group whether they would like to go for using the > > a) the input to the U-NAPTR process OR > > b) the output of the U-NAPTR process > > to be matched against (1). > > > > To illustrate the issue please consider Section 4 of the LoST > > specification since it provides an example. > > > > The complexity of the issue is hidden in the deployment story. There > are > > three deployment cases that need to be considered: > > > > Case 1: Pre-Configured URI of the LoST server > > > > In this case the LoST client is configured with the LoST server URI > and > > hence there is no need for the U-NAPTR mechanism. > > > > Example: https://lostserver.example.com > > > > The usage of the SIP config framework is a possible tool for providing > > this information to the LoST client. > > > > Case 2: VoIP provider runs a LoST server and uses U-NAPTR > > > > In this case the U-NAPTR mechanism is used and the LoST client is only > > configured with the domain of it's VoIP provider, here > > example.com. An example of this configuration can be found in the > > document: > > > > > ------------------------------------------------------------------------ > > > > example.com. > > > > IN NAPTR 100 10 "u" "LoST:https" > > "!.*!https://lostserver.example.com/secure!" "" > > > > IN NAPTR 200 10 "u" "LoST:http" > > "!.*!http://lostserver.example.com!" "" > > > > > > > ------------------------------------------------------------------------ > > > > In this case matching the output of the U-NAPTR introduces problems > > since the translation step from example.com to > > https://lostserver.example.com/secure is only secure if DNSSEC is > used. > > Without DNSSEC an adversary would be able to intercept the response > and > > provide a different answer back or make use of DNS cache poisioning. > > > > > > > > Case 3: VoIP provider points to a LoST server and uses U-NAPTR > > > > This case is the most likely one based on the current thinking of the > > deployment models. Here, the VoIP provider itself does not run the > LoST > > server but just points to it using the U-NAPTR mechanism. This might > be, > > for example, the case when enterprises in one state point to a LoST > > server operated by the government. > > > > The following configuration shows this example: > > > > > ------------------------------------------------------------------------ > > > > enterprise-example.com. > > > > IN NAPTR 100 10 "u" "LoST:https" > > "!.*!https://lostserver.state-psap.gov/secure!" "" > > > > IN NAPTR 200 10 "u" "LoST:http" > > "!.*!http://lostserver.state-psap.gov!" "" > > > > > > > ------------------------------------------------------------------------ > > > > In this case the government operating the LoST server provides their > > service for a large number of enterprise networks within a particular > > state. In fact, they might even be unaware of the number of > enterprising > > pointing to their LoST server at a given point in time. > > > > Using the output of the U-NAPTR process for comparison against (1) > makes > > a lot of sense in this deployment case. Using the input would require > > the LoST server operated by the government to have certificates for > each > > of the enterprise networks the LoST server is providing services for. > > > > Case 4: DHCP-based Discovery > > > > In the DHCP-based discovery the DHCP client is provided with the > domain > > name of the LoST server. Then, the client uses the U-NAPTR mechanism > as > > described above. The considerations of Case 2 and Case 4 apply. > > > > The security of the DHCP-based discovery is determined by the level of > > security provided by DHCP and additionally by the security of the > > U-NAPTR procedure. > > > > > > 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 > > ------------------------------------------------------------------------ -- > -- > -------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > -- > -------------------- > [mf2] > ------------------------------------------------------------------------ ---- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ---- -------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 18 20:09:05 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 955F33A6BF1; Tue, 18 Mar 2008 20:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.228 X-Spam-Level: X-Spam-Status: No, score=-101.228 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0D5OYKlwINP; Tue, 18 Mar 2008 20:09:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5DE23A67F3; Tue, 18 Mar 2008 20:09:04 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90DCF3A67F3 for ; Tue, 18 Mar 2008 20:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJFeAyheE2SO for ; Tue, 18 Mar 2008 20:09:02 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 9B3883A67A9 for ; Tue, 18 Mar 2008 20:09:02 -0700 (PDT) Received: from [192.168.0.57] (pool-70-21-180-58.nwrk.east.verizon.net [70.21.180.58]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m2J36fN9018429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 18 Mar 2008 23:06:42 -0400 (EDT) Message-Id: <86855082-62C8-466E-8CEC-4D632036CF7B@cs.columbia.edu> From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <045701c88938$e0bdd410$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 18 Mar 2008 23:06:41 -0400 References: <47E023F9.8040900@gmx.net> <045701c88938$e0bdd410$640fa8c0@cis.neustar.com> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Cc: ecrit@ietf.org Subject: Re: [Ecrit] LoST & U-NAPTR Usage X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Practically speaking, we need to support a number of options, given that not all enterprises or WiFi access networks will support LoST servers next year. Many home Linksys boxes will never be upgraded to contain DHCP information for LoST servers. VoIP providers are probably going to be the earliest adopters, simply because they have an incentive and have traditionally been held responsible for emergency calls, fairly or not. Thus, you need a reasonable set of alternatives, probably starting with DHCP (most likely to be local), followed by SIP configuration (also often local and avoids UNAPTR problems, and already supports network and provider configuration, but obviously not finished yet and somewhat complicated) and last, UNAPTR for the SIP domain name (easiest to deploy). Henning On Mar 18, 2008, at 4:44 PM, Brian Rosen wrote: > Even in an enterprise environment, the VoIP provider is unlikely to > know the > best LoST server. The access network provider is much more likely > to be > able to do that. Consider a telecommuter for example; enterprise = > clueless, access (broadband) supplier=likely to have correct data. > > Doesn't really affect your discussion, although the DHCP case is > more likely > for that. When we finish this, we probably need words in phonebcp > about > this, and especially what to do when the access network says one > thing and > the calling network says another. In the U.S., we're likely to have > well > behaved LoST servers hooked up to a comprehensive forest guide > network, so > any LoST server should be able to get you to the right one. That > may not be > true in other places. The access network is roughly never wrong > (because > it's local). The calling network may well be, because it doesn't > know where > you are. > > Of course if the calling network and the access network are the same > entity, > it probably doesn't matter. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 19 02:34:31 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18BCE3A6D31; Wed, 19 Mar 2008 02:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoMfJDqXO3Z0; Wed, 19 Mar 2008 02:34:29 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C32003A6B41; Wed, 19 Mar 2008 02:34:29 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58C193A6A79 for ; Wed, 19 Mar 2008 02:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYTih8ZJrgto for ; Wed, 19 Mar 2008 02:34:25 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 366A43A6B41 for ; Wed, 19 Mar 2008 02:34:25 -0700 (PDT) Received: (qmail invoked by alias); 19 Mar 2008 09:32:06 -0000 Received: from 84-230-123-105.elisa-mobile.fi (EHLO [84.230.123.105]) [84.230.123.105] by mail.gmx.net (mp047) with SMTP; 19 Mar 2008 10:32:06 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/4PWVk7fr4zbvqcWjnk/Z49vLl1xNaj9o7Jt7T7P 360oDeCnMiU/Ym Message-ID: <47E0DD97.6090603@gmx.net> Date: Wed, 19 Mar 2008 11:32:07 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Brian Rosen References: <47E023F9.8040900@gmx.net> <045701c88938$e0bdd410$640fa8c0@cis.neustar.com> <047201c8893c$2c336d30$640fa8c0@cis.neustar.com> In-Reply-To: <047201c8893c$2c336d30$640fa8c0@cis.neustar.com> X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: [Ecrit] LoST & U-NAPTR Usage: The important Issue X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Brian, James, Martin, Henning, Hi all, there are certainly challenging issues about the ability to incrementally deploy LoST and whether it is easier to deploy FGs or local LoST servers. This is all very interesting (and as Henning says there are good reasons for having all these mechanisms) BUT *** that's not really what the DISCUSS by Sam Hartman and now Pasi Eronen is about ***. Regardless whether you use DHCP (and then U-NAPTR) or U-NAPTR directly there is this issue about security. Hence, the most important topic for our discussion is what to compare the content of the certificate with. There are only two choices: The input or the output of the U-NAPTR mechanism Currently, we are using the output of the U-NAPTR procedure and compare it with the cert. This has the nice property that the entity that operates the LoST server does not need to know all the enterprise networks, VoIP provider, etc. that point to it. This is case 3 in my summary. There are, however, disadvantages with respect to security. Hence, there is a clear tradeoff between security vulnerability and simplicity of deployment. That's what we should come to a conclusion on. Ciao Hannes Brian Rosen wrote: > This is the question I'm raising. > > Suppose you have an enterprise client and you take it to Paris (or Sierra > Leone). Your hardwired LoST server is likely wrong. You MAY be able to > follow the forest guides to the right server, but maybe not. If the access > network gave you a LoST server via DHCP, you should probably use that in > preference to your configured server in the client. > > Brian > > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Tuesday, March 18, 2008 4:48 PM > To: Brian Rosen; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] LoST & U-NAPTR Usage > > Actually I think for the enterprise case you will just have a hard-coded > LoST server in your calling client. This does of course assume that LoST > servers are widely deployed and have a good peering relationship going. > > Cheers > James > > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> > Of > >> Brian Rosen >> Sent: Wednesday, 19 March 2008 7:45 AM >> To: 'Hannes Tschofenig'; ecrit@ietf.org >> Subject: Re: [Ecrit] LoST & U-NAPTR Usage >> >> Even in an enterprise environment, the VoIP provider is unlikely to >> > know > >> the >> best LoST server. The access network provider is much more likely to >> > be > >> able to do that. Consider a telecommuter for example; enterprise = >> clueless, access (broadband) supplier=likely to have correct data. >> >> Doesn't really affect your discussion, although the DHCP case is more >> likely >> for that. When we finish this, we probably need words in phonebcp >> > about > >> this, and especially what to do when the access network says one thing >> > and > >> the calling network says another. In the U.S., we're likely to have >> > well > >> behaved LoST servers hooked up to a comprehensive forest guide >> > network, so > >> any LoST server should be able to get you to the right one. That may >> > not > >> be >> true in other places. The access network is roughly never wrong >> > (because > >> it's local). The calling network may well be, because it doesn't know >> where >> you are. >> >> Of course if the calling network and the access network are the same >> entity, >> it probably doesn't matter. >> >> Brian >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> > Of > >> Hannes Tschofenig >> Sent: Tuesday, March 18, 2008 4:20 PM >> To: ecrit@ietf.org >> Subject: [Ecrit] LoST & U-NAPTR Usage >> >> Hi folks, >> >> prior to IETF#71 we received a lot of IESG comments and particular one >> comment from Sam Hartman triggered some discussion. The topic of >> discussion referred to the way how two pieces of information are >> > matched > >> against each other, namely: >> 1) the content of the identity information carried in the certificate >> exchanged as part of a TLS handshake between a LoST client and a LoST >> server >> 2) information that is provided as input or obtained as output of the >> U-NAPTR DNS discovery mechanism. >> >> The 2nd mechanism triggered some discussion since the current text in >> the draft uses the output of the U-NAPTR mechanism for comparison >> against (1). >> >> During the ECRIT session at IETF#71 I asked for an opinion of the >> working group whether they would like to go for using the >> a) the input to the U-NAPTR process OR >> b) the output of the U-NAPTR process >> to be matched against (1). >> >> To illustrate the issue please consider Section 4 of the LoST >> specification since it provides an example. >> >> The complexity of the issue is hidden in the deployment story. There >> > are > >> three deployment cases that need to be considered: >> >> Case 1: Pre-Configured URI of the LoST server >> >> In this case the LoST client is configured with the LoST server URI >> > and > >> hence there is no need for the U-NAPTR mechanism. >> >> Example: https://lostserver.example.com >> >> The usage of the SIP config framework is a possible tool for providing >> this information to the LoST client. >> >> Case 2: VoIP provider runs a LoST server and uses U-NAPTR >> >> In this case the U-NAPTR mechanism is used and the LoST client is only >> configured with the domain of it's VoIP provider, here >> example.com. An example of this configuration can be found in the >> document: >> >> >> > ------------------------------------------------------------------------ > >> example.com. >> >> IN NAPTR 100 10 "u" "LoST:https" >> "!.*!https://lostserver.example.com/secure!" "" >> >> IN NAPTR 200 10 "u" "LoST:http" >> "!.*!http://lostserver.example.com!" "" >> >> >> >> > ------------------------------------------------------------------------ > >> In this case matching the output of the U-NAPTR introduces problems >> since the translation step from example.com to >> https://lostserver.example.com/secure is only secure if DNSSEC is >> > used. > >> Without DNSSEC an adversary would be able to intercept the response >> > and > >> provide a different answer back or make use of DNS cache poisioning. >> >> >> >> Case 3: VoIP provider points to a LoST server and uses U-NAPTR >> >> This case is the most likely one based on the current thinking of the >> deployment models. Here, the VoIP provider itself does not run the >> > LoST > >> server but just points to it using the U-NAPTR mechanism. This might >> > be, > >> for example, the case when enterprises in one state point to a LoST >> server operated by the government. >> >> The following configuration shows this example: >> >> >> > ------------------------------------------------------------------------ > >> enterprise-example.com. >> >> IN NAPTR 100 10 "u" "LoST:https" >> "!.*!https://lostserver.state-psap.gov/secure!" "" >> >> IN NAPTR 200 10 "u" "LoST:http" >> "!.*!http://lostserver.state-psap.gov!" "" >> >> >> >> > ------------------------------------------------------------------------ > >> In this case the government operating the LoST server provides their >> service for a large number of enterprise networks within a particular >> state. In fact, they might even be unaware of the number of >> > enterprising > >> pointing to their LoST server at a given point in time. >> >> Using the output of the U-NAPTR process for comparison against (1) >> > makes > >> a lot of sense in this deployment case. Using the input would require >> the LoST server operated by the government to have certificates for >> > each > >> of the enterprise networks the LoST server is providing services for. >> >> Case 4: DHCP-based Discovery >> >> In the DHCP-based discovery the DHCP client is provided with the >> > domain > >> name of the LoST server. Then, the client uses the U-NAPTR mechanism >> > as > >> described above. The considerations of Case 2 and Case 4 apply. >> >> The security of the DHCP-based discovery is determined by the level of >> security provided by DHCP and additionally by the security of the >> U-NAPTR procedure. >> >> >> 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 >> > > ---------------------------------------------------------------------------- > -------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------------- > -------------------- > [mf2] > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 19 04:39:11 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18DAE3A6A04; Wed, 19 Mar 2008 04:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.555 X-Spam-Level: X-Spam-Status: No, score=-100.555 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GN38GwcrQRfq; Wed, 19 Mar 2008 04:39:10 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 568FB28C399; Wed, 19 Mar 2008 04:39:10 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73AC03A67F2 for ; Wed, 19 Mar 2008 04:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MOO6PQUUqdY for ; Wed, 19 Mar 2008 04:39:08 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 61B493A6A04 for ; Wed, 19 Mar 2008 04:39:08 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jbwb9-0003Us-0Y; Wed, 19 Mar 2008 06:36:47 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , References: <47E02587.5000208@gmx.net> Date: Wed, 19 Mar 2008 07:36:47 -0400 Message-ID: <054501c889b5$85dd2e10$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciJNmXY7T8XFYEdTmCGdn9QkrQRYQAfxNTw In-Reply-To: <47E02587.5000208@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Consensus Call on U-NAPTR usage for LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Output, please Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, March 18, 2008 4:27 PM To: ecrit@ietf.org Subject: [Ecrit] Consensus Call on U-NAPTR usage for LoST Hi all, I have just distributed a mail about a more detailed description on the usage of U-NAPTR for LoST discovery. During the IETF#71 ECRIT session I asked the group for a hum whether the group wants to use a) the input to the U-NAPTR process OR b) the output of the U-NAPTR process to be matched against the content of the identity information carried in the certificate exchanged as part of a TLS handshake between a LoST client and a LoST server. There was strong consensus in the room for (b), as it is currently defined in the LoST document. This mail aims to confirm that decision on the mailing list. Please post your opinion to the list. 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 ecrit-bounces@ietf.org Wed Mar 19 07:42:50 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AD413A6A5B; Wed, 19 Mar 2008 07:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.518 X-Spam-Level: X-Spam-Status: No, score=-101.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ok039Umxkpmx; Wed, 19 Mar 2008 07:42:43 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CB0D3A6D90; Wed, 19 Mar 2008 07:42:43 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4342028C1E7 for ; Wed, 19 Mar 2008 07:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdSnaDDaXETV for ; Wed, 19 Mar 2008 07:42:34 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id 6877B3A6A5B for ; Wed, 19 Mar 2008 07:42:34 -0700 (PDT) Received: from [10.8.0.10] ([::ffff:192.136.136.120]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 19 Mar 2008 10:40:15 -0400 id 015A06D1.47E125D0.0000030D Message-Id: From: Andrew Newton To: Hannes Tschofenig In-Reply-To: <47E02587.5000208@gmx.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 19 Mar 2008 10:40:15 -0400 References: <47E02587.5000208@gmx.net> X-Mailer: Apple Mail (2.919.2) Cc: ecrit@ietf.org Subject: Re: [Ecrit] Consensus Call on U-NAPTR usage for LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This does not take into account how the input data was acquired. If it was acquired via DHCP, it could already be compromised. This means that both options have security problems. Therefore, the difference between these two options is that (a) will restrict the deployment options. So I hum for (b). -andy On Mar 18, 2008, at 4:26 PM, Hannes Tschofenig wrote: > Hi all, > > I have just distributed a mail about a more detailed description on > the > usage of U-NAPTR for LoST discovery. > > During the IETF#71 ECRIT session I asked the group for a hum whether > the > group wants to use > a) the input to the U-NAPTR process OR > b) the output of the U-NAPTR process > to be matched against the content of the identity information > carried in > the certificate exchanged as part of a TLS handshake between a LoST > client and a LoST server. > > There was strong consensus in the room for (b), as it is currently > defined in the LoST document. > > This mail aims to confirm that decision on the mailing list. Please > post > your opinion to the list. > > 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 ecrit-bounces@ietf.org Wed Mar 19 07:45:33 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53ED128C5B4; Wed, 19 Mar 2008 07:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.06 X-Spam-Level: X-Spam-Status: No, score=-100.06 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aU-EA10DheZ6; Wed, 19 Mar 2008 07:45:29 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A16E3A6B9F; Wed, 19 Mar 2008 07:45:29 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 503F028C4CC for ; Wed, 19 Mar 2008 07:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dAQ-NZHhK4R for ; Wed, 19 Mar 2008 07:45:26 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id B740628C5A1 for ; Wed, 19 Mar 2008 07:45:22 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_03_19_09_56_00 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 19 Mar 2008 09:56:00 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Mar 2008 09:43:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Mar 2008 09:43:03 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Consensus Call on U-NAPTR usage for LoST Thread-Index: AciJzzJ63t5cpJXsQES2s/Uhwdy5IwAAEzDQ References: <47E02587.5000208@gmx.net> From: "Winterbottom, James" To: "Andrew Newton" , "Hannes Tschofenig" X-OriginalArrivalTime: 19 Mar 2008 14:43:04.0104 (UTC) FILETIME=[89ABEA80:01C889CF] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Consensus Call on U-NAPTR usage for LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I hum for b) as well! > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Andrew Newton > Sent: Thursday, 20 March 2008 1:40 AM > To: Hannes Tschofenig > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Consensus Call on U-NAPTR usage for LoST > > This does not take into account how the input data was acquired. If > it was acquired via DHCP, it could already be compromised. This means > that both options have security problems. Therefore, the difference > between these two options is that (a) will restrict the deployment > options. So I hum for (b). > > -andy > > On Mar 18, 2008, at 4:26 PM, Hannes Tschofenig wrote: > > > Hi all, > > > > I have just distributed a mail about a more detailed description on > > the > > usage of U-NAPTR for LoST discovery. > > > > During the IETF#71 ECRIT session I asked the group for a hum whether > > the > > group wants to use > > a) the input to the U-NAPTR process OR > > b) the output of the U-NAPTR process > > to be matched against the content of the identity information > > carried in > > the certificate exchanged as part of a TLS handshake between a LoST > > client and a LoST server. > > > > There was strong consensus in the room for (b), as it is currently > > defined in the LoST document. > > > > This mail aims to confirm that decision on the mailing list. Please > > post > > your opinion to the list. > > > > 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 ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 19 09:44:48 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA3F928C4E9; Wed, 19 Mar 2008 09:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.964 X-Spam-Level: X-Spam-Status: No, score=-100.964 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0SB-lk75PGj; Wed, 19 Mar 2008 09:44:47 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB1CB3A697D; Wed, 19 Mar 2008 09:44:47 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9FA428C1E9 for ; Wed, 19 Mar 2008 09:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zjXetYzN4Ae for ; Wed, 19 Mar 2008 09:44:37 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 69EC128C1CA for ; Wed, 19 Mar 2008 09:44:37 -0700 (PDT) Received: from [128.59.20.159] (irt-af.cs.columbia.edu [128.59.20.159]) (user=agf2104 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m2JGgGxX015430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 19 Mar 2008 12:42:19 -0400 (EDT) Message-ID: <47E142E5.6060402@cs.columbia.edu> Date: Wed, 19 Mar 2008 12:44:21 -0400 From: "Andrea G. Forte" User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: ecrit@ietf.org X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Subject: [Ecrit] LoST Extensions draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Dear all, I just wanted to let you know that I have just submitted a new draft for your consideration. Looking forward to your feedback. Filename: draft-forte-ecrit-lost-extensions Revision: 00 Title: Location-to-Service Translation Protocol (LoST) Extensions Creation_date: 2008-03-19 WG ID: Independent Submission Number_of_pages: 11 Abstract: An important class of location-based services answer the question "What instances of this service are closest to me?" Examples include finding restaurants, gas stations, stores, automated teller machines, wireless access points (hot spots) or parking spaces. Currently, the Location-to-Service Translation (LoST) protocol only supports mapping locations to a single service based on service regions. This document describes an extension that allows queries "N nearest" and "within distance X". URL: https://datatracker.ietf.org/drafts/draft-forte-ecrit-lost-extensions/ -Andrea -- http://www.cs.columbia.edu/~andreaf/ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 19 11:29:31 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 705FF3A6EBA; Wed, 19 Mar 2008 11:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.228 X-Spam-Level: X-Spam-Status: No, score=-101.228 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uPRXfPdl+6w; Wed, 19 Mar 2008 11:29:30 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AEFA28C2CC; Wed, 19 Mar 2008 11:29:30 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 303CD3A68BB for ; Wed, 19 Mar 2008 11:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JA-661TkZnUJ for ; Wed, 19 Mar 2008 11:29:24 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 63E433A6F76 for ; Wed, 19 Mar 2008 11:29:12 -0700 (PDT) Received: from dyn-160-39-253-76.dyn.columbia.edu (dyn-160-39-253-76.dyn.columbia.edu [160.39.253.76]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m2JIQsd9010718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 19 Mar 2008 14:26:54 -0400 (EDT) Message-Id: <4DF40D8B-1794-44B2-A695-E7EC4635AD21@cs.columbia.edu> From: Henning Schulzrinne To: ECRIT In-Reply-To: <47E142E5.6060402@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 19 Mar 2008 14:26:56 -0400 References: <47E142E5.6060402@cs.columbia.edu> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Subject: Re: [Ecrit] LoST Extensions draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I should add that we don't expect this to become part of ECRIT charter, but since there isn't really another obvious home for this, we chose this WG for now. The goal of the draft is to illustrate that it is relatively straightforward to extend LoST to handle other types of services. Some of these may well even be useful for emergency coordination ("what are all hospitals in a 50 mile radius?"). Henning On Mar 19, 2008, at 12:44 PM, Andrea G. Forte wrote: > Dear all, > > I just wanted to let you know that I have just submitted a new draft > for > your consideration. > Looking forward to your feedback. > > Filename: draft-forte-ecrit-lost-extensions > Revision: 00 > Title: Location-to-Service Translation Protocol (LoST) Extensions > Creation_date: 2008-03-19 > WG ID: Independent Submission > Number_of_pages: 11 > > Abstract: > An important class of location-based services answer the question > "What instances of this service are closest to me?" Examples include > finding restaurants, gas stations, stores, automated teller machines, > wireless access points (hot spots) or parking spaces. Currently, the > Location-to-Service Translation (LoST) protocol only supports mapping > locations to a single service based on service regions. This > document describes an extension that allows queries "N nearest" and > "within distance X". > > > URL: https://datatracker.ietf.org/drafts/draft-forte-ecrit-lost-extensions/ > > -Andrea > > -- > > http://www.cs.columbia.edu/~andreaf/ > > > _______________________________________________ > 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 ecrit-bounces@ietf.org Wed Mar 19 14:27:58 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E418928C127; Wed, 19 Mar 2008 14:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.82 X-Spam-Level: X-Spam-Status: No, score=-100.82 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAO-dtpBw4Sa; Wed, 19 Mar 2008 14:27:58 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 141663A68AC; Wed, 19 Mar 2008 14:27:58 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C4F53A67B7 for ; Wed, 19 Mar 2008 14:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lY8sZwAHtwNj for ; Wed, 19 Mar 2008 14:27:55 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 95B463A68AC for ; Wed, 19 Mar 2008 14:27:55 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_03_19_16_38_34 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 19 Mar 2008 16:38:33 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Mar 2008 16:25:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Mar 2008 16:25:32 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Consensus Call on U-NAPTR usage for LoST Thread-Index: AciJzzJ63t5cpJXsQES2s/Uhwdy5IwAAEzDQAA4FW+A= References: <47E02587.5000208@gmx.net> From: "Thomson, Martin" To: "Winterbottom, James" , "Andrew Newton" , "Hannes Tschofenig" X-OriginalArrivalTime: 19 Mar 2008 21:25:36.0825 (UTC) FILETIME=[C5D0AA90:01C88A07] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Consensus Call on U-NAPTR usage for LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If I didn't hum for b, then I'd have to change my geopriv draft - it has the same limitations. b works for me, providing the limitations are adequately documented. It's not as if it's your first and only option. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Winterbottom, James > Sent: Thursday, 20 March 2008 1:43 AM > To: Andrew Newton; Hannes Tschofenig > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Consensus Call on U-NAPTR usage for LoST > > I hum for b) as well! > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > Of > > Andrew Newton > > Sent: Thursday, 20 March 2008 1:40 AM > > To: Hannes Tschofenig > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] Consensus Call on U-NAPTR usage for LoST > > > > This does not take into account how the input data was acquired. If > > it was acquired via DHCP, it could already be compromised. This > means > > that both options have security problems. Therefore, the difference > > between these two options is that (a) will restrict the deployment > > options. So I hum for (b). > > > > -andy > > > > On Mar 18, 2008, at 4:26 PM, Hannes Tschofenig wrote: > > > > > Hi all, > > > > > > I have just distributed a mail about a more detailed description on > > > the > > > usage of U-NAPTR for LoST discovery. > > > > > > During the IETF#71 ECRIT session I asked the group for a hum > whether > > > the > > > group wants to use > > > a) the input to the U-NAPTR process OR > > > b) the output of the U-NAPTR process > > > to be matched against the content of the identity information > > > carried in > > > the certificate exchanged as part of a TLS handshake between a LoST > > > client and a LoST server. > > > > > > There was strong consensus in the room for (b), as it is currently > > > defined in the LoST document. > > > > > > This mail aims to confirm that decision on the mailing list. Please > > > post > > > your opinion to the list. > > > > > > 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 > > ----------------------------------------------------------------------- > ------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ----------------------------------------------------------------------- > ------------------------- > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 19 14:30:56 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4176828C29A; Wed, 19 Mar 2008 14:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.457 X-Spam-Level: X-Spam-Status: No, score=-100.457 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSHar6LM7R-m; Wed, 19 Mar 2008 14:30:55 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5730B3A68C3; Wed, 19 Mar 2008 14:30:55 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B01A328C127 for ; Wed, 19 Mar 2008 14:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rmqqgvgoxm5b for ; Wed, 19 Mar 2008 14:30:52 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5A8AF3A68AF for ; Wed, 19 Mar 2008 14:30:52 -0700 (PDT) Received: (qmail invoked by alias); 19 Mar 2008 21:28:33 -0000 Received: from 85-156-75-43.elisa-mobile.fi (EHLO [85.156.75.43]) [85.156.75.43] by mail.gmx.net (mp027) with SMTP; 19 Mar 2008 22:28:33 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19/N51HFEh/xwOUxYJxcHX6Lumq/C/hhvhxoC0oPc aL4opF6tNU9rCL Message-ID: <47E18584.4060405@gmx.net> Date: Wed, 19 Mar 2008 23:28:36 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Thomson, Martin" References: <47E02587.5000208@gmx.net> In-Reply-To: X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Consensus Call on U-NAPTR usage for LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Thomson, Martin wrote: > If I didn't hum for b, then I'd have to change my geopriv draft - it has > the same limitations. > I guess you are talking about the LIS discovery document. Right? > b works for me, providing the limitations are adequately documented. > It's not as if it's your first and only option. > > Ok. Thanks for the feedback. Ciao Hannes >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Winterbottom, James >> Sent: Thursday, 20 March 2008 1:43 AM >> To: Andrew Newton; Hannes Tschofenig >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Consensus Call on U-NAPTR usage for LoST >> >> I hum for b) as well! >> >> >> >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> >> Behalf >> Of >> >>> Andrew Newton >>> Sent: Thursday, 20 March 2008 1:40 AM >>> To: Hannes Tschofenig >>> Cc: ecrit@ietf.org >>> Subject: Re: [Ecrit] Consensus Call on U-NAPTR usage for LoST >>> >>> This does not take into account how the input data was acquired. If >>> it was acquired via DHCP, it could already be compromised. This >>> >> means >> >>> that both options have security problems. Therefore, the difference >>> between these two options is that (a) will restrict the deployment >>> options. So I hum for (b). >>> >>> -andy >>> >>> On Mar 18, 2008, at 4:26 PM, Hannes Tschofenig wrote: >>> >>> >>>> Hi all, >>>> >>>> I have just distributed a mail about a more detailed description >>>> > on > >>>> the >>>> usage of U-NAPTR for LoST discovery. >>>> >>>> During the IETF#71 ECRIT session I asked the group for a hum >>>> >> whether >> >>>> the >>>> group wants to use >>>> a) the input to the U-NAPTR process OR >>>> b) the output of the U-NAPTR process >>>> to be matched against the content of the identity information >>>> carried in >>>> the certificate exchanged as part of a TLS handshake between a >>>> > LoST > >>>> client and a LoST server. >>>> >>>> There was strong consensus in the room for (b), as it is currently >>>> defined in the LoST document. >>>> >>>> This mail aims to confirm that decision on the mailing list. >>>> > Please > >>>> post >>>> your opinion to the list. >>>> >>>> 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 >>> >> > ----------------------------------------------------------------------- > >> ------------------------- >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> >> > ----------------------------------------------------------------------- > >> ------------------------- >> [mf2] >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 19 14:50:11 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF92A28C20D; Wed, 19 Mar 2008 14:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.678 X-Spam-Level: X-Spam-Status: No, score=-99.678 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MANGLED_LOW=2.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvhmTqE-9nG5; Wed, 19 Mar 2008 14:50:10 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34B83A6C46; Wed, 19 Mar 2008 14:50:10 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F03BB3A6888 for ; Wed, 19 Mar 2008 14:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os0m9+LRJ3wQ for ; Wed, 19 Mar 2008 14:50:08 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id AE15D28C0D8 for ; Wed, 19 Mar 2008 14:50:08 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 19 Mar 2008 14:47:51 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m2JLln7j009233; Wed, 19 Mar 2008 14:47:49 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2JLlnKA021856; Wed, 19 Mar 2008 21:47:49 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 14:47:49 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.72.205]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 14:47:47 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 19 Mar 2008 16:47:46 -0500 To: Henning Schulzrinne , ECRIT From: "James M. Polk" In-Reply-To: <4DF40D8B-1794-44B2-A695-E7EC4635AD21@cs.columbia.edu> References: <47E142E5.6060402@cs.columbia.edu> <4DF40D8B-1794-44B2-A695-E7EC4635AD21@cs.columbia.edu> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 19 Mar 2008 21:47:48.0009 (UTC) FILETIME=[DF433990:01C88A0A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4838; t=1205963269; x=1206827269; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20LoST=20Extensions=20draft |Sender:=20; bh=Gcm7oWufTKAvBxoRHc9vpZ7ofAIi3G71vpaFl2EDP9U=; b=e5J0nJ7rHr7FBESjBm/Nmk9HLA9g7fh45JqNHKzk9iQOrRTh0S/lpYKR2Z fsQRfQHTgY82XOlj7UVCLxB/XbAxxkUjSGoUlBnPHL5bmq9yWOOeC7DKWQ9g R2zeyUtbbN; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Ecrit] LoST Extensions draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Having only scanned the doc (I know - bad dog!) - but it is short, I have a few simple questions - what exactly determines which hospital is closest? For example, there could be one 8.4 miles away via a freeway, another 7.8 miles away - but the path only has surface streets between me and that hospital, and another 5.1 miles away, but there is a river directly between me and the hospital - with a river crossing 5 miles away (making that 3rd hospital over 9 miles away). If I have a 'limit' of 1, then the problem above is compounded by time of travel to get there being different than what's closest 'as the crow flies'... Is this a function of a protocol, or of an application server that does the calculation, given the nearly exact location of all relevant points of interest (and knowing my location)? I'm also curious how far out (i.e., how big) you can take the liberty (i.e., redefinition) of "area of uncertainty" to indicate an area? Is this proportional to the size of the target? I find it kinda hard to believe you have indicate a target as a specific point (indicating the center of a circle here) with a a radius of 2 miles or 50 miles or 500 miles -- where this radius was normally (i.e., previously) defined as the "area of uncertainty", in other words, the potential error in location measurement. Further, doesn't this fairly radically change the XML of the PIDF-LO, and how the locations of each point of interest (in this case several hospitals are identified to the requester) are indicated to that requester? Fundamentally, I think these URIs need to be returned either with or after the locations of the "points of interest" (POI) are returned to the requester. It may do little good to get a URI to a Japanese restaurant because you are jonesing for some Sushi if you don't know where that restaurant is located - which could lead to your choice among the several returns (within the 'limit' element). Sometimes you may want to know exactly where these restaurants are (geographically) to make a choice which URI to contact. I think will necessitate returning a "PIDF-LO w/ associated URI" for each POI, in your LoST reply. At least, this is what I would want from whatever service provided me this information. Phase II - is not returning the nearest POIs to your location, but the nearest POIs to another location. For example, I might know where there are several Japanese restaurants, but don't know just how many. I'd like to enter (or give) a location and then ask "give me the nearest 25 Japanese restaurants to this location, to then choice which among them, within a certain part of a city, I want to choose from. Just a few thoughts James At 01:26 PM 3/19/2008, Henning Schulzrinne wrote: >I should add that we don't expect this to become part of ECRIT >charter, but since there isn't really another obvious home for this, >we chose this WG for now. The goal of the draft is to illustrate that >it is relatively straightforward to extend LoST to handle other types >of services. Some of these may well even be useful for emergency >coordination ("what are all hospitals in a 50 mile radius?"). > >Henning > >On Mar 19, 2008, at 12:44 PM, Andrea G. Forte wrote: > > > Dear all, > > > > I just wanted to let you know that I have just submitted a new draft > > for > > your consideration. > > Looking forward to your feedback. > > > > Filename: draft-forte-ecrit-lost-extensions > > Revision: 00 > > Title: Location-to-Service Translation Protocol > (LoST) Extensions > > Creation_date: 2008-03-19 > > WG ID: Independent Submission > > Number_of_pages: 11 > > > > Abstract: > > An important class of location-based services answer the question > > "What instances of this service are closest to me?" Examples include > > finding restaurants, gas stations, stores, automated teller machines, > > wireless access points (hot spots) or parking spaces. Currently, the > > Location-to-Service Translation (LoST) protocol only supports mapping > > locations to a single service based on service regions. This > > document describes an extension that allows queries "N nearest" and > > "within distance X". > > > > > > URL: https://datatracker.ietf.org/drafts/draft-forte-ecrit-lost-extensions/ > > > > -Andrea > > > > -- > > > > http://www.cs.columbia.edu/~andreaf/ > > > > > > _______________________________________________ > > 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 ecrit-bounces@ietf.org Wed Mar 19 15:25:38 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF6D3A6B56; Wed, 19 Mar 2008 15:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.373 X-Spam-Level: X-Spam-Status: No, score=-99.373 tagged_above=-999 required=5 tests=[AWL=-1.236, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MANGLED_LOW=2.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Q3xUej0xWbl; Wed, 19 Mar 2008 15:25:37 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3354C3A68AF; Wed, 19 Mar 2008 15:25:37 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D4163A63D3 for ; Wed, 19 Mar 2008 15:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9F7mOholN6Zm for ; Wed, 19 Mar 2008 15:25:31 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 9414A3A689F for ; Wed, 19 Mar 2008 15:25:31 -0700 (PDT) Received: from [128.59.20.159] (irt-af.cs.columbia.edu [128.59.20.159]) (user=agf2104 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m2JMNC4Q008186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Mar 2008 18:23:12 -0400 (EDT) Message-ID: <47E192CC.6040105@cs.columbia.edu> Date: Wed, 19 Mar 2008 18:25:16 -0400 From: "Andrea G. Forte" User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: "James M. Polk" References: <47E142E5.6060402@cs.columbia.edu> <4DF40D8B-1794-44B2-A695-E7EC4635AD21@cs.columbia.edu> In-Reply-To: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Cc: ECRIT Subject: Re: [Ecrit] LoST Extensions draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Please read comments inline. http://www.cs.columbia.edu/~andreaf/ James M. Polk wrote: > Having only scanned the doc (I know - bad dog!) - but it is short, I > have a few simple questions - what exactly determines which hospital > is closest? > > For example, there could be one 8.4 miles away via a freeway, another > 7.8 miles away - but the path only has surface streets between me and > that hospital, and another 5.1 miles away, but there is a river > directly between me and the hospital - with a river crossing 5 miles > away (making that 3rd hospital over 9 miles away). > > If I have a 'limit' of 1, then the problem above is compounded by time > of travel to get there being different than what's closest 'as the > crow flies'... > > Is this a function of a protocol, or of an application server that > does the calculation, given the nearly exact location of all relevant > points of interest (and knowing my location)? Yes, as you point out and as we mention in Section 6 of the draft, straight-line distance is not always the best metric. Because of obstacles, types of roads and other reasons, route (and travel time) rather than distance might be a better metric. This, however is not directly related to LoST as a protocol, but rather to how the server computes "closest". In reality this computation could be performed also on the client for "within distance X" queries and for "N nearest" queries when all the possible results are less than N. The reason why we do not explicitly address this problem is because this is not really protocol related. You could imagine each company deploying such service using their own location-estimation techniques on their servers/clients. > > I'm also curious how far out (i.e., how big) you can take the liberty > (i.e., redefinition) of "area of uncertainty" to indicate an area? Is > this proportional to the size of the target? I find it kinda hard to > believe you have indicate a target as a specific point (indicating the > center of a circle here) with a a radius of 2 miles or 50 miles or 500 > miles -- where this radius was normally (i.e., previously) defined as > the "area of uncertainty", in other words, the potential error in > location measurement. I am not sure if I understand what you mean here. However, I think that for POIs the area of uncertainty is useless. This depends on how the database containing these POIs has been populated. If you look at google maps, the position of POIs is very accurate. > > Further, doesn't this fairly radically change the XML of the PIDF-LO, > and how the locations of each point of interest (in this case several > hospitals are identified to the requester) are indicated to that > requester? > > Fundamentally, I think these URIs need to be returned either with or > after the locations of the "points of interest" (POI) are returned to > the requester. It may do little good to get a URI to a Japanese > restaurant because you are jonesing for some Sushi if you don't know > where that restaurant is located - which could lead to your choice > among the several returns (within the 'limit' element). Sometimes you > may want to know exactly where these restaurants are (geographically) > to make a choice which URI to contact. I think will necessitate > returning a "PIDF-LO w/ associated URI" for each POI, in your LoST reply. > > At least, this is what I would want from whatever service provided me > this information. Again, I am not sure I follow. In our draft the server returns the geodetic coordinates of each point of interest. So the client would know exactly where each POI is located. -Andrea > > Phase II - is not returning the nearest POIs to your location, but the > nearest POIs to another location. For example, I might know where > there are several Japanese restaurants, but don't know just how many. > I'd like to enter (or give) a location and then ask "give me the > nearest 25 Japanese restaurants to this location, to then choice > which among them, within a certain part of a city, I want to choose from. > > Just a few thoughts > > James > > At 01:26 PM 3/19/2008, Henning Schulzrinne wrote: >> I should add that we don't expect this to become part of ECRIT >> charter, but since there isn't really another obvious home for this, >> we chose this WG for now. The goal of the draft is to illustrate that >> it is relatively straightforward to extend LoST to handle other types >> of services. Some of these may well even be useful for emergency >> coordination ("what are all hospitals in a 50 mile radius?"). >> >> Henning >> >> On Mar 19, 2008, at 12:44 PM, Andrea G. Forte wrote: >> >> > Dear all, >> > >> > I just wanted to let you know that I have just submitted a new draft >> > for >> > your consideration. >> > Looking forward to your feedback. >> > >> > Filename: draft-forte-ecrit-lost-extensions >> > Revision: 00 >> > Title: Location-to-Service Translation Protocol >> (LoST) Extensions >> > Creation_date: 2008-03-19 >> > WG ID: Independent Submission >> > Number_of_pages: 11 >> > >> > Abstract: >> > An important class of location-based services answer the question >> > "What instances of this service are closest to me?" Examples include >> > finding restaurants, gas stations, stores, automated teller machines, >> > wireless access points (hot spots) or parking spaces. Currently, the >> > Location-to-Service Translation (LoST) protocol only supports mapping >> > locations to a single service based on service regions. This >> > document describes an extension that allows queries "N nearest" and >> > "within distance X". >> > >> > >> > URL: >> https://datatracker.ietf.org/drafts/draft-forte-ecrit-lost-extensions/ >> > >> > -Andrea >> > >> > -- >> > >> > http://www.cs.columbia.edu/~andreaf/ >> > >> > >> > _______________________________________________ >> > 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 ecrit-bounces@ietf.org Wed Mar 19 17:49:27 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83DB53A6AF9; Wed, 19 Mar 2008 17:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.788 X-Spam-Level: X-Spam-Status: No, score=-100.788 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boQPMev-LlLf; Wed, 19 Mar 2008 17:49:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 702233A6A3C; Wed, 19 Mar 2008 17:49:26 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67A113A6CFA for ; Wed, 19 Mar 2008 17:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCOEpRw-yfoY for ; Wed, 19 Mar 2008 17:49:21 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 7AD4928C1F3 for ; Wed, 19 Mar 2008 17:49:14 -0700 (PDT) Received: from [192.168.0.57] (pool-70-21-180-58.nwrk.east.verizon.net [70.21.180.58]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m2K0krRe012579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 19 Mar 2008 20:46:54 -0400 (EDT) Message-Id: <67F3AC43-8C04-4F0E-98EF-1255D3F90A05@cs.columbia.edu> From: Henning Schulzrinne To: "Andrea G. Forte" In-Reply-To: <47E192CC.6040105@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 19 Mar 2008 20:46:52 -0400 References: <47E142E5.6060402@cs.columbia.edu> <4DF40D8B-1794-44B2-A695-E7EC4635AD21@cs.columbia.edu> <47E192CC.6040105@cs.columbia.edu> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6 Cc: ECRIT Subject: Re: [Ecrit] LoST Extensions draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Just to amplify what Andrea is saying a bit... On Mar 19, 2008, at 6:25 PM, Andrea G. Forte wrote: > > James M. Polk wrote: >> Having only scanned the doc (I know - bad dog!) - but it is short, >> I have a few simple questions - what exactly determines which >> hospital is closest? >> >> Is this a function of a protocol, or of an application server that >> does the calculation, given the nearly exact location of all >> relevant points of interest (and knowing my location)? > Yes, as you point out and as we mention in Section 6 of the draft, > straight-line distance is not always the best metric. Because of > obstacles, types of roads and other reasons, route (and travel time) > rather than distance might be a better metric. This, however is not > directly related to LoST as a protocol, but rather to how the server > computes "closest". In reality this computation could be performed > also on the client for "within distance X" queries and for "N > nearest" queries when all the possible results are less than N. > The reason why we do not explicitly address this problem is because > this is not really protocol related. You could imagine each company > deploying such service using their own location-estimation > techniques on their servers/clients. In my view, this is typically a client function. For example, your standard-issue Garmin/TomTom device (or Google Maps) can do this fairly easily already. Conveying all my travel preferences (walk vs. bike vs. train vs. car vs. helicopter, with numerous variations of fastest vs. cheapest vs. closest) would seem rather onerous. Plus, it would reveal more about myself to the location service than seems necessary. We were trying to keep this relatively simple; there are plenty of extensions one can think of, such as "give me all ZAGAT-rated restaurants that have a fish special tonight, take Discover cards, are non-smoking, have a table for two near a window and are near a movie theatre that plays a romantic comedy". For that level of sophistication, we have the GloServ project (http://www1.cs.columbia.edu/~knarig/gloserv/Overview.html ). > > >> >> I'm also curious how far out (i.e., how big) you can take the >> liberty (i.e., redefinition) of "area of uncertainty" to indicate >> an area? Is this proportional to the size of the target? I find >> it kinda hard to believe you have indicate a target as a specific >> point (indicating the center of a circle here) with a a radius of 2 >> miles or 50 miles or 500 miles -- where this radius was normally >> (i.e., previously) defined as the "area of uncertainty", in other >> words, the potential error in location measurement. > I am not sure if I understand what you mean here. However, I think > that for POIs the area of uncertainty is useless. This depends on > how the database containing these POIs has been populated. If you > look at google maps, the position of POIs is very accurate. The meaning is essentially the same: "I'm somewhere in this region; please tell me about the services". We currently make no representation as to the probability distribution in either case. > >> >> Phase II - is not returning the nearest POIs to your location, but >> the nearest POIs to another location. For example, I might know >> where there are several Japanese restaurants, but don't know just >> how many. I'd like to enter (or give) a location and then ask >> "give me the nearest 25 Japanese restaurants to this location, >> to then choice which among them, within a certain part of a city, I >> want to choose from. >> The same protocol would work; just substitute another location or shape. There's nothing in the protocol that restricts queries to the current location. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 20 18:45:45 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 705E63A6F87; Thu, 20 Mar 2008 18:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100, WHOIS_MYPRIVREG=1.499] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IS7H4W3+w4a3; Thu, 20 Mar 2008 18:45:44 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A15C23A6D3E; Thu, 20 Mar 2008 18:45:44 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D2503A6D3E for ; Thu, 20 Mar 2008 18:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3AAGWpJ5Ut6 for ; Thu, 20 Mar 2008 18:45:42 -0700 (PDT) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by core3.amsl.com (Postfix) with ESMTP id A3CA03A69D6 for ; Thu, 20 Mar 2008 18:45:42 -0700 (PDT) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1JcWI1-0003Ou-01 for ecrit@ietf.org; Thu, 20 Mar 2008 18:43:25 -0700 Message-ID: <16176346.post@talk.nabble.com> Date: Thu, 20 Mar 2008 18:43:24 -0700 (PDT) From: Robins George To: ecrit@ietf.org In-Reply-To: <47E142E5.6060402@cs.columbia.edu> MIME-Version: 1.0 X-Nabble-From: robinsg@huawei.com References: <47E142E5.6060402@cs.columbia.edu> Subject: Re: [Ecrit] LoST Extensions draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org how do we find the instances of a service in the location B from the location A ? is it possible ? and how how do we find a list/combination of instances of a service in a location A ? (for example I need to find the instances of a restaurant and juice shop) robins Andrea G Forte wrote: > > Dear all, > > I just wanted to let you know that I have just submitted a new draft for > your consideration. > Looking forward to your feedback. > > Filename: draft-forte-ecrit-lost-extensions > Revision: 00 > Title: Location-to-Service Translation Protocol (LoST) Extensions > Creation_date: 2008-03-19 > WG ID: Independent Submission > Number_of_pages: 11 > > Abstract: > An important class of location-based services answer the question > "What instances of this service are closest to me?" Examples include > finding restaurants, gas stations, stores, automated teller machines, > wireless access points (hot spots) or parking spaces. Currently, the > Location-to-Service Translation (LoST) protocol only supports mapping > locations to a single service based on service regions. This > document describes an extension that allows queries "N nearest" and > "within distance X". > > > URL: > https://datatracker.ietf.org/drafts/draft-forte-ecrit-lost-extensions/ > > -Andrea > > -- > > http://www.cs.columbia.edu/~andreaf/ > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > -- View this message in context: http://www.nabble.com/LoST-Extensions-draft-tp16159750p16176346.html Sent from the IETF - Ecrit mailing list archive at Nabble.com. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 20 19:07:33 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471983A6D1A; Thu, 20 Mar 2008 19:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.733 X-Spam-Level: X-Spam-Status: No, score=-100.733 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pD4aVgrQBvBm; Thu, 20 Mar 2008 19:07:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6253B3A68FD; Thu, 20 Mar 2008 19:07:32 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F2DE3A69D9 for ; Thu, 20 Mar 2008 19:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycPjQC-jgBxY for ; Thu, 20 Mar 2008 19:07:30 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 9A2213A6869 for ; Thu, 20 Mar 2008 19:07:26 -0700 (PDT) Received: from [192.168.0.57] (pool-70-21-180-58.nwrk.east.verizon.net [70.21.180.58]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m2L24vKk007097 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 20 Mar 2008 22:04:58 -0400 (EDT) Message-Id: <046E5214-2803-4E18-A4B3-503D7DA9924B@cs.columbia.edu> From: Henning Schulzrinne To: Robins George In-Reply-To: <16176346.post@talk.nabble.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 20 Mar 2008 22:04:57 -0400 References: <47E142E5.6060402@cs.columbia.edu> <16176346.post@talk.nabble.com> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Cc: ecrit@ietf.org Subject: Re: [Ecrit] LoST Extensions draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Mar 20, 2008, at 9:43 PM, Robins George wrote: > > how do we find the instances of a service in the location B from the > location A ? Yes. Nothing in LoST requires that the location provided is your current location. > > is it possible ? > and how how do we find a list/combination of instances of a service > in a > location A ? > (for example I need to find the instances of a restaurant and juice > shop) > I'm not sure if you want to find restaurants that are also moonlighting as juice shops or a restaurant that is close to a juice shop. Assuming the latter, the current proposal would leave such operations to the client. Presumably, the list of juice shops and restaurants in the area of interest is reasonable in size, say, no more than a few hundred, so that client computation are feasible. As I mentioned before, our GloServ project does this explicitly, but it uses far heavier machinery, such as OWL. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 21 07:32:30 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C7E33A6D13; Fri, 21 Mar 2008 07:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.677 X-Spam-Level: X-Spam-Status: No, score=-100.677 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qvR5OxBYoCl; Fri, 21 Mar 2008 07:32:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E1E13A6B77; Fri, 21 Mar 2008 07:32:26 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2233A6B31 for ; Fri, 21 Mar 2008 07:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrXoe2VK5DDl for ; Fri, 21 Mar 2008 07:32:21 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 5EF903A6785 for ; Fri, 21 Mar 2008 07:32:21 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so1115633fgg.41 for ; Fri, 21 Mar 2008 07:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=8OIVK8FlqdHKKc4CBtpZeBKqQZaO0/qrvmm3xxIRPj8=; b=QBK9wcdIOqDy8aSkK1Vpblm+lB+RTW6X/iDkdmMqesRTZmXiS3SqOUVHJQoAZI2KdM9nTDP9BcXxtpVRu9leRSqoi+HrvWydyM9uK2qvm4KLoRsDGkS+RS/pjGbg6b0NMuEPl4GZl+4f/wlYWag+i+AphH4SnKBJSJhBTNAUKvA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bVjtV8WLnA6Osmy0raSEeH0zjH8HssPHrnduQHg+lscsroMjO9daWfwKnAg5KPmixUWtq58P4J27FwTm1inhYIjXis3Aa3vP47n/am18RcP9wYVd1BvRRydnHzEPMv+atQny6eyE/xZg/c1Iwh+MU6zVUR5LmRlvJjvF1gCozdc= Received: by 10.82.171.16 with SMTP id t16mr7463825bue.25.1206109802729; Fri, 21 Mar 2008 07:30:02 -0700 (PDT) Received: by 10.82.182.2 with HTTP; Fri, 21 Mar 2008 07:30:02 -0700 (PDT) Message-ID: Date: Fri, 21 Mar 2008 15:30:02 +0100 From: "Karl Heinz Wolf" To: "Hannes Tschofenig" In-Reply-To: <47CAE9D4.9080702@gmx.net> MIME-Version: 1.0 Content-Disposition: inline References: <47CAE9D4.9080702@gmx.net> Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I read through the document and here are my comments: page 7: "The phone gets location from the DHCP server in civic [RFC4676] or geo" -> should it be "and/or"? page 8: second bullet: it is not obvious to me that the refreshing of the mapping is meant (sounds rather like initial determination). And there should be another bullet above saying that location information is refreshed too (as indicated in the figure below and discussed below in the text). page 9: second bullet: "In this flow, DHCP is used as an example location configuration protocol (LCP)" - I can't find anything in the example above that mentions DHCP, and I don't think Figure 1 and 2 have any special consideration for DHCP. Is it necessary to restrict this example to DHCP? page 10: "The LoST response may contain the dial string for emergency calls appropriate for the location provided." Just a MAY for the dialstring? The dialstring is mandatory for detecting an emergency call (although it is an optional element in LoST). page 15: "... as a point (geo or civic) or polygon." What is a "civic point"? I would suggest "geo point or polygon or civic location". page 27: "create SIP INVITE messages with the Service URN in the Request URI" - The To: header is not mentioned here. editorial: page 3: Dispatch Location: ... "easily locate the callee" - should be: "caller" page 7: "to a set of PSAP or URIs" -> PSAP URIs page 13: "routing is but one of two uses..." page 22: "it make take some time" page 23: Missing reference: "Handling multiple locations is discussed in ." cheers karl heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 21 07:44:23 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0904428C139; Fri, 21 Mar 2008 07:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.573 X-Spam-Level: X-Spam-Status: No, score=-100.573 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTZyyhCdY83L; Fri, 21 Mar 2008 07:44:22 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 051A93A6965; Fri, 21 Mar 2008 07:44:22 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB0B3A684A for ; Fri, 21 Mar 2008 07:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpsikqUliDR8 for ; Fri, 21 Mar 2008 07:44:19 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 9202B3A68BE for ; Fri, 21 Mar 2008 07:43:26 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JciQZ-0002TR-E5; Fri, 21 Mar 2008 09:41:03 -0500 From: "Brian Rosen" To: "'Karl Heinz Wolf'" , "'Hannes Tschofenig'" References: <47CAE9D4.9080702@gmx.net> Date: Fri, 21 Mar 2008 10:41:04 -0400 Message-ID: <022001c88b61$99562f70$6901a8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AciLYBJJJwlc24uuTAC61NyaDlOEIQAAPmtw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Thanks a lot for your comments. I agree with all of your comments except the page 10 LoST return of dialstring may/must. I don't think it's possible to make it MUST because there are systems such as 3GPP that work without it. I could see a SHOULD, where the exception is a closed system where the LoST operator knows for certain that all devices that query it have the correct dial string via some other mechanism. Henning, does that sound about right to you? Karl, would that address your issue? Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Karl Heinz Wolf Sent: Friday, March 21, 2008 10:30 AM To: Hannes Tschofenig Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05 I read through the document and here are my comments: page 7: "The phone gets location from the DHCP server in civic [RFC4676] or geo" -> should it be "and/or"? page 8: second bullet: it is not obvious to me that the refreshing of the mapping is meant (sounds rather like initial determination). And there should be another bullet above saying that location information is refreshed too (as indicated in the figure below and discussed below in the text). page 9: second bullet: "In this flow, DHCP is used as an example location configuration protocol (LCP)" - I can't find anything in the example above that mentions DHCP, and I don't think Figure 1 and 2 have any special consideration for DHCP. Is it necessary to restrict this example to DHCP? page 10: "The LoST response may contain the dial string for emergency calls appropriate for the location provided." Just a MAY for the dialstring? The dialstring is mandatory for detecting an emergency call (although it is an optional element in LoST). page 15: "... as a point (geo or civic) or polygon." What is a "civic point"? I would suggest "geo point or polygon or civic location". page 27: "create SIP INVITE messages with the Service URN in the Request URI" - The To: header is not mentioned here. editorial: page 3: Dispatch Location: ... "easily locate the callee" - should be: "caller" page 7: "to a set of PSAP or URIs" -> PSAP URIs page 13: "routing is but one of two uses..." page 22: "it make take some time" page 23: Missing reference: "Handling multiple locations is discussed in ." cheers karl heinz _______________________________________________ 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 ecrit-bounces@ietf.org Fri Mar 21 07:54:58 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC183A6C37; Fri, 21 Mar 2008 07:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.797 X-Spam-Level: X-Spam-Status: No, score=-100.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsUyQGzT2X+7; Fri, 21 Mar 2008 07:54:54 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6033A6953; Fri, 21 Mar 2008 07:54:54 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8DF03A6953 for ; Fri, 21 Mar 2008 07:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjUmRW+DnjbY for ; Fri, 21 Mar 2008 07:54:53 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by core3.amsl.com (Postfix) with ESMTP id E8D103A684A for ; Fri, 21 Mar 2008 07:54:52 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 19so1917559fkr.5 for ; Fri, 21 Mar 2008 07:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=6T2gLwNd0kvgsZDZv/+mgIh6yGidB+KX6oWOjs/gFxI=; b=s3G9YncOAHUYHaqKTM41nscDhXrM0wFl9uoUEVZ2uxBIhNp+fyKOwHWPjLK69MYNuLYqhdWjZcgwsMIkbXmKlNJLhp4SePFCDhNWaQyV21xHKcK7qaML33Y7sEcqEZKWbTPu3+tI0dGM/nUUtFCi0pjokNbEz4rfvDzG/uDdUk0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JiGorKh8LvYTKagsv6aOsXuTqHRiTd08zq5l5th4durmZWV4OncxWbwxNTtYTQLaqJrHwj5rvM/b+Av5K/RtGxHPV2OHMN76RiTgebACF72mGetiZLZIgb7PAftdWcqSuKZc4TaBjSva7HfiUKcVlh3rS5nQrhQ9Ra572iICmy0= Received: by 10.82.112.3 with SMTP id k3mr7607646buc.32.1206111150350; Fri, 21 Mar 2008 07:52:30 -0700 (PDT) Received: by 10.82.182.2 with HTTP; Fri, 21 Mar 2008 07:52:30 -0700 (PDT) Message-ID: Date: Fri, 21 Mar 2008 15:52:30 +0100 From: "Karl Heinz Wolf" To: "Brian Rosen" In-Reply-To: <022001c88b61$99562f70$6901a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Disposition: inline References: <47CAE9D4.9080702@gmx.net> <022001c88b61$99562f70$6901a8c0@cis.neustar.com> Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > LoST dialstring may/must/should > Karl, would that address your issue? > we already had a discussion on this topic when I read "framework-03" - I just wanted to preserve this topic from falling into oblivion. I would suggest to note somewhere in what cases the LoST server is expected to return the dialstring and in what situation it is not necessary. cheers karl heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 21 08:08:10 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E15A3A6C68; Fri, 21 Mar 2008 08:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.228 X-Spam-Level: X-Spam-Status: No, score=-101.228 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJxzkc4jUSoQ; Fri, 21 Mar 2008 08:08:09 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D993A6CC6; Fri, 21 Mar 2008 08:08:09 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 703F83A6A54 for ; Fri, 21 Mar 2008 08:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z41Iu8JLbpJ4 for ; Fri, 21 Mar 2008 08:08:06 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 0A6F03A6CC6 for ; Fri, 21 Mar 2008 08:08:05 -0700 (PDT) Received: from dhcp62.cs.columbia.edu (dhcp62.cs.columbia.edu [128.59.17.212]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m2LF5hSg017905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Mar 2008 11:05:43 -0400 (EDT) Message-Id: <5A9E3E25-6ABB-4498-9B15-9BD7D626D028@cs.columbia.edu> From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <022001c88b61$99562f70$6901a8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 21 Mar 2008 11:05:43 -0400 References: <47CAE9D4.9080702@gmx.net> <022001c88b61$99562f70$6901a8c0@cis.neustar.com> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Mar 21, 2008, at 10:41 AM, Brian Rosen wrote: > Thanks a lot for your comments. I agree with all of your comments > except > the page 10 LoST return of dialstring may/must. I don't think it's > possible > to make it MUST because there are systems such as 3GPP that work > without it. > I could see a SHOULD, where the exception is a closed system where > the LoST > operator knows for certain that all devices that query it have the > correct > dial string via some other mechanism. > > Henning, does that sound about right to you? > I'm ok with documenting a clear exception, but I wonder whether there is harm in requiring that LoST always returns the dial string, for several reasons: - You never know who will connect to a server, even if you believe that it can only be accessed from within a certain physical network. This also tends to change over time; upgrading servers and data sets at that time seems more error-prone, easy to forget and painful. - It doesn't seem particularly onerous to include this information. It's not secret, it's not hard to maintain and it doesn't change. - Longer term, IMS may get more open (see Verizon...), so it may be harder to make the distinction. - It seems difficult to describe the exception in a way that covers what we want without encouraging "bad" behavior. Thus, I think interoperability and robustness argue for MUST. If certain specialized systems end up ignoring the information in favor of local configuration, that's a separate problem. Given that disagreement over the dialstring seems unlikely and obvious, I'd rather have two sources than none. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 21 09:29:51 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BA2F28C312; Fri, 21 Mar 2008 09:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.571 X-Spam-Level: X-Spam-Status: No, score=-100.571 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5z4eOUvqNBM; Fri, 21 Mar 2008 09:29:45 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDB6928C18A; Fri, 21 Mar 2008 09:29:35 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B01CB3A6D0E for ; Fri, 21 Mar 2008 09:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeikpFF1KFDx for ; Fri, 21 Mar 2008 09:29:22 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 6AC0C28C3B2 for ; Fri, 21 Mar 2008 09:28:48 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jck4W-0002MW-K9; Fri, 21 Mar 2008 11:26:24 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" References: <47CAE9D4.9080702@gmx.net> <022001c88b61$99562f70$6901a8c0@cis.neustar.com> <5A9E3E25-6ABB-4498-9B15-9BD7D626D028@cs.columbia.edu> Date: Fri, 21 Mar 2008 12:26:27 -0400 Message-ID: <023c01c88b70$51b95e80$6901a8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <5A9E3E25-6ABB-4498-9B15-9BD7D626D028@cs.columbia.edu> Thread-Index: AciLZQasuCKNyJp1RVOlR+mDMQ83mQACzC7A X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Anyone else on the list have a problem in making this a must (small must in framework, MUST in phonebcp)? Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Friday, March 21, 2008 11:06 AM To: Brian Rosen Cc: 'Karl Heinz Wolf'; 'Hannes Tschofenig'; ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05 On Mar 21, 2008, at 10:41 AM, Brian Rosen wrote: > Thanks a lot for your comments. I agree with all of your comments > except > the page 10 LoST return of dialstring may/must. I don't think it's > possible > to make it MUST because there are systems such as 3GPP that work > without it. > I could see a SHOULD, where the exception is a closed system where > the LoST > operator knows for certain that all devices that query it have the > correct > dial string via some other mechanism. > > Henning, does that sound about right to you? > I'm ok with documenting a clear exception, but I wonder whether there is harm in requiring that LoST always returns the dial string, for several reasons: - You never know who will connect to a server, even if you believe that it can only be accessed from within a certain physical network. This also tends to change over time; upgrading servers and data sets at that time seems more error-prone, easy to forget and painful. - It doesn't seem particularly onerous to include this information. It's not secret, it's not hard to maintain and it doesn't change. - Longer term, IMS may get more open (see Verizon...), so it may be harder to make the distinction. - It seems difficult to describe the exception in a way that covers what we want without encouraging "bad" behavior. Thus, I think interoperability and robustness argue for MUST. If certain specialized systems end up ignoring the information in favor of local configuration, that's a separate problem. Given that disagreement over the dialstring seems unlikely and obvious, I'd rather have two sources than none. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 21 09:51:06 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 392C528C25E; Fri, 21 Mar 2008 09:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.426 X-Spam-Level: X-Spam-Status: No, score=-101.426 tagged_above=-999 required=5 tests=[AWL=-1.173, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_HIRISK_FORGED_ATT=0.184, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7d8Cb6LDxtl; Fri, 21 Mar 2008 09:51:05 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 501423A6997; Fri, 21 Mar 2008 09:51:05 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C3A23A684F for ; Fri, 21 Mar 2008 09:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OgnPaZZuyLd for ; Fri, 21 Mar 2008 09:51:03 -0700 (PDT) Received: from aismt06p.bellsouth.com (aismt06p.bellsouth.com [139.76.165.211]) by core3.amsl.com (Postfix) with ESMTP id 190413A6997 for ; Fri, 21 Mar 2008 09:51:03 -0700 (PDT) Received: from ([139.76.131.87]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.43396698; Fri, 21 Mar 2008 12:48:15 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 21 Mar 2008 12:48:15 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 21 Mar 2008 12:48:14 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Mar 2008 12:48:13 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA080EC210@crexc41p> In-Reply-To: <023c01c88b70$51b95e80$6901a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] WGLC on draft-ietf-ecrit-framework-05 thread-index: AciLZQasuCKNyJp1RVOlR+mDMQ83mQACzC7AAADBmZA= References: <47CAE9D4.9080702@gmx.net><022001c88b61$99562f70$6901a8c0@cis.neustar.com><5A9E3E25-6ABB-4498-9B15-9BD7D626D028@cs.columbia.edu> <023c01c88b70$51b95e80$6901a8c0@cis.neustar.com> From: "Stark, Barbara" To: "Brian Rosen" , "Henning Schulzrinne" X-OriginalArrivalTime: 21 Mar 2008 16:48:14.0989 (UTC) FILETIME=[5B5583D0:01C88B73] Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think it's a good thing to have it as MUST in bcp. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, March 21, 2008 12:26 PM To: 'Henning Schulzrinne' Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05 Anyone else on the list have a problem in making this a must (small must in framework, MUST in phonebcp)? Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Friday, March 21, 2008 11:06 AM To: Brian Rosen Cc: 'Karl Heinz Wolf'; 'Hannes Tschofenig'; ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05 On Mar 21, 2008, at 10:41 AM, Brian Rosen wrote: > Thanks a lot for your comments. I agree with all of your comments > except > the page 10 LoST return of dialstring may/must. I don't think it's > possible > to make it MUST because there are systems such as 3GPP that work > without it. > I could see a SHOULD, where the exception is a closed system where > the LoST > operator knows for certain that all devices that query it have the > correct > dial string via some other mechanism. > > Henning, does that sound about right to you? > I'm ok with documenting a clear exception, but I wonder whether there is harm in requiring that LoST always returns the dial string, for several reasons: - You never know who will connect to a server, even if you believe that it can only be accessed from within a certain physical network. This also tends to change over time; upgrading servers and data sets at that time seems more error-prone, easy to forget and painful. - It doesn't seem particularly onerous to include this information. It's not secret, it's not hard to maintain and it doesn't change. - Longer term, IMS may get more open (see Verizon...), so it may be harder to make the distinction. - It seems difficult to describe the exception in a way that covers what we want without encouraging "bad" behavior. Thus, I think interoperability and robustness argue for MUST. If certain specialized systems end up ignoring the information in favor of local configuration, that's a separate problem. Given that disagreement over the dialstring seems unlikely and obvious, I'd rather have two sources than none. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 21 09:56:24 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AFBA28C1C6; Fri, 21 Mar 2008 09:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.707 X-Spam-Level: X-Spam-Status: No, score=-100.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujli6zYzIYer; Fri, 21 Mar 2008 09:56:18 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84EE33A6B9D; Fri, 21 Mar 2008 09:56:18 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00BB63A6C64 for ; Fri, 21 Mar 2008 09:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8CsA5o2IRUd for ; Fri, 21 Mar 2008 09:56:15 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id DA3933A6B9D for ; Fri, 21 Mar 2008 09:56:15 -0700 (PDT) Received: from mail.bbn.com ([128.33.1.19]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JckVB-0004UR-4I; Fri, 21 Mar 2008 12:53:57 -0400 Received: from col-dhcp33-244-170.bbn.com ([128.33.244.170]) by mail.bbn.com with esmtp (Exim 4.67) (envelope-from ) id 1JckVB-0003io-6J; Fri, 21 Mar 2008 12:53:57 -0400 Message-ID: <47E3E806.7050809@bbn.com> Date: Fri, 21 Mar 2008 12:53:26 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hannes Tschofenig References: <47E02587.5000208@gmx.net> In-Reply-To: <47E02587.5000208@gmx.net> Cc: ecrit@ietf.org Subject: Re: [Ecrit] Consensus Call on U-NAPTR usage for LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org In favor of (b). The security risks of U-NAPTR without DNSSEC are well-known; this case is not special. This document should, however, state clearly that this risk exists, and how it can be mitigated in deployments. --Richard Hannes Tschofenig wrote: > Hi all, > > I have just distributed a mail about a more detailed description on the > usage of U-NAPTR for LoST discovery. > > During the IETF#71 ECRIT session I asked the group for a hum whether the > group wants to use > a) the input to the U-NAPTR process OR > b) the output of the U-NAPTR process > to be matched against the content of the identity information carried in > the certificate exchanged as part of a TLS handshake between a LoST > client and a LoST server. > > There was strong consensus in the room for (b), as it is currently > defined in the LoST document. > > This mail aims to confirm that decision on the mailing list. Please post > your opinion to the list. > > 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 ecrit-bounces@ietf.org Sat Mar 22 17:51:01 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1D43A63CB; Sat, 22 Mar 2008 17:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.784 X-Spam-Level: X-Spam-Status: No, score=-99.784 tagged_above=-999 required=5 tests=[AWL=0.653, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWZJALuWZC4f; Sat, 22 Mar 2008 17:51:00 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EA433A68B0; Sat, 22 Mar 2008 17:51:00 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB5613A68B0 for ; Sat, 22 Mar 2008 17:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vULs2pGvV55J for ; Sat, 22 Mar 2008 17:50:59 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id DCA893A63CB for ; Sat, 22 Mar 2008 17:50:58 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_03_22_20_01_39 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sat, 22 Mar 2008 20:01:37 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Mar 2008 19:48:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 22 Mar 2008 19:48:34 -0500 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA080EC210@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] WGLC on draft-ietf-ecrit-framework-05 Thread-Index: AciLZQasuCKNyJp1RVOlR+mDMQ83mQACzC7AAADBmZAAQqlxgA== References: <47CAE9D4.9080702@gmx.net><022001c88b61$99562f70$6901a8c0@cis.neustar.com><5A9E3E25-6ABB-4498-9B15-9BD7D626D028@cs.columbia.edu><023c01c88b70$51b95e80$6901a8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA080EC210@crexc41p> From: "Dawson, Martin" To: "Stark, Barbara" , "Brian Rosen" , "Henning Schulzrinne" X-OriginalArrivalTime: 23 Mar 2008 00:48:36.0906 (UTC) FILETIME=[A0F2C8A0:01C88C7F] Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I agree with it being a MUST. With respect to the comment " there are systems such as 3GPP that work without it." I think the correct positioning is that those are not ECRIT systems - they are systems defined for more closed network scenarios that are not applicable to the general scope that ECRIT addresses. Those systems can call out their own criteria - and, really, their specifications are the correct place to identify exceptions to ECRIT rules if that's what they see fit. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Stark, Barbara Sent: Saturday, 22 March 2008 3:48 AM To: Brian Rosen; Henning Schulzrinne Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05 I think it's a good thing to have it as MUST in bcp. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, March 21, 2008 12:26 PM To: 'Henning Schulzrinne' Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05 Anyone else on the list have a problem in making this a must (small must in framework, MUST in phonebcp)? Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Friday, March 21, 2008 11:06 AM To: Brian Rosen Cc: 'Karl Heinz Wolf'; 'Hannes Tschofenig'; ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05 On Mar 21, 2008, at 10:41 AM, Brian Rosen wrote: > Thanks a lot for your comments. I agree with all of your comments > except > the page 10 LoST return of dialstring may/must. I don't think it's > possible > to make it MUST because there are systems such as 3GPP that work > without it. > I could see a SHOULD, where the exception is a closed system where > the LoST > operator knows for certain that all devices that query it have the > correct > dial string via some other mechanism. > > Henning, does that sound about right to you? > I'm ok with documenting a clear exception, but I wonder whether there is harm in requiring that LoST always returns the dial string, for several reasons: - You never know who will connect to a server, even if you believe that it can only be accessed from within a certain physical network. This also tends to change over time; upgrading servers and data sets at that time seems more error-prone, easy to forget and painful. - It doesn't seem particularly onerous to include this information. It's not secret, it's not hard to maintain and it doesn't change. - Longer term, IMS may get more open (see Verizon...), so it may be harder to make the distinction. - It seems difficult to describe the exception in a way that covers what we want without encouraging "bad" behavior. Thus, I think interoperability and robustness argue for MUST. If certain specialized systems end up ignoring the information in favor of local configuration, that's a separate problem. Given that disagreement over the dialstring seems unlikely and obvious, I'd rather have two sources than none. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 25 06:31:08 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9C133A6C73; Tue, 25 Mar 2008 06:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.746 X-Spam-Level: X-Spam-Status: No, score=-100.746 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D58DYQ9f1b6N; Tue, 25 Mar 2008 06:31:08 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15B253A6C1D; Tue, 25 Mar 2008 06:31:08 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C12C33A6B0C for ; Tue, 25 Mar 2008 06:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43tsjOFUoo9i for ; Tue, 25 Mar 2008 06:31:06 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by core3.amsl.com (Postfix) with ESMTP id C5E5E3A699C for ; Tue, 25 Mar 2008 06:31:05 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 19so4160868fkr.5 for ; Tue, 25 Mar 2008 06:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Bse/G5V66rblEKrAYB97k8qasjZmpzg5mrL7xZE8xnE=; b=D16+xqGzbxzoo7a2PdgS+t1LaRYSwZ5ggu7o2H2KUssO32pwPaH4zw4bBczYCJXsy+XYhqRld5MDwD+A6tbuyehGpRLlC75AhhAAPZPq+WTa2frqKuPLT+yfA0w4Gx1ap4FCCwUEUuZwvdSsVMyavp7F2fhpSvNTSq2jlx3N2UA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nfXFi9v5v6zJ1Yl0v3cTbFvq1Qlf4EhQxejDx+GNKAbDgXb+34ABF6ay+R6Jr14gM9quWbaTsTcK24Kz58GBe15S4SgjfxdieqMh/NfSuFWG12A/J9mPiFvp/Tl5OMle9zcsZ1R82+DH4P5NV4n2+7xSm3jjUP9VcQyyAP3lM/w= Received: by 10.82.127.14 with SMTP id z14mr20937025buc.3.1206451725336; Tue, 25 Mar 2008 06:28:45 -0700 (PDT) Received: by 10.82.181.20 with HTTP; Tue, 25 Mar 2008 06:28:45 -0700 (PDT) Message-ID: Date: Tue, 25 Mar 2008 14:28:45 +0100 From: "Karl Heinz Wolf" To: ecrit@ietf.org In-Reply-To: <47CAE9CA.9010901@gmx.net> MIME-Version: 1.0 Content-Disposition: inline References: <47CAE9CA.9010901@gmx.net> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org just a small additional comments on phonebcp: SP-7 says "Proxy Servers MUST recognize emergency dial strings represented by ..." I assume the meaning of this requirement is "if a proxy does dial string recognition on behalf of the client, it MUST accept dial strings represented by ..." Otherwise it is somehow irritating since requirement SP-2 starts with "Proxy Servers SHOULD recognize emergency dial strings ..." SP-24: is "at least one proxy" enough? If the first proxy does not understand the SOS URN, the call may fail. cheers karl heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 25 11:59:20 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3621C3A6C30; Tue, 25 Mar 2008 11:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.518 X-Spam-Level: X-Spam-Status: No, score=-101.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqHUQIRw91+u; Tue, 25 Mar 2008 11:59:20 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6D63A6A81; Tue, 25 Mar 2008 11:59:19 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1CBB3A68C4 for ; Tue, 25 Mar 2008 11:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpI7E2NcQeus for ; Tue, 25 Mar 2008 11:59:16 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 815D83A69B0 for ; Tue, 25 Mar 2008 11:59:16 -0700 (PDT) Received: (qmail invoked by alias); 25 Mar 2008 18:56:55 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp009) with SMTP; 25 Mar 2008 19:56:55 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+eyG9Tgoye7Azk/W4DIl4ZzQMueXz6Oy6PAQCoiT nNiRB7VlQDxICg Message-ID: <47E94B01.8060909@gmx.net> Date: Tue, 25 Mar 2008 20:57:05 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] Meeting Minutes X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org We have uploaded the meeting minutes. You can find them here: http://www.ietf.org/proceedings/08mar/minutes/ecrit.txt Please let us know if you have comments. Currently we only have the meeting minutes provided by Robert. Roger is keeping an eye on Matt to get more detailed minutes. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 25 12:07:05 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88F3A28C5AD; Tue, 25 Mar 2008 12:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZysO-ihYtn6w; Tue, 25 Mar 2008 12:07:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1435D28C14A; Tue, 25 Mar 2008 12:04:56 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611C928C14A for ; Tue, 25 Mar 2008 12:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4e6uMWu4kHqM for ; Tue, 25 Mar 2008 12:04:52 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id 01B9D3A6EFF for ; Tue, 25 Mar 2008 12:03:45 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Tue, 25 Mar 2008 12:01:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Mar 2008 12:01:17 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575096F8EC4@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <47E94B01.8060909@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Meeting Minutes Thread-Index: AciOqgpjiR9NbVMaSzKDQgeifbjLVQAAG8tA References: <47E94B01.8060909@gmx.net> From: "Roger Marshall" To: "Hannes Tschofenig" , Subject: Re: [Ecrit] Meeting Minutes X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I am consolidating the two sets of minutes - and will upload later today. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Hannes Tschofenig > Sent: Tuesday, March 25, 2008 11:57 AM > To: ecrit@ietf.org > Subject: [Ecrit] Meeting Minutes > > We have uploaded the meeting minutes. You can find them here: > http://www.ietf.org/proceedings/08mar/minutes/ecrit.txt > > Please let us know if you have comments. > > Currently we only have the meeting minutes provided by > Robert. Roger is keeping an eye on Matt to get more detailed minutes. > > Ciao > Hannes > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > 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. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 25 15:25:33 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5DFD28C14A; Tue, 25 Mar 2008 15:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.677 X-Spam-Level: X-Spam-Status: No, score=-100.677 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+5v3jp951AU; Tue, 25 Mar 2008 15:25:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C497D3A69AE; Tue, 25 Mar 2008 15:25:32 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0566F3A69AE for ; Tue, 25 Mar 2008 15:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPbu3Sd-ptIm for ; Tue, 25 Mar 2008 15:25:31 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id D4BC33A68CB for ; Tue, 25 Mar 2008 15:25:30 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Tue, 25 Mar 2008 15:22:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Mar 2008 15:21:56 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575096F90E5@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A6575096F8EC4@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Consolidated Meeting Minutes - now posted Thread-Index: AciOqgpjiR9NbVMaSzKDQgeifbjLVQAAG8tAAAXqwgA= References: <47E94B01.8060909@gmx.net> <8C837214C95C864C9F34F3635C2A6575096F8EC4@SEA-EXCHVS-2.telecomsys.com> From: "Roger Marshall" To: "Hannes Tschofenig" , , "Marc Linsner" Subject: [Ecrit] Consolidated Meeting Minutes - now posted X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Consolidated meeting minutes for ECRIT 3/10 meeting have now been posted to the meeting materials page. The file also includes the raw minutes at bottom of file. Thanks to Robert Sparks and Matt Lepinski for generating these minutes. https://datatracker.ietf.org/meeting/71/materials.html -rsm. 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. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 26 00:46:13 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8E8528C4FF; Wed, 26 Mar 2008 00:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.889 X-Spam-Level: X-Spam-Status: No, score=-100.889 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLzW+BFxB6QR; Wed, 26 Mar 2008 00:46:13 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8770528C261; Wed, 26 Mar 2008 00:46:11 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5AC73A6EDE for ; Wed, 26 Mar 2008 00:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARKyXpqj-KXC for ; Wed, 26 Mar 2008 00:46:10 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 08A2B28C4CC for ; Wed, 26 Mar 2008 00:46:04 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so3007575fgg.41 for ; Wed, 26 Mar 2008 00:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=hcFVUk3xty0PKJuofIrmtRrQojQI5VbwJxiCM2i0zB4=; b=mubAKtvpzY2UZeuZreb/kOJE/zIPz9KA2H90K11ZaMKHA7OobuOg1jhveAEoJaml22xStww7EleCUBmkIqHtb5ZuQb3iBXT1OtOBR10s/OkJRj4Pux0aJp4jaj/97T1LYk93EEEqNg0Dknwk3v/Emo5onoj5Re59qzedLVbSZOI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=irIGYpfCFKvPkTh7cX+xujgV6yX9JFpAVwQifpIkOq4Pwn3NUzy5ibQWvtGNicpHY6FcMfKnE7uvBQPWSoYM1ZqHM2AUyaUCicbRP68s6LprSLlYnJ98wSB4Y+rqJI2tCvHX9Ef1k1ovGGqUxTTkF6AvbZAO6roW2C/a/jBFDSI= Received: by 10.82.146.10 with SMTP id t10mr23826282bud.6.1206517422939; Wed, 26 Mar 2008 00:43:42 -0700 (PDT) Received: by 10.82.181.20 with HTTP; Wed, 26 Mar 2008 00:43:42 -0700 (PDT) Message-ID: Date: Wed, 26 Mar 2008 08:43:42 +0100 From: "Karl Heinz Wolf" To: ecrit@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <47CAE9CA.9010901@gmx.net> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org one more thing I just noticed concerning the Request-URI: is it a MUST or a SHOULD for the service URN? ED-4 and ED-62 differ: ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the Request-URI of the INVITE. ED-62 The initial SIP signaling method is an INVITE request: 1. The Request URI SHOULD be the service URN in the "sos" tree, If the device cannot interpert local dial strings, the Request-URI SHOULD be a dial string URI [RFC4967] with the dialed digits. karl heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 26 01:54:09 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA61128C540; Wed, 26 Mar 2008 01:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.532 X-Spam-Level: X-Spam-Status: No, score=-100.532 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_54=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4zFYE+mn3oM; Wed, 26 Mar 2008 01:54:08 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA5CC28C4A8; Wed, 26 Mar 2008 01:54:08 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E821A28C481 for ; Wed, 26 Mar 2008 01:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkvsN9aCcUYQ for ; Wed, 26 Mar 2008 01:54:06 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id A485E28C543 for ; Wed, 26 Mar 2008 01:54:05 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so3027062fgg.41 for ; Wed, 26 Mar 2008 01:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Ixe6Ep6BIok9yZsDsnxwa/hXwCY41c+3Aq5zgURHCtw=; b=eot4ZYiETAUEIqKKLHdPw2um8c62mJvt2hgHoi/I65nY1bRe1D0zzgUbTNf0AkKkpkxKBmQRncFwlq8ucvcAnNBOzVFlfg8M+r1GCPXUqOdn3Z+rZU1gNy7d8YmcyzapdjTyY5zVmTUblxCaLPAECj16O7EEodu85WIubKZuDCg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hk0mhoNw8J/vXHsd9HSZFbu82jPeR71TKfEJV7yVzq1y4KoJC4y93O4FifRUKgXhkB+u6eZCtDWAI/Q4wvDpfQ5+G+COjmMuKPL3/1sQwSvG2QRTU4+ETnIzYt/TGCl8Qu6BpwrBzhXjJv+ArZdIDKvaq7/h3agkGIG743ELPgM= Received: by 10.82.167.9 with SMTP id p9mr23984099bue.7.1206521501066; Wed, 26 Mar 2008 01:51:41 -0700 (PDT) Received: by 10.82.181.20 with HTTP; Wed, 26 Mar 2008 01:51:41 -0700 (PDT) Message-ID: Date: Wed, 26 Mar 2008 09:51:41 +0100 From: "Karl Heinz Wolf" To: "Richard Barnes" In-Reply-To: <47B9A89C.2020704@bbn.com> MIME-Version: 1.0 Content-Disposition: inline References: <47B9A89C.2020704@bbn.com> Cc: ECRIT Subject: Re: [Ecrit] [Fwd: New Version Notification for draft-barnes-ecrit-rough-loc-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Richard, I read your draft and I have a question on section 4.1.: If I understand you correctly, a client using HELD would perform a HELD request, and would get back location by value and by reference at once. The value is imprecise, the reference can be dereferenced to precise location by the PSAP. What if the HELD request is with locationtype civic and exact=true ? The LIS is not allowed to hand out a URI any more, and the client cannot know that the value it gets is imprecise. Or would you suggest that this type of query fails, and the client would have to request a locationURI in a separate request, dereference the URI in the next step to get imprecise location? cheers karl heinz On Mon, Feb 18, 2008 at 4:47 PM, Richard Barnes wrote: > We have posted a draft that explains how imprecise location can be used > for emergency context resolution within the ECRIT framework. > Specifically, we describe how a location provider can determine when a > position is sufficiently precise for emergency call routing, and how > emergency and non-emergency services are delivered in this context. > > While this document may enable a solution to the location-hiding > problem, it can also be useful when a location provider is using > positioning mechanisms that are capable of returning location at various > granularities, with finer-grained location taking more time or resources > to compute. > > --Richard > > > > -------- Original Message -------- > Subject: New Version Notification for draft-barnes-ecrit-rough-loc-00 > Date: Mon, 18 Feb 2008 07:35:55 -0800 (PST) > From: IETF I-D Submission Tool > To: rbarnes@bbn.com > CC: mlepinski@bbn.com > > > A new version of I-D, draft-barnes-ecrit-rough-loc-00.txt has been > successfuly submitted by Richard Barnes and posted to the IETF repository. > > Filename: draft-barnes-ecrit-rough-loc > Revision: 00 > Title: Using Imprecise Location for Emergency Context Resolution > Creation_date: 2008-02-18 > WG ID: Independent Submission > Number_of_pages: 12 > > 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 descibe > how emergency services and non-emergency services can be invoked by > an endpoint that does not have access to its precise location. > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > http://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 26 06:48:12 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A6C128C5DE; Wed, 26 Mar 2008 06:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.583 X-Spam-Level: X-Spam-Status: No, score=-100.583 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KU5AjZ6komiz; Wed, 26 Mar 2008 06:48:10 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98B43A6860; Wed, 26 Mar 2008 06:48:10 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214D13A6802 for ; Wed, 26 Mar 2008 06:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-FgT0KDy+9G for ; Wed, 26 Mar 2008 06:48:08 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 4690D3A65A6 for ; Wed, 26 Mar 2008 06:48:08 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JeVwm-0006wm-LP; Wed, 26 Mar 2008 08:45:44 -0500 From: "Brian Rosen" To: "'Karl Heinz Wolf'" , References: <47CAE9CA.9010901@gmx.net> Date: Wed, 26 Mar 2008 09:45:45 -0400 Message-ID: <02cc01c88f47$b2d01350$58441f0a@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciPFV+JTlTHMp6kTX697qh0HeCuHQAMdwGQ In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org There are two circumstances: 1. The end device does dial plan interpretation. In that case, it puts the Service URN. 2. The end device does not do dial plan interpretation. In that case the proxy does it, and puts in the Service URN. The result of both cases is that there is a Service URN. That is ED-4/SP-3. ED-62 differentiates the cases for the end device. We could improve the text by writing a more complex ED-4/SP-3. If that is deemed important, I'll propose text. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Karl Heinz Wolf Sent: Wednesday, March 26, 2008 3:44 AM To: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 one more thing I just noticed concerning the Request-URI: is it a MUST or a SHOULD for the service URN? ED-4 and ED-62 differ: ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the Request-URI of the INVITE. ED-62 The initial SIP signaling method is an INVITE request: 1. The Request URI SHOULD be the service URN in the "sos" tree, If the device cannot interpert local dial strings, the Request-URI SHOULD be a dial string URI [RFC4967] with the dialed digits. karl heinz _______________________________________________ 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 ecrit-bounces@ietf.org Wed Mar 26 11:12:49 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F380C3A692C; Wed, 26 Mar 2008 11:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.588 X-Spam-Level: X-Spam-Status: No, score=-100.588 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_HIRISK_FORGED_ATT=0.184, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45j4+xdPzobG; Wed, 26 Mar 2008 11:12:44 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45D83A6F66; Wed, 26 Mar 2008 11:12:43 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E896A3A6DF1 for ; Wed, 26 Mar 2008 11:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6weMvW-hB73 for ; Wed, 26 Mar 2008 11:11:55 -0700 (PDT) Received: from aismt06p.bellsouth.com (aismt06p.bellsouth.com [139.76.165.211]) by core3.amsl.com (Postfix) with ESMTP id 493A63A6CC9 for ; Wed, 26 Mar 2008 11:11:52 -0700 (PDT) Received: from ([139.76.131.79]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.43705826; Wed, 26 Mar 2008 14:09:00 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 26 Mar 2008 14:09:00 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 26 Mar 2008 14:08:59 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Mar 2008 14:08:59 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA080EC99D@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of framework-05 thread-index: AciPbHZIl8H9YFdMR2uRYLvXnRwfIQ== From: "Stark, Barbara" To: X-OriginalArrivalTime: 26 Mar 2008 18:08:59.0960 (UTC) FILETIME=[773A2B80:01C88F6C] Subject: [Ecrit] Review of framework-05 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I only have minor comments and editorial nits. This is in great shape. Barbara Minor comments -------------- 1. Section 6.1, "Postal" definition, last sentence "There is no other accommodation for postal addresses in these protocols." I thought there was a spot for the postal code. Wouldn't that be an accommodation for postal addresses? And that postal code is very useful in the overall validation process of civic locations in the US. 2. Section 6.6, last paragraph "NENA recommends IP based systems complete calls in two seconds (i.e., last dial press to ring at PSAP)." Is there a reference to a NENA doc for this recommendation? 3. Section 6.10, 2nd paragraph, last sentence "Test functions (Section 15) should also re-validate." I didn't completely understand this. Is this trying to say that when an end device is doing its test function, that its LoST request needs to request validation? Or is there something that the PSAP test function is supposed to do? 4. Section 16 Need to note the note, and delete it when done. "Ed. Note: go through that doc and make sure any actions needed are captured in the BCP text." Editorial nits -------------- Section 3, first paragraph "..., which maps a location to a set of PSAP or URIs." Delete "or" "...that serves an incoming proxy for group..." Change to "...that serves as an incoming proxy for a group..." Section 3, last line of Figure 2 Change "propogated" to "propagated" Section 5, 2nd paragraph "...or visited dialing strings..." change to "...or visited dial strings..." Section 6.1, location types Instead of "Jurisdictional this..." and "Postal this...", maybe use a colon and repeat the word being defined. Section 6.2.3, 2nd paragraph "...but need a "cold start period lasting more than a couple seconds on need..." Delete """ and "on". Section 6.5, 2nd to last paragraph "See Section Section 6.8..." delete extra "Section" Section 6.6, 2nd paragraph "1,000,00" should be "1,000,000" Section 6.8, 1st paragraph, 1s sentence Change "make" to "may" Section 6.8, last paragraph "The LIS is should be aware..." Delete "is" Section 6.9, 1st paragraph "Handling multiple locations is discussed in ." Needs reference to phonebcp "It is permissable to send multiple locations towards the PSAP, but the element that choses the route..." "permissable" is "permissible" and "choses" is "chooses" Section 8, 5th paragraph from the end "...it should use this cached value." Change "this" to "its". There is no antecedent for "this". ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 27 03:19:15 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ACAC3A6FA3; Thu, 27 Mar 2008 03:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.671 X-Spam-Level: X-Spam-Status: No, score=-100.671 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2EHH1Lpw2x1; Thu, 27 Mar 2008 03:19:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7043E3A6F98; Thu, 27 Mar 2008 03:19:14 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D4BD3A6F88 for ; Thu, 27 Mar 2008 03:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVl7tkKaOr56 for ; Thu, 27 Mar 2008 03:19:09 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 4A1133A6A9D for ; Thu, 27 Mar 2008 03:19:09 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so3441691fgg.41 for ; Thu, 27 Mar 2008 03:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ocHcXL7iW7DXVVoLWYRyUh+UXFDDw9MKg0ik/LT8Tbk=; b=SmB8qKDvolypOhyyTCTiNXfL/Z0rkyywdvMYTYAQbjx5WJeWrUafSPHmEEmW2gvuvfHPPHotOTYrJ/Og9dAp+V2zYJd18QWMTkfixnDqcQc5wNOPMGasP6Nqo5Ib4XlFxfYTx0BMGZsrXiaC/R1B2h0pZUlNezawiRXLzKmrt4Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WArHCUDu6Rsus72LzExGiXvYOQzvX/zO0dZ3MzChe/pCT0SY65wPpz6N/DVHmaALUMT4p6vKGnGjqvGg0mTaMlBvGVTV71gn5y+in3wzURBee2hUzzXo8dqf7TMe9PvdtzEf9bNKaZclnUlgIIOMOd6Bior/eYSGM6mo6B2mhDk= Received: by 10.82.158.12 with SMTP id g12mr1637041bue.39.1206613000240; Thu, 27 Mar 2008 03:16:40 -0700 (PDT) Received: by 10.82.181.20 with HTTP; Thu, 27 Mar 2008 03:16:40 -0700 (PDT) Message-ID: Date: Thu, 27 Mar 2008 11:16:40 +0100 From: "Karl Heinz Wolf" To: "Brian Rosen" In-Reply-To: <02cc01c88f47$b2d01350$58441f0a@cis.neustar.com> MIME-Version: 1.0 Content-Disposition: inline References: <47CAE9CA.9010901@gmx.net> <02cc01c88f47$b2d01350$58441f0a@cis.neustar.com> Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Wed, Mar 26, 2008 at 2:45 PM, Brian Rosen wrote: > There are two circumstances: > 1. The end device does dial plan interpretation. In that case, it puts the > Service URN. > > 2. The end device does not do dial plan interpretation. In that case the > proxy does it, and puts in the Service URN. > > The result of both cases is that there is a Service URN. That is ED-4/SP-3. > ED-62 differentiates the cases for the end device. > > We could improve the text by writing a more complex ED-4/SP-3. If that is > deemed important, I'll propose text. thank you for your explanation, Brian. So ED-4/SP-3 does not say who marks the call, but it requires that someone (ED/SP) marks the call. The way I understand the first part of ED-62 now is: "the Request URI MUST be the service URN in the "sos" tree if the device interprets dial strings. If the device cannot interpret local dial strings, the Request-URI SHOULD be a dial string URI [RFC4967] with the dialed digits." Is this correct? karl heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 28 12:14:32 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B12A3A6BE5; Fri, 28 Mar 2008 12:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.84 X-Spam-Level: X-Spam-Status: No, score=-100.84 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_HIRISK_FORGED_ATT=0.184, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNZLlETXka+H; Fri, 28 Mar 2008 12:14:30 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4FDF3A6D14; Fri, 28 Mar 2008 12:14:30 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8555F3A6BE5 for ; Fri, 28 Mar 2008 12:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Erd7fUxor4kv for ; Fri, 28 Mar 2008 12:14:29 -0700 (PDT) Received: from aismt06p.bellsouth.com (aismt06p.bellsouth.com [139.76.165.211]) by core3.amsl.com (Postfix) with ESMTP id 150733A691C for ; Fri, 28 Mar 2008 12:14:28 -0700 (PDT) Received: from ([139.76.131.31]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.43916120; Fri, 28 Mar 2008 15:13:52 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 28 Mar 2008 15:13:52 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 28 Mar 2008 15:13:53 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Mar 2008 15:13:52 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA080ECE5C@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: phonebcp-04 comments thread-index: AciRB9vLHaJTnHq9Q0yXx0elTeXdwA== From: "Stark, Barbara" To: X-OriginalArrivalTime: 28 Mar 2008 19:13:53.0195 (UTC) FILETIME=[DC9A2FB0:01C89107] Subject: [Ecrit] phonebcp-04 comments X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Here are my phonebcp-04 comments. I don't have any major comments. Slightly substantive comments and Questions ------------------------------------------- 1. AN-10 Access networks with range of <10 meters MUST provide a location to mobile devices connected to it. The location provided SHOULD be that of the access point location unless a more accurate mechanism is provided. Is this referring to a PAN wireless technology (like Bluetooth)? I had trouble envisioning the type of access network it was referring to. Maybe an e.g. would be useful? 2. ED-25/INT-18 Endpoints SHOULD obtain location immediately after obtaining local network configuration information. When HELD is the LCP the client MUST support a random back-off period (between 30 seconds and 300 seconds) for re-trying the HELD query, when no response is received Recommend adding the following phrase at the end of the last sentence ", and no other LCP provided location information." HELD doesn't need to be retried if another LCP was successful. 3. ED-37/AN-20 Recommend the following change: "For other location-by-reference schemes, the PSAP will have to repeatedly dereference the URI to determine if the device moved." becomes "For other location-by-reference schemes that do not support subscription, the PSAP will have to repeatedly dereference the URI to determine if the device moved." It is conceivable that another subscription-based L-by-R scheme might be invented, sometime in the future. 4. ED-41/SP-20 Recommend slight rewording, because it's currently recommended that all locations be validated with LoST. "The "used-for-routing" parameter MUST be set to the location that was used to query LoST" "The "used-for-routing" parameter MUST be set to the location that was chosen for routing." 5. Section 7 Recommend an additional requirement that states something like: "AN-xx Access Networks that use HELD and that have a DHCP server SHOULD (MAY?) support DHCP options for providing LIS and LoST servers." 6. ED-62 5. "A Route header SHOULD be present with a PSAP URI obtained from LoST (see Section 8) and the loose route parameter." The loose route parameter part of this really confused me. Is this saying that the loose route parameter should be present in the Route header? If so, is it suggesting there is a requirement on the End Device to validate for the presence of lr, and insert it if it isn't there? Or is it expected that URIs sent by LoST will simply include the lr parameter? If the expectation is for the LoST server, then that needs to go in the LoST doc, and not in and ED requirement. If the expectation is for the LoST server, I recommend deleting " and the loose route parameter", because the ED simply includes the URI exactly as provided by LoST. If the expectation is that the ED ensure the presence of the lr parameter, then this needs to be explicitly stated. 7. Section 10 I thought "uninitialized devices" had been gotten rid of. Framework-05 doesn't mention them in Section 10. If this term is going to be used, it needs to be defined. Minor comments -------------- AN-6/INT-6 "upstream" -> "downstream" ED-17/INT-8/AN-7 and AN-9 Is phrase "at all times" needed? Doesn't MUST imply that? ED-53 Recommend changing the end: "...MUST use the cached value if it has one." -> "MUST use the cached value. If there is no cached value, it MUST signal an emergency call without a Route header." SP-32 2. "a Route header with a PSAP URI, it MUST run LoST routing." -> "a Route header, it MUST query a LoST server. If multiple locations were provided, the proxy uses the location that has the "used-for-routing" marker set." (SP doesn't check for a PSAP URI in the Route header -- it checks for the existance of a Route header with something in it. Need to handle the multiple location scenario.) ED-73 Recommend the following wording change, since, theoretically, any SIP device can be used anywhere, which would make mu Law a MUST according to the current wording. "(and mu Law if they could be used in North America)" -> "(and mu Law if they are intended to be used in North America)" Editorial nits -------------- Section 2, 1st paragraph "devicesand" -> "devices and" (needs space) Section 2, 2nd paragraph "(see Section 6" -> "(see Section 6)" (needs close parenthesis) Section 3, 1st pargraph "URN[I-D.ietf-ecrit-service-urn]" -> "URN [I-D.ietf-ecrit-service-urn]" (needs space) Section 4, header "emergency calls" -> "emergency calls" (extra space) SP-2 "dial string" -> "dial strings" AN-10 "it" -> "them" ("Access networks" is plural) ED-18/INT-9 "do" -> "attempt to" ED-19/INT-10/SP-13 "the the" -> "the" ED-25/INT-18 "information.When" -> "information. When" ED-28/INT-21 Delete 2nd instance of "VPNs" ED-44/AN-24 Reference that belongs after "...SHOULD use" somehow got moved to the end of the paragraph. ED-49 "by service provider" -> "by a service provider" ED-60/AN-25 "minimise" -> "minimize" ED-61/AN-26 "retrieveal" -> "retrieval" ED-62 "interpert" -> "interpret" ED-62 2. "cannot do interpret" -> "cannot interpret" ED-62 5. "interpet" -> "interpret", "serverr" -> "server" ED-62 14. "headers ." -> "headers." SP-32 1. "does interprets" -> either "does interpret" or "interprets" Section 10 "unitialized" -> "uninitialized" (both instances, if this word is to be used) ED-67/SP-37 "proxys" -> "proxies" ED-68/SP-38 "dialstrings" -> "dial strings" ED-75 "IM" -> "Instant Messaging (IM)" ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 28 12:45:11 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1267A28C3AB; Fri, 28 Mar 2008 12:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.472 X-Spam-Level: X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGxuJtdvvfcO; Fri, 28 Mar 2008 12:45:05 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63C9228C3D9; Fri, 28 Mar 2008 12:45:05 -0700 (PDT) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 66DDF28C392; Fri, 28 Mar 2008 12:45:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080328194501.66DDF28C392@core3.amsl.com> Date: Fri, 28 Mar 2008 12:45:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-08.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : LoST: A Location-to-Service Translation Protocol Author(s) : T. Hardie, et al. Filename : draft-ietf-ecrit-lost-08.txt Pages : 78 Date : 2008-03-28 This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-lost-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-03-28124228.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Fri Mar 28 13:00:05 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FA5A28CA3D; Fri, 28 Mar 2008 13:00:05 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDUhfrDSfKOn; Fri, 28 Mar 2008 13:00:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 134DB28C3F5; Fri, 28 Mar 2008 13:00:04 -0700 (PDT) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8DC333A691C; Fri, 28 Mar 2008 13:00:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080328200001.8DC333A691C@core3.amsl.com> Date: Fri, 28 Mar 2008 13:00:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-09.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : LoST: A Location-to-Service Translation Protocol Author(s) : T. Hardie, et al. Filename : draft-ietf-ecrit-lost-09.txt Pages : 78 Date : 2008-03-28 This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-lost-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-03-28125739.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Sat Mar 29 11:11:55 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5AB03A6EDF; Sat, 29 Mar 2008 11:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.571 X-Spam-Level: X-Spam-Status: No, score=-100.571 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kI0JUqGVcfd; Sat, 29 Mar 2008 11:11:53 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F26AC3A6BE0; Sat, 29 Mar 2008 11:11:52 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 869533A6BE0 for ; Sat, 29 Mar 2008 11:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoQPzvBTq+se for ; Sat, 29 Mar 2008 11:11:49 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 130AC3A6C5D for ; Sat, 29 Mar 2008 11:11:48 -0700 (PDT) Received: (qmail invoked by alias); 29 Mar 2008 18:11:46 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp048) with SMTP; 29 Mar 2008 19:11:46 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18zM950KSMzS22K5wXDloKRwr7XGC2vo8XsGJrGyJ Mxso08EPjgnpNn Message-ID: <47EE865D.5000404@gmx.net> Date: Sat, 29 Mar 2008 20:11:41 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] Location Hiding Requirements & Problem Statement X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At the last IETF meeting we had a discussion about the next steps regarding the draft-schulzrinne-ecrit-location-hiding-req "Location Hiding: Problem Statement and Requirements" document. The suggestion of a few folks was to add to extend the document before it may become a WG item. More specifically, folks suggested to discuss solution approaches in that document. Two questions to the group before the document editing starts: a) Who thinks it is appropriate to discuss various solutions in this problem statement and requirements document? As I understood it from the feedback of the group the plan was to match requirements against certain solutions. b) If you think (a) is useful then let us know what solutions you would like to see discussed. To make it easier for you we have created a Wiki page with a couple of solutions, see http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/LocationHiding I have once sent a mail to the list with many more proposal. It can be found here: http://www1.ietf.org/mail-archive/web/ecrit/current/msg03482.html Please help us to get the topic moving forward. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 07:06:28 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55FB33A6D2F; Sun, 30 Mar 2008 07:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.6 X-Spam-Level: X-Spam-Status: No, score=-100.6 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Qo7v2CTc5Qz; Sun, 30 Mar 2008 07:06:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ABF33A6A3E; Sun, 30 Mar 2008 07:06:27 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A763B3A67AC for ; Sun, 30 Mar 2008 07:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXxR7Ey3llnT for ; Sun, 30 Mar 2008 07:06:25 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 949EF3A6A3E for ; Sun, 30 Mar 2008 07:06:25 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2008 14:06:22 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp011) with SMTP; 30 Mar 2008 16:06:22 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+ik7dfVSiiz9y3YOYVdteLEhw4C9zze8YIGlt148 gJblmEU/aToqjg Message-ID: <47EF9E5A.2050302@gmx.net> Date: Sun, 30 Mar 2008 17:06:18 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] ECRIT Framework Review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I reviewed the draft and noticed a few minor issues. Overall the document is in good shape. I will distribute the issues in separate mails. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 07:06:32 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 802303A6D7C; Sun, 30 Mar 2008 07:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.599 X-Spam-Level: X-Spam-Status: No, score=-100.599 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SzWJip41FTH; Sun, 30 Mar 2008 07:06:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4C003A6D2F; Sun, 30 Mar 2008 07:06:31 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 219603A6C61 for ; Sun, 30 Mar 2008 07:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nl+nU2Q3sY12 for ; Sun, 30 Mar 2008 07:06:29 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DB1AE3A6BE2 for ; Sun, 30 Mar 2008 07:06:28 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2008 14:06:26 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp008) with SMTP; 30 Mar 2008 16:06:26 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+ZvUFRKRuZ0VkT87VSPKZX1BcNMbKBnaW/LRjkTf z3K2QxF/zLWtdC Message-ID: <47EF9E5E.9000205@gmx.net> Date: Sun, 30 Mar 2008 17:06:22 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] ECRIT Framework: Disabling of features X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org You write: " A UA can determine a PSAP call back by examining the domain of incoming calls after placing an emergency call and comparing that to the domain of the answering PSAP from the emergency call. " You might want to say "A UA and a proxy can determine ..." This is necessary to say that in order to address the case where authorization policies are enforced at a proxy rather than at a UA only. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 07:06:37 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 200B73A6D10; Sun, 30 Mar 2008 07:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.6 X-Spam-Level: X-Spam-Status: No, score=-100.6 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14jo2SkFPy4x; Sun, 30 Mar 2008 07:06:36 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062CF3A6D6C; Sun, 30 Mar 2008 07:06:35 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FDE73A6BE2 for ; Sun, 30 Mar 2008 07:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pITlETnuvWFh for ; Sun, 30 Mar 2008 07:06:32 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 913E53A6C61 for ; Sun, 30 Mar 2008 07:06:31 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2008 14:06:29 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp004) with SMTP; 30 Mar 2008 16:06:29 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18SW3EmSFESU4KjMyVBQvB2SP3PgzQveFv3rFz5cU eWYFC48axTknhO Message-ID: <47EF9E62.6090609@gmx.net> Date: Sun, 30 Mar 2008 17:06:26 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] ECRIT Framework: Security X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org You write: " IPSEC [RFC2401] is an acceptable alternative to TLS when used with an equivalent crypto suite. " I guess you mean that IPsec **between proxies** provides equivalent security compared to TLS. I don't think you suggest to run IPsec from the end host to the proxy You write: " Location may be used for routing by multiple proxy servers on the path. Confidentiality mechanisms such as S/MIME encryption of SIP signaling [RFC3261] cannot be used because they obscure location. Only hop-by-hop mechanisms such as TLS should be used. Many SIP devices do not support TLS. Implementing location conveyance in SIP mandates inclusion of TLS support. " You might want to be a bit more specific. S/MIME encryption of PIDF-LOs must not be used when proxies are supposed to perform location based routing. They need to be able to inspect the PIDF-LO in order todo their job. Delete " Many SIP devices do not support TLS." since it does not add too much value here. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 07:06:40 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6E9C28C16E; Sun, 30 Mar 2008 07:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.609 X-Spam-Level: X-Spam-Status: No, score=-100.609 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ozE-Hd2I5pX; Sun, 30 Mar 2008 07:06:40 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D78828C14C; Sun, 30 Mar 2008 07:06:39 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 092B33A6D6C for ; Sun, 30 Mar 2008 07:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBY7gKhzBz79 for ; Sun, 30 Mar 2008 07:06:37 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 23EC43A6BE2 for ; Sun, 30 Mar 2008 07:06:35 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2008 14:06:33 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp026) with SMTP; 30 Mar 2008 16:06:33 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18JhQsYHEQJVXRGN6roLwrGQDg85xsEsTxppAVkuZ 9pKFHCMPW9eQ7T Message-ID: <47EF9E65.1090402@gmx.net> Date: Sun, 30 Mar 2008 17:06:29 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] ECRIT Framework: Dial Strings X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org You write: " Therefore, the visited dial string must work while having the home dial string work is optional. " I don't understand this reasoning on why the home dial string is optional. From an implementation point of view you have to implement the home emergency dial strings since in most cases devices will be used "at home". Why isn't the ability to understand the home dial string mandatory? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 07:06:48 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0E33A6DA5; Sun, 30 Mar 2008 07:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.614 X-Spam-Level: X-Spam-Status: No, score=-100.614 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKhsZUGohvVW; Sun, 30 Mar 2008 07:06:47 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989333A6C61; Sun, 30 Mar 2008 07:06:47 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AC593A6A3E for ; Sun, 30 Mar 2008 07:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ictFM4TAX9GV for ; Sun, 30 Mar 2008 07:06:46 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9EDD228C22B for ; Sun, 30 Mar 2008 07:06:45 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2008 14:06:42 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp013) with SMTP; 30 Mar 2008 16:06:42 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX190YZoXeeZ02amr2HiTmevmp+0dITK+HOZ8DhzPby HP6Fk1bm441x40 Message-ID: <47EF9E6E.5030904@gmx.net> Date: Sun, 30 Mar 2008 17:06:38 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] ECRIT Framework: UI Issues X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org You write: " Note: It is undesirable to have a single button emergency call user interface element. These mechanisms tend to result in a very high rate of false or accidental emergency calls. In order to minimize this rate, devices should only initiate emergency calls based on entry of specific emergency call dial strings. " I agree with you but is this really an issue for such a document? UI issues are typically outside the scope of the IETF work. We have even learned that UK dial string is not ideally from a UI issue either. Still, we cannot argue that is has to be discontinued since this is not our job. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 07:07:46 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E32503A6D4B; Sun, 30 Mar 2008 07:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.619 X-Spam-Level: X-Spam-Status: No, score=-100.619 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYdJTo4khFvd; Sun, 30 Mar 2008 07:07:46 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E5423A6C61; Sun, 30 Mar 2008 07:07:46 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 831F73A6C61 for ; Sun, 30 Mar 2008 07:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krmdly7jmXpf for ; Sun, 30 Mar 2008 07:07:43 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2CD0D3A6A3E for ; Sun, 30 Mar 2008 07:07:43 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2008 14:07:41 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp015) with SMTP; 30 Mar 2008 16:07:41 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19vStgiMGRvdsPLsluI8yZLQ5+iAWrhFxG0Pb9/Fx kAONf2ew9eWzHw Message-ID: <47EF9EA9.8080703@gmx.net> Date: Sun, 30 Mar 2008 17:07:37 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] ECRIT Framework: Terminology X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org You have to state where you take the terminology from unless it is your own term. For example, "confidence" and "uncertainty" are most likely not your terms (at least I hope so). When you copy-and-paste a term then you need to put it in "..." followed by a reference. For example, ESRP and LIS. Please go through the terminology section and add proper references where needed. Delete the following paragraph: " The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. " _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 07:08:27 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 423D53A6D4B; Sun, 30 Mar 2008 07:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.621 X-Spam-Level: X-Spam-Status: No, score=-100.621 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQ-bXp5vODuu; Sun, 30 Mar 2008 07:08:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B8583A6D0B; Sun, 30 Mar 2008 07:08:26 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A863A6D0B for ; Sun, 30 Mar 2008 07:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id so50KK1g68vn for ; Sun, 30 Mar 2008 07:08:24 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C1DD23A6CEF for ; Sun, 30 Mar 2008 07:08:23 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2008 14:08:21 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp057) with SMTP; 30 Mar 2008 16:08:21 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18U6p0SeOAUilgsWCoIwDS+SS6v4s7n/wFBfDzpJ6 FifpTZq/asnSlK Message-ID: <47EF9ED2.7000503@gmx.net> Date: Sun, 30 Mar 2008 17:08:18 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] ECRIT Framework: References X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The document contains a number of normative references. I wonder whether this is indeed necessary. Why cannot you just have a single normative reference, namely to the Phone BCP document. The rest is informative? If you don't do that then we have a lot of dependencies and a huge number of downrefs. Two references are not up-to-date: * [I-D.ietf-ecrit-service-urn]: RFC 5031 * [I-D.thomson-geopriv-lis-discovery]: it is already a WG item. == Unused Reference: 'RFC3263' is defined on line 1514, but no explicit reference was found in the text == Unused Reference: 'RFC3265' is defined on line 1522, but no explicit reference was found in the text == Unused Reference: 'RFC3311' is defined on line 1525, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4507 (Obsoleted by RFC 5077) ** Obsolete normative reference: RFC 4676 (Obsoleted by RFC 4776) Delete reference RFC 2119 You write: " NENA recommends IP based systems complete calls in two seconds (i.e., last dial press to ring at PSAP). " Reference to a NENA document that says that is missing. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 07:09:46 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2C353A6D10; Sun, 30 Mar 2008 07:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.641 X-Spam-Level: X-Spam-Status: No, score=-101.641 tagged_above=-999 required=5 tests=[AWL=0.796, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lN-0D4NXxWJj; Sun, 30 Mar 2008 07:09:45 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D20733A6D36; Sun, 30 Mar 2008 07:09:45 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A49F3A6D36 for ; Sun, 30 Mar 2008 07:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o18+uLnoSOmq for ; Sun, 30 Mar 2008 07:09:44 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id CF7043A6A3E for ; Sun, 30 Mar 2008 07:09:38 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2008 14:09:37 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp036) with SMTP; 30 Mar 2008 16:09:37 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19oA48ANOZor3ptviB4+RdGdGZRJzlUQNAXhPXGdM UuwXOt/JDIx6yf Message-ID: <47EF9F1D.8000509@gmx.net> Date: Sun, 30 Mar 2008 17:09:33 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] ECRIT Framework: Editorial X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org * The contact info of Andy Newton is not up-to-date * There is no IANA Considerations section in the document. * A few things from IDNITs == Line 387 has weird spacing: '...URI and dial ...' == Line 641 has weird spacing: '...ctional this ...' == Line 643 has weird spacing: '... Postal this ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. s/Section Section 6.10/Section 6.10 s/WiMAX/Wimax s/WiMaX/Wimax s/Section Section 6.8/Section 6.8 s/is should be aware/should be aware s/Never the less/Nevertheless Each section heading has to have capitialized letters. This makes the job of the RFC Editor easier. They cost money! For example, s/6.2.1 User-entered location information/ User-Entered Location Informatoin Incomplete sentence: " Handling multiple locations is discussed in . " _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 11:22:33 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FCAD3A69AB; Sun, 30 Mar 2008 11:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.457 X-Spam-Level: X-Spam-Status: No, score=-100.457 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuOwCZCsa1q7; Sun, 30 Mar 2008 11:22:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71CED28C301; Sun, 30 Mar 2008 11:22:31 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE863A683E for ; Sun, 30 Mar 2008 11:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HR1Ilnp1YpSP for ; Sun, 30 Mar 2008 11:22:29 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id D217628C29C for ; Sun, 30 Mar 2008 11:20:47 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jg292-0007GG-3I; Sun, 30 Mar 2008 13:20:40 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , References: <47EF9E5E.9000205@gmx.net> Date: Sun, 30 Mar 2008 14:20:48 -0400 Message-ID: <005f01c89292$c90704a0$9744f444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47EF9E5E.9000205@gmx.net> Thread-Index: AciSbz/UINSSKbO0QKazqZYHGi4pNAAI3ukQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] ECRIT Framework: Disabling of features X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Maybe "or a proxy", but sure. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 10:06 AM To: ecrit@ietf.org Subject: [Ecrit] ECRIT Framework: Disabling of features You write: " A UA can determine a PSAP call back by examining the domain of incoming calls after placing an emergency call and comparing that to the domain of the answering PSAP from the emergency call. " You might want to say "A UA and a proxy can determine ..." This is necessary to say that in order to address the case where authorization policies are enforced at a proxy rather than at a UA only. _______________________________________________ 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 ecrit-bounces@ietf.org Sun Mar 30 11:26:32 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8613D28C21E; Sun, 30 Mar 2008 11:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.523 X-Spam-Level: X-Spam-Status: No, score=-100.523 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uv3JP73rJicg; Sun, 30 Mar 2008 11:26:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0B2428C2E9; Sun, 30 Mar 2008 11:26:25 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 407D128C1AB for ; Sun, 30 Mar 2008 11:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMtIdbPGEH7x for ; Sun, 30 Mar 2008 11:26:22 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id ACA2A28C350 for ; Sun, 30 Mar 2008 11:25:34 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jg2De-0007cH-Te; Sun, 30 Mar 2008 13:25:27 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , References: <47EF9E62.6090609@gmx.net> Date: Sun, 30 Mar 2008 14:25:34 -0400 Message-ID: <006001c89293$740e4840$9744f444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47EF9E62.6090609@gmx.net> Thread-Index: AciSb0XK31IL/Qg9SwGqffNImzemTQAI4Qsw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] ECRIT Framework: Security X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I certainly wouldn't think it was all that common, but IPsec would work between a proxy and a UA, right? With regard to "Many SIP devices...", despite the fact that 3261 says they should, many UAs don't. That's a fact. We need them to in order to handle location privacy. I think it's worth pointing that out. This is requesting a change in implementations. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 10:06 AM To: ecrit@ietf.org Subject: [Ecrit] ECRIT Framework: Security You write: " IPSEC [RFC2401] is an acceptable alternative to TLS when used with an equivalent crypto suite. " I guess you mean that IPsec **between proxies** provides equivalent security compared to TLS. I don't think you suggest to run IPsec from the end host to the proxy You write: " Location may be used for routing by multiple proxy servers on the path. Confidentiality mechanisms such as S/MIME encryption of SIP signaling [RFC3261] cannot be used because they obscure location. Only hop-by-hop mechanisms such as TLS should be used. Many SIP devices do not support TLS. Implementing location conveyance in SIP mandates inclusion of TLS support. " You might want to be a bit more specific. S/MIME encryption of PIDF-LOs must not be used when proxies are supposed to perform location based routing. They need to be able to inspect the PIDF-LO in order todo their job. Delete " Many SIP devices do not support TLS." since it does not add too much value here. _______________________________________________ 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 ecrit-bounces@ietf.org Sun Mar 30 11:34:39 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108AA28C39D; Sun, 30 Mar 2008 11:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.579 X-Spam-Level: X-Spam-Status: No, score=-100.579 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyfRPRz8kWRa; Sun, 30 Mar 2008 11:34:38 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5356C3A67D5; Sun, 30 Mar 2008 11:34:38 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3E8E28C29C for ; Sun, 30 Mar 2008 11:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4x3Px+pMbkd for ; Sun, 30 Mar 2008 11:34:36 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 35A413A67D5 for ; Sun, 30 Mar 2008 11:34:36 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jg2MO-0008Rl-D6; Sun, 30 Mar 2008 13:34:28 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , References: <47EF9E65.1090402@gmx.net> Date: Sun, 30 Mar 2008 14:34:32 -0400 Message-ID: <006101c89294$b45036b0$9744f444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47EF9E65.1090402@gmx.net> Thread-Index: AciSb0jFlOgz5NA4RaqbA9nfmYGMvgAJC8bw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] ECRIT Framework: Dial Strings X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org No current systems recognize the home dial string unless they happen to be the same, or there is some fixed strings always recognized. There are legal requirements for the local one, and there are none for the home one. Unless you have some good reason, I think there is no requirement to support the home dial string. I'm not even sure it's a good idea. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 10:06 AM To: ecrit@ietf.org Subject: [Ecrit] ECRIT Framework: Dial Strings You write: " Therefore, the visited dial string must work while having the home dial string work is optional. " I don't understand this reasoning on why the home dial string is optional. From an implementation point of view you have to implement the home emergency dial strings since in most cases devices will be used "at home". Why isn't the ability to understand the home dial string mandatory? _______________________________________________ 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 ecrit-bounces@ietf.org Sun Mar 30 11:36:43 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C1033A6C2D; Sun, 30 Mar 2008 11:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.583 X-Spam-Level: X-Spam-Status: No, score=-100.583 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPkFsVIWUwxJ; Sun, 30 Mar 2008 11:36:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D08E28C1DB; Sun, 30 Mar 2008 11:36:42 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E40853A6809 for ; Sun, 30 Mar 2008 11:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iKHM+2Qy+AG for ; Sun, 30 Mar 2008 11:36:40 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 33D2F3A6767 for ; Sun, 30 Mar 2008 11:36:40 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jg2OO-0000KD-If; Sun, 30 Mar 2008 13:36:32 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , References: <47EF9E6E.5030904@gmx.net> Date: Sun, 30 Mar 2008 14:36:29 -0400 Message-ID: <006201c89294$fe016ae0$9744f444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47EF9E6E.5030904@gmx.net> Thread-Index: AciSb0xZCArqYgKXSguheHUcOxb64QAJW/1g X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] ECRIT Framework: UI Issues X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org There is no other place to put this information. If you were an implementor, would you not wish to know that what your intuition suggests may be a good idea, is probably not? This is not a protocol spec. It's Best Current Practice. This issues is definitely a best current practice. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 10:07 AM To: ecrit@ietf.org Subject: [Ecrit] ECRIT Framework: UI Issues You write: " Note: It is undesirable to have a single button emergency call user interface element. These mechanisms tend to result in a very high rate of false or accidental emergency calls. In order to minimize this rate, devices should only initiate emergency calls based on entry of specific emergency call dial strings. " I agree with you but is this really an issue for such a document? UI issues are typically outside the scope of the IETF work. We have even learned that UK dial string is not ideally from a UI issue either. Still, we cannot argue that is has to be discontinued since this is not our job. _______________________________________________ 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 ecrit-bounces@ietf.org Sun Mar 30 11:43:27 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BFCC28C2E9; Sun, 30 Mar 2008 11:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.602 X-Spam-Level: X-Spam-Status: No, score=-100.602 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0NtIKCyyWus; Sun, 30 Mar 2008 11:43:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE1443A67D5; Sun, 30 Mar 2008 11:43:26 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAE6C3A67D5 for ; Sun, 30 Mar 2008 11:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhK5sPsyJX9U for ; Sun, 30 Mar 2008 11:43:25 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id F230F3A6767 for ; Sun, 30 Mar 2008 11:43:24 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jg2Uv-0001D8-68; Sun, 30 Mar 2008 13:43:17 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , References: <47EF9EA9.8080703@gmx.net> Date: Sun, 30 Mar 2008 14:43:19 -0400 Message-ID: <006301c89295$eeac97d0$9744f444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47EF9EA9.8080703@gmx.net> Thread-Index: AciSb2yIgZZQej0xRfSG7JSDT9QQeAAJn2xA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] ECRIT Framework: Terminology X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Okay -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 10:08 AM To: ecrit@ietf.org Subject: [Ecrit] ECRIT Framework: Terminology You have to state where you take the terminology from unless it is your own term. For example, "confidence" and "uncertainty" are most likely not your terms (at least I hope so). When you copy-and-paste a term then you need to put it in "..." followed by a reference. For example, ESRP and LIS. Please go through the terminology section and add proper references where needed. Delete the following paragraph: " The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. " _______________________________________________ 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 ecrit-bounces@ietf.org Sun Mar 30 11:45:24 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4BC83A67D5; Sun, 30 Mar 2008 11:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.599 X-Spam-Level: X-Spam-Status: No, score=-100.599 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCw2saDAyKuy; Sun, 30 Mar 2008 11:45:18 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37F813A68C9; Sun, 30 Mar 2008 11:45:18 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769BC28C179 for ; Sun, 30 Mar 2008 11:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHbBlXJtmQuk for ; Sun, 30 Mar 2008 11:45:13 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 2E3733A67D5 for ; Sun, 30 Mar 2008 11:45:13 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jg2Wf-0001Ny-OG; Sun, 30 Mar 2008 13:45:06 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , References: <47EF9ED2.7000503@gmx.net> Date: Sun, 30 Mar 2008 14:45:08 -0400 Message-ID: <006401c89296$2f588820$9744f444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47EF9ED2.7000503@gmx.net> Thread-Index: AciSb4RgmFJv8u3cSd+Mevez8JWy1QAJn6KQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] ECRIT Framework: References X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think you have a good point on normative references. Indeed, is there a reason why -phonebcp needs to be normative? What is "normative" in a framework? I'll fix the mistakes you found. Thanks for pointing them out. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 10:08 AM To: ecrit@ietf.org Subject: [Ecrit] ECRIT Framework: References The document contains a number of normative references. I wonder whether this is indeed necessary. Why cannot you just have a single normative reference, namely to the Phone BCP document. The rest is informative? If you don't do that then we have a lot of dependencies and a huge number of downrefs. Two references are not up-to-date: * [I-D.ietf-ecrit-service-urn]: RFC 5031 * [I-D.thomson-geopriv-lis-discovery]: it is already a WG item. == Unused Reference: 'RFC3263' is defined on line 1514, but no explicit reference was found in the text == Unused Reference: 'RFC3265' is defined on line 1522, but no explicit reference was found in the text == Unused Reference: 'RFC3311' is defined on line 1525, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4507 (Obsoleted by RFC 5077) ** Obsolete normative reference: RFC 4676 (Obsoleted by RFC 4776) Delete reference RFC 2119 You write: " NENA recommends IP based systems complete calls in two seconds (i.e., last dial press to ring at PSAP). " Reference to a NENA document that says that is missing. _______________________________________________ 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 ecrit-bounces@ietf.org Sun Mar 30 11:47:05 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47DC28C350; Sun, 30 Mar 2008 11:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.69 X-Spam-Level: X-Spam-Status: No, score=-101.69 tagged_above=-999 required=5 tests=[AWL=0.747, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFZksgQ+vywZ; Sun, 30 Mar 2008 11:47:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C066628C1BB; Sun, 30 Mar 2008 11:47:04 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C783428C179 for ; Sun, 30 Mar 2008 11:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndZNXX4gHCsR for ; Sun, 30 Mar 2008 11:47:03 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 0F2D428C1BB for ; Sun, 30 Mar 2008 11:47:03 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jg2YR-0001VD-C8; Sun, 30 Mar 2008 13:46:55 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , References: <47EF9F1D.8000509@gmx.net> Date: Sun, 30 Mar 2008 14:46:57 -0400 Message-ID: <006501c89296$70ab8de0$9744f444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47EF9F1D.8000509@gmx.net> Thread-Index: AciSb7N2MaeKo6E1RY2ZJuBiR2MFLgAJoMDA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] ECRIT Framework: Editorial X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Thanks for these. Is it a requirement now to have an IANA section when there are no IANA considerations? I must have missed some RFC that says that. Agree that -framework does not have 2119 language of any kind. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 10:10 AM To: ecrit@ietf.org Subject: [Ecrit] ECRIT Framework: Editorial * The contact info of Andy Newton is not up-to-date * There is no IANA Considerations section in the document. * A few things from IDNITs == Line 387 has weird spacing: '...URI and dial ...' == Line 641 has weird spacing: '...ctional this ...' == Line 643 has weird spacing: '... Postal this ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. s/Section Section 6.10/Section 6.10 s/WiMAX/Wimax s/WiMaX/Wimax s/Section Section 6.8/Section 6.8 s/is should be aware/should be aware s/Never the less/Nevertheless Each section heading has to have capitialized letters. This makes the job of the RFC Editor easier. They cost money! For example, s/6.2.1 User-entered location information/ User-Entered Location Informatoin Incomplete sentence: " Handling multiple locations is discussed in . " _______________________________________________ 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 ecrit-bounces@ietf.org Sun Mar 30 12:54:37 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2807228C21F; Sun, 30 Mar 2008 12:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.698 X-Spam-Level: X-Spam-Status: No, score=-100.698 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbzE2Y2h9L4P; Sun, 30 Mar 2008 12:54:36 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E5AF28C180; Sun, 30 Mar 2008 12:54:36 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 109E028C180 for ; Sun, 30 Mar 2008 12:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAZtRAznayTG for ; Sun, 30 Mar 2008 12:54:34 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2E49628C0DC for ; Sun, 30 Mar 2008 12:54:33 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2008 19:54:31 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp017) with SMTP; 30 Mar 2008 21:54:31 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX199uw9FgjV9Y3azST0W2iG7Wrr0aOrPFAXmlFuso7 1zhJVcdFh90y0Z Message-ID: <47EFEFF3.7070307@gmx.net> Date: Sun, 30 Mar 2008 22:54:27 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] Phone BCP Review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I read through the Phone BCP draft and I came across a couple of minor issues. I will put individual issues in separate mails. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 12:54:47 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90D2328C2DC; Sun, 30 Mar 2008 12:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.686 X-Spam-Level: X-Spam-Status: No, score=-100.686 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hS4+Al+P1Ey; Sun, 30 Mar 2008 12:54:46 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A380528C168; Sun, 30 Mar 2008 12:54:46 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E5C528C168 for ; Sun, 30 Mar 2008 12:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmy2QcFyr8Sv for ; Sun, 30 Mar 2008 12:54:45 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 518D828C0DC for ; Sun, 30 Mar 2008 12:54:45 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2008 19:54:42 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp013) with SMTP; 30 Mar 2008 21:54:42 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/kqFN9SVHk6PbCCzZa6Qda65BD1rYEvlBbqSqLQY 9ImK2l4BmSqZM9 Message-ID: <47EFEFFE.1020307@gmx.net> Date: Sun, 30 Mar 2008 22:54:38 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] Phone BCP: References X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org == Unused Reference: 'I-D.ietf-geopriv-pdif-lo-profile' is defined on line 907, but no explicit reference was found in the text == Unused Reference: 'LLDP' is defined on line 971, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 981, but no explicit reference was found in the text == Unused Reference: 'RFC2396' is defined on line 984, but no explicit reference was found in the text == Unused Reference: 'RFC3046' is defined on line 991, but no explicit reference was found in the text == Unused Reference: 'RFC4190' is defined on line 1060, but no explicit reference was found in the text == Outdated reference: draft-ietf-ecrit-security-threats has been published as RFC 5069 == Outdated reference: draft-ietf-ecrit-service-urn has been published as RFC 5031 == Outdated reference: draft-ietf-sip-connected-identity has been published as RFC 4916 ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 4507 (Obsoleted by RFC 5077) ** Obsolete normative reference: RFC 4676 (Obsoleted by RFC 4776) Do you really need these normative references? - draft-ietf-sip-sips - draft-barnes-geopriv-lo-sec _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 12:54:52 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8622B28C2DC; Sun, 30 Mar 2008 12:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.707 X-Spam-Level: X-Spam-Status: No, score=-101.707 tagged_above=-999 required=5 tests=[AWL=0.730, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yApqdu2bK+ri; Sun, 30 Mar 2008 12:54:51 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7C7028C1AB; Sun, 30 Mar 2008 12:54:51 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 366D628C1AB for ; Sun, 30 Mar 2008 12:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5QNJxi23uGF for ; Sun, 30 Mar 2008 12:54:50 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 14DB528C168 for ; Sun, 30 Mar 2008 12:54:49 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2008 19:54:48 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp007) with SMTP; 30 Mar 2008 21:54:48 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/W67Inh73W6yjo6G0RNUypNAtp/FQxeCKZ/jPpGh ZYyNYaLW/SJkQC Message-ID: <47EFF004.6030009@gmx.net> Date: Sun, 30 Mar 2008 22:54:44 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] Phone BCP: Editorial X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org == Line 54 has weird spacing: '...ergency calls...' == Line 144 has weird spacing: '...ergency calls...' == Line 245 has weird spacing: '...ocation infor...' Use capital letters for subject headings Example: s/Identifying an emergency call/Identitying for Subject Headings Avoid usage of "BCP" in the text since the document is not a BCP s/devicesand/devices and s/(see Section 6 may depend/(see Section 6) may depend s/the the/the s/which/, which s/interpert/interpret s/cannot do interpret/cannot interpret s/headers ./headers. " AN-21 A LIS should perform location validation of civic locations via LoST before entering a location in its database. " I guess you want to write "SHOULD" instead of "should". This sentence seems to be broken: " ED-44/AN-24 To prevent against spoofing of the DHCP server, elements implementing DHCP for location configuration SHOULD use although the difficulty in providing appropriate credentials is significant. [RFC3118]. " _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 12:55:00 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B72CC28C274; Sun, 30 Mar 2008 12:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.737 X-Spam-Level: X-Spam-Status: No, score=-100.737 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1QfEEwnsE1d; Sun, 30 Mar 2008 12:54:59 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA26928C1B5; Sun, 30 Mar 2008 12:54:59 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28CA528C1B5 for ; Sun, 30 Mar 2008 12:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sm0mPb993HO7 for ; Sun, 30 Mar 2008 12:54:58 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id F21E028C180 for ; Sun, 30 Mar 2008 12:54:57 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2008 19:54:55 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp004) with SMTP; 30 Mar 2008 21:54:55 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19Gs3xueuZGb9fv5zDVeNBMQRN/MHsy2KSN3gSjC8 k9HcO9XFY/Pqt6 Message-ID: <47EFF00B.8050008@gmx.net> Date: Sun, 30 Mar 2008 22:54:51 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] Phone BCP: RFC 2119 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I am not sure whether RFC 2119 language is used consistently throughout the document. For example, Section 4 uses RFC 2119 althought in my view this has nothing todo with RFC 2119. Here is the text from Section 4: " 4. Which devices and services should support emergency calls ED-1 A device or application SHOULD support emergency calling if a user could reasonably expect to be able to place a call for help with the device. SP-1 If a device or application expects to be able to place a call for help, the service provider that supports it MUST facilitate emergency calling. ED-2 Devices that create media sessions and exchange audio, video and/or text, and have the capability to establish sessions to a wide variety of addresses, and communicate over private IP networks or the Internet, SHOULD support emergency calls. " I am also not sure whether one should say anything about this aspect. Another example: " ED-10 Devices SHOULD NOT have one button emergency calling initiation. " Yet another example: " ED-13/INT-2/SP-11/AN-1 Elements MUST NOT convert (civic to geo or geo to civic) from the form of location the determination mechanism supplied. " This requirement is somewhat out of scope of the IETF work in general: " ED-14/INT-3/AN-2 Any suitable location determination mechanism MAY be used. " " AN-4 Access networks supporting copper, fiber or other hard wired IP packet service SHOULD support location configuration. If the network does not support location configuration, it MUST require every device that connects to the network to support end system measured location. " _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 12:55:14 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CADE528C168; Sun, 30 Mar 2008 12:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.731 X-Spam-Level: X-Spam-Status: No, score=-100.731 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMFA6CuXlxsf; Sun, 30 Mar 2008 12:55:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 174C428C1C3; Sun, 30 Mar 2008 12:55:14 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C805028C2E9 for ; Sun, 30 Mar 2008 12:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYDcsxEP4kAI for ; Sun, 30 Mar 2008 12:55:12 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5B3CC28C168 for ; Sun, 30 Mar 2008 12:55:07 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2008 19:55:05 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp058) with SMTP; 30 Mar 2008 21:55:05 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18wGHYKjEUwdPUPEXtsUqBN+WrBLNiVRlZqaZqUgJ 7TzMRzofkMBnbk Message-ID: <47EFF015.1010601@gmx.net> Date: Sun, 30 Mar 2008 22:55:01 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] Phone BCP: Indication of Numbers X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org In a couple of cases you mention specific numbers. I would like to understand where these numbers come from. Can we motivate them by indicating that "we" think that these are useful numbers and whether these are numbers someone else came up with; a ref would be appropriate in that case. Examples: " AN-5/INT-5 Access networks and intermediate devices providing wire database location information SHOULD provide interior location data (building, floor, room, cubicle) where possible. It is RECOMMENDED that interior location be provided when spaces exceed approximately 650 square meters. " ---> 650 square meters " ED-16/INT-7 Devices MAY support end-system measured location. Uncertainty of less than 100 m with 95% confidence SHOULD be available for dispatch. " ---> 100 m with 95% " AN-8 Access networks MAY provide network-measured location determination. Wireless access network which do not support network measured location MUST require that all devices connected to the network have end-system measured location. Uncertainty of less than 100 m with 95% confidence SHOULD be available for dispatch. " " AN-10 Access networks with range of <10 meters MUST provide a location to mobile devices connected to it. The location provided SHOULD be that of the access point location unless a more accurate mechanism is provided. " Should we really define these requirements? Sounds more like a job of a regulator. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 12:55:47 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 337CE28C356; Sun, 30 Mar 2008 12:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.744 X-Spam-Level: X-Spam-Status: No, score=-100.744 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuYig+RYF0xi; Sun, 30 Mar 2008 12:55:46 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED4D3A6A1E; Sun, 30 Mar 2008 12:55:44 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1DE83A67E5 for ; Sun, 30 Mar 2008 12:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8O5Q-lIWK8G for ; Sun, 30 Mar 2008 12:55:42 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B3AA228C24C for ; Sun, 30 Mar 2008 12:55:16 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2008 19:55:14 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp051) with SMTP; 30 Mar 2008 21:55:14 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+b+PQJ6eeb+L0uiVM/OGeyZGCnuLxPy4EdM/VFRY ZTq2lJZmlvdMeE Message-ID: <47EFF01E.3060306@gmx.net> Date: Sun, 30 Mar 2008 22:55:10 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] Phone BCP: LCP interaction X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org You write: " ED-22/INT-15 Endpoints SHOULD try all LCPs supported by the device in any order or in parallel. The first one that succeeds in supplying location can be used. " Didn't Barbara provide more details on how this procedure should work? " ED-25/INT-18 Endpoints SHOULD obtain location immediately after obtaining local network configuration information.When HELD is the LCP the client MUST support a random back-off period (between 30 seconds and 300 seconds) for re-trying the HELD query, when no response is received. " Are these numbers based on some testing or just an idea? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 12:55:47 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF41428C276; Sun, 30 Mar 2008 12:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.726 X-Spam-Level: X-Spam-Status: No, score=-100.726 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71GavNNRFZJJ; Sun, 30 Mar 2008 12:55:46 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CA8328C31F; Sun, 30 Mar 2008 12:55:44 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72C823A67E5 for ; Sun, 30 Mar 2008 12:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9K88M7bQQYk for ; Sun, 30 Mar 2008 12:55:42 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BB58128C276 for ; Sun, 30 Mar 2008 12:55:22 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2008 19:55:20 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp047) with SMTP; 30 Mar 2008 21:55:20 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+ON1Q0J1SO+zCsIRsxLaLLWF0zr5ecTFZKCdOeG9 +ZidKyfPwVq6aP Message-ID: <47EFF025.9000705@gmx.net> Date: Sun, 30 Mar 2008 22:55:17 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org " ED-39 If a UA has more than one location available to it, it MUST choose one location to route the call towards the PSAP. SP-16 If a proxy inserts location on behalf of an endpoint, and it has multiple locations available for the endpoint it MUST choose one location to use to route the call towards the PSAP. " I could imagine that someone might ask how to make a decision. So, how does the decision making look like? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 12:55:48 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2430428C341; Sun, 30 Mar 2008 12:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.714 X-Spam-Level: X-Spam-Status: No, score=-100.714 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtkmXKD1YSsS; Sun, 30 Mar 2008 12:55:47 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DCD728C155; Sun, 30 Mar 2008 12:55:46 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EEE628C0F7 for ; Sun, 30 Mar 2008 12:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nElg8hyxAzM6 for ; Sun, 30 Mar 2008 12:55:44 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 8E3C828C2D9 for ; Sun, 30 Mar 2008 12:55:33 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2008 19:55:31 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp039) with SMTP; 30 Mar 2008 21:55:31 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/1KKhs7m/1gBr2R3pOQP0+OmWOfRN6xwgF8tIRMn TNmIUJ569g0utO Message-ID: <47EFF030.5030802@gmx.net> Date: Sun, 30 Mar 2008 22:55:28 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] Phone BCP: Default Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org " AN-23/SP-22 Default locations MUST be marked with method=Default and the proxy MUST be identfied in provided-by element of the PIDF-LO. " Someone should register the token "default". To my knowledge it is not registered. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 12:55:51 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4655E28C3C6; Sun, 30 Mar 2008 12:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.701 X-Spam-Level: X-Spam-Status: No, score=-100.701 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJsMhdJg7KR3; Sun, 30 Mar 2008 12:55:50 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB8D28C347; Sun, 30 Mar 2008 12:55:48 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDA4428C310 for ; Sun, 30 Mar 2008 12:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 970ifRWheGdX for ; Sun, 30 Mar 2008 12:55:46 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 79E493A67D5 for ; Sun, 30 Mar 2008 12:55:40 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2008 19:55:38 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp034) with SMTP; 30 Mar 2008 21:55:38 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19l8HEz4ZhlBFIjOQEpuW3IAWRAGg+M7I8Yy1Bb8a 3l6vbSGEKHzDb2 Message-ID: <47EFF036.2000508@gmx.net> Date: Sun, 30 Mar 2008 22:55:34 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] Phone BCP: LoST Discovery X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org " ED-48 Endpoints MUST support LIS discovery as described in [I-D.thomson-geopriv-lis-discovery], and the LoST discovery as described in [I-D.ietf-ecrit-dhc-lost-discovery]. " I think LoST discovery based on DHCP is only a SHOULD; not a MUST. It is good to have it but not absolutely necessary. The DNS U-NAPTR discovery described in LoST itself is mandatory. " ED-49 The device MUST have a configurable default LoST server parameter. If the device is provided by or managed by service provider, it is expected that the service provider will configure this option. " I believe that this default LoST server is not absolutely necessary. The client may also use the U-NAPTR discovery procedure based on the domain name it has. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 12:55:54 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4438B28C399; Sun, 30 Mar 2008 12:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.703 X-Spam-Level: X-Spam-Status: No, score=-100.703 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1u10fEu3WW7; Sun, 30 Mar 2008 12:55:53 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C4828C3A5; Sun, 30 Mar 2008 12:55:52 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A697828C3A5 for ; Sun, 30 Mar 2008 12:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-bY2mKfCK1T for ; Sun, 30 Mar 2008 12:55:52 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9E66C28C3BC for ; Sun, 30 Mar 2008 12:55:50 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2008 19:55:48 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp030) with SMTP; 30 Mar 2008 21:55:48 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19OWWtP8/dOCYorf9wzGuRG3BnFWedzGCD4YK97Zh p5Lp//p3ob48Bv Message-ID: <47EFF041.6020904@gmx.net> Date: Sun, 30 Mar 2008 22:55:45 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] Phone BCP: HELD Discovery X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org " ED-47 Endpoints MUST support one or more mechanisms that allow them to determine their public IP address. Examples include ICE [I-D.ietf-mmusic-ice] and HTTP get. " This functionality is inherited by the HELD discovery mechanism. The reference to ICE is not needed since HELD discovery does not use ICE and HTTP get is not used at all. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 12:56:09 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0710E28C3E5; Sun, 30 Mar 2008 12:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.705 X-Spam-Level: X-Spam-Status: No, score=-100.705 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDyqPSPobbVB; Sun, 30 Mar 2008 12:56:07 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B2BF28C30F; Sun, 30 Mar 2008 12:56:07 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3248328C373 for ; Sun, 30 Mar 2008 12:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59Hmmltam2Z8 for ; Sun, 30 Mar 2008 12:56:05 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D25C728C30F for ; Sun, 30 Mar 2008 12:56:04 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2008 19:56:02 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp025) with SMTP; 30 Mar 2008 21:56:02 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18v6O5c2UkvEMzR4esrIh86i76lAFMdA9S3CQyj/r JT1OEvmD2dSxkd Message-ID: <47EFF04D.9020007@gmx.net> Date: Sun, 30 Mar 2008 22:55:57 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] Phone BCP: TLS Session Resumption X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org " ED-60/AN-25 TLS MUST be specified when attempting to retrieve location (configuration or dereferencing) with HELD. The use of [RFC4507] is RECOMMENDED to minimise the time to establish TLS sessions. " The main purpose of RFC 5077 (obsoleting RFC 4507) is not only to reduce the time for TLS session setup but also to avoid storing state at the HELD server. Maybe one should add such a statement. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 12:56:17 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC22528C3C4; Sun, 30 Mar 2008 12:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.702 X-Spam-Level: X-Spam-Status: No, score=-100.702 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbiNAwHlmH6Z; Sun, 30 Mar 2008 12:56:17 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6295728C35C; Sun, 30 Mar 2008 12:56:16 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E62328C35C for ; Sun, 30 Mar 2008 12:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27kG2ivwlbgw for ; Sun, 30 Mar 2008 12:56:14 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 93D7828C341 for ; Sun, 30 Mar 2008 12:56:14 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2008 19:56:12 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp015) with SMTP; 30 Mar 2008 21:56:12 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18YVdh466gYFXrkH5yQB60BuEjCa+shqPX8BoaWQO 3hQAWCiTGAkqI6 Message-ID: <47EFF059.70601@gmx.net> Date: Sun, 30 Mar 2008 22:56:09 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] Phone BCP: Testing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org You write: " ED-78 INVITE requests to a service URN ending in ".test" indicates a request for an automated test. For example, "urn:service.sos.fire.test". " I am not sure whether one can actually add a .test to the defined URNs without registering a new set of URNs. Have you checked that? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 12:56:23 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5838F28C393; Sun, 30 Mar 2008 12:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.702 X-Spam-Level: X-Spam-Status: No, score=-100.702 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGpKH+2CrrzS; Sun, 30 Mar 2008 12:56:22 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A82628C39F; Sun, 30 Mar 2008 12:56:22 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A509328C39F for ; Sun, 30 Mar 2008 12:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCfj0+57-zDX for ; Sun, 30 Mar 2008 12:56:21 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6328828C24C for ; Sun, 30 Mar 2008 12:56:20 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2008 19:56:18 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp011) with SMTP; 30 Mar 2008 21:56:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18LkDcjKRULGIwjTC4rmJrA7wb1k0nJ7LN5h/vxRM RirgzyUupyR45p Message-ID: <47EFF05E.7020207@gmx.net> Date: Sun, 30 Mar 2008 22:56:14 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] Phone BCP: Call Backs X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org " SP-33 Unitialized devices, like any device MUST have a globally routable URI in a Contact: header. SP-34 Unitialized devices SHOULD have a persistent URI in a P-Asserted-Identity: header if there is some way to assign such an identifier to the device. " I suggest to delete it since the ECRIT Framework also has everything deleted related to unauthenticated emergency services usage. The usage of GRUU should, however, be mandated even without the usage of unauthenticated emergency services for call-back. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 13:05:09 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24D4028C1E3; Sun, 30 Mar 2008 13:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.773 X-Spam-Level: X-Spam-Status: No, score=-100.773 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-eim+USAJ1j; Sun, 30 Mar 2008 13:05:07 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F4DC3A6925; Sun, 30 Mar 2008 13:05:07 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2814928C180 for ; Sun, 30 Mar 2008 13:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7SvpPrWI6lo for ; Sun, 30 Mar 2008 13:05:02 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 1D61A3A6774 for ; Sun, 30 Mar 2008 13:04:56 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jg3ln-0007jG-T6; Sun, 30 Mar 2008 15:04:48 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , References: <47EFF004.6030009@gmx.net> Date: Sun, 30 Mar 2008 16:04:52 -0400 Message-ID: <008301c892a1$52fad7a0$9744f444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47EFF004.6030009@gmx.net> Thread-Index: AciSn+gCYYBQQcyzRGGD0+tXYtPpFQAAQLwQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Phone BCP: Editorial X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Thanks for these. Okay with all of them except: >Avoid usage of "BCP" in the text since the document is not a BCP It's not a protocol definition, it IS a BCP. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 13:07:34 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31C173A69BA; Sun, 30 Mar 2008 13:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.748 X-Spam-Level: X-Spam-Status: No, score=-100.748 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z10es9JCR650; Sun, 30 Mar 2008 13:07:33 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FD003A6847; Sun, 30 Mar 2008 13:07:33 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D273A6925 for ; Sun, 30 Mar 2008 13:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kk2m++D4YIjZ for ; Sun, 30 Mar 2008 13:07:29 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id B0C883A69BA for ; Sun, 30 Mar 2008 13:07:29 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jg3oH-0007vO-Bz; Sun, 30 Mar 2008 15:07:21 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , References: <47EFF00B.8050008@gmx.net> Date: Sun, 30 Mar 2008 16:07:25 -0400 Message-ID: <008701c892a1$ae93f060$9744f444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47EFF00B.8050008@gmx.net> Thread-Index: AciSn+1fE6+mpEIHSZKVTUiyV4rkCgAAYK0g X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Phone BCP: RFC 2119 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I do not understand your reasoning. I think 2119 language is appropriate in all of your examples. We have discussed the scope issues several times. I thought we had agreed on it, but we certainly can re-open the discussion. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 3:55 PM To: ecrit@ietf.org Subject: [Ecrit] Phone BCP: RFC 2119 I am not sure whether RFC 2119 language is used consistently throughout the document. For example, Section 4 uses RFC 2119 althought in my view this has nothing todo with RFC 2119. Here is the text from Section 4: " 4. Which devices and services should support emergency calls ED-1 A device or application SHOULD support emergency calling if a user could reasonably expect to be able to place a call for help with the device. SP-1 If a device or application expects to be able to place a call for help, the service provider that supports it MUST facilitate emergency calling. ED-2 Devices that create media sessions and exchange audio, video and/or text, and have the capability to establish sessions to a wide variety of addresses, and communicate over private IP networks or the Internet, SHOULD support emergency calls. " I am also not sure whether one should say anything about this aspect. Another example: " ED-10 Devices SHOULD NOT have one button emergency calling initiation. " Yet another example: " ED-13/INT-2/SP-11/AN-1 Elements MUST NOT convert (civic to geo or geo to civic) from the form of location the determination mechanism supplied. " This requirement is somewhat out of scope of the IETF work in general: " ED-14/INT-3/AN-2 Any suitable location determination mechanism MAY be used. " " AN-4 Access networks supporting copper, fiber or other hard wired IP packet service SHOULD support location configuration. If the network does not support location configuration, it MUST require every device that connects to the network to support end system measured location. " _______________________________________________ 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 ecrit-bounces@ietf.org Sun Mar 30 13:14:12 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFFE828C1AB; Sun, 30 Mar 2008 13:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.739 X-Spam-Level: X-Spam-Status: No, score=-100.739 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SW0I440Sipcf; Sun, 30 Mar 2008 13:14:10 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2BB43A6925; Sun, 30 Mar 2008 13:14:10 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7D9E3A6925 for ; Sun, 30 Mar 2008 13:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dw9NPvsewPlS for ; Sun, 30 Mar 2008 13:14:09 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 0220D3A6847 for ; Sun, 30 Mar 2008 13:14:08 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jg3ui-0008Ln-NJ; Sun, 30 Mar 2008 15:14:01 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , References: <47EFF015.1010601@gmx.net> Date: Sun, 30 Mar 2008 16:14:05 -0400 Message-ID: <008801c892a2$9cc088c0$9744f444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47EFF015.1010601@gmx.net> Thread-Index: AciSn/W4ZnxWG/4zTE20/qWHrH9lZgAAeS9A X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Phone BCP: Indication of Numbers X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Look in -framework in the same section. It should tell you where the numbers come from. It does explain 650 m2 It doesn't sufficiently explain 100m w/ 95% confidence (it's the current U.S. standard). I believe guidance is essential. I think it is appropriate to provide guidance. They are all "SHOULDs" because regulation may define them. In most cases, they don't, and there is no effective guidance. We're in the best position to offer it for now. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 3:55 PM To: ecrit@ietf.org Subject: [Ecrit] Phone BCP: Indication of Numbers In a couple of cases you mention specific numbers. I would like to understand where these numbers come from. Can we motivate them by indicating that "we" think that these are useful numbers and whether these are numbers someone else came up with; a ref would be appropriate in that case. Examples: " AN-5/INT-5 Access networks and intermediate devices providing wire database location information SHOULD provide interior location data (building, floor, room, cubicle) where possible. It is RECOMMENDED that interior location be provided when spaces exceed approximately 650 square meters. " ---> 650 square meters " ED-16/INT-7 Devices MAY support end-system measured location. Uncertainty of less than 100 m with 95% confidence SHOULD be available for dispatch. " ---> 100 m with 95% " AN-8 Access networks MAY provide network-measured location determination. Wireless access network which do not support network measured location MUST require that all devices connected to the network have end-system measured location. Uncertainty of less than 100 m with 95% confidence SHOULD be available for dispatch. " " AN-10 Access networks with range of <10 meters MUST provide a location to mobile devices connected to it. The location provided SHOULD be that of the access point location unless a more accurate mechanism is provided. " Should we really define these requirements? Sounds more like a job of a regulator. _______________________________________________ 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 ecrit-bounces@ietf.org Sun Mar 30 13:16:31 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 295643A6B60; Sun, 30 Mar 2008 13:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.723 X-Spam-Level: X-Spam-Status: No, score=-100.723 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3FsNXG9iU6g; Sun, 30 Mar 2008 13:16:30 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64F793A6925; Sun, 30 Mar 2008 13:16:30 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 050863A6852 for ; Sun, 30 Mar 2008 13:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CDlsH-qw27W for ; Sun, 30 Mar 2008 13:16:28 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 171BD3A67E5 for ; Sun, 30 Mar 2008 13:16:28 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jg3wx-000086-Qd; Sun, 30 Mar 2008 15:16:20 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , References: <47EFF01E.3060306@gmx.net> Date: Sun, 30 Mar 2008 16:16:25 -0400 Message-ID: <008901c892a2$efba9980$9744f444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47EFF01E.3060306@gmx.net> Thread-Index: AciSoAljH2kZA70bQ96jN1oSZwkZAQAAqd9w X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Phone BCP: LCP interaction X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'll look back in the archives for any suggested text or specifics Barbara offered on this. The 30/300 is out of my head. It's long enough to be effective in spreading load, and short enough to not cause serious issues if a user needs to make a call shortly after booting. I could offer that explanation in -framework if you think it's appropriate. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 3:55 PM To: ecrit@ietf.org Subject: [Ecrit] Phone BCP: LCP interaction You write: " ED-22/INT-15 Endpoints SHOULD try all LCPs supported by the device in any order or in parallel. The first one that succeeds in supplying location can be used. " Didn't Barbara provide more details on how this procedure should work? " ED-25/INT-18 Endpoints SHOULD obtain location immediately after obtaining local network configuration information.When HELD is the LCP the client MUST support a random back-off period (between 30 seconds and 300 seconds) for re-trying the HELD query, when no response is received. " Are these numbers based on some testing or just an idea? _______________________________________________ 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 ecrit-bounces@ietf.org Sun Mar 30 13:18:10 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C056128C180; Sun, 30 Mar 2008 13:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GBrHXhApl0M; Sun, 30 Mar 2008 13:18:09 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDD153A6B43; Sun, 30 Mar 2008 13:18:09 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 019F43A6B46 for ; Sun, 30 Mar 2008 13:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ralABY3CwUhx for ; Sun, 30 Mar 2008 13:18:08 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 386C73A6B43 for ; Sun, 30 Mar 2008 13:18:08 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jg3ya-0000GQ-8v; Sun, 30 Mar 2008 15:18:00 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , References: <47EFF025.9000705@gmx.net> Date: Sun, 30 Mar 2008 16:18:05 -0400 Message-ID: <008a01c892a3$2ba5cd70$9744f444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47EFF025.9000705@gmx.net> Thread-Index: AciSoA4opjlRbFAFRHaEVQlAojFghQAAumaw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think -framework motivates how you do it: Getting multiple locations all purported to describe the location of the caller is confusing to all, and should be avoided. Handling multiple locations is discussed in . Conflicting location information is particularly harmful if different routes (PSAPs) result from LoST queries for the multiple locations. When they occur anyway, the general guidance is that the entity earliest in the chain generally has more knowledge than later elements to make an intelligent decision, especially about which location will be used for routing. It is permissable to send multiple locations towards the PSAP, but the element that choses the route must select one (and only one) location to use with LoST. Guidelines for dealing with multiple locations are also given in [I-D.ietf-ecrit-lost]. If a UA gets multiple locations, it must choose the one to use for routing, but it may send all of the locations it has in the signaling. If a proxy is inserting location and has multiple locations, it must choose the one to use to route and send any others it has. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 3:55 PM To: ecrit@ietf.org Subject: [Ecrit] Phone BCP: Multiple Location " ED-39 If a UA has more than one location available to it, it MUST choose one location to route the call towards the PSAP. SP-16 If a proxy inserts location on behalf of an endpoint, and it has multiple locations available for the endpoint it MUST choose one location to use to route the call towards the PSAP. " I could imagine that someone might ask how to make a decision. So, how does the decision making look like? _______________________________________________ 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 ecrit-bounces@ietf.org Sun Mar 30 13:18:35 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F19F13A6C99; Sun, 30 Mar 2008 13:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.706 X-Spam-Level: X-Spam-Status: No, score=-100.706 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oflIOiIyj-dx; Sun, 30 Mar 2008 13:18:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E9563A6BCD; Sun, 30 Mar 2008 13:18:35 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C99853A6BCD for ; Sun, 30 Mar 2008 13:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13AlIiqcgVHq for ; Sun, 30 Mar 2008 13:18:33 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 1DAC43A6852 for ; Sun, 30 Mar 2008 13:18:33 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jg3yy-0000Hs-SQ; Sun, 30 Mar 2008 15:18:25 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , References: <47EFF030.5030802@gmx.net> Date: Sun, 30 Mar 2008 16:18:30 -0400 Message-ID: <008b01c892a3$3a53bcb0$9744f444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47EFF030.5030802@gmx.net> Thread-Index: AciSoBEjEu3jAaXSQuqYPC27P2iQSAAAx7nQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Phone BCP: Default Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yes, I am aware of this. I will prepare a draft. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 3:55 PM To: ecrit@ietf.org Subject: [Ecrit] Phone BCP: Default Location " AN-23/SP-22 Default locations MUST be marked with method=Default and the proxy MUST be identfied in provided-by element of the PIDF-LO. " Someone should register the token "default". To my knowledge it is not registered. _______________________________________________ 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 ecrit-bounces@ietf.org Sun Mar 30 13:19:39 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 709213A6C7F; Sun, 30 Mar 2008 13:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.699 X-Spam-Level: X-Spam-Status: No, score=-100.699 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZO3iVfIMOFP; Sun, 30 Mar 2008 13:19:38 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB14B28C0F7; Sun, 30 Mar 2008 13:19:38 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5416E3A6BCD for ; Sun, 30 Mar 2008 13:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+p-VXDKHSfR for ; Sun, 30 Mar 2008 13:19:35 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 5D6083A69BA for ; Sun, 30 Mar 2008 13:19:34 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jg3zy-0000ME-Eg; Sun, 30 Mar 2008 15:19:26 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , References: <47EFF036.2000508@gmx.net> Date: Sun, 30 Mar 2008 16:19:31 -0400 Message-ID: <008c01c892a3$5f0ea920$9744f444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47EFF036.2000508@gmx.net> Thread-Index: AciSoBhKQdi0ZzG0Tg2fkAW/umMl6AAAzDvQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Phone BCP: LoST Discovery X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think Barbara asked for it to be a MUST. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 3:56 PM To: ecrit@ietf.org Subject: [Ecrit] Phone BCP: LoST Discovery " ED-48 Endpoints MUST support LIS discovery as described in [I-D.thomson-geopriv-lis-discovery], and the LoST discovery as described in [I-D.ietf-ecrit-dhc-lost-discovery]. " I think LoST discovery based on DHCP is only a SHOULD; not a MUST. It is good to have it but not absolutely necessary. The DNS U-NAPTR discovery described in LoST itself is mandatory. " ED-49 The device MUST have a configurable default LoST server parameter. If the device is provided by or managed by service provider, it is expected that the service provider will configure this option. " I believe that this default LoST server is not absolutely necessary. The client may also use the U-NAPTR discovery procedure based on the domain name it has. _______________________________________________ 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 ecrit-bounces@ietf.org Sun Mar 30 13:21:33 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7241A28C220; Sun, 30 Mar 2008 13:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.694 X-Spam-Level: X-Spam-Status: No, score=-100.694 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2W3rIrDesi9; Sun, 30 Mar 2008 13:21:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59E428C168; Sun, 30 Mar 2008 13:21:32 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8848F28C168 for ; Sun, 30 Mar 2008 13:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mceTdT3qU6US for ; Sun, 30 Mar 2008 13:21:30 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id D83B328C146 for ; Sun, 30 Mar 2008 13:21:30 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jg41q-0000VW-IM; Sun, 30 Mar 2008 15:21:22 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , References: <47EFF041.6020904@gmx.net> Date: Sun, 30 Mar 2008 16:21:27 -0400 Message-ID: <008d01c892a3$a4530d50$9744f444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47EFF041.6020904@gmx.net> Thread-Index: AciSoBqsOT+0WFnXRMKPRqULJ9NB/wAA3Tkw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Phone BCP: HELD Discovery X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think you are correct. This was a left over from some previous notions of how HELD worked. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 3:56 PM To: ecrit@ietf.org Subject: [Ecrit] Phone BCP: HELD Discovery " ED-47 Endpoints MUST support one or more mechanisms that allow them to determine their public IP address. Examples include ICE [I-D.ietf-mmusic-ice] and HTTP get. " This functionality is inherited by the HELD discovery mechanism. The reference to ICE is not needed since HELD discovery does not use ICE and HTTP get is not used at all. _______________________________________________ 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 ecrit-bounces@ietf.org Sun Mar 30 13:21:51 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F1E93A6C7F; Sun, 30 Mar 2008 13:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.689 X-Spam-Level: X-Spam-Status: No, score=-100.689 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxAAOBnXgsP0; Sun, 30 Mar 2008 13:21:50 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEFF728C1AB; Sun, 30 Mar 2008 13:21:50 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D2D53A6B44 for ; Sun, 30 Mar 2008 13:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rseEDB6MvYBy for ; Sun, 30 Mar 2008 13:21:48 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 9196A3A6852 for ; Sun, 30 Mar 2008 13:21:48 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jg428-0000Wm-AJ; Sun, 30 Mar 2008 15:21:40 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , References: <47EFF04D.9020007@gmx.net> Date: Sun, 30 Mar 2008 16:21:44 -0400 Message-ID: <008e01c892a3$aefed540$9744f444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47EFF04D.9020007@gmx.net> Thread-Index: AciSoB2nMmjhm4WuRxSDUtxILRJRGgAA4uNw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Phone BCP: TLS Session Resumption X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I will do so -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 3:56 PM To: ecrit@ietf.org Subject: [Ecrit] Phone BCP: TLS Session Resumption " ED-60/AN-25 TLS MUST be specified when attempting to retrieve location (configuration or dereferencing) with HELD. The use of [RFC4507] is RECOMMENDED to minimise the time to establish TLS sessions. " The main purpose of RFC 5077 (obsoleting RFC 4507) is not only to reduce the time for TLS session setup but also to avoid storing state at the HELD server. Maybe one should add such a statement. _______________________________________________ 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 ecrit-bounces@ietf.org Sun Mar 30 13:22:34 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C873128C1E3; Sun, 30 Mar 2008 13:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.682 X-Spam-Level: X-Spam-Status: No, score=-100.682 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTbQ5X3rPR2h; Sun, 30 Mar 2008 13:22:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 303C23A6A1E; Sun, 30 Mar 2008 13:22:32 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C19F3A6B44 for ; Sun, 30 Mar 2008 13:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbgtQqMP6ZJI for ; Sun, 30 Mar 2008 13:22:29 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 9EF563A69BA for ; Sun, 30 Mar 2008 13:22:29 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jg42n-0000co-Ew; Sun, 30 Mar 2008 15:22:21 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , References: <47EFF059.70601@gmx.net> Date: Sun, 30 Mar 2008 16:22:26 -0400 Message-ID: <008f01c892a3$c781db80$9744f444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47EFF059.70601@gmx.net> Thread-Index: AciSoCMEJxbOcSreRp2csEsS06C6jgAA5NFA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Phone BCP: Testing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Henning, your call. Should we register them? Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 3:56 PM To: ecrit@ietf.org Subject: [Ecrit] Phone BCP: Testing You write: " ED-78 INVITE requests to a service URN ending in ".test" indicates a request for an automated test. For example, "urn:service.sos.fire.test". " I am not sure whether one can actually add a .test to the defined URNs without registering a new set of URNs. Have you checked that? _______________________________________________ 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 ecrit-bounces@ietf.org Sun Mar 30 13:23:49 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 486F628C1E3; Sun, 30 Mar 2008 13:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.678 X-Spam-Level: X-Spam-Status: No, score=-100.678 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yp1S1dfnRAhR; Sun, 30 Mar 2008 13:23:48 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8789C3A69BA; Sun, 30 Mar 2008 13:23:48 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F35B3A6852 for ; Sun, 30 Mar 2008 13:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnPobJWH2WO6 for ; Sun, 30 Mar 2008 13:23:46 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id C973E3A6847 for ; Sun, 30 Mar 2008 13:23:46 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jg442-0000jw-GQ; Sun, 30 Mar 2008 15:23:38 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , References: <47EFF05E.7020207@gmx.net> Date: Sun, 30 Mar 2008 16:23:44 -0400 Message-ID: <009001c892a3$f56b17a0$9744f444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47EFF05E.7020207@gmx.net> Thread-Index: AciSoCaY5kdkogutTCqHkknUXcXcLAAA60Hg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Phone BCP: Call Backs X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This was an editing error. I did try to eliminate all references to unitialized devices. I'll fix it. I agree that a globally routable Contact: must remain. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 3:56 PM To: ecrit@ietf.org Subject: [Ecrit] Phone BCP: Call Backs " SP-33 Unitialized devices, like any device MUST have a globally routable URI in a Contact: header. SP-34 Unitialized devices SHOULD have a persistent URI in a P-Asserted-Identity: header if there is some way to assign such an identifier to the device. " I suggest to delete it since the ECRIT Framework also has everything deleted related to unauthenticated emergency services usage. The usage of GRUU should, however, be mandated even without the usage of unauthenticated emergency services for call-back. _______________________________________________ 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 ecrit-bounces@ietf.org Sun Mar 30 13:33:56 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8ECA3A6A32; Sun, 30 Mar 2008 13:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.629 X-Spam-Level: X-Spam-Status: No, score=-100.629 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7QK013k5UKm; Sun, 30 Mar 2008 13:33:56 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12D663A6824; Sun, 30 Mar 2008 13:33:56 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1833A6824 for ; Sun, 30 Mar 2008 13:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fPXCYDR-XKl for ; Sun, 30 Mar 2008 13:33:53 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 4F05E3A67E5 for ; Sun, 30 Mar 2008 13:33:53 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_03_30_15_47_01 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 30 Mar 2008 15:47:00 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Mar 2008 15:33:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 30 Mar 2008 15:33:51 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: Default Location Thread-Index: AciSoBsXzeiyM5C1TbiPfHV2vt2oAQAA98Tk References: <47EFF030.5030802@gmx.net> From: "Winterbottom, James" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 30 Mar 2008 20:33:51.0495 (UTC) FILETIME=[5D702970:01C892A5] Subject: Re: [Ecrit] Phone BCP: Default Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Actually this is a misuse of the method token. The method token says how location was determined for inclusion in the PIDF-LO. The intent I read from this requirement is that the method is attempting to say that the location doesn't represent where the end point is at all, but is what they have registered as a default location. I think you need a new element in the PIDF-LO to represent this. Something like: yes or default Then it could have a value of "current" or "recent" or other kind of subjective things too. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig Sent: Sun 3/30/2008 2:55 PM To: ecrit@ietf.org Subject: [Ecrit] Phone BCP: Default Location " AN-23/SP-22 Default locations MUST be marked with method=Default and the proxy MUST be identfied in provided-by element of the PIDF-LO. " Someone should register the token "default". To my knowledge it is not registered. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 30 13:36:31 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7816828C2E9; Sun, 30 Mar 2008 13:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.533 X-Spam-Level: X-Spam-Status: No, score=-100.533 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZzBwqSYJFEg; Sun, 30 Mar 2008 13:36:30 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42EBC28C29D; Sun, 30 Mar 2008 13:36:30 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9FBA28C174 for ; Sun, 30 Mar 2008 13:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5V4IfjGkOm1 for ; Sun, 30 Mar 2008 13:36:28 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id D62FE3A69B2 for ; Sun, 30 Mar 2008 13:36:25 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_03_30_15_49_33 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 30 Mar 2008 15:49:33 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Mar 2008 15:36:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 30 Mar 2008 15:35:33 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: Multiple Location Thread-Index: AciSoBSicmd+wT1mQom8/iePcnSz0wABYVlr References: <47EFF025.9000705@gmx.net> From: "Winterbottom, James" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 30 Mar 2008 20:36:24.0503 (UTC) FILETIME=[B8A35470:01C892A5] Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org PIDF-LO profile describes how to choose the correct location for exactly this purpose. That is the application form which the original requirements were drawn. -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig Sent: Sun 3/30/2008 2:55 PM To: ecrit@ietf.org Subject: [Ecrit] Phone BCP: Multiple Location " ED-39 If a UA has more than one location available to it, it MUST choose one location to route the call towards the PSAP. SP-16 If a proxy inserts location on behalf of an endpoint, and it has multiple locations available for the endpoint it MUST choose one location to use to route the call towards the PSAP. " I could imagine that someone might ask how to make a decision. So, how does the decision making look like? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 03:12:36 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADD0E3A6988; Mon, 31 Mar 2008 03:12:36 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE9A13A6988 for ; Mon, 31 Mar 2008 03:12:34 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JysOVrSlvrst for ; Mon, 31 Mar 2008 03:12:34 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6E2833A6930 for ; Mon, 31 Mar 2008 03:12:32 -0700 (PDT) Received: (qmail 18679 invoked by uid 0); 31 Mar 2008 10:12:29 -0000 Received: from 192.100.124.219 by www162.gmx.net with HTTP; Mon, 31 Mar 2008 12:12:29 +0200 (CEST) Date: Mon, 31 Mar 2008 12:12:29 +0200 From: "Hannes Tschofenig" In-Reply-To: <008b01c892a3$3a53bcb0$9744f444@cis.neustar.com> Message-ID: <20080331101229.122300@gmx.net> MIME-Version: 1.0 References: <47EFF030.5030802@gmx.net> <008b01c892a3$3a53bcb0$9744f444@cis.neustar.com> To: "Brian Rosen" , ecrit@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX191j+RuEIp1JxsnCFK5QA5ki85SHYhEepqRp+Xskh rvvHRNh9ZIE3RVqKYQy9Wa348h0Ymz/7DnNQ== X-GMX-UID: WtyCZ6JOeSEqa5IAqXUhoYZ+IGRvb0BC Subject: Re: [Ecrit] Phone BCP: Default Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Brian, I thought about the issue a bit more and I don't think that "default" for the element is actually a good idea at all. The method element was supposed to be used for indicating which location determination technique was used to derive the location information. "Default" is not really a location determination technique. Instead, what you really want to say is "I have added location information but it is probably of dubious quality since I had nothing else available. Be careful." Hence, I believe you want to have an indication of the quality of the data you provided. Ciao Hannes PS: Here is the text from RFC 4117. The usage of "dhcp" should be depricated from the registry since it is not a location determination technique either. Should be replaced by wiremap. Someone should talk to IANA todo that. 2.2.3. 'method' Element The optional 'method' element describes the way that the location information was derived or discovered. An example of this element (for a geographical position system) is: gps The possible values of the 'method' element are enumerated within an IANA registry. Implementations MUST limit the use of this method to the values shepherded by IANA. This document pre-populates the IANA registry with seven possible values; see Section 6.1 for more information. The 'method' element is useful, for example, when multiple sources are reporting location information for a given user, and some means of determining location might be considered more authoritative than others (i.e., a dynamic, real-time position system versus static provisioning associated with a target device). However, note that inclusion of 'method' might reveal sensitive information when the generator is providing intentionally coarsened location information. For example, when a LO is transmitted with 'DHCP' as the 'method', but the location information indicates only the city in which the generator is located, the sender has good justification to suspect that some location information is being withheld. Ciao Hannes -------- Original-Nachricht -------- > Datum: Sun, 30 Mar 2008 16:18:30 -0400 > Von: "Brian Rosen" > An: "\'Hannes Tschofenig\'" , ecrit@ietf.org > Betreff: RE: [Ecrit] Phone BCP: Default Location > Yes, I am aware of this. I will prepare a draft. > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Sunday, March 30, 2008 3:55 PM > To: ecrit@ietf.org > Subject: [Ecrit] Phone BCP: Default Location > > " > AN-23/SP-22 Default locations MUST be marked with method=Default and > the proxy MUST be identfied in provided-by element of the PIDF-LO. > " > > Someone should register the token "default". To my knowledge it is not > registered. > > _______________________________________________ > 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 ecrit-bounces@ietf.org Mon Mar 31 05:03:41 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEFEA3A6B55; Mon, 31 Mar 2008 05:03:40 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B74FF3A66B4 for ; Mon, 31 Mar 2008 05:03:39 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qv1L7pHCL6Yv for ; Mon, 31 Mar 2008 05:03:38 -0700 (PDT) Received: from anchor-internal-1.mail.demon.net (anchor-internal-1.mail.demon.net [195.173.56.100]) by core3.amsl.com (Postfix) with ESMTP id 88C783A6E55 for ; Mon, 31 Mar 2008 05:03:36 -0700 (PDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id m2VC3XJX025170Mon, 31 Mar 2008 12:03:33 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1JgIjd-0004tP-00; Mon, 31 Mar 2008 13:03:33 +0100 Date: Mon, 31 Mar 2008 13:03:33 +0100 From: "Clive D.W. Feather" To: Hannes Tschofenig Message-ID: <20080331120333.GS82714@finch-staff-1.thus.net> References: <47EFF015.1010601@gmx.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <47EFF015.1010601@gmx.net> User-Agent: Mutt/1.5.3i Cc: ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Indication of Numbers X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig said: > " > AN-5/INT-5 Access networks and intermediate devices providing wire > database location information SHOULD provide interior location data > (building, floor, room, cubicle) where possible. It is RECOMMENDED > that interior location be provided when spaces exceed approximately > 650 square meters. > " Please note, here and elsewhere, that the word is spelled "metre". It is a technical term defined by an international convention (the "Metre Convention") signed up to by 51 nations, *including the USA*, and ISO 31. See . -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 05:26:49 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 691AB3A6B05; Mon, 31 Mar 2008 05:26:49 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01F053A6C0A for ; Mon, 31 Mar 2008 05:26:48 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pd3o5TVUu-rs for ; Mon, 31 Mar 2008 05:26:44 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 1FD303A6B77 for ; Mon, 31 Mar 2008 05:26:43 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so1547077fgg.41 for ; Mon, 31 Mar 2008 05:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=VoNyCgGytIocr/pVdOhOPcWol+uhXiLNLLpuItuE/iM=; b=HQ162csKYiKy4G0fnp11Z3kn0MPUpHxJTH9S0Icta6Oth9CuO5FnGv9ov8Ov6/1Bws/f9GCm8Ho7riyePkqdU7+9ZKWz+VgwPIe4iCy9b0qTqnmRCUv6vnuH1FgeKkypDZ/R9LE4YjL7jHnagDd+rluQeaeQtxVRIZudYmvPuyU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BDQXWxZ/sqa/wEO3PuSXLZ5OVeZCtacjFjGlriACHQPZb0s/tkSP5VDh37s03z+7Psd2MWsmt3y4qaSKw9IZcQzPMhD5sqMlXJORM0UCb/BXDeTCQ/O1VuCiB3z6KGESPGonhx/zyfG3U2J8FfsnW2bcL4P1Q4lirq3LFPmZjts= Received: by 10.82.185.3 with SMTP id i3mr15426612buf.22.1206966392127; Mon, 31 Mar 2008 05:26:32 -0700 (PDT) Received: by 10.82.181.20 with HTTP; Mon, 31 Mar 2008 05:26:29 -0700 (PDT) Message-ID: Date: Mon, 31 Mar 2008 14:26:29 +0200 From: "Karl Heinz Wolf" To: "Hannes Tschofenig" In-Reply-To: <47EFF01E.3060306@gmx.net> MIME-Version: 1.0 Content-Disposition: inline References: <47EFF01E.3060306@gmx.net> Cc: ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: LCP interaction X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > " > ED-22/INT-15 Endpoints SHOULD try all LCPs supported by the device in > any order or in parallel. The first one that succeeds in supplying > location can be used. > " > > Didn't Barbara provide more details on how this procedure should work? > probably in the DSL Forum documents? see http://www.ietf.org/mail-archive/web/ecrit/current/msg04309.html A sequence flow is in the appendix of http://www.dial911anddie.com/DSLForum/WT-164v2.pdf karl heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 05:47:36 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A97143A6E5D; Mon, 31 Mar 2008 05:47:36 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 126FB28C271 for ; Mon, 31 Mar 2008 05:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.621 X-Spam-Level: X-Spam-Status: No, score=-101.621 tagged_above=-999 required=5 tests=[AWL=0.978, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BK99vPtElp6n for ; Mon, 31 Mar 2008 05:47:34 -0700 (PDT) Received: from aismt06p.bellsouth.com (aismt06p.bellsouth.com [139.76.165.211]) by core3.amsl.com (Postfix) with ESMTP id 06D6D3A69FB for ; Mon, 31 Mar 2008 05:47:33 -0700 (PDT) Received: from ([139.76.131.91]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.43972500; Mon, 31 Mar 2008 08:47:13 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 31 Mar 2008 08:47:13 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 31 Mar 2008 08:47:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 31 Mar 2008 08:47:12 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA080ECEE2@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: LCP interaction Thread-Index: AciTKo81pO+ao0tVQhGLL/4Nrq9PGAAAm4eg References: <47EFF01E.3060306@gmx.net> From: "Stark, Barbara" To: "Karl Heinz Wolf" , "Hannes Tschofenig" X-OriginalArrivalTime: 31 Mar 2008 12:47:13.0298 (UTC) FILETIME=[57A01720:01C8932D] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: LCP interaction X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I just sent Jon and Cullen a new liaison with the latest version of the DSLF doc. Yes, that doc does provide a lot more detail on how this might work. In discussions with Brian, though, I though we were going to leave that level of detail in the DSLF doc, and not try to put it in the BCP. But I'm certainly open to having it in the BCP. The DSLF doc also has guidance on selecting from among multiple locations. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Karl Heinz Wolf Sent: Monday, March 31, 2008 8:26 AM To: Hannes Tschofenig Cc: ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: LCP interaction > " > ED-22/INT-15 Endpoints SHOULD try all LCPs supported by the device in > any order or in parallel. The first one that succeeds in supplying > location can be used. > " > > Didn't Barbara provide more details on how this procedure should work? > probably in the DSL Forum documents? see http://www.ietf.org/mail-archive/web/ecrit/current/msg04309.html A sequence flow is in the appendix of http://www.dial911anddie.com/DSLForum/WT-164v2.pdf karl heinz _______________________________________________ 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 ecrit-bounces@ietf.org Mon Mar 31 05:51:41 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CE783A69FB; Mon, 31 Mar 2008 05:51:41 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4F43A66B4 for ; Mon, 31 Mar 2008 05:51:39 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwpFSFwhWzBO for ; Mon, 31 Mar 2008 05:51:39 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7F51B3A69FB for ; Mon, 31 Mar 2008 05:51:38 -0700 (PDT) Received: (qmail 3167 invoked by uid 0); 31 Mar 2008 12:51:34 -0000 Received: from 192.100.124.219 by www148.gmx.net with HTTP; Mon, 31 Mar 2008 14:51:34 +0200 (CEST) Date: Mon, 31 Mar 2008 14:51:34 +0200 From: "Hannes Tschofenig" In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA080ECEE2@crexc41p> Message-ID: <20080331125134.249460@gmx.net> MIME-Version: 1.0 References: <47EFF01E.3060306@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA080ECEE2@crexc41p> To: "Stark, Barbara" , khwolf1@gmail.com X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+WTxcdrYKW97zqUC5fysfsJcTTg2yjtnc9ruOluo JKk+dt4DK3gcAbZaeO5A0ggMNK3W9mlXXmIQ== X-GMX-UID: ZenCdkZJIydmFNYGtmZrB2NSa2FkZpUX Cc: ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: LCP interaction X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Why did you conclude that this should not go into the document? Because it is largely implementation dependent? Ciao Hannes PS: Could you send the liaison document to the ECRIT list? -------- Original-Nachricht -------- > Datum: Mon, 31 Mar 2008 08:47:12 -0400 > Von: "Stark, Barbara" > An: "Karl Heinz Wolf" , "Hannes Tschofenig" > CC: ecrit@ietf.org > Betreff: RE: [Ecrit] Phone BCP: LCP interaction > I just sent Jon and Cullen a new liaison with the latest version of the > DSLF doc. Yes, that doc does provide a lot more detail on how this might > work. In discussions with Brian, though, I though we were going to leave > that level of detail in the DSLF doc, and not try to put it in the BCP. > But I'm certainly open to having it in the BCP. > > The DSLF doc also has guidance on selecting from among multiple > locations. > Barbara > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Karl Heinz Wolf > Sent: Monday, March 31, 2008 8:26 AM > To: Hannes Tschofenig > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Phone BCP: LCP interaction > > > " > > ED-22/INT-15 Endpoints SHOULD try all LCPs supported by the device > in > > any order or in parallel. The first one that succeeds in supplying > > location can be used. > > " > > > > Didn't Barbara provide more details on how this procedure should > work? > > > > probably in the DSL Forum documents? > > see http://www.ietf.org/mail-archive/web/ecrit/current/msg04309.html > > A sequence flow is in the appendix of > http://www.dial911anddie.com/DSLForum/WT-164v2.pdf > > > karl heinz > _______________________________________________ > 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 ecrit-bounces@ietf.org Mon Mar 31 05:59:37 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4D9F28C338; Mon, 31 Mar 2008 05:59:37 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD0EF28C338 for ; Mon, 31 Mar 2008 05:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=0.851, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0MeqFxuctrx for ; Mon, 31 Mar 2008 05:59:32 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id B417328C271 for ; Mon, 31 Mar 2008 05:59:32 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JgJbi-0003gy-JU; Mon, 31 Mar 2008 07:59:26 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Hannes Tschofenig'" , References: <47EFF030.5030802@gmx.net> Date: Mon, 31 Mar 2008 08:59:27 -0400 Message-ID: <00e701c8932f$0ee90f80$6901a8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciSoBsXzeiyM5C1TbiPfHV2vt2oAQAA98TkACKpIhA= In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Phone BCP: Default Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org No, it represents the best available location of the user. It was determined by some element who failed to get it by some other method, and is using a default value which was predefined for that purpose. The best available location is the default value, and the method used to determine it was the 'default' method. I think it's appropriate as defined. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Sunday, March 30, 2008 4:34 PM To: Hannes Tschofenig; ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Default Location Actually this is a misuse of the method token. The method token says how location was determined for inclusion in the PIDF-LO. The intent I read from this requirement is that the method is attempting to say that the location doesn't represent where the end point is at all, but is what they have registered as a default location. I think you need a new element in the PIDF-LO to represent this. Something like: yes or default Then it could have a value of "current" or "recent" or other kind of subjective things too. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig Sent: Sun 3/30/2008 2:55 PM To: ecrit@ietf.org Subject: [Ecrit] Phone BCP: Default Location " AN-23/SP-22 Default locations MUST be marked with method=Default and the proxy MUST be identfied in provided-by element of the PIDF-LO. " Someone should register the token "default". To my knowledge it is not registered. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 06:06:42 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A763E3A6CB5; Mon, 31 Mar 2008 06:06:42 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2369B3A6E52 for ; Mon, 31 Mar 2008 06:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.761 X-Spam-Level: X-Spam-Status: No, score=-101.761 tagged_above=-999 required=5 tests=[AWL=0.838, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cOYzWtrWfDc for ; Mon, 31 Mar 2008 06:06:29 -0700 (PDT) Received: from aismt07p.bellsouth.com (aismt07p.bellsouth.com [139.76.165.213]) by core3.amsl.com (Postfix) with ESMTP id 3E4483A69EB for ; Mon, 31 Mar 2008 06:06:19 -0700 (PDT) Received: from ([139.76.131.91]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.198536983; Mon, 31 Mar 2008 09:05:35 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 31 Mar 2008 09:05:35 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 31 Mar 2008 09:05:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 31 Mar 2008 09:05:34 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA080ECEF5@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: Multiple Location Thread-Index: AciSoBSicmd+wT1mQom8/iePcnSz0wABYVlrACJtvEA= References: <47EFF025.9000705@gmx.net> From: "Stark, Barbara" To: "Winterbottom, James" , "Hannes Tschofenig" , X-OriginalArrivalTime: 31 Mar 2008 13:05:35.0505 (UTC) FILETIME=[E8978810:01C8932F] Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org It's my understanding that PIDF-LO only describes multiple location precedence within a single message. It doesn't describe how to prioritize multiple locations received from various sources, received in multiple messages (or statically configured) at various times. I did include that sort of logic in my latest DSLF draft. If there is a desire to have some of this in phonebcp, I'm fine with that. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Sunday, March 30, 2008 4:36 PM To: Hannes Tschofenig; ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Multiple Location PIDF-LO profile describes how to choose the correct location for exactly this purpose. That is the application form which the original requirements were drawn. -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig Sent: Sun 3/30/2008 2:55 PM To: ecrit@ietf.org Subject: [Ecrit] Phone BCP: Multiple Location " ED-39 If a UA has more than one location available to it, it MUST choose one location to route the call towards the PSAP. SP-16 If a proxy inserts location on behalf of an endpoint, and it has multiple locations available for the endpoint it MUST choose one location to use to route the call towards the PSAP. " I could imagine that someone might ask how to make a decision. So, how does the decision making look like? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 06:08:08 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1330F3A6E69; Mon, 31 Mar 2008 06:08:08 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778113A6E69 for ; Mon, 31 Mar 2008 06:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.866 X-Spam-Level: X-Spam-Status: No, score=-101.866 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlNkGeDNARiv for ; Mon, 31 Mar 2008 06:08:02 -0700 (PDT) Received: from aismt06p.bellsouth.com (aismt06p.bellsouth.com [139.76.165.211]) by core3.amsl.com (Postfix) with ESMTP id 020213A6D18 for ; Mon, 31 Mar 2008 06:08:01 -0700 (PDT) Received: from ([139.76.131.87]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.43975100; Mon, 31 Mar 2008 09:07:39 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 31 Mar 2008 09:07:39 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 31 Mar 2008 09:07:39 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 31 Mar 2008 09:07:38 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA080ECEFC@crexc41p> In-Reply-To: <006001c89293$740e4840$9744f444@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT Framework: Security thread-index: AciSb0XK31IL/Qg9SwGqffNImzemTQAI4QswACY6w8A= References: <47EF9E62.6090609@gmx.net> <006001c89293$740e4840$9744f444@cis.neustar.com> From: "Stark, Barbara" To: "Brian Rosen" , "Hannes Tschofenig" , X-OriginalArrivalTime: 31 Mar 2008 13:07:39.0321 (UTC) FILETIME=[32645A90:01C89330] Subject: Re: [Ecrit] ECRIT Framework: Security X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Most proposals I've seen for future "dual mode" phones with Wi-Fi connectivity are that the phone establishes an IPsec session to the cellular carrier. I want to make sure that we don't in any way reject or restrict this solution by mandating that TLS is the only way to achieve secure signaling. IPsec meets the real requirement of providing encrypted signaling. And, unlike the TLS proposal, it also provides encryption of the RTP stream. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Sunday, March 30, 2008 2:26 PM To: 'Hannes Tschofenig'; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Framework: Security I certainly wouldn't think it was all that common, but IPsec would work between a proxy and a UA, right? With regard to "Many SIP devices...", despite the fact that 3261 says they should, many UAs don't. That's a fact. We need them to in order to handle location privacy. I think it's worth pointing that out. This is requesting a change in implementations. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 10:06 AM To: ecrit@ietf.org Subject: [Ecrit] ECRIT Framework: Security You write: " IPSEC [RFC2401] is an acceptable alternative to TLS when used with an equivalent crypto suite. " I guess you mean that IPsec **between proxies** provides equivalent security compared to TLS. I don't think you suggest to run IPsec from the end host to the proxy You write: " Location may be used for routing by multiple proxy servers on the path. Confidentiality mechanisms such as S/MIME encryption of SIP signaling [RFC3261] cannot be used because they obscure location. Only hop-by-hop mechanisms such as TLS should be used. Many SIP devices do not support TLS. Implementing location conveyance in SIP mandates inclusion of TLS support. " You might want to be a bit more specific. S/MIME encryption of PIDF-LOs must not be used when proxies are supposed to perform location based routing. They need to be able to inspect the PIDF-LO in order todo their job. Delete " Many SIP devices do not support TLS." since it does not add too much value here. _______________________________________________ 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 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 06:08:31 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069843A6E6D; Mon, 31 Mar 2008 06:08:31 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA93A3A6E5D for ; Mon, 31 Mar 2008 06:08:29 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLcWZVVFL3ff for ; Mon, 31 Mar 2008 06:08:28 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 28DDC28C39E for ; Mon, 31 Mar 2008 06:08:28 -0700 (PDT) Received: (qmail 15409 invoked by uid 0); 31 Mar 2008 13:08:26 -0000 Received: from 192.100.124.219 by www158.gmx.net with HTTP; Mon, 31 Mar 2008 15:08:25 +0200 (CEST) Date: Mon, 31 Mar 2008 15:08:25 +0200 From: "Hannes Tschofenig" In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA080ECEF5@crexc41p> Message-ID: <20080331130825.115280@gmx.net> MIME-Version: 1.0 References: <47EFF025.9000705@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA080ECEF5@crexc41p> To: "Stark, Barbara" , ecrit@ietf.org, James.Winterbottom@andrew.com X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX18m6Ic/fMEmaG2GNBpOY4P5H+ms7XxxhK1OTdevoc ID/S5xQAKNQTYSnzMKW8QEVevpU506Xcu4iw== X-GMX-UID: e9vIcjRebmwoUIERqjZLKApPUzc4ctEo Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Should we at least reference PIDF-LO profile and indicate constraints? -------- Original-Nachricht -------- > Datum: Mon, 31 Mar 2008 09:05:34 -0400 > Von: "Stark, Barbara" > An: "Winterbottom, James" , "Hannes Tschofenig" , ecrit@ietf.org > Betreff: RE: [Ecrit] Phone BCP: Multiple Location > It's my understanding that PIDF-LO only describes multiple location > precedence within a single message. It doesn't describe how to > prioritize multiple locations received from various sources, received > in multiple messages (or statically configured) at various times. > > I did include that sort of logic in my latest DSLF draft. If there is a > desire to have some of this in phonebcp, I'm fine with that. > Barbara > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Winterbottom, James > Sent: Sunday, March 30, 2008 4:36 PM > To: Hannes Tschofenig; ecrit@ietf.org > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > PIDF-LO profile describes how to choose the correct location for exactly > this purpose. > That is the application form which the original requirements were drawn. > > > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > Sent: Sun 3/30/2008 2:55 PM > To: ecrit@ietf.org > Subject: [Ecrit] Phone BCP: Multiple Location > > " > ED-39 If a UA has more than one location available to it, it MUST > choose one location to route the call towards the PSAP. > > SP-16 If a proxy inserts location on behalf of an endpoint, and it > has multiple locations available for the endpoint it MUST choose one > location to use to route the call towards the PSAP. > " > > I could imagine that someone might ask how to make a decision. > So, how does the decision making look like? > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > ------------------------------------------------------------------------ > ------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ > ------------------------ > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 06:08:35 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C1D428C439; Mon, 31 Mar 2008 06:08:35 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9325228C432 for ; Mon, 31 Mar 2008 06:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbGAsMTMdwan for ; Mon, 31 Mar 2008 06:08:29 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id C93C128C439 for ; Mon, 31 Mar 2008 06:08:28 -0700 (PDT) Received: from dhcp31.cs.columbia.edu (dhcp31.cs.columbia.edu [128.59.19.231]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m2VD8Lji009717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 31 Mar 2008 09:08:22 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: "Clive D.W. Feather" In-Reply-To: <20080331120333.GS82714@finch-staff-1.thus.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 31 Mar 2008 09:08:23 -0400 References: <47EFF015.1010601@gmx.net> <20080331120333.GS82714@finch-staff-1.thus.net> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Indication of Numbers X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The appropriate solution is to use 'm', as it avoids the problem. See http://en.wikipedia.org/wiki/Metric_system#Spelling_variations On Mar 31, 2008, at 8:03 AM, Clive D.W. Feather wrote: > Hannes Tschofenig said: >> " >> AN-5/INT-5 Access networks and intermediate devices providing wire >> database location information SHOULD provide interior location data >> (building, floor, room, cubicle) where possible. It is RECOMMENDED >> that interior location be provided when spaces exceed approximately >> 650 square meters. >> " > > Please note, here and elsewhere, that the word is spelled "metre". > It is a > technical term defined by an international convention (the "Metre > Convention") signed up to by 51 nations, *including the USA*, and > ISO 31. > > See . > > -- > Clive D.W. Feather | Work: | Tel: +44 20 > 8495 6138 > Internet Expert | Home: | Fax: +44 870 > 051 9937 > Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 > 377646 > THUS plc | | > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 06:13:43 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADA153A6996; Mon, 31 Mar 2008 06:13:43 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0B693A6E6D for ; Mon, 31 Mar 2008 06:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[AWL=0.843, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gxzsvo3SqVUd for ; Mon, 31 Mar 2008 06:13:41 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id DAE1A3A6996 for ; Mon, 31 Mar 2008 06:13:41 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JgJpP-0004yq-T3; Mon, 31 Mar 2008 08:13:36 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Clive D.W. Feather'" References: <47EFF015.1010601@gmx.net><20080331120333.GS82714@finch-staff-1.thus.net> Date: Mon, 31 Mar 2008 09:13:36 -0400 Message-ID: <00e801c89331$095783b0$6901a8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciTMFQsxGWQmczmTnigdvksyjVL1wAAJkkA In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Indication of Numbers X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm happy with that, but do I say (in ASCII) m2? For square meters (or metres)? Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, March 31, 2008 9:08 AM To: Clive D.W. Feather Cc: ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Indication of Numbers The appropriate solution is to use 'm', as it avoids the problem. See http://en.wikipedia.org/wiki/Metric_system#Spelling_variations On Mar 31, 2008, at 8:03 AM, Clive D.W. Feather wrote: > Hannes Tschofenig said: >> " >> AN-5/INT-5 Access networks and intermediate devices providing wire >> database location information SHOULD provide interior location data >> (building, floor, room, cubicle) where possible. It is RECOMMENDED >> that interior location be provided when spaces exceed approximately >> 650 square meters. >> " > > Please note, here and elsewhere, that the word is spelled "metre". > It is a > technical term defined by an international convention (the "Metre > Convention") signed up to by 51 nations, *including the USA*, and > ISO 31. > > See . > > -- > Clive D.W. Feather | Work: | Tel: +44 20 > 8495 6138 > Internet Expert | Home: | Fax: +44 870 > 051 9937 > Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 > 377646 > THUS plc | | > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://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 ecrit-bounces@ietf.org Mon Mar 31 06:29:47 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079523A6E2F; Mon, 31 Mar 2008 06:29:47 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD523A6E2F for ; Mon, 31 Mar 2008 06:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.947 X-Spam-Level: X-Spam-Status: No, score=-101.947 tagged_above=-999 required=5 tests=[AWL=0.652, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6RGS+eCCFgN for ; Mon, 31 Mar 2008 06:29:40 -0700 (PDT) Received: from aismt07p.bellsouth.com (aismt07p.bellsouth.com [139.76.165.213]) by core3.amsl.com (Postfix) with ESMTP id 9CC003A6A64 for ; Mon, 31 Mar 2008 06:29:40 -0700 (PDT) Received: from ([139.76.131.91]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.198540293; Mon, 31 Mar 2008 09:29:17 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 31 Mar 2008 09:29:17 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 31 Mar 2008 09:29:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 31 Mar 2008 09:29:16 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA080ECF11@crexc41p> In-Reply-To: <006101c89294$b45036b0$9744f444@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT Framework: Dial Strings Thread-Index: AciSb0jFlOgz5NA4RaqbA9nfmYGMvgAJC8bwACZT2rA= References: <47EF9E65.1090402@gmx.net> <006101c89294$b45036b0$9744f444@cis.neustar.com> From: "Stark, Barbara" To: "Brian Rosen" , "Hannes Tschofenig" , X-OriginalArrivalTime: 31 Mar 2008 13:29:17.0003 (UTC) FILETIME=[37DEE9B0:01C89333] Subject: Re: [Ecrit] ECRIT Framework: Dial Strings X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm not aware of any country that requires that companies operating in foreign countries recognize "local" dial strings, when their customers are traveling into the "local" country. Likewise, I'm not aware of any country that has emergency dialing legislation regarding devices that visitors bring into the country or that residents bring in from foreign countries. I think the "legal requirements" argument is empty. But I don't see that requiring end devices to request local dial strings is a bad thing. I also think that there's a strong likelihood that "home" governments will require "home" service providers and "home" devices to support "home" dial strings, no matter where the device may go. Since the BCP doesn't preclude this, and sufficiently describes how this can be done, I'm ok with the phonebcp language. So, I'm fine with the requirements as they are. But I still think that this "legal" argument is backwards and incorrect. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Sunday, March 30, 2008 2:35 PM To: 'Hannes Tschofenig'; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Framework: Dial Strings No current systems recognize the home dial string unless they happen to be the same, or there is some fixed strings always recognized. There are legal requirements for the local one, and there are none for the home one. Unless you have some good reason, I think there is no requirement to support the home dial string. I'm not even sure it's a good idea. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 10:06 AM To: ecrit@ietf.org Subject: [Ecrit] ECRIT Framework: Dial Strings You write: " Therefore, the visited dial string must work while having the home dial string work is optional. " I don't understand this reasoning on why the home dial string is optional. From an implementation point of view you have to implement the home emergency dial strings since in most cases devices will be used "at home". Why isn't the ability to understand the home dial string mandatory? _______________________________________________ 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 ecrit-bounces@ietf.org Mon Mar 31 08:53:46 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0072D3A6BDB; Mon, 31 Mar 2008 08:53:46 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 153343A6994 for ; Mon, 31 Mar 2008 08:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 942SysakPLdw for ; Mon, 31 Mar 2008 08:53:43 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 495AD3A6A98 for ; Mon, 31 Mar 2008 08:53:43 -0700 (PDT) Received: from dyn-160-39-250-210.dyn.columbia.edu (dyn-160-39-250-210.dyn.columbia.edu [160.39.250.210]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m2VFrZl2006935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 31 Mar 2008 11:53:35 -0400 (EDT) Message-Id: <6175DFB2-299B-4B0D-BB2B-55F44FCA113B@cs.columbia.edu> From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <00e801c89331$095783b0$6901a8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 31 Mar 2008 11:53:35 -0400 References: <47EFF015.1010601@gmx.net><20080331120333.GS82714@finch-staff-1.thus.net> <00e801c89331$095783b0$6901a8c0@cis.neustar.com> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Indication of Numbers X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I guess m^2 is common. On Mar 31, 2008, at 9:13 AM, Brian Rosen wrote: > I'm happy with that, but do I say (in ASCII) m2? For square meters > (or > metres)? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 09:07:09 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E096B3A6B85; Mon, 31 Mar 2008 09:07:09 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421273A69C3 for ; Mon, 31 Mar 2008 09:07:09 -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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5RvrhaoB3m7 for ; Mon, 31 Mar 2008 09:07:08 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 3E5113A6814 for ; Mon, 31 Mar 2008 09:07:05 -0700 (PDT) Received: from dyn-160-39-250-210.dyn.columbia.edu (dyn-160-39-250-210.dyn.columbia.edu [160.39.250.210]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m2VG6uRq017755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 31 Mar 2008 12:06:57 -0400 (EDT) Message-Id: <89678C47-7277-4EA4-9F4A-B5F7C8C831A3@cs.columbia.edu> From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <008f01c892a3$c781db80$9744f444@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 31 Mar 2008 12:06:56 -0400 References: <47EFF059.70601@gmx.net> <008f01c892a3$c781db80$9744f444@cis.neustar.com> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Testing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is one of the topics that requires more discussion. There are several possibilities: (1) Register a .test for every service. That seems inelegant if we assume that just about every service will need this. This also doesn't quite fit when we want to subset services, such as urn:service:sos.police.postal and urn:service.sos.police.transport since police.test is not parallel to police.postal. (2) Have an orthogonal mechanism that indicates "this is a test". Presumably, this would have to be in LoST, since the SIP URL may differ between test and operational destinations. (2a) A flag in the query. (2b) An additional entry in the response, returning a separate service URL. My preference would be (2b), as it minimizes the number of queries compared to (1) and (2a) and avoids the labeling issues. This can easily be added as a trivial extension draft to LoST if we don't want to do this at this late stage. Henning On Mar 30, 2008, at 4:22 PM, Brian Rosen wrote: > Henning, your call. Should we register them? > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of > Hannes Tschofenig > Sent: Sunday, March 30, 2008 3:56 PM > To: ecrit@ietf.org > Subject: [Ecrit] Phone BCP: Testing > > You write: > > " > ED-78 INVITE requests to a service URN ending in ".test" indicates a > request for an automated test. For example, > "urn:service.sos.fire.test". > " > > I am not sure whether one can actually add a .test to the defined URNs > without registering a new set of URNs. Have you checked that? > > _______________________________________________ > 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 ecrit-bounces@ietf.org Mon Mar 31 09:17:52 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 600AA3A695F; Mon, 31 Mar 2008 09:17:52 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FBD73A68C8 for ; Mon, 31 Mar 2008 09:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.163 X-Spam-Level: X-Spam-Status: No, score=-1.163 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcsFz1JnFRKD for ; Mon, 31 Mar 2008 09:17:49 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id ED9EA3A67E2 for ; Mon, 31 Mar 2008 09:17:44 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JgMhV-0006bn-Hx; Mon, 31 Mar 2008 11:17:37 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" References: <47EFF059.70601@gmx.net> <008f01c892a3$c781db80$9744f444@cis.neustar.com> <89678C47-7277-4EA4-9F4A-B5F7C8C831A3@cs.columbia.edu> Date: Mon, 31 Mar 2008 12:17:39 -0400 Message-ID: <014101c8934a$bf63c970$6901a8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciTST1GrjMR9EbJSbKGUwO6zWfJtAAAM9Tw In-Reply-To: <89678C47-7277-4EA4-9F4A-B5F7C8C831A3@cs.columbia.edu> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Testing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Henning Please recall that the first idea was a urn parameter. Then it was the .test idea. Now we're looking at another return value. I don't really care, but I want to pick a mechanism and finish the discussion. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, March 31, 2008 12:07 PM To: Brian Rosen Cc: 'Hannes Tschofenig'; ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Testing This is one of the topics that requires more discussion. There are several possibilities: (1) Register a .test for every service. That seems inelegant if we assume that just about every service will need this. This also doesn't quite fit when we want to subset services, such as urn:service:sos.police.postal and urn:service.sos.police.transport since police.test is not parallel to police.postal. (2) Have an orthogonal mechanism that indicates "this is a test". Presumably, this would have to be in LoST, since the SIP URL may differ between test and operational destinations. (2a) A flag in the query. (2b) An additional entry in the response, returning a separate service URL. My preference would be (2b), as it minimizes the number of queries compared to (1) and (2a) and avoids the labeling issues. This can easily be added as a trivial extension draft to LoST if we don't want to do this at this late stage. Henning On Mar 30, 2008, at 4:22 PM, Brian Rosen wrote: > Henning, your call. Should we register them? > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of > Hannes Tschofenig > Sent: Sunday, March 30, 2008 3:56 PM > To: ecrit@ietf.org > Subject: [Ecrit] Phone BCP: Testing > > You write: > > " > ED-78 INVITE requests to a service URN ending in ".test" indicates a > request for an automated test. For example, > "urn:service.sos.fire.test". > " > > I am not sure whether one can actually add a .test to the defined URNs > without registering a new set of URNs. Have you checked that? > > _______________________________________________ > 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 ecrit-bounces@ietf.org Mon Mar 31 09:59:40 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0170E28C222; Mon, 31 Mar 2008 09:59:40 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00C9A3A6AB7 for ; Mon, 31 Mar 2008 09:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuSPKohVnAHb for ; Mon, 31 Mar 2008 09:59:38 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 257323A6C6B for ; Mon, 31 Mar 2008 09:59:38 -0700 (PDT) Received: from dhcp31.cs.columbia.edu (dhcp31.cs.columbia.edu [128.59.19.231]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m2VGxU3H000533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 31 Mar 2008 12:59:30 -0400 (EDT) Message-Id: <771CF8C9-6595-42F3-AA77-EA69046AC906@cs.columbia.edu> From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <014101c8934a$bf63c970$6901a8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 31 Mar 2008 12:59:30 -0400 References: <47EFF059.70601@gmx.net> <008f01c892a3$c781db80$9744f444@cis.neustar.com> <89678C47-7277-4EA4-9F4A-B5F7C8C831A3@cs.columbia.edu> <014101c8934a$bf63c970$6901a8c0@cis.neustar.com> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Testing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm happy to draft the LoST extension if there's no objection. I think we now have explored the option space reasonably well, so it's time to move ahead, as you say. On Mar 31, 2008, at 12:17 PM, Brian Rosen wrote: > Henning > > Please recall that the first idea was a urn parameter. Then it was > the > .test idea. Now we're looking at another return value. > > I don't really care, but I want to pick a mechanism and finish the > discussion. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 10:49:37 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840EA28C3E0; Mon, 31 Mar 2008 10:49:37 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C059128C395 for ; Mon, 31 Mar 2008 10:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.776 X-Spam-Level: X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5 tests=[AWL=0.823, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-UJN4WxRvIG for ; Mon, 31 Mar 2008 10:49:33 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9513428C432 for ; Mon, 31 Mar 2008 10:46:39 -0700 (PDT) Received: (qmail invoked by alias); 31 Mar 2008 17:46:34 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp025) with SMTP; 31 Mar 2008 19:46:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18hPXFNIdUh7fp/XjZeRpSAUbGV7fbXUBYtDTkeqT EW6K4J9eHO9C75 Message-ID: <47F12375.8000700@gmx.net> Date: Mon, 31 Mar 2008 20:46:29 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Henning Schulzrinne References: <47EFF059.70601@gmx.net> <008f01c892a3$c781db80$9744f444@cis.neustar.com> <89678C47-7277-4EA4-9F4A-B5F7C8C831A3@cs.columbia.edu> <014101c8934a$bf63c970$6901a8c0@cis.neustar.com> <771CF8C9-6595-42F3-AA77-EA69046AC906@cs.columbia.edu> In-Reply-To: <771CF8C9-6595-42F3-AA77-EA69046AC906@cs.columbia.edu> X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Testing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org What was wrong with the URN parameter idea? It was in former versions of draft-ietf-ecrit-phonebcp? Henning Schulzrinne wrote: > I'm happy to draft the LoST extension if there's no objection. I think > we now have explored the option space reasonably well, so it's time to > move ahead, as you say. > > On Mar 31, 2008, at 12:17 PM, Brian Rosen wrote: > >> Henning >> >> Please recall that the first idea was a urn parameter. Then it was the >> .test idea. Now we're looking at another return value. >> >> I don't really care, but I want to pick a mechanism and finish the >> discussion. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 10:53:02 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E53428C27C; Mon, 31 Mar 2008 10:53:02 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79DB028C198 for ; Mon, 31 Mar 2008 10:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7bwKAnjAxDk for ; Mon, 31 Mar 2008 10:53:00 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 5F0153A6E3A for ; Mon, 31 Mar 2008 10:50:39 -0700 (PDT) Received: from dhcp31.cs.columbia.edu (dhcp31.cs.columbia.edu [128.59.19.231]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m2VHoWWG015669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 31 Mar 2008 13:50:32 -0400 (EDT) Message-Id: <03A42269-889E-4A75-B8D4-98127959C16E@cs.columbia.edu> From: Henning Schulzrinne To: Hannes Tschofenig In-Reply-To: <47F12375.8000700@gmx.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 31 Mar 2008 13:50:32 -0400 References: <47EFF059.70601@gmx.net> <008f01c892a3$c781db80$9744f444@cis.neustar.com> <89678C47-7277-4EA4-9F4A-B5F7C8C831A3@cs.columbia.edu> <014101c8934a$bf63c970$6901a8c0@cis.neustar.com> <771CF8C9-6595-42F3-AA77-EA69046AC906@cs.columbia.edu> <47F12375.8000700@gmx.net> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Testing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org It has two disadvantages: - It requires roughly twice the number of queries to the LoST infrastructure since every end system will need both the non-test and test services. - It requires a non-backwards-compatible update of RFC 5031. I'm less concerned about the second issue, but before doing this, I'd rather know that this is the right outcome. Henning On Mar 31, 2008, at 1:46 PM, Hannes Tschofenig wrote: > What was wrong with the URN parameter idea? > It was in former versions of draft-ietf-ecrit-phonebcp? > > > Henning Schulzrinne wrote: >> I'm happy to draft the LoST extension if there's no objection. I >> think we now have explored the option space reasonably well, so >> it's time to move ahead, as you say. >> >> On Mar 31, 2008, at 12:17 PM, Brian Rosen wrote: >> >>> Henning >>> >>> Please recall that the first idea was a urn parameter. Then it >>> was the >>> .test idea. Now we're looking at another return value. >>> >>> I don't really care, but I want to pick a mechanism and finish the >>> discussion. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 11:00:01 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261FD3A6B05; Mon, 31 Mar 2008 11:00:01 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3143628C13B for ; Mon, 31 Mar 2008 11:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[AWL=0.819, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1kpqLFqNAt5 for ; Mon, 31 Mar 2008 10:59:59 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DF0A628C16C for ; Mon, 31 Mar 2008 10:59:58 -0700 (PDT) Received: (qmail invoked by alias); 31 Mar 2008 17:59:56 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp050) with SMTP; 31 Mar 2008 19:59:56 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18L25ZBKwQLdysyHnSH7ei/eZ0+/b8Q8Sp4oDfH+i hA4Qu3I4odoZPA Message-ID: <47F12698.5010307@gmx.net> Date: Mon, 31 Mar 2008 20:59:52 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Henning Schulzrinne References: <47EFF059.70601@gmx.net> <008f01c892a3$c781db80$9744f444@cis.neustar.com> <89678C47-7277-4EA4-9F4A-B5F7C8C831A3@cs.columbia.edu> <014101c8934a$bf63c970$6901a8c0@cis.neustar.com> <771CF8C9-6595-42F3-AA77-EA69046AC906@cs.columbia.edu> <47F12375.8000700@gmx.net> <03A42269-889E-4A75-B8D4-98127959C16E@cs.columbia.edu> In-Reply-To: <03A42269-889E-4A75-B8D4-98127959C16E@cs.columbia.edu> X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Testing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Henning, I thought that the "test" parameter would be used in a different way, namely: * A LoST client issues a query for urn:service.sos.fire * A LoST server provides an answer. * The client creates an INVITE with the Service URN parameter and appends the "test" parameter In this example: urn:service.sos.fire;test I understand the problem with RFC 5031. Ciao Hannes Henning Schulzrinne wrote: > It has two disadvantages: > > - It requires roughly twice the number of queries to the LoST > infrastructure since every end system will need both the non-test and > test services. > > - It requires a non-backwards-compatible update of RFC 5031. > > I'm less concerned about the second issue, but before doing this, I'd > rather know that this is the right outcome. > > Henning > > On Mar 31, 2008, at 1:46 PM, Hannes Tschofenig wrote: > >> What was wrong with the URN parameter idea? >> It was in former versions of draft-ietf-ecrit-phonebcp? >> >> >> Henning Schulzrinne wrote: >>> I'm happy to draft the LoST extension if there's no objection. I >>> think we now have explored the option space reasonably well, so it's >>> time to move ahead, as you say. >>> >>> On Mar 31, 2008, at 12:17 PM, Brian Rosen wrote: >>> >>>> Henning >>>> >>>> Please recall that the first idea was a urn parameter. Then it was >>>> the >>>> .test idea. Now we're looking at another return value. >>>> >>>> I don't really care, but I want to pick a mechanism and finish the >>>> discussion. >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 11:07:23 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A404F3A6A9A; Mon, 31 Mar 2008 11:07:23 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36CC03A68CE for ; Mon, 31 Mar 2008 11:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCKKOsjOl1I1 for ; Mon, 31 Mar 2008 11:07:21 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 4F9C53A6856 for ; Mon, 31 Mar 2008 11:07:21 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JgOPZ-0008NQ-C8; Mon, 31 Mar 2008 13:07:13 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'Henning Schulzrinne'" References: <47EFF059.70601@gmx.net> <008f01c892a3$c781db80$9744f444@cis.neustar.com> <89678C47-7277-4EA4-9F4A-B5F7C8C831A3@cs.columbia.edu> <014101c8934a$bf63c970$6901a8c0@cis.neustar.com> <771CF8C9-6595-42F3-AA77-EA69046AC906@cs.columbia.edu> <47F12375.8000700@gmx.net> <03A42269-889E-4A75-B8D4-98127959C16E@cs.columbia.edu> <47F12698.5010307@gmx.net> Date: Mon, 31 Mar 2008 14:07:15 -0400 Message-ID: <016d01c8935a$0ebdab30$6901a8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciTWQXgwVtlTaK5TByoUSRlTn3eHAAANtIQ In-Reply-To: <47F12698.5010307@gmx.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Testing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yeah, that's what I thought. -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Monday, March 31, 2008 2:00 PM To: Henning Schulzrinne Cc: Brian Rosen; ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Testing Hi Henning, I thought that the "test" parameter would be used in a different way, namely: * A LoST client issues a query for urn:service.sos.fire * A LoST server provides an answer. * The client creates an INVITE with the Service URN parameter and appends the "test" parameter In this example: urn:service.sos.fire;test I understand the problem with RFC 5031. Ciao Hannes Henning Schulzrinne wrote: > It has two disadvantages: > > - It requires roughly twice the number of queries to the LoST > infrastructure since every end system will need both the non-test and > test services. > > - It requires a non-backwards-compatible update of RFC 5031. > > I'm less concerned about the second issue, but before doing this, I'd > rather know that this is the right outcome. > > Henning > > On Mar 31, 2008, at 1:46 PM, Hannes Tschofenig wrote: > >> What was wrong with the URN parameter idea? >> It was in former versions of draft-ietf-ecrit-phonebcp? >> >> >> Henning Schulzrinne wrote: >>> I'm happy to draft the LoST extension if there's no objection. I >>> think we now have explored the option space reasonably well, so it's >>> time to move ahead, as you say. >>> >>> On Mar 31, 2008, at 12:17 PM, Brian Rosen wrote: >>> >>>> Henning >>>> >>>> Please recall that the first idea was a urn parameter. Then it was >>>> the >>>> .test idea. Now we're looking at another return value. >>>> >>>> I don't really care, but I want to pick a mechanism and finish the >>>> discussion. >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 11:07:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E025128C1B7; Mon, 31 Mar 2008 11:07:25 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475E728C1B7 for ; Mon, 31 Mar 2008 11:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKHyjIjyESeQ for ; Mon, 31 Mar 2008 11:07:24 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 341683A6D6F for ; Mon, 31 Mar 2008 11:07:24 -0700 (PDT) Received: from dhcp31.cs.columbia.edu (dhcp31.cs.columbia.edu [128.59.19.231]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m2VI7DJT026396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 31 Mar 2008 14:07:13 -0400 (EDT) Message-Id: <23B6A633-5A88-4B48-BFC4-35B88C85A867@cs.columbia.edu> From: Henning Schulzrinne To: Hannes Tschofenig In-Reply-To: <47F12698.5010307@gmx.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 31 Mar 2008 14:07:13 -0400 References: <47EFF059.70601@gmx.net> <008f01c892a3$c781db80$9744f444@cis.neustar.com> <89678C47-7277-4EA4-9F4A-B5F7C8C831A3@cs.columbia.edu> <014101c8934a$bf63c970$6901a8c0@cis.neustar.com> <771CF8C9-6595-42F3-AA77-EA69046AC906@cs.columbia.edu> <47F12375.8000700@gmx.net> <03A42269-889E-4A75-B8D4-98127959C16E@cs.columbia.edu> <47F12698.5010307@gmx.net> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Testing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I don't see how this can work unless the service URL is the same for both test and operational systems. I thought our requirement was that a PSAP could designate another system as a test system (e.g., a statewide center), so that any tests would not interfere with "real" calls. Thus, we want to be able to convey test URLs in LoST. Once you do that, it's presumably trivial to have two SIP URLs: sip:police+test@psap.gov sip:police@psap.gov even if you want to direct both calls to the same proxy. This isn't a major concern if we assume that all calls, test and real, go to a statewide ESRP. I'm not sure that we want to *require* that. Henning On Mar 31, 2008, at 1:59 PM, Hannes Tschofenig wrote: > Hi Henning, > > I thought that the "test" parameter would be used in a different > way, namely: > > * A LoST client issues a query for urn:service.sos.fire > * A LoST server provides an answer. > * The client creates an INVITE with the Service URN parameter and > appends the "test" parameter > In this example: urn:service.sos.fire;test > > I understand the problem with RFC 5031. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 11:12:46 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3E9C28C134; Mon, 31 Mar 2008 11:12:46 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2052E3A6856 for ; Mon, 31 Mar 2008 11:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=0.826, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mG1+GKM1JxWw for ; Mon, 31 Mar 2008 11:12:44 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 359303A67F7 for ; Mon, 31 Mar 2008 11:12:44 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JgOUm-0000Tx-Az; Mon, 31 Mar 2008 13:12:36 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Hannes Tschofenig'" References: <47EFF059.70601@gmx.net> <008f01c892a3$c781db80$9744f444@cis.neustar.com> <89678C47-7277-4EA4-9F4A-B5F7C8C831A3@cs.columbia.edu> <014101c8934a$bf63c970$6901a8c0@cis.neustar.com> <771CF8C9-6595-42F3-AA77-EA69046AC906@cs.columbia.edu> <47F12375.8000700@gmx.net> <03A42269-889E-4A75-B8D4-98127959C16E@cs.columbia.edu> <47F12698.5010307@gmx.net> <23B6A633-5A88-4B48-BFC4-35B88C85A867@cs.columbia.edu> Date: Mon, 31 Mar 2008 14:12:38 -0400 Message-ID: <016e01c8935a$cf3efad0$6901a8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciTWguK788ulLG6SriQhNzb1/LMCAAAFSmg In-Reply-To: <23B6A633-5A88-4B48-BFC4-35B88C85A867@cs.columbia.edu> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Testing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org A proxy is allowed to route on any information it has, including what is in a parameter. For best results, you want the route to be as close as possible to the same, so I think that the notion that you have to get to a proxy in the domain of the PSAP URI before the route can diverge is no problem. I think that having a bunch of mechanism just so the domain of the test URL and the real URL can be different is not worth the effort. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, March 31, 2008 2:07 PM To: Hannes Tschofenig Cc: Brian Rosen; ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Testing I don't see how this can work unless the service URL is the same for both test and operational systems. I thought our requirement was that a PSAP could designate another system as a test system (e.g., a statewide center), so that any tests would not interfere with "real" calls. Thus, we want to be able to convey test URLs in LoST. Once you do that, it's presumably trivial to have two SIP URLs: sip:police+test@psap.gov sip:police@psap.gov even if you want to direct both calls to the same proxy. This isn't a major concern if we assume that all calls, test and real, go to a statewide ESRP. I'm not sure that we want to *require* that. Henning On Mar 31, 2008, at 1:59 PM, Hannes Tschofenig wrote: > Hi Henning, > > I thought that the "test" parameter would be used in a different > way, namely: > > * A LoST client issues a query for urn:service.sos.fire > * A LoST server provides an answer. > * The client creates an INVITE with the Service URN parameter and > appends the "test" parameter > In this example: urn:service.sos.fire;test > > I understand the problem with RFC 5031. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 11:14:58 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AAEA28C3B1; Mon, 31 Mar 2008 11:14:58 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C39928C3B1 for ; Mon, 31 Mar 2008 11:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=0.814, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8vtlQiDbhbx for ; Mon, 31 Mar 2008 11:14:56 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id CCCB128C134 for ; Mon, 31 Mar 2008 11:14:55 -0700 (PDT) Received: (qmail invoked by alias); 31 Mar 2008 18:14:52 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp048) with SMTP; 31 Mar 2008 20:14:52 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18fT7siq30fL/8WmDn/MKSw5xifgf406dGaL448OI YG2QP8Hn5mK77t Message-ID: <47F12A17.6070109@gmx.net> Date: Mon, 31 Mar 2008 21:14:47 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Henning Schulzrinne References: <47EFF059.70601@gmx.net> <008f01c892a3$c781db80$9744f444@cis.neustar.com> <89678C47-7277-4EA4-9F4A-B5F7C8C831A3@cs.columbia.edu> <014101c8934a$bf63c970$6901a8c0@cis.neustar.com> <771CF8C9-6595-42F3-AA77-EA69046AC906@cs.columbia.edu> <47F12375.8000700@gmx.net> <03A42269-889E-4A75-B8D4-98127959C16E@cs.columbia.edu> <47F12698.5010307@gmx.net> <23B6A633-5A88-4B48-BFC4-35B88C85A867@cs.columbia.edu> In-Reply-To: <23B6A633-5A88-4B48-BFC4-35B88C85A867@cs.columbia.edu> X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Testing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Henning, Henning Schulzrinne wrote: > I don't see how this can work unless the service URL is the same for > both test and operational systems. I thought our requirement was that > a PSAP could designate another system as a test system (e.g., a > statewide center), so that any tests would not interfere with "real" > calls. I thought that this was the idea to have test calls treated in the same way as real emergency calls. > Thus, we want to be able to convey test URLs in LoST. Once you do > that, it's presumably trivial to have two SIP URLs: > > sip:police+test@psap.gov > sip:police@psap.gov > > even if you want to direct both calls to the same proxy. This isn't a > major concern if we assume that all calls, test and real, go to a > statewide ESRP. I'm not sure that we want to *require* that. Maybe we should ask PSAP operators what type of depoloyment mode they want. Another way forward would be to go ahead with the solution you proposed, i.e., introducing flexibility. When a PSAP operator wants to use the "real" system also for test calls then they would return the same URIs twice, one for the test and another one for the "real" emergency call. If they don't want this behavior then they would return different URIs. Ciao Hannes > > Henning > > On Mar 31, 2008, at 1:59 PM, Hannes Tschofenig wrote: > >> Hi Henning, >> >> I thought that the "test" parameter would be used in a different way, >> namely: >> >> * A LoST client issues a query for urn:service.sos.fire >> * A LoST server provides an answer. >> * The client creates an INVITE with the Service URN parameter and >> appends the "test" parameter >> In this example: urn:service.sos.fire;test >> >> I understand the problem with RFC 5031. >> > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 11:51:35 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B92AB3A6B49; Mon, 31 Mar 2008 11:51:35 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4FE53A6B49 for ; Mon, 31 Mar 2008 11:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxuBZxRcfgaq for ; Mon, 31 Mar 2008 11:51:32 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id CD8283A6A0D for ; Mon, 31 Mar 2008 11:51:31 -0700 (PDT) Received: (qmail invoked by alias); 31 Mar 2008 18:51:28 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp045) with SMTP; 31 Mar 2008 20:51:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+2nUY0Tz62ZSOzfB49ucwRaXxfMhzwu3tBMfbEQL faFcPOV1Pl/xsR Message-ID: <47F132AB.3010303@gmx.net> Date: Mon, 31 Mar 2008 21:51:23 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org X-Y-GMX-Trusted: 0 Subject: [Ecrit] [Fwd: RE: draft-ietf-ecrit-lost-09.txt has been submitted.] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org FYI -------- Original Message -------- Subject: RE: draft-ietf-ecrit-lost-09.txt has been submitted. Date: Mon, 31 Mar 2008 20:34:10 +0300 From: To: , CC: , , References: Ted, I'm not fully satisfied with -09 yet. The existing DDDS specs (in particular, the security considerations text in RFC 3958) are quite clear that server identity check is usually needed, but the identity that has to be checked is the input to NAPTR processing, not the output. Simply saying "The use of server identity checks is also RECOMMENDED, as described in [4]" does not quite capture this important distinction, and could even lead to interop problems if the implementor assumes that this intended to follow RFC 3958. (Also, "RECOMMENDED" would benefit from couple of sentences describing when they're not needed.) It seems that in the particular emergency deployment you're most concerned with, solving this particular problem isn't actually feasible (unless you have DNSSEC). However, hardcoding LoST to use the NAPTR processing output in the identity check also means that other deployments of LoST -- where implementing the checks as outlined in RFC 3958 (with e.g. certs containing the NAPTR input) would be totally feasible -- won't be secure without DNSSEC. Suggested rewriting on this section that would be more acceptable to me (not very polished text yet, feel free to suggest improvements): To avoid an attacker modifying the query or its result, TLS MUST be implemented and SHOULD be used. Use is RECOMMENDED both for clients' queries to servers and for queries among servers; this latter recommendation is to help avoid LoST cache poisoning attacks by replacing answers given to caching LoST servers. The use of server identity checks with TLS, as described in Section 3.1 of [4] is also RECOMMENDED. Omitting the server identity check allows an attacker to masquerade as a LoST server, so this approach should be used only when getting any answer, even from a potentially malicious LoST server, is preferred over closing the connection (and thus not getting any answer at all). The host name compared against the server certificate is the host name in the URI, not the DNS name used as input to NAPTR resolution. Note that the security considerations in [RFC3958] recommend comparing the input of NAPTR resolution to the certificate, not the output (host name in the URI). This approach was not chosen, because in emergency service use cases, it is likely that deployments will see a large number of inputs (such as company and other organization names) to the NAPTR processing resolving to a single server, typically run by a local emergency services authority. In this case, checking the input to the NAPTR resolution against the certificates provided by the LoST server would be impractical, as the list of organizations using it would be large, subject to rapid change, and unknown to the LoST server operator. This use of server identity check does leave open the possibility of DNS based attacks, as the NAPTR records may be altered by an attacker. The attacks include, for example, interception of DNS packets between the client and the recursive name server, DNS cache poisoning, and intentional modifications by the recursive name server; see [RFC3833] for more comprehensive discussion. DNSSEC [20] can be used to protect against these threats. While DNSSEC is incompletely deployed, users should be aware of the risk, particularly when they are requesting NAPTR records in environments where the local recursive name server, or the network between the client and the local recursive name server, is not considered trustworthy. LoST deployments which are unable to use DNSSEC and unwilling to trust DNS resolution without DNSSEC, cannot use the NATPR based discovery of LoST servers as-is. When suitable configuration mechanisms are available, one possibility is to configure the LoST server URIs (instead of the domain name to be used for NAPTR resolution) directly. Future specifications for applying LoST in non-emergency services may also specify additional discovery mechanisms and name matching semantics. One alternative which I suggested in a private email earlier would be to provide a "LoST discovery security mode" configuration option. This could have e.g. three different values: "loose" would be the name matching described above; "strict" would compare the NAPTR input with the certificate (this is what RFC3958 recommends, as it doesn't rely on DNSSEC), and "dnssec" would be the current mechanism + a check that DNSSEC was actually used. This would allow the emergency service scenario to work as-is, but would give flexibility for future, non-emergency deployments. I haven't received any comments about that proposal yet. Best regards, Pasi > -----Original Message----- > From: iesg-bounces@iesg.org [mailto:iesg-bounces@iesg.org] On > Behalf Of ext Ted Hardie > Sent: 28 March, 2008 22:12 > To: iesg@ietf.org > Cc: Andrew Newton; hannes.tschofenig@gmx.net; Henning Schulzrinne > Subject: draft-ietf-ecrit-lost-09.txt has been submitted. > > The new version of this draft is now available at: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-09.txt > > You may have seen an announcement for 08 earlier in the day. > After it was submitted, Hannes realized that the URI pointer for > reference 22 was still incorrect, and the later update corrects this > as well. The authors believe that this draft resolves all of > the outstanding > DISCUSSes. > > The resolution of one issue raised by Cullen may be non-obvious. In > his revised DISCUSS, Cullen notes: > > >The document contains text such as > > The < Polygon > element is described in Section 5.2.2 > of [13]. The > > restriction to 16 points for a polygon contained in > Section 7.2.2 > > of [12] is not applicable to this document. > >and text like > > When clients place a < Polygon >, < Circle >, < Ellipse > > or < ArcBand > > > element within the < location > element then it indicates that the > > query is about any point contained in the given area; it is left to > > the server to select an appropriate matching algorithm, > such as using > > computing the centroid. > >I can not see how this draft can be implemented without > reading Ref 13 which defined the shapes such as Polygon. > > These shapes are defined with reference to the base OGC GML specs and > are called out specifically in "GML 3.1.1 PIDF-LO Shape Application > Schema for use by the Internet Engineering Task Force (IETF)" > which is normatively > referenced (as reference 12) in this paragraph. The authors > believe that > the additional information found in [13] is valuable context > but can be treated as informative > given the information in [12] and the note in-line that the > 16 point restriction > does not apply. > > The authors suggest that they work with the RFC editor on > final submission to work > out how to handle a dual reference (to both [12] and [13]) > when one is normative > and one informative or alternatively, if the progress of [13] > is sufficient, to both of > them as normative. The authors do not believe a reference > hold for [13] would > be appropriate in this case, given the relationship to [12]. > > regards, > Ted Hardie > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 12:57:46 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0FC3A6A9F; Mon, 31 Mar 2008 12:57:46 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71A173A6AD4 for ; Mon, 31 Mar 2008 12:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.013 X-Spam-Level: X-Spam-Status: No, score=-102.013 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ehf8ay4YPZqY for ; Mon, 31 Mar 2008 12:57:44 -0700 (PDT) Received: from aismt06p.bellsouth.com (aismt06p.bellsouth.com [139.76.165.211]) by core3.amsl.com (Postfix) with ESMTP id 1FEB63A6A9F for ; Mon, 31 Mar 2008 12:57:44 -0700 (PDT) Received: from ([139.76.131.87]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.44039136; Mon, 31 Mar 2008 15:57:00 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 31 Mar 2008 15:57:00 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 31 Mar 2008 15:56:59 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 31 Mar 2008 15:56:58 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA083C6644@crexc41p> In-Reply-To: <008c01c892a3$5f0ea920$9744f444@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: LoST Discovery thread-index: AciSoBhKQdi0ZzG0Tg2fkAW/umMl6AAAzDvQACLuxvA= References: <47EFF036.2000508@gmx.net> <008c01c892a3$5f0ea920$9744f444@cis.neustar.com> From: "Stark, Barbara" To: "Brian Rosen" , "Hannes Tschofenig" , X-OriginalArrivalTime: 31 Mar 2008 19:56:59.0939 (UTC) FILETIME=[61A93F30:01C89369] Subject: Re: [Ecrit] Phone BCP: LoST Discovery X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yes, I did. Here is a quote from Section 4 (LoST Servers and Their Resolution) of the current lost-09 text: "Clients learn the LoST server's host name by means beyond the scope of this specification, such as SIP configuration and DHCP." If that's the case, then I want all clients to support both configuration and DHCP methods. There are pros and cons to each. The domain name that clients get behind routers are generally not reliable for use in LoST discovery. They are "home" domains. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Sunday, March 30, 2008 4:20 PM To: 'Hannes Tschofenig'; ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: LoST Discovery I think Barbara asked for it to be a MUST. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 3:56 PM To: ecrit@ietf.org Subject: [Ecrit] Phone BCP: LoST Discovery " ED-48 Endpoints MUST support LIS discovery as described in [I-D.thomson-geopriv-lis-discovery], and the LoST discovery as described in [I-D.ietf-ecrit-dhc-lost-discovery]. " I think LoST discovery based on DHCP is only a SHOULD; not a MUST. It is good to have it but not absolutely necessary. The DNS U-NAPTR discovery described in LoST itself is mandatory. " ED-49 The device MUST have a configurable default LoST server parameter. If the device is provided by or managed by service provider, it is expected that the service provider will configure this option. " I believe that this default LoST server is not absolutely necessary. The client may also use the U-NAPTR discovery procedure based on the domain name it has. _______________________________________________ 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 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 13:29:50 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D19928C3F6; Mon, 31 Mar 2008 13:29:50 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA07728C3D8 for ; Mon, 31 Mar 2008 13:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owFpK-hYN9s6 for ; Mon, 31 Mar 2008 13:29:45 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 8A55D3A6AD4 for ; Mon, 31 Mar 2008 13:29:42 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_03_31_15_42_51 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 31 Mar 2008 15:42:50 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Mar 2008 15:29:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 31 Mar 2008 15:28:53 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: Multiple Location Thread-Index: AciSoBSicmd+wT1mQom8/iePcnSz0wABYVlrACJtvEAAD6FFRA== References: <47EFF025.9000705@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA080ECEF5@crexc41p> From: "Winterbottom, James" To: "Stark, Barbara" , "Hannes Tschofenig" , X-OriginalArrivalTime: 31 Mar 2008 20:29:40.0044 (UTC) FILETIME=[F1F988C0:01C8936D] Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Nope. This is from PIDF-LO Profile " Rule #9: Where multiple PIDF documents can be sent or received together, say in a multi-part MIME body, and current location information is required by the recipient, then document selection SHOULD be based on document order, with the first document considered first." Cheers James -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Mon 3/31/2008 8:05 AM To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org Subject: RE: [Ecrit] Phone BCP: Multiple Location It's my understanding that PIDF-LO only describes multiple location precedence within a single message. It doesn't describe how to prioritize multiple locations received from various sources, received in multiple messages (or statically configured) at various times. I did include that sort of logic in my latest DSLF draft. If there is a desire to have some of this in phonebcp, I'm fine with that. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Sunday, March 30, 2008 4:36 PM To: Hannes Tschofenig; ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Multiple Location PIDF-LO profile describes how to choose the correct location for exactly this purpose. That is the application form which the original requirements were drawn. -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig Sent: Sun 3/30/2008 2:55 PM To: ecrit@ietf.org Subject: [Ecrit] Phone BCP: Multiple Location " ED-39 If a UA has more than one location available to it, it MUST choose one location to route the call towards the PSAP. SP-16 If a proxy inserts location on behalf of an endpoint, and it has multiple locations available for the endpoint it MUST choose one location to use to route the call towards the PSAP. " I could imagine that someone might ask how to make a decision. So, how does the decision making look like? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 14:17:36 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F20F3A6959; Mon, 31 Mar 2008 14:17:36 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263053A6909 for ; Mon, 31 Mar 2008 14:17:35 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8uKwR2RkVPI for ; Mon, 31 Mar 2008 14:17:34 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id 1FA8E3A6959 for ; Mon, 31 Mar 2008 14:17:33 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Mon, 31 Mar 2008 14:17:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 31 Mar 2008 14:17:31 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575097B99E0@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <00e701c8932f$0ee90f80$6901a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: Default Location Thread-Index: AciSoBsXzeiyM5C1TbiPfHV2vt2oAQAA98TkACKpIhAAEOXLgA== References: <47EFF030.5030802@gmx.net> <00e701c8932f$0ee90f80$6901a8c0@cis.neustar.com> From: "Roger Marshall" To: "Brian Rosen" , "Winterbottom, James" , "Hannes Tschofenig" , Subject: Re: [Ecrit] Phone BCP: Default Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org ...Brian Rosen wrote on Monday, March 31, 2008 5:59 AM, > It was determined by some element who failed to get it by > some other method, I'm not sure I get it. Are you saying "default", in the sense of "manually provisioned" only? Locations in their most basic form are either 1. (e.g., wiremap), 2. (e.g., agps), or 3. (e.g., geocoded) Configuration mechanisms have been talked about, such as using a DHCP server for location acquisition. I just want to make sure folks don't think that the answer as to what to put in the PIDF-LO's method element would be something like . If so, then any info relating to the 3 methods above is gone. If not, then we need another value in PIDF-LO, something like: dhcp Mostly though, the method value doesn't tell me anything about the how the location should be characterized. -roger. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Monday, March 31, 2008 5:59 AM > To: 'Winterbottom, James'; 'Hannes Tschofenig'; ecrit@ietf.org > Subject: Re: [Ecrit] Phone BCP: Default Location > > No, it represents the best available location of the user. > > It was determined by some element who failed to get it by > some other method, > and is using a default value which was predefined for that > purpose. The > best available location is the default value, and the method > used to determine it was the 'default' method. > > I think it's appropriate as defined. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Winterbottom, James > Sent: Sunday, March 30, 2008 4:34 PM > To: Hannes Tschofenig; ecrit@ietf.org > Subject: Re: [Ecrit] Phone BCP: Default Location > > Actually this is a misuse of the method token. > The method token says how location was determined for > inclusion in the PIDF-LO. > The intent I read from this requirement is that the method is > attempting to say that the location doesn't represent where > the end point is at all, but is what they have registered as > a default location. > > I think you need a new element in the PIDF-LO to represent this. > Something like: > yes > > or > > default > > Then it could have a value of "current" or "recent" or other > kind of subjective things too. > > Cheers > James > > > > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > Sent: Sun 3/30/2008 2:55 PM > To: ecrit@ietf.org > Subject: [Ecrit] Phone BCP: Default Location > > " > AN-23/SP-22 Default locations MUST be marked with > method=Default and > the proxy MUST be identfied in provided-by element of the PIDF-LO. > " > > Someone should register the token "default". To my knowledge > it is not registered. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > -------------------------------------------------------------- > -------------- > -------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > -------------- > -------------------- > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > 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. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 14:35:02 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9214C28C228; Mon, 31 Mar 2008 14:35:02 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B53228C228 for ; Mon, 31 Mar 2008 14:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.136 X-Spam-Level: X-Spam-Status: No, score=0.136 tagged_above=-999 required=5 tests=[AWL=-0.765, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbxBPU10Yte3 for ; Mon, 31 Mar 2008 14:34:55 -0700 (PDT) Received: from andrew.com (unknown [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id F246D28C203 for ; Mon, 31 Mar 2008 14:34:54 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_03_31_16_47_43 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 31 Mar 2008 16:47:43 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Mar 2008 16:34:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 31 Mar 2008 16:34:30 -0500 Message-ID: In-Reply-To: <8C837214C95C864C9F34F3635C2A6575097B99E0@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: Default Location Thread-Index: AciSoBsXzeiyM5C1TbiPfHV2vt2oAQAA98TkACKpIhAAEOXLgAABJabQ References: <47EFF030.5030802@gmx.net> <00e701c8932f$0ee90f80$6901a8c0@cis.neustar.com> <8C837214C95C864C9F34F3635C2A6575097B99E0@SEA-EXCHVS-2.telecomsys.com> From: "Winterbottom, James" To: "Roger Marshall" , "Brian Rosen" , "Hannes Tschofenig" , X-OriginalArrivalTime: 31 Mar 2008 21:34:32.0615 (UTC) FILETIME=[0220BB70:01C89377] Subject: Re: [Ecrit] Phone BCP: Default Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Roger, I think I agree with you, which is why I proposed what I did. I certainly don't believe that the tag should have a value of default as is being suggested by the current text. Cheers James > -----Original Message----- > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > Sent: Tuesday, 1 April 2008 8:18 AM > To: Brian Rosen; Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] Phone BCP: Default Location > > ...Brian Rosen wrote on Monday, March 31, 2008 5:59 AM, > > > It was determined by some element who failed to get it by > > some other method, > > I'm not sure I get it. Are you saying "default", in the sense of > "manually provisioned" only? > > Locations in their most basic form are either > 1. (e.g., wiremap), > 2. (e.g., agps), or > 3. (e.g., geocoded) > > Configuration mechanisms have been talked about, such as using a DHCP > server for location acquisition. I just want to make sure folks don't > think that the answer as to what to put in the PIDF-LO's method element > would be something like . If so, then any info relating to the > 3 methods above is gone. If not, then we need another value in PIDF-LO, > something like: > > dhcp > > Mostly though, the method value doesn't tell me anything about > the how the location should be characterized. > > -roger. > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of Brian Rosen > > Sent: Monday, March 31, 2008 5:59 AM > > To: 'Winterbottom, James'; 'Hannes Tschofenig'; ecrit@ietf.org > > Subject: Re: [Ecrit] Phone BCP: Default Location > > > > No, it represents the best available location of the user. > > > > It was determined by some element who failed to get it by > > some other method, > > and is using a default value which was predefined for that > > purpose. The > > best available location is the default value, and the method > > used to determine it was the 'default' method. > > > > I think it's appropriate as defined. > > > > Brian > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of Winterbottom, James > > Sent: Sunday, March 30, 2008 4:34 PM > > To: Hannes Tschofenig; ecrit@ietf.org > > Subject: Re: [Ecrit] Phone BCP: Default Location > > > > Actually this is a misuse of the method token. > > The method token says how location was determined for > > inclusion in the PIDF-LO. > > The intent I read from this requirement is that the method is > > attempting to say that the location doesn't represent where > > the end point is at all, but is what they have registered as > > a default location. > > > > I think you need a new element in the PIDF-LO to represent this. > > Something like: > > yes > > > > or > > > > default > > > > Then it could have a value of "current" or "recent" or other > > kind of subjective things too. > > > > Cheers > > James > > > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > > Sent: Sun 3/30/2008 2:55 PM > > To: ecrit@ietf.org > > Subject: [Ecrit] Phone BCP: Default Location > > > > " > > AN-23/SP-22 Default locations MUST be marked with > > method=Default and > > the proxy MUST be identfied in provided-by element of the PIDF-LO. > > " > > > > Someone should register the token "default". To my knowledge > > it is not registered. > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > -------------------------------------------------------------- > > -------------- > > -------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > -------------- > > -------------------- > > [mf2] > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > 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. > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 15:13:59 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C67993A68B0; Mon, 31 Mar 2008 15:13:59 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A6C63A6834 for ; Mon, 31 Mar 2008 15:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[AWL=0.819, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyS2p9txZ+Zf for ; Mon, 31 Mar 2008 15:13:57 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 6629E28C2E7 for ; Mon, 31 Mar 2008 15:13:57 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JgSGB-0007u5-B2; Mon, 31 Mar 2008 17:13:48 -0500 From: "Brian Rosen" To: "'Roger Marshall'" , "'Winterbottom, James'" , "'Hannes Tschofenig'" , References: <47EFF030.5030802@gmx.net> <00e701c8932f$0ee90f80$6901a8c0@cis.neustar.com> <8C837214C95C864C9F34F3635C2A6575097B99E0@SEA-EXCHVS-2.telecomsys.com> Date: Mon, 31 Mar 2008 18:13:51 -0400 Message-ID: <019001c8937c$81e73460$6901a8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciSoBsXzeiyM5C1TbiPfHV2vt2oAQAA98TkACKpIhAAEOXLgAACPnMA In-Reply-To: <8C837214C95C864C9F34F3635C2A6575097B99E0@SEA-EXCHVS-2.telecomsys.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Phone BCP: Default Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Well, maybe. I don't want to limit default to manually provisioned, but it's probably the most common way you get it. The point is that every element that handles an emergency call has to be prepared to supply a default value. The closer the element is to the endpoint, the more likely it is to have a good default value. In your list, in most cases, it's . DHCP is an LCP, not a method. In most cases, a civic location is a wiremap and a geo is measured by GPS or triangulated by APs. It isn't always so, but that's probably good enough. Default is a method. You got it some basic way (usually configured). We used an example of a CMTS area for a cable system. If the LIS failed to determine a location, or a proxy server needed to add location, using some location in the CMTS service area may be a decent default location. The "some location" is configured. When you have a default location, you don't have some other method. If you did, you would use it, and you wouldn't need a default. Brian -----Original Message----- From: Roger Marshall [mailto:RMarshall@telecomsys.com] Sent: Monday, March 31, 2008 5:18 PM To: Brian Rosen; Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org Subject: RE: [Ecrit] Phone BCP: Default Location ...Brian Rosen wrote on Monday, March 31, 2008 5:59 AM, > It was determined by some element who failed to get it by > some other method, I'm not sure I get it. Are you saying "default", in the sense of "manually provisioned" only? Locations in their most basic form are either 1. (e.g., wiremap), 2. (e.g., agps), or 3. (e.g., geocoded) Configuration mechanisms have been talked about, such as using a DHCP server for location acquisition. I just want to make sure folks don't think that the answer as to what to put in the PIDF-LO's method element would be something like . If so, then any info relating to the 3 methods above is gone. If not, then we need another value in PIDF-LO, something like: dhcp Mostly though, the method value doesn't tell me anything about the how the location should be characterized. -roger. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Monday, March 31, 2008 5:59 AM > To: 'Winterbottom, James'; 'Hannes Tschofenig'; ecrit@ietf.org > Subject: Re: [Ecrit] Phone BCP: Default Location > > No, it represents the best available location of the user. > > It was determined by some element who failed to get it by > some other method, > and is using a default value which was predefined for that > purpose. The > best available location is the default value, and the method > used to determine it was the 'default' method. > > I think it's appropriate as defined. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Winterbottom, James > Sent: Sunday, March 30, 2008 4:34 PM > To: Hannes Tschofenig; ecrit@ietf.org > Subject: Re: [Ecrit] Phone BCP: Default Location > > Actually this is a misuse of the method token. > The method token says how location was determined for > inclusion in the PIDF-LO. > The intent I read from this requirement is that the method is > attempting to say that the location doesn't represent where > the end point is at all, but is what they have registered as > a default location. > > I think you need a new element in the PIDF-LO to represent this. > Something like: > yes > > or > > default > > Then it could have a value of "current" or "recent" or other > kind of subjective things too. > > Cheers > James > > > > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > Sent: Sun 3/30/2008 2:55 PM > To: ecrit@ietf.org > Subject: [Ecrit] Phone BCP: Default Location > > " > AN-23/SP-22 Default locations MUST be marked with > method=Default and > the proxy MUST be identfied in provided-by element of the PIDF-LO. > " > > Someone should register the token "default". To my knowledge > it is not registered. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > -------------------------------------------------------------- > -------------- > -------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > -------------- > -------------------- > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > 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. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 17:23:04 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C38963A6CEE; Mon, 31 Mar 2008 17:23:04 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D56393A6CB5 for ; Mon, 31 Mar 2008 17:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.857 X-Spam-Level: X-Spam-Status: No, score=-0.857 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDt3BKSXN8ZZ for ; Mon, 31 Mar 2008 17:23:02 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id E213F3A6CEE for ; Mon, 31 Mar 2008 17:23:01 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_03_31_19_36_10 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 31 Mar 2008 19:36:10 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Mar 2008 19:22:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 31 Mar 2008 19:22:57 -0500 Message-ID: In-Reply-To: <019001c8937c$81e73460$6901a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: Default Location Thread-Index: AciSoBsXzeiyM5C1TbiPfHV2vt2oAQAA98TkACKpIhAAEOXLgAACPnMAAASTsQA= References: <47EFF030.5030802@gmx.net> <00e701c8932f$0ee90f80$6901a8c0@cis.neustar.com> <8C837214C95C864C9F34F3635C2A6575097B99E0@SEA-EXCHVS-2.telecomsys.com> <019001c8937c$81e73460$6901a8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Roger Marshall" , "Hannes Tschofenig" , X-OriginalArrivalTime: 01 Apr 2008 00:22:59.0403 (UTC) FILETIME=[8A3E31B0:01C8938E] Subject: Re: [Ecrit] Phone BCP: Default Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Let's agree to disagree on this. I see method as a means of describing how the location of the Target was determined. What is being described by a value of default is that the location bears no perceivable relationship to the Target, but is being provided because we want the call to be answered. This is a measure of the quality of the location information, and this requires a separate indicator. If everybody disagrees me on this then I will let it drop, but I think it is a slippery path to follow. Cheers James > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, 1 April 2008 9:14 AM > To: 'Roger Marshall'; Winterbottom, James; 'Hannes Tschofenig'; > ecrit@ietf.org > Subject: RE: [Ecrit] Phone BCP: Default Location > > Well, maybe. I don't want to limit default to manually provisioned, but > it's probably the most common way you get it. > > The point is that every element that handles an emergency call has to be > prepared to supply a default value. The closer the element is to the > endpoint, the more likely it is to have a good default value. In your > list, > in most cases, it's . > > DHCP is an LCP, not a method. In most cases, a civic location is a > wiremap > and a geo is measured by GPS or triangulated by APs. It isn't always so, > but that's probably good enough. > > Default is a method. You got it some basic way (usually configured). We > used an example of a CMTS area for a cable system. If the LIS failed to > determine a location, or a proxy server needed to add location, using some > location in the CMTS service area may be a decent default location. The > "some location" is configured. > > When you have a default location, you don't have some other method. If > you > did, you would use it, and you wouldn't need a default. > > Brian > > -----Original Message----- > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > Sent: Monday, March 31, 2008 5:18 PM > To: Brian Rosen; Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] Phone BCP: Default Location > > ...Brian Rosen wrote on Monday, March 31, 2008 5:59 AM, > > > It was determined by some element who failed to get it by > > some other method, > > I'm not sure I get it. Are you saying "default", in the sense of > "manually provisioned" only? > > Locations in their most basic form are either > 1. (e.g., wiremap), > 2. (e.g., agps), or > 3. (e.g., geocoded) > > Configuration mechanisms have been talked about, such as using a DHCP > server for location acquisition. I just want to make sure folks don't > think that the answer as to what to put in the PIDF-LO's method element > would be something like . If so, then any info relating to the > 3 methods above is gone. If not, then we need another value in PIDF-LO, > something like: > > dhcp > > Mostly though, the method value doesn't tell me anything about > the how the location should be characterized. > > -roger. > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of Brian Rosen > > Sent: Monday, March 31, 2008 5:59 AM > > To: 'Winterbottom, James'; 'Hannes Tschofenig'; ecrit@ietf.org > > Subject: Re: [Ecrit] Phone BCP: Default Location > > > > No, it represents the best available location of the user. > > > > It was determined by some element who failed to get it by > > some other method, > > and is using a default value which was predefined for that > > purpose. The > > best available location is the default value, and the method > > used to determine it was the 'default' method. > > > > I think it's appropriate as defined. > > > > Brian > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of Winterbottom, James > > Sent: Sunday, March 30, 2008 4:34 PM > > To: Hannes Tschofenig; ecrit@ietf.org > > Subject: Re: [Ecrit] Phone BCP: Default Location > > > > Actually this is a misuse of the method token. > > The method token says how location was determined for > > inclusion in the PIDF-LO. > > The intent I read from this requirement is that the method is > > attempting to say that the location doesn't represent where > > the end point is at all, but is what they have registered as > > a default location. > > > > I think you need a new element in the PIDF-LO to represent this. > > Something like: > > yes > > > > or > > > > default > > > > Then it could have a value of "current" or "recent" or other > > kind of subjective things too. > > > > Cheers > > James > > > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > > Sent: Sun 3/30/2008 2:55 PM > > To: ecrit@ietf.org > > Subject: [Ecrit] Phone BCP: Default Location > > > > " > > AN-23/SP-22 Default locations MUST be marked with > > method=Default and > > the proxy MUST be identfied in provided-by element of the PIDF-LO. > > " > > > > Someone should register the token "default". To my knowledge > > it is not registered. > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > -------------------------------------------------------------- > > -------------- > > -------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > -------------- > > -------------------- > > [mf2] > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > 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. > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 19:30:18 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7BBB3A6B2C; Mon, 31 Mar 2008 19:30:18 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3261A3A699B for ; Mon, 31 Mar 2008 19:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.066 X-Spam-Level: X-Spam-Status: No, score=-102.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHaTHSoXB16S for ; Mon, 31 Mar 2008 19:30:16 -0700 (PDT) Received: from aismt06p.bellsouth.com (aismt06p.bellsouth.com [139.76.165.211]) by core3.amsl.com (Postfix) with ESMTP id 0259E3A683F for ; Mon, 31 Mar 2008 19:30:15 -0700 (PDT) Received: from ([139.76.131.83]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.44059146; Mon, 31 Mar 2008 22:29:50 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 31 Mar 2008 22:29:50 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 31 Mar 2008 22:29:49 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 31 Mar 2008 22:29:48 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA083C6764@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: Multiple Location thread-index: AciSoBSicmd+wT1mQom8/iePcnSz0wABYVlrACJtvEAAD6FFRAAMWCaw References: <47EFF025.9000705@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA080ECEF5@crexc41p> From: "Stark, Barbara" To: "Winterbottom, James" , "Hannes Tschofenig" , X-OriginalArrivalTime: 01 Apr 2008 02:29:49.0760 (UTC) FILETIME=[425E8400:01C893A0] Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Key words are "Where multiple PIDF documents can be sent or received together". When a device has a configured location, a location from LLDP-MED, one from DHCP, and one or two (routing and dispatch) from HELD, I think that the quoted language has no relevance on the order in which these are then included in an "sos" message. These different locations were not received together. LLDP-MED and DHCP locations are not received as PIDF documents. This language does apply to the PSAP when it receives all of these locations. They arrive together, and all in PIDF format. Barbara -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Monday, March 31, 2008 4:29 PM To: Stark, Barbara; Hannes Tschofenig; ecrit@ietf.org Subject: RE: [Ecrit] Phone BCP: Multiple Location Nope. This is from PIDF-LO Profile " Rule #9: Where multiple PIDF documents can be sent or received together, say in a multi-part MIME body, and current location information is required by the recipient, then document selection SHOULD be based on document order, with the first document considered first." Cheers James -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Mon 3/31/2008 8:05 AM To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org Subject: RE: [Ecrit] Phone BCP: Multiple Location It's my understanding that PIDF-LO only describes multiple location precedence within a single message. It doesn't describe how to prioritize multiple locations received from various sources, received in multiple messages (or statically configured) at various times. I did include that sort of logic in my latest DSLF draft. If there is a desire to have some of this in phonebcp, I'm fine with that. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Sunday, March 30, 2008 4:36 PM To: Hannes Tschofenig; ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Multiple Location PIDF-LO profile describes how to choose the correct location for exactly this purpose. That is the application form which the original requirements were drawn. -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig Sent: Sun 3/30/2008 2:55 PM To: ecrit@ietf.org Subject: [Ecrit] Phone BCP: Multiple Location " ED-39 If a UA has more than one location available to it, it MUST choose one location to route the call towards the PSAP. SP-16 If a proxy inserts location on behalf of an endpoint, and it has multiple locations available for the endpoint it MUST choose one location to use to route the call towards the PSAP. " I could imagine that someone might ask how to make a decision. So, how does the decision making look like? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ------------------------ [mf2] ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 19:38:05 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FE9628C202; Mon, 31 Mar 2008 19:38:05 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17FE428C19E for ; Mon, 31 Mar 2008 19:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.882 X-Spam-Level: X-Spam-Status: No, score=-0.882 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hsT6WRmics4 for ; Mon, 31 Mar 2008 19:38:03 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id E1F643A680D for ; Mon, 31 Mar 2008 19:38:02 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_03_31_21_51_11 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 31 Mar 2008 21:51:11 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Mar 2008 21:38:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 31 Mar 2008 21:37:58 -0500 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA083C6764@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: Multiple Location Thread-Index: AciSoBSicmd+wT1mQom8/iePcnSz0wABYVlrACJtvEAAD6FFRAAMWCawAABUM5A= References: <47EFF025.9000705@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA080ECEF5@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA083C6764@crexc41p> From: "Winterbottom, James" To: "Stark, Barbara" , "Hannes Tschofenig" , X-OriginalArrivalTime: 01 Apr 2008 02:38:00.0592 (UTC) FILETIME=[66ED8900:01C893A1] Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think that we need to be really careful about what kind of systems we are talking about then. For example RFC 3261 is extremely clear about what a proxy can and cannot do with a SIP body. So if extra body elements are being inserted then we better not be calling this thing a proxy. PIDF-LO profile is clear about how to interpret what is provided. So, my previous paragraph aside for one second, things upstream from the device originating the call MUST only be providing location if they believe that the location they are providing is better than that that is already provided. Assuming this premise holds true, then the rules for inclusion are clear, the new location must appear ahead of any existing location information. Cheers James > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Tuesday, 1 April 2008 1:30 PM > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > Key words are "Where multiple PIDF documents can be sent or received > together". When a device has a configured location, a location from > LLDP-MED, one from DHCP, and one or two (routing and dispatch) from > HELD, I think that the quoted language has no relevance on the order in > which these are then included in an "sos" message. These different > locations were not received together. LLDP-MED and DHCP locations are > not received as PIDF documents. > > This language does apply to the PSAP when it receives all of these > locations. They arrive together, and all in PIDF format. > Barbara > > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Monday, March 31, 2008 4:29 PM > To: Stark, Barbara; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > Nope. > > This is from PIDF-LO Profile > > " Rule #9: Where multiple PIDF documents can be sent or received > together, say in a multi-part MIME body, and current location > information is required by the recipient, then document selection > SHOULD be based on document order, with the first document > considered first." > > Cheers > James > > > > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Mon 3/31/2008 8:05 AM > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > It's my understanding that PIDF-LO only describes multiple location > precedence within a single message. It doesn't describe how to > prioritize multiple locations received from various sources, received > in multiple messages (or statically configured) at various times. > > I did include that sort of logic in my latest DSLF draft. If there is a > desire to have some of this in phonebcp, I'm fine with that. > Barbara > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Winterbottom, James > Sent: Sunday, March 30, 2008 4:36 PM > To: Hannes Tschofenig; ecrit@ietf.org > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > PIDF-LO profile describes how to choose the correct location for exactly > this purpose. > That is the application form which the original requirements were drawn. > > > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > Sent: Sun 3/30/2008 2:55 PM > To: ecrit@ietf.org > Subject: [Ecrit] Phone BCP: Multiple Location > > " > ED-39 If a UA has more than one location available to it, it MUST > choose one location to route the call towards the PSAP. > > SP-16 If a proxy inserts location on behalf of an endpoint, and it > has multiple locations available for the endpoint it MUST choose one > location to use to route the call towards the PSAP. > " > > I could imagine that someone might ask how to make a decision. > So, how does the decision making look like? > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > ------------------------------------------------------------------------ > ------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ > ------------------------ > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > ------------------------------------------------------------------------ > ------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ > ------------------------ > [mf2] > > > ***** > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential, proprietary, and/or > privileged material. Any review, retransmission, dissemination or other > use of, or taking of any action in reliance upon this information by > persons or entities other than the intended recipient is prohibited. If > you received this in error, please contact the sender and delete the > material from all computers. GA622 > > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 19:46:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B6B3A6A20; Mon, 31 Mar 2008 19:46:24 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4F4B3A6823 for ; Mon, 31 Mar 2008 19:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsx04GgSnYp6 for ; Mon, 31 Mar 2008 19:46:21 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 3663C28C10C for ; Mon, 31 Mar 2008 19:45:38 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_03_31_21_58_47 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 31 Mar 2008 21:58:47 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Mar 2008 21:45:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 31 Mar 2008 21:45:33 -0500 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA083C6764@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: Multiple Location Thread-Index: AciSoBSicmd+wT1mQom8/iePcnSz0wABYVlrACJtvEAAD6FFRAAMWCawAACTyqA= References: <47EFF025.9000705@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA080ECEF5@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA083C6764@crexc41p> From: "Winterbottom, James" To: "Stark, Barbara" , "Hannes Tschofenig" , X-OriginalArrivalTime: 01 Apr 2008 02:45:36.0267 (UTC) FILETIME=[768805B0:01C893A2] Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Barbara, Having re-read your email I think I misunderstood what you were saying. I think what you are saying is that if a device engages all three LCPs and gets a different location for each of them, what does it do? I think the correct answer is that it should only try 3 methods if the first 2 failed. That is, it tries one method, if that doesn't work, it tries the next one. In the HELD routing/dispatch example I hope that we can say always use dispatch since the dispatch location kind of needs to fall into the catchment of the routing area to make any sense. I think we should avoid trying to get as many different locations as we can. As for DHCP and LLDP-MED I am not sure that I understand your last sentence in the first paragraph. I am not aware that we considering sending a literal location in any form other than a PIDF-LO with the sos message. Cheers James > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Tuesday, 1 April 2008 1:30 PM > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > Key words are "Where multiple PIDF documents can be sent or received > together". When a device has a configured location, a location from > LLDP-MED, one from DHCP, and one or two (routing and dispatch) from > HELD, I think that the quoted language has no relevance on the order in > which these are then included in an "sos" message. These different > locations were not received together. LLDP-MED and DHCP locations are > not received as PIDF documents. > > This language does apply to the PSAP when it receives all of these > locations. They arrive together, and all in PIDF format. > Barbara > > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Monday, March 31, 2008 4:29 PM > To: Stark, Barbara; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > Nope. > > This is from PIDF-LO Profile > > " Rule #9: Where multiple PIDF documents can be sent or received > together, say in a multi-part MIME body, and current location > information is required by the recipient, then document selection > SHOULD be based on document order, with the first document > considered first." > > Cheers > James > > > > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Mon 3/31/2008 8:05 AM > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > It's my understanding that PIDF-LO only describes multiple location > precedence within a single message. It doesn't describe how to > prioritize multiple locations received from various sources, received > in multiple messages (or statically configured) at various times. > > I did include that sort of logic in my latest DSLF draft. If there is a > desire to have some of this in phonebcp, I'm fine with that. > Barbara > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Winterbottom, James > Sent: Sunday, March 30, 2008 4:36 PM > To: Hannes Tschofenig; ecrit@ietf.org > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > PIDF-LO profile describes how to choose the correct location for exactly > this purpose. > That is the application form which the original requirements were drawn. > > > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > Sent: Sun 3/30/2008 2:55 PM > To: ecrit@ietf.org > Subject: [Ecrit] Phone BCP: Multiple Location > > " > ED-39 If a UA has more than one location available to it, it MUST > choose one location to route the call towards the PSAP. > > SP-16 If a proxy inserts location on behalf of an endpoint, and it > has multiple locations available for the endpoint it MUST choose one > location to use to route the call towards the PSAP. > " > > I could imagine that someone might ask how to make a decision. > So, how does the decision making look like? > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > ------------------------------------------------------------------------ > ------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ > ------------------------ > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > ------------------------------------------------------------------------ > ------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ > ------------------------ > [mf2] > > > ***** > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential, proprietary, and/or > privileged material. Any review, retransmission, dissemination or other > use of, or taking of any action in reliance upon this information by > persons or entities other than the intended recipient is prohibited. If > you received this in error, please contact the sender and delete the > material from all computers. GA622 > > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 31 20:00:12 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5FF13A68D8; Mon, 31 Mar 2008 20:00:12 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC39D3A68D8 for ; Mon, 31 Mar 2008 20:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=1.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKpxOi2np42m for ; Mon, 31 Mar 2008 20:00:10 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id E497E3A685E for ; Mon, 31 Mar 2008 20:00:09 -0700 (PDT) Received: from [192.168.0.57] (pool-71-250-66-107.nwrknj.east.verizon.net [71.250.66.107]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m312xx1W011380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 31 Mar 2008 23:00:00 -0400 (EDT) Message-Id: <61C23714-5B39-4EE8-AB8B-33EE321CEAD6@cs.columbia.edu> From: Henning Schulzrinne To: Hannes Tschofenig In-Reply-To: <47F12A17.6070109@gmx.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 31 Mar 2008 22:59:58 -0400 References: <47EFF059.70601@gmx.net> <008f01c892a3$c781db80$9744f444@cis.neustar.com> <89678C47-7277-4EA4-9F4A-B5F7C8C831A3@cs.columbia.edu> <014101c8934a$bf63c970$6901a8c0@cis.neustar.com> <771CF8C9-6595-42F3-AA77-EA69046AC906@cs.columbia.edu> <47F12375.8000700@gmx.net> <03A42269-889E-4A75-B8D4-98127959C16E@cs.columbia.edu> <47F12698.5010307@gmx.net> <23B6A633-5A88-4B48-BFC4-35B88C85A867@cs.columbia.edu> <47F12A17.6070109@gmx.net> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Testing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Mar 31, 2008, at 2:14 PM, Hannes Tschofenig wrote: > Hi Henning, > > > Henning Schulzrinne wrote: >> I don't see how this can work unless the service URL is the same >> for both test and operational systems. I thought our requirement >> was that a PSAP could designate another system as a test system >> (e.g., a statewide center), so that any tests would not interfere >> with "real" calls. > > I thought that this was the idea to have test calls treated in the > same way as real emergency calls. We only do a certain extent. For example, we probably don't want a real PSAP call taker to answer the call and we may not want to route the call all the way to the PSAP, given their somewhat more limited bandwidth. > > >> Thus, we want to be able to convey test URLs in LoST. Once you do >> that, it's presumably trivial to have two SIP URLs: >> >> sip:police+test@psap.gov >> sip:police@psap.gov >> >> even if you want to direct both calls to the same proxy. This isn't >> a major concern if we assume that all calls, test and real, go to a >> statewide ESRP. I'm not sure that we want to *require* that. > > Maybe we should ask PSAP operators what type of depoloyment mode > they want. > > Another way forward would be to go ahead with the solution you > proposed, i.e., introducing flexibility. When a PSAP operator wants > to use the "real" system also for test calls then they would return > the same URIs twice, one for the test and another one for the "real" > emergency call. If they don't want this behavior then they would > return different URIs. > I suspect PSAP operators don't know yet what they want - they have no operational experience to guide them. Thus, I'd rather have a solution that makes it less likely we guess wrong. In addition, these types of details are likely to depend strongly on national differences, so that just asking, say, somebody from a highly distributed or highly centralized arrangement isn't likely to be helpful. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 1 06:01:28 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A90B13A6F98; Tue, 1 Apr 2008 06:01:28 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D6F43A6F89 for ; Tue, 1 Apr 2008 06:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.11 X-Spam-Level: X-Spam-Status: No, score=-102.11 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoJ4lAU+msdP for ; Tue, 1 Apr 2008 06:01:22 -0700 (PDT) Received: from aismt07p.bellsouth.com (aismt07p.bellsouth.com [139.76.165.213]) by core3.amsl.com (Postfix) with ESMTP id 549AA28C4A1 for ; Tue, 1 Apr 2008 05:47:43 -0700 (PDT) Received: from ([139.76.131.87]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.198633842; Tue, 01 Apr 2008 08:47:20 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 1 Apr 2008 08:47:19 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 1 Apr 2008 08:47:20 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 08:47:18 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA083C6796@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: Multiple Location thread-index: AciSoBSicmd+wT1mQom8/iePcnSz0wABYVlrACJtvEAAD6FFRAAMWCawAACTyqAAFIlhkA== References: <47EFF025.9000705@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA080ECEF5@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA083C6764@crexc41p> From: "Stark, Barbara" To: "Winterbottom, James" , "Hannes Tschofenig" , X-OriginalArrivalTime: 01 Apr 2008 12:47:20.0311 (UTC) FILETIME=[8637F070:01C893F6] Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hey James, I agree with your statement in your other email about proxies. I thought I had also read that proxies can only insert LbyR, because they aren't supposed to insert stuff in the body. And I think that proxies that have multiple locations for an endpoint are beyond anyone's help in writing recommendations for decision making. We don't know what those locations are or where they came from. I'm really only concerned with end devices and "intermediate devices", like home routers. If you say that devices "should" only try 3 methods if the first 2 failed, that means that it's ok if they want to just do all 3. There's no prohibition against trying multiple methods. And a configured location may also be available. Recommendations for how an end device prioritizes these (if it happens to get multiple locations), before sending them out, are included in my document. And I'm not going to remove those recommendations just because devices "should" try to avoid having multiple locations. My statement on LLDP-MED and DHCP was that the location sent by those protocols does not arrive at the end device in PIDF-LO format. I was mentioning that the PIDF rules on prioritizing received PIDF locations state that they apply to received PIDF locations. LLDP-MED and DHCP locations are not received by the end device as PIDF locations. Therefore the rules do not apply. They are also not received "together". Therefore, the rules do not apply. If recommendations are needed for handling multiple locations at an end device (and I believe they are), then I am saying that the PIDF rules are necessary (for multiple PIDF received together) but insufficient (for multiple locations gotten in a variety of ways), and that the PIDF document is the wrong place for comprehensive recommendations that take into account a variety of permutations of how devices get location. Barbara -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Monday, March 31, 2008 10:46 PM To: Stark, Barbara; Hannes Tschofenig; ecrit@ietf.org Subject: RE: [Ecrit] Phone BCP: Multiple Location Hi Barbara, Having re-read your email I think I misunderstood what you were saying. I think what you are saying is that if a device engages all three LCPs and gets a different location for each of them, what does it do? I think the correct answer is that it should only try 3 methods if the first 2 failed. That is, it tries one method, if that doesn't work, it tries the next one. In the HELD routing/dispatch example I hope that we can say always use dispatch since the dispatch location kind of needs to fall into the catchment of the routing area to make any sense. I think we should avoid trying to get as many different locations as we can. As for DHCP and LLDP-MED I am not sure that I understand your last sentence in the first paragraph. I am not aware that we considering sending a literal location in any form other than a PIDF-LO with the sos message. Cheers James > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Tuesday, 1 April 2008 1:30 PM > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > Key words are "Where multiple PIDF documents can be sent or received > together". When a device has a configured location, a location from > LLDP-MED, one from DHCP, and one or two (routing and dispatch) from > HELD, I think that the quoted language has no relevance on the order in > which these are then included in an "sos" message. These different > locations were not received together. LLDP-MED and DHCP locations are > not received as PIDF documents. > > This language does apply to the PSAP when it receives all of these > locations. They arrive together, and all in PIDF format. > Barbara > > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Monday, March 31, 2008 4:29 PM > To: Stark, Barbara; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > Nope. > > This is from PIDF-LO Profile > > " Rule #9: Where multiple PIDF documents can be sent or received > together, say in a multi-part MIME body, and current location > information is required by the recipient, then document selection > SHOULD be based on document order, with the first document > considered first." > > Cheers > James > > > > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Mon 3/31/2008 8:05 AM > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > It's my understanding that PIDF-LO only describes multiple location > precedence within a single message. It doesn't describe how to > prioritize multiple locations received from various sources, received > in multiple messages (or statically configured) at various times. > > I did include that sort of logic in my latest DSLF draft. If there is a > desire to have some of this in phonebcp, I'm fine with that. > Barbara > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Winterbottom, James > Sent: Sunday, March 30, 2008 4:36 PM > To: Hannes Tschofenig; ecrit@ietf.org > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > PIDF-LO profile describes how to choose the correct location for exactly > this purpose. > That is the application form which the original requirements were drawn. > > > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > Sent: Sun 3/30/2008 2:55 PM > To: ecrit@ietf.org > Subject: [Ecrit] Phone BCP: Multiple Location > > " > ED-39 If a UA has more than one location available to it, it MUST > choose one location to route the call towards the PSAP. > > SP-16 If a proxy inserts location on behalf of an endpoint, and it > has multiple locations available for the endpoint it MUST choose one > location to use to route the call towards the PSAP. > " > > I could imagine that someone might ask how to make a decision. > So, how does the decision making look like? > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > ------------------------------------------------------------------------ > ------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ > ------------------------ > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > ------------------------------------------------------------------------ > ------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ > ------------------------ > [mf2] > > > ***** > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential, proprietary, and/or > privileged material. Any review, retransmission, dissemination or other > use of, or taking of any action in reliance upon this information by > persons or entities other than the intended recipient is prohibited. If > you received this in error, please contact the sender and delete the > material from all computers. GA622 > > ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ------------------------ [mf2] ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 1 06:19:14 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C33133A6D26; Tue, 1 Apr 2008 06:19:14 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A583728C4A9 for ; Tue, 1 Apr 2008 06:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.148 X-Spam-Level: X-Spam-Status: No, score=-102.148 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAMPVwgRGl4d for ; Tue, 1 Apr 2008 06:19:12 -0700 (PDT) Received: from aismt07p.bellsouth.com (aismt07p.bellsouth.com [139.76.165.213]) by core3.amsl.com (Postfix) with ESMTP id 022EF28C4DE for ; Tue, 1 Apr 2008 06:18:40 -0700 (PDT) Received: from ([139.76.131.79]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.198637956; Tue, 01 Apr 2008 09:18:05 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 1 Apr 2008 09:18:05 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 1 Apr 2008 09:18:05 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 09:18:04 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA083C67B9@crexc41p> In-Reply-To: <008d01c892a3$a4530d50$9744f444@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: HELD Discovery thread-index: AciSoBqsOT+0WFnXRMKPRqULJ9NB/wAA3TkwACQpPfA= References: <47EFF041.6020904@gmx.net> <008d01c892a3$a4530d50$9744f444@cis.neustar.com> From: "Stark, Barbara" To: "Brian Rosen" , "Hannes Tschofenig" , X-OriginalArrivalTime: 01 Apr 2008 13:18:05.0250 (UTC) FILETIME=[D1E34A20:01C893FA] Subject: Re: [Ecrit] Phone BCP: HELD Discovery X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org HELD (LIS) discovery (http://www.ietf.org/internet-drafts/draft-ietf-geopriv-lis-discovery-00 .txt) has a section on "Determining an External IP Address". Being able to determine the public IP address is an important capability in order to be able to do reverse DNS for the domain, which enables the ability to do U-NAPTR. That section mentions several possible methods of determining the public IP address, including STUN (a subset of ICE), UPnP, and HTTP GET. I would like to see the phonebcp requirement remain, as is. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Sunday, March 30, 2008 4:21 PM To: 'Hannes Tschofenig'; ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: HELD Discovery I think you are correct. This was a left over from some previous notions of how HELD worked. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 3:56 PM To: ecrit@ietf.org Subject: [Ecrit] Phone BCP: HELD Discovery " ED-47 Endpoints MUST support one or more mechanisms that allow them to determine their public IP address. Examples include ICE [I-D.ietf-mmusic-ice] and HTTP get. " This functionality is inherited by the HELD discovery mechanism. The reference to ICE is not needed since HELD discovery does not use ICE and HTTP get is not used at all. _______________________________________________ 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 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit