From ecrit-bounces@ietf.org Thu Jul 3 18:10:37 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 165D73A6A46; Thu, 3 Jul 2008 18:10: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 5BB6D3A688B for ; Thu, 3 Jul 2008 18:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 XoEXq91oejAw for ; Thu, 3 Jul 2008 18:10:34 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [61.144.161.53]) by core3.amsl.com (Postfix) with ESMTP id 83B0E3A6A2E for ; Thu, 3 Jul 2008 18:10:34 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3G00ATSJ9THQ@szxga01-in.huawei.com> for ecrit@ietf.org; Fri, 04 Jul 2008 09:10:41 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3G00CGHJ9T40@szxga01-in.huawei.com> for ecrit@ietf.org; Fri, 04 Jul 2008 09:10:41 +0800 (CST) Received: from s32328b ([10.85.203.144]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K3G00KBVJ9S0T@szxml03-in.huawei.com> for ecrit@ietf.org; Fri, 04 Jul 2008 09:10:41 +0800 (CST) Date: Fri, 04 Jul 2008 09:10:40 +0800 From: Qian Sun To: ecrit@ietf.org Message-id: <004201c8dd72$c6a743c0$90cb550a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcjdcsZRfXRrruICSTupoJtODGFhhQ== Subject: [Ecrit] New ID:draft-sun-ecrit-unsafe-areas-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 just submitted a new draft, it can be found here: http://www.ietf.org/internet-drafts/draft-sun-ecrit-unsafe-areas-00.txt Filename: draft-sun-ecrit-unsafe-areas Revision: 00 Title: Specifying Unsafe Areas in LoST Service Boundary Creation_date: 2008-07-01 WG ID: Independent Submission Number_of_pages: 8 Abstract: This document describes how to specify unsafe areas in LoST for emergency services, such as police, mountain, marine and fire. Your comments are welcome! Thanks! Qian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 4 10:23:01 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1119D3A69C6; Fri, 4 Jul 2008 10:23: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 A7AF73A69C3 for ; Fri, 4 Jul 2008 10:22:59 -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 7PCX9qtxC6VJ for ; Fri, 4 Jul 2008 10:22:58 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 60A773A69A0 for ; Fri, 4 Jul 2008 10:22:57 -0700 (PDT) Received: (qmail invoked by alias); 04 Jul 2008 17:23:04 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp048) with SMTP; 04 Jul 2008 19:23:04 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Lw6I/t6iLD9dgpdumBPkv8mo8Cvn8atq5TUeVYZ UWaHb4Qfadh7xZ Message-ID: <486E5C71.5070403@gmx.net> Date: Fri, 04 Jul 2008 20:22:57 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: 'ECRIT' X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Subject: [Ecrit] Comments for draft-sun-ecrit-shelter-service-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Thanks again for this draft. This sounds like a useful concept to define something like the "urn:service:shelter" URN. The listed sub-services would require more discussion since their semantic is not well specified. I do, however, wonder how to treat the overlap with early warning concepts here. I recall the adhoc meeting we had on early warning last year and Steve told us that in the London bombing there was a need for people to learn where they have to go after the bombings took place. His idea, however, was to put that information into the early warning CAP document itself. Have you had a chance to speak with folks working in the disaster management field to get some feedback from them? Ciao Hannes -------- Original Message -------- Subject: I-D Action:draft-sun-ecrit-shelter-service-00.txt Date: Thu, 3 Jul 2008 03:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Shelter Service And Classification Author(s) : Q. Sun, R. George Filename : draft-sun-ecrit-shelter-service-00.txt Pages : 8 Date : 2008-07-03 This document defines a new service registration 'shelter', and describes how to find, what instances of shelter service are closest to the user's location. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sun-ecrit-shelter-service-00.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. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 4 10:23:53 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CAD33A69C6; Fri, 4 Jul 2008 10:23: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 4FEE33A69C6 for ; Fri, 4 Jul 2008 10:23:52 -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=[AWL=0.000, 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 U15+M7BkBNey for ; Fri, 4 Jul 2008 10:23:51 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9AB913A69A0 for ; Fri, 4 Jul 2008 10:23:49 -0700 (PDT) Received: (qmail invoked by alias); 04 Jul 2008 17:23:56 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp029) with SMTP; 04 Jul 2008 19:23:56 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18V3SYEe/0VKXUe6dhYR6dd8GBPr/aQFpUxpBJ0/v bndl6WAMnjFaSD Message-ID: <486E5CA5.7010502@gmx.net> Date: Fri, 04 Jul 2008 20:23:49 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: 'ECRIT' X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Subject: [Ecrit] Comments for draft-robins-ecrit-sub-services-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Robins, Hi Qian, thanks for submitting this document. I have two questions/comments for your draft. * There is a List Services query in the LoST specification that allows you to list the services of a LoST server (see Section 10 of LoST). Is this functionality insufficient for your purpose. * In your document you suggest to define new URNs that allow further differentiation between the type of service a PSAP might provide. You indicate urn:service:sos.police.terrorist urn:service:sos.police.arson urn:service:sos.police.robbery as sub-services for urn:service:sos.police. Did you have a chance to talk to PSAP operators whether they believe this functionality is something they would like to expose to the outside world? When do you expect the user to indicate this type of detail (since there is a user-interface issue associated with this aspect)? I could imagine that you could quickly turn the person that reports certain crime into a detective when you, for example, allow the following information to be differentiated: urn:service:sos.police.robbery urn:service:sos.police.homicide urn:service:sos.police.homicide.aggravated-assault urn:service:sos.police.homicide.manslaughter urn:service:sos.police.homicide.manslaughter.avunculicide urn:service:sos.police.homicide.manslaughter.democide urn:service:sos.police.homicide.manslaughter.familicide urn:service:sos.police.homicide.manslaughter.femicide urn:service:sos.police.homicide.manslaughter.filicide urn:service:sos.police.homicide.manslaughter.fratricide urn:service:sos.police.homicide.manslaughter.gendercide urn:service:sos.police.homicide.manslaughter.genocide urn:service:sos.police.homicide.manslaughter.infanticide urn:service:sos.police.homicide.manslaughter.mariticide urn:service:sos.police.homicide.manslaughter.matricide urn:service:sos.police.homicide.manslaughter.neonaticide urn:service:sos.police.homicide.manslaughter.parricide urn:service:sos.police.homicide.manslaughter.patricide urn:service:sos.police.homicide.manslaughter.regicide urn:service:sos.police.homicide.manslaughter.sororicide urn:service:sos.police.homicide.manslaughter.suicide urn:service:sos.police.homicide.manslaughter.tyrannicide urn:service:sos.police.homicide.manslaughter.uxoricide urn:service:sos.police.homicide.murder urn:service:sos.police.homicide.murder.assassination urn:service:sos.police.homicide.murder.child-murder urn:service:sos.police.homicide.murder.consensual-homicide urn:service:sos.police.homicide.murder.contract-killing urn:service:sos.police.homicide.murder.honour-killing urn:service:sos.police.homicide.murder.lust-murder urn:service:sos.police.homicide.murder.lynching urn:service:sos.police.homicide.murder.mass-murder urn:service:sos.police.homicide.murder.murder-suicide urn:service:sos.police.homicide.murder.proxy-murder urn:service:sos.police.homicide.murder.ritual-murder urn:service:sos.police.homicide.murder.serial-killer urn:service:sos.police.homicide.murder.spree-killer urn:service:sos.police.homicide.murder.torture-murder I guess you get the point. I am unsure where to stop with the types of sub-services and the ability of the person to know all these different things. Needless to say that there are persons other than Thomas Mueller and Sherlock Homes out there... Ciao Hannes -------- Original Message -------- Subject: I-D Action:draft-robins-ecrit-sub-services-00.txt Date: Wed, 2 Jul 2008 20:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Location-to-Service Translation Protocol (LoST) Sub-Services Author(s) : R. George, Q. Sun Filename : draft-robins-ecrit-sub-services-00.txt Pages : 8 Date : 2008-07-02 This document describes, how a LoST client can ask LoST server for the list of sub services that it supports, and to incorporate additional information about the service provider in response. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-robins-ecrit-sub-services-00.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. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 4 10:25:04 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CCC23A69C3; Fri, 4 Jul 2008 10:25: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 7E4893A69C3 for ; Fri, 4 Jul 2008 10:25:02 -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 BvURHKNg-dy9 for ; Fri, 4 Jul 2008 10:25:01 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 34EE43A691C for ; Fri, 4 Jul 2008 10:25:00 -0700 (PDT) Received: (qmail invoked by alias); 04 Jul 2008 17:25:08 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp053) with SMTP; 04 Jul 2008 19:25:08 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19zyI0AYxBzTHEtno+vXyK9YGn5DO2SbQ/cRMKLiU wkFG4ZnTHlzAKx Message-ID: <486E5CEC.9040200@gmx.net> Date: Fri, 04 Jul 2008 20:25:00 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Qian Sun References: <004201c8dd72$c6a743c0$90cb550a@china.huawei.com> In-Reply-To: <004201c8dd72$c6a743c0$90cb550a@china.huawei.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55 Cc: ecrit@ietf.org Subject: [Ecrit] Comments for draft-sun-ecrit-unsafe-areas-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Qian, thanks for the document. Interesting usage of LoST. A few quick comments: * I wonder whether it wouldn't be better to define some new service URNs for the usage of these "unsafe" areas instead of adding a new attribute. The reason for this is that the existing service URNs are somewhat difficult to use in this context. For example, what does it mean to have the unsafe attribute included in the request when the "urn:service:sos.poison" URN is used? New URNs are being proposed, such as those in http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.txt, that make the semantic even more difficult to interpret. * Would be useful to include an element in the reponse to point to more detailed information, such as a URL to a webpage? * Deployment: Who do you think would want to run such a service? Would this be something the PSAP operator would want todo? Tourism office? Police departments? (I am trying to figure out where to get some feedback from.) How often do you think the "service boundaries" of these unsafe areas change? (Keep constant for years vs. change every day) Ciao Hannes Qian Sun wrote: > Hi, All > > I just submitted a new draft, it can be found here: > http://www.ietf.org/internet-drafts/draft-sun-ecrit-unsafe-areas-00.txt > > Filename: draft-sun-ecrit-unsafe-areas > Revision: 00 > Title: Specifying Unsafe Areas in LoST Service Boundary > Creation_date: 2008-07-01 > WG ID: Independent Submission > Number_of_pages: 8 > > Abstract: > This document describes how to specify unsafe areas in LoST for emergency services, such as police, mountain, marine and fire. > > Your comments are welcome! > > Thanks! > Qian > > _______________________________________________ > Ecrit mailing 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 Jul 4 11:16:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB2EF3A689B; Fri, 4 Jul 2008 11:16: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 B612B3A689B for ; Fri, 4 Jul 2008 11:16:24 -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=[AWL=0.000, 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 K-BzDKy7C9f6 for ; Fri, 4 Jul 2008 11:16:24 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 95AEC3A6851 for ; Fri, 4 Jul 2008 11:16:23 -0700 (PDT) Received: (qmail invoked by alias); 04 Jul 2008 18:16:28 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp056) with SMTP; 04 Jul 2008 20:16:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX185EX8eC3I5NYPhtfu3sPcrRBdIDyh+DvSabSnV7v WaNUrEqSxlV9nz Message-ID: <486E68F5.4030701@gmx.net> Date: Fri, 04 Jul 2008 21:16:21 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: 'ECRIT' X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78 Subject: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Karl Heinz, sounds useful to me to specify for what region the response to the ListServicesByLocation query remains the same. The document is incomplete since the corresponding XML schema extensions are not specified. Are you planning to incorporate it into the next draft update? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 4 11:23:04 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F3D73A6921; Fri, 4 Jul 2008 11: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 80A783A6921 for ; Fri, 4 Jul 2008 11:23:03 -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 T3gkllCHogwB for ; Fri, 4 Jul 2008 11:23:02 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 29B9D3A6851 for ; Fri, 4 Jul 2008 11:23:01 -0700 (PDT) Received: (qmail invoked by alias); 04 Jul 2008 18:23:08 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp041) with SMTP; 04 Jul 2008 20:23:08 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+wWSd820yw+ZG+L+ZqCOBV14Y9PI+KEeFyefW7jD mnZAzYTTbCVOHb Message-ID: <486E6A84.5070103@gmx.net> Date: Fri, 04 Jul 2008 21:23:00 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Hannu Hietalahti References: <48580FE7.9010302@gmx.net> In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.68 Cc: 'ECRIT' Subject: [Ecrit] draft-polk-ecrit-local-emergency-rph-namespace-02.txt: A dependency from the 3GPP? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Hannu, > I'd like to know about this ID > http://www.ietf.org/internet-drafts/draft-polk-ecrit-local-emergency-rph-namespace-02.txt > > > I was tasked with neutering it to only work inside an ESInet, yet 3GPP > wants to be able to use this within their networks by the P- and > E-(CSCFs) because they control their infrastructure. This is > mentioned in the above -02, but that's not what Ted recommended I do > with the doc. Hannu, is this true? Is there a dependency from the 3GPP side? Ciao Hannes PS: I put a presentation about this document to the agenda. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 4 13:55:07 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47D563A6BB1; Fri, 4 Jul 2008 13:55: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 D92AE3A6BA9 for ; Fri, 4 Jul 2008 13:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9eH1li0Kk8T for ; Fri, 4 Jul 2008 13:55:05 -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 0D1D93A6BB1 for ; Fri, 4 Jul 2008 13:55:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,304,1212364800"; d="scan'208";a="48986815" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 04 Jul 2008 20:55:12 +0000 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 m64KtCHX005931; Fri, 4 Jul 2008 13:55:12 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m64KtCpX005868; Fri, 4 Jul 2008 20:55:12 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); Fri, 4 Jul 2008 13:55:12 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.80.13]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jul 2008 13:55:12 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 04 Jul 2008 15:55:14 -0500 To: Hannes Tschofenig , Hannu Hietalahti From: "James M. Polk" In-Reply-To: <486E6A84.5070103@gmx.net> References: <48580FE7.9010302@gmx.net> <486E6A84.5070103@gmx.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 04 Jul 2008 20:55:12.0230 (UTC) FILETIME=[4078D060:01C8DE18] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=716; t=1215204912; x=1216068912; 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=20draft-polk-ecrit-local-emergency-rph-na mespace-02.txt=3A=20A=0A=20=20dependency=20from=20the=203GPP ? |Sender:=20; bh=rvm7VHLK72WG8rkyMsgxONCCNtOPslvLxowXgviaW7M=; b=kUgmQGQdMO2ocELosy5TOYB/wAJEv9sBVZAjWl5IsC5iUI/Ip5q08sB73l SWsNdWkApy43z2Q9lAopkR0Xi6PkzmlcW3ba5Fk16fhU/Wm/O6SYsLiitIfL qNraIc6vS2Y58EvtolJ2Lj5U4+Xa4DN78ORc2iEe1K0N5kT/Se/U8=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] draft-polk-ecrit-local-emergency-rph-namespace-02.txt: A dependency from the 3GPP? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 01:23 PM 7/4/2008, Hannes Tschofenig wrote: >Hi Hannu, > >>I'd like to know about this ID >>http://www.ietf.org/internet-drafts/draft-polk-ecrit-local-emergency-rph-namespace-02.txt >> >> >>I was tasked with neutering it to only work inside an ESInet, yet >>3GPP wants to be able to use this within their networks by the P- >>and E-(CSCFs) because they control their infrastructure. This is >>mentioned in the above -02, but that's not what Ted recommended I >>do with the doc. > >Hannu, is this true? Hannes - Keith Drage is who made this request, not Hannu. >Is there a dependency from the 3GPP side? > >Ciao >Hannes > >PS: I put a presentation about this document to the agenda. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 4 15:20:20 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFCFC3A6847; Fri, 4 Jul 2008 15:20: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 976F13A6847 for ; Fri, 4 Jul 2008 15:20:19 -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=[AWL=0.000, 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 qOUsvWGVgJig for ; Fri, 4 Jul 2008 15:20:18 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B91BA3A681E for ; Fri, 4 Jul 2008 15:20:16 -0700 (PDT) Received: (qmail invoked by alias); 04 Jul 2008 22:20:23 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp032) with SMTP; 05 Jul 2008 00:20:23 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19c2dVacnFcyQSamlSck5wl8e2INjQJGLpsDAlAgr 8NGuijA8eGXA5y Message-ID: <486EA21F.40203@gmx.net> Date: Sat, 05 Jul 2008 01:20:15 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "James M. Polk" References: <48580FE7.9010302@gmx.net> <486E6A84.5070103@gmx.net> In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 Cc: 'ECRIT' , Hannu Hietalahti Subject: Re: [Ecrit] draft-polk-ecrit-local-emergency-rph-namespace-02.txt: A dependency from the 3GPP? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Sorry; might have asked the wrong person then. Keith, can you give us more information? Ciao Hannes James M. Polk wrote: > At 01:23 PM 7/4/2008, Hannes Tschofenig wrote: >> Hi Hannu, >> >>> I'd like to know about this ID >>> http://www.ietf.org/internet-drafts/draft-polk-ecrit-local-emergency-rph-namespace-02.txt >>> >>> >>> I was tasked with neutering it to only work inside an ESInet, yet >>> 3GPP wants to be able to use this within their networks by the P- >>> and E-(CSCFs) because they control their infrastructure. This is >>> mentioned in the above -02, but that's not what Ted recommended I do >>> with the doc. >> >> Hannu, is this true? > > Hannes - Keith Drage is who made this request, not Hannu. > >> Is there a dependency from the 3GPP side? >> >> Ciao >> Hannes >> >> PS: I put a presentation about this document to the agenda. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 5 12:23:28 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A2C03A684B; Sat, 5 Jul 2008 12:23: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 527B53A684B for ; Sat, 5 Jul 2008 12:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 r+L0iOv-6svt for ; Sat, 5 Jul 2008 12:23:26 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E43A03A67D4 for ; Sat, 5 Jul 2008 12:23:25 -0700 (PDT) Received: (qmail invoked by alias); 05 Jul 2008 19:23:23 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp011) with SMTP; 05 Jul 2008 21:23:23 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+EJUp3RqyELcZRQuO7ilYKAmVkhBO4d/vROWVczP ATVBIl+jJee2hH Message-ID: <486FCA24.8000608@gmx.net> Date: Sat, 05 Jul 2008 22:23:16 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Karl Heinz Wolf References: <20080528194502.7D0D03A6A7A@core3.amsl.com> In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Cc: ecrit@ietf.org Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-lost-10.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Karl Heinz, I am currently addressing your comments as part of the AUTH48. Thanks for reading the draft so carefully. Nobody doing the implementation work has noticed these issues so far. Very good. Karl Heinz Wolf wrote: > I just had a look at the new LoST document, and I remembered that I > had some questions concerning LoST, I still got no answer for. > > Here are the points that still confuse me: > > 1) listServices and path indication: The draft says: "Since the query > is answered by the queried server, there > is no notion of recursion or indirection and no path indication." > But the sample in figure 12 has a element. > > The element always has to be present according to the XML schema. However, it will only contain one element, namely the contacted server. Hence, I removed the "... and no path indication." part of the sentence. > 2) the serviceNumber is still missing for the sample in figure 18, the > default mapping sample (as mentioned here last year > http://www.ietf.org/mail-archive/web/ecrit/current/msg04727.html ) > Although the servieNumber is optional in LoST, I thought the samples > should contain it since they are emergency call samples and without a > service number one cannot call the default PSAP. > > True. For the emergency services cases having the element there makes a lot of sense. > 3) how to request a specific location profile for > ? see > http://www.ietf.org/mail-archive/web/ecrit/current/msg05226.html > > > The location profile is essentially pre-set when the initial query was created. Hence, in this example the response to the getServiceBoundary should actually be geodetic location info rather than civic. I will fix the example -- good catch! > And I just noticed something new: > > profile="urn:ietf:params:lost:location-profile:basic-civic" is used > once, all the other examples use profile="civic". > > Fixed. > editorial: there is a "s" missing in ListServicesResponse: "Figure 12: > Example of " > > Fixed. Ciao Hannes > I hope someone can clarify my concerns! Thanks in advance. > > karl heinz > > > 2008/5/28 : > >> 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-10.txt >> Pages : 79 >> Date : 2008-05-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-10.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. >> >> >> _______________________________________________ >> Ecrit mailing 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 Jul 7 00:36:24 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 479E83A6A53; Mon, 7 Jul 2008 00:36: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 5A6373A6A53 for ; Mon, 7 Jul 2008 00:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=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 I4ZDoxQOYxcd for ; Mon, 7 Jul 2008 00:36:21 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by core3.amsl.com (Postfix) with ESMTP id 698293A6A4C for ; Mon, 7 Jul 2008 00:36:21 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id y36so1002860ugd.46 for ; Mon, 07 Jul 2008 00:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=eod3T3GpRPrRelpUVO7eumE/PuKutpgyZuiF8+OkSjg=; b=pQdfT925vBakEfLIl1h3HKOxejqQzNnAkx2zwR1z7Hk0UHosKoHTBnX8P8yWKxeaf1 EkDfvZSDe7qn0KcabD/VfW/+zVYRsfI42U+TRrHrZSkHp92hTsIFHUqlLzizrWYDl0oW lPU9kyytN3gIzl70Pv6FmTObaQ8Ic8lCGbclg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=dVbvTXsuvT6gEcWGdzmznIm/ta94nR2hmrokuN2PQu19uS/XtjTl01EnEB/D4YDt+b 2qCU43o5c9/In2kec7nFjqQjFWWFtoPkeph7chE20g3j1oZak+elab/hdqc5/fq3IDMM wp0PKlkAbEB9tNacas1KPYflV0nDMbh+yzmcw= Received: by 10.66.239.16 with SMTP id m16mr4260618ugh.9.1215416183103; Mon, 07 Jul 2008 00:36:23 -0700 (PDT) Received: by 10.67.30.1 with HTTP; Mon, 7 Jul 2008 00:36:23 -0700 (PDT) Message-ID: Date: Mon, 7 Jul 2008 09:36:23 +0200 From: "Karl Heinz Wolf" To: "Hannes Tschofenig" In-Reply-To: <486FCA24.8000608@gmx.net> MIME-Version: 1.0 Content-Disposition: inline References: <20080528194502.7D0D03A6A7A@core3.amsl.com> <486FCA24.8000608@gmx.net> Cc: ecrit@ietf.org Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-lost-10.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Hannes! good to hear that you are addressing my points. I hope you did not miss to remove sos.suicide? (figure 12 and 14!) And also don't forget to correct the examples on your webpage! just one more clarification please: >3) how to request a specific location profile for ? see http://www.ietf.org/mail-archive/web/ecrit/current/msg05226.html > The location profile is essentially pre-set when the initial query was > created. Hence, in this example the response to the getServiceBoundary > should actually be geodetic location info rather than civic. > > I will fix the example -- good catch! > how is the location profile pre-set? is it somehow done with the key (the draft does not say this, I'm just guessing)? cheers karl heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 7 00:44:06 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A614C28C137; Mon, 7 Jul 2008 00:44: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 92B2728C133 for ; Mon, 7 Jul 2008 00:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDlsWexnW5Ia for ; Mon, 7 Jul 2008 00:44:04 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 7785E28C135 for ; Mon, 7 Jul 2008 00:44:04 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m677i7ef025758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 09:44:07 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m677i5rd012481; Mon, 7 Jul 2008 09:44:07 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jul 2008 09:44:06 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jul 2008 09:44:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 10:43:58 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] I-D Action:draft-ietf-ecrit-lost-10.txt Thread-Index: AcjgBDEqjaKfvs0iRLqBqEOIF/ugoQAAB2Wg References: <20080528194502.7D0D03A6A7A@core3.amsl.com><486FCA24.8000608@gmx.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Karl Heinz Wolf" , "Hannes Tschofenig" X-OriginalArrivalTime: 07 Jul 2008 07:44:05.0924 (UTC) FILETIME=[3B968E40:01C8E005] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16016.005 X-TM-AS-Result: No--13.359000-8.000000-31 Cc: ecrit@ietf.org Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-lost-10.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Karl Heinz, >Hi Hannes! > >good to hear that you are addressing my points. >I hope you did not miss to remove sos.suicide? (figure 12 and 14!) I put you on CC when I sent the mail to the RFC Editor > >And also don't forget to correct the examples on your webpage! Will do that once the entire process is completed. > >just one more clarification please: > >>3) how to request a specific location profile for >? see >http://www.ietf.org/mail-archive/web/ecrit/current/msg05226.html >> The location profile is essentially pre-set when the initial >query was >> created. Hence, in this example the response to the >getServiceBoundary >> should actually be geodetic location info rather than civic. >> >> I will fix the example -- good catch! >> > >how is the location profile pre-set? is it somehow done with >the key (the draft does not say this, I'm just guessing)? With the initial request. The location profile used in the element is supposed to be the same as the one that is later returned. Ciao Hannes > >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 Mon Jul 7 00:58:10 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AC2B3A6806; Mon, 7 Jul 2008 00:58: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 43FE73A6806 for ; Mon, 7 Jul 2008 00:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 0G1JWxdcpNHJ for ; Mon, 7 Jul 2008 00:58:08 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by core3.amsl.com (Postfix) with ESMTP id 387EF3A67D7 for ; Mon, 7 Jul 2008 00:58:08 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id y36so1005441ugd.46 for ; Mon, 07 Jul 2008 00:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=NYJ2K91mgOAuPJ3uGoXPjHGJVyFm5AYtpL/6g792m+s=; b=G3hKCJgYK52uoz4dY2Ahq+2LDixZwVobMRD42P0dFH92LJ28Bwcji+ihfpwkulRcpj zTrEEE5WcL/AxXm2YesqODqUZNeOWgs/rdDBGuMX2uBtkIDnbGF5+n+RR5dh6kVUFEDY qzE08k3qsOqFGqBcCGuuLvWyQfS7yx/gC0tcQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=JuuOKoIaIKTCx8gcsHVAKVILDOZ6IP98r93bf4btTZAb21gtfuIikEIycEtCaohWde NZ+I/uWK8tv4dxoK/FKFgAnlXEixPG+Hb7DnM63lnKQI+mPJ9364U9WOcHJvqn9mQ5Qs 5j20BtDM8pHtQfataZTQxULUm4791TN9Q4dkM= Received: by 10.67.26.7 with SMTP id d7mr4265082ugj.44.1215417490974; Mon, 07 Jul 2008 00:58:10 -0700 (PDT) Received: by 10.67.30.1 with HTTP; Mon, 7 Jul 2008 00:58:11 -0700 (PDT) Message-ID: Date: Mon, 7 Jul 2008 09:58:11 +0200 From: "Karl Heinz Wolf" To: "Hannes Tschofenig" In-Reply-To: <486E68F5.4030701@gmx.net> MIME-Version: 1.0 Content-Disposition: inline References: <486E68F5.4030701@gmx.net> Cc: ECRIT Subject: Re: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Hannes! Thank you for reading my draft. At this early stage of the draft I concentrated on describing the problem in order to start a discussion. If the proposed solution sounds acceptable, I'll improve the draft. So, more comments are appreciated. cheers karl heinz On Fri, Jul 4, 2008 at 8:16 PM, Hannes Tschofenig wrote: > Hi Karl Heinz, > > sounds useful to me to specify for what region the response to the > ListServicesByLocation query remains the same. > > The document is incomplete since the corresponding XML schema extensions are > not specified. Are you planning to incorporate it into the next draft > update? > > 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 Mon Jul 7 01:08:08 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C585E28C147; Mon, 7 Jul 2008 01: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 4F77228C147 for ; Mon, 7 Jul 2008 01:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_37=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 NXj9FZarGEJX for ; Mon, 7 Jul 2008 01:08:06 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by core3.amsl.com (Postfix) with ESMTP id 190FA28C146 for ; Mon, 7 Jul 2008 01:08:05 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id y36so1006434ugd.46 for ; Mon, 07 Jul 2008 01:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=kTsChwV0RgRq4pR6IMOl07eRf+2LuHwav6VAy2wwt4s=; b=VDDYj0lvW9ZITLUGqcPGVVyqhyVGGH8hWwfLufsnVbp7lnk8gEPpxNWpX3WIfd1CSB 99j9GAfMNYBu/d7cPCkLNHvau7ORpF2Jw8UcCfK0ebt+Q4zTyBwXkuq3JvGBFtrPv2sV Y6w2V+UqD6nL4gizhCmwChSTtf2Sy7MCE7zh4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=U4osNquxQ/0qNH0/dgDsuoVuBVrmNVqDD7BjxTZS5f31uhxJ6wr7DTACoWbaEEZZgT JigQzLxK5K2FBm++KhPcHZfhupIl94nMivKzO1uLifZ4ffphlPglDdP5sOliojqsJ+k4 JOywstPS/ZcjqmP1vb0PFM8pV1TIYyCSuXd/k= Received: by 10.67.24.11 with SMTP id b11mr4269462ugj.35.1215418083743; Mon, 07 Jul 2008 01:08:03 -0700 (PDT) Received: by 10.67.30.1 with HTTP; Mon, 7 Jul 2008 01:08:03 -0700 (PDT) Message-ID: Date: Mon, 7 Jul 2008 10:08:03 +0200 From: "Karl Heinz Wolf" To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <20080528194502.7D0D03A6A7A@core3.amsl.com> <486FCA24.8000608@gmx.net> Cc: ecrit@ietf.org Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-lost-10.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Hannes! >>I hope you did not miss to remove sos.suicide? (figure 12 and 14!) > > > I put you on CC when I sent the mail to the RFC Editor Thank you, I read this mail now and it's corrected there. >> >>And also don't forget to correct the examples on your webpage! > > Will do that once the entire process is completed. > >> >>just one more clarification please: >> >>>3) how to request a specific location profile for >>? see >>http://www.ietf.org/mail-archive/web/ecrit/current/msg05226.html >>> The location profile is essentially pre-set when the initial >>query was >>> created. Hence, in this example the response to the >>getServiceBoundary >>> should actually be geodetic location info rather than civic. >>> >>> I will fix the example -- good catch! >>> >> >>how is the location profile pre-set? is it somehow done with >>the key (the draft does not say this, I'm just guessing)? > > With the initial request. The location profile used in the > element is supposed to be the same as the one that is later > returned. > but how should the LoST server know what profile to return when a client does a getServiceBoundary request (some time after the initial findService)? Is the LoST Server expected to identify the clients somehow and to store information what client gets which location profile? cheers karl heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 7 01:20:12 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7864128C13E; Mon, 7 Jul 2008 01:20: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 BEFDB3A6A67 for ; Mon, 7 Jul 2008 01:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 x8zlSkb5T5gZ for ; Mon, 7 Jul 2008 01:20:10 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by core3.amsl.com (Postfix) with ESMTP id 9DFEA3A6A5E for ; Mon, 7 Jul 2008 01:20:09 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id y36so1007692ugd.46 for ; Mon, 07 Jul 2008 01:20:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=dVVX3gIeVxrlxISKl0oDtcInewSFpi8WuKa8bk5jgok=; b=r38gmWH7NYYhoPUpbR/HXn7RY0qBZGJSqYCnjlS3CapKgoyRkpW+h6SipT0erJ9CRP 4ZCAp/Jyg9wAxpB9+GVxO00+k3WLvl0OJi4gVPWV8QW3QA4E3M/q08Hye+snjwhT8sVf MSnKo3m5Pg2IQDrzMgzXaOwkSDa8a5R6hK9wQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=SS/qLTXOaQPKDcQX5C816IvhVgjy6zxly/uNX7ROwKz0snH0Mh94PmeS8VxwA5g+YV yyNv+Qmp0LZA60tuI7VMQaRR2WEeCOSeoOHCPGZgc7aNqd5+ZOH38eSNyQ9mZTR2Eybf hJ2Nm20tUQ2Ke/9XSA3R0K9NJFIfNku6wT/8w= Received: by 10.67.122.10 with SMTP id z10mr4278570ugm.10.1215418813987; Mon, 07 Jul 2008 01:20:13 -0700 (PDT) Received: by 10.67.30.1 with HTTP; Mon, 7 Jul 2008 01:20:14 -0700 (PDT) Message-ID: Date: Mon, 7 Jul 2008 10:20:14 +0200 From: "Karl Heinz Wolf" To: "Hannes Tschofenig" In-Reply-To: <486E5CEC.9040200@gmx.net> MIME-Version: 1.0 Content-Disposition: inline References: <004201c8dd72$c6a743c0$90cb550a@china.huawei.com> <486E5CEC.9040200@gmx.net> Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments for draft-sun-ecrit-unsafe-areas-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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, I also read the draft, and like Hannes, my first thought was about a separate service URN for this propose. One additional comment: When the unsafe-Information is included to the Mapping Information of a particular PSAP, there could be a problem when a PSAP is responsible for a large area. Assuming a police PSAP is responsible for a whole federal state, there may be hundreds of unsafe areas inside - and most of them will be far away from my current location. So it could be more interesting to query for all unsafe-areas within a radius of 5 km, regardless of the service boundary of a particular PSAP. cheers karl heinz On Fri, Jul 4, 2008 at 7:25 PM, Hannes Tschofenig wrote: > Hi Qian, > > thanks for the document. Interesting usage of LoST. > > A few quick comments: > > * I wonder whether it wouldn't be better to define some new service URNs for > the usage of these "unsafe" areas instead of adding a new attribute. > The reason for this is that the existing service URNs are somewhat difficult > to use in this context. For example, what does it mean to have the unsafe > attribute included in the request when the "urn:service:sos.poison" URN is > used? New URNs are being proposed, such as those in > http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.txt, > that make the semantic even more difficult to interpret. > > * Would be useful to include an element in the reponse to point to more > detailed information, such as a URL to a webpage? > > * Deployment: Who do you think would want to run such a service? Would this > be something the PSAP operator would want todo? Tourism office? Police > departments? (I am trying to figure out where to get some feedback from.) > > How often do you think the "service boundaries" of these unsafe areas > change? (Keep constant for years vs. change every day) > > Ciao > Hannes > > > > Qian Sun wrote: >> >> Hi, All >> >> I just submitted a new draft, it can be found here: >> http://www.ietf.org/internet-drafts/draft-sun-ecrit-unsafe-areas-00.txt >> Filename: draft-sun-ecrit-unsafe-areas >> Revision: 00 >> Title: Specifying Unsafe Areas in LoST Service Boundary >> Creation_date: 2008-07-01 >> WG ID: Independent Submission >> Number_of_pages: 8 >> >> Abstract: >> This document describes how to specify unsafe areas in LoST for emergency >> services, such as police, mountain, marine and fire. >> >> Your comments are welcome! >> >> Thanks! >> Qian >> >> _______________________________________________ >> Ecrit mailing 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 Jul 7 02:46:13 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3315D3A6A48; Mon, 7 Jul 2008 02:46:13 -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 C61673A67AB for ; Mon, 7 Jul 2008 02:46:11 -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 v7xYHZes-Kv3 for ; Mon, 7 Jul 2008 02:46:10 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id DB9CF3A6A87 for ; Mon, 7 Jul 2008 02:45:41 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3M009ITQYOUF@szxga01-in.huawei.com> for ecrit@ietf.org; Mon, 07 Jul 2008 17:42:24 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3M00AXEQYOQW@szxga01-in.huawei.com> for ecrit@ietf.org; Mon, 07 Jul 2008 17:42:24 +0800 (CST) Received: from s32328b ([10.85.203.144]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K3M00IHYQYOCX@szxml05-in.huawei.com> for ecrit@ietf.org; Mon, 07 Jul 2008 17:42:24 +0800 (CST) Date: Mon, 07 Jul 2008 17:42:24 +0800 From: Qian Sun In-reply-to: To: 'Karl Heinz Wolf' , 'Hannes Tschofenig' Message-id: <000d01c8e015$c27fce70$90cb550a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcjgCkfcxVYVbKaARKKSUm+wppBJogACqHVQ Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments for draft-sun-ecrit-unsafe-areas-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 comments! In another draft we use this way you suggested to find safe areas: http://tools.ietf.org/html/draft-sun-ecrit-shelter-service-00 Regards, Qian > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > Sent: Monday, July 07, 2008 4:20 PM > To: Hannes Tschofenig > Cc: Qian Sun; ecrit@ietf.org > Subject: Re: [Ecrit] Comments for draft-sun-ecrit-unsafe-areas-00 > > Hi, > > I also read the draft, and like Hannes, my first thought was about a > separate service URN for this propose. > > One additional comment: > When the unsafe-Information is included to the Mapping Information of > a particular PSAP, there could be a problem when a PSAP is responsible > for a large area. Assuming a police PSAP is responsible for a whole > federal state, there may be hundreds of unsafe areas inside - and most > of them will be far away from my current location. So it could be more > interesting to query for all unsafe-areas within a radius of 5 km, > regardless of the service boundary of a particular PSAP. > > cheers > karl heinz > > On Fri, Jul 4, 2008 at 7:25 PM, Hannes Tschofenig > wrote: > > Hi Qian, > > > > thanks for the document. Interesting usage of LoST. > > > > A few quick comments: > > > > * I wonder whether it wouldn't be better to define some new service URNs for > > the usage of these "unsafe" areas instead of adding a new attribute. > > The reason for this is that the existing service URNs are somewhat difficult > > to use in this context. For example, what does it mean to have the unsafe > > attribute included in the request when the "urn:service:sos.poison" URN is > > used? New URNs are being proposed, such as those in > > > http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.txt, > > that make the semantic even more difficult to interpret. > > > > * Would be useful to include an element in the reponse to point to more > > detailed information, such as a URL to a webpage? > > > > * Deployment: Who do you think would want to run such a service? Would this > > be something the PSAP operator would want todo? Tourism office? Police > > departments? (I am trying to figure out where to get some feedback from.) > > > > How often do you think the "service boundaries" of these unsafe areas > > change? (Keep constant for years vs. change every day) > > > > Ciao > > Hannes > > > > > > > > Qian Sun wrote: > >> > >> Hi, All > >> > >> I just submitted a new draft, it can be found here: > >> http://www.ietf.org/internet-drafts/draft-sun-ecrit-unsafe-areas-00.txt > >> Filename: draft-sun-ecrit-unsafe-areas > >> Revision: 00 > >> Title: Specifying Unsafe Areas in LoST Service Boundary > >> Creation_date: 2008-07-01 > >> WG ID: Independent Submission > >> Number_of_pages: 8 > >> > >> Abstract: > >> This document describes how to specify unsafe areas in LoST for emergency > >> services, such as police, mountain, marine and fire. > >> > >> Your comments are welcome! > >> > >> Thanks! > >> Qian > >> > >> _______________________________________________ > >> Ecrit mailing 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 Jul 7 03:08:32 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3DF928C157; Mon, 7 Jul 2008 03:08: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 D79BD28C153 for ; Mon, 7 Jul 2008 03:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-1.700, 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 LzRbzqsou5M4 for ; Mon, 7 Jul 2008 03:08:30 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 2418928C157 for ; Mon, 7 Jul 2008 03:08:29 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m67A8WJA026337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 12:08:32 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m67A8Wma029393; Mon, 7 Jul 2008 12:08:32 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jul 2008 12:08:32 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jul 2008 12:08:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 13:08:30 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] I-D Action:draft-ietf-ecrit-lost-10.txt Thread-Index: AcjgCJjCHk5k6fixSuG7ie/+8mtUBwAEJFDQ References: <20080528194502.7D0D03A6A7A@core3.amsl.com> <486FCA24.8000608@gmx.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Karl Heinz Wolf" X-OriginalArrivalTime: 07 Jul 2008 10:08:32.0190 (UTC) FILETIME=[6915CDE0:01C8E019] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16016.006 X-TM-AS-Result: No--7.594000-8.000000-31 Cc: ecrit@ietf.org Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-lost-10.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 > >but how should the LoST server know what profile to return >when a client does a getServiceBoundary request (some time >after the initial findService)? Is the LoST Server expected to >identify the clients somehow and to store information what >client gets which location profile? When the LoST server creates the reference for later retrieval then it needs to store information, namely the respective location info elements, behind that reference. Ciao Hannes > >cheers >karl heinz > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 7 03:10:10 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 662E028C15D; Mon, 7 Jul 2008 03:10: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 B321928C153 for ; Mon, 7 Jul 2008 03:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.850, 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 7MRxOHHX9vun for ; Mon, 7 Jul 2008 03:10:06 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 73BE028C158 for ; Mon, 7 Jul 2008 03:10:06 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m67AA54m027914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 12:10:05 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m67AA4AU031585; Mon, 7 Jul 2008 12:10:05 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jul 2008 12:10:05 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jul 2008 12:10:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 13:10:02 +0300 Message-ID: In-Reply-To: <000d01c8e015$c27fce70$90cb550a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments for draft-sun-ecrit-unsafe-areas-00 Thread-Index: AcjgCkfcxVYVbKaARKKSUm+wppBJogACqHVQAAEpJpA= References: <000d01c8e015$c27fce70$90cb550a@china.huawei.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Qian Sun" , "Karl Heinz Wolf" , "Hannes Tschofenig" X-OriginalArrivalTime: 07 Jul 2008 10:10:04.0076 (UTC) FILETIME=[9FDA7EC0:01C8E019] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16016.006 X-TM-AS-Result: No--23.793600-8.000000-31 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments for draft-sun-ecrit-unsafe-areas-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Correct, and this document also makes far more sense for me. >Thanks for comments! > >In another draft we use this way you suggested to find safe areas: >http://tools.ietf.org/html/draft-sun-ecrit-shelter-service-00 > >Regards, >Qian >> -----Original Message----- >> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >> Sent: Monday, July 07, 2008 4:20 PM >> To: Hannes Tschofenig >> Cc: Qian Sun; ecrit@ietf.org >> Subject: Re: [Ecrit] Comments for draft-sun-ecrit-unsafe-areas-00 >> >> Hi, >> >> I also read the draft, and like Hannes, my first thought was about a >> separate service URN for this propose. >> >> One additional comment: >> When the unsafe-Information is included to the Mapping >Information of >> a particular PSAP, there could be a problem when a PSAP is >responsible >> for a large area. Assuming a police PSAP is responsible for a whole >> federal state, there may be hundreds of unsafe areas inside >- and most >> of them will be far away from my current location. So it >could be more >> interesting to query for all unsafe-areas within a radius of 5 km, >> regardless of the service boundary of a particular PSAP. >> >> cheers >> karl heinz >> >> On Fri, Jul 4, 2008 at 7:25 PM, Hannes Tschofenig >> wrote: >> > Hi Qian, >> > >> > thanks for the document. Interesting usage of LoST. >> > >> > A few quick comments: >> > >> > * I wonder whether it wouldn't be better to define some >new service >> > URNs for the usage of these "unsafe" areas instead of >adding a new attribute. >> > The reason for this is that the existing service URNs are somewhat >> > difficult to use in this context. For example, what does >it mean to >> > have the unsafe attribute included in the request when the >> > "urn:service:sos.poison" URN is used? New URNs are being proposed, >> > such as those in >> > >> >http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.t >> xt, >> > that make the semantic even more difficult to interpret. >> > >> > * Would be useful to include an element in the reponse to point to >> > more detailed information, such as a URL to a webpage? >> > >> > * Deployment: Who do you think would want to run such a service? >> > Would this be something the PSAP operator would want todo? Tourism >> > office? Police departments? (I am trying to figure out >where to get >> > some feedback from.) >> > >> > How often do you think the "service boundaries" of these unsafe >> > areas change? (Keep constant for years vs. change every day) >> > >> > Ciao >> > Hannes >> > >> > >> > >> > Qian Sun wrote: >> >> >> >> Hi, All >> >> >> >> I just submitted a new draft, it can be found here: >> >> >http://www.ietf.org/internet-drafts/draft-sun-ecrit-unsafe-areas-00.txt >> >> Filename: draft-sun-ecrit-unsafe-areas >> >> Revision: 00 >> >> Title: Specifying Unsafe Areas in LoST Service Boundary >> >> Creation_date: 2008-07-01 >> >> WG ID: Independent Submission >> >> Number_of_pages: 8 >> >> >> >> Abstract: >> >> This document describes how to specify unsafe areas in LoST for >> >> emergency services, such as police, mountain, marine and fire. >> >> >> >> Your comments are welcome! >> >> >> >> Thanks! >> >> Qian >> >> >> >> _______________________________________________ >> >> Ecrit mailing 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 Jul 7 03:24:00 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B7F028C16D; Mon, 7 Jul 2008 03:24: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 3375328C16D for ; Mon, 7 Jul 2008 03:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.586 X-Spam-Level: X-Spam-Status: No, score=-0.586 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FAKE_REPLY_C=2.012, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqRdHr6jcnSP for ; Mon, 7 Jul 2008 03:23:57 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 252CD28C12E for ; Mon, 7 Jul 2008 03:23:57 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3M00FAJSPR2D@szxga01-in.huawei.com> for ecrit@ietf.org; Mon, 07 Jul 2008 18:20:15 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3M00E5MSPR8V@szxga01-in.huawei.com> for ecrit@ietf.org; Mon, 07 Jul 2008 18:20:15 +0800 (CST) Received: from r00125280 ([10.85.202.219]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K3M00HZOSPQWF@szxml03-in.huawei.com> for ecrit@ietf.org; Mon, 07 Jul 2008 18:20:14 +0800 (CST) Date: Mon, 07 Jul 2008 18:20:14 +0800 From: Robins George To: Hannes Tschofenig Message-id: <5F0E3E60C6A24AFC9E85BAEBC70A9D9C@china.huawei.com> Organization: Huawei Tech MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-Priority: 3 X-MSMail-priority: Normal Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments for draft-robins-ecrit-sub-services-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Robins George List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0172926436==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0172926436== Content-type: multipart/alternative; boundary="Boundary_(ID_Gj66oXHoJRbpZrTJ7uYapQ)" This is a multi-part message in MIME format. --Boundary_(ID_Gj66oXHoJRbpZrTJ7uYapQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thanks Hannes for your comments. > Hi Robins, > Hi Qian, > > thanks for submitting this document. > > I have two questions/comments for your draft. > > * There is a List Services query in the LoST > specification that allows you to list the services of a LoST server > (see Section 10 of LoST). Is this functionality insufficient for your > purpose. In the given section, it says about finding the list of services supported by a LoST server. this draft says the list of sub services supported by the particular instance of a service. > * In your document you suggest to define new URNs that allow > further differentiation between the type of service a PSAP might provide. > You indicate > > urn:service:sos.police.terrorist > urn:service:sos.police.arson > urn:service:sos.police.robbery > > as sub-services for urn:service:sos.police. > > Did you have a chance to talk to PSAP operators whether they > believe this functionality is something they would like to expose to the > outside world? > they would like to expose to the outside world. > When do you expect the user to indicate this type of detail (since > there is a user-interface issue associated with this aspect)? we can indicate the type detail in the SIP invite, INVITE sip:nypd@example.gov SIP/2.0 To: urn:service:sos.police.robbery >I could imagine that you could quickly turn the person >that reports certain crime into a detective when you, for example, >allow the following information to be differentiated: > > urn:service:sos.police.robbery > urn:service:sos.police.homicide > urn:service:sos.police.homicide.aggravated-assault > urn:service:sos.police.homicide.manslaughter > urn:service:sos.police.homicide.manslaughter.avunculicide > urn:service:sos.police.homicide.manslaughter.democide > urn:service:sos.police.homicide.manslaughter.familicide > urn:service:sos.police.homicide.manslaughter.femicide > urn:service:sos.police.homicide.manslaughter.filicide > urn:service:sos.police.homicide.manslaughter.fratricide > urn:service:sos.police.homicide.manslaughter.gendercide > urn:service:sos.police.homicide.manslaughter.genocide > urn:service:sos.police.homicide.manslaughter.infanticide > urn:service:sos.police.homicide.manslaughter.mariticide > urn:service:sos.police.homicide.manslaughter.matricide > urn:service:sos.police.homicide.manslaughter.neonaticide > urn:service:sos.police.homicide.manslaughter.parricide > urn:service:sos.police.homicide.manslaughter.patricide > urn:service:sos.police.homicide.manslaughter.regicide > urn:service:sos.police.homicide.manslaughter.sororicide > urn:service:sos.police.homicide.manslaughter.suicide > urn:service:sos.police.homicide.manslaughter.tyrannicide > urn:service:sos.police.homicide.manslaughter.uxoricide > urn:service:sos.police.homicide.murder > urn:service:sos.police.homicide.murder.assassination > urn:service:sos.police.homicide.murder.child-murder > urn:service:sos.police.homicide.murder.consensual-homicide > urn:service:sos.police.homicide.murder.contract-killing > urn:service:sos.police.homicide.murder.honour-killing > urn:service:sos.police.homicide.murder.lust-murder > urn:service:sos.police.homicide.murder.lynching > urn:service:sos.police.homicide.murder.mass-murder > urn:service:sos.police.homicide.murder.murder-suicide > urn:service:sos.police.homicide.murder.proxy-murder > urn:service:sos.police.homicide.murder.ritual-murder > urn:service:sos.police.homicide.murder.serial-killer > urn:service:sos.police.homicide.murder.spree-killer > urn:service:sos.police.homicide.murder.torture-murder > > I guess you get the point. I am unsure where to stop with the types > of sub-services and the ability of the person to know all these > different things. we could list only one level of subservices, implying support for all sub categories. For example consider the crime classifications which came from FBI. Arson Criminal sexual assault Gambling Homicide Interfere with public officer Kidnapping Motor vehicle theft Narcotics Prostitution Public indecency Robbery Theft Traffic accident Weapons violation ...... > Needless to say that there are persons other than Thomas Mueller > and Sherlock Homes out there... > classification could be based on user point of view, so that they can understand very easily. and I suspect most users don't want to become experts in crime classification. Regards, Robins > > Ciao > Hannes > > -------- Original Message -------- > Subject: I-D Action:draft-robins-ecrit-sub-services-00.txt > Date: Wed, 2 Jul 2008 20:15:01 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > Title : Location-to-Service Translation Protocol (LoST) > Sub-Services > Author(s) : R. George, Q. Sun > Filename : draft-robins-ecrit-sub-services-00.txt > Pages : 8 > Date : 2008-07-02 > > This document describes, how a LoST client can ask LoST server for > the list of sub services that it supports, and to incorporate > additional information about the service provider in response. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-robins-ecrit-sub-services- > 00.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. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > --Boundary_(ID_Gj66oXHoJRbpZrTJ7uYapQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
 
Thanks Hannes for your comments.


> Hi Robins,
> Hi Qian,
>
> thanks for submitting this document.
>
> I have two questions/comments for your draft.
>
> * There is a List Services query <listServices> in the LoST
> specification that allows you to list the services of a LoST server
> (see Section 10 of LoST). Is this functionality insufficient for your
> purpose.


In the given section, it says about finding the list of services
supported by a LoST server.

this draft says the list of sub services supported
by the particular instance of a service.

> * In your document you suggest to define new URNs that allow
> further differentiation between the type of service a PSAP might provide.
> You indicate
>
>              urn:service:sos.police.terrorist
>              urn:service:sos.police.arson
>              urn:service:sos.police.robbery
>
> as sub-services for urn:service:sos.police.
>
> Did you have a chance to talk to PSAP operators whether they
> believe this functionality is something they would like to expose to the
> outside  world?
>

they would like to expose to the outside world.

> When do you expect the user to indicate this type of detail (since
> there is a user-interface issue associated with this aspect)?

we can indicate the type detail in the SIP invite,

INVITE sip:nypd@example.gov SIP/2.0
To: urn:service:sos.police.robbery

>I could  imagine that you could quickly turn the person
>that reports certain crime into a detective when you, for example,
>allow the following information to be differentiated:
>
> urn:service:sos.police.robbery
> urn:service:sos.police.homicide
> urn:service:sos.police.homicide.aggravated-assault
> urn:service:sos.police.homicide.manslaughter
> urn:service:sos.police.homicide.manslaughter.avunculicide
> urn:service:sos.police.homicide.manslaughter.democide
> urn:service:sos.police.homicide.manslaughter.familicide
> urn:service:sos.police.homicide.manslaughter.femicide
> urn:service:sos.police.homicide.manslaughter.filicide
> urn:service:sos.police.homicide.manslaughter.fratricide
> urn:service:sos.police.homicide.manslaughter.gendercide
> urn:service:sos.police.homicide.manslaughter.genocide
> urn:service:sos.police.homicide.manslaughter.infanticide
> urn:service:sos.police.homicide.manslaughter.mariticide
> urn:service:sos.police.homicide.manslaughter.matricide
> urn:service:sos.police.homicide.manslaughter.neonaticide
> urn:service:sos.police.homicide.manslaughter.parricide
> urn:service:sos.police.homicide.manslaughter.patricide
> urn:service:sos.police.homicide.manslaughter.regicide
> urn:service:sos.police.homicide.manslaughter.sororicide
> urn:service:sos.police.homicide.manslaughter.suicide
> urn:service:sos.police.homicide.manslaughter.tyrannicide
> urn:service:sos.police.homicide.manslaughter.uxoricide
> urn:service:sos.police.homicide.murder
> urn:service:sos.police.homicide.murder.assassination
> urn:service:sos.police.homicide.murder.child-murder
> urn:service:sos.police.homicide.murder.consensual-homicide
> urn:service:sos.police.homicide.murder.contract-killing
> urn:service:sos.police.homicide.murder.honour-killing
> urn:service:sos.police.homicide.murder.lust-murder
> urn:service:sos.police.homicide.murder.lynching
> urn:service:sos.police.homicide.murder.mass-murder
> urn:service:sos.police.homicide.murder.murder-suicide
> urn:service:sos.police.homicide.murder.proxy-murder
> urn:service:sos.police.homicide.murder.ritual-murder
> urn:service:sos.police.homicide.murder.serial-killer
> urn:service:sos.police.homicide.murder.spree-killer
> urn:service:sos.police.homicide.murder.torture-murder
>
> I guess you get the point. I am unsure where to stop with the types
> of sub-services and the ability of the person to know all these
> different things.

we could list only one level of subservices,
implying support for all sub categories.
For example consider the crime classifications
which came from FBI.

Arson
Criminal sexual assault
Gambling
Homicide
Interfere with public officer
Kidnapping
Motor vehicle theft
Narcotics
Prostitution
Public indecency
Robbery
Theft
Traffic accident
Weapons violation

......


> Needless to say that there are persons other than Thomas Mueller
> and Sherlock Homes out there...
>

classification could be based on user point of view,
so that they can understand very easily.
and I suspect most users don't
want to become experts in crime classification.

Regards,
Robins


>
> Ciao
> Hannes
>
> -------- Original Message --------
> Subject:  I-D Action:draft-robins-ecrit-sub-services-00.txt
> Date:  Wed, 2 Jul 2008 20:15:01 -0700 (PDT)
> From:  Internet-Drafts@ietf.org
> Reply-To:  internet-drafts@ietf.org
> To:  i-d-announce@ietf.org
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  Title           : Location-to-Service Translation Protocol (LoST)
> Sub-Services
>  Author(s)       : R. George, Q. Sun
>  Filename        : draft-robins-ecrit-sub-services-00.txt
>  Pages           : 8
>  Date            : 2008-07-02
>
> This document describes, how a LoST client can ask LoST server for
> the list of sub services that it supports, and to incorporate
> additional information about the service provider in response.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-robins-ecrit-sub-services-
> 00.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.
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>

 

--Boundary_(ID_Gj66oXHoJRbpZrTJ7uYapQ)-- --===============0172926436== 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 --===============0172926436==-- From ecrit-bounces@ietf.org Mon Jul 7 03:30:14 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F47928C191; Mon, 7 Jul 2008 03:30: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 8955428C189 for ; Mon, 7 Jul 2008 03:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 PFN4TYCyotvM for ; Mon, 7 Jul 2008 03:30:12 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by core3.amsl.com (Postfix) with ESMTP id BB97928C191 for ; Mon, 7 Jul 2008 03:30:11 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id y36so1021414ugd.46 for ; Mon, 07 Jul 2008 03:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=7j51WGCj7+tPx9Wa+FEFquhEhmyP87QbFU9mkOfwkdo=; b=Mylq3xLBmqMHstB/kdSgQAz/I7rF1U1yUJDDQIaMtfJH6kTyi3Lc55cxo4ycta3Mp8 6RrMBYA5E58PvBXTSi4Ni2wkOQu2l0m+P3rropybEfxnNU6FwPZq5Av8yi+Qy0KxEVPo UA7Jw1mXINUSrScAY1ICoYGGlPkN4ORxOXymk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=QQaiGU1Q9fVF4GbLncNd3HEuGG514hOtZjic3Ns2UWWqLoASC97FO/h8mXNvIQL3Xn GB4ZbgoUEJwwd8ZHlemZlMxjyonDQZTh/1q6/ljwGZTzbdaYsB/hjdasQJe3kvL6GSs8 f9bL4XxB+Q9ZdjTsPxoXdUf2CP94nClNo/SXw= Received: by 10.66.220.12 with SMTP id s12mr4361769ugg.5.1215426616817; Mon, 07 Jul 2008 03:30:16 -0700 (PDT) Received: by 10.67.30.1 with HTTP; Mon, 7 Jul 2008 03:30:16 -0700 (PDT) Message-ID: Date: Mon, 7 Jul 2008 12:30:16 +0200 From: "Karl Heinz Wolf" To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <20080528194502.7D0D03A6A7A@core3.amsl.com> <486FCA24.8000608@gmx.net> Cc: ecrit@ietf.org Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-lost-10.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Mon, Jul 7, 2008 at 12:08 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> >>but how should the LoST server know what profile to return >>when a client does a getServiceBoundary request (some time >>after the initial findService)? Is the LoST Server expected to >>identify the clients somehow and to store information what >>client gets which location profile? > > When the LoST server creates the reference for later retrieval then it > needs to store information, namely the respective location info > elements, behind that reference. > the reference is the "key" in LoST, isn't it? so the assumption is that there is a seperate key for the civic, geodetic and for civic+geodetic location profile (and for every possible future combination of new profiles) for every service boundary? I'm asking again because I couldn't find any information on this in the draft. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 7 09:04:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6641C3A685E; Mon, 7 Jul 2008 09:04: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 72C7D3A65A6 for ; Mon, 7 Jul 2008 09:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrwMGhdKZF9U for ; Mon, 7 Jul 2008 09:04:19 -0700 (PDT) Received: from mail150.messagelabs.com (mail150.messagelabs.com [85.158.136.115]) by core3.amsl.com (Postfix) with ESMTP id D001C3A6AAD for ; Mon, 7 Jul 2008 09:04:16 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-12.tower-150.messagelabs.com!1215446657!12438044!4 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [206.47.0.168] Received: (qmail 29213 invoked from network); 7 Jul 2008 16:04:21 -0000 Received: from dm1c8g.bell.ca (HELO TLS.Exchange.bell.ca) (206.47.0.168) by server-12.tower-150.messagelabs.com with RC4-SHA encrypted SMTP; 7 Jul 2008 16:04:21 -0000 Received: from hub02-wyn.bell.corp.bce.ca (142.182.199.50) by dm1c8g.exchange1.bell.ca (198.235.102.109) with Microsoft SMTP Server id 8.1.278.0; Mon, 7 Jul 2008 12:04:13 -0400 Received: from toroondc550.bell.corp.bce.ca (142.182.84.162) by hub02-wyn.bell.corp.bce.ca (142.182.199.50) with Microsoft SMTP Server id 8.1.278.0; Mon, 7 Jul 2008 12:04:08 -0400 Received: from toroondc254.bell.corp.bce.ca ([142.182.4.53]) by toroondc550.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jul 2008 12:04:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 12:04:07 -0400 Message-ID: <2DE9A51895931C4CBCAEFA9306AE480E84883E@toroondc254.bell.corp.bce.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PSAP Call Control features Thread-Index: AcjgSxXfaS0J9IvSQMCPlOTJCvHOsg== From: To: X-OriginalArrivalTime: 07 Jul 2008 16:04:08.0451 (UTC) FILETIME=[167CDD30:01C8E04B] Cc: nena-i2_5@listserv.neustar.biz Subject: [Ecrit] PSAP Call Control features X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 ECRIT, NENA has been working on mechanisms to provide PSAP control over emergency calls. This is the first of two posts that NENA is submitting which targets the "Switch-hook Status" and "Ringback" features. A distinct post targeting "emergency call termination" will be submitted separately. These kinds of controls are implemented (and sometimes mandated) in some existing emergency call systems and NENA is desirous of maintaining current capability as we move to new IP-based systems. It is also NENA's desire that such mechanisms be implementable in migratory environments such as i2 for forward-compatibility purposes. Here are short descriptions of the features as currently defined in the PSTN: Switch-hook Status (SHS): When the emergency call is established between the caller and the PSAP, changes in the "line" state (on/off hook) are signalled to the PSAP through a special audible tone. Ringback (RB): During an established emergency call, the PSAP can re-invite a caller that has gone on-hook by invoking RB which triggers ringing at the callers' end. If the caller is still off-hook but do not react to the PSAP attendant commands, invoking RB will supply a special tone (usually ROH) towards the caller. Currently, -framework (v.05) and -phonebcp (v.04) acknowledge that a caller cannot terminate an active emergency call (section 12 of the documents). However, in order to support the other features, additional signaling may be required beyond the "don't send a BYE" language in the current -phonebcp. All mechanisms being discussed within NENA utilize existing capabilities defined in the SIP suite; only changes in behaviour are sought. Please find a short description below: SHS: In addition to not sending a BYE when a caller is trying to terminate the call, the endpoint sends a re-INVITE with SDP=inactive. The PSAP interprets this action as an on-hook state at the caller's device. If the caller comes back online, the endpoint sends a re-INVITE with SDP=sendrecv. The PSAP interprets this action as an off-hook state at the caller's device and can resume the conversation. On-hook RB: the PSAP issues a re-INVITE with Alert-Info= towards the caller's endpoint. Off-hook RB: The PSAP supplies a ROH tone in-band of the media path. The following changes are submitted for your consideration: -framework: ========= At the end of section 2: ------------------------------- Further, the following capabilities may be required at the PSAP: o A PSAP may require to be notified of a change in state (aka on/off hook) of the caller's device so it can react accordingly. o The PSAP may have the ability to withhold an active emergency communication. o Once an emergency call has been initially setup, the PSAP attendant may choose to re-invite a caller into a conversation through ringback independently of the caller's device's state (on/off hook). Changes to section 12: ------------------------------- Change the section title to: Call Termination and call control [a new section specific to call control could be considered] Add the following: A PSAP may have the capability to re-invite a caller into conversation through the ringback feature. Ringback can be invoked while the caller's device is in an on-hook state by supplying a ringing tone to the caller's device. Ringback can also be invoked while the caller's device is still off-hook by supplying a special audible tone (usually ROH) to the caller's device. It is desirable to signal changes in the caller's device's state to the PSAP so it can react accordingly. By allowing this, the PSAP may choose to hold the call, invoke ringback or dispose of the call at its discretion. -phonebcp: ========= Appendix A [I will leave to the group to determine where they best fit in the body of the document if those get acceptance] A.1 Change the ED-65 as follows: ED-65 UACs with an active emergency call (i.e. SIP Dialog) MUST NOT generate a BYE request (or equivalent for other non-SIP signaling). The PSAP must be the only entity that can terminate a call. If the user "hangs up" an emergency call, the device MUST alert the PSAP by putting the media on hold (through a re-INVITE with sdp=inactive), and if the user responds by attempting to pick up the call, the device MUST reconnect the caller to the PSAP. Add the following requirement: ED-84 A PSAP UAC SHALL invoke Ringback within an existing emergency call by sending a re-INVITE towards the caller. If the caller's UAC is in an on-hook state, the re-INVITE MUST include a ringing URI in the Alert-Info header. If the caller's UAC is in an off-hook state, a special tone (usually ROH) MUST be supplied inband of the media. Any feedback would be greatly appreciated. Note that the NENA WG is copied on this post. Please keep this mail address CC'ed so the group can follow the discussions. Thanks, Guy Caron On behalf of NENA _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 7 11:46:37 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA4F33A69D1; Mon, 7 Jul 2008 11:46: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 CA5063A68DF for ; Mon, 7 Jul 2008 11:46:36 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfN7lZ0vZLLI for ; Mon, 7 Jul 2008 11:46:35 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 7790D3A67E3 for ; Mon, 7 Jul 2008 11:46:34 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KFvjL-0003GZ-Oi; Mon, 07 Jul 2008 13:46:33 -0500 From: "Brian Rosen" To: "'Robins George'" , "'Hannes Tschofenig'" References: <5F0E3E60C6A24AFC9E85BAEBC70A9D9C@china.huawei.com> Date: Mon, 7 Jul 2008 14:46:33 -0400 Message-ID: <081901c8e061$ca435900$4101a8c0@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: AcjgG5ZGCQhu7s+kQ1KSI6tP0g26PQARW9Sg In-Reply-To: <5F0E3E60C6A24AFC9E85BAEBC70A9D9C@china.huawei.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: Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments for draft-robins-ecrit-sub-services-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0687424566==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0687424566== Content-Type: multipart/alternative; boundary="----=_NextPart_000_081A_01C8E040.4331B900" This is a multi-part message in MIME format. ------=_NextPart_000_081A_01C8E040.4331B900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The only reason to have separate services (sub services) and thus separate service URNs if it is possible that calls to these services would be routed differently. I suspect that this is not the case here. I think you are trying to use the service URN to allow the caller to start classifying the call so that dispatch of the appropriate resources is optimized. If this is indeed your intention, then we should use a different mechanism. In the jurisdictions with which I am familiar, all police calls go to the same place initially. Based on what the call taker gleans from the caller, they may send the call to one of several entities for further handling. Call classification is one of the tasks that the call taker does. If the caller could supply information that began the classification process, that might be useful. In North America, any such self-classification would not be considered definitive, and would always be verified. Brian _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Robins George Sent: Monday, July 07, 2008 6:20 AM To: Hannes Tschofenig Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments for draft-robins-ecrit-sub-services-00.txt Thanks Hannes for your comments. > Hi Robins, > Hi Qian, > > thanks for submitting this document. > > I have two questions/comments for your draft. > > * There is a List Services query in the LoST > specification that allows you to list the services of a LoST server > (see Section 10 of LoST). Is this functionality insufficient for your > purpose. In the given section, it says about finding the list of services supported by a LoST server. this draft says the list of sub services supported by the particular instance of a service. > * In your document you suggest to define new URNs that allow > further differentiation between the type of service a PSAP might provide. > You indicate > > urn:service:sos.police.terrorist > urn:service:sos.police.arson > urn:service:sos.police.robbery > > as sub-services for urn:service:sos.police. > > Did you have a chance to talk to PSAP operators whether they > believe this functionality is something they would like to expose to the > outside world? > they would like to expose to the outside world. > When do you expect the user to indicate this type of detail (since > there is a user-interface issue associated with this aspect)? we can indicate the type detail in the SIP invite, INVITE sip:nypd@example.gov SIP/2.0 To: urn:service:sos.police.robbery >I could imagine that you could quickly turn the person >that reports certain crime into a detective when you, for example, >allow the following information to be differentiated: > > urn:service:sos.police.robbery > urn:service:sos.police.homicide > urn:service:sos.police.homicide.aggravated-assault > urn:service:sos.police.homicide.manslaughter > urn:service:sos.police.homicide.manslaughter.avunculicide > urn:service:sos.police.homicide.manslaughter.democide > urn:service:sos.police.homicide.manslaughter.familicide > urn:service:sos.police.homicide.manslaughter.femicide > urn:service:sos.police.homicide.manslaughter.filicide > urn:service:sos.police.homicide.manslaughter.fratricide > urn:service:sos.police.homicide.manslaughter.gendercide > urn:service:sos.police.homicide.manslaughter.genocide > urn:service:sos.police.homicide.manslaughter.infanticide > urn:service:sos.police.homicide.manslaughter.mariticide > urn:service:sos.police.homicide.manslaughter.matricide > urn:service:sos.police.homicide.manslaughter.neonaticide > urn:service:sos.police.homicide.manslaughter.parricide > urn:service:sos.police.homicide.manslaughter.patricide > urn:service:sos.police.homicide.manslaughter.regicide > urn:service:sos.police.homicide.manslaughter.sororicide > urn:service:sos.police.homicide.manslaughter.suicide > urn:service:sos.police.homicide.manslaughter.tyrannicide > urn:service:sos.police.homicide.manslaughter.uxoricide > urn:service:sos.police.homicide.murder > urn:service:sos.police.homicide.murder.assassination > urn:service:sos.police.homicide.murder.child-murder > urn:service:sos.police.homicide.murder.consensual-homicide > urn:service:sos.police.homicide.murder.contract-killing > urn:service:sos.police.homicide.murder.honour-killing > urn:service:sos.police.homicide.murder.lust-murder > urn:service:sos.police.homicide.murder.lynching > urn:service:sos.police.homicide.murder.mass-murder > urn:service:sos.police.homicide.murder.murder-suicide > urn:service:sos.police.homicide.murder.proxy-murder > urn:service:sos.police.homicide.murder.ritual-murder > urn:service:sos.police.homicide.murder.serial-killer > urn:service:sos.police.homicide.murder.spree-killer > urn:service:sos.police.homicide.murder.torture-murder > > I guess you get the point. I am unsure where to stop with the types > of sub-services and the ability of the person to know all these > different things. we could list only one level of subservices, implying support for all sub categories. For example consider the crime classifications which came from FBI. Arson Criminal sexual assault Gambling Homicide Interfere with public officer Kidnapping Motor vehicle theft Narcotics Prostitution Public indecency Robbery Theft Traffic accident Weapons violation ...... > Needless to say that there are persons other than Thomas Mueller > and Sherlock Homes out there... > classification could be based on user point of view, so that they can understand very easily. and I suspect most users don't want to become experts in crime classification. Regards, Robins > > Ciao > Hannes > > -------- Original Message -------- > Subject: I-D Action:draft-robins-ecrit-sub-services-00.txt > Date: Wed, 2 Jul 2008 20:15:01 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > Title : Location-to-Service Translation Protocol (LoST) > Sub-Services > Author(s) : R. George, Q. Sun > Filename : draft-robins-ecrit-sub-services-00.txt > Pages : 8 > Date : 2008-07-02 > > This document describes, how a LoST client can ask LoST server for > the list of sub services that it supports, and to incorporate > additional information about the service provider in response. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-robins-ecrit-sub-services- > 00.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. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > ------=_NextPart_000_081A_01C8E040.4331B900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The only reason to have separate = services (sub services) and thus separate service URNs if it is possible that = calls to these services would be routed differently.  I suspect that this is = not the case here.  I think you are trying to use the service URN to allow = the caller to start classifying the call so that dispatch of the appropriate = resources is optimized.  If this is indeed your intention, then we should use a = different mechanism.

 

In the jurisdictions with which I = am familiar, all police calls go to the same place initially.  Based = on what the call taker gleans from the caller, they may send the call to one of = several entities for further handling.  Call classification is one of the = tasks that the call taker does.  If the caller could supply information that = began the classification process, that might be useful.  In North America, any such self-classification would not be = considered definitive, and would always be verified. 

 

Brian

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Robins George
Sent: Monday, July 07, = 2008 6:20 AM
To: Hannes Tschofenig
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] = Comments for draft-robins-ecrit-sub-services-00.txt

 

 

Thanks Hannes for your comments.


> Hi Robins,
> Hi Qian,
>
> thanks for submitting this document.
>
> I have two questions/comments for your draft.
>
> * There is a List Services query <listServices> in the LoST =
> specification that allows you to list the services of a LoST server =
> (see Section 10 of LoST). Is this functionality insufficient for = your
> purpose.


In the given section, it says about finding the list of services
supported by a LoST server.

this draft says the list of sub services supported
by the particular instance of a service.

> * In your document you suggest to define new URNs that allow
> further differentiation between the type of service a PSAP might = provide.
> You indicate
>
>           &nb= sp;  urn:service:sos.police.terrorist
>           &nb= sp;  urn:service:sos.police.arson
>           &nb= sp;  urn:service:sos.police.robbery
>
> as sub-services for urn:service:sos.police.
>
> Did you have a chance to talk to PSAP operators whether they
> believe this functionality is something they would like to expose = to the
> outside  world?
>

they would like to expose to the outside world.

> When do you expect the user to indicate this type of detail (since
> there is a user-interface issue associated with this aspect)? =

we can indicate the type detail in the SIP invite,

INVITE sip:nypd@example.gov SIP/2.0
To: urn:service:sos.police.robbery

>I could  imagine that you could quickly turn the person
>that reports certain crime into a detective when you, for = example,
>allow the following information to be differentiated:
>
> urn:service:sos.police.robbery
> urn:service:sos.police.homicide
> urn:service:sos.police.homicide.aggravated-assault
> urn:service:sos.police.homicide.manslaughter
> urn:service:sos.police.homicide.manslaughter.avunculicide
> urn:service:sos.police.homicide.manslaughter.democide
> urn:service:sos.police.homicide.manslaughter.familicide
> urn:service:sos.police.homicide.manslaughter.femicide
> urn:service:sos.police.homicide.manslaughter.filicide
> urn:service:sos.police.homicide.manslaughter.fratricide
> urn:service:sos.police.homicide.manslaughter.gendercide
> urn:service:sos.police.homicide.manslaughter.genocide
> urn:service:sos.police.homicide.manslaughter.infanticide
> urn:service:sos.police.homicide.manslaughter.mariticide
> urn:service:sos.police.homicide.manslaughter.matricide
> urn:service:sos.police.homicide.manslaughter.neonaticide
> urn:service:sos.police.homicide.manslaughter.parricide
> urn:service:sos.police.homicide.manslaughter.patricide
> urn:service:sos.police.homicide.manslaughter.regicide
> urn:service:sos.police.homicide.manslaughter.sororicide
> urn:service:sos.police.homicide.manslaughter.suicide
> urn:service:sos.police.homicide.manslaughter.tyrannicide
> urn:service:sos.police.homicide.manslaughter.uxoricide
> urn:service:sos.police.homicide.murder
> urn:service:sos.police.homicide.murder.assassination
> urn:service:sos.police.homicide.murder.child-murder
> urn:service:sos.police.homicide.murder.consensual-homicide
> urn:service:sos.police.homicide.murder.contract-killing
> urn:service:sos.police.homicide.murder.honour-killing
> urn:service:sos.police.homicide.murder.lust-murder
> urn:service:sos.police.homicide.murder.lynching
> urn:service:sos.police.homicide.murder.mass-murder
> urn:service:sos.police.homicide.murder.murder-suicide
> urn:service:sos.police.homicide.murder.proxy-murder
> urn:service:sos.police.homicide.murder.ritual-murder
> urn:service:sos.police.homicide.murder.serial-killer
> urn:service:sos.police.homicide.murder.spree-killer
> urn:service:sos.police.homicide.murder.torture-murder
>
> I guess you get the point. I am unsure where to stop with the types =
> of sub-services and the ability of the person to know all these =
> different things.

we could list only one level of subservices,
implying support for all sub categories.
For example consider the crime classifications
which came from FBI.

Arson
Criminal sexual assault
Gambling
Homicide
Interfere with public officer
Kidnapping
Motor vehicle theft
Narcotics
Prostitution
Public indecency
Robbery
Theft
Traffic accident
Weapons violation

......


> Needless to say that there are persons other than Thomas Mueller =
> and Sherlock Homes out there...
>

classification could be based on user point of view,
so that they can understand very easily.
and I suspect most users don't
want to become experts in crime = classification.

Regards,
Robins


>
> Ciao
> Hannes
>
> -------- Original Message --------
> Subject:  I-D = Action:draft-robins-ecrit-sub-services-00.txt
> Date:  Wed, 2 Jul 2008 20:15:01 -0700 (PDT)
> From:  Internet-Drafts@ietf.org
= > Reply-To:  internet-drafts@ietf.org
= > To:  i-d-announce@ietf.org
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts =
> directories.
> =  Title           = : Location-to-Service Translation Protocol (LoST)
> Sub-Services
>  Author(s)       : R. George, Q. = Sun
>  Filename        : draft-robins-ecrit-sub-services-00.txt
> =  Pages           = : 8
>  Date          &nb= sp; : 2008-07-02
>
> This document describes, how a LoST client can ask LoST server = for
> the list of sub services that it supports, and to incorporate
> additional information about the service provider in response.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-robins-ecrit-sub-services-
> 00.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.
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org= /mailman/listinfo/ecrit
>

 

------=_NextPart_000_081A_01C8E040.4331B900-- --===============0687424566== 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 --===============0687424566==-- From ecrit-bounces@ietf.org Mon Jul 7 12:31:44 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 408453A6983; Mon, 7 Jul 2008 12:31: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 5BC8D3A6AE3 for ; Mon, 7 Jul 2008 12:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LqCAtHyW3U5 for ; Mon, 7 Jul 2008 12:31:42 -0700 (PDT) Received: from mail140.messagelabs.com (mail140.messagelabs.com [85.158.137.83]) by core3.amsl.com (Postfix) with ESMTP id 3AC0C3A6983 for ; Mon, 7 Jul 2008 12:31:42 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-8.tower-140.messagelabs.com!1215459057!12445501!63 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [206.47.0.168] Received: (qmail 7420 invoked from network); 7 Jul 2008 19:31:47 -0000 Received: from dm1c8g.bell.ca (HELO TLS.Exchange.bell.ca) (206.47.0.168) by server-8.tower-140.messagelabs.com with RC4-SHA encrypted SMTP; 7 Jul 2008 19:31:47 -0000 Received: from hub02-wyn.bell.corp.bce.ca (142.182.199.50) by dm1c8g.exchange1.bell.ca (198.235.102.109) with Microsoft SMTP Server id 8.1.278.0; Mon, 7 Jul 2008 15:31:42 -0400 Received: from TOROONDC918.bell.corp.bce.ca (142.182.89.79) by hub02-wyn.bell.corp.bce.ca (142.182.199.50) with Microsoft SMTP Server id 8.1.278.0; Mon, 7 Jul 2008 15:31:38 -0400 Received: from toroondc254.bell.corp.bce.ca ([142.182.4.53]) by TOROONDC918.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jul 2008 15:31:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 15:31:37 -0400 Message-ID: <2DE9A51895931C4CBCAEFA9306AE480E8488A2@toroondc254.bell.corp.bce.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: emergency call termination Thread-Index: AcjgaBJx/LkkzLbHQVqCdOMjccnu3A== From: To: X-OriginalArrivalTime: 07 Jul 2008 19:31:38.0199 (UTC) FILETIME=[131DA670:01C8E068] Cc: nena-i2_5@listserv.neustar.biz Subject: [Ecrit] emergency call termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 ECRIT, NENA wishes to provide comments regarding "emergency call termination" behavior in -framework-05 and -phonebcp-04. The UA behavior currently defined disallows a UA engaged in an emergency communication to release the call and states that only the PSAP should be able to terminate an emergency call. NENA wishes to express that this behavior, while desired or mandated in certain jurisdictions, is undesirable in others. For example, the majority of the U.S. jurisdictions do not use this feature and prefer to allow the caller to release an emergency call. It is not NENA's intent to revert the current behavior in such a way that the caller has always the ability to release an emergency call. NENA would like however that this feature be made optional and controlled at the PSAP end. This would allow a roaming device to adjust its behavior according to the rules of the jurisdiction it is currently in. Thanks, Guy Caron On behalf of NENA _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 7 14:01:24 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A56483A6B4B; Mon, 7 Jul 2008 14:01: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 25E8D3A6B3C for ; Mon, 7 Jul 2008 14:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=0.780, 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 LPSFodykE-Yi for ; Mon, 7 Jul 2008 14:01:23 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id A5F203A6B4B for ; Mon, 7 Jul 2008 14:00:52 -0700 (PDT) Received: (qmail invoked by alias); 07 Jul 2008 21:00:58 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp007) with SMTP; 07 Jul 2008 23:00:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/UWZJr8drUcdhrXmYw5Pf31LM4xR1azeHGkUsqlh BVLmyLt0gFurxT Message-ID: <4872840A.6020808@gmx.net> Date: Tue, 08 Jul 2008 00:00:58 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: 'ECRIT' X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 Subject: [Ecrit] ECRIT Status Update: July 2008 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org * draft-ietf-ecrit-lost, draft-ietf-ecrit-dhc-lost-discovery These two documents are in the RFC Editor queue. * draft-ietf-ecrit-mapping-arch This document is waiting for an update by Henning, I believe. I have sent a mail to Jon and Henning asking about the status. * draft-ietf-ecrit-framework and draft-ietf-ecrit-phonebcp The received comments are currently being incorporated. It will be necessary to determine whether the feedback has been reflected appropriately. The idea is to finish this document soon. A first WGLC has already been started. The plan would be to send these two documents to the IESG in 2 months. * draft-ietf-ecrit-location-hiding-req, draft-ietf-ecrit-specifying-holes These two documents became working group items recently but they are sufficiently complete so that I plan to initiate a WGLC. * draft-schulzrinne-ecrit-lost-sync I have asked Henning to re-submit his document as WG item. That will follow soon as well. * What's next? We have also received a couple of new documents and we have some older documents, such as the unauthenticated emergency services work. The overall question is going to be: What should we do in the group once we finished our main documents? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 7 14:10:08 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5218D28C245; Mon, 7 Jul 2008 14:10: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 A25ED28C23B for ; Mon, 7 Jul 2008 14:10:06 -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=[AWL=0.000, 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 Mg32ustG11SE for ; Mon, 7 Jul 2008 14:10:06 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id B718428C245 for ; Mon, 7 Jul 2008 14:10:05 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KFxyF-0002ml-Gj; Mon, 07 Jul 2008 16:10:03 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'ECRIT'" References: <4872840A.6020808@gmx.net> Date: Mon, 7 Jul 2008 17:10:07 -0400 Message-ID: <090b01c8e075$d7d95880$4101a8c0@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: AcjgdMLaylmEPJ3VT5yDyE/pIV57jgAAKQmg In-Reply-To: <4872840A.6020808@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: Subject: Re: [Ecrit] ECRIT Status Update: July 2008 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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's next? > > We have also received a couple of new documents and we have some older > documents, such as the unauthenticated emergency services work. > > The overall question is going to be: What should we do in the group once > we finished our main documents? I will have some small documents to submit once I get -framework and -phonebcp out. What I propose is that we go dormant until we get some deployment if the small stuff gets done quick. We then make a decision to close or recharter. Since some deployment should be late next year or so, I think dormancy for a cycle or two is better than dissolution and reconstitution. There is also the emergency alert issue, which we have said could be an expanded ecrit charter or a new wg. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 7 14:36:35 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9179A28C28F; Mon, 7 Jul 2008 14:36: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 5665928C270 for ; Mon, 7 Jul 2008 14:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 lodg2I+gULMx for ; Mon, 7 Jul 2008 14:36:33 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1F23F28C28F for ; Mon, 7 Jul 2008 14:35:47 -0700 (PDT) Received: (qmail invoked by alias); 07 Jul 2008 21:35:55 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp029) with SMTP; 07 Jul 2008 23:35:55 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/LJxoClqHL98+6B5pxPIJgW4jZMomuUjiLDqoKiW pT3jGkXuN2hMaq Message-ID: <48728C3B.1040809@gmx.net> Date: Tue, 08 Jul 2008 00:35:55 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: 'ECRIT' X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 Subject: [Ecrit] IETF#72 Agenda: Let's discuss it! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org For our main documents, as mentioned in my previous status update there isn't a lot to discuss anymore as they are getting finished. Even the new onces are approaching an end already. I will put Framework and Phone BCP on the agenda if there are unresolved issues that need to be addressed. I hope that there aren't any at that time. There might be some feedback regarding location hiding and the holes draft; but I don't really think so. We can briefly chat about Henning's LoST Sync document. We also have a couple of new documents, as everyone knows. Here are the docs I found: draft-barnes-ecrit-rough-loc draft-forte-ecrit-lost-extensions draft-forte-ecrit-service-classification draft-robins-ecrit-sub-services draft-rosen-ecrit-ecall draft-schulzrinne-ecrit-unauthenticated-access draft-sun-ecrit-shelter-service draft-sun-ecrit-unsafe-areas draft-tschofenig-ecrit-trustworthy-location draft-wolf-ecrit-lost-servicelistboundary draft-polk-ecrit-local-emergency-rph-namespace-02.txt ... maybe some early warning stuff could belong here as well. Is there something else you plan to submit but you missed the deadline or you are looking for help? To work on these documents within the group we have to re-charter and that's something we had planned already some time ago. So, in which direction would you like to group to go? Your opinion is highly appreciated. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 7 14:43:47 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FF3528C299; Mon, 7 Jul 2008 14:43: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 5743A28C299 for ; Mon, 7 Jul 2008 14:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.557, 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 GoDPAdPfb1YH for ; Mon, 7 Jul 2008 14:43:45 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5EEA428C24A for ; Mon, 7 Jul 2008 14:43:42 -0700 (PDT) Received: (qmail invoked by alias); 07 Jul 2008 21:43:49 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp067) with SMTP; 07 Jul 2008 23:43:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+baP4UuAib4GQrUDjBc2Sxb+cVFhHyWGlR0VkUqT qOZSsD1syxbE7c Message-ID: <48728E16.5010501@gmx.net> Date: Tue, 08 Jul 2008 00:43:50 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: 'ECRIT' X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 Subject: [Ecrit] WGLC on draft-ietf-ecrit-location-hiding-req-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, we would like to start the WGLC for the "Location Hiding: Problem Statement and Requirements" http://tools.ietf.org/html/draft-ietf-ecrit-location-hiding-req-00 document. Please have all comments in by August 1, 2008. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 7 14:43:54 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C24528C29C; Mon, 7 Jul 2008 14:43: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 EF25A28C24A for ; Mon, 7 Jul 2008 14:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=0.487, 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 r+zai0j4LRoQ for ; Mon, 7 Jul 2008 14:43:52 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0BD3528C29C for ; Mon, 7 Jul 2008 14:43:51 -0700 (PDT) Received: (qmail invoked by alias); 07 Jul 2008 21:43:58 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp062) with SMTP; 07 Jul 2008 23:43:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18GSX0UFasGZf/helDYnzse7TqqdmbOHiTz+f8YUz Jsbr4C5Se0UyAE Message-ID: <48728E1F.9010300@gmx.net> Date: Tue, 08 Jul 2008 00:43:59 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: 'ECRIT' X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 Subject: [Ecrit] WGLC on draft-ietf-ecrit-specifying-holes-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, we would like to start the WGLC for the "Specifying Holes in LoST Service Boundaries" http://tools.ietf.org/html/draft-ietf-ecrit-specifying-holes-00 document. Please have all comments in by August 1, 2008. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 7 16:38:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95973A6B7A; Mon, 7 Jul 2008 16:38: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 81F053A6847 for ; Mon, 7 Jul 2008 16:38:24 -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 hMxt2Cc-+xVM for ; Mon, 7 Jul 2008 16:38:23 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 9CF5F3A6B7A for ; Mon, 7 Jul 2008 16:38:23 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_07_07_18_53_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); Mon, 07 Jul 2008 18:53:33 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jul 2008 18:38:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 18:38:29 -0500 Message-ID: In-Reply-To: <48728E16.5010501@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] WGLC on draft-ietf-ecrit-location-hiding-req-00 Thread-Index: Acjgeo4ukxRXSO49Q364oCWdwzPbbQADTKRg References: <48728E16.5010501@gmx.net> From: "Thomson, Martin" To: "Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 07 Jul 2008 23:38:30.0647 (UTC) FILETIME=[9005D870:01C8E08A] Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-location-hiding-req-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 is quite straightforward, but I have a couple of minor comments. In S1.3, the following (untrue) statement is made: This document explores the architectural impact for the current architecture and lists requirements. The document doesn't do any exploration of architectural impacts. I know that there has been a lot of discussion on requirements like Req-C (VSP validation of emergency calls). I'm not going to debate whether or not this requirement exists, but I'd observe that this is a requirement that should probably exist outside of the context of this document. Given the ACL authorization model for LbyR dissemination [1], the VSP is not necessarily able to check that PSAP URIs are valid. There are other requirements that similarly would be better placed in a more general document. Of course, this is a non-comment, 'cause there isn't a better place to put this. Cheers, Martin [1] http://tools.ietf.org/html/draft-winterbottom-geopriv-deref-protocol > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Tuesday, 8 July 2008 7:44 AM > To: 'ECRIT' > Subject: [Ecrit] WGLC on draft-ietf-ecrit-location-hiding-req-00 > > Hi all, > > we would like to start the WGLC for the "Location Hiding: Problem > Statement and Requirements" > http://tools.ietf.org/html/draft-ietf-ecrit-location-hiding-req-00 > document. > > Please have all comments in by August 1, 2008. > > Ciao > Hannes & Marc > > _______________________________________________ > 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 Jul 7 16:45:52 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A323628C369; Mon, 7 Jul 2008 16:45:52 -0700 (PDT) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DC1F03A6B96; Mon, 7 Jul 2008 16:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080707234501.DC1F03A6B96@core3.amsl.com> Date: Mon, 7 Jul 2008 16:45:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-sync-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 : Synchronizing Location-to-Service Translation (LoST) Servers Author(s) : H. Schulzrinne Filename : draft-ietf-ecrit-lost-sync-00.txt Pages : 11 Date : 2008-07-07 The LoST (Location-to-Service Translation) protocol is used to map locations to service URLs. This document defines a set of LoST extensions that allow LoST servers to synchronize their lists of mappings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-00.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-sync-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-07164122.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 Tue Jul 8 02:27:27 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F87C3A69BC; Tue, 8 Jul 2008 02:27: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 4D59D3A6A5A for ; Tue, 8 Jul 2008 02:27:26 -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 6e1WFG9HlBEK for ; Tue, 8 Jul 2008 02:27:25 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id A13993A6997 for ; Tue, 8 Jul 2008 02:27:24 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3O00J81KX3FW@szxga02-in.huawei.com> for ecrit@ietf.org; Tue, 08 Jul 2008 17:27:03 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3O00JMZKX3FN@szxga02-in.huawei.com> for ecrit@ietf.org; Tue, 08 Jul 2008 17:27:03 +0800 (CST) Received: from s32328b ([10.85.203.144]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K3O00343KX2CR@szxml03-in.huawei.com> for ecrit@ietf.org; Tue, 08 Jul 2008 17:27:03 +0800 (CST) Date: Tue, 08 Jul 2008 17:27:02 +0800 From: Qian Sun To: ecrit@ietf.org Message-id: <001601c8e0dc$c7d59770$90cb550a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acjg3Mea94IhYbpBQ5SRXNQVLHmfRA== Subject: Re: [Ecrit] Comments for draft-sun-ecrit-unsafe-areas-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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, Hannes Thanks for your comments! Please see inline. > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Saturday, July 05, 2008 1:25 AM > To: Qian Sun > Cc: ecrit@ietf.org > Subject: Comments for draft-sun-ecrit-unsafe-areas-00 > > Hi Qian, > > thanks for the document. Interesting usage of LoST. > > A few quick comments: > > * I wonder whether it wouldn't be better to define some new service > URNs for the usage of these "unsafe" areas instead of adding a new attribute. > The reason for this is that the existing service URNs are somewhat > difficult to use in this context. For example, what does it mean to > have the unsafe attribute included in the request when the > "urn:service:sos.poison" URN is used? New URNs are being proposed, > such as those in > http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.t > xt, that make the semantic even more difficult to interpret. > Good point! Indeed, "unsafe" area is meaningless for some services. Maybe it's better to define some new service URNs for the usage of these "unsafe" areas instead of adding a new attribute. However, could we use "hotspotArea" attribute instead of "unsafeArea"? It means the service is frequently requested or provided in these areas. This is meaningful for most services. For example: For police service, these areas are the regions with high crime report. For restaurant service, these areas are the regions with a lot of popular restaurants. ...... Is this more general? > * Would be useful to include an element in the reponse to point to > more detailed information, such as a URL to a webpage? > Sure. > * Deployment: Who do you think would want to run such a service? Would > this be something the PSAP operator would want todo? Tourism office? > Police departments? (I am trying to figure out where to get some > feedback from.) > If we define a new service URN for unsafe area of crime, maybe police departments would want to run such a service. > How often do you think the "service boundaries" of these unsafe areas > change? (Keep constant for years vs. change every day) > It depends on the specific service. For police service, change every month might be appropriate (normally the police departments give a monthly crime report). For marine service, maybe it can keep constant for years (submerged rocks are fixed). Regards, Qian > Ciao > Hannes > > > > Qian Sun wrote: > > Hi, All > > > > I just submitted a new draft, it can be found here: > > http://www.ietf.org/internet-drafts/draft-sun-ecrit-unsafe-areas-00. > > txt > > > > Filename: draft-sun-ecrit-unsafe-areas > > Revision: 00 > > Title: Specifying Unsafe Areas in LoST Service Boundary > > Creation_date: 2008-07-01 > > WG ID: Independent Submission > > Number_of_pages: 8 > > > > Abstract: > > This document describes how to specify unsafe areas in LoST for > > emergency > services, such as police, mountain, marine and fire. > > > > Your comments are welcome! > > > > Thanks! > > Qian > > > > _______________________________________________ > > Ecrit mailing 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 Jul 8 02:27:29 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45F028C17E; Tue, 8 Jul 2008 02:27: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 1154C3A6997 for ; Tue, 8 Jul 2008 02:27:27 -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 JW8X7g6D3o3G for ; Tue, 8 Jul 2008 02:27:26 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id CD3943A69BC for ; Tue, 8 Jul 2008 02:27:25 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3M00MGYPTDEX@szxga02-in.huawei.com> for ecrit@ietf.org; Mon, 07 Jul 2008 17:17:37 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3M00DJ5PTDT7@szxga02-in.huawei.com> for ecrit@ietf.org; Mon, 07 Jul 2008 17:17:37 +0800 (CST) Received: from s32328b ([10.85.203.144]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K3M00H8IPTDWF@szxml03-in.huawei.com> for ecrit@ietf.org; Mon, 07 Jul 2008 17:17:37 +0800 (CST) Date: Mon, 07 Jul 2008 17:17:36 +0800 From: Qian Sun In-reply-to: <486E5CEC.9040200@gmx.net> To: 'Hannes Tschofenig' Message-id: <000601c8e012$4c192a90$90cb550a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acjd+uL/32uoHNONSP6lOHFBy8KuJwCFcpgg Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments for draft-sun-ecrit-unsafe-areas-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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, Hannes Thanks for your comments! Please see inline. > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Saturday, July 05, 2008 1:25 AM > To: Qian Sun > Cc: ecrit@ietf.org > Subject: Comments for draft-sun-ecrit-unsafe-areas-00 > > Hi Qian, > > thanks for the document. Interesting usage of LoST. > > A few quick comments: > > * I wonder whether it wouldn't be better to define some new service URNs > for the usage of these "unsafe" areas instead of adding a new attribute. > The reason for this is that the existing service URNs are somewhat > difficult to use in this context. For example, what does it mean to have > the unsafe attribute included in the request when the > "urn:service:sos.poison" URN is used? New URNs are being proposed, such > as those in > http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.txt, > that make the semantic even more difficult to interpret. > Good point! Indeed, "unsafe" area is meaningless for some services. Maybe it's better to define some new service URNs for the usage of these "unsafe" areas instead of adding a new attribute. However, could we use "hotspotArea" attribute instead of "unsafeArea"? It means the service is frequently requested or provided in these areas. This is meaningful for most services. For example: For police service, these areas are the regions with high crime report. For restaurant service, these areas are the regions with a lot of popular restaurants. ...... Is this more general? > * Would be useful to include an element in the reponse to point to more > detailed information, such as a URL to a webpage? > Sure. > * Deployment: Who do you think would want to run such a service? Would > this be something the PSAP operator would want todo? Tourism office? > Police departments? (I am trying to figure out where to get some > feedback from.) > If we define a new service URN for unsafe area of crime, maybe police departments would want to run such a service. > How often do you think the "service boundaries" of these unsafe areas > change? (Keep constant for years vs. change every day) > It depends on the specific service. For police service, change every month might be appropriate (normally the police departments give a monthly crime report). For marine service, maybe it can keep constant for years (submerged rocks are fixed). Regards, Qian > Ciao > Hannes > > > > Qian Sun wrote: > > Hi, All > > > > I just submitted a new draft, it can be found here: > > http://www.ietf.org/internet-drafts/draft-sun-ecrit-unsafe-areas-00.txt > > > > Filename: draft-sun-ecrit-unsafe-areas > > Revision: 00 > > Title: Specifying Unsafe Areas in LoST Service Boundary > > Creation_date: 2008-07-01 > > WG ID: Independent Submission > > Number_of_pages: 8 > > > > Abstract: > > This document describes how to specify unsafe areas in LoST for emergency > services, such as police, mountain, marine and fire. > > > > Your comments are welcome! > > > > Thanks! > > Qian > > > > _______________________________________________ > > Ecrit mailing 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 Jul 8 03:30:44 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04B673A6A65; Tue, 8 Jul 2008 03:30: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 3188B3A6A6C for ; Tue, 8 Jul 2008 03:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.166 X-Spam-Level: X-Spam-Status: No, score=-5.166 tagged_above=-999 required=5 tests=[AWL=1.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ri2VIt5An75h for ; Tue, 8 Jul 2008 03:30:42 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 16FC93A6A65 for ; Tue, 8 Jul 2008 03:30:41 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m68AUcKh014809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2008 12:30:38 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m68AUVrb029046; Tue, 8 Jul 2008 12:30:34 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jul 2008 12:30:32 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jul 2008 12:30:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 13:30:08 +0300 Message-ID: In-Reply-To: <090b01c8e075$d7d95880$4101a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT Status Update: July 2008 Thread-Index: AcjgdMLaylmEPJ3VT5yDyE/pIV57jgAAKQmgABv2CQA= References: <4872840A.6020808@gmx.net> <090b01c8e075$d7d95880$4101a8c0@cis.neustar.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Brian Rosen" , "Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 08 Jul 2008 10:30:31.0577 (UTC) FILETIME=[A5EA0890:01C8E0E5] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16018.006 X-TM-AS-Result: No--15.967000-8.000000-31 Subject: Re: [Ecrit] ECRIT Status Update: July 2008 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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, Thanks for the quick response. >> * What's next? >> >> We have also received a couple of new documents and we have >some older >> documents, such as the unauthenticated emergency services work. >> >> The overall question is going to be: What should we do in the group >> once we finished our main documents? >I will have some small documents to submit once I get >-framework and -phonebcp out. > >What I propose is that we go dormant until we get some >deployment if the small stuff gets done quick. We then make a >decision to close or recharter. >Since some deployment should be late next year or so, I think >dormancy for a cycle or two is better than dissolution and >reconstitution. By dormant you mean that we just should schedule a slot at IETF meetings. Some folks seem to have the idea of extending LoST beyond the emergency services usage -- you don't seem to be thrilled by that idea? >There is also the emergency alert issue, which we have said >could be an expanded ecrit charter or a new wg. Correct. Strictly speaking we don't need to wait to start that work. Ciao Hannes > >Brian > >_______________________________________________ >Ecrit mailing 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 Jul 8 03:31:46 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48EBE3A69BC; Tue, 8 Jul 2008 03:31: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 83C6C3A69BC for ; Tue, 8 Jul 2008 03:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.524 X-Spam-Level: X-Spam-Status: No, score=-5.524 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05coNv5CizeV for ; Tue, 8 Jul 2008 03:31:44 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 6F4143A6845 for ; Tue, 8 Jul 2008 03:31:44 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m68AVjEf015441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2008 12:31:45 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m68AVgio032353; Tue, 8 Jul 2008 12:31:45 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jul 2008 12:31:43 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jul 2008 12:31:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 13:31:40 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] I-D Action:draft-ietf-ecrit-lost-sync-00.txt Thread-Index: AcjgjHpig/lcPxrcQQqT3Dt2SbOZ1AAWTSog From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Henning Schulzrinne" X-OriginalArrivalTime: 08 Jul 2008 10:31:41.0711 (UTC) FILETIME=[CFB7A1F0:01C8E0E5] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16018.006 X-TM-AS-Result: No--4.051600-8.000000-31 Cc: ECRIT Subject: [Ecrit] FW: I-D Action:draft-ietf-ecrit-lost-sync-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Thank you Henning for the draft update. So, how far, do you think are we to get this to WGLC? What people would be in the best position todo a detailed review? Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Internet-Drafts@ietf.org >Sent: 08 July, 2008 02:45 >To: i-d-announce@ietf.org >Cc: ecrit@ietf.org >Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-sync-00.txt > >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 : Synchronizing Location-to-Service >Translation (LoST) Servers > Author(s) : H. Schulzrinne > Filename : draft-ietf-ecrit-lost-sync-00.txt > Pages : 11 > Date : 2008-07-07 > >The LoST (Location-to-Service Translation) protocol is used to >map locations to service URLs. This document defines a set of >LoST extensions that allow LoST servers to synchronize their >lists of mappings. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-00.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. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 8 09:16:19 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6907B3A693E; Tue, 8 Jul 2008 09:16: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 D254C3A691A for ; Tue, 8 Jul 2008 09:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 vAUwNzPj2O0a for ; Tue, 8 Jul 2008 09:16:18 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id A14FF3A693E for ; Tue, 8 Jul 2008 09:16:17 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KGFrW-0002ML-CV; Tue, 08 Jul 2008 11:16:19 -0500 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'Hannes Tschofenig'" , "'ECRIT'" References: <4872840A.6020808@gmx.net> <090b01c8e075$d7d95880$4101a8c0@cis.neustar.com> Date: Tue, 8 Jul 2008 12:16:13 -0400 Message-ID: <009201c8e115$f7b90600$1bd213ac@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: AcjgdMLaylmEPJ3VT5yDyE/pIV57jgAAKQmgABv2CQAADAsgMA== 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 Status Update: July 2008 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 "Dormant" means list stays active, no meetings, but the work group is not concluded. I think registering service URNs for non-emergency use doesn't need a work group. I'm not sure what other standardization is needed for, let's say, urn:service:pizza.pizzahut I am neutral on whether alert work should be a rechartered ecrit or a new wg. I think the work is important, and I want to participate in it. I think that is an AD call. The only difference is whether we need to organize a BOF. Brian > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:hannes.tschofenig@nsn.com] > Sent: Tuesday, July 08, 2008 6:30 AM > To: ext Brian Rosen; Hannes Tschofenig; ECRIT > Subject: RE: [Ecrit] ECRIT Status Update: July 2008 > > Hi Brian, > > Thanks for the quick response. > > >> * What's next? > >> > >> We have also received a couple of new documents and we have > >some older > >> documents, such as the unauthenticated emergency services work. > >> > >> The overall question is going to be: What should we do in the group > >> once we finished our main documents? > >I will have some small documents to submit once I get > >-framework and -phonebcp out. > > > >What I propose is that we go dormant until we get some > >deployment if the small stuff gets done quick. We then make a > >decision to close or recharter. > >Since some deployment should be late next year or so, I think > >dormancy for a cycle or two is better than dissolution and > >reconstitution. > > By dormant you mean that we just should schedule a slot at IETF > meetings. > > Some folks seem to have the idea of extending LoST beyond the emergency > services usage -- you don't seem to be thrilled by that idea? > > > >There is also the emergency alert issue, which we have said > >could be an expanded ecrit charter or a new wg. > > Correct. Strictly speaking we don't need to wait to start that work. > > Ciao > Hannes > > > >Brian > > > >_______________________________________________ > >Ecrit mailing 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 Jul 8 12:51:52 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E44293A6AD4; Tue, 8 Jul 2008 12:51: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 747A23A6AD4 for ; Tue, 8 Jul 2008 12:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 IKqoFADbDSLh for ; Tue, 8 Jul 2008 12:51:50 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 6A0CC3A6811 for ; Tue, 8 Jul 2008 12:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1215546720; x=1247082720; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<009201c8e115$f7b90600$1bd 213ac@cis.neustar.com>|References:=20<4872840A.6020808@gm x.net>=0D=0A=20<090b01c8e075$d7d95880$4101a8c0@cis.neusta r.com>=0D=0A=20=0D=0A=20<009201c8e115$f7b90600$1b d213ac@cis.neustar.com>|Date:=20Tue,=208=20Jul=202008=201 2:51:55=20-0700|To:=20Brian=20Rosen=20 ,=0D=0A=20=20=20=20=20=20=20=20"'Tschofenig,=20Hannes=20( NSN=20-=20FI/Espoo)'"=0D=0A=09 ,=0D=0A=20=20=20=20=20=20=20=20"'Hannes=20Tschofenig'"=20 ,=0D=0A=20=20=20=20=20=20=20 =20"'ECRIT'"=20|From:=20Ted=20Hardie=20|Subject:=20Re:=20[Ecrit]=20ECRIT=20St atus=20Update:=20July=202008|Content-Type:=20text/plain =3B=20charset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcAfee=3B i=3D"5200,2160,5334"=3B=20a=3D"4538524"; bh=nlFCLAUlRLY9ttaZQdtZkI9GjBl8N2+szkPQPR4Eko8=; b=RRS8nUlW9xzmRBqLwXQaloLSsZz8SZMOKyN4cNQYqRHlbgwCaNpOS8VL GIDOt7+E0TcGJIyovTir+RH+FcU9Go2cjfJ8J6wE07qi904PXZJbYeDjq LjdrVtiFMVr3FeOMeBiKSbA9EGfr/E6j6Xq9/ckdh42lUQSN7qnzoBIAo 8=; X-IronPort-AV: E=McAfee;i="5200,2160,5334"; a="4538524" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2008 12:52:00 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m68JpxKK027351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Jul 2008 12:52:00 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m68JpxfG004768 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Jul 2008 12:51:59 -0700 Received: from [10.30.6.110] (10.50.0.37) by qcmail1.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.278.0; Tue, 8 Jul 2008 12:51:58 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <009201c8e115$f7b90600$1bd213ac@cis.neustar.com> References: <4872840A.6020808@gmx.net> <090b01c8e075$d7d95880$4101a8c0@cis.neustar.com> <009201c8e115$f7b90600$1bd213ac@cis.neustar.com> Date: Tue, 8 Jul 2008 12:51:55 -0700 To: Brian Rosen , "'Tschofenig, Hannes (NSN - FI/Espoo)'" , "'Hannes Tschofenig'" , "'ECRIT'" From: Ted Hardie Subject: Re: [Ecrit] ECRIT Status Update: July 2008 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 9:16 AM -0700 7/8/08, Brian Rosen wrote: >"Dormant" means list stays active, no meetings, but the work group is not >concluded. > >I think registering service URNs for non-emergency use doesn't need a work >group. I'm not sure what other standardization is needed for, let's say, >urn:service:pizza.pizzahut I think a group focused on the emergency use case is exactly the wrong place to consider this. The rats in that rat-hole have been dodged pretty successfully so far, but I see no prospect of dormancy if that is on the plate of the group. two cents, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 8 12:56:04 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB83F3A6935; Tue, 8 Jul 2008 12:56: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 6A1B03A6935 for ; Tue, 8 Jul 2008 12:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.368, 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 rVatTmoWM3Tp for ; Tue, 8 Jul 2008 12:56:02 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 292383A689C for ; Tue, 8 Jul 2008 12:56:01 -0700 (PDT) Received: (qmail invoked by alias); 08 Jul 2008 19:56:09 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp003) with SMTP; 08 Jul 2008 21:56:09 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/97wsZzMD9P/4Co8NvYH9vuMUYUOGIWQvz2pOQMW 8iSuo+rqKKY8pd Message-ID: <4873C658.2010505@gmx.net> Date: Tue, 08 Jul 2008 22:56:08 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ted Hardie References: <4872840A.6020808@gmx.net> <090b01c8e075$d7d95880$4101a8c0@cis.neustar.com> <009201c8e115$f7b90600$1bd213ac@cis.neustar.com> In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 Cc: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , 'ECRIT' Subject: Re: [Ecrit] ECRIT Status Update: July 2008 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Would you be willing to work on early warning related aspects? Ciao Hannes Ted Hardie wrote: > At 9:16 AM -0700 7/8/08, Brian Rosen wrote: > >> "Dormant" means list stays active, no meetings, but the work group is not >> concluded. >> >> I think registering service URNs for non-emergency use doesn't need a work >> group. I'm not sure what other standardization is needed for, let's say, >> urn:service:pizza.pizzahut >> > > I think a group focused on the emergency use case is exactly the wrong > place to consider this. The rats in that rat-hole have been dodged > pretty successfully so far, but I see no prospect of dormancy if that > is on the plate of the group. > > two cents, > Ted > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 8 13:04:18 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 537E73A6989; Tue, 8 Jul 2008 13:04: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 6AE3C3A6989 for ; Tue, 8 Jul 2008 13:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 ub3PGOJdg0BQ for ; Tue, 8 Jul 2008 13:04:16 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id A76613A6970 for ; Tue, 8 Jul 2008 13:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1215547466; x=1247083466; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<4873C658.2010505@gmx.net> |References:=20<4872840A.6020808@gmx.net>=0D=0A=20<090b01 c8e075$d7d95880$4101a8c0@cis.neustar.com>=0D=0A=20=0D=0A=20<009201c8e115$f7b90600$1bd213ac@cis.neustar.com >=0D=0A=20=20<4873C6 58.2010505@gmx.net>|Date:=20Tue,=208=20Jul=202008=2013:04 :22=20-0700|To:=20Hannes=20Tschofenig=20|From:=20Ted=20Hardie=20 |Subject:=20Re:=20[Ecrit]=20ECRIT=20Status=20Update:=20Ju ly=202008|CC:=20Brian=20Rosen=20,=0D =0A=20=20=20=20=20=20=20=20"'Tschofenig,=20Hannes=20(NSN =20-=20FI/Espoo)'"=0D=0A=09, =0D=0A=20=20=20=20=20=20=20=20"'ECRIT'"=20|Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5334"=3B=20 a=3D"4538973"; bh=pHbSEAuS9foUV7ho/Py2LBV1UAeMrKUY+E2jWANppq4=; b=YaR7uF9GlUjckpRn8VHdyA7SQq6Eio+ZE1O8szABy7lMGOkVpXoHQtc+ SNtYBaQMQZ/IZwZP4xCAt/C+EflBuH2iMilDRwRa4nUlDP8ecM8D+YbWa KUNsRVPF8X2SC1JbSuVClY4qOxFumwK4+J1V0+mxPTovBGBDQL1N4XB10 c=; X-IronPort-AV: E=McAfee;i="5200,2160,5334"; a="4538973" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2008 13:04:26 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m68K4QoX028952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Jul 2008 13:04:26 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m68K4PKI009611 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Jul 2008 13:04:26 -0700 Received: from [10.30.6.110] (10.50.16.134) by qcmail1.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.278.0; Tue, 8 Jul 2008 13:04:25 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <4873C658.2010505@gmx.net> References: <4872840A.6020808@gmx.net> <090b01c8e075$d7d95880$4101a8c0@cis.neustar.com> <009201c8e115$f7b90600$1bd213ac@cis.neustar.com> <4873C658.2010505@gmx.net> Date: Tue, 8 Jul 2008 13:04:22 -0700 To: Hannes Tschofenig From: Ted Hardie Cc: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , 'ECRIT' Subject: Re: [Ecrit] ECRIT Status Update: July 2008 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 12:56 PM -0700 7/8/08, Hannes Tschofenig wrote: >Would you be willing to work on early warning related aspects? > >Ciao >Hannes That does make sense to me as a continuation. It's the "urn:service:pizza.pizzahut" vs. "urn:service:pepsico-brands.foods.pizzahut" vs. "urn:service:food.delivery.pizzahut" debate cycle that I think needs other constituents. Again, just my personal opinion. Ted > > >Ted Hardie wrote: >> At 9:16 AM -0700 7/8/08, Brian Rosen wrote: >> >>> "Dormant" means list stays active, no meetings, but the work group is not >>> concluded. >>> >>> I think registering service URNs for non-emergency use doesn't need a work >>> group. I'm not sure what other standardization is needed for, let's say, >>> urn:service:pizza.pizzahut >>> >> >> I think a group focused on the emergency use case is exactly the wrong >> place to consider this. The rats in that rat-hole have been dodged >> pretty successfully so far, but I see no prospect of dormancy if that >> is on the plate of the group. >> >> two cents, >> Ted >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 8 13:05:30 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A975128C2DF; Tue, 8 Jul 2008 13:05: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 B525C28C2DF for ; Tue, 8 Jul 2008 13:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=0.552, 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 ufleGAPrVChB for ; Tue, 8 Jul 2008 13:05:28 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by core3.amsl.com (Postfix) with ESMTP id F2F3E28C22B for ; Tue, 8 Jul 2008 13:05:27 -0700 (PDT) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KGJRQ2MWy-0005SA; Tue, 08 Jul 2008 16:05:37 -0400 Message-ID: <08f801c8e136$1f9c7510$6501a8c0@china.huawei.com> From: "Spencer Dawkins" To: "'ECRIT'" References: <4872840A.6020808@gmx.net><090b01c8e075$d7d95880$4101a8c0@cis.neustar.com><009201c8e115$f7b90600$1bd213ac@cis.neustar.com> <4873C658.2010505@gmx.net> Date: Tue, 8 Jul 2008 15:06:33 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX19+H3eSXTb+bwlqVxQBSved118EhhYs0d8x7F2 /9+tMDTEDSI2QR5u1+CuxTt1CDRmcZ5KYi+eBqXYehxzHesGdk y/BqwEAKGjH7x+P4d/jTnzbU91Z1dbd0hR8JUh8PN4= Subject: Re: [Ecrit] ECRIT Status Update: July 2008 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > Would you be willing to work on early warning related aspects? I would think that the ADs would be looking for two things in deciding what to do with early warning - - will this use the same protocol? and - is this the same group of people doing the work? I'd expect that feedback on these two points would be most helpful... Spencer _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 8 13:32:01 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0A183A6905; Tue, 8 Jul 2008 13:32: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 4C4B63A6B1A for ; Tue, 8 Jul 2008 13:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.312, 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 xkRJNLOr1BI9 for ; Tue, 8 Jul 2008 13:31:59 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 258023A6905 for ; Tue, 8 Jul 2008 13:31:58 -0700 (PDT) Received: (qmail invoked by alias); 08 Jul 2008 20:32:08 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp030) with SMTP; 08 Jul 2008 22:32:08 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19oQAEQRzto5Pp7oWxHOEG4F7iGHLYc1oQc7Xd7l7 65rri0ps/nHkJO Message-ID: <4873CEC8.7020104@gmx.net> Date: Tue, 08 Jul 2008 23:32:08 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Spencer Dawkins References: <4872840A.6020808@gmx.net><090b01c8e075$d7d95880$4101a8c0@cis.neustar.com><009201c8e115$f7b90600$1bd213ac@cis.neustar.com> <4873C658.2010505@gmx.net> <08f801c8e136$1f9c7510$6501a8c0@china.huawei.com> In-Reply-To: <08f801c8e136$1f9c7510$6501a8c0@china.huawei.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.79 Cc: 'ECRIT' Subject: Re: [Ecrit] ECRIT Status Update: July 2008 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Spencer, we had a chat about the early warning aspects already with the ADs (since we already had discussions about this stuff for a while now). The main issue is that the same folks would work on the topic. How the solution will look like is difficult to say. Ciao Hannes Spencer Dawkins wrote: >> Would you be willing to work on early warning related aspects? > > I would think that the ADs would be looking for two things in deciding > what to do with early warning - > > - will this use the same protocol? and > > - is this the same group of people doing the work? > > I'd expect that feedback on these two points would be most helpful... > > Spencer > > _______________________________________________ > Ecrit mailing 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 Jul 8 13:40:10 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AAB028C2E9; Tue, 8 Jul 2008 13:40: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 C7DA428C2E9 for ; Tue, 8 Jul 2008 13:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3qBQbQQMkuT for ; Tue, 8 Jul 2008 13:40:08 -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 CA52A3A6AF0 for ; Tue, 8 Jul 2008 13:40:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,326,1212364800"; d="scan'208";a="63767613" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 08 Jul 2008 20:40:19 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m68KeJ78017066; Tue, 8 Jul 2008 13:40:19 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m68Ke6Os017940; Tue, 8 Jul 2008 20:40:19 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); Tue, 8 Jul 2008 13:40:15 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.65.193]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jul 2008 13:40:14 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 08 Jul 2008 15:40:17 -0500 To: "Spencer Dawkins" , "'ECRIT'" From: "James M. Polk" In-Reply-To: <08f801c8e136$1f9c7510$6501a8c0@china.huawei.com> References: <4872840A.6020808@gmx.net> <090b01c8e075$d7d95880$4101a8c0@cis.neustar.com> <009201c8e115$f7b90600$1bd213ac@cis.neustar.com> <4873C658.2010505@gmx.net> <08f801c8e136$1f9c7510$6501a8c0@china.huawei.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 08 Jul 2008 20:40:15.0053 (UTC) FILETIME=[D35D77D0:01C8E13A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1088; t=1215549619; x=1216413619; c=relaxed/simple; s=sjdkim4002; 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]=20ECRIT=20Status=20Update=3A=20 July=202008 |Sender:=20; bh=Yhw6KtvfBcf6xPhIjjyhAJaVy4vUp1+XcIGab1ItQdU=; b=tyAe6398S0Sy1HPZmTp62AnlxwOS7fY7qW/APeg6Kvp5CtwrA8FBHmneRk yiWc2a6otEkHIn0tGS3SzAgKUbv1+bnPiEzU00Wg2U1TxkG51TyDV6QykV0w ZKRge91hcV; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Ecrit] ECRIT Status Update: July 2008 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 03:06 PM 7/8/2008, Spencer Dawkins wrote: >>Would you be willing to work on early warning related aspects? > >I would think that the ADs would be looking for two things in >deciding what to do with early warning - > >- will this use the same protocol? and "SIP" SIP solves everything, right? but seriously, it will be a different part of SIP (mostly through notifications and subscriptions, and not focused very much on INVITEs (and related requests)) I think this is fairly obvious to most >- is this the same group of people doing the work? a subset (the pure public safety (PSAP folks) would leave, unless personally interested), plus new additions (the early warning folks - which is a different part of government organization) I think the vendors would remain largely the same of course, this is my own opinion >I'd expect that feedback on these two points would be most helpful... > >Spencer > >_______________________________________________ >Ecrit mailing 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 Jul 8 13:43:20 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7733328C31B; Tue, 8 Jul 2008 13:43: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 88A9928C339 for ; Tue, 8 Jul 2008 13:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.460, 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 FvzxZtcIG784 for ; Tue, 8 Jul 2008 13:43:17 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 964DA28C31B for ; Tue, 8 Jul 2008 13:43:17 -0700 (PDT) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KGK221wye-0005sz; Tue, 08 Jul 2008 16:43:27 -0400 Message-ID: <094101c8e13b$6878dad0$6501a8c0@china.huawei.com> From: "Spencer Dawkins" To: "'ECRIT'" References: <4872840A.6020808@gmx.net> <090b01c8e075$d7d95880$4101a8c0@cis.neustar.com> <009201c8e115$f7b90600$1bd213ac@cis.neustar.com> <4873C658.2010505@gmx.net> <08f801c8e136$1f9c7510$6501a8c0@china.huawei.com> Date: Tue, 8 Jul 2008 15:44:23 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX1/rZmHN1lMd0+5Jm+6eeo7s0Fqmi+nMMNuGl2t JNsTzxlfAkrFstyBylYRdyoaAOyQ8KG/NISFXnRAL1MGBZri3/ ixs80j94khTcT9o9e2KAeTYx0+lMt459yGc3QvJ84I= Subject: Re: [Ecrit] ECRIT Status Update: July 2008 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James and Hannes, Thanks for the feedback. Spencer > At 03:06 PM 7/8/2008, Spencer Dawkins wrote: >>>Would you be willing to work on early warning related aspects? >> >>I would think that the ADs would be looking for two things in >>deciding what to do with early warning - >> >>- will this use the same protocol? and > > "SIP" > > SIP solves everything, right? > > but seriously, it will be a different part of SIP (mostly through > notifications and subscriptions, and not focused very much on INVITEs > (and related requests)) > > I think this is fairly obvious to most > > >>- is this the same group of people doing the work? > > a subset (the pure public safety (PSAP folks) would leave, unless > personally interested), plus new additions (the early warning folks - > which is a different part of government organization) > > I think the vendors would remain largely the same > > of course, this is my own opinion > > >>I'd expect that feedback on these two points would be most helpful... >> >>Spencer >> >>_______________________________________________ >>Ecrit mailing 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 Jul 8 13:47:43 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5508628C32C; Tue, 8 Jul 2008 13:47: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 390AC28C32B for ; Tue, 8 Jul 2008 13:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=0.289, 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 eju9MGOAgg3E for ; Tue, 8 Jul 2008 13:47:41 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id F38F528C32C for ; Tue, 8 Jul 2008 13:47:40 -0700 (PDT) Received: (qmail invoked by alias); 08 Jul 2008 20:47:50 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp053) with SMTP; 08 Jul 2008 22:47:50 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Uk0oLTZ0Us+0BQ7p25UeRItAmY5yW7j/49+S6X/ 5QLLAMFLLbGKca Message-ID: <4873D275.6030604@gmx.net> Date: Tue, 08 Jul 2008 23:47:49 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Spencer Dawkins References: <4872840A.6020808@gmx.net> <090b01c8e075$d7d95880$4101a8c0@cis.neustar.com> <009201c8e115$f7b90600$1bd213ac@cis.neustar.com> <4873C658.2010505@gmx.net> <08f801c8e136$1f9c7510$6501a8c0@china.huawei.com> <094101c8e13b$6878dad0$6501a8c0@china.huawei.com> In-Reply-To: <094101c8e13b$6878dad0$6501a8c0@china.huawei.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Cc: 'ECRIT' Subject: Re: [Ecrit] ECRIT Status Update: July 2008 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > Thanks for the feedback. > ..... although our response was quite different. The main difference is in the fact that there are different views on how the overal architecture for early warning would look like. SIP is very likely to be part of it but there are more challenges ahead of us... Ciao Hannes > Spencer > > >> At 03:06 PM 7/8/2008, Spencer Dawkins wrote: >>>> Would you be willing to work on early warning related aspects? >>> >>> I would think that the ADs would be looking for two things in >>> deciding what to do with early warning - >>> >>> - will this use the same protocol? and >> >> "SIP" >> >> SIP solves everything, right? >> >> but seriously, it will be a different part of SIP (mostly through >> notifications and subscriptions, and not focused very much on INVITEs >> (and related requests)) >> >> I think this is fairly obvious to most >> >> >>> - is this the same group of people doing the work? >> >> a subset (the pure public safety (PSAP folks) would leave, unless >> personally interested), plus new additions (the early warning folks - >> which is a different part of government organization) >> >> I think the vendors would remain largely the same >> >> of course, this is my own opinion >> >> >>> I'd expect that feedback on these two points would be most helpful... >>> >>> Spencer >>> >>> _______________________________________________ >>> Ecrit mailing 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 Jul 8 13:56:20 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0211728C335; Tue, 8 Jul 2008 13:56: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 0811A28C335 for ; Tue, 8 Jul 2008 13:56:19 -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 rj0TZn8H5s3Y for ; Tue, 8 Jul 2008 13:56:18 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 0919228C2C6 for ; Tue, 8 Jul 2008 13:56:17 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m68KuMiP002658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 Jul 2008 16:56:22 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Hannes Tschofenig In-Reply-To: <4873CEC8.7020104@gmx.net> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 8 Jul 2008 16:56:22 -0400 References: <4872840A.6020808@gmx.net><090b01c8e075$d7d95880$4101a8c0@cis.neustar.com><009201c8e115$f7b90600$1bd213ac@cis.neustar.com> <4873C658.2010505@gmx.net> <08f801c8e136$1f9c7510$6501a8c0@china.huawei.com> <4873CEC8.7020104@gmx.net> X-Mailer: Apple Mail (2.926) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6 Cc: 'ECRIT' Subject: Re: [Ecrit] ECRIT Status Update: July 2008 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org With the emergency call work, we had a fairly well-defined and cooperative partner (NENA) that provided/s feedback and some "customer" credibility. With alerting, it would be helpful to identify the customers, unless we intentionally follow the "build and they will/ may come" model. (I'm not against that model - it has worked well for other IETF standards, but it would be helpful to know beforehand.) On Jul 8, 2008, at 4:32 PM, Hannes Tschofenig wrote: > Hi Spencer, > > we had a chat about the early warning aspects already with the ADs > (since we already had discussions about this stuff for a while now). > > The main issue is that the same folks would work on the topic. How > the solution will look like is difficult to say. > > Ciao _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 8 13:57:37 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0D623A67B2; Tue, 8 Jul 2008 13:57: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 6EDAA28C346 for ; Tue, 8 Jul 2008 13:57:35 -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 kqK31d0w9X-O for ; Tue, 8 Jul 2008 13:57:34 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 871BF28C206 for ; Tue, 8 Jul 2008 13:57:34 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m68Kvf8a002926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 Jul 2008 16:57:42 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Ted Hardie In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 8 Jul 2008 16:57:41 -0400 References: <4872840A.6020808@gmx.net> <090b01c8e075$d7d95880$4101a8c0@cis.neustar.com> <009201c8e115$f7b90600$1bd213ac@cis.neustar.com> <4873C658.2010505@gmx.net> X-Mailer: Apple Mail (2.926) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6 Cc: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , 'ECRIT' Subject: Re: [Ecrit] ECRIT Status Update: July 2008 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Jul 8, 2008, at 4:04 PM, Ted Hardie wrote: > At 12:56 PM -0700 7/8/08, Hannes Tschofenig wrote: >> Would you be willing to work on early warning related aspects? >> >> Ciao >> Hannes > > That does make sense to me as a continuation. It's the > "urn:service:pizza.pizzahut" vs. "urn:service:pepsico-brands.foods.pizzahut > " > vs. "urn:service:food.delivery.pizzahut" debate cycle that > I think needs other constituents. > That debate, if there needs to be one, may well be sufficiently narrow to just take place in the general APPS or RAI area (depending on one's take of the main customer). _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 8 14:06:38 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A8DA3A683A; Tue, 8 Jul 2008 14:06: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 502953A689F for ; Tue, 8 Jul 2008 14:06:36 -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 JHr8ncASzHj3 for ; Tue, 8 Jul 2008 14:06:35 -0700 (PDT) Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 3B3B63A683A for ; Tue, 8 Jul 2008 14:06:35 -0700 (PDT) Received: from c-69-255-78-171.hsd1.md.comcast.net ([69.255.78.171]:51114 helo=[192.168.1.120]) by portland.eukhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1KGKOS-0000ci-BH; Tue, 08 Jul 2008 21:06:36 +0000 Message-Id: From: ken carlberg To: Henning Schulzrinne In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 8 Jul 2008 17:06:38 -0400 References: <4872840A.6020808@gmx.net><090b01c8e075$d7d95880$4101a8c0@cis.neustar.com><009201c8e115$f7b90600$1bd213ac@cis.neustar.com> <4873C658.2010505@gmx.net> <08f801c8e136$1f9c7510$6501a8c0@china.huawei.com> <4873CEC8.7020104@gmx.net> X-Mailer: Apple Mail (2.926) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk Cc: 'ECRIT' Subject: Re: [Ecrit] ECRIT Status Update: July 2008 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org within the U.S, the "customer" varies. Initial candidates would be emergency management offices of local jurisdictions (ie, counties), along with some states that have a more coordinated policy/authority/ funding. the same counties that have installed inverse-911 will most likely have an interest (though not necessairly a commitment) to extend it to the SIP & IP world. broader systems that involve various technologies beyond just voice are other candidates that will probably express an interest. see the emergency alert system of Washington D.C. as another example. https://textalert.ema.dc.gov/index.php?CCheck=1 -ken On Jul 8, 2008, at 4:56 PM, Henning Schulzrinne wrote: > With the emergency call work, we had a fairly well-defined and > cooperative partner (NENA) that provided/s feedback and some > "customer" credibility. With alerting, it would be helpful to > identify the customers, unless we intentionally follow the "build > and they will/may come" model. (I'm not against that model - it has > worked well for other IETF standards, but it would be helpful to > know beforehand.) > > On Jul 8, 2008, at 4:32 PM, Hannes Tschofenig wrote: > >> Hi Spencer, >> >> we had a chat about the early warning aspects already with the ADs >> (since we already had discussions about this stuff for a while now). >> >> The main issue is that the same folks would work on the topic. How >> the solution will look like is difficult to say. >> >> Ciao > _______________________________________________ > Ecrit mailing 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 Jul 8 14:44:59 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C601228C36B; Tue, 8 Jul 2008 14:44: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 B904D28C372 for ; Tue, 8 Jul 2008 14:44:58 -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 rSw5Y8pFek9Q for ; Tue, 8 Jul 2008 14:44:58 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id EBAB728C369 for ; Tue, 8 Jul 2008 14:44:57 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m68Lj4G3000780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 Jul 2008 17:45:06 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 8 Jul 2008 17:45:04 -0400 References: X-Mailer: Apple Mail (2.926) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Cc: ECRIT Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-lost-sync-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Jul 8, 2008, at 6:31 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Thank you Henning for the draft update. > > So, how far, do you think are we to get this to WGLC? The main missing technical piece, in my opinion, is to identify error conditions. (There's also the need for some schema work, but that's more mechanical.) Input on what errors seem reasonable would be appreciated. I came up pretty dry, given that authorization errors, for example, probably would be handled and indicated by HTTP, not LoST. > What people would be in the best position todo a detailed review? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 8 15:32:56 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E563A28C344; Tue, 8 Jul 2008 15:32: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 C979928C344 for ; Tue, 8 Jul 2008 15:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 1oq8Eni6YOEr for ; Tue, 8 Jul 2008 15:32:55 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 1212828C32D for ; Tue, 8 Jul 2008 15:32:55 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KGLjx-0006Kc-Rt; Tue, 08 Jul 2008 17:32:54 -0500 From: "Brian Rosen" To: "'Spencer Dawkins'" , "'ECRIT'" References: <4872840A.6020808@gmx.net><090b01c8e075$d7d95880$4101a8c0@cis.neustar.com><009201c8e115$f7b90600$1bd213ac@cis.neustar.com><4873C658.2010505@gmx.net> <08f801c8e136$1f9c7510$6501a8c0@china.huawei.com> Date: Tue, 8 Jul 2008 18:33:00 -0400 Message-ID: <019801c8e14a$957e21c0$1bd213ac@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <08f801c8e136$1f9c7510$6501a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjhNfwnEN+6jG3ZSOCqMhg1Zwde6wAFGe1A 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 Status Update: July 2008 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 largely the same people. I suspect that there are aspects of LoST that would be useful, primarily, if there is a subscription, how do you find out where to subscribe? I think that is geographically based in nearly all circumstances, and thus LoST may be used to find the subscription URI. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Spencer Dawkins > Sent: Tuesday, July 08, 2008 4:07 PM > To: 'ECRIT' > Subject: Re: [Ecrit] ECRIT Status Update: July 2008 > > > Would you be willing to work on early warning related aspects? > > I would think that the ADs would be looking for two things in deciding > what > to do with early warning - > > - will this use the same protocol? and > > - is this the same group of people doing the work? > > I'd expect that feedback on these two points would be most helpful... > > Spencer > > > _______________________________________________ > Ecrit mailing 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 Jul 10 09:21:28 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0066E3A6828; Thu, 10 Jul 2008 09:21: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 5DB9F3A680E for ; Thu, 10 Jul 2008 09:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 4vDBhoZ278OM for ; Thu, 10 Jul 2008 09:21:25 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 581A33A67EA for ; Thu, 10 Jul 2008 09:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1215706900; x=1247242900; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<2DE9A51895931C4CBCAEFA930 6AE480E8488A2@toroondc254.bell.corp.bce.ca>|References: =20<2DE9A51895931C4CBCAEFA9306AE480E8488A2@toroondc254.be ll.corp.bce.ca>|Date:=20Thu,=2010=20Jul=202008=2009:21:37 =20-0700|To:=20"g.caron@bell.ca"=20,=20" ecrit@ietf.org"=20|From:=20Ted=20Hardie =20|Subject:=20Re:=20[Ecrit]=20emerg ency=20call=20termination|CC:=20"nena-i2_5@listserv.neust ar.biz"=20|Content-Type: =20text/plain=3B=20charset=3D"us-ascii"|X-IronPort-AV:=20 E=3DMcAfee=3Bi=3D"5200,2160,5335"=3B=20a=3D"4602984"; bh=L2D4MINkYfhbY7nVY6JHp5crvbrdUVey+7ba87hB35o=; b=DhgST99F/ngmGNi323cR8PRJzzQfkmNSlpTwrSBLEI95BWOHYw4d4iI6 vy1mCjM5KpUYacDS8lBGbh5HI6JUQSJFzlJovY8W8vG5CMbdoprjd4q9A w9amt5BBI2iD0PmRPKOl4xEwCJ1ONiw8we28LgJo40++qEbZhGPwRuf9I 8=; X-IronPort-AV: E=McAfee;i="5200,2160,5335"; a="4602984" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2008 09:21:40 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6AGLeJk008547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Jul 2008 09:21:40 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6AGLdjb021765 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 10 Jul 2008 09:21:39 -0700 Received: from [10.30.5.110] (10.50.16.39) by qcmail1.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.278.0; Thu, 10 Jul 2008 09:21:39 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <2DE9A51895931C4CBCAEFA9306AE480E8488A2@toroondc254.bell.corp.bce.ca> References: <2DE9A51895931C4CBCAEFA9306AE480E8488A2@toroondc254.bell.corp.bce.ca> Date: Thu, 10 Jul 2008 09:21:37 -0700 To: "g.caron@bell.ca" , "ecrit@ietf.org" From: Ted Hardie Cc: "nena-i2_5@listserv.neustar.biz" Subject: Re: [Ecrit] emergency call termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 12:31 PM -0700 7/7/08, g.caron@bell.ca wrote: >Dear ECRIT, > >NENA wishes to provide comments regarding "emergency call termination" >behavior in -framework-05 and -phonebcp-04. > >The UA behavior currently defined disallows a UA engaged in an emergency >communication to release the call and states that only the PSAP should >be able to terminate an emergency call. Sorry for the late comment on this, but having thought about this a bit, I agree that this should not be mandatory. If a caller realizes after starting the call that it is not an emergency (the person choking has their airway clear; the parent realizes a child has dialed 911, whatever), they should be able to terminate the call. >NENA wishes to express that this behavior, while desired or mandated in >certain jurisdictions, is undesirable in others. For example, the >majority of the U.S. jurisdictions do not use this feature and prefer to >allow the caller to release an emergency call. > >It is not NENA's intent to revert the current behavior in such a way >that the caller has always the ability to release an emergency call. >NENA would like however that this feature be made optional and >controlled at the PSAP end. This would allow a roaming device to adjust >its behavior according to the rules of the jurisdiction it is currently >in. Though I am no expert in this, it's my understanding that this is not behavior supported by the current cellular networks, so I believe that it would be both simpler and more appropriate to define user terminated calls as permitted behavior. regards, Ted >Thanks, > > >Guy Caron >On behalf of NENA >_______________________________________________ >Ecrit mailing 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 Jul 10 10:21:44 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8AAE3A685A; Thu, 10 Jul 2008 10:21: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 88A443A685A for ; Thu, 10 Jul 2008 10:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akryS7jqv9Fk for ; Thu, 10 Jul 2008 10:21:42 -0700 (PDT) Received: from mail90.messagelabs.com (mail90.messagelabs.com [85.158.139.3]) by core3.amsl.com (Postfix) with ESMTP id 23B2F3A683C for ; Thu, 10 Jul 2008 10:21:41 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-12.tower-90.messagelabs.com!1215710494!40911713!32 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [206.47.0.177] Received: (qmail 15619 invoked from network); 10 Jul 2008 17:21:55 -0000 Received: from dm1c8e.bell.ca (HELO TLS.Exchange.Bell.ca) (206.47.0.177) by server-12.tower-90.messagelabs.com with RC4-SHA encrypted SMTP; 10 Jul 2008 17:21:55 -0000 Received: from hub03-wyn.bell.corp.bce.ca (142.182.199.49) by dm1c8e.exchange3.bell.ca (198.235.102.108) with Microsoft SMTP Server id 8.1.278.0; Thu, 10 Jul 2008 13:21:45 -0400 Received: from TOROONDC908.bell.corp.bce.ca (142.182.89.88) by hub03-wyn.bell.corp.bce.ca (142.182.199.49) with Microsoft SMTP Server id 8.1.278.0; Thu, 10 Jul 2008 13:21:45 -0400 Received: from toroondc254.bell.corp.bce.ca ([142.182.4.53]) by TOROONDC908.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 13:21:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 13:21:45 -0400 Message-ID: <2DE9A51895931C4CBCAEFA9306AE480E848B68@toroondc254.bell.corp.bce.ca> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] emergency call termination Thread-Index: AcjiqQx1Ex7ujnMCTWWSw9+sA0LJ0QABE9Fw References: <2DE9A51895931C4CBCAEFA9306AE480E8488A2@toroondc254.bell.corp.bce.ca> From: To: , X-OriginalArrivalTime: 10 Jul 2008 17:21:45.0679 (UTC) FILETIME=[6DA6B5F0:01C8E2B1] Cc: nena-i2_5@listserv.neustar.biz Subject: Re: [Ecrit] emergency call termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Thank you Ted for taking the time to look at this. Regardless of the outcome of your proposal within ECRIT, do you agree that = this particular UA behavior should be modulated by the requirements/rules o= f the jurisdictions since it simply reflects today's situation? Thanks, Guy Caron -----Message d'origine----- De=A0: Ted Hardie [mailto:hardie@qualcomm.com] = Envoy=E9=A0: 10 juillet 2008 12:22 =C0=A0: Caron, Guy (A162859); ecrit@ietf.org Cc=A0: nena-i2_5@listserv.neustar.biz Objet=A0: Re: [Ecrit] emergency call termination At 12:31 PM -0700 7/7/08, g.caron@bell.ca wrote: >Dear ECRIT, > >NENA wishes to provide comments regarding "emergency call termination" >behavior in -framework-05 and -phonebcp-04. > >The UA behavior currently defined disallows a UA engaged in an emergency >communication to release the call and states that only the PSAP should >be able to terminate an emergency call. Sorry for the late comment on this, but having thought about this a bit, I agree that this should not be mandatory. If a caller realizes after starting the call that it is not an emergency (the person choking has their airway clear; the parent realizes a child has dialed 911, whatever), they should be able to terminate the call. = >NENA wishes to express that this behavior, while desired or mandated in >certain jurisdictions, is undesirable in others. For example, the >majority of the U.S. jurisdictions do not use this feature and prefer to >allow the caller to release an emergency call. > >It is not NENA's intent to revert the current behavior in such a way >that the caller has always the ability to release an emergency call. >NENA would like however that this feature be made optional and >controlled at the PSAP end. This would allow a roaming device to adjust >its behavior according to the rules of the jurisdiction it is currently >in. Though I am no expert in this, it's my understanding that this is not behavior supported by the current cellular networks, so I believe that it would be both simpler and more appropriate to define user terminated calls as permitted behavior. regards, Ted >Thanks, > > >Guy Caron >On behalf of NENA >_______________________________________________ >Ecrit mailing 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 Jul 10 10:54:22 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 229A33A697B; Thu, 10 Jul 2008 10:54: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 3034A3A69AB for ; Thu, 10 Jul 2008 10:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.742 X-Spam-Level: X-Spam-Status: No, score=-102.742 tagged_above=-999 required=5 tests=[AWL=-0.143, 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 UXhFMQH8mNbG for ; Thu, 10 Jul 2008 10:54:20 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 2E7FB3A697B for ; Thu, 10 Jul 2008 10:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1215712475; x=1247248475; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<2DE9A51895931C4CBCAEFA930 6AE480E848B68@toroondc254.bell.corp.bce.ca>|References: =20<2DE9A51895931C4CBCAEFA9306AE480E8488A2@toroondc254.be ll.corp.bce.ca>=0D=0A=20=20=0D=0A=20<2DE9A51895931C4CBCAEFA9306AE480E848B68@t oroondc254.bell.corp.bce.ca>|Date:=20Thu,=2010=20Jul=2020 08=2010:54:32=20-0700|To:=20"g.caron@bell.ca"=20,=20"ecrit@ietf.org"=20|From:=20T ed=20Hardie=20|Subject:=20RE:=20[Ecr it]=20emergency=20call=20termination|CC:=20"nena-i2_5@lis tserv.neustar.biz"=20 |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5335"=3B=20 a=3D"4435845"; bh=gldcYTXGbF+Adbtpn3gpEsAp/WTJUM91HhhF0iGTe0E=; b=WUVLndKiDrklDo+B88qDKb/2ZI7PHaaMVYZ+JtmKiTqyY6+ecl9H8nv6 IyR2CsmQh8lThqI6C6hqCHOj99XH++6TzCtVuIh2PSDLUXyIaWgvXHQwW milMFUPsQmL00rSmd4kKIf9//N0Rncy2NdqC8kBqLLgHNHXnFJMuPQUxU Q=; X-IronPort-AV: E=McAfee;i="5200,2160,5335"; a="4435845" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2008 10:54:35 -0700 Received: from msgtransport06.qualcomm.com (msgtransport06.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6AHsZJN011937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Jul 2008 10:54:35 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport06.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6AHsY3R030770 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 10 Jul 2008 10:54:34 -0700 Received: from [10.30.5.110] (10.50.16.39) by qcmail1.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.278.0; Thu, 10 Jul 2008 10:54:34 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <2DE9A51895931C4CBCAEFA9306AE480E848B68@toroondc254.bell.corp.bce.ca> References: <2DE9A51895931C4CBCAEFA9306AE480E8488A2@toroondc254.bell.corp.bce.ca> <2DE9A51895931C4CBCAEFA9306AE480E848B68@toroondc254.bell.corp.bce.ca> Date: Thu, 10 Jul 2008 10:54:32 -0700 To: "g.caron@bell.ca" , "ecrit@ietf.org" From: Ted Hardie Cc: "nena-i2_5@listserv.neustar.biz" Subject: Re: [Ecrit] emergency call termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 10:21 AM -0700 7/10/08, g.caron@bell.ca wrote: >Thank you Ted for taking the time to look at this. > >Regardless of the outcome of your proposal within ECRIT, do you agree that this particular UA behavior should be modulated by the requirements/rules of the jurisdictions since it simply reflects today's situation? > >Thanks, > >Guy Caron I'm not sure I follow the question. Are you asking whether the UA behavior should be regulated or requirements placed on it by jurisdictions? Or are you asking whether UAs should be location aware and should change their behavior based on the rules applicable in a location? Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 10 10:55:52 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 736033A69F5; Thu, 10 Jul 2008 10: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 5CAEE3A69F5 for ; Thu, 10 Jul 2008 10:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.406 X-Spam-Level: X-Spam-Status: No, score=-1.406 tagged_above=-999 required=5 tests=[AWL=-1.107, BAYES_00=-2.599, MANGLED_PREMTR=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2STPZBc392+4 for ; Thu, 10 Jul 2008 10:55:50 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 467EF3A697B for ; Thu, 10 Jul 2008 10:55:50 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KH0N4-0007Pj-GF; Thu, 10 Jul 2008 12:55:58 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , , References: <2DE9A51895931C4CBCAEFA9306AE480E8488A2@toroondc254.bell.corp.bce.ca> Date: Thu, 10 Jul 2008 13:56:01 -0400 Message-ID: <045101c8e2b6$38f90bf0$1bd213ac@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: AcjiqQkYKu5g3LihS4alyu4KVIkI0AAAUA4A 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: nena-i2_5@listserv.neustar.biz Subject: Re: [Ecrit] emergency call termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 complex issue, made more complex by current deployments. First of all, we need to distinguish between a call that is complete, where a BYE ends the call, and a call that is not complete where a CANCEL ends the call. -phonebcp discusses a completed call where BYE would be used to terminate. It is currently silent on uncompleted calls. Your example is an uncompleted call, but you can extend it to include the case where the caller hangs up just as the call taker answers. Both of these are considered "abandoned calls". In many jurisdictions, they respond to an abandoned call. They don't know why the call is abandoned. So, most PSAPs I've talked to want to force the call to complete, and have the call taker hear (or read) that the problem is solved, and they don't need to send a cop to check it out. This is one reason why they want this capability. The basic CPH is for another purpose, which is pre-mature hang up. It happens often enough that PSAPs care. The user, who is stressed, hangs up before the call taker has enough information. They want the call to be reconnected if the user does that and subsequently goes on hook. They want to be able to ring and/or send howler tone to alert the user to get back on the d&*m phone. It used to be that 9-1-1 in the U.S. had these features. In Canada, they still do. In the U.S. they got lost in the ISDN signaling change, much to the regret of the PSAPs. ISDN (and ISUP) didn't retain the feature, and, I am told, the PSAPs howled, but it didn't get fixed. Now, some of them are used to not having it, but many wish they could get it back. The Canadians have it still, and don't want to lose it. It is clear however, that there are circumstances where CPH is not desired. The best example is where you have a mass calling event and some calls are answered on an IVR (or "IMR" -- multimedia). Clearly, you want the caller to be able to hang up. Now, Guy Caron has proposed several more features, one of which is the ability to signal the hook state of the phone. If we had that, then the PSAP could return BYE automatically upon receipt of an on-hook state. That would allow the PSAP to control CPH without a negotiation of features at the phone. So, I propose that we retain the prohibition on BYE, and we add the proposed hook state signaling (sending SDP with inactive). PSAPs who don't want CPH should send BYE upon receipt of inactive. Note that -phonebcp says hold should be disabled. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Ted Hardie > Sent: Thursday, July 10, 2008 12:22 PM > To: g.caron@bell.ca; ecrit@ietf.org > Cc: nena-i2_5@listserv.neustar.biz > Subject: Re: [Ecrit] emergency call termination > > At 12:31 PM -0700 7/7/08, g.caron@bell.ca wrote: > >Dear ECRIT, > > > >NENA wishes to provide comments regarding "emergency call termination" > >behavior in -framework-05 and -phonebcp-04. > > > >The UA behavior currently defined disallows a UA engaged in an emergency > >communication to release the call and states that only the PSAP should > >be able to terminate an emergency call. > > Sorry for the late comment on this, but having thought about this a bit, > I agree that this should not be mandatory. If a caller realizes after > starting the call that it is not an emergency (the person choking has > their airway clear; the parent realizes a child has dialed 911, whatever), > they should be able to terminate the call. > > >NENA wishes to express that this behavior, while desired or mandated in > >certain jurisdictions, is undesirable in others. For example, the > >majority of the U.S. jurisdictions do not use this feature and prefer to > >allow the caller to release an emergency call. > > > >It is not NENA's intent to revert the current behavior in such a way > >that the caller has always the ability to release an emergency call. > >NENA would like however that this feature be made optional and > >controlled at the PSAP end. This would allow a roaming device to adjust > >its behavior according to the rules of the jurisdiction it is currently > >in. > > Though I am no expert in this, it's my understanding that this is > not behavior supported by the current cellular networks, so I > believe that it would be both simpler and more appropriate to > define user terminated calls as permitted behavior. > regards, > Ted > > > > > > >Thanks, > > > > > >Guy Caron > >On behalf of NENA > >_______________________________________________ > >Ecrit mailing 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 Jul 10 11:26:46 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AADA3A692A; Thu, 10 Jul 2008 11:26: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 8F9FC3A69E5 for ; Thu, 10 Jul 2008 11:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgHkU-piBGtq for ; Thu, 10 Jul 2008 11:26:43 -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 628EF3A68F7 for ; Thu, 10 Jul 2008 11:26:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,339,1212364800"; d="scan'208";a="13865204" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Jul 2008 18:26:58 +0000 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 m6AIQwJK018328; Thu, 10 Jul 2008 14:26:58 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6AIQw90022457; Thu, 10 Jul 2008 18:26:58 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); Thu, 10 Jul 2008 14:26:58 -0400 Received: from [10.116.195.115] ([10.116.195.115]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 14:26:57 -0400 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 10 Jul 2008 14:26:54 -0400 From: Marc Linsner To: , Message-ID: Thread-Topic: [Ecrit] emergency call termination Thread-Index: AcjiqQx1Ex7ujnMCTWWSw9+sA0LJ0QABE9FwAANK3j4= In-Reply-To: <2DE9A51895931C4CBCAEFA9306AE480E848B68@toroondc254.bell.corp.bce.ca> Mime-version: 1.0 X-OriginalArrivalTime: 10 Jul 2008 18:26:57.0609 (UTC) FILETIME=[8957DB90:01C8E2BA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3435; t=1215714418; x=1216578418; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20emergency=20call=20terminatio n |Sender:=20 |To:=20,=20; bh=kkeEaYgjCT9gou+oZPwGczGZqyxu9jjNuN0UqtCT6dw=; b=tt4hTxvUHt78ruPcaiQoNPIqx2l2kbG1maZkOduewZMt/Sr8mC1fLWtcKW lAewcck6UvX0uusWjMG0M2L9cmh0pnla5+vOYGqXWPD3FZE7KErjjmVz6PJn Z17jZ7vm00; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: nena-i2_5@listserv.neustar.biz Subject: Re: [Ecrit] emergency call termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Guy, Would you please expand on 'today's situation'? What I've gleaned out of Ted's assertion (which is also my understanding) and NENA's request (from you) is that PSAPs can 'technically' control the call on wireline service, but not wireless service. I also believe that even if the capability is technically feasible, some jurisdictions don't have the desire to control the call. I'm struggling when it's the case where the jurisdiction requires call control, but it is not technically feasible. Hence, how do you expect the IETF to support the feature since your are asking to match today's situation? Which situation? The one where it's not technically feasible? -Marc- On 7/10/08 1:21 PM, "g.caron@bell.ca" wrote: > Thank you Ted for taking the time to look at this. > = > Regardless of the outcome of your proposal within ECRIT, do you agree that > this particular UA behavior should be modulated by the requirements/rules= of > the jurisdictions since it simply reflects today's situation? > = > Thanks, > = > Guy Caron > -----Message d'origine----- > De=A0: Ted Hardie [mailto:hardie@qualcomm.com] > Envoy=E9=A0: 10 juillet 2008 12:22 > =C0=A0: Caron, Guy (A162859); ecrit@ietf.org > Cc=A0: nena-i2_5@listserv.neustar.biz > Objet=A0: Re: [Ecrit] emergency call termination > = > At 12:31 PM -0700 7/7/08, g.caron@bell.ca wrote: >> Dear ECRIT, >> = >> NENA wishes to provide comments regarding "emergency call termination" >> behavior in -framework-05 and -phonebcp-04. >> = >> The UA behavior currently defined disallows a UA engaged in an emergency >> communication to release the call and states that only the PSAP should >> be able to terminate an emergency call. > = > Sorry for the late comment on this, but having thought about this a bit, > I agree that this should not be mandatory. If a caller realizes after > starting the call that it is not an emergency (the person choking has > their airway clear; the parent realizes a child has dialed 911, whatever), > they should be able to terminate the call. > = >> NENA wishes to express that this behavior, while desired or mandated in >> certain jurisdictions, is undesirable in others. For example, the >> majority of the U.S. jurisdictions do not use this feature and prefer to >> allow the caller to release an emergency call. >> = >> It is not NENA's intent to revert the current behavior in such a way >> that the caller has always the ability to release an emergency call. >> NENA would like however that this feature be made optional and >> controlled at the PSAP end. This would allow a roaming device to adjust >> its behavior according to the rules of the jurisdiction it is currently >> in. > = > Though I am no expert in this, it's my understanding that this is > not behavior supported by the current cellular networks, so I > believe that it would be both simpler and more appropriate to > define user terminated calls as permitted behavior. > regards, > Ted > = > = > = > = > = >> Thanks, >> = >> = >> Guy Caron >> On behalf of NENA >> _______________________________________________ >> Ecrit mailing 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 Jul 10 12:16:52 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A7633A6A80; Thu, 10 Jul 2008 12:16: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 776533A6A82 for ; Thu, 10 Jul 2008 12:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVWkWlJpG0PS for ; Thu, 10 Jul 2008 12:16:50 -0700 (PDT) Received: from mail90.messagelabs.com (mail90.messagelabs.com [85.158.139.3]) by core3.amsl.com (Postfix) with ESMTP id DB65F3A6A01 for ; Thu, 10 Jul 2008 12:16:49 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-14.tower-90.messagelabs.com!1215717422!41670532!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [206.47.0.168] Received: (qmail 1455 invoked from network); 10 Jul 2008 19:17:03 -0000 Received: from dm1c8g.bell.ca (HELO TLS.Exchange.bell.ca) (206.47.0.168) by server-14.tower-90.messagelabs.com with RC4-SHA encrypted SMTP; 10 Jul 2008 19:17:03 -0000 Received: from hub03-wyn.bell.corp.bce.ca (142.182.199.49) by dm1c8g.exchange1.bell.ca (198.235.102.109) with Microsoft SMTP Server id 8.1.278.0; Thu, 10 Jul 2008 15:16:55 -0400 Received: from TOROONDC918.bell.corp.bce.ca (142.182.89.79) by hub03-wyn.bell.corp.bce.ca (142.182.199.49) with Microsoft SMTP Server id 8.1.278.0; Thu, 10 Jul 2008 15:16:51 -0400 Received: from toroondc254.bell.corp.bce.ca ([142.182.4.53]) by TOROONDC918.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 15:16:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 15:16:49 -0400 Message-ID: <2DE9A51895931C4CBCAEFA9306AE480E848B98@toroondc254.bell.corp.bce.ca> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] emergency call termination Thread-Index: Acjitggi/QP5Vcx2S/uNfzoV4DOibAAC01Wg References: <2DE9A51895931C4CBCAEFA9306AE480E8488A2@toroondc254.bell.corp.bce.ca> <2DE9A51895931C4CBCAEFA9306AE480E848B68@toroondc254.bell.corp.bce.ca> From: To: , X-OriginalArrivalTime: 10 Jul 2008 19:16:50.0959 (UTC) FILETIME=[8184D1F0:01C8E2C1] Cc: nena-i2_5@listserv.neustar.biz Subject: Re: [Ecrit] emergency call termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Ted, More of the latter. Thanks, = Guy Caron -----Message d'origine----- De=A0: Ted Hardie [mailto:hardie@qualcomm.com] = Envoy=E9=A0: 10 juillet 2008 13:55 =C0=A0: Caron, Guy (A162859); ecrit@ietf.org Cc=A0: nena-i2_5@listserv.neustar.biz Objet=A0: RE: [Ecrit] emergency call termination At 10:21 AM -0700 7/10/08, g.caron@bell.ca wrote: >Thank you Ted for taking the time to look at this. > >Regardless of the outcome of your proposal within ECRIT, do you agree that= this particular UA behavior should be modulated by the requirements/rules = of the jurisdictions since it simply reflects today's situation? > >Thanks, > >Guy Caron I'm not sure I follow the question. Are you asking whether the UA behavior should be regulated or requirements placed on it by jurisdictions? Or are you asking whether UAs should be location aware and should change their behavior based on the rules applicable in a location? Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 10 12:42:52 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FE483A69E5; Thu, 10 Jul 2008 12: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 23EE03A68D8 for ; Thu, 10 Jul 2008 12:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKwLlJi5ZjS7 for ; Thu, 10 Jul 2008 12:42:50 -0700 (PDT) Received: from mail70.messagelabs.com (mail70.messagelabs.com [193.109.255.115]) by core3.amsl.com (Postfix) with ESMTP id 9E28D3A692A for ; Thu, 10 Jul 2008 12:42:49 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-7.tower-70.messagelabs.com!1215718961!102936276!34 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [206.47.0.173] Received: (qmail 3294 invoked from network); 10 Jul 2008 19:43:02 -0000 Received: from dm1c8f.bell.ca (HELO TLS.Exchange.Bell.ca) (206.47.0.173) by server-7.tower-70.messagelabs.com with RC4-SHA encrypted SMTP; 10 Jul 2008 19:43:02 -0000 Received: from hub02-wyn.bell.corp.bce.ca (142.182.199.50) by dm1c8f.exchange1.bell.ca (198.235.102.112) with Microsoft SMTP Server id 8.1.278.0; Thu, 10 Jul 2008 15:42:55 -0400 Received: from TOROONDC908.bell.corp.bce.ca (142.182.89.88) by hub02-wyn.bell.corp.bce.ca (142.182.199.50) with Microsoft SMTP Server id 8.1.278.0; Thu, 10 Jul 2008 15:42:54 -0400 Received: from toroondc254.bell.corp.bce.ca ([142.182.4.53]) by TOROONDC908.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 15:42:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 15:42:53 -0400 Message-ID: <2DE9A51895931C4CBCAEFA9306AE480E848BAC@toroondc254.bell.corp.bce.ca> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] emergency call termination Thread-Index: AcjiqQx1Ex7ujnMCTWWSw9+sA0LJ0QABE9FwAANK3j4AAdOWcA== References: <2DE9A51895931C4CBCAEFA9306AE480E848B68@toroondc254.bell.corp.bce.ca> From: To: , X-OriginalArrivalTime: 10 Jul 2008 19:42:54.0211 (UTC) FILETIME=[254A2530:01C8E2C5] Cc: nena-i2_5@listserv.neustar.biz Subject: Re: [Ecrit] emergency call termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Certainly Marc. It is also my understanding that current cellular voice services have not i= mplemented the network capabilities to enable PSAP control over call termin= ation even if the jurisdiction requires/mandates it. The reasons for this a= re still obscure to me. I note however that those PSAPs using it are very d= isappointed of this situation in wireless and would like not to repeat it f= or Next Generation services. The situation I was referring to was more in line with PSAP requirements th= an with technical limitations. In that sense, if a PSAP assumes a certain b= ehavior for devices operating in its jurisdiction, it would be up to the de= vice to adjust accordingly. Thanks, = Guy Caron -----Message d'origine----- De=A0: Marc Linsner [mailto:mlinsner@cisco.com] = Envoy=E9=A0: 10 juillet 2008 14:27 =C0=A0: Caron, Guy (A162859); ecrit@ietf.org Cc=A0: nena-i2_5@listserv.neustar.biz Objet=A0: Re: [Ecrit] emergency call termination Guy, Would you please expand on 'today's situation'? What I've gleaned out of Ted's assertion (which is also my understanding) and NENA's request (from you) is that PSAPs can 'technically' control the call on wireline service, but not wireless service. I also believe that even if the capability is technically feasible, some jurisdictions don't have the desire to control the call. I'm struggling when it's the case where the jurisdiction requires call control, but it is not technically feasible. Hence, how do you expect the IETF to support the feature since your are asking to match today's situation? Which situation? The one where it's not technically feasible? -Marc- On 7/10/08 1:21 PM, "g.caron@bell.ca" wrote: > Thank you Ted for taking the time to look at this. > = > Regardless of the outcome of your proposal within ECRIT, do you agree that > this particular UA behavior should be modulated by the requirements/rules= of > the jurisdictions since it simply reflects today's situation? > = > Thanks, > = > Guy Caron > -----Message d'origine----- > De=A0: Ted Hardie [mailto:hardie@qualcomm.com] > Envoy=E9=A0: 10 juillet 2008 12:22 > =C0=A0: Caron, Guy (A162859); ecrit@ietf.org > Cc=A0: nena-i2_5@listserv.neustar.biz > Objet=A0: Re: [Ecrit] emergency call termination > = > At 12:31 PM -0700 7/7/08, g.caron@bell.ca wrote: >> Dear ECRIT, >> = >> NENA wishes to provide comments regarding "emergency call termination" >> behavior in -framework-05 and -phonebcp-04. >> = >> The UA behavior currently defined disallows a UA engaged in an emergency >> communication to release the call and states that only the PSAP should >> be able to terminate an emergency call. > = > Sorry for the late comment on this, but having thought about this a bit, > I agree that this should not be mandatory. If a caller realizes after > starting the call that it is not an emergency (the person choking has > their airway clear; the parent realizes a child has dialed 911, whatever), > they should be able to terminate the call. > = >> NENA wishes to express that this behavior, while desired or mandated in >> certain jurisdictions, is undesirable in others. For example, the >> majority of the U.S. jurisdictions do not use this feature and prefer to >> allow the caller to release an emergency call. >> = >> It is not NENA's intent to revert the current behavior in such a way >> that the caller has always the ability to release an emergency call. >> NENA would like however that this feature be made optional and >> controlled at the PSAP end. This would allow a roaming device to adjust >> its behavior according to the rules of the jurisdiction it is currently >> in. > = > Though I am no expert in this, it's my understanding that this is > not behavior supported by the current cellular networks, so I > believe that it would be both simpler and more appropriate to > define user terminated calls as permitted behavior. > regards, > Ted > = > = > = > = > = >> Thanks, >> = >> = >> Guy Caron >> On behalf of NENA >> _______________________________________________ >> Ecrit mailing 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 Jul 10 13:00:02 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2F3B3A6A8B; Thu, 10 Jul 2008 13:00:02 -0700 (PDT) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 93C633A6A8B; Thu, 10 Jul 2008 13:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080710200001.93C633A6A8B@core3.amsl.com> Date: Thu, 10 Jul 2008 13:00:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-framework-06.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 : Framework for Emergency Calling using Internet Multimedia Author(s) : B. Rosen, et al. Filename : draft-ietf-ecrit-framework-06.txt Pages : 37 Date : 2008-07-10 The IETF has several efforts targeted at standardizing various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-06.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-framework-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-10124808.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 Thu Jul 10 13:00:03 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C19803A6A9A; Thu, 10 Jul 2008 13:00:03 -0700 (PDT) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 985E23A6A8C; Thu, 10 Jul 2008 13:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080710200001.985E23A6A8C@core3.amsl.com> Date: Thu, 10 Jul 2008 13:00:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-05.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 : Best Current Practice for Communications Services in support of Emergency Calling Author(s) : B. Rosen, J. Polk Filename : draft-ietf-ecrit-phonebcp-05.txt Pages : 46 Date : 2008-07-10 The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-05.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-phonebcp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-10124820.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 Thu Jul 10 13:16:18 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8BD28C0F0; Thu, 10 Jul 2008 13:16: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 20EBD28C0F6 for ; Thu, 10 Jul 2008 13:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 j5PXzadifVim for ; Thu, 10 Jul 2008 13:16:16 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 5B8F828C0E9 for ; Thu, 10 Jul 2008 13:16:16 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KH2Yx-0006mm-TY for ecrit@ietf.org; Thu, 10 Jul 2008 15:16:24 -0500 From: "Brian Rosen" To: "'ECRIT'" Date: Thu, 10 Jul 2008 16:16:28 -0400 Message-ID: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjiydXLGzki70/bTm6ZLPN8UtBw2g== 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: [Ecrit] New versions of -framework and -phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 These versions incorporate all last call comments except as I have stated in prior email. The majority of changes have to do with: * More explicit text and references to -profile for multiple locations * Requiring the return of dialstrings on LoST for sos service URNs. * Lots of typos and wording changes. I did end up adding a couple of requirements, and thus needed to renumber the requirements, so diffs look bad. I ask commenters to look at the text to make sure I made all the changes you requested (with the exceptions covered in the emails). Chairs can consider if they wish to hold a short 2nd WGLC. There are a couple of substantive changes and added requirements, but not a whole lot text is modified in any but trivial ways. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 10 13:18:49 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319713A6948; Thu, 10 Jul 2008 13:18: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 E37C33A69EB for ; Thu, 10 Jul 2008 13:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RpEjr09CHpf for ; Thu, 10 Jul 2008 13:18:47 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 1A55C3A6948 for ; Thu, 10 Jul 2008 13:18:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,340,1212364800"; d="scan'208";a="86473551" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 10 Jul 2008 20:19:02 +0000 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 m6AKJ2DR006006; Thu, 10 Jul 2008 13:19:02 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6AKJ2qT025267; Thu, 10 Jul 2008 20:19:02 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); Thu, 10 Jul 2008 13:19:02 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.78.105]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 13:19:01 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 10 Jul 2008 15:19:04 -0500 To: , From: "James M. Polk" In-Reply-To: <2DE9A51895931C4CBCAEFA9306AE480E8488A2@toroondc254.bell.co rp.bce.ca> References: <2DE9A51895931C4CBCAEFA9306AE480E8488A2@toroondc254.bell.corp.bce.ca> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 10 Jul 2008 20:19:01.0634 (UTC) FILETIME=[312CA620:01C8E2CA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1866; t=1215721142; x=1216585142; 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]=20emergency=20call=20terminatio n |Sender:=20; bh=bNVBTMqvS3l6q7eTiFCzhz+7mHtYLx5t39cVlTUCc+U=; b=sF+MJ8Hr4vmQWWviAbMt7wMrtzeBZCPAk2XTtK9JDxszHXvFUMPjzasBuw 3Yap64KhIBg3XIxBjgnDrVxTvQmqUUbFTjrrD9zQZCsK8hojgnmt6sWYg7f7 vQgEGYuWVj; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: nena-i2_5@listserv.neustar.biz Subject: Re: [Ecrit] emergency call termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 02:31 PM 7/7/2008, g.caron@bell.ca wrote: >NENA wishes to express that this behavior, while desired or mandated in >certain jurisdictions, is undesirable in others. For example, the >majority of the U.S. jurisdictions do not use this feature and prefer to >allow the caller to release an emergency call. Guy -- First off, IETF is not all about the US or North America, , so just because some US jurisdictions practice a capability one way, doesn't mean the whole proposal needs to change. Second, if the caller wants to hang up the phone, the call taker is going to hang up also. Why can't the call taker be the one in charge of this BYE? Didn't Canada just have a bad situation occur in which the location of a caller resulted in the death of a boy? The case involved a family that was using residential VoIP, and the call taker didn't ask where they lived; instead relying on "the system" to tell the call taker where the call originated. The family had moved to Calgary from the Winnipeg or Toronto area (I can't remember which) and the first responders went to their old location. The one from the form they had to fill out by hand, informing anyone who called in on IP, that this is where to send the responders. Personally, I think the call taker shouldn't have relied on the system, and simply asked where the caller was located. But I'm sure if that information hadn't been given, and the call taker wanted it (but for some reason delayed asking for it), they would want to have the ability to prevent the caller from hanging up. This is one way for that not to occur. At the end of the day, if both caller and call taker want the call to end, does it make a difference who's hang-up or button sends the BYE? It's gonna happen at about the same time, give or take a half a second. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 10 14:00:11 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E3C23A69B7; Thu, 10 Jul 2008 14:00: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 576B23A6929 for ; Thu, 10 Jul 2008 14:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eSblWJMpfcE for ; Thu, 10 Jul 2008 14:00:08 -0700 (PDT) Received: from mail176.messagelabs.com (mail176.messagelabs.com [85.158.138.83]) by core3.amsl.com (Postfix) with ESMTP id E0BB03A680F for ; Thu, 10 Jul 2008 14:00:07 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-15.tower-176.messagelabs.com!1215723581!6539200!25 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [206.47.0.168] Received: (qmail 26046 invoked from network); 10 Jul 2008 21:00:19 -0000 Received: from dm1c8g.bell.ca (HELO TLS.Exchange.bell.ca) (206.47.0.168) by server-15.tower-176.messagelabs.com with RC4-SHA encrypted SMTP; 10 Jul 2008 21:00:19 -0000 Received: from hub01-wyn.bell.corp.bce.ca (142.182.199.48) by dm1c8g.exchange1.bell.ca (198.235.102.109) with Microsoft SMTP Server id 8.1.278.0; Thu, 10 Jul 2008 17:00:15 -0400 Received: from toroondc550.bell.corp.bce.ca (142.182.84.162) by hub01-wyn.bell.corp.bce.ca (142.182.199.48) with Microsoft SMTP Server id 8.1.278.0; Thu, 10 Jul 2008 17:00:13 -0400 Received: from toroondc254.bell.corp.bce.ca ([142.182.4.53]) by toroondc550.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 17:00:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 17:00:12 -0400 Message-ID: <2DE9A51895931C4CBCAEFA9306AE480E848BC4@toroondc254.bell.corp.bce.ca> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] emergency call termination Thread-Index: AcjiyjUBrMqBgD+FRf2qeku85hSx5wAACxyA References: <2DE9A51895931C4CBCAEFA9306AE480E8488A2@toroondc254.bell.corp.bce.ca> From: To: , X-OriginalArrivalTime: 10 Jul 2008 21:00:13.0837 (UTC) FILETIME=[F2B8E3D0:01C8E2CF] Cc: nena-i2_5@listserv.neustar.biz Subject: Re: [Ecrit] emergency call termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Thanks John for your comments. Please find some replies inline. = Guy Caron -----Message d'origine----- De=A0: James M. Polk [mailto:jmpolk@cisco.com] = Envoy=E9=A0: 10 juillet 2008 16:19 =C0=A0: Caron, Guy (A162859); ecrit@ietf.org Cc=A0: nena-i2_5@listserv.neustar.biz Objet=A0: Re: [Ecrit] emergency call termination At 02:31 PM 7/7/2008, g.caron@bell.ca wrote: >NENA wishes to express that this behavior, while desired or mandated in >certain jurisdictions, is undesirable in others. For example, the >majority of the U.S. jurisdictions do not use this feature and prefer to >allow the caller to release an emergency call. Guy -- First off, IETF is not all about the US or North America, , so just = because some US jurisdictions practice a capability one way, doesn't = mean the whole proposal needs to change. [GC] I do appreciate the global scope of the IETF. I simply wanted to give = one tangible example where the PSAP do not want to enforce PSAP control ove= r call termination. There may be others that I'm not aware of. It is my und= erstanding that other countries require it. Japan (http://tools.ietf.org/ht= ml/draft-arai-ecrit-japan-req-01) and Canada are known examples. Second, if the caller wants to hang up the phone, the call taker is = going to hang up also. [GC] The call taker may in fact hang-up if he feels it is the appropriate t= hing to do. It may however decide to pursue the conversation if, for exampl= e, he was not able to confirm all the information required to properly proc= ess that call. Please refer to the previous post (http://www.ietf.org/mail-= archive/web/ecrit/current/msg05276.html) that describes some features that = can be invoked by the call taker in this situation. Comments are also welco= me on this one :-). Why can't the call taker be the one in charge of this BYE? [GC] He definitively should if that's the PSAP's normal operation to keep c= ontrol over call termination. But this may not be the case for all PSAPs. Didn't Canada just have a bad situation occur in which the location = of a caller resulted in the death of a boy? The case involved a = family that was using residential VoIP, and the call taker didn't ask = where they lived; instead relying on "the system" to tell the call = taker where the call originated. The family had moved to Calgary from = the Winnipeg or Toronto area (I can't remember which) and the first = responders went to their old location. The one from the form they had = to fill out by hand, informing anyone who called in on IP, that this = is where to send the responders. [GC] Indeed, a very unfortunate and dramatic event that we all wish would n= ever happen. My understanding of the series of events is not exactly as you= described. You are right though that the location information "on file" wa= s wrong. The "system" in this case was not the E9-1-1 infrastructure though. Personally, I think the call taker shouldn't have relied on the = system, and simply asked where the caller was located. [GC] My understanding is that he did ask verbally for the location. Apparen= tly because of a language barrier, it did not get acknowledged before the c= all was dropped. But I'm sure if that information hadn't been given, and the call taker wa= nted it (but for some reason delayed asking for it), they would want to hav= e the ability to prevent the caller from hanging up. This is one way = for that not to occur. [GC] Absolutely. At the end of the day, if both caller and call taker want the call to = end, does it make a difference who's hang-up or button sends = the BYE? It's gonna happen at about the same time, give or take a = half a second. [GC] In normal circumstances, I agree. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 10 14:20:01 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62A8E3A6A8D; Thu, 10 Jul 2008 14:20: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 2DF4F3A6A8D for ; Thu, 10 Jul 2008 14:20: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 Wy8LF+rPvVpN for ; Thu, 10 Jul 2008 14:20: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 618953A6A8B for ; Thu, 10 Jul 2008 14:20:00 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m6ALKA8g003015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 10 Jul 2008 17:20:10 -0400 (EDT) Message-Id: <67A83811-40C2-48F3-B22F-B58A83779286@cs.columbia.edu> From: Henning Schulzrinne To: "" In-Reply-To: <2DE9A51895931C4CBCAEFA9306AE480E848BAC@toroondc254.bell.corp.bce.ca> Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 10 Jul 2008 17:20:10 -0400 References: <2DE9A51895931C4CBCAEFA9306AE480E848B68@toroondc254.bell.corp.bce.ca> <2DE9A51895931C4CBCAEFA9306AE480E848BAC@toroondc254.bell.corp.bce.ca> X-Mailer: Apple Mail (2.926) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Cc: nena-i2_5@listserv.neustar.biz, ecrit@ietf.org Subject: Re: [Ecrit] emergency call termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I assume that preventing BYE from the caller side is mainly meant to deal with accidental disconnect. Nothing prevents a caller from turning off the cell phone, removing its battery or unplugging the land-line phone (or simply muting the microphone). On Jul 10, 2008, at 3:42 PM, wrote: > Certainly Marc. > > It is also my understanding that current cellular voice services > have not implemented the network capabilities to enable PSAP control > over call termination even if the jurisdiction requires/mandates it. > The reasons for this are still obscure to me. I note however that > those PSAPs using it are very disappointed of this situation in > wireless and would like not to repeat it for Next Generation services. > > The situation I was referring to was more in line with PSAP > requirements than with technical limitations. In that sense, if a > PSAP assumes a certain behavior for devices operating in its > jurisdiction, it would be up to the device to adjust accordingly. > > Thanks, _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 10 14:41:41 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6663A6AB3; Thu, 10 Jul 2008 14:41: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 7A5483A69BD for ; Thu, 10 Jul 2008 14:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2i5ERX4m3FN for ; Thu, 10 Jul 2008 14:41:39 -0700 (PDT) Received: from mail70.messagelabs.com (mail70.messagelabs.com [193.109.255.115]) by core3.amsl.com (Postfix) with ESMTP id BE9943A6ABE for ; Thu, 10 Jul 2008 14:41:11 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-8.tower-70.messagelabs.com!1215726083!111653036!4 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [206.47.0.173] Received: (qmail 23719 invoked from network); 10 Jul 2008 21:41:25 -0000 Received: from dm1c8f.bell.ca (HELO TLS.Exchange.Bell.ca) (206.47.0.173) by server-8.tower-70.messagelabs.com with RC4-SHA encrypted SMTP; 10 Jul 2008 21:41:25 -0000 Received: from hub03-wyn.bell.corp.bce.ca (142.182.199.49) by dm1c8f.exchange1.bell.ca (198.235.102.112) with Microsoft SMTP Server id 8.1.278.0; Thu, 10 Jul 2008 17:41:26 -0400 Received: from toroondc550.bell.corp.bce.ca (142.182.84.162) by hub03-wyn.bell.corp.bce.ca (142.182.199.49) with Microsoft SMTP Server id 8.1.278.0; Thu, 10 Jul 2008 17:41:24 -0400 Received: from toroondc254.bell.corp.bce.ca ([142.182.4.53]) by toroondc550.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 17:41:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 17:41:23 -0400 Message-ID: <2DE9A51895931C4CBCAEFA9306AE480E848BCD@toroondc254.bell.corp.bce.ca> In-Reply-To: <67A83811-40C2-48F3-B22F-B58A83779286@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] emergency call termination Thread-Index: Acji0r/Zcx99cZvNQ+WN+oZnsWVr3gAABrCg References: <2DE9A51895931C4CBCAEFA9306AE480E848B68@toroondc254.bell.corp.bce.ca> <2DE9A51895931C4CBCAEFA9306AE480E848BAC@toroondc254.bell.corp.bce.ca> <67A83811-40C2-48F3-B22F-B58A83779286@cs.columbia.edu> From: To: X-OriginalArrivalTime: 10 Jul 2008 21:41:24.0400 (UTC) FILETIME=[B34AE300:01C8E2D5] Cc: nena-i2_5@listserv.neustar.biz, ecrit@ietf.org Subject: Re: [Ecrit] emergency call termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Henning, Yes, accidental disconnects is one case including where the caller thinks h= e had given enough info but the call taker does not. Drastic actions such as the one you mentioned are indeed a challenge. For t= he PSTN phone though, if there is more than one phone in the house (as it i= s usually the case), the other sets could be used to re-invite the caller i= nto a conversation since it is the "line" that is kept alive. Thanks, = Guy Caron -----Message d'origine----- De=A0: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] = Envoy=E9=A0: 10 juillet 2008 17:20 =C0=A0: Caron, Guy (A162859) Cc=A0: mlinsner@cisco.com; ecrit@ietf.org; nena-i2_5@listserv.neustar.biz Objet=A0: Re: [Ecrit] emergency call termination I assume that preventing BYE from the caller side is mainly meant to = deal with accidental disconnect. Nothing prevents a caller from = turning off the cell phone, removing its battery or unplugging the = land-line phone (or simply muting the microphone). On Jul 10, 2008, at 3:42 PM, wrote: > Certainly Marc. > > It is also my understanding that current cellular voice services = > have not implemented the network capabilities to enable PSAP control = > over call termination even if the jurisdiction requires/mandates it. = > The reasons for this are still obscure to me. I note however that = > those PSAPs using it are very disappointed of this situation in = > wireless and would like not to repeat it for Next Generation services. > > The situation I was referring to was more in line with PSAP = > requirements than with technical limitations. In that sense, if a = > PSAP assumes a certain behavior for devices operating in its = > jurisdiction, it would be up to the device to adjust accordingly. > > Thanks, _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 10 14:43:07 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 360DE3A6A9E; Thu, 10 Jul 2008 14:43: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 4E0AC3A69B7 for ; Thu, 10 Jul 2008 14:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6d8mvw+xH6L for ; Thu, 10 Jul 2008 14:43: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 2F07E3A68D8 for ; Thu, 10 Jul 2008 14:43:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,340,1212364800"; d="scan'208";a="64585011" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 10 Jul 2008 21:26:42 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m6ALQg7D024848; Thu, 10 Jul 2008 14:26:42 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m6ALQgmw024715; Thu, 10 Jul 2008 21:26:42 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); Thu, 10 Jul 2008 14:26:42 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.93.106]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 14:26:41 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 10 Jul 2008 16:26:43 -0500 To: , From: "James M. Polk" In-Reply-To: <2DE9A51895931C4CBCAEFA9306AE480E848BC4@toroondc254.bell.co rp.bce.ca> References: <2DE9A51895931C4CBCAEFA9306AE480E8488A2@toroondc254.bell.corp.bce.ca> <2DE9A51895931C4CBCAEFA9306AE480E848BC4@toroondc254.bell.corp.bce.ca> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 10 Jul 2008 21:26:41.0849 (UTC) FILETIME=[A5404A90:01C8E2D3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1741; t=1215725202; x=1216589202; 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]=20emergency=20call=20terminatio n |Sender:=20; bh=nrzl1Mr6aRZC5fHXR9tGLorcZyuGOMQgcP+5zOoFHGg=; b=PVYSEZhKA6c/0Z31jL1lX6RKxKDOVu5wd9hUNkewDbzIgtKeBFj62065qa GfoZJKUh/AWb32hDbPlYvE/r2hFND8NVoVzvleWG/jyCudajRDr+nG3rvg3Y bKqoVVzhZA; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: nena-i2_5@listserv.neustar.biz Subject: Re: [Ecrit] emergency call termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Guy in-line below At 04:00 PM 7/10/2008, g.caron@bell.ca wrote: >Didn't Canada just have a bad situation occur in which the location >of a caller resulted in the death of a boy? The case involved a >family that was using residential VoIP, and the call taker didn't ask >where they lived; instead relying on "the system" to tell the call >taker where the call originated. The family had moved to Calgary from >the Winnipeg or Toronto area (I can't remember which) and the first >responders went to their old location. The one from the form they had >to fill out by hand, informing anyone who called in on IP, that this >is where to send the responders. > >[GC] Indeed, a very unfortunate and dramatic event that we all wish >would never happen. My understanding of the series of events is not >exactly as you described. You are right though that the location >information "on file" was wrong. The "system" in this case was not >the E9-1-1 infrastructure though. [JMP] I didn't mean to imply it was. > But I'm sure if that information hadn't been given, and the call > taker wanted it (but for some reason delayed asking for it), they > would want to have the ability to prevent the caller from hanging > up. This is one way >for that not to occur. > >[GC] Absolutely. > >At the end of the day, if both caller and call taker want the call to >end, does it make a difference who's hang-up or button sends >the BYE? It's gonna happen at about the same time, give or take a >half a second. > >[GC] In normal circumstances, I agree. [JMP] so, what are the non-normal circumstances you want this specified feature removed for, and how common (i.e., at what frequency) do they occur? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 10 14:58:53 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2DC53A6A2E; Thu, 10 Jul 2008 14:58: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 57CD53A6921 for ; Thu, 10 Jul 2008 14:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbINBxdFr9TE for ; Thu, 10 Jul 2008 14:58:52 -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 1CAB13A6A5B for ; Thu, 10 Jul 2008 14:58:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,340,1212364800"; d="scan'208";a="125159160" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 10 Jul 2008 21:58:34 +0000 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 m6ALwXNr007885; Thu, 10 Jul 2008 14:58:33 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6ALwX8T019785; Thu, 10 Jul 2008 21:58:34 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); Thu, 10 Jul 2008 14:58:33 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.93.106]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 14:58:33 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 10 Jul 2008 16:58:35 -0500 To: Henning Schulzrinne , "" From: "James M. Polk" In-Reply-To: <67A83811-40C2-48F3-B22F-B58A83779286@cs.columbia.edu> References: <2DE9A51895931C4CBCAEFA9306AE480E848B68@toroondc254.bell.corp.bce.ca> <2DE9A51895931C4CBCAEFA9306AE480E848BAC@toroondc254.bell.corp.bce.ca> <67A83811-40C2-48F3-B22F-B58A83779286@cs.columbia.edu> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 10 Jul 2008 21:58:33.0334 (UTC) FILETIME=[1895C160:01C8E2D8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1278; t=1215727113; x=1216591113; 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]=20emergency=20call=20terminatio n |Sender:=20; bh=eGSyO96I6TFZWfNBz7UId6ajmVzXYyVhmb0lmE/ZqLM=; b=FFF2mbs35xluB+1H9G6L1PVcijxqVQhRPttNnCsDEH3rWgLoCjkLciJsWr P/od9d9vLMiBfyvrsbLoMjNIoG1DaJn5MvgmM53CXm6FoMkpTySoF/rYSkKE w/b0L0JID3; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: nena-i2_5@listserv.neustar.biz, ecrit@ietf.org Subject: Re: [Ecrit] emergency call termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 04:20 PM 7/10/2008, Henning Schulzrinne wrote: >I assume that preventing BYE from the caller side is mainly meant to >deal with accidental disconnect. Nothing prevents a caller from >turning off the cell phone, removing its battery or unplugging the >land-line phone (or simply muting the microphone). I agree with that >On Jul 10, 2008, at 3:42 PM, wrote: > >>Certainly Marc. >> >>It is also my understanding that current cellular voice services >>have not implemented the network capabilities to enable PSAP control >>over call termination even if the jurisdiction requires/mandates it. >>The reasons for this are still obscure to me. I note however that >>those PSAPs using it are very disappointed of this situation in >>wireless and would like not to repeat it for Next Generation services. >> >>The situation I was referring to was more in line with PSAP >>requirements than with technical limitations. In that sense, if a >>PSAP assumes a certain behavior for devices operating in its >>jurisdiction, it would be up to the device to adjust accordingly. >> >>Thanks, > >_______________________________________________ >Ecrit mailing 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 Jul 10 15:03:32 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87CC43A6A23; Thu, 10 Jul 2008 15:03: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 C6B7A3A6A23 for ; Thu, 10 Jul 2008 15:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vq3+4g+xgKb for ; Thu, 10 Jul 2008 15:03:30 -0700 (PDT) Received: from mail125.messagelabs.com (mail125.messagelabs.com [85.158.136.35]) by core3.amsl.com (Postfix) with ESMTP id 685043A6921 for ; Thu, 10 Jul 2008 15:03:30 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-9.tower-125.messagelabs.com!1215727422!30248462!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [206.47.0.177] Received: (qmail 11737 invoked from network); 10 Jul 2008 22:03:43 -0000 Received: from dm1c8e.bell.ca (HELO TLS.Exchange.Bell.ca) (206.47.0.177) by server-9.tower-125.messagelabs.com with RC4-SHA encrypted SMTP; 10 Jul 2008 22:03:43 -0000 Received: from hub03-wyn.bell.corp.bce.ca (142.182.199.49) by dm1c8e.exchange3.bell.ca (198.235.102.108) with Microsoft SMTP Server id 8.1.278.0; Thu, 10 Jul 2008 18:03:42 -0400 Received: from TOROONDC918.bell.corp.bce.ca (142.182.89.79) by hub03-wyn.bell.corp.bce.ca (142.182.199.49) with Microsoft SMTP Server id 8.1.278.0; Thu, 10 Jul 2008 18:03:42 -0400 Received: from toroondc254.bell.corp.bce.ca ([142.182.4.53]) by TOROONDC918.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 18:03:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 18:03:41 -0400 Message-ID: <2DE9A51895931C4CBCAEFA9306AE480E848BCF@toroondc254.bell.corp.bce.ca> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] emergency call termination Thread-Index: Acji1fkgBaVdbeWjSAOJocjaSqtvawAAEUkQ References: <2DE9A51895931C4CBCAEFA9306AE480E8488A2@toroondc254.bell.corp.bce.ca> <2DE9A51895931C4CBCAEFA9306AE480E848BC4@toroondc254.bell.corp.bce.ca> From: To: , X-OriginalArrivalTime: 10 Jul 2008 22:03:41.0956 (UTC) FILETIME=[D089BC40:01C8E2D8] Cc: nena-i2_5@listserv.neustar.biz Subject: Re: [Ecrit] emergency call termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 James, I'm not sure I understand the question but let me try this answer: By "normal circumstances" I meant an emergency call being processed by a ca= ll taker until such time both agrees the call is over. In that plain vanill= a case, both hang-ups would happen almost synchronously. In other cases, both the caller and the call taker may not have the same no= tion of "the call is over". For some PSAPs, they want to rely on the abilit= y to retain the connection. For other PSAPs, they don't use that. The initial post was asking that the ability for a PSAP to control call ter= mination be made optional and modulated by the location the device is curre= ntly in. Let me know if I'm in the left field here. Thanks, = Guy Caron -----Message d'origine----- De=A0: James M. Polk [mailto:jmpolk@cisco.com] = Envoy=E9=A0: 10 juillet 2008 17:27 =C0=A0: Caron, Guy (A162859); ecrit@ietf.org Cc=A0: nena-i2_5@listserv.neustar.biz Objet=A0: RE: [Ecrit] emergency call termination Guy in-line below At 04:00 PM 7/10/2008, g.caron@bell.ca wrote: >Didn't Canada just have a bad situation occur in which the location >of a caller resulted in the death of a boy? The case involved a >family that was using residential VoIP, and the call taker didn't ask >where they lived; instead relying on "the system" to tell the call >taker where the call originated. The family had moved to Calgary from >the Winnipeg or Toronto area (I can't remember which) and the first >responders went to their old location. The one from the form they had >to fill out by hand, informing anyone who called in on IP, that this >is where to send the responders. > >[GC] Indeed, a very unfortunate and dramatic event that we all wish = >would never happen. My understanding of the series of events is not = >exactly as you described. You are right though that the location = >information "on file" was wrong. The "system" in this case was not = >the E9-1-1 infrastructure though. [JMP] I didn't mean to imply it was. > But I'm sure if that information hadn't been given, and the call = > taker wanted it (but for some reason delayed asking for it), they = > would want to have the ability to prevent the caller from hanging = > up. This is one way >for that not to occur. > >[GC] Absolutely. > >At the end of the day, if both caller and call taker want the call to >end, does it make a difference who's hang-up or button sends >the BYE? It's gonna happen at about the same time, give or take a >half a second. > >[GC] In normal circumstances, I agree. [JMP] so, what are the non-normal circumstances you want this = specified feature removed for, and how common (i.e., at what = frequency) do they occur? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 11 02:59:22 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9295428C15C; Fri, 11 Jul 2008 02:59: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 7D93E28C15C for ; Fri, 11 Jul 2008 02:59:21 -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 J6WHScJ-q8RO for ; Fri, 11 Jul 2008 02:59:20 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 9950728C103 for ; Fri, 11 Jul 2008 02:59:20 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so3371532rvf.49 for ; Fri, 11 Jul 2008 02:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=vH1WFnfGo4pkhURKff1V2GIA8NAPwvEQEHnQmlyS4WI=; b=lnWsZq+Rvytiy9EypCBCRmkAWwaS1ZXnCqAuGX9OaFT1Ep4JMyl4lDbZK09up/5bwI 3SgNVNNIa7TaOtiQR+s0/apDLt25wAm649qaH5DulEHE/ZsKUrpvngDgn3ynhA8Nhwgh piJGB5X9NVOjdQHqSXwFoZcY5CpfH7SpPtgCw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=pp1vFnii5ELR2GPzTQvZMj9fuvRsZZMBzXAl/tUkDdSGO0aKnoiJyZk9Uq8q6q2W5z 5e9omUHNYnfrX36r/wLRu382445pcQitfO4gV1xy2nEnHjcUdttdiBeDGPhNr4vtd3ms OFe7dt7iLHCSiyiuQeP8/sT3tzLE6lOfselHE= Received: by 10.115.78.1 with SMTP id f1mr13492260wal.150.1215770372001; Fri, 11 Jul 2008 02:59:32 -0700 (PDT) Received: by 10.114.36.15 with HTTP; Fri, 11 Jul 2008 02:59:31 -0700 (PDT) Message-ID: Date: Fri, 11 Jul 2008 11:59:31 +0200 From: "Karl Heinz Wolf" To: "Brian Rosen" In-Reply-To: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Disposition: inline References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> Cc: ECRIT Subject: Re: [Ecrit] New versions of -framework and -phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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, thank you for submitting the new versions of your documents. However, I'm afraid you forgot my comments (except the LoSt dialstring "must"). My old posting: http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html In your reply to this mail you agreed to these points. Karl Heinz On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen wrote: > These versions incorporate all last call comments except as I have stated in > prior email. > > The majority of changes have to do with: > * More explicit text and references to -profile for multiple locations > > * Requiring the return of dialstrings on LoST for sos service URNs. > > * Lots of typos and wording changes. > > I did end up adding a couple of requirements, and thus needed to renumber > the requirements, so diffs look bad. > > I ask commenters to look at the text to make sure I made all the changes you > requested (with the exceptions covered in the emails). > > Chairs can consider if they wish to hold a short 2nd WGLC. There are a > couple of substantive changes and added requirements, but not a whole lot > text is modified in any but trivial ways. > > Brian > > _______________________________________________ > Ecrit mailing 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 Jul 11 03:15:09 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD09428C179; Fri, 11 Jul 2008 03:15: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 07E1A28C174 for ; Fri, 11 Jul 2008 03:15:09 -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 MIl8AJ3Tz4tl for ; Fri, 11 Jul 2008 03:15:08 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C629B28C163 for ; Fri, 11 Jul 2008 03:15:07 -0700 (PDT) Received: (qmail invoked by alias); 11 Jul 2008 10:15:23 -0000 Received: from unknown (EHLO [10.183.180.149]) [192.100.124.156] by mail.gmx.net (mp047) with SMTP; 11 Jul 2008 12:15:23 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/baXY9FlrbsXP5dObOIXaGs3+3sIcQklOaSUF6DG n5XcI58SBuWNks Message-ID: <487732B9.3080606@gmx.net> Date: Fri, 11 Jul 2008 13:15:21 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Karl Heinz Wolf References: <20080528194502.7D0D03A6A7A@core3.amsl.com> <486FCA24.8000608@gmx.net> In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ecrit@ietf.org Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-lost-10.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > the reference is the "key" in LoST, isn't it? > so the assumption is that there is a seperate key for the civic, > geodetic and for civic+geodetic location profile (and for every > possible future combination of new profiles) for every service > boundary? I'm asking again because I couldn't find any information on > this in the draft. > Correct. It's a one-to-one mapping. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 11 07:25:07 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF343A6B35; Fri, 11 Jul 2008 07:25: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 D46533A6B33 for ; Fri, 11 Jul 2008 07:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 Zgx7dzThx1pV for ; Fri, 11 Jul 2008 07:25:04 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id CEDD73A6B35 for ; Fri, 11 Jul 2008 07:25:04 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KHJYj-0003TT-7l; Fri, 11 Jul 2008 09:25:17 -0500 From: "Brian Rosen" To: "'Karl Heinz Wolf'" References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> Date: Fri, 11 Jul 2008 10:25:18 -0400 Message-ID: <023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjjPNFazUSS+1e6QKeFWmOCMPqPsgAH0MeA 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: Cc: 'ECRIT' Subject: Re: [Ecrit] New versions of -framework and -phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 sorry, I don't know how I missed these. >page 7: "The phone gets location from the DHCP server in civic >[RFC4676] or geo" -> should it be "and/or"? The text makes clear that multiple locations are problematic. Multiple versions of the same location are problematic. I worry about systems trying to be helpful and giving you a measured location and also giving you a derived (geo coded or reverse geo coded) version of the same location. This does raise yet another issue about this general subject; looking at the list at: http://www.iana.org/assignments/method-tokens There is no method for "derived". So: I will add text to -framework covering this subject I will ask IANA to create a "Derived" method token I will add a requirement to -phonebcp that says if you get both and one is derived, you must use the non-derived value. I've made the other changes in my source file and they will appear in the next version. Brian > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > Sent: Friday, July 11, 2008 6:00 AM > To: Brian Rosen > Cc: ECRIT > Subject: Re: [Ecrit] New versions of -framework and -phonebcp > > Brian, > > thank you for submitting the new versions of your documents. > However, I'm afraid you forgot my comments (except the LoSt dialstring > "must"). > My old posting: > http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html > In your reply to this mail you agreed to these points. > > Karl Heinz > > On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen wrote: > > These versions incorporate all last call comments except as I have > stated in > > prior email. > > > > The majority of changes have to do with: > > * More explicit text and references to -profile for multiple locations > > > > * Requiring the return of dialstrings on LoST for sos service URNs. > > > > * Lots of typos and wording changes. > > > > I did end up adding a couple of requirements, and thus needed to > renumber > > the requirements, so diffs look bad. > > > > I ask commenters to look at the text to make sure I made all the changes > you > > requested (with the exceptions covered in the emails). > > > > Chairs can consider if they wish to hold a short 2nd WGLC. There are a > > couple of substantive changes and added requirements, but not a whole > lot > > text is modified in any but trivial ways. > > > > Brian > > > > _______________________________________________ > > Ecrit mailing 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 Jul 12 02:04:06 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD6E63A692E; Sat, 12 Jul 2008 02:04: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 9076F3A692E for ; Sat, 12 Jul 2008 02:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, 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 SasbFH80WmTf for ; Sat, 12 Jul 2008 02:04:04 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 05D013A68DC for ; Sat, 12 Jul 2008 02:04:03 -0700 (PDT) Received: (qmail invoked by alias); 12 Jul 2008 09:04:22 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp060) with SMTP; 12 Jul 2008 11:04:22 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19O3V4o7QhOyQmFur14vRyRps80vWpH2gpecq6aCZ XGlugE6YyA+nST Message-ID: <48787395.1040507@gmx.net> Date: Sat, 12 Jul 2008 12:04:21 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Brian Rosen References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> <023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com> In-Reply-To: <023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Cc: 'ECRIT' Subject: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Could you describe the semantic of the "Derived" method a bit more? Brian Rosen wrote: > I am sorry, I don't know how I missed these. > > >> page 7: "The phone gets location from the DHCP server in civic >> [RFC4676] or geo" -> should it be "and/or"? >> > The text makes clear that multiple locations are problematic. Multiple > versions of the same location are problematic. I worry about systems trying > to be helpful and giving you a measured location and also giving you a > derived (geo coded or reverse geo coded) version of the same location. > > This does raise yet another issue about this general subject; looking at the > list at: > http://www.iana.org/assignments/method-tokens > There is no method for "derived". So: > I will add text to -framework covering this subject > I will ask IANA to create a "Derived" method token > I will add a requirement to -phonebcp that says if you get both and one is > derived, you must use the non-derived value. > > I've made the other changes in my source file and they will appear in the > next version. > > Brian > >> -----Original Message----- >> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >> Sent: Friday, July 11, 2008 6:00 AM >> To: Brian Rosen >> Cc: ECRIT >> Subject: Re: [Ecrit] New versions of -framework and -phonebcp >> >> Brian, >> >> thank you for submitting the new versions of your documents. >> However, I'm afraid you forgot my comments (except the LoSt dialstring >> "must"). >> My old posting: >> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html >> In your reply to this mail you agreed to these points. >> >> Karl Heinz >> >> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen wrote: >> >>> These versions incorporate all last call comments except as I have >>> >> stated in >> >>> prior email. >>> >>> The majority of changes have to do with: >>> * More explicit text and references to -profile for multiple locations >>> >>> * Requiring the return of dialstrings on LoST for sos service URNs. >>> >>> * Lots of typos and wording changes. >>> >>> I did end up adding a couple of requirements, and thus needed to >>> >> renumber >> >>> the requirements, so diffs look bad. >>> >>> I ask commenters to look at the text to make sure I made all the changes >>> >> you >> >>> requested (with the exceptions covered in the emails). >>> >>> Chairs can consider if they wish to hold a short 2nd WGLC. There are a >>> couple of substantive changes and added requirements, but not a whole >>> >> lot >> >>> text is modified in any but trivial ways. >>> >>> Brian >>> >>> _______________________________________________ >>> Ecrit mailing 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 Sat Jul 12 05:02:36 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9F7A3A6A5E; Sat, 12 Jul 2008 05:02: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 828BF3A6A07 for ; Sat, 12 Jul 2008 05:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.253, 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 Vxpf-Dx8yYJj for ; Sat, 12 Jul 2008 05:02:34 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 25BDC3A67A6 for ; Sat, 12 Jul 2008 05:02:33 -0700 (PDT) Received: (qmail invoked by alias); 12 Jul 2008 12:02:52 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp054) with SMTP; 12 Jul 2008 14:02:52 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+ifakNO8WiVZpZ7EcCq4bgCrOKvrTCW85bXaGbFy dEV8DeHAW49D1H Message-ID: <48789D6D.2010902@gmx.net> Date: Sat, 12 Jul 2008 15:02:53 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Henning Schulzrinne , 'ECRIT' , earlywarning@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Cc: "Murhammer, Leopold" Subject: [Ecrit] draft-norreys-ecrit-authority2individuals-requirements-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, I have re-submitted the "Requirements for Authority-to-Individuals Communication for Emergency Situations" document. Abstract Public safety agencies need to provide information to the general public before and during large-scale emergencies. While many aspects of such systems are specific to national or local jurisdictions, emergencies span such boundaries and notifications need to reach visitors from other jurisdictions. This document summarizes requirements for protocols to alert individuals within a defined geographic area. The document can be found here: http://www.ietf.org/proceedings/staging/draft-norreys-ecrit-authority2individuals-requirements-01.txt (The filename was too long and hence it needs manual processing by the secretary.) Btw, I noticed that the comments by Leopold Murhammer haven't been addressed appropriately. His comments can be found here: http://www.ietf.org/mail-archive/web/ecrit/current/msg04035.html Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 12 06:42:46 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E606D3A6B41; Sat, 12 Jul 2008 06:42: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 369F03A6B41 for ; Sat, 12 Jul 2008 06:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 eWccejpcnb-h for ; Sat, 12 Jul 2008 06:42:44 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id BD92E3A6B3B for ; Sat, 12 Jul 2008 06:42:44 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KHfNN-0004tP-1U; Sat, 12 Jul 2008 08:43:01 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> <023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com> <48787395.1040507@gmx.net> Date: Sat, 12 Jul 2008 09:43:01 -0400 Message-ID: <03eb01c8e425$35b47180$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acjj/kik0jGHUBU2TMisU85i6KWRbgAJqDcA In-Reply-To: <48787395.1040507@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: Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 "Derived" method is used when the PIDF creator has a location available in one form (civic or geo) using another method, and derives a location in the other form. So for example, the determination method might be GPS, which creates a geo and the PIDF includes a civic derived from that geo. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Saturday, July 12, 2008 5:04 AM > To: Brian Rosen > Cc: 'Karl Heinz Wolf'; 'ECRIT' > Subject: "Derived" method > > Could you describe the semantic of the "Derived" method a bit more? > > Brian Rosen wrote: > > I am sorry, I don't know how I missed these. > > > > > >> page 7: "The phone gets location from the DHCP server in civic > >> [RFC4676] or geo" -> should it be "and/or"? > >> > > The text makes clear that multiple locations are problematic. Multiple > > versions of the same location are problematic. I worry about systems > trying > > to be helpful and giving you a measured location and also giving you a > > derived (geo coded or reverse geo coded) version of the same location. > > > > This does raise yet another issue about this general subject; looking at > the > > list at: > > http://www.iana.org/assignments/method-tokens > > There is no method for "derived". So: > > I will add text to -framework covering this subject > > I will ask IANA to create a "Derived" method token > > I will add a requirement to -phonebcp that says if you get both and one > is > > derived, you must use the non-derived value. > > > > I've made the other changes in my source file and they will appear in > the > > next version. > > > > Brian > > > >> -----Original Message----- > >> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > >> Sent: Friday, July 11, 2008 6:00 AM > >> To: Brian Rosen > >> Cc: ECRIT > >> Subject: Re: [Ecrit] New versions of -framework and -phonebcp > >> > >> Brian, > >> > >> thank you for submitting the new versions of your documents. > >> However, I'm afraid you forgot my comments (except the LoSt dialstring > >> "must"). > >> My old posting: > >> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html > >> In your reply to this mail you agreed to these points. > >> > >> Karl Heinz > >> > >> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen > wrote: > >> > >>> These versions incorporate all last call comments except as I have > >>> > >> stated in > >> > >>> prior email. > >>> > >>> The majority of changes have to do with: > >>> * More explicit text and references to -profile for multiple locations > >>> > >>> * Requiring the return of dialstrings on LoST for sos service URNs. > >>> > >>> * Lots of typos and wording changes. > >>> > >>> I did end up adding a couple of requirements, and thus needed to > >>> > >> renumber > >> > >>> the requirements, so diffs look bad. > >>> > >>> I ask commenters to look at the text to make sure I made all the > changes > >>> > >> you > >> > >>> requested (with the exceptions covered in the emails). > >>> > >>> Chairs can consider if they wish to hold a short 2nd WGLC. There are > a > >>> couple of substantive changes and added requirements, but not a whole > >>> > >> lot > >> > >>> text is modified in any but trivial ways. > >>> > >>> Brian > >>> > >>> _______________________________________________ > >>> Ecrit mailing 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 Sat Jul 12 06:48:32 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0066C3A6BAC; Sat, 12 Jul 2008 06:48: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 5406C3A6BAC for ; Sat, 12 Jul 2008 06:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, 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 AMuqawu9QdRz for ; Sat, 12 Jul 2008 06:48:29 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E666E3A6BAA for ; Sat, 12 Jul 2008 06:48:28 -0700 (PDT) Received: (qmail invoked by alias); 12 Jul 2008 13:48:48 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp023) with SMTP; 12 Jul 2008 15:48:48 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX190B94GHwN0hwe51NbDySTyY0aUsOxQo5hcvgHGqX q2oGQjmto6CfZt Message-ID: <4878B640.1050907@gmx.net> Date: Sat, 12 Jul 2008 16:48:48 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Brian Rosen References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> <023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com> <48787395.1040507@gmx.net> <03eb01c8e425$35b47180$640fa8c0@cis.neustar.com> In-Reply-To: <03eb01c8e425$35b47180$640fa8c0@cis.neustar.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Thanks. Brian Rosen wrote: > The "Derived" method is used when the PIDF creator has a location available > in one form (civic or geo) using another method, and derives a location in > the other form. So for example, the determination method might be GPS, > which creates a geo and the PIDF includes a civic derived from that geo. > > Brian > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Saturday, July 12, 2008 5:04 AM >> To: Brian Rosen >> Cc: 'Karl Heinz Wolf'; 'ECRIT' >> Subject: "Derived" method >> >> Could you describe the semantic of the "Derived" method a bit more? >> >> Brian Rosen wrote: >> >>> I am sorry, I don't know how I missed these. >>> >>> >>> >>>> page 7: "The phone gets location from the DHCP server in civic >>>> [RFC4676] or geo" -> should it be "and/or"? >>>> >>>> >>> The text makes clear that multiple locations are problematic. Multiple >>> versions of the same location are problematic. I worry about systems >>> >> trying >> >>> to be helpful and giving you a measured location and also giving you a >>> derived (geo coded or reverse geo coded) version of the same location. >>> >>> This does raise yet another issue about this general subject; looking at >>> >> the >> >>> list at: >>> http://www.iana.org/assignments/method-tokens >>> There is no method for "derived". So: >>> I will add text to -framework covering this subject >>> I will ask IANA to create a "Derived" method token >>> I will add a requirement to -phonebcp that says if you get both and one >>> >> is >> >>> derived, you must use the non-derived value. >>> >>> I've made the other changes in my source file and they will appear in >>> >> the >> >>> next version. >>> >>> Brian >>> >>> >>>> -----Original Message----- >>>> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >>>> Sent: Friday, July 11, 2008 6:00 AM >>>> To: Brian Rosen >>>> Cc: ECRIT >>>> Subject: Re: [Ecrit] New versions of -framework and -phonebcp >>>> >>>> Brian, >>>> >>>> thank you for submitting the new versions of your documents. >>>> However, I'm afraid you forgot my comments (except the LoSt dialstring >>>> "must"). >>>> My old posting: >>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html >>>> In your reply to this mail you agreed to these points. >>>> >>>> Karl Heinz >>>> >>>> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen >>>> >> wrote: >> >>>>> These versions incorporate all last call comments except as I have >>>>> >>>>> >>>> stated in >>>> >>>> >>>>> prior email. >>>>> >>>>> The majority of changes have to do with: >>>>> * More explicit text and references to -profile for multiple locations >>>>> >>>>> * Requiring the return of dialstrings on LoST for sos service URNs. >>>>> >>>>> * Lots of typos and wording changes. >>>>> >>>>> I did end up adding a couple of requirements, and thus needed to >>>>> >>>>> >>>> renumber >>>> >>>> >>>>> the requirements, so diffs look bad. >>>>> >>>>> I ask commenters to look at the text to make sure I made all the >>>>> >> changes >> >>>> you >>>> >>>> >>>>> requested (with the exceptions covered in the emails). >>>>> >>>>> Chairs can consider if they wish to hold a short 2nd WGLC. There are >>>>> >> a >> >>>>> couple of substantive changes and added requirements, but not a whole >>>>> >>>>> >>>> lot >>>> >>>> >>>>> text is modified in any but trivial ways. >>>>> >>>>> Brian >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing 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 Sat Jul 12 07:18:34 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D1ED3A6823; Sat, 12 Jul 2008 07:18:34 -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 E012B3A6823 for ; Sat, 12 Jul 2008 07:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 FOq4TnKabkLV for ; Sat, 12 Jul 2008 07:18:32 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7308F3A67FB for ; Sat, 12 Jul 2008 07:18:32 -0700 (PDT) Received: (qmail invoked by alias); 12 Jul 2008 14:18:52 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp039) with SMTP; 12 Jul 2008 16:18:52 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+BZdUdm86B/VGRF2cVEwjm4fVkbsX7Zz6rElHIYq WLtjx0im/+0PGp Message-ID: <4878BD4C.5070805@gmx.net> Date: Sat, 12 Jul 2008 17:18:52 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Brian Rosen References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> <023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com> <48787395.1040507@gmx.net> <03eb01c8e425$35b47180$640fa8c0@cis.neustar.com> <4878B640.1050907@gmx.net> In-Reply-To: <4878B640.1050907@gmx.net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The problem is a bit with the semantic of the method token given that it was supposed to be used to indicate the location determination method. There are some "wrong" entries in the table already with that semantic since something like "DHCP" refers to an LCP rather than the actual location determination method. Now, I wonder whether it is possible to put more than one token into the method element. The data type is string and hence it would be possible. To pick your example, could you indicate gps derived? Ciao Hannes PS: I wonder whether there is actually a way to deprecate certain tokens from the registry. Nothing is indicated in RFC 4119. "802.11" and "DHCP" "LLDP-MED" really does not belong in there. FCFS as a policy for assignment does not sound useful to me either; expert review would be more useful. Hannes Tschofenig wrote: > Thanks. > > Brian Rosen wrote: >> The "Derived" method is used when the PIDF creator has a location >> available >> in one form (civic or geo) using another method, and derives a >> location in >> the other form. So for example, the determination method might be GPS, >> which creates a geo and the PIDF includes a civic derived from that geo. >> >> Brian >> >> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Saturday, July 12, 2008 5:04 AM >>> To: Brian Rosen >>> Cc: 'Karl Heinz Wolf'; 'ECRIT' >>> Subject: "Derived" method >>> >>> Could you describe the semantic of the "Derived" method a bit more? >>> >>> Brian Rosen wrote: >>> >>>> I am sorry, I don't know how I missed these. >>>> >>>> >>>> >>>>> page 7: "The phone gets location from the DHCP server in civic >>>>> [RFC4676] or geo" -> should it be "and/or"? >>>>> >>>>> >>>> The text makes clear that multiple locations are problematic. Multiple >>>> versions of the same location are problematic. I worry about systems >>>> >>> trying >>> >>>> to be helpful and giving you a measured location and also giving you a >>>> derived (geo coded or reverse geo coded) version of the same location. >>>> >>>> This does raise yet another issue about this general subject; >>>> looking at >>>> >>> the >>> >>>> list at: >>>> http://www.iana.org/assignments/method-tokens >>>> There is no method for "derived". So: >>>> I will add text to -framework covering this subject >>>> I will ask IANA to create a "Derived" method token >>>> I will add a requirement to -phonebcp that says if you get both and >>>> one >>>> >>> is >>> >>>> derived, you must use the non-derived value. >>>> >>>> I've made the other changes in my source file and they will appear in >>>> >>> the >>> >>>> next version. >>>> >>>> Brian >>>> >>>> >>>>> -----Original Message----- >>>>> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >>>>> Sent: Friday, July 11, 2008 6:00 AM >>>>> To: Brian Rosen >>>>> Cc: ECRIT >>>>> Subject: Re: [Ecrit] New versions of -framework and -phonebcp >>>>> >>>>> Brian, >>>>> >>>>> thank you for submitting the new versions of your documents. >>>>> However, I'm afraid you forgot my comments (except the LoSt >>>>> dialstring >>>>> "must"). >>>>> My old posting: >>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html >>>>> In your reply to this mail you agreed to these points. >>>>> >>>>> Karl Heinz >>>>> >>>>> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen >>>>> >>> wrote: >>> >>>>>> These versions incorporate all last call comments except as I have >>>>>> >>>>>> >>>>> stated in >>>>> >>>>> >>>>>> prior email. >>>>>> >>>>>> The majority of changes have to do with: >>>>>> * More explicit text and references to -profile for multiple >>>>>> locations >>>>>> >>>>>> * Requiring the return of dialstrings on LoST for sos service URNs. >>>>>> >>>>>> * Lots of typos and wording changes. >>>>>> >>>>>> I did end up adding a couple of requirements, and thus needed to >>>>>> >>>>>> >>>>> renumber >>>>> >>>>> >>>>>> the requirements, so diffs look bad. >>>>>> >>>>>> I ask commenters to look at the text to make sure I made all the >>>>>> >>> changes >>> >>>>> you >>>>> >>>>> >>>>>> requested (with the exceptions covered in the emails). >>>>>> >>>>>> Chairs can consider if they wish to hold a short 2nd WGLC. There >>>>>> are >>>>>> >>> a >>> >>>>>> couple of substantive changes and added requirements, but not a >>>>>> whole >>>>>> >>>>>> >>>>> lot >>>>> >>>>> >>>>>> text is modified in any but trivial ways. >>>>>> >>>>>> Brian >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing 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 Sat Jul 12 10:43:53 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74E43A6ABC; Sat, 12 Jul 2008 10:43: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 152523A6ABC for ; Sat, 12 Jul 2008 10:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 XYLKHQUlJW2p for ; Sat, 12 Jul 2008 10:43:50 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 18BCE3A6AAB for ; Sat, 12 Jul 2008 10:43:49 -0700 (PDT) Received: (qmail invoked by alias); 12 Jul 2008 17:44:09 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp065) with SMTP; 12 Jul 2008 19:44:09 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18i45pAHB8iHxYU7eNdHdiLG5BIsr971EUmg31FJP htDO91C1c/EGPV Message-ID: <4878ED65.9080709@gmx.net> Date: Sat, 12 Jul 2008 20:44:05 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Art Botterell References: <48789D6D.2010902@gmx.net> <02969261-5C18-44F8-98CD-AAA82AEE80B5@incident.com> In-Reply-To: <02969261-5C18-44F8-98CD-AAA82AEE80B5@incident.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: earlywarning@ietf.org, 'ECRIT' , "Murhammer, Leopold" Subject: Re: [Ecrit] [earlywarning] draft-norreys-ecrit-authority2individuals-requirements-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Art, thanks for your question. Art Botterell wrote: > Hello Hannes - > > Very very interesting. I'm curious, though, your draft makes no > mention of the OASIS Common Alerting Protocol standard, which is also > ITU recommendation X.1303. I'm sure that wasn't an oversight, but > maybe you could say a few words about how this initiative might relate > to that one. > We did not want to put a solution into the requirements document. Based on the previous adhoc meeting on early warning, I guess it was mid last year, I got the impression that the participants were looking for a way to carry CAP documents using some IETF protocols. The following document is an example of such an approach: http://www.ietf.org/internet-drafts/draft-rosen-sipping-cap-02.txt Abstract: The Common Alerting Protocol (CAP) is an XML document format for exchanging emergency alerts and public warnings. This document allows CAP documents to be distributed via the event notification mechanism available with the Session Initiation Protocol (SIP). This is very similar to CAP over XMPP: http://www.xmpp.org/extensions/xep-0127.html > Also, on a more substantive level, I'm wondering whether there might > be a bit of a tension between Requirement 1 ("real-time delivery") > and Requirement 9 ("independent of the underlying access network > technology"). How would you envision specifying latency parameters > without creating dependencies on the transport layer? > That's a good point. We have also noticed in the early warning meeting (see http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/EarlyWarningBarBOF) we had that there are clearly different types of alerts we need to differentiate and some have real-time requiremens and other do not have them. Additionally, it depends on the person you talk to; some prefer higher layer solutions only and others again want to go all the way down to the link layer. So, there is a bit of an architectural question looming over us. Unfortunately, we haven't gotten a good grip on the big picture yet. I believe we are still in the phase of figuring out what the "customers" of this technology are going to be and how we can best interact with them. Finally, there is the question on what "real-time" precisely means. Many years ago I worked in a group dealing with real-time operating systems and using their terminology, I would argue we are talking about "soft real-time" here and not "hard real time". But we need to flesh these things out a bit more. I do see a clear problem with the deployment difficulty one creates when demanding too much. If we could work out a solution that does not require any changes to layer 2 and layer 3 devices then we are in a much better position when it comes to a realistic deployment story for something on the Internet. Ciao Hannes > Thanks! > > - Art > > Art Botterell > Community Warning System Manager > Office of the Sheriff > Contra Costa County (California) > http://www.cocosheriff.org/cws/ > > > On Jul 12, 2008, at 7/12/08 5:02 AM, Hannes Tschofenig wrote: > >> Hi all, >> >> I have re-submitted the "Requirements for Authority-to-Individuals >> Communication for Emergency Situations" document. >> >> Abstract >> >> Public safety agencies need to provide information to the general >> public before and during large-scale emergencies. While many aspects >> of such systems are specific to national or local jurisdictions, >> emergencies span such boundaries and notifications need to reach >> visitors from other jurisdictions. This document summarizes >> requirements for protocols to alert individuals within a defined >> f geographic area. >> >> The document can be found here: >> http://www.ietf.org/proceedings/staging/draft-norreys-ecrit-authority2individuals-requirements-01.txt >> >> (The filename was too long and hence it needs manual processing by >> the secretary.) >> >> Btw, I noticed that the comments by Leopold Murhammer haven't been >> addressed appropriately. >> His comments can be found here: >> http://www.ietf.org/mail-archive/web/ecrit/current/msg04035.html >> >> Ciao >> Hannes >> >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 12 19:39:53 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DACD53A686D; Sat, 12 Jul 2008 19:39: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 849993A686D for ; Sat, 12 Jul 2008 19:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[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 ee-rsdb2OfKt for ; Sat, 12 Jul 2008 19:39:52 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 6613E3A6836 for ; Sat, 12 Jul 2008 19:39:52 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_07_12_21_55_18 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, 12 Jul 2008 21:55:17 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 12 Jul 2008 21:40:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 12 Jul 2008 21:37:23 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] "Derived" method Thread-Index: Acjj/kqatWspRDNjTpGlsvIYOA1ZHwAkxbp+ References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> <023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com> <48787395.1040507@gmx.net> From: "Winterbottom, James" To: "Hannes Tschofenig" , "Brian Rosen" X-OriginalArrivalTime: 13 Jul 2008 02:40:08.0978 (UTC) FILETIME=[C3FFEF20:01C8E491] Cc: ECRIT Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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, For derived to really have a clear meaning it needs to be totally unambiguous what the location is derived from. The example I always hear is a civic address derived from a geodetic shape, or vice versa. In this case, you need to provide both locations in the PIDF-LO document, and somehow, there needs to be a link between them. Simply havinf both locations in the same document isn't sufficient, I think you need the equivalent of an tag, or something like that. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig Sent: Sat 7/12/2008 4:04 AM To: Brian Rosen Cc: 'ECRIT' Subject: [Ecrit] "Derived" method Could you describe the semantic of the "Derived" method a bit more? Brian Rosen wrote: > I am sorry, I don't know how I missed these. > > >> page 7: "The phone gets location from the DHCP server in civic >> [RFC4676] or geo" -> should it be "and/or"? >> > The text makes clear that multiple locations are problematic. Multiple > versions of the same location are problematic. I worry about systems trying > to be helpful and giving you a measured location and also giving you a > derived (geo coded or reverse geo coded) version of the same location. > > This does raise yet another issue about this general subject; looking at the > list at: > http://www.iana.org/assignments/method-tokens > There is no method for "derived". So: > I will add text to -framework covering this subject > I will ask IANA to create a "Derived" method token > I will add a requirement to -phonebcp that says if you get both and one is > derived, you must use the non-derived value. > > I've made the other changes in my source file and they will appear in the > next version. > > Brian > >> -----Original Message----- >> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >> Sent: Friday, July 11, 2008 6:00 AM >> To: Brian Rosen >> Cc: ECRIT >> Subject: Re: [Ecrit] New versions of -framework and -phonebcp >> >> Brian, >> >> thank you for submitting the new versions of your documents. >> However, I'm afraid you forgot my comments (except the LoSt dialstring >> "must"). >> My old posting: >> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html >> In your reply to this mail you agreed to these points. >> >> Karl Heinz >> >> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen wrote: >> >>> These versions incorporate all last call comments except as I have >>> >> stated in >> >>> prior email. >>> >>> The majority of changes have to do with: >>> * More explicit text and references to -profile for multiple locations >>> >>> * Requiring the return of dialstrings on LoST for sos service URNs. >>> >>> * Lots of typos and wording changes. >>> >>> I did end up adding a couple of requirements, and thus needed to >>> >> renumber >> >>> the requirements, so diffs look bad. >>> >>> I ask commenters to look at the text to make sure I made all the changes >>> >> you >> >>> requested (with the exceptions covered in the emails). >>> >>> Chairs can consider if they wish to hold a short 2nd WGLC. There are a >>> couple of substantive changes and added requirements, but not a whole >>> >> lot >> >>> text is modified in any but trivial ways. >>> >>> Brian >>> >>> _______________________________________________ >>> Ecrit mailing 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 Jul 13 08:17:54 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE7EB3A698B; Sun, 13 Jul 2008 08:17: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 4B87A3A698B for ; Sun, 13 Jul 2008 08:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 HsWG51naPftT for ; Sun, 13 Jul 2008 08:17:53 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 22B553A68B3 for ; Sun, 13 Jul 2008 08:17:53 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KI3L1-0005Gj-47; Sun, 13 Jul 2008 10:18:11 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Hannes Tschofenig'" References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> <023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com> <48787395.1040507@gmx.net> Date: Sun, 13 Jul 2008 11:18:12 -0400 Message-ID: <053301c8e4fb$ac68e960$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acjj/kqatWspRDNjTpGlsvIYOA1ZHwAkxbp+ABp3x9A= 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: Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 get quite carried away with all the possibilities, and there is no reason to be carried away. The possibilities are: 1. There is exactly one location, and it's marked "Derived". There is no need for more information. 2. There are exactly two locations, and one is marked "Derived". This means the other is the original 3. There are more than two locations and one or more is marked "Derived". I think we can ignore this case, or at least say that there is no way to understand what is derived from what. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Saturday, July 12, 2008 10:37 PM > To: Hannes Tschofenig; Brian Rosen > Cc: ECRIT > Subject: RE: [Ecrit] "Derived" method > > Hi Brian, > > For derived to really have a clear meaning it needs to be totally > unambiguous what the location is derived from. > The example I always hear is a civic address derived from a geodetic > shape, or vice versa. In this case, you need to provide both locations in > the PIDF-LO document, and somehow, there needs to be a link between them. > Simply havinf both locations in the same document isn't sufficient, I > think you need the equivalent of an tag, or something like that. > > Cheers > James > > > > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > Sent: Sat 7/12/2008 4:04 AM > To: Brian Rosen > Cc: 'ECRIT' > Subject: [Ecrit] "Derived" method > > Could you describe the semantic of the "Derived" method a bit more? > > Brian Rosen wrote: > > I am sorry, I don't know how I missed these. > > > > > >> page 7: "The phone gets location from the DHCP server in civic > >> [RFC4676] or geo" -> should it be "and/or"? > >> > > The text makes clear that multiple locations are problematic. Multiple > > versions of the same location are problematic. I worry about systems > trying > > to be helpful and giving you a measured location and also giving you a > > derived (geo coded or reverse geo coded) version of the same location. > > > > This does raise yet another issue about this general subject; looking at > the > > list at: > > http://www.iana.org/assignments/method-tokens > > There is no method for "derived". So: > > I will add text to -framework covering this subject > > I will ask IANA to create a "Derived" method token > > I will add a requirement to -phonebcp that says if you get both and one > is > > derived, you must use the non-derived value. > > > > I've made the other changes in my source file and they will appear in > the > > next version. > > > > Brian > > > >> -----Original Message----- > >> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > >> Sent: Friday, July 11, 2008 6:00 AM > >> To: Brian Rosen > >> Cc: ECRIT > >> Subject: Re: [Ecrit] New versions of -framework and -phonebcp > >> > >> Brian, > >> > >> thank you for submitting the new versions of your documents. > >> However, I'm afraid you forgot my comments (except the LoSt dialstring > >> "must"). > >> My old posting: > >> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html > >> In your reply to this mail you agreed to these points. > >> > >> Karl Heinz > >> > >> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen > wrote: > >> > >>> These versions incorporate all last call comments except as I have > >>> > >> stated in > >> > >>> prior email. > >>> > >>> The majority of changes have to do with: > >>> * More explicit text and references to -profile for multiple locations > >>> > >>> * Requiring the return of dialstrings on LoST for sos service URNs. > >>> > >>> * Lots of typos and wording changes. > >>> > >>> I did end up adding a couple of requirements, and thus needed to > >>> > >> renumber > >> > >>> the requirements, so diffs look bad. > >>> > >>> I ask commenters to look at the text to make sure I made all the > changes > >>> > >> you > >> > >>> requested (with the exceptions covered in the emails). > >>> > >>> Chairs can consider if they wish to hold a short 2nd WGLC. There are > a > >>> couple of substantive changes and added requirements, but not a whole > >>> > >> lot > >> > >>> text is modified in any but trivial ways. > >>> > >>> Brian > >>> > >>> _______________________________________________ > >>> Ecrit mailing 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 Jul 13 23:56:07 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A89323A6A98; Sun, 13 Jul 2008 23: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 497863A6A98 for ; Sun, 13 Jul 2008 23:56:06 -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 AJucyZ949uIE for ; Sun, 13 Jul 2008 23:56:05 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by core3.amsl.com (Postfix) with ESMTP id 3AD553A69C2 for ; Sun, 13 Jul 2008 23:56:04 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so2512856pyg.24 for ; Sun, 13 Jul 2008 23:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=nSRzwT5VOCTPRjCFrDdK94YIM3u4HT+W00VXAFX/Ii8=; b=EMLEC/xxBgYhNU8+Ns5pdD5Iz0rYfTfNqOPoYuRruecX2co6NwEUoBL9lpGCjO0Lxw /H6q58PZJiAvgUVNBlzAyR/c1LRDlDwc/NwE+OXUNY3ROWZe2LLTJzbitaztGXQJgO0U sey7uLlwFxDSX+O4PQNL1wncGAAXYzNikKe2s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Zg+IXhhLvOGZcnaHFDZ5xSvdjVqAE9fclVSvhiaUxgbjjsHF5Jz9BdLdqQOP1SlzX/ /QZcO6zYMZGKSsv/q7p9L+rtiQObtF6lOPqCBz1n+KjASyLa47XurZqxlMVs/r7BdEGT bQdTXZGc1qEgfZwxgutp16tmdBMu96YEhsy/Q= Received: by 10.115.50.5 with SMTP id c5mr11035425wak.60.1216018587619; Sun, 13 Jul 2008 23:56:27 -0700 (PDT) Received: by 10.114.36.15 with HTTP; Sun, 13 Jul 2008 23:56:27 -0700 (PDT) Message-ID: Date: Mon, 14 Jul 2008 08:56:27 +0200 From: "Karl Heinz Wolf" To: "Brian Rosen" In-Reply-To: <023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Disposition: inline References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> <023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com> Cc: ECRIT Subject: Re: [Ecrit] New versions of -framework and -phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Thank you for incorporating my comments. > > This does raise yet another issue about this general subject; looking at the > list at: > http://www.iana.org/assignments/method-tokens > There is no method for "derived". So: > I will add text to -framework covering this subject > I will ask IANA to create a "Derived" method token > I will add a requirement to -phonebcp that says if you get both and one is > derived, you must use the non-derived value. how should a DHCP server for example indicate "Derived" then? karl heinz > > I've made the other changes in my source file and they will appear in the > next version. > > Brian >> -----Original Message----- >> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >> Sent: Friday, July 11, 2008 6:00 AM >> To: Brian Rosen >> Cc: ECRIT >> Subject: Re: [Ecrit] New versions of -framework and -phonebcp >> >> Brian, >> >> thank you for submitting the new versions of your documents. >> However, I'm afraid you forgot my comments (except the LoSt dialstring >> "must"). >> My old posting: >> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html >> In your reply to this mail you agreed to these points. >> >> Karl Heinz >> >> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen wrote: >> > These versions incorporate all last call comments except as I have >> stated in >> > prior email. >> > >> > The majority of changes have to do with: >> > * More explicit text and references to -profile for multiple locations >> > >> > * Requiring the return of dialstrings on LoST for sos service URNs. >> > >> > * Lots of typos and wording changes. >> > >> > I did end up adding a couple of requirements, and thus needed to >> renumber >> > the requirements, so diffs look bad. >> > >> > I ask commenters to look at the text to make sure I made all the changes >> you >> > requested (with the exceptions covered in the emails). >> > >> > Chairs can consider if they wish to hold a short 2nd WGLC. There are a >> > couple of substantive changes and added requirements, but not a whole >> lot >> > text is modified in any but trivial ways. >> > >> > Brian >> > >> > _______________________________________________ >> > Ecrit mailing 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 Jul 14 08:00:01 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3ABB28C207; Mon, 14 Jul 2008 08: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 EA96328C189; Mon, 14 Jul 2008 07:59:59 -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 rppdFJDVz+CQ; Mon, 14 Jul 2008 07:59:55 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 735CE28C182; Mon, 14 Jul 2008 07:59:52 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 16:00:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 16:00:10 +0100 Message-ID: <20B524BAC1567F48AE039F74BD294D190359E03A@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <02969261-5C18-44F8-98CD-AAA82AEE80B5@incident.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [earlywarning]draft-norreys-ecrit-authority2individuals-requirements-01.txt Thread-Index: AcjkQYBJUFBtDM2mRGqLY6hq7n5bKABfzDOw From: To: , X-OriginalArrivalTime: 14 Jul 2008 15:00:14.0512 (UTC) FILETIME=[522C7300:01C8E5C2] Cc: earlywarning@ietf.org, ecrit@ietf.org, leopold.murhammer@siemens.com Subject: Re: [Ecrit] [earlywarning]draft-norreys-ecrit-authority2individuals-requirements-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Art This draft is a requirements draft whereas the OASIS CAP is a protocol solution to a part of overall problem in this space i.e. how to convey the emergency early message. So when the solutions are agreed upon then CAP may be part of this but first of all we need to get the requirements agreed first. You are correct with your second point and it was agreed that the words should reflect the outcome of the ad hoc meeting where this point was raised. Why is a real time solutions required for a early warning for a flood warning in two hours does not require real time procedures, however an early warning to get everyone out of a particular area because a gas leak has been found does require real time solutions. What is needed is to word the text to reflect the type of emergency scenario e.g. "The early warning is given in a time pertinent to the emergency situation" Regards Steve Norreys -----Original Message----- From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org] On Behalf Of Art Botterell Sent: 12 July 2008 18:05 To: Hannes Tschofenig Cc: earlywarning@ietf.org; 'ECRIT'; Murhammer, Leopold Subject: Re: [earlywarning]draft-norreys-ecrit-authority2individuals-requirements-01. txt Hello Hannes - Very very interesting. I'm curious, though, your draft makes no mention of the OASIS Common Alerting Protocol standard, which is also ITU recommendation X.1303. I'm sure that wasn't an oversight, but maybe you could say a few words about how this initiative might relate to that one. Also, on a more substantive level, I'm wondering whether there might be a bit of a tension between Requirement 1 ("real-time delivery") and Requirement 9 ("independent of the underlying access network technology"). How would you envision specifying latency parameters without creating dependencies on the transport layer? Thanks! - Art Art Botterell Community Warning System Manager Office of the Sheriff Contra Costa County (California) http://www.cocosheriff.org/cws/ On Jul 12, 2008, at 7/12/08 5:02 AM, Hannes Tschofenig wrote: > Hi all, > > I have re-submitted the "Requirements for Authority-to-Individuals > Communication for Emergency Situations" document. > > Abstract > > Public safety agencies need to provide information to the general > public before and during large-scale emergencies. While many aspects > of such systems are specific to national or local jurisdictions, > emergencies span such boundaries and notifications need to reach > visitors from other jurisdictions. This document summarizes > requirements for protocols to alert individuals within a defined > geographic area. > > The document can be found here: > http://www.ietf.org/proceedings/staging/draft-norreys-ecrit-authority2in dividuals-requirements-01.txt > (The filename was too long and hence it needs manual processing by > the secretary.) > > Btw, I noticed that the comments by Leopold Murhammer haven't been > addressed appropriately. > His comments can be found here: http://www.ietf.org/mail-archive/web/ecrit/current/msg04035.html > > Ciao > Hannes > > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning _______________________________________________ earlywarning mailing list earlywarning@ietf.org https://www.ietf.org/mailman/listinfo/earlywarning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 14 10:17:43 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C99A73A6842; Mon, 14 Jul 2008 10:17: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 1698828C1AE for ; Mon, 14 Jul 2008 10:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdbkTX1vKFWF for ; Mon, 14 Jul 2008 10:17:40 -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 398763A6809 for ; Mon, 14 Jul 2008 10:17:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,360,1212364800"; d="scan'208";a="52713199" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 14 Jul 2008 17:18:06 +0000 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 m6EHI6TY016715; Mon, 14 Jul 2008 10:18:06 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6EHI6N6026432; Mon, 14 Jul 2008 17:18:06 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 10:18:06 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.84.1]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 10:18:05 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Jul 2008 12:18:09 -0500 To: Hannes Tschofenig From: "James M. Polk" In-Reply-To: <4878BD4C.5070805@gmx.net> References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> <023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com> <48787395.1040507@gmx.net> <03eb01c8e425$35b47180$640fa8c0@cis.neustar.com> <4878B640.1050907@gmx.net> <4878BD4C.5070805@gmx.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 14 Jul 2008 17:18:05.0926 (UTC) FILETIME=[94521060:01C8E5D5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6647; t=1216055886; x=1216919886; 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]=20=22Derived=22=20method |Sender:=20; bh=NE8q4a6W4d84QZ6YLekYVT/URToYuYpLFQj2UmYju2U=; b=jtpgXczNY8CX27R2hCn2Ign6+yIjyTCudhjoNjqCSTrjQR+vdWIUSLKagv cZ3V7rC+enbjlzWjCIcMQbtZ+zsRQEbgaKj1SdExSx0nqNEKWR589WJB/7ys 75mgXhb4lxhyODbW0jUWEfDVzdEMY2X4dCCPavOwSsFL9JaCg19bc=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 09:18 AM 7/12/2008, Hannes Tschofenig wrote: >The problem is a bit with the semantic of the method token given >that it was supposed to be used to indicate the location determination method. this is simply not true. Your definition is adding meaning that isn't there. The element is the indication, solely created by the endpoint (as an LG), of how it received (i.e., "discovered") location information (not LO, but LI). Case in point, if a target has a sighter that derives location based on triangulating the position of the target, yet delivers that LI via DHCP, the would NOT say triangulation it would say dhcp and be correct. >There are some "wrong" entries in the table already with that >semantic since something like "DHCP" refers to an LCP rather than >the actual location determination method. This is not true either. If a target (as an LG) discovers its LI from DHCP (Option 99 or 123), then this is the dhcp James W. added some additional semantics to the additional values without running them by the WG when he IANA registered them, so the non-4119 defined values haven't been fully vetted. This is because 4119 doesn't require any review of any kind before adding new IANA entries to this registry. >Now, I wonder whether it is possible to put more than one token into >the method element. The data type is string and hence it would be possible. > >To pick your example, could you indicate gps derived? > >Ciao >Hannes > >PS: I wonder whether there is actually a way to deprecate certain >tokens from the registry. Nothing is indicated in RFC 4119. "802.11" >and "DHCP" "LLDP-MED" really does not belong in there. FCFS as a >policy for assignment does not sound useful to me either; expert >review would be more useful. Hennes - these 4119 values were the only ones that ever were "expert reviewed", if you consider Geopriv a place where that can take place. BTW -- you were there for this expert review... perhaps you will reconsider this stance once you re-evaluate how these entries are 4119 intended. >Hannes Tschofenig wrote: >>Thanks. >> >>Brian Rosen wrote: >>>The "Derived" method is used when the PIDF creator has a location available >>>in one form (civic or geo) using another method, and derives a location in >>>the other form. So for example, the determination method might be GPS, >>>which creates a geo and the PIDF includes a civic derived from that geo. >>> >>>Brian >>> >>> >>>>-----Original Message----- >>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>Sent: Saturday, July 12, 2008 5:04 AM >>>>To: Brian Rosen >>>>Cc: 'Karl Heinz Wolf'; 'ECRIT' >>>>Subject: "Derived" method >>>> >>>>Could you describe the semantic of the "Derived" method a bit more? >>>> >>>>Brian Rosen wrote: >>>> >>>>>I am sorry, I don't know how I missed these. >>>>> >>>>> >>>>> >>>>>>page 7: "The phone gets location from the DHCP server in civic >>>>>>[RFC4676] or geo" -> should it be "and/or"? >>>>>> >>>>>> >>>>>The text makes clear that multiple locations are problematic. Multiple >>>>>versions of the same location are problematic. I worry about systems >>>>> >>>>trying >>>> >>>>>to be helpful and giving you a measured location and also giving you a >>>>>derived (geo coded or reverse geo coded) version of the same location. >>>>> >>>>>This does raise yet another issue about this general subject; looking at >>>>> >>>>the >>>> >>>>>list at: >>>>>http://www.iana.org/assignments/method-tokens >>>>>There is no method for "derived". So: >>>>>I will add text to -framework covering this subject >>>>>I will ask IANA to create a "Derived" method token >>>>>I will add a requirement to -phonebcp that says if you get both and one >>>>> >>>>is >>>> >>>>>derived, you must use the non-derived value. >>>>> >>>>>I've made the other changes in my source file and they will appear in >>>>> >>>>the >>>> >>>>>next version. >>>>> >>>>>Brian >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >>>>>>Sent: Friday, July 11, 2008 6:00 AM >>>>>>To: Brian Rosen >>>>>>Cc: ECRIT >>>>>>Subject: Re: [Ecrit] New versions of -framework and -phonebcp >>>>>> >>>>>>Brian, >>>>>> >>>>>>thank you for submitting the new versions of your documents. >>>>>>However, I'm afraid you forgot my comments (except the LoSt dialstring >>>>>>"must"). >>>>>>My old posting: >>>>>>http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html >>>>>>In your reply to this mail you agreed to these points. >>>>>> >>>>>>Karl Heinz >>>>>> >>>>>>On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen >>>>>> >>>>wrote: >>>> >>>>>>>These versions incorporate all last call comments except as I have >>>>>>> >>>>>>> >>>>>>stated in >>>>>> >>>>>> >>>>>>>prior email. >>>>>>> >>>>>>>The majority of changes have to do with: >>>>>>>* More explicit text and references to -profile for multiple locations >>>>>>> >>>>>>>* Requiring the return of dialstrings on LoST for sos service URNs. >>>>>>> >>>>>>>* Lots of typos and wording changes. >>>>>>> >>>>>>>I did end up adding a couple of requirements, and thus needed to >>>>>>> >>>>>>> >>>>>>renumber >>>>>> >>>>>> >>>>>>>the requirements, so diffs look bad. >>>>>>> >>>>>>>I ask commenters to look at the text to make sure I made all the >>>>>>> >>>>changes >>>> >>>>>>you >>>>>> >>>>>> >>>>>>>requested (with the exceptions covered in the emails). >>>>>>> >>>>>>>Chairs can consider if they wish to hold a short 2nd WGLC. There are >>>>>>> >>>>a >>>> >>>>>>>couple of substantive changes and added requirements, but not a whole >>>>>>> >>>>>>> >>>>>>lot >>>>>> >>>>>> >>>>>>>text is modified in any but trivial ways. >>>>>>> >>>>>>>Brian >>>>>>> >>>>>>>_______________________________________________ >>>>>>>Ecrit mailing 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 Mon Jul 14 10:29:56 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C70033A6941; Mon, 14 Jul 2008 10:29: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 205EE3A6A3B for ; Mon, 14 Jul 2008 10:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.202, 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 tJDHSZwljBDt for ; Mon, 14 Jul 2008 10:29:54 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0832D3A6941 for ; Mon, 14 Jul 2008 10:29:53 -0700 (PDT) Received: (qmail invoked by alias); 14 Jul 2008 17:30:19 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp045) with SMTP; 14 Jul 2008 19:30:19 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18JqAI+RosJEKwdmlzRWmtaQRGzdhoO9oltUjPJ7X IHuBIhJN+VEpOb Message-ID: <487B8D31.4000402@gmx.net> Date: Mon, 14 Jul 2008 20:30:25 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "James M. Polk" References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> <023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com> <48787395.1040507@gmx.net> <03eb01c8e425$35b47180$640fa8c0@cis.neustar.com> <4878B640.1050907@gmx.net> <4878BD4C.5070805@gmx.net> In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.48 Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org RFC 4119 isn't super exhaustive in the description of the semantic of the element and what it is being used for. What could be more useful for the Location Recipient to know: * Location was obtained using DHCP, or LLDP-MED OR * Location was determined using manual configuration, wiremap database, triangulation. Ciao Hannes James M. Polk wrote: > At 09:18 AM 7/12/2008, Hannes Tschofenig wrote: >> The problem is a bit with the semantic of the method token given that >> it was supposed to be used to indicate the location determination >> method. > > this is simply not true. Your definition is adding meaning that isn't > there. > > The element is the indication, solely created by the endpoint > (as an LG), of how it received (i.e., "discovered") location > information (not LO, but LI). > > Case in point, if a target has a sighter that derives location based > on triangulating the position of the target, yet delivers that LI via > DHCP, the would NOT say > > triangulation > > it would say > > dhcp > > and be correct. > >> There are some "wrong" entries in the table already with that >> semantic since something like "DHCP" refers to an LCP rather than the >> actual location determination method. > > This is not true either. If a target (as an LG) discovers its LI from > DHCP (Option 99 or 123), then this is the > > dhcp > > James W. added some additional semantics to the additional values > without running them by the WG when he IANA registered them, so the > non-4119 defined values haven't been fully vetted. > > This is because 4119 doesn't require any review of any kind before > adding new IANA entries to this registry. > > > >> Now, I wonder whether it is possible to put more than one token into >> the method element. The data type is string and hence it would be >> possible. >> >> To pick your example, could you indicate gps derived? >> >> Ciao >> Hannes >> >> PS: I wonder whether there is actually a way to deprecate certain >> tokens from the registry. Nothing is indicated in RFC 4119. "802.11" >> and "DHCP" "LLDP-MED" really does not belong in there. FCFS as a >> policy for assignment does not sound useful to me either; expert >> review would be more useful. > > Hennes - these 4119 values were the only ones that ever were "expert > reviewed", if you consider Geopriv a place where that can take place. > > BTW -- you were there for this expert review... perhaps you will > reconsider this stance once you re-evaluate how these entries are 4119 > intended. > > > > >> Hannes Tschofenig wrote: >>> Thanks. >>> >>> Brian Rosen wrote: >>>> The "Derived" method is used when the PIDF creator has a location >>>> available >>>> in one form (civic or geo) using another method, and derives a >>>> location in >>>> the other form. So for example, the determination method might be >>>> GPS, >>>> which creates a geo and the PIDF includes a civic derived from that >>>> geo. >>>> >>>> Brian >>>> >>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Sent: Saturday, July 12, 2008 5:04 AM >>>>> To: Brian Rosen >>>>> Cc: 'Karl Heinz Wolf'; 'ECRIT' >>>>> Subject: "Derived" method >>>>> >>>>> Could you describe the semantic of the "Derived" method a bit more? >>>>> >>>>> Brian Rosen wrote: >>>>> >>>>>> I am sorry, I don't know how I missed these. >>>>>> >>>>>> >>>>>> >>>>>>> page 7: "The phone gets location from the DHCP server in civic >>>>>>> [RFC4676] or geo" -> should it be "and/or"? >>>>>>> >>>>>>> >>>>>> The text makes clear that multiple locations are problematic. >>>>>> Multiple >>>>>> versions of the same location are problematic. I worry about >>>>>> systems >>>>>> >>>>> trying >>>>> >>>>>> to be helpful and giving you a measured location and also giving >>>>>> you a >>>>>> derived (geo coded or reverse geo coded) version of the same >>>>>> location. >>>>>> >>>>>> This does raise yet another issue about this general subject; >>>>>> looking at >>>>>> >>>>> the >>>>> >>>>>> list at: >>>>>> http://www.iana.org/assignments/method-tokens >>>>>> There is no method for "derived". So: >>>>>> I will add text to -framework covering this subject >>>>>> I will ask IANA to create a "Derived" method token >>>>>> I will add a requirement to -phonebcp that says if you get both >>>>>> and one >>>>>> >>>>> is >>>>> >>>>>> derived, you must use the non-derived value. >>>>>> >>>>>> I've made the other changes in my source file and they will >>>>>> appear in >>>>>> >>>>> the >>>>> >>>>>> next version. >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >>>>>>> Sent: Friday, July 11, 2008 6:00 AM >>>>>>> To: Brian Rosen >>>>>>> Cc: ECRIT >>>>>>> Subject: Re: [Ecrit] New versions of -framework and -phonebcp >>>>>>> >>>>>>> Brian, >>>>>>> >>>>>>> thank you for submitting the new versions of your documents. >>>>>>> However, I'm afraid you forgot my comments (except the LoSt >>>>>>> dialstring >>>>>>> "must"). >>>>>>> My old posting: >>>>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html >>>>>>> In your reply to this mail you agreed to these points. >>>>>>> >>>>>>> Karl Heinz >>>>>>> >>>>>>> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen >>>>>>> >>>>> wrote: >>>>> >>>>>>>> These versions incorporate all last call comments except as I have >>>>>>>> >>>>>>>> >>>>>>> stated in >>>>>>> >>>>>>> >>>>>>>> prior email. >>>>>>>> >>>>>>>> The majority of changes have to do with: >>>>>>>> * More explicit text and references to -profile for multiple >>>>>>>> locations >>>>>>>> >>>>>>>> * Requiring the return of dialstrings on LoST for sos service >>>>>>>> URNs. >>>>>>>> >>>>>>>> * Lots of typos and wording changes. >>>>>>>> >>>>>>>> I did end up adding a couple of requirements, and thus needed to >>>>>>>> >>>>>>>> >>>>>>> renumber >>>>>>> >>>>>>> >>>>>>>> the requirements, so diffs look bad. >>>>>>>> >>>>>>>> I ask commenters to look at the text to make sure I made all the >>>>>>>> >>>>> changes >>>>> >>>>>>> you >>>>>>> >>>>>>> >>>>>>>> requested (with the exceptions covered in the emails). >>>>>>>> >>>>>>>> Chairs can consider if they wish to hold a short 2nd WGLC. >>>>>>>> There are >>>>>>>> >>>>> a >>>>> >>>>>>>> couple of substantive changes and added requirements, but not a >>>>>>>> whole >>>>>>>> >>>>>>>> >>>>>>> lot >>>>>>> >>>>>>> >>>>>>>> text is modified in any but trivial ways. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Ecrit mailing 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 Mon Jul 14 10:32:43 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 528463A6B24; Mon, 14 Jul 2008 10:32: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 386CC3A6A73 for ; Mon, 14 Jul 2008 10:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIXHwzNWuEEA for ; Mon, 14 Jul 2008 10:32:41 -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 B91063A67E1 for ; Mon, 14 Jul 2008 10:32:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,360,1212364800"; d="scan'208";a="52719382" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 14 Jul 2008 17:33:05 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m6EHX57d029833; Mon, 14 Jul 2008 10:33:05 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m6EHX5t4022189; Mon, 14 Jul 2008 17:33:05 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); Mon, 14 Jul 2008 10:33:05 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.84.1]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 10:33:04 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Jul 2008 12:33:07 -0500 To: "Brian Rosen" , "'Hannes Tschofenig'" From: "James M. Polk" In-Reply-To: <053301c8e4fb$ac68e960$640fa8c0@cis.neustar.com> References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> <023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com> <48787395.1040507@gmx.net> <053301c8e4fb$ac68e960$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 14 Jul 2008 17:33:04.0754 (UTC) FILETIME=[AC105520:01C8E5D7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6307; t=1216056785; x=1216920785; 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]=20=22Derived=22=20method |Sender:=20; bh=OOyPLNRgSbNm0tpCHtmTmMDRYremt1SQ/dWxfq3MxN4=; b=LGwww3cs4eUjLjAE45AjqTpoRgmziHd5tLtRTeBNv4PAovwHUmWHqTmAn/ kqC5HK/3P6TfwDyWcdU0dJx/Q2Pt/v3gmf6neqkCbgDA2rKk+aUJcpORdfvW WajL0lM1hf; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 10:18 AM 7/13/2008, Brian Rosen wrote: >I think we can get quite carried away with all the possibilities, and there >is no reason to be carried away. > >The possibilities are: >1. There is exactly one location, and it's marked "Derived". There is no >need for more information. I agree with this >2. There are exactly two locations, and one is marked "Derived". This means >the other is the original I do not agree with this. Here's how I got there The element is a sub-element of what element? Is it ? no -- it's parallel to it therefore the element has to be THE way the whole LO was discovered, regardless of how many formats (civic, geo, whatever's_coming_next) are in the LO. IF there are two locations, and they were discovered using different methods, that's TWO PIDF-LOs; else there's confusion. >3. There are more than two locations and one or more is marked "Derived". I >think we can ignore this case, or at least say that there is no way to >understand what is derived from what. > >Brian > > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Saturday, July 12, 2008 10:37 PM > > To: Hannes Tschofenig; Brian Rosen > > Cc: ECRIT > > Subject: RE: [Ecrit] "Derived" method > > > > Hi Brian, > > > > For derived to really have a clear meaning it needs to be totally > > unambiguous what the location is derived from. > > The example I always hear is a civic address derived from a geodetic > > shape, or vice versa. In this case, you need to provide both locations in > > the PIDF-LO document, and somehow, there needs to be a link between them. > > Simply havinf both locations in the same document isn't sufficient, I > > think you need the equivalent of an tag, or something like that. > > > > Cheers > > James > > > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > > Sent: Sat 7/12/2008 4:04 AM > > To: Brian Rosen > > Cc: 'ECRIT' > > Subject: [Ecrit] "Derived" method > > > > Could you describe the semantic of the "Derived" method a bit more? > > > > Brian Rosen wrote: > > > I am sorry, I don't know how I missed these. > > > > > > > > >> page 7: "The phone gets location from the DHCP server in civic > > >> [RFC4676] or geo" -> should it be "and/or"? > > >> > > > The text makes clear that multiple locations are problematic. Multiple > > > versions of the same location are problematic. I worry about systems > > trying > > > to be helpful and giving you a measured location and also giving you a > > > derived (geo coded or reverse geo coded) version of the same location. > > > > > > This does raise yet another issue about this general subject; looking at > > the > > > list at: > > > http://www.iana.org/assignments/method-tokens > > > There is no method for "derived". So: > > > I will add text to -framework covering this subject > > > I will ask IANA to create a "Derived" method token > > > I will add a requirement to -phonebcp that says if you get both and one > > is > > > derived, you must use the non-derived value. > > > > > > I've made the other changes in my source file and they will appear in > > the > > > next version. > > > > > > Brian > > > > > >> -----Original Message----- > > >> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > >> Sent: Friday, July 11, 2008 6:00 AM > > >> To: Brian Rosen > > >> Cc: ECRIT > > >> Subject: Re: [Ecrit] New versions of -framework and -phonebcp > > >> > > >> Brian, > > >> > > >> thank you for submitting the new versions of your documents. > > >> However, I'm afraid you forgot my comments (except the LoSt dialstring > > >> "must"). > > >> My old posting: > > >> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html > > >> In your reply to this mail you agreed to these points. > > >> > > >> Karl Heinz > > >> > > >> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen > > wrote: > > >> > > >>> These versions incorporate all last call comments except as I have > > >>> > > >> stated in > > >> > > >>> prior email. > > >>> > > >>> The majority of changes have to do with: > > >>> * More explicit text and references to -profile for multiple locations > > >>> > > >>> * Requiring the return of dialstrings on LoST for sos service URNs. > > >>> > > >>> * Lots of typos and wording changes. > > >>> > > >>> I did end up adding a couple of requirements, and thus needed to > > >>> > > >> renumber > > >> > > >>> the requirements, so diffs look bad. > > >>> > > >>> I ask commenters to look at the text to make sure I made all the > > changes > > >>> > > >> you > > >> > > >>> requested (with the exceptions covered in the emails). > > >>> > > >>> Chairs can consider if they wish to hold a short 2nd WGLC. There are > > a > > >>> couple of substantive changes and added requirements, but not a whole > > >>> > > >> lot > > >> > > >>> text is modified in any but trivial ways. > > >>> > > >>> Brian > > >>> > > >>> _______________________________________________ > > >>> Ecrit mailing 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 Jul 14 10:44:55 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F8D33A6A45; Mon, 14 Jul 2008 10:44: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 EE7783A6A4A for ; Mon, 14 Jul 2008 10:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.195, 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 MVhhViy01ziR for ; Mon, 14 Jul 2008 10:44:53 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7575B3A69AF for ; Mon, 14 Jul 2008 10:44:52 -0700 (PDT) Received: (qmail invoked by alias); 14 Jul 2008 17:45:16 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp047) with SMTP; 14 Jul 2008 19:45:16 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+bpJE7e8GbSGbuhK48IYkaBqaMZSd03YHrP9Tsqo zOakFx8NJBzUfS Message-ID: <487B90B2.2030906@gmx.net> Date: Mon, 14 Jul 2008 20:45:22 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "James M. Polk" References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> <023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com> <48787395.1040507@gmx.net> <053301c8e4fb$ac68e960$640fa8c0@cis.neustar.com> In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > therefore the element has to be THE way the whole LO was > discovered, regardless of how many formats (civic, geo, > whatever's_coming_next) are in the LO. > > IF there are two locations, and they were discovered using different > methods, that's TWO PIDF-LOs; else there's confusion. That does not seem to be right. When I return civic and geo then I doubt that both are determined using the same mechanism. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 14 10:51:18 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471D43A6C13; Mon, 14 Jul 2008 10:51: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 C93F73A6C13 for ; Mon, 14 Jul 2008 10:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 ZylBJGAeoICG for ; Mon, 14 Jul 2008 10:51:15 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 41ED13A6B70 for ; Mon, 14 Jul 2008 10:51:15 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KISD0-0000X1-3N; Mon, 14 Jul 2008 12:51:34 -0500 From: "Brian Rosen" To: "'James M. Polk'" , "'Hannes Tschofenig'" References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com><023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com><48787395.1040507@gmx.net><03eb01c8e425$35b47180$640fa8c0@cis.neustar.com><4878B640.1050907@gmx.net> <4878BD4C.5070805@gmx.net> Date: Mon, 14 Jul 2008 13:51:37 -0400 Message-ID: <093401c8e5da$4500f120$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acjl1aw0k+/of2pUR5CNWZKq2NE4XAABCVEQ 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: Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Perhaps we need to re-examine what we need. It doesn't seem useful to me to know by which protocol the PIDF creator learned location ('dhcp'). It does seem useful to understand the determination mechanism that was used to discover the location ('a-gps'). If we need to update 4119, let's do that. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > James M. Polk > Sent: Monday, July 14, 2008 1:18 PM > To: Hannes Tschofenig > Cc: 'ECRIT' > Subject: Re: [Ecrit] "Derived" method > > At 09:18 AM 7/12/2008, Hannes Tschofenig wrote: > >The problem is a bit with the semantic of the method token given > >that it was supposed to be used to indicate the location determination > method. > > this is simply not true. Your definition is adding meaning that isn't > there. > > The element is the indication, solely created by the > endpoint (as an LG), of how it received (i.e., "discovered") location > information (not LO, but LI). > > Case in point, if a target has a sighter that derives location based > on triangulating the position of the target, yet delivers that LI via > DHCP, the would NOT say > > triangulation > > it would say > > dhcp > > and be correct. > > >There are some "wrong" entries in the table already with that > >semantic since something like "DHCP" refers to an LCP rather than > >the actual location determination method. > > This is not true either. If a target (as an LG) discovers its LI > from DHCP (Option 99 or 123), then this is the > > dhcp > > James W. added some additional semantics to the additional values > without running them by the WG when he IANA registered them, so the > non-4119 defined values haven't been fully vetted. > > This is because 4119 doesn't require any review of any kind before > adding new IANA entries to this registry. > > > > >Now, I wonder whether it is possible to put more than one token into > >the method element. The data type is string and hence it would be > possible. > > > >To pick your example, could you indicate gps derived? > > > >Ciao > >Hannes > > > >PS: I wonder whether there is actually a way to deprecate certain > >tokens from the registry. Nothing is indicated in RFC 4119. "802.11" > >and "DHCP" "LLDP-MED" really does not belong in there. FCFS as a > >policy for assignment does not sound useful to me either; expert > >review would be more useful. > > Hennes - these 4119 values were the only ones that ever were "expert > reviewed", if you consider Geopriv a place where that can take place. > > BTW -- you were there for this expert review... perhaps you will > reconsider this stance once you re-evaluate how these entries are > 4119 intended. > > > > > >Hannes Tschofenig wrote: > >>Thanks. > >> > >>Brian Rosen wrote: > >>>The "Derived" method is used when the PIDF creator has a location > available > >>>in one form (civic or geo) using another method, and derives a location > in > >>>the other form. So for example, the determination method might be GPS, > >>>which creates a geo and the PIDF includes a civic derived from that > geo. > >>> > >>>Brian > >>> > >>> > >>>>-----Original Message----- > >>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>Sent: Saturday, July 12, 2008 5:04 AM > >>>>To: Brian Rosen > >>>>Cc: 'Karl Heinz Wolf'; 'ECRIT' > >>>>Subject: "Derived" method > >>>> > >>>>Could you describe the semantic of the "Derived" method a bit more? > >>>> > >>>>Brian Rosen wrote: > >>>> > >>>>>I am sorry, I don't know how I missed these. > >>>>> > >>>>> > >>>>> > >>>>>>page 7: "The phone gets location from the DHCP server in civic > >>>>>>[RFC4676] or geo" -> should it be "and/or"? > >>>>>> > >>>>>> > >>>>>The text makes clear that multiple locations are problematic. > Multiple > >>>>>versions of the same location are problematic. I worry about systems > >>>>> > >>>>trying > >>>> > >>>>>to be helpful and giving you a measured location and also giving you > a > >>>>>derived (geo coded or reverse geo coded) version of the same > location. > >>>>> > >>>>>This does raise yet another issue about this general subject; looking > at > >>>>> > >>>>the > >>>> > >>>>>list at: > >>>>>http://www.iana.org/assignments/method-tokens > >>>>>There is no method for "derived". So: > >>>>>I will add text to -framework covering this subject > >>>>>I will ask IANA to create a "Derived" method token > >>>>>I will add a requirement to -phonebcp that says if you get both and > one > >>>>> > >>>>is > >>>> > >>>>>derived, you must use the non-derived value. > >>>>> > >>>>>I've made the other changes in my source file and they will appear in > >>>>> > >>>>the > >>>> > >>>>>next version. > >>>>> > >>>>>Brian > >>>>> > >>>>> > >>>>>>-----Original Message----- > >>>>>>From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > >>>>>>Sent: Friday, July 11, 2008 6:00 AM > >>>>>>To: Brian Rosen > >>>>>>Cc: ECRIT > >>>>>>Subject: Re: [Ecrit] New versions of -framework and -phonebcp > >>>>>> > >>>>>>Brian, > >>>>>> > >>>>>>thank you for submitting the new versions of your documents. > >>>>>>However, I'm afraid you forgot my comments (except the LoSt > dialstring > >>>>>>"must"). > >>>>>>My old posting: > >>>>>>http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html > >>>>>>In your reply to this mail you agreed to these points. > >>>>>> > >>>>>>Karl Heinz > >>>>>> > >>>>>>On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen > >>>>>> > >>>>wrote: > >>>> > >>>>>>>These versions incorporate all last call comments except as I have > >>>>>>> > >>>>>>> > >>>>>>stated in > >>>>>> > >>>>>> > >>>>>>>prior email. > >>>>>>> > >>>>>>>The majority of changes have to do with: > >>>>>>>* More explicit text and references to -profile for multiple > locations > >>>>>>> > >>>>>>>* Requiring the return of dialstrings on LoST for sos service URNs. > >>>>>>> > >>>>>>>* Lots of typos and wording changes. > >>>>>>> > >>>>>>>I did end up adding a couple of requirements, and thus needed to > >>>>>>> > >>>>>>> > >>>>>>renumber > >>>>>> > >>>>>> > >>>>>>>the requirements, so diffs look bad. > >>>>>>> > >>>>>>>I ask commenters to look at the text to make sure I made all the > >>>>>>> > >>>>changes > >>>> > >>>>>>you > >>>>>> > >>>>>> > >>>>>>>requested (with the exceptions covered in the emails). > >>>>>>> > >>>>>>>Chairs can consider if they wish to hold a short 2nd WGLC. There > are > >>>>>>> > >>>>a > >>>> > >>>>>>>couple of substantive changes and added requirements, but not a > whole > >>>>>>> > >>>>>>> > >>>>>>lot > >>>>>> > >>>>>> > >>>>>>>text is modified in any but trivial ways. > >>>>>>> > >>>>>>>Brian > >>>>>>> > >>>>>>>_______________________________________________ > >>>>>>>Ecrit mailing 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 Mon Jul 14 10:53:02 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8745E3A6BF9; Mon, 14 Jul 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 8FF493A6BF9 for ; Mon, 14 Jul 2008 10:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 yLQnqp2DA6Ip for ; Mon, 14 Jul 2008 10:52:58 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 426C63A6B70 for ; Mon, 14 Jul 2008 10:52:58 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KISEf-0000bj-Kz; Mon, 14 Jul 2008 12:53:17 -0500 From: "Brian Rosen" To: "'James M. Polk'" , "'Hannes Tschofenig'" References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> <023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com> <48787395.1040507@gmx.net> <053301c8e4fb$ac68e960$640fa8c0@cis.neustar.com> Date: Mon, 14 Jul 2008 13:53:20 -0400 Message-ID: <093b01c8e5da$82b461f0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acjl195HgGp45MiqQMSngQHsZ2z/KgAAmo2Q 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: Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 would say this is an error. I think we need to determine what "method" should mean (prior email) first, but then we should fix this so that each location info section has its own method. Brian > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Monday, July 14, 2008 1:33 PM > To: Brian Rosen; 'Hannes Tschofenig' > Cc: 'ECRIT' > Subject: Re: [Ecrit] "Derived" method > > At 10:18 AM 7/13/2008, Brian Rosen wrote: > >I think we can get quite carried away with all the possibilities, and > there > >is no reason to be carried away. > > > >The possibilities are: > >1. There is exactly one location, and it's marked "Derived". There is no > >need for more information. > > I agree with this > > >2. There are exactly two locations, and one is marked "Derived". This > means > >the other is the original > > I do not agree with this. > > Here's how I got there > > The element is a sub-element of what element? > > Is it ? > > no -- it's parallel to it > > therefore the element has to be THE way the whole LO was > discovered, regardless of how many formats (civic, geo, > whatever's_coming_next) are in the LO. > > IF there are two locations, and they were discovered using different > methods, that's TWO PIDF-LOs; else there's confusion. > > >3. There are more than two locations and one or more is marked "Derived". > I > >think we can ignore this case, or at least say that there is no way to > >understand what is derived from what. > > > >Brian > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Saturday, July 12, 2008 10:37 PM > > > To: Hannes Tschofenig; Brian Rosen > > > Cc: ECRIT > > > Subject: RE: [Ecrit] "Derived" method > > > > > > Hi Brian, > > > > > > For derived to really have a clear meaning it needs to be totally > > > unambiguous what the location is derived from. > > > The example I always hear is a civic address derived from a geodetic > > > shape, or vice versa. In this case, you need to provide both locations > in > > > the PIDF-LO document, and somehow, there needs to be a link between > them. > > > Simply havinf both locations in the same document isn't sufficient, I > > > think you need the equivalent of an tag, or something like > that. > > > > > > Cheers > > > James > > > > > > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > > > Sent: Sat 7/12/2008 4:04 AM > > > To: Brian Rosen > > > Cc: 'ECRIT' > > > Subject: [Ecrit] "Derived" method > > > > > > Could you describe the semantic of the "Derived" method a bit more? > > > > > > Brian Rosen wrote: > > > > I am sorry, I don't know how I missed these. > > > > > > > > > > > >> page 7: "The phone gets location from the DHCP server in civic > > > >> [RFC4676] or geo" -> should it be "and/or"? > > > >> > > > > The text makes clear that multiple locations are problematic. > Multiple > > > > versions of the same location are problematic. I worry about > systems > > > trying > > > > to be helpful and giving you a measured location and also giving you > a > > > > derived (geo coded or reverse geo coded) version of the same > location. > > > > > > > > This does raise yet another issue about this general subject; > looking at > > > the > > > > list at: > > > > http://www.iana.org/assignments/method-tokens > > > > There is no method for "derived". So: > > > > I will add text to -framework covering this subject > > > > I will ask IANA to create a "Derived" method token > > > > I will add a requirement to -phonebcp that says if you get both and > one > > > is > > > > derived, you must use the non-derived value. > > > > > > > > I've made the other changes in my source file and they will appear > in > > > the > > > > next version. > > > > > > > > Brian > > > > > > > >> -----Original Message----- > > > >> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > > >> Sent: Friday, July 11, 2008 6:00 AM > > > >> To: Brian Rosen > > > >> Cc: ECRIT > > > >> Subject: Re: [Ecrit] New versions of -framework and -phonebcp > > > >> > > > >> Brian, > > > >> > > > >> thank you for submitting the new versions of your documents. > > > >> However, I'm afraid you forgot my comments (except the LoSt > dialstring > > > >> "must"). > > > >> My old posting: > > > >> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html > > > >> In your reply to this mail you agreed to these points. > > > >> > > > >> Karl Heinz > > > >> > > > >> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen > > > wrote: > > > >> > > > >>> These versions incorporate all last call comments except as I have > > > >>> > > > >> stated in > > > >> > > > >>> prior email. > > > >>> > > > >>> The majority of changes have to do with: > > > >>> * More explicit text and references to -profile for multiple > locations > > > >>> > > > >>> * Requiring the return of dialstrings on LoST for sos service > URNs. > > > >>> > > > >>> * Lots of typos and wording changes. > > > >>> > > > >>> I did end up adding a couple of requirements, and thus needed to > > > >>> > > > >> renumber > > > >> > > > >>> the requirements, so diffs look bad. > > > >>> > > > >>> I ask commenters to look at the text to make sure I made all the > > > changes > > > >>> > > > >> you > > > >> > > > >>> requested (with the exceptions covered in the emails). > > > >>> > > > >>> Chairs can consider if they wish to hold a short 2nd WGLC. There > are > > > a > > > >>> couple of substantive changes and added requirements, but not a > whole > > > >>> > > > >> lot > > > >> > > > >>> text is modified in any but trivial ways. > > > >>> > > > >>> Brian > > > >>> > > > >>> _______________________________________________ > > > >>> Ecrit mailing 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 Jul 14 10:54:30 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E823A6BFF; Mon, 14 Jul 2008 10:54: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 882353A6BFF for ; Mon, 14 Jul 2008 10:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCV0NFN4yKad for ; Mon, 14 Jul 2008 10:54:28 -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 D9B113A6BFE for ; Mon, 14 Jul 2008 10:54:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,360,1212364800"; d="scan'208";a="14251969" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Jul 2008 17:54:53 +0000 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 m6EHsrdp016243; Mon, 14 Jul 2008 13:54:53 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6EHsq3c014759; Mon, 14 Jul 2008 17:54:53 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, 14 Jul 2008 13:54:46 -0400 Received: from [10.116.195.115] ([10.116.195.115]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 13:54:45 -0400 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Mon, 14 Jul 2008 13:54:44 -0400 From: Marc Linsner To: Hannes Tschofenig , James Polk Message-ID: Thread-Topic: [Ecrit] "Derived" method Thread-Index: Acjl2rJ550Y6QF3avE2es8xxCUxJhA== In-Reply-To: <487B8D31.4000402@gmx.net> Mime-version: 1.0 X-OriginalArrivalTime: 14 Jul 2008 17:54:45.0889 (UTC) FILETIME=[B399C710:01C8E5DA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8442; t=1216058093; x=1216922093; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20=22Derived=22=20method |Sender:=20 |To:=20Hannes=20Tschofenig=20,=0 A=20=20=20=20=20=20=20=20James=20Polk=20; bh=lQXw0Saqve5ihq2OMV9a4KPTjaDHTTU8sXpqiCt77nU=; b=kzr3Yfq0Pm3bcD9CXoeK6EJ/AcNNpxz1LaiCXo587eEn3qtpx2CrTOELe7 egufJz4xz+GoWhEFAtMIvPyCjSQOxDDTOc5DkYmoNxzKmffzVXBIvbl7oUJ0 wIT7FFh/1Q; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 convinced any of this information is useful to a LR. Would the pizza be warmer when delivered if the delivery person had this information? What would the LR do if the location information is wrong and they knew it was derived by a ouija board vs. a wiremap database vs. triangulation? What if the wiremap database was populated using gps? -Marc- On 7/14/08 1:30 PM, "Hannes Tschofenig" wrote: > RFC 4119 isn't super exhaustive in the description of the semantic of > the element and what it is being used for. > > What could be more useful for the Location Recipient to know: > > * Location was obtained using DHCP, or LLDP-MED > > OR > > * Location was determined using manual configuration, wiremap database, > triangulation. > > > Ciao > Hannes > > > > James M. Polk wrote: >> At 09:18 AM 7/12/2008, Hannes Tschofenig wrote: >>> The problem is a bit with the semantic of the method token given that >>> it was supposed to be used to indicate the location determination >>> method. >> >> this is simply not true. Your definition is adding meaning that isn't >> there. >> >> The element is the indication, solely created by the endpoint >> (as an LG), of how it received (i.e., "discovered") location >> information (not LO, but LI). >> >> Case in point, if a target has a sighter that derives location based >> on triangulating the position of the target, yet delivers that LI via >> DHCP, the would NOT say >> >> triangulation >> >> it would say >> >> dhcp >> >> and be correct. >> >>> There are some "wrong" entries in the table already with that >>> semantic since something like "DHCP" refers to an LCP rather than the >>> actual location determination method. >> >> This is not true either. If a target (as an LG) discovers its LI from >> DHCP (Option 99 or 123), then this is the >> >> dhcp >> >> James W. added some additional semantics to the additional values >> without running them by the WG when he IANA registered them, so the >> non-4119 defined values haven't been fully vetted. >> >> This is because 4119 doesn't require any review of any kind before >> adding new IANA entries to this registry. >> >> >> >>> Now, I wonder whether it is possible to put more than one token into >>> the method element. The data type is string and hence it would be >>> possible. >>> >>> To pick your example, could you indicate gps derived? >>> >>> Ciao >>> Hannes >>> >>> PS: I wonder whether there is actually a way to deprecate certain >>> tokens from the registry. Nothing is indicated in RFC 4119. "802.11" >>> and "DHCP" "LLDP-MED" really does not belong in there. FCFS as a >>> policy for assignment does not sound useful to me either; expert >>> review would be more useful. >> >> Hennes - these 4119 values were the only ones that ever were "expert >> reviewed", if you consider Geopriv a place where that can take place. >> >> BTW -- you were there for this expert review... perhaps you will >> reconsider this stance once you re-evaluate how these entries are 4119 >> intended. >> >> >> >> >>> Hannes Tschofenig wrote: >>>> Thanks. >>>> >>>> Brian Rosen wrote: >>>>> The "Derived" method is used when the PIDF creator has a location >>>>> available >>>>> in one form (civic or geo) using another method, and derives a >>>>> location in >>>>> the other form. So for example, the determination method might be >>>>> GPS, >>>>> which creates a geo and the PIDF includes a civic derived from that >>>>> geo. >>>>> >>>>> Brian >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>> Sent: Saturday, July 12, 2008 5:04 AM >>>>>> To: Brian Rosen >>>>>> Cc: 'Karl Heinz Wolf'; 'ECRIT' >>>>>> Subject: "Derived" method >>>>>> >>>>>> Could you describe the semantic of the "Derived" method a bit more? >>>>>> >>>>>> Brian Rosen wrote: >>>>>> >>>>>>> I am sorry, I don't know how I missed these. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> page 7: "The phone gets location from the DHCP server in civic >>>>>>>> [RFC4676] or geo" -> should it be "and/or"? >>>>>>>> >>>>>>>> >>>>>>> The text makes clear that multiple locations are problematic. >>>>>>> Multiple >>>>>>> versions of the same location are problematic. I worry about >>>>>>> systems >>>>>>> >>>>>> trying >>>>>> >>>>>>> to be helpful and giving you a measured location and also giving >>>>>>> you a >>>>>>> derived (geo coded or reverse geo coded) version of the same >>>>>>> location. >>>>>>> >>>>>>> This does raise yet another issue about this general subject; >>>>>>> looking at >>>>>>> >>>>>> the >>>>>> >>>>>>> list at: >>>>>>> http://www.iana.org/assignments/method-tokens >>>>>>> There is no method for "derived". So: >>>>>>> I will add text to -framework covering this subject >>>>>>> I will ask IANA to create a "Derived" method token >>>>>>> I will add a requirement to -phonebcp that says if you get both >>>>>>> and one >>>>>>> >>>>>> is >>>>>> >>>>>>> derived, you must use the non-derived value. >>>>>>> >>>>>>> I've made the other changes in my source file and they will >>>>>>> appear in >>>>>>> >>>>>> the >>>>>> >>>>>>> next version. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >>>>>>>> Sent: Friday, July 11, 2008 6:00 AM >>>>>>>> To: Brian Rosen >>>>>>>> Cc: ECRIT >>>>>>>> Subject: Re: [Ecrit] New versions of -framework and -phonebcp >>>>>>>> >>>>>>>> Brian, >>>>>>>> >>>>>>>> thank you for submitting the new versions of your documents. >>>>>>>> However, I'm afraid you forgot my comments (except the LoSt >>>>>>>> dialstring >>>>>>>> "must"). >>>>>>>> My old posting: >>>>>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html >>>>>>>> In your reply to this mail you agreed to these points. >>>>>>>> >>>>>>>> Karl Heinz >>>>>>>> >>>>>>>> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen >>>>>>>> >>>>>> wrote: >>>>>> >>>>>>>>> These versions incorporate all last call comments except as I have >>>>>>>>> >>>>>>>>> >>>>>>>> stated in >>>>>>>> >>>>>>>> >>>>>>>>> prior email. >>>>>>>>> >>>>>>>>> The majority of changes have to do with: >>>>>>>>> * More explicit text and references to -profile for multiple >>>>>>>>> locations >>>>>>>>> >>>>>>>>> * Requiring the return of dialstrings on LoST for sos service >>>>>>>>> URNs. >>>>>>>>> >>>>>>>>> * Lots of typos and wording changes. >>>>>>>>> >>>>>>>>> I did end up adding a couple of requirements, and thus needed to >>>>>>>>> >>>>>>>>> >>>>>>>> renumber >>>>>>>> >>>>>>>> >>>>>>>>> the requirements, so diffs look bad. >>>>>>>>> >>>>>>>>> I ask commenters to look at the text to make sure I made all the >>>>>>>>> >>>>>> changes >>>>>> >>>>>>>> you >>>>>>>> >>>>>>>> >>>>>>>>> requested (with the exceptions covered in the emails). >>>>>>>>> >>>>>>>>> Chairs can consider if they wish to hold a short 2nd WGLC. >>>>>>>>> There are >>>>>>>>> >>>>>> a >>>>>> >>>>>>>>> couple of substantive changes and added requirements, but not a >>>>>>>>> whole >>>>>>>>> >>>>>>>>> >>>>>>>> lot >>>>>>>> >>>>>>>> >>>>>>>>> text is modified in any but trivial ways. >>>>>>>>> >>>>>>>>> Brian >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Ecrit mailing 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 Mon Jul 14 10:56:48 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 483523A6BDA; Mon, 14 Jul 2008 10:56: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 D70743A6BDA for ; Mon, 14 Jul 2008 10:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.189, 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 Z6X8A4NzFwUv for ; Mon, 14 Jul 2008 10:56:46 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B66253A6A4E for ; Mon, 14 Jul 2008 10:56:45 -0700 (PDT) Received: (qmail invoked by alias); 14 Jul 2008 17:57:07 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp049) with SMTP; 14 Jul 2008 19:57:07 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/SEdgXLtzSJQ2F353ZWS1KPqcMIvgYJk7OA8bGhc OagUDCKOLl9PPn Message-ID: <487B937B.5010709@gmx.net> Date: Mon, 14 Jul 2008 20:57:15 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Brian Rosen References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com><023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com><48787395.1040507@gmx.net><03eb01c8e425$35b47180$640fa8c0@cis.neustar.com><4878B640.1050907@gmx.net> <4878BD4C.5070805@gmx.net> <093401c8e5da$4500f120$640fa8c0@cis.neustar.com> In-Reply-To: <093401c8e5da$4500f120$640fa8c0@cis.neustar.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78 Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > Perhaps we need to re-examine what we need. > > It doesn't seem useful to me to know by which protocol the PIDF creator > learned location ('dhcp'). > > Unless you are the author of that protocol and you want to keep track of the deployment :-) > It does seem useful to understand the determination mechanism that was used > to discover the location ('a-gps'). > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 14 11:02:37 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B9D53A6B65; Mon, 14 Jul 2008 11:02: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 D6E613A68FA for ; Mon, 14 Jul 2008 11:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 eAtSCg3vUJ1F for ; Mon, 14 Jul 2008 11:02:34 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C974B3A6A4E for ; Mon, 14 Jul 2008 11:02:33 -0700 (PDT) Received: (qmail invoked by alias); 14 Jul 2008 18:02:59 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp048) with SMTP; 14 Jul 2008 20:02:59 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+2ZoYiDlW20qObZNYXLxOX7+1apoNp1dryzsac4z bY2s40hph8ybqZ Message-ID: <487B94DB.7060701@gmx.net> Date: Mon, 14 Jul 2008 21:03:07 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Marc Linsner References: In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.48 Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org That's actually a good question: Is the element really so useful? Ciao Hannes Marc Linsner wrote: > I'm not convinced any of this information is useful to a LR. > > Would the pizza be warmer when delivered if the delivery person had this > information? > > What would the LR do if the location information is wrong and they knew it > was derived by a ouija board vs. a wiremap database vs. triangulation? > > What if the wiremap database was populated using gps? > > -Marc- > > > On 7/14/08 1:30 PM, "Hannes Tschofenig" wrote: > > >> RFC 4119 isn't super exhaustive in the description of the semantic of >> the element and what it is being used for. >> >> What could be more useful for the Location Recipient to know: >> >> * Location was obtained using DHCP, or LLDP-MED >> >> OR >> >> * Location was determined using manual configuration, wiremap database, >> triangulation. >> >> >> Ciao >> Hannes >> >> >> >> James M. Polk wrote: >> >>> At 09:18 AM 7/12/2008, Hannes Tschofenig wrote: >>> >>>> The problem is a bit with the semantic of the method token given that >>>> it was supposed to be used to indicate the location determination >>>> method. >>>> >>> this is simply not true. Your definition is adding meaning that isn't >>> there. >>> >>> The element is the indication, solely created by the endpoint >>> (as an LG), of how it received (i.e., "discovered") location >>> information (not LO, but LI). >>> >>> Case in point, if a target has a sighter that derives location based >>> on triangulating the position of the target, yet delivers that LI via >>> DHCP, the would NOT say >>> >>> triangulation >>> >>> it would say >>> >>> dhcp >>> >>> and be correct. >>> >>> >>>> There are some "wrong" entries in the table already with that >>>> semantic since something like "DHCP" refers to an LCP rather than the >>>> actual location determination method. >>>> >>> This is not true either. If a target (as an LG) discovers its LI from >>> DHCP (Option 99 or 123), then this is the >>> >>> dhcp >>> >>> James W. added some additional semantics to the additional values >>> without running them by the WG when he IANA registered them, so the >>> non-4119 defined values haven't been fully vetted. >>> >>> This is because 4119 doesn't require any review of any kind before >>> adding new IANA entries to this registry. >>> >>> >>> >>> >>>> Now, I wonder whether it is possible to put more than one token into >>>> the method element. The data type is string and hence it would be >>>> possible. >>>> >>>> To pick your example, could you indicate gps derived? >>>> >>>> Ciao >>>> Hannes >>>> >>>> PS: I wonder whether there is actually a way to deprecate certain >>>> tokens from the registry. Nothing is indicated in RFC 4119. "802.11" >>>> and "DHCP" "LLDP-MED" really does not belong in there. FCFS as a >>>> policy for assignment does not sound useful to me either; expert >>>> review would be more useful. >>>> >>> Hennes - these 4119 values were the only ones that ever were "expert >>> reviewed", if you consider Geopriv a place where that can take place. >>> >>> BTW -- you were there for this expert review... perhaps you will >>> reconsider this stance once you re-evaluate how these entries are 4119 >>> intended. >>> >>> >>> >>> >>> >>>> Hannes Tschofenig wrote: >>>> >>>>> Thanks. >>>>> >>>>> Brian Rosen wrote: >>>>> >>>>>> The "Derived" method is used when the PIDF creator has a location >>>>>> available >>>>>> in one form (civic or geo) using another method, and derives a >>>>>> location in >>>>>> the other form. So for example, the determination method might be >>>>>> GPS, >>>>>> which creates a geo and the PIDF includes a civic derived from that >>>>>> geo. >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>> Sent: Saturday, July 12, 2008 5:04 AM >>>>>>> To: Brian Rosen >>>>>>> Cc: 'Karl Heinz Wolf'; 'ECRIT' >>>>>>> Subject: "Derived" method >>>>>>> >>>>>>> Could you describe the semantic of the "Derived" method a bit more? >>>>>>> >>>>>>> Brian Rosen wrote: >>>>>>> >>>>>>> >>>>>>>> I am sorry, I don't know how I missed these. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> page 7: "The phone gets location from the DHCP server in civic >>>>>>>>> [RFC4676] or geo" -> should it be "and/or"? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> The text makes clear that multiple locations are problematic. >>>>>>>> Multiple >>>>>>>> versions of the same location are problematic. I worry about >>>>>>>> systems >>>>>>>> >>>>>>>> >>>>>>> trying >>>>>>> >>>>>>> >>>>>>>> to be helpful and giving you a measured location and also giving >>>>>>>> you a >>>>>>>> derived (geo coded or reverse geo coded) version of the same >>>>>>>> location. >>>>>>>> >>>>>>>> This does raise yet another issue about this general subject; >>>>>>>> looking at >>>>>>>> >>>>>>>> >>>>>>> the >>>>>>> >>>>>>> >>>>>>>> list at: >>>>>>>> http://www.iana.org/assignments/method-tokens >>>>>>>> There is no method for "derived". So: >>>>>>>> I will add text to -framework covering this subject >>>>>>>> I will ask IANA to create a "Derived" method token >>>>>>>> I will add a requirement to -phonebcp that says if you get both >>>>>>>> and one >>>>>>>> >>>>>>>> >>>>>>> is >>>>>>> >>>>>>> >>>>>>>> derived, you must use the non-derived value. >>>>>>>> >>>>>>>> I've made the other changes in my source file and they will >>>>>>>> appear in >>>>>>>> >>>>>>>> >>>>>>> the >>>>>>> >>>>>>> >>>>>>>> next version. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >>>>>>>>> Sent: Friday, July 11, 2008 6:00 AM >>>>>>>>> To: Brian Rosen >>>>>>>>> Cc: ECRIT >>>>>>>>> Subject: Re: [Ecrit] New versions of -framework and -phonebcp >>>>>>>>> >>>>>>>>> Brian, >>>>>>>>> >>>>>>>>> thank you for submitting the new versions of your documents. >>>>>>>>> However, I'm afraid you forgot my comments (except the LoSt >>>>>>>>> dialstring >>>>>>>>> "must"). >>>>>>>>> My old posting: >>>>>>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html >>>>>>>>> In your reply to this mail you agreed to these points. >>>>>>>>> >>>>>>>>> Karl Heinz >>>>>>>>> >>>>>>>>> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen >>>>>>>>> >>>>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>>>> These versions incorporate all last call comments except as I have >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> stated in >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> prior email. >>>>>>>>>> >>>>>>>>>> The majority of changes have to do with: >>>>>>>>>> * More explicit text and references to -profile for multiple >>>>>>>>>> locations >>>>>>>>>> >>>>>>>>>> * Requiring the return of dialstrings on LoST for sos service >>>>>>>>>> URNs. >>>>>>>>>> >>>>>>>>>> * Lots of typos and wording changes. >>>>>>>>>> >>>>>>>>>> I did end up adding a couple of requirements, and thus needed to >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> renumber >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> the requirements, so diffs look bad. >>>>>>>>>> >>>>>>>>>> I ask commenters to look at the text to make sure I made all the >>>>>>>>>> >>>>>>>>>> >>>>>>> changes >>>>>>> >>>>>>> >>>>>>>>> you >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> requested (with the exceptions covered in the emails). >>>>>>>>>> >>>>>>>>>> Chairs can consider if they wish to hold a short 2nd WGLC. >>>>>>>>>> There are >>>>>>>>>> >>>>>>>>>> >>>>>>> a >>>>>>> >>>>>>> >>>>>>>>>> couple of substantive changes and added requirements, but not a >>>>>>>>>> whole >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> lot >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> text is modified in any but trivial ways. >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Ecrit mailing 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 Mon Jul 14 11:03:30 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C58D28C148; Mon, 14 Jul 2008 11:03: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 155A23A6C20 for ; Mon, 14 Jul 2008 11:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 ZpkPJBxGgdvC for ; Mon, 14 Jul 2008 11:03:27 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id A37013A68FA for ; Mon, 14 Jul 2008 11:03:27 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KISOi-0001SN-0a; Mon, 14 Jul 2008 13:03:46 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , "'Hannes Tschofenig'" , "'James Polk'" References: <487B8D31.4000402@gmx.net> Date: Mon, 14 Jul 2008 14:03:38 -0400 Message-ID: <094e01c8e5db$f985c070$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acjl2rJ550Y6QF3avE2es8xxCUxJhAAAKd1A 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: Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 can reasonably infer things based on it. For example, wiremap data would never change. GPS data might. If you measured wiremap data with gps, it would not likely change. No guarantees. Another example would be "cell". If you ask for an update later, in some countries, you likely will get a better location (using a different method). Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Marc Linsner > Sent: Monday, July 14, 2008 1:55 PM > To: Hannes Tschofenig; James Polk > Cc: 'ECRIT' > Subject: Re: [Ecrit] "Derived" method > > I'm not convinced any of this information is useful to a LR. > > Would the pizza be warmer when delivered if the delivery person had this > information? > > What would the LR do if the location information is wrong and they knew it > was derived by a ouija board vs. a wiremap database vs. triangulation? > > What if the wiremap database was populated using gps? > > -Marc- > > > On 7/14/08 1:30 PM, "Hannes Tschofenig" wrote: > > > RFC 4119 isn't super exhaustive in the description of the semantic of > > the element and what it is being used for. > > > > What could be more useful for the Location Recipient to know: > > > > * Location was obtained using DHCP, or LLDP-MED > > > > OR > > > > * Location was determined using manual configuration, wiremap database, > > triangulation. > > > > > > Ciao > > Hannes > > > > > > > > James M. Polk wrote: > >> At 09:18 AM 7/12/2008, Hannes Tschofenig wrote: > >>> The problem is a bit with the semantic of the method token given that > >>> it was supposed to be used to indicate the location determination > >>> method. > >> > >> this is simply not true. Your definition is adding meaning that isn't > >> there. > >> > >> The element is the indication, solely created by the endpoint > >> (as an LG), of how it received (i.e., "discovered") location > >> information (not LO, but LI). > >> > >> Case in point, if a target has a sighter that derives location based > >> on triangulating the position of the target, yet delivers that LI via > >> DHCP, the would NOT say > >> > >> triangulation > >> > >> it would say > >> > >> dhcp > >> > >> and be correct. > >> > >>> There are some "wrong" entries in the table already with that > >>> semantic since something like "DHCP" refers to an LCP rather than the > >>> actual location determination method. > >> > >> This is not true either. If a target (as an LG) discovers its LI from > >> DHCP (Option 99 or 123), then this is the > >> > >> dhcp > >> > >> James W. added some additional semantics to the additional values > >> without running them by the WG when he IANA registered them, so the > >> non-4119 defined values haven't been fully vetted. > >> > >> This is because 4119 doesn't require any review of any kind before > >> adding new IANA entries to this registry. > >> > >> > >> > >>> Now, I wonder whether it is possible to put more than one token into > >>> the method element. The data type is string and hence it would be > >>> possible. > >>> > >>> To pick your example, could you indicate gps derived? > >>> > >>> Ciao > >>> Hannes > >>> > >>> PS: I wonder whether there is actually a way to deprecate certain > >>> tokens from the registry. Nothing is indicated in RFC 4119. "802.11" > >>> and "DHCP" "LLDP-MED" really does not belong in there. FCFS as a > >>> policy for assignment does not sound useful to me either; expert > >>> review would be more useful. > >> > >> Hennes - these 4119 values were the only ones that ever were "expert > >> reviewed", if you consider Geopriv a place where that can take place. > >> > >> BTW -- you were there for this expert review... perhaps you will > >> reconsider this stance once you re-evaluate how these entries are 4119 > >> intended. > >> > >> > >> > >> > >>> Hannes Tschofenig wrote: > >>>> Thanks. > >>>> > >>>> Brian Rosen wrote: > >>>>> The "Derived" method is used when the PIDF creator has a location > >>>>> available > >>>>> in one form (civic or geo) using another method, and derives a > >>>>> location in > >>>>> the other form. So for example, the determination method might be > >>>>> GPS, > >>>>> which creates a geo and the PIDF includes a civic derived from that > >>>>> geo. > >>>>> > >>>>> Brian > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>>> Sent: Saturday, July 12, 2008 5:04 AM > >>>>>> To: Brian Rosen > >>>>>> Cc: 'Karl Heinz Wolf'; 'ECRIT' > >>>>>> Subject: "Derived" method > >>>>>> > >>>>>> Could you describe the semantic of the "Derived" method a bit more? > >>>>>> > >>>>>> Brian Rosen wrote: > >>>>>> > >>>>>>> I am sorry, I don't know how I missed these. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> page 7: "The phone gets location from the DHCP server in civic > >>>>>>>> [RFC4676] or geo" -> should it be "and/or"? > >>>>>>>> > >>>>>>>> > >>>>>>> The text makes clear that multiple locations are problematic. > >>>>>>> Multiple > >>>>>>> versions of the same location are problematic. I worry about > >>>>>>> systems > >>>>>>> > >>>>>> trying > >>>>>> > >>>>>>> to be helpful and giving you a measured location and also giving > >>>>>>> you a > >>>>>>> derived (geo coded or reverse geo coded) version of the same > >>>>>>> location. > >>>>>>> > >>>>>>> This does raise yet another issue about this general subject; > >>>>>>> looking at > >>>>>>> > >>>>>> the > >>>>>> > >>>>>>> list at: > >>>>>>> http://www.iana.org/assignments/method-tokens > >>>>>>> There is no method for "derived". So: > >>>>>>> I will add text to -framework covering this subject > >>>>>>> I will ask IANA to create a "Derived" method token > >>>>>>> I will add a requirement to -phonebcp that says if you get both > >>>>>>> and one > >>>>>>> > >>>>>> is > >>>>>> > >>>>>>> derived, you must use the non-derived value. > >>>>>>> > >>>>>>> I've made the other changes in my source file and they will > >>>>>>> appear in > >>>>>>> > >>>>>> the > >>>>>> > >>>>>>> next version. > >>>>>>> > >>>>>>> Brian > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > >>>>>>>> Sent: Friday, July 11, 2008 6:00 AM > >>>>>>>> To: Brian Rosen > >>>>>>>> Cc: ECRIT > >>>>>>>> Subject: Re: [Ecrit] New versions of -framework and -phonebcp > >>>>>>>> > >>>>>>>> Brian, > >>>>>>>> > >>>>>>>> thank you for submitting the new versions of your documents. > >>>>>>>> However, I'm afraid you forgot my comments (except the LoSt > >>>>>>>> dialstring > >>>>>>>> "must"). > >>>>>>>> My old posting: > >>>>>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html > >>>>>>>> In your reply to this mail you agreed to these points. > >>>>>>>> > >>>>>>>> Karl Heinz > >>>>>>>> > >>>>>>>> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen > >>>>>>>> > >>>>>> wrote: > >>>>>> > >>>>>>>>> These versions incorporate all last call comments except as I > have > >>>>>>>>> > >>>>>>>>> > >>>>>>>> stated in > >>>>>>>> > >>>>>>>> > >>>>>>>>> prior email. > >>>>>>>>> > >>>>>>>>> The majority of changes have to do with: > >>>>>>>>> * More explicit text and references to -profile for multiple > >>>>>>>>> locations > >>>>>>>>> > >>>>>>>>> * Requiring the return of dialstrings on LoST for sos service > >>>>>>>>> URNs. > >>>>>>>>> > >>>>>>>>> * Lots of typos and wording changes. > >>>>>>>>> > >>>>>>>>> I did end up adding a couple of requirements, and thus needed to > >>>>>>>>> > >>>>>>>>> > >>>>>>>> renumber > >>>>>>>> > >>>>>>>> > >>>>>>>>> the requirements, so diffs look bad. > >>>>>>>>> > >>>>>>>>> I ask commenters to look at the text to make sure I made all the > >>>>>>>>> > >>>>>> changes > >>>>>> > >>>>>>>> you > >>>>>>>> > >>>>>>>> > >>>>>>>>> requested (with the exceptions covered in the emails). > >>>>>>>>> > >>>>>>>>> Chairs can consider if they wish to hold a short 2nd WGLC. > >>>>>>>>> There are > >>>>>>>>> > >>>>>> a > >>>>>> > >>>>>>>>> couple of substantive changes and added requirements, but not a > >>>>>>>>> whole > >>>>>>>>> > >>>>>>>>> > >>>>>>>> lot > >>>>>>>> > >>>>>>>> > >>>>>>>>> text is modified in any but trivial ways. > >>>>>>>>> > >>>>>>>>> Brian > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Ecrit mailing 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 Mon Jul 14 11:05:32 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C008728C266; Mon, 14 Jul 2008 11:05: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 4FF3428C1BC for ; Mon, 14 Jul 2008 11:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMQMkHUdKTob for ; Mon, 14 Jul 2008 11:05:30 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 6F12D28C262 for ; Mon, 14 Jul 2008 11:05:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,360,1212364800"; d="scan'208";a="87011054" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 14 Jul 2008 18:05:54 +0000 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 m6EI5s7O013395; Mon, 14 Jul 2008 11:05:54 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6EI5svD008048; Mon, 14 Jul 2008 18:05:54 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); Mon, 14 Jul 2008 11:05:54 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.84.1]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 11:05:53 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Jul 2008 13:05:56 -0500 To: Hannes Tschofenig From: "James M. Polk" In-Reply-To: <487B8D31.4000402@gmx.net> References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> <023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com> <48787395.1040507@gmx.net> <03eb01c8e425$35b47180$640fa8c0@cis.neustar.com> <4878B640.1050907@gmx.net> <4878BD4C.5070805@gmx.net> <487B8D31.4000402@gmx.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 14 Jul 2008 18:05:53.0855 (UTC) FILETIME=[41BD4CF0:01C8E5DC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7691; t=1216058754; x=1216922754; 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]=20=22Derived=22=20method |Sender:=20; bh=34LIiV+PJvQmPfgQJRo44N+LYXHqbld+rIBSOKzIdjs=; b=VzJ8aJrzsxnbHsBakEklXt8D0X8mVHDV7fRfeQrfRda6l2QYJUZRBqyXOm t0sUo622jZ0Mbf9nk6leBo4gEnx8bg+eeCOZGleb9sn/LB3n+CUUHIv89OR6 +TfEu7h7B4lzLA53gYKsT39N3F+tn5Ihn8YMhGbYG+n9T4ZuERNGs=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 12:30 PM 7/14/2008, Hannes Tschofenig wrote: >RFC 4119 isn't super exhaustive in the description of the semantic >of the element and what it is being used for. > >What could be more useful for the Location Recipient to know: > >* Location was obtained using DHCP, or LLDP-MED > >OR > >* Location was determined using manual configuration, wiremap >database, triangulation. Here is a quote from RFC 4119 "2.2.3. 'method' Element The optional 'method' element describes the way that the location information was derived or discovered. " How isn't this exactly what you said above? "Derived" and "Obtained" are synonyms >Ciao >Hannes > > > >James M. Polk wrote: >>At 09:18 AM 7/12/2008, Hannes Tschofenig wrote: >>>The problem is a bit with the semantic of the method token given >>>that it was supposed to be used to indicate the location determination method. >> >>this is simply not true. Your definition is adding meaning that isn't there. >> >>The element is the indication, solely created by the >>endpoint (as an LG), of how it received (i.e., "discovered") >>location information (not LO, but LI). >> >>Case in point, if a target has a sighter that derives location >>based on triangulating the position of the target, yet delivers >>that LI via DHCP, the would NOT say >> >> triangulation >> >>it would say >> >> dhcp >> >>and be correct. >> >>>There are some "wrong" entries in the table already with that >>>semantic since something like "DHCP" refers to an LCP rather than >>>the actual location determination method. >> >>This is not true either. If a target (as an LG) discovers its LI >>from DHCP (Option 99 or 123), then this is the >> >> dhcp >> >>James W. added some additional semantics to the additional values >>without running them by the WG when he IANA registered them, so the >>non-4119 defined values haven't been fully vetted. >> >>This is because 4119 doesn't require any review of any kind before >>adding new IANA entries to this registry. >> >> >> >>>Now, I wonder whether it is possible to put more than one token >>>into the method element. The data type is string and hence it >>>would be possible. >>> >>>To pick your example, could you indicate gps derived? >>> >>>Ciao >>>Hannes >>> >>>PS: I wonder whether there is actually a way to deprecate certain >>>tokens from the registry. Nothing is indicated in RFC 4119. >>>"802.11" and "DHCP" "LLDP-MED" really does not belong in there. >>>FCFS as a policy for assignment does not sound useful to me >>>either; expert review would be more useful. >> >>Hennes - these 4119 values were the only ones that ever were >>"expert reviewed", if you consider Geopriv a place where that can take place. >> >>BTW -- you were there for this expert review... perhaps you will >>reconsider this stance once you re-evaluate how these entries are >>4119 intended. >> >> >> >> >>>Hannes Tschofenig wrote: >>>>Thanks. >>>> >>>>Brian Rosen wrote: >>>>>The "Derived" method is used when the PIDF creator has a >>>>>location available >>>>>in one form (civic or geo) using another method, and derives a location in >>>>>the other form. So for example, the determination method might be GPS, >>>>>which creates a geo and the PIDF includes a civic derived from that geo. >>>>> >>>>>Brian >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>Sent: Saturday, July 12, 2008 5:04 AM >>>>>>To: Brian Rosen >>>>>>Cc: 'Karl Heinz Wolf'; 'ECRIT' >>>>>>Subject: "Derived" method >>>>>> >>>>>>Could you describe the semantic of the "Derived" method a bit more? >>>>>> >>>>>>Brian Rosen wrote: >>>>>> >>>>>>>I am sorry, I don't know how I missed these. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>page 7: "The phone gets location from the DHCP server in civic >>>>>>>>[RFC4676] or geo" -> should it be "and/or"? >>>>>>>> >>>>>>>The text makes clear that multiple locations are problematic. Multiple >>>>>>>versions of the same location are problematic. I worry about systems >>>>>>trying >>>>>> >>>>>>>to be helpful and giving you a measured location and also giving you a >>>>>>>derived (geo coded or reverse geo coded) version of the same location. >>>>>>> >>>>>>>This does raise yet another issue about this general subject; looking at >>>>>>the >>>>>> >>>>>>>list at: >>>>>>>http://www.iana.org/assignments/method-tokens >>>>>>>There is no method for "derived". So: >>>>>>>I will add text to -framework covering this subject >>>>>>>I will ask IANA to create a "Derived" method token >>>>>>>I will add a requirement to -phonebcp that says if you get both and one >>>>>>is >>>>>> >>>>>>>derived, you must use the non-derived value. >>>>>>> >>>>>>>I've made the other changes in my source file and they will appear in >>>>>>the >>>>>> >>>>>>>next version. >>>>>>> >>>>>>>Brian >>>>>>> >>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >>>>>>>>Sent: Friday, July 11, 2008 6:00 AM >>>>>>>>To: Brian Rosen >>>>>>>>Cc: ECRIT >>>>>>>>Subject: Re: [Ecrit] New versions of -framework and -phonebcp >>>>>>>> >>>>>>>>Brian, >>>>>>>> >>>>>>>>thank you for submitting the new versions of your documents. >>>>>>>>However, I'm afraid you forgot my comments (except the LoSt dialstring >>>>>>>>"must"). >>>>>>>>My old posting: >>>>>>>>http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html >>>>>>>>In your reply to this mail you agreed to these points. >>>>>>>> >>>>>>>>Karl Heinz >>>>>>>> >>>>>>>>On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen >>>>>>wrote: >>>>>> >>>>>>>>>These versions incorporate all last call comments except as I have >>>>>>>>> >>>>>>>>stated in >>>>>>>> >>>>>>>> >>>>>>>>>prior email. >>>>>>>>> >>>>>>>>>The majority of changes have to do with: >>>>>>>>>* More explicit text and references to -profile for multiple locations >>>>>>>>> >>>>>>>>>* Requiring the return of dialstrings on LoST for sos service URNs. >>>>>>>>> >>>>>>>>>* Lots of typos and wording changes. >>>>>>>>> >>>>>>>>>I did end up adding a couple of requirements, and thus needed to >>>>>>>>> >>>>>>>>renumber >>>>>>>> >>>>>>>> >>>>>>>>>the requirements, so diffs look bad. >>>>>>>>> >>>>>>>>>I ask commenters to look at the text to make sure I made all the >>>>>>changes >>>>>> >>>>>>>>you >>>>>>>> >>>>>>>> >>>>>>>>>requested (with the exceptions covered in the emails). >>>>>>>>> >>>>>>>>>Chairs can consider if they wish to hold a short 2nd WGLC. >>>>>>>>>There are >>>>>>a >>>>>> >>>>>>>>>couple of substantive changes and added requirements, but not a whole >>>>>>>>> >>>>>>>>lot >>>>>>>> >>>>>>>> >>>>>>>>>text is modified in any but trivial ways. >>>>>>>>> >>>>>>>>>Brian >>>>>>>>> >>>>>>>>>_______________________________________________ >>>>>>>>>Ecrit mailing 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 Mon Jul 14 11:07:03 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48E7628C0F7; Mon, 14 Jul 2008 11:07:03 -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 87C733A6BF9 for ; Mon, 14 Jul 2008 11:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtYtMxuZbc+Y for ; Mon, 14 Jul 2008 11:07:00 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id B7BC83A6C0D for ; Mon, 14 Jul 2008 11:06:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,360,1212364800"; d="scan'208";a="87011817" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 14 Jul 2008 18:07:21 +0000 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 m6EI7Lhw016384; Mon, 14 Jul 2008 11:07:21 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6EI7LCs009568; Mon, 14 Jul 2008 18:07:21 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, 14 Jul 2008 11:07:21 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.84.1]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 11:07:20 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Jul 2008 13:07:23 -0500 To: Hannes Tschofenig From: "James M. Polk" In-Reply-To: <487B90B2.2030906@gmx.net> References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> <023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com> <48787395.1040507@gmx.net> <053301c8e4fb$ac68e960$640fa8c0@cis.neustar.com> <487B90B2.2030906@gmx.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 14 Jul 2008 18:07:20.0738 (UTC) FILETIME=[75869820:01C8E5DC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=623; t=1216058841; x=1216922841; 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]=20=22Derived=22=20method |Sender:=20; bh=F+4mi/V+DgfnqOfRTb4CFrzGaQ1WE7oya9Kc7GoanTQ=; b=kGrODRDR5/iUgzskywHsvyy+b0AbbcZ48PmwF6krzCFBQcQ7WLao1xb4SF e6mc94BRYgAXX8nN+ASHLWsRQTjWGQAG335WLg51WqmwlLzBEOu7gicBf9f1 cDDnUYx5BF4J73fB+Qyruc4U/BgsrG2qm6mpWtzh2EDafbe4Q2l1M=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 12:45 PM 7/14/2008, Hannes Tschofenig wrote: >>therefore the element has to be THE way the whole LO was >>discovered, regardless of how many formats (civic, geo, >>whatever's_coming_next) are in the LO. >> >>IF there are two locations, and they were discovered using >>different methods, that's TWO PIDF-LOs; else there's confusion. > >That does not seem to be right. > >When I return civic and geo then I doubt that both are determined >using the same mechanism. tell me how many times DHCP Option 99 and 123 "cannot" be in the SAME message? (then re-read what you wrote above, please) _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 14 11:09:06 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB6903A6C13; Mon, 14 Jul 2008 11:09: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 617FA3A6995 for ; Mon, 14 Jul 2008 11:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTvjHRMi2cOx for ; Mon, 14 Jul 2008 11:09:04 -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 047133A6BF9 for ; Mon, 14 Jul 2008 11:09:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,360,1212364800"; d="scan'208";a="52738548" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 14 Jul 2008 18:09:26 +0000 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 m6EI9QYY018025; Mon, 14 Jul 2008 11:09:26 -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.13.8/8.13.8) with ESMTP id m6EI9QEg016542; Mon, 14 Jul 2008 18:09:26 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, 14 Jul 2008 11:09:26 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.84.1]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 11:09:25 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Jul 2008 13:09:28 -0500 To: "Brian Rosen" , "'Hannes Tschofenig'" From: "James M. Polk" In-Reply-To: <093401c8e5da$4500f120$640fa8c0@cis.neustar.com> References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> <023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com> <48787395.1040507@gmx.net> <03eb01c8e425$35b47180$640fa8c0@cis.neustar.com> <4878B640.1050907@gmx.net> <4878BD4C.5070805@gmx.net> <093401c8e5da$4500f120$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 14 Jul 2008 18:09:25.0665 (UTC) FILETIME=[BFFCF110:01C8E5DC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8490; t=1216058966; x=1216922966; 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]=20=22Derived=22=20method |Sender:=20; bh=rjXUgtwxhKNu6fxjWg1SHS3ZsoqMR85I6eLZuHh2mV4=; b=c4k9XHJYMbYmA0oAzT7nQeHaWqBhBtZ4sslrUzTtVbawa+eWzYKfiA0i9a s02h5KTJPus8cesw7pEV10nZjFx95BdUNldFaNmq9HdALc4akk+i2PuZj1RA +Bahv2sQ87; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 12:51 PM 7/14/2008, Brian Rosen wrote: >Perhaps we need to re-examine what we need. > >It doesn't seem useful to me to know by which protocol the PIDF creator >learned location ('dhcp'). > >It does seem useful to understand the determination mechanism that was used >to discover the location ('a-gps'). > >If we need to update 4119, let's do that. until we have viable determination mechanisms agreed to, we cannot do any of this We shouldn't guess which ones will be passed by the WG. >Brian > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > > James M. Polk > > Sent: Monday, July 14, 2008 1:18 PM > > To: Hannes Tschofenig > > Cc: 'ECRIT' > > Subject: Re: [Ecrit] "Derived" method > > > > At 09:18 AM 7/12/2008, Hannes Tschofenig wrote: > > >The problem is a bit with the semantic of the method token given > > >that it was supposed to be used to indicate the location determination > > method. > > > > this is simply not true. Your definition is adding meaning that isn't > > there. > > > > The element is the indication, solely created by the > > endpoint (as an LG), of how it received (i.e., "discovered") location > > information (not LO, but LI). > > > > Case in point, if a target has a sighter that derives location based > > on triangulating the position of the target, yet delivers that LI via > > DHCP, the would NOT say > > > > triangulation > > > > it would say > > > > dhcp > > > > and be correct. > > > > >There are some "wrong" entries in the table already with that > > >semantic since something like "DHCP" refers to an LCP rather than > > >the actual location determination method. > > > > This is not true either. If a target (as an LG) discovers its LI > > from DHCP (Option 99 or 123), then this is the > > > > dhcp > > > > James W. added some additional semantics to the additional values > > without running them by the WG when he IANA registered them, so the > > non-4119 defined values haven't been fully vetted. > > > > This is because 4119 doesn't require any review of any kind before > > adding new IANA entries to this registry. > > > > > > > > >Now, I wonder whether it is possible to put more than one token into > > >the method element. The data type is string and hence it would be > > possible. > > > > > >To pick your example, could you indicate gps derived? > > > > > >Ciao > > >Hannes > > > > > >PS: I wonder whether there is actually a way to deprecate certain > > >tokens from the registry. Nothing is indicated in RFC 4119. "802.11" > > >and "DHCP" "LLDP-MED" really does not belong in there. FCFS as a > > >policy for assignment does not sound useful to me either; expert > > >review would be more useful. > > > > Hennes - these 4119 values were the only ones that ever were "expert > > reviewed", if you consider Geopriv a place where that can take place. > > > > BTW -- you were there for this expert review... perhaps you will > > reconsider this stance once you re-evaluate how these entries are > > 4119 intended. > > > > > > > > > > >Hannes Tschofenig wrote: > > >>Thanks. > > >> > > >>Brian Rosen wrote: > > >>>The "Derived" method is used when the PIDF creator has a location > > available > > >>>in one form (civic or geo) using another method, and derives a location > > in > > >>>the other form. So for example, the determination method might be GPS, > > >>>which creates a geo and the PIDF includes a civic derived from that > > geo. > > >>> > > >>>Brian > > >>> > > >>> > > >>>>-----Original Message----- > > >>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > >>>>Sent: Saturday, July 12, 2008 5:04 AM > > >>>>To: Brian Rosen > > >>>>Cc: 'Karl Heinz Wolf'; 'ECRIT' > > >>>>Subject: "Derived" method > > >>>> > > >>>>Could you describe the semantic of the "Derived" method a bit more? > > >>>> > > >>>>Brian Rosen wrote: > > >>>> > > >>>>>I am sorry, I don't know how I missed these. > > >>>>> > > >>>>> > > >>>>> > > >>>>>>page 7: "The phone gets location from the DHCP server in civic > > >>>>>>[RFC4676] or geo" -> should it be "and/or"? > > >>>>>> > > >>>>>> > > >>>>>The text makes clear that multiple locations are problematic. > > Multiple > > >>>>>versions of the same location are problematic. I worry about systems > > >>>>> > > >>>>trying > > >>>> > > >>>>>to be helpful and giving you a measured location and also giving you > > a > > >>>>>derived (geo coded or reverse geo coded) version of the same > > location. > > >>>>> > > >>>>>This does raise yet another issue about this general subject; looking > > at > > >>>>> > > >>>>the > > >>>> > > >>>>>list at: > > >>>>>http://www.iana.org/assignments/method-tokens > > >>>>>There is no method for "derived". So: > > >>>>>I will add text to -framework covering this subject > > >>>>>I will ask IANA to create a "Derived" method token > > >>>>>I will add a requirement to -phonebcp that says if you get both and > > one > > >>>>> > > >>>>is > > >>>> > > >>>>>derived, you must use the non-derived value. > > >>>>> > > >>>>>I've made the other changes in my source file and they will appear in > > >>>>> > > >>>>the > > >>>> > > >>>>>next version. > > >>>>> > > >>>>>Brian > > >>>>> > > >>>>> > > >>>>>>-----Original Message----- > > >>>>>>From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > >>>>>>Sent: Friday, July 11, 2008 6:00 AM > > >>>>>>To: Brian Rosen > > >>>>>>Cc: ECRIT > > >>>>>>Subject: Re: [Ecrit] New versions of -framework and -phonebcp > > >>>>>> > > >>>>>>Brian, > > >>>>>> > > >>>>>>thank you for submitting the new versions of your documents. > > >>>>>>However, I'm afraid you forgot my comments (except the LoSt > > dialstring > > >>>>>>"must"). > > >>>>>>My old posting: > > >>>>>>http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html > > >>>>>>In your reply to this mail you agreed to these points. > > >>>>>> > > >>>>>>Karl Heinz > > >>>>>> > > >>>>>>On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen > > >>>>>> > > >>>>wrote: > > >>>> > > >>>>>>>These versions incorporate all last call comments except as I have > > >>>>>>> > > >>>>>>> > > >>>>>>stated in > > >>>>>> > > >>>>>> > > >>>>>>>prior email. > > >>>>>>> > > >>>>>>>The majority of changes have to do with: > > >>>>>>>* More explicit text and references to -profile for multiple > > locations > > >>>>>>> > > >>>>>>>* Requiring the return of dialstrings on LoST for sos service URNs. > > >>>>>>> > > >>>>>>>* Lots of typos and wording changes. > > >>>>>>> > > >>>>>>>I did end up adding a couple of requirements, and thus needed to > > >>>>>>> > > >>>>>>> > > >>>>>>renumber > > >>>>>> > > >>>>>> > > >>>>>>>the requirements, so diffs look bad. > > >>>>>>> > > >>>>>>>I ask commenters to look at the text to make sure I made all the > > >>>>>>> > > >>>>changes > > >>>> > > >>>>>>you > > >>>>>> > > >>>>>> > > >>>>>>>requested (with the exceptions covered in the emails). > > >>>>>>> > > >>>>>>>Chairs can consider if they wish to hold a short 2nd WGLC. There > > are > > >>>>>>> > > >>>>a > > >>>> > > >>>>>>>couple of substantive changes and added requirements, but not a > > whole > > >>>>>>> > > >>>>>>> > > >>>>>>lot > > >>>>>> > > >>>>>> > > >>>>>>>text is modified in any but trivial ways. > > >>>>>>> > > >>>>>>>Brian > > >>>>>>> > > >>>>>>>_______________________________________________ > > >>>>>>>Ecrit mailing 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 Mon Jul 14 11:12:12 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EFC43A6995; Mon, 14 Jul 2008 11:12: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 3B9BE3A6847 for ; Mon, 14 Jul 2008 11:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upEGeTzJufRV for ; Mon, 14 Jul 2008 11:12:10 -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 4BEDD3A6A7D for ; Mon, 14 Jul 2008 11:11:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,360,1212364800"; d="scan'208";a="126525185" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 14 Jul 2008 18:11:07 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m6EIB7FB007208; Mon, 14 Jul 2008 11:11:07 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m6EIB7jc027026; Mon, 14 Jul 2008 18:11:07 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, 14 Jul 2008 11:11:07 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.84.1]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 11:11:07 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Jul 2008 13:11:10 -0500 To: "Brian Rosen" , "'Hannes Tschofenig'" From: "James M. Polk" In-Reply-To: <093b01c8e5da$82b461f0$640fa8c0@cis.neustar.com> References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> <023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com> <48787395.1040507@gmx.net> <053301c8e4fb$ac68e960$640fa8c0@cis.neustar.com> <093b01c8e5da$82b461f0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 14 Jul 2008 18:11:07.0233 (UTC) FILETIME=[FC86FD10:01C8E5DC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7819; t=1216059067; x=1216923067; 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]=20=22Derived=22=20method |Sender:=20; bh=CFygs7J6bpv6eS0U+mpUCV6yry6CdMgh0T3ITpleO1w=; b=RtJucXd+yfxyCH7dX7l6TTcNgqY7Mi9WCHG+16wOnmksUF8jc/4OJLj86T SRDNVamtemC7xuYzxI0+4b3aAq6BSM2q3Ze/LdVH2cRdBdM9Am6TxmXqyrUG uiMAznfxvb; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 12:53 PM 7/14/2008, Brian Rosen wrote: >I would say this is an error. > >I think we need to determine what "method" should mean (prior email) first, >but then we should fix this so that each location info section has its own >method. err, has a clear definition now. If you want to change that definition, then we need to have a discussion - including the impact of changing the original definition. >Brian > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Monday, July 14, 2008 1:33 PM > > To: Brian Rosen; 'Hannes Tschofenig' > > Cc: 'ECRIT' > > Subject: Re: [Ecrit] "Derived" method > > > > At 10:18 AM 7/13/2008, Brian Rosen wrote: > > >I think we can get quite carried away with all the possibilities, and > > there > > >is no reason to be carried away. > > > > > >The possibilities are: > > >1. There is exactly one location, and it's marked "Derived". There is no > > >need for more information. > > > > I agree with this > > > > >2. There are exactly two locations, and one is marked "Derived". This > > means > > >the other is the original > > > > I do not agree with this. > > > > Here's how I got there > > > > The element is a sub-element of what element? > > > > Is it ? > > > > no -- it's parallel to it > > > > therefore the element has to be THE way the whole LO was > > discovered, regardless of how many formats (civic, geo, > > whatever's_coming_next) are in the LO. > > > > IF there are two locations, and they were discovered using different > > methods, that's TWO PIDF-LOs; else there's confusion. > > > > >3. There are more than two locations and one or more is marked "Derived". > > I > > >think we can ignore this case, or at least say that there is no way to > > >understand what is derived from what. > > > > > >Brian > > > > > > > -----Original Message----- > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > Sent: Saturday, July 12, 2008 10:37 PM > > > > To: Hannes Tschofenig; Brian Rosen > > > > Cc: ECRIT > > > > Subject: RE: [Ecrit] "Derived" method > > > > > > > > Hi Brian, > > > > > > > > For derived to really have a clear meaning it needs to be totally > > > > unambiguous what the location is derived from. > > > > The example I always hear is a civic address derived from a geodetic > > > > shape, or vice versa. In this case, you need to provide both locations > > in > > > > the PIDF-LO document, and somehow, there needs to be a link between > > them. > > > > Simply havinf both locations in the same document isn't sufficient, I > > > > think you need the equivalent of an tag, or something like > > that. > > > > > > > > Cheers > > > > James > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > > > > Sent: Sat 7/12/2008 4:04 AM > > > > To: Brian Rosen > > > > Cc: 'ECRIT' > > > > Subject: [Ecrit] "Derived" method > > > > > > > > Could you describe the semantic of the "Derived" method a bit more? > > > > > > > > Brian Rosen wrote: > > > > > I am sorry, I don't know how I missed these. > > > > > > > > > > > > > > >> page 7: "The phone gets location from the DHCP server in civic > > > > >> [RFC4676] or geo" -> should it be "and/or"? > > > > >> > > > > > The text makes clear that multiple locations are problematic. > > Multiple > > > > > versions of the same location are problematic. I worry about > > systems > > > > trying > > > > > to be helpful and giving you a measured location and also giving you > > a > > > > > derived (geo coded or reverse geo coded) version of the same > > location. > > > > > > > > > > This does raise yet another issue about this general subject; > > looking at > > > > the > > > > > list at: > > > > > http://www.iana.org/assignments/method-tokens > > > > > There is no method for "derived". So: > > > > > I will add text to -framework covering this subject > > > > > I will ask IANA to create a "Derived" method token > > > > > I will add a requirement to -phonebcp that says if you get both and > > one > > > > is > > > > > derived, you must use the non-derived value. > > > > > > > > > > I've made the other changes in my source file and they will appear > > in > > > > the > > > > > next version. > > > > > > > > > > Brian > > > > > > > > > >> -----Original Message----- > > > > >> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > > > >> Sent: Friday, July 11, 2008 6:00 AM > > > > >> To: Brian Rosen > > > > >> Cc: ECRIT > > > > >> Subject: Re: [Ecrit] New versions of -framework and -phonebcp > > > > >> > > > > >> Brian, > > > > >> > > > > >> thank you for submitting the new versions of your documents. > > > > >> However, I'm afraid you forgot my comments (except the LoSt > > dialstring > > > > >> "must"). > > > > >> My old posting: > > > > >> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html > > > > >> In your reply to this mail you agreed to these points. > > > > >> > > > > >> Karl Heinz > > > > >> > > > > >> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen > > > > wrote: > > > > >> > > > > >>> These versions incorporate all last call comments except as I have > > > > >>> > > > > >> stated in > > > > >> > > > > >>> prior email. > > > > >>> > > > > >>> The majority of changes have to do with: > > > > >>> * More explicit text and references to -profile for multiple > > locations > > > > >>> > > > > >>> * Requiring the return of dialstrings on LoST for sos service > > URNs. > > > > >>> > > > > >>> * Lots of typos and wording changes. > > > > >>> > > > > >>> I did end up adding a couple of requirements, and thus needed to > > > > >>> > > > > >> renumber > > > > >> > > > > >>> the requirements, so diffs look bad. > > > > >>> > > > > >>> I ask commenters to look at the text to make sure I made all the > > > > changes > > > > >>> > > > > >> you > > > > >> > > > > >>> requested (with the exceptions covered in the emails). > > > > >>> > > > > >>> Chairs can consider if they wish to hold a short 2nd WGLC. There > > are > > > > a > > > > >>> couple of substantive changes and added requirements, but not a > > whole > > > > >>> > > > > >> lot > > > > >> > > > > >>> text is modified in any but trivial ways. > > > > >>> > > > > >>> Brian > > > > >>> > > > > >>> _______________________________________________ > > > > >>> Ecrit mailing 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 Jul 14 11:12:12 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A674828C122; Mon, 14 Jul 2008 11:12: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 DB9613A69D8 for ; Mon, 14 Jul 2008 11:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-dhOH3RTe5z for ; Mon, 14 Jul 2008 11:12:10 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 45EF23A67B7 for ; Mon, 14 Jul 2008 11:11:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,360,1212364800"; d="scan'208";a="87013877" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 14 Jul 2008 18:11:54 +0000 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 m6EIBsTN008620; Mon, 14 Jul 2008 11:11:54 -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.13.8/8.13.8) with ESMTP id m6EIBsdP019093; Mon, 14 Jul 2008 18:11:54 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, 14 Jul 2008 11:11:54 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.84.1]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 11:11:53 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Jul 2008 13:11:57 -0500 To: Marc Linsner , Hannes Tschofenig From: "James M. Polk" In-Reply-To: References: <487B8D31.4000402@gmx.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 14 Jul 2008 18:11:53.0968 (UTC) FILETIME=[18622F00:01C8E5DD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8935; t=1216059114; x=1216923114; 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]=20=22Derived=22=20method |Sender:=20; bh=tiP8kQp3YtPBZ4ot89ha1DYyVuzfsPDVBh0L0ZE/mpA=; b=uRdyqYWkDCepSzT/DeS8ItapesQ5aBG4lhkgUJvafECNv47ObW3ickRHoS L8PuNU+2Vvuw3tONMMsWo8MFHz0HudTW2Jk7CEdYJ1cb9m4hLBYr4dVwppjf q5vezexSZh; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 12:54 PM 7/14/2008, Marc Linsner wrote: >I'm not convinced any of this information is useful to a LR. > >Would the pizza be warmer when delivered if the delivery person had this >information? > >What would the LR do if the location information is wrong and they knew it >was derived by a ouija board vs. a wiremap database vs. triangulation? > >What if the wiremap database was populated using gps? bingo >-Marc- > > >On 7/14/08 1:30 PM, "Hannes Tschofenig" wrote: > > > RFC 4119 isn't super exhaustive in the description of the semantic of > > the element and what it is being used for. > > > > What could be more useful for the Location Recipient to know: > > > > * Location was obtained using DHCP, or LLDP-MED > > > > OR > > > > * Location was determined using manual configuration, wiremap database, > > triangulation. > > > > > > Ciao > > Hannes > > > > > > > > James M. Polk wrote: > >> At 09:18 AM 7/12/2008, Hannes Tschofenig wrote: > >>> The problem is a bit with the semantic of the method token given that > >>> it was supposed to be used to indicate the location determination > >>> method. > >> > >> this is simply not true. Your definition is adding meaning that isn't > >> there. > >> > >> The element is the indication, solely created by the endpoint > >> (as an LG), of how it received (i.e., "discovered") location > >> information (not LO, but LI). > >> > >> Case in point, if a target has a sighter that derives location based > >> on triangulating the position of the target, yet delivers that LI via > >> DHCP, the would NOT say > >> > >> triangulation > >> > >> it would say > >> > >> dhcp > >> > >> and be correct. > >> > >>> There are some "wrong" entries in the table already with that > >>> semantic since something like "DHCP" refers to an LCP rather than the > >>> actual location determination method. > >> > >> This is not true either. If a target (as an LG) discovers its LI from > >> DHCP (Option 99 or 123), then this is the > >> > >> dhcp > >> > >> James W. added some additional semantics to the additional values > >> without running them by the WG when he IANA registered them, so the > >> non-4119 defined values haven't been fully vetted. > >> > >> This is because 4119 doesn't require any review of any kind before > >> adding new IANA entries to this registry. > >> > >> > >> > >>> Now, I wonder whether it is possible to put more than one token into > >>> the method element. The data type is string and hence it would be > >>> possible. > >>> > >>> To pick your example, could you indicate gps derived? > >>> > >>> Ciao > >>> Hannes > >>> > >>> PS: I wonder whether there is actually a way to deprecate certain > >>> tokens from the registry. Nothing is indicated in RFC 4119. "802.11" > >>> and "DHCP" "LLDP-MED" really does not belong in there. FCFS as a > >>> policy for assignment does not sound useful to me either; expert > >>> review would be more useful. > >> > >> Hennes - these 4119 values were the only ones that ever were "expert > >> reviewed", if you consider Geopriv a place where that can take place. > >> > >> BTW -- you were there for this expert review... perhaps you will > >> reconsider this stance once you re-evaluate how these entries are 4119 > >> intended. > >> > >> > >> > >> > >>> Hannes Tschofenig wrote: > >>>> Thanks. > >>>> > >>>> Brian Rosen wrote: > >>>>> The "Derived" method is used when the PIDF creator has a location > >>>>> available > >>>>> in one form (civic or geo) using another method, and derives a > >>>>> location in > >>>>> the other form. So for example, the determination method might be > >>>>> GPS, > >>>>> which creates a geo and the PIDF includes a civic derived from that > >>>>> geo. > >>>>> > >>>>> Brian > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>>> Sent: Saturday, July 12, 2008 5:04 AM > >>>>>> To: Brian Rosen > >>>>>> Cc: 'Karl Heinz Wolf'; 'ECRIT' > >>>>>> Subject: "Derived" method > >>>>>> > >>>>>> Could you describe the semantic of the "Derived" method a bit more? > >>>>>> > >>>>>> Brian Rosen wrote: > >>>>>> > >>>>>>> I am sorry, I don't know how I missed these. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> page 7: "The phone gets location from the DHCP server in civic > >>>>>>>> [RFC4676] or geo" -> should it be "and/or"? > >>>>>>>> > >>>>>>>> > >>>>>>> The text makes clear that multiple locations are problematic. > >>>>>>> Multiple > >>>>>>> versions of the same location are problematic. I worry about > >>>>>>> systems > >>>>>>> > >>>>>> trying > >>>>>> > >>>>>>> to be helpful and giving you a measured location and also giving > >>>>>>> you a > >>>>>>> derived (geo coded or reverse geo coded) version of the same > >>>>>>> location. > >>>>>>> > >>>>>>> This does raise yet another issue about this general subject; > >>>>>>> looking at > >>>>>>> > >>>>>> the > >>>>>> > >>>>>>> list at: > >>>>>>> http://www.iana.org/assignments/method-tokens > >>>>>>> There is no method for "derived". So: > >>>>>>> I will add text to -framework covering this subject > >>>>>>> I will ask IANA to create a "Derived" method token > >>>>>>> I will add a requirement to -phonebcp that says if you get both > >>>>>>> and one > >>>>>>> > >>>>>> is > >>>>>> > >>>>>>> derived, you must use the non-derived value. > >>>>>>> > >>>>>>> I've made the other changes in my source file and they will > >>>>>>> appear in > >>>>>>> > >>>>>> the > >>>>>> > >>>>>>> next version. > >>>>>>> > >>>>>>> Brian > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > >>>>>>>> Sent: Friday, July 11, 2008 6:00 AM > >>>>>>>> To: Brian Rosen > >>>>>>>> Cc: ECRIT > >>>>>>>> Subject: Re: [Ecrit] New versions of -framework and -phonebcp > >>>>>>>> > >>>>>>>> Brian, > >>>>>>>> > >>>>>>>> thank you for submitting the new versions of your documents. > >>>>>>>> However, I'm afraid you forgot my comments (except the LoSt > >>>>>>>> dialstring > >>>>>>>> "must"). > >>>>>>>> My old posting: > >>>>>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html > >>>>>>>> In your reply to this mail you agreed to these points. > >>>>>>>> > >>>>>>>> Karl Heinz > >>>>>>>> > >>>>>>>> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen > >>>>>>>> > >>>>>> wrote: > >>>>>> > >>>>>>>>> These versions incorporate all last call comments except as I have > >>>>>>>>> > >>>>>>>>> > >>>>>>>> stated in > >>>>>>>> > >>>>>>>> > >>>>>>>>> prior email. > >>>>>>>>> > >>>>>>>>> The majority of changes have to do with: > >>>>>>>>> * More explicit text and references to -profile for multiple > >>>>>>>>> locations > >>>>>>>>> > >>>>>>>>> * Requiring the return of dialstrings on LoST for sos service > >>>>>>>>> URNs. > >>>>>>>>> > >>>>>>>>> * Lots of typos and wording changes. > >>>>>>>>> > >>>>>>>>> I did end up adding a couple of requirements, and thus needed to > >>>>>>>>> > >>>>>>>>> > >>>>>>>> renumber > >>>>>>>> > >>>>>>>> > >>>>>>>>> the requirements, so diffs look bad. > >>>>>>>>> > >>>>>>>>> I ask commenters to look at the text to make sure I made all the > >>>>>>>>> > >>>>>> changes > >>>>>> > >>>>>>>> you > >>>>>>>> > >>>>>>>> > >>>>>>>>> requested (with the exceptions covered in the emails). > >>>>>>>>> > >>>>>>>>> Chairs can consider if they wish to hold a short 2nd WGLC. > >>>>>>>>> There are > >>>>>>>>> > >>>>>> a > >>>>>> > >>>>>>>>> couple of substantive changes and added requirements, but not a > >>>>>>>>> whole > >>>>>>>>> > >>>>>>>>> > >>>>>>>> lot > >>>>>>>> > >>>>>>>> > >>>>>>>>> text is modified in any but trivial ways. > >>>>>>>>> > >>>>>>>>> Brian > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Ecrit mailing 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 Mon Jul 14 11:18:12 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33E6F28C0D9; Mon, 14 Jul 2008 11:18: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 00D9328C0D9 for ; Mon, 14 Jul 2008 11:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Czyf82HEPUyB for ; Mon, 14 Jul 2008 11:18:09 -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 E3F603A6994 for ; Mon, 14 Jul 2008 11:18:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,360,1212364800"; d="scan'208";a="14255642" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Jul 2008 18:18:34 +0000 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 m6EIIYZb032327; Mon, 14 Jul 2008 14:18:34 -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.13.8/8.13.8) with ESMTP id m6EIIYlw016523; Mon, 14 Jul 2008 18:18:34 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, 14 Jul 2008 14:18:34 -0400 Received: from [10.116.195.115] ([10.116.195.115]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 14:18:33 -0400 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Mon, 14 Jul 2008 14:18:32 -0400 From: Marc Linsner To: Brian Rosen Message-ID: Thread-Topic: [Ecrit] "Derived" method Thread-Index: Acjl2rJ550Y6QF3avE2es8xxCUxJhAAAKd1AAACq7ZI= In-Reply-To: <094e01c8e5db$f985c070$640fa8c0@cis.neustar.com> Mime-version: 1.0 X-OriginalArrivalTime: 14 Jul 2008 18:18:33.0648 (UTC) FILETIME=[069C8300:01C8E5DE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9891; t=1216059514; x=1216923514; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20=22Derived=22=20method |Sender:=20 |To:=20Brian=20Rosen=20; bh=K1XgN/SgEMDlzsTZFbFcnbjdeKJzes8nUHneY3oDaTE=; b=gmIGxS5i0f4CR0DzEyP/zR+X1P3Fo/Tj4XaPdR9i6Hzt8CaHzldywYFRT2 sKDUZxOzq9i/p84aQQmB1ZdOF7/9p0DHeMinZUSGmuZ5ZT/Fpx3syYGGsdEz vkpl8N1l/J; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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, > You can reasonably infer things based on it. This will make the pizza warmer how? -Marc- > > For example, wiremap data would never change. GPS data might. If you > measured wiremap data with gps, it would not likely change. No guarantees. > > > Another example would be "cell". If you ask for an update later, in some > countries, you likely will get a better location (using a different method). > > Brian > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> Marc Linsner >> Sent: Monday, July 14, 2008 1:55 PM >> To: Hannes Tschofenig; James Polk >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] "Derived" method >> >> I'm not convinced any of this information is useful to a LR. >> >> Would the pizza be warmer when delivered if the delivery person had this >> information? >> >> What would the LR do if the location information is wrong and they knew it >> was derived by a ouija board vs. a wiremap database vs. triangulation? >> >> What if the wiremap database was populated using gps? >> >> -Marc- >> >> >> On 7/14/08 1:30 PM, "Hannes Tschofenig" wrote: >> >>> RFC 4119 isn't super exhaustive in the description of the semantic of >>> the element and what it is being used for. >>> >>> What could be more useful for the Location Recipient to know: >>> >>> * Location was obtained using DHCP, or LLDP-MED >>> >>> OR >>> >>> * Location was determined using manual configuration, wiremap database, >>> triangulation. >>> >>> >>> Ciao >>> Hannes >>> >>> >>> >>> James M. Polk wrote: >>>> At 09:18 AM 7/12/2008, Hannes Tschofenig wrote: >>>>> The problem is a bit with the semantic of the method token given that >>>>> it was supposed to be used to indicate the location determination >>>>> method. >>>> >>>> this is simply not true. Your definition is adding meaning that isn't >>>> there. >>>> >>>> The element is the indication, solely created by the endpoint >>>> (as an LG), of how it received (i.e., "discovered") location >>>> information (not LO, but LI). >>>> >>>> Case in point, if a target has a sighter that derives location based >>>> on triangulating the position of the target, yet delivers that LI via >>>> DHCP, the would NOT say >>>> >>>> triangulation >>>> >>>> it would say >>>> >>>> dhcp >>>> >>>> and be correct. >>>> >>>>> There are some "wrong" entries in the table already with that >>>>> semantic since something like "DHCP" refers to an LCP rather than the >>>>> actual location determination method. >>>> >>>> This is not true either. If a target (as an LG) discovers its LI from >>>> DHCP (Option 99 or 123), then this is the >>>> >>>> dhcp >>>> >>>> James W. added some additional semantics to the additional values >>>> without running them by the WG when he IANA registered them, so the >>>> non-4119 defined values haven't been fully vetted. >>>> >>>> This is because 4119 doesn't require any review of any kind before >>>> adding new IANA entries to this registry. >>>> >>>> >>>> >>>>> Now, I wonder whether it is possible to put more than one token into >>>>> the method element. The data type is string and hence it would be >>>>> possible. >>>>> >>>>> To pick your example, could you indicate gps derived? >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> PS: I wonder whether there is actually a way to deprecate certain >>>>> tokens from the registry. Nothing is indicated in RFC 4119. "802.11" >>>>> and "DHCP" "LLDP-MED" really does not belong in there. FCFS as a >>>>> policy for assignment does not sound useful to me either; expert >>>>> review would be more useful. >>>> >>>> Hennes - these 4119 values were the only ones that ever were "expert >>>> reviewed", if you consider Geopriv a place where that can take place. >>>> >>>> BTW -- you were there for this expert review... perhaps you will >>>> reconsider this stance once you re-evaluate how these entries are 4119 >>>> intended. >>>> >>>> >>>> >>>> >>>>> Hannes Tschofenig wrote: >>>>>> Thanks. >>>>>> >>>>>> Brian Rosen wrote: >>>>>>> The "Derived" method is used when the PIDF creator has a location >>>>>>> available >>>>>>> in one form (civic or geo) using another method, and derives a >>>>>>> location in >>>>>>> the other form. So for example, the determination method might be >>>>>>> GPS, >>>>>>> which creates a geo and the PIDF includes a civic derived from that >>>>>>> geo. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>> Sent: Saturday, July 12, 2008 5:04 AM >>>>>>>> To: Brian Rosen >>>>>>>> Cc: 'Karl Heinz Wolf'; 'ECRIT' >>>>>>>> Subject: "Derived" method >>>>>>>> >>>>>>>> Could you describe the semantic of the "Derived" method a bit more? >>>>>>>> >>>>>>>> Brian Rosen wrote: >>>>>>>> >>>>>>>>> I am sorry, I don't know how I missed these. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> page 7: "The phone gets location from the DHCP server in civic >>>>>>>>>> [RFC4676] or geo" -> should it be "and/or"? >>>>>>>>>> >>>>>>>>>> >>>>>>>>> The text makes clear that multiple locations are problematic. >>>>>>>>> Multiple >>>>>>>>> versions of the same location are problematic. I worry about >>>>>>>>> systems >>>>>>>>> >>>>>>>> trying >>>>>>>> >>>>>>>>> to be helpful and giving you a measured location and also giving >>>>>>>>> you a >>>>>>>>> derived (geo coded or reverse geo coded) version of the same >>>>>>>>> location. >>>>>>>>> >>>>>>>>> This does raise yet another issue about this general subject; >>>>>>>>> looking at >>>>>>>>> >>>>>>>> the >>>>>>>> >>>>>>>>> list at: >>>>>>>>> http://www.iana.org/assignments/method-tokens >>>>>>>>> There is no method for "derived". So: >>>>>>>>> I will add text to -framework covering this subject >>>>>>>>> I will ask IANA to create a "Derived" method token >>>>>>>>> I will add a requirement to -phonebcp that says if you get both >>>>>>>>> and one >>>>>>>>> >>>>>>>> is >>>>>>>> >>>>>>>>> derived, you must use the non-derived value. >>>>>>>>> >>>>>>>>> I've made the other changes in my source file and they will >>>>>>>>> appear in >>>>>>>>> >>>>>>>> the >>>>>>>> >>>>>>>>> next version. >>>>>>>>> >>>>>>>>> Brian >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >>>>>>>>>> Sent: Friday, July 11, 2008 6:00 AM >>>>>>>>>> To: Brian Rosen >>>>>>>>>> Cc: ECRIT >>>>>>>>>> Subject: Re: [Ecrit] New versions of -framework and -phonebcp >>>>>>>>>> >>>>>>>>>> Brian, >>>>>>>>>> >>>>>>>>>> thank you for submitting the new versions of your documents. >>>>>>>>>> However, I'm afraid you forgot my comments (except the LoSt >>>>>>>>>> dialstring >>>>>>>>>> "must"). >>>>>>>>>> My old posting: >>>>>>>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html >>>>>>>>>> In your reply to this mail you agreed to these points. >>>>>>>>>> >>>>>>>>>> Karl Heinz >>>>>>>>>> >>>>>>>>>> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen >>>>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>>>> These versions incorporate all last call comments except as I >> have >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> stated in >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> prior email. >>>>>>>>>>> >>>>>>>>>>> The majority of changes have to do with: >>>>>>>>>>> * More explicit text and references to -profile for multiple >>>>>>>>>>> locations >>>>>>>>>>> >>>>>>>>>>> * Requiring the return of dialstrings on LoST for sos service >>>>>>>>>>> URNs. >>>>>>>>>>> >>>>>>>>>>> * Lots of typos and wording changes. >>>>>>>>>>> >>>>>>>>>>> I did end up adding a couple of requirements, and thus needed to >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> renumber >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> the requirements, so diffs look bad. >>>>>>>>>>> >>>>>>>>>>> I ask commenters to look at the text to make sure I made all the >>>>>>>>>>> >>>>>>>> changes >>>>>>>> >>>>>>>>>> you >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> requested (with the exceptions covered in the emails). >>>>>>>>>>> >>>>>>>>>>> Chairs can consider if they wish to hold a short 2nd WGLC. >>>>>>>>>>> There are >>>>>>>>>>> >>>>>>>> a >>>>>>>> >>>>>>>>>>> couple of substantive changes and added requirements, but not a >>>>>>>>>>> whole >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> lot >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> text is modified in any but trivial ways. >>>>>>>>>>> >>>>>>>>>>> Brian >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Ecrit mailing 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 Mon Jul 14 11:28:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BC6D3A6994; Mon, 14 Jul 2008 11:28: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 CF8433A6994; Mon, 14 Jul 2008 11:28:23 -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 2V9fSlYonoVi; Mon, 14 Jul 2008 11:28:22 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 522553A6768; Mon, 14 Jul 2008 11:28:22 -0700 (PDT) Received: from [128.89.254.210] (helo=Lab-Macbook-Pro.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1KISmx-0007Tv-3Z; Mon, 14 Jul 2008 14:28:43 -0400 Message-ID: <487B9ADA.8020708@bbn.com> Date: Mon, 14 Jul 2008 14:28:42 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Marc Linsner References: In-Reply-To: Cc: 'GEOPRIV' , 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I don't have any suggestions for pizza warming, other than that it seems to be inversely related to CO2 emissions -- the more the delivery driver drives, the cooler my pizza gets. (Perhaps if we all order enough pizza, this could offset global warming?) However, I would like to suggest that this conversation move over to the GEOPRIV list. --Richard Marc Linsner wrote: > Brian, > > >> You can reasonably infer things based on it. > > This will make the pizza warmer how? > > -Marc- > >> For example, wiremap data would never change. GPS data might. If you >> measured wiremap data with gps, it would not likely change. No guarantees. >> >> >> Another example would be "cell". If you ask for an update later, in some >> countries, you likely will get a better location (using a different method). >> >> Brian >> >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >>> Marc Linsner >>> Sent: Monday, July 14, 2008 1:55 PM >>> To: Hannes Tschofenig; James Polk >>> Cc: 'ECRIT' >>> Subject: Re: [Ecrit] "Derived" method >>> >>> I'm not convinced any of this information is useful to a LR. >>> >>> Would the pizza be warmer when delivered if the delivery person had this >>> information? >>> >>> What would the LR do if the location information is wrong and they knew it >>> was derived by a ouija board vs. a wiremap database vs. triangulation? >>> >>> What if the wiremap database was populated using gps? >>> >>> -Marc- >>> >>> >>> On 7/14/08 1:30 PM, "Hannes Tschofenig" wrote: >>> >>>> RFC 4119 isn't super exhaustive in the description of the semantic of >>>> the element and what it is being used for. >>>> >>>> What could be more useful for the Location Recipient to know: >>>> >>>> * Location was obtained using DHCP, or LLDP-MED >>>> >>>> OR >>>> >>>> * Location was determined using manual configuration, wiremap database, >>>> triangulation. >>>> >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> >>>> James M. Polk wrote: >>>>> At 09:18 AM 7/12/2008, Hannes Tschofenig wrote: >>>>>> The problem is a bit with the semantic of the method token given that >>>>>> it was supposed to be used to indicate the location determination >>>>>> method. >>>>> this is simply not true. Your definition is adding meaning that isn't >>>>> there. >>>>> >>>>> The element is the indication, solely created by the endpoint >>>>> (as an LG), of how it received (i.e., "discovered") location >>>>> information (not LO, but LI). >>>>> >>>>> Case in point, if a target has a sighter that derives location based >>>>> on triangulating the position of the target, yet delivers that LI via >>>>> DHCP, the would NOT say >>>>> >>>>> triangulation >>>>> >>>>> it would say >>>>> >>>>> dhcp >>>>> >>>>> and be correct. >>>>> >>>>>> There are some "wrong" entries in the table already with that >>>>>> semantic since something like "DHCP" refers to an LCP rather than the >>>>>> actual location determination method. >>>>> This is not true either. If a target (as an LG) discovers its LI from >>>>> DHCP (Option 99 or 123), then this is the >>>>> >>>>> dhcp >>>>> >>>>> James W. added some additional semantics to the additional values >>>>> without running them by the WG when he IANA registered them, so the >>>>> non-4119 defined values haven't been fully vetted. >>>>> >>>>> This is because 4119 doesn't require any review of any kind before >>>>> adding new IANA entries to this registry. >>>>> >>>>> >>>>> >>>>>> Now, I wonder whether it is possible to put more than one token into >>>>>> the method element. The data type is string and hence it would be >>>>>> possible. >>>>>> >>>>>> To pick your example, could you indicate gps derived? >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> PS: I wonder whether there is actually a way to deprecate certain >>>>>> tokens from the registry. Nothing is indicated in RFC 4119. "802.11" >>>>>> and "DHCP" "LLDP-MED" really does not belong in there. FCFS as a >>>>>> policy for assignment does not sound useful to me either; expert >>>>>> review would be more useful. >>>>> Hennes - these 4119 values were the only ones that ever were "expert >>>>> reviewed", if you consider Geopriv a place where that can take place. >>>>> >>>>> BTW -- you were there for this expert review... perhaps you will >>>>> reconsider this stance once you re-evaluate how these entries are 4119 >>>>> intended. >>>>> >>>>> >>>>> >>>>> >>>>>> Hannes Tschofenig wrote: >>>>>>> Thanks. >>>>>>> >>>>>>> Brian Rosen wrote: >>>>>>>> The "Derived" method is used when the PIDF creator has a location >>>>>>>> available >>>>>>>> in one form (civic or geo) using another method, and derives a >>>>>>>> location in >>>>>>>> the other form. So for example, the determination method might be >>>>>>>> GPS, >>>>>>>> which creates a geo and the PIDF includes a civic derived from that >>>>>>>> geo. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>> Sent: Saturday, July 12, 2008 5:04 AM >>>>>>>>> To: Brian Rosen >>>>>>>>> Cc: 'Karl Heinz Wolf'; 'ECRIT' >>>>>>>>> Subject: "Derived" method >>>>>>>>> >>>>>>>>> Could you describe the semantic of the "Derived" method a bit more? >>>>>>>>> >>>>>>>>> Brian Rosen wrote: >>>>>>>>> >>>>>>>>>> I am sorry, I don't know how I missed these. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> page 7: "The phone gets location from the DHCP server in civic >>>>>>>>>>> [RFC4676] or geo" -> should it be "and/or"? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> The text makes clear that multiple locations are problematic. >>>>>>>>>> Multiple >>>>>>>>>> versions of the same location are problematic. I worry about >>>>>>>>>> systems >>>>>>>>>> >>>>>>>>> trying >>>>>>>>> >>>>>>>>>> to be helpful and giving you a measured location and also giving >>>>>>>>>> you a >>>>>>>>>> derived (geo coded or reverse geo coded) version of the same >>>>>>>>>> location. >>>>>>>>>> >>>>>>>>>> This does raise yet another issue about this general subject; >>>>>>>>>> looking at >>>>>>>>>> >>>>>>>>> the >>>>>>>>> >>>>>>>>>> list at: >>>>>>>>>> http://www.iana.org/assignments/method-tokens >>>>>>>>>> There is no method for "derived". So: >>>>>>>>>> I will add text to -framework covering this subject >>>>>>>>>> I will ask IANA to create a "Derived" method token >>>>>>>>>> I will add a requirement to -phonebcp that says if you get both >>>>>>>>>> and one >>>>>>>>>> >>>>>>>>> is >>>>>>>>> >>>>>>>>>> derived, you must use the non-derived value. >>>>>>>>>> >>>>>>>>>> I've made the other changes in my source file and they will >>>>>>>>>> appear in >>>>>>>>>> >>>>>>>>> the >>>>>>>>> >>>>>>>>>> next version. >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >>>>>>>>>>> Sent: Friday, July 11, 2008 6:00 AM >>>>>>>>>>> To: Brian Rosen >>>>>>>>>>> Cc: ECRIT >>>>>>>>>>> Subject: Re: [Ecrit] New versions of -framework and -phonebcp >>>>>>>>>>> >>>>>>>>>>> Brian, >>>>>>>>>>> >>>>>>>>>>> thank you for submitting the new versions of your documents. >>>>>>>>>>> However, I'm afraid you forgot my comments (except the LoSt >>>>>>>>>>> dialstring >>>>>>>>>>> "must"). >>>>>>>>>>> My old posting: >>>>>>>>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html >>>>>>>>>>> In your reply to this mail you agreed to these points. >>>>>>>>>>> >>>>>>>>>>> Karl Heinz >>>>>>>>>>> >>>>>>>>>>> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen >>>>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>>>> These versions incorporate all last call comments except as I >>> have >>>>>>>>>>>> >>>>>>>>>>> stated in >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> prior email. >>>>>>>>>>>> >>>>>>>>>>>> The majority of changes have to do with: >>>>>>>>>>>> * More explicit text and references to -profile for multiple >>>>>>>>>>>> locations >>>>>>>>>>>> >>>>>>>>>>>> * Requiring the return of dialstrings on LoST for sos service >>>>>>>>>>>> URNs. >>>>>>>>>>>> >>>>>>>>>>>> * Lots of typos and wording changes. >>>>>>>>>>>> >>>>>>>>>>>> I did end up adding a couple of requirements, and thus needed to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> renumber >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> the requirements, so diffs look bad. >>>>>>>>>>>> >>>>>>>>>>>> I ask commenters to look at the text to make sure I made all the >>>>>>>>>>>> >>>>>>>>> changes >>>>>>>>> >>>>>>>>>>> you >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> requested (with the exceptions covered in the emails). >>>>>>>>>>>> >>>>>>>>>>>> Chairs can consider if they wish to hold a short 2nd WGLC. >>>>>>>>>>>> There are >>>>>>>>>>>> >>>>>>>>> a >>>>>>>>> >>>>>>>>>>>> couple of substantive changes and added requirements, but not a >>>>>>>>>>>> whole >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> lot >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> text is modified in any but trivial ways. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Ecrit mailing 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 Mon Jul 14 11:29:41 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC9D43A6A18; Mon, 14 Jul 2008 11:29: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 B505B3A6A09 for ; Mon, 14 Jul 2008 11:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 CK3+bvsW6zy6 for ; Mon, 14 Jul 2008 11:29:39 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 376F63A6768 for ; Mon, 14 Jul 2008 11:29:39 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KISoA-0005u5-1E; Mon, 14 Jul 2008 13:29:58 -0500 From: "Brian Rosen" To: "'Marc Linsner'" References: <094e01c8e5db$f985c070$640fa8c0@cis.neustar.com> Date: Mon, 14 Jul 2008 14:30:01 -0400 Message-ID: <097401c8e5df$a2739290$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acjl2rJ550Y6QF3avE2es8xxCUxJhAAAKd1AAACq7ZIAADs/sA== 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: Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 system may make intelligent choices on how/when/whether location updates should be made. If you get "cell", you can't use it. If you get a-gps, you probably can. It's useful enough that PSAPs want to know if its gps or TDOA for example (although they likely don't care really about the variants; they really want to know handset based vs network based). Their expectation of what happens, and when is guided by the information. It also is useful in post mortem examinations (statistical analysis for example). You can't, in at least the current environment, get rid of it, and no one, that I know wants 'dhcp' as an answer. They really don't care about the protocol. They care about how it was determined, not how it was configured or conveyed, using our current terminology. Brian > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Monday, July 14, 2008 2:19 PM > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] "Derived" method > > Brian, > > > > You can reasonably infer things based on it. > > This will make the pizza warmer how? > > -Marc- > > > > > For example, wiremap data would never change. GPS data might. If you > > measured wiremap data with gps, it would not likely change. No > guarantees. > > > > > > Another example would be "cell". If you ask for an update later, in > some > > countries, you likely will get a better location (using a different > method). > > > > Brian > > > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > >> Marc Linsner > >> Sent: Monday, July 14, 2008 1:55 PM > >> To: Hannes Tschofenig; James Polk > >> Cc: 'ECRIT' > >> Subject: Re: [Ecrit] "Derived" method > >> > >> I'm not convinced any of this information is useful to a LR. > >> > >> Would the pizza be warmer when delivered if the delivery person had > this > >> information? > >> > >> What would the LR do if the location information is wrong and they knew > it > >> was derived by a ouija board vs. a wiremap database vs. triangulation? > >> > >> What if the wiremap database was populated using gps? > >> > >> -Marc- > >> > >> > >> On 7/14/08 1:30 PM, "Hannes Tschofenig" > wrote: > >> > >>> RFC 4119 isn't super exhaustive in the description of the semantic of > >>> the element and what it is being used for. > >>> > >>> What could be more useful for the Location Recipient to know: > >>> > >>> * Location was obtained using DHCP, or LLDP-MED > >>> > >>> OR > >>> > >>> * Location was determined using manual configuration, wiremap > database, > >>> triangulation. > >>> > >>> > >>> Ciao > >>> Hannes > >>> > >>> > >>> > >>> James M. Polk wrote: > >>>> At 09:18 AM 7/12/2008, Hannes Tschofenig wrote: > >>>>> The problem is a bit with the semantic of the method token given > that > >>>>> it was supposed to be used to indicate the location determination > >>>>> method. > >>>> > >>>> this is simply not true. Your definition is adding meaning that > isn't > >>>> there. > >>>> > >>>> The element is the indication, solely created by the > endpoint > >>>> (as an LG), of how it received (i.e., "discovered") location > >>>> information (not LO, but LI). > >>>> > >>>> Case in point, if a target has a sighter that derives location based > >>>> on triangulating the position of the target, yet delivers that LI via > >>>> DHCP, the would NOT say > >>>> > >>>> triangulation > >>>> > >>>> it would say > >>>> > >>>> dhcp > >>>> > >>>> and be correct. > >>>> > >>>>> There are some "wrong" entries in the table already with that > >>>>> semantic since something like "DHCP" refers to an LCP rather than > the > >>>>> actual location determination method. > >>>> > >>>> This is not true either. If a target (as an LG) discovers its LI > from > >>>> DHCP (Option 99 or 123), then this is the > >>>> > >>>> dhcp > >>>> > >>>> James W. added some additional semantics to the additional values > >>>> without running them by the WG when he IANA registered them, so the > >>>> non-4119 defined values haven't been fully vetted. > >>>> > >>>> This is because 4119 doesn't require any review of any kind before > >>>> adding new IANA entries to this registry. > >>>> > >>>> > >>>> > >>>>> Now, I wonder whether it is possible to put more than one token into > >>>>> the method element. The data type is string and hence it would be > >>>>> possible. > >>>>> > >>>>> To pick your example, could you indicate gps > derived? > >>>>> > >>>>> Ciao > >>>>> Hannes > >>>>> > >>>>> PS: I wonder whether there is actually a way to deprecate certain > >>>>> tokens from the registry. Nothing is indicated in RFC 4119. "802.11" > >>>>> and "DHCP" "LLDP-MED" really does not belong in there. FCFS as a > >>>>> policy for assignment does not sound useful to me either; expert > >>>>> review would be more useful. > >>>> > >>>> Hennes - these 4119 values were the only ones that ever were "expert > >>>> reviewed", if you consider Geopriv a place where that can take place. > >>>> > >>>> BTW -- you were there for this expert review... perhaps you will > >>>> reconsider this stance once you re-evaluate how these entries are > 4119 > >>>> intended. > >>>> > >>>> > >>>> > >>>> > >>>>> Hannes Tschofenig wrote: > >>>>>> Thanks. > >>>>>> > >>>>>> Brian Rosen wrote: > >>>>>>> The "Derived" method is used when the PIDF creator has a location > >>>>>>> available > >>>>>>> in one form (civic or geo) using another method, and derives a > >>>>>>> location in > >>>>>>> the other form. So for example, the determination method might be > >>>>>>> GPS, > >>>>>>> which creates a geo and the PIDF includes a civic derived from > that > >>>>>>> geo. > >>>>>>> > >>>>>>> Brian > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>>>>> Sent: Saturday, July 12, 2008 5:04 AM > >>>>>>>> To: Brian Rosen > >>>>>>>> Cc: 'Karl Heinz Wolf'; 'ECRIT' > >>>>>>>> Subject: "Derived" method > >>>>>>>> > >>>>>>>> Could you describe the semantic of the "Derived" method a bit > more? > >>>>>>>> > >>>>>>>> Brian Rosen wrote: > >>>>>>>> > >>>>>>>>> I am sorry, I don't know how I missed these. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> page 7: "The phone gets location from the DHCP server in civic > >>>>>>>>>> [RFC4676] or geo" -> should it be "and/or"? > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> The text makes clear that multiple locations are problematic. > >>>>>>>>> Multiple > >>>>>>>>> versions of the same location are problematic. I worry about > >>>>>>>>> systems > >>>>>>>>> > >>>>>>>> trying > >>>>>>>> > >>>>>>>>> to be helpful and giving you a measured location and also giving > >>>>>>>>> you a > >>>>>>>>> derived (geo coded or reverse geo coded) version of the same > >>>>>>>>> location. > >>>>>>>>> > >>>>>>>>> This does raise yet another issue about this general subject; > >>>>>>>>> looking at > >>>>>>>>> > >>>>>>>> the > >>>>>>>> > >>>>>>>>> list at: > >>>>>>>>> http://www.iana.org/assignments/method-tokens > >>>>>>>>> There is no method for "derived". So: > >>>>>>>>> I will add text to -framework covering this subject > >>>>>>>>> I will ask IANA to create a "Derived" method token > >>>>>>>>> I will add a requirement to -phonebcp that says if you get both > >>>>>>>>> and one > >>>>>>>>> > >>>>>>>> is > >>>>>>>> > >>>>>>>>> derived, you must use the non-derived value. > >>>>>>>>> > >>>>>>>>> I've made the other changes in my source file and they will > >>>>>>>>> appear in > >>>>>>>>> > >>>>>>>> the > >>>>>>>> > >>>>>>>>> next version. > >>>>>>>>> > >>>>>>>>> Brian > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > >>>>>>>>>> Sent: Friday, July 11, 2008 6:00 AM > >>>>>>>>>> To: Brian Rosen > >>>>>>>>>> Cc: ECRIT > >>>>>>>>>> Subject: Re: [Ecrit] New versions of -framework and -phonebcp > >>>>>>>>>> > >>>>>>>>>> Brian, > >>>>>>>>>> > >>>>>>>>>> thank you for submitting the new versions of your documents. > >>>>>>>>>> However, I'm afraid you forgot my comments (except the LoSt > >>>>>>>>>> dialstring > >>>>>>>>>> "must"). > >>>>>>>>>> My old posting: > >>>>>>>>>> http://www.ietf.org/mail- > archive/web/ecrit/current/msg04936.html > >>>>>>>>>> In your reply to this mail you agreed to these points. > >>>>>>>>>> > >>>>>>>>>> Karl Heinz > >>>>>>>>>> > >>>>>>>>>> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen > > >>>>>>>>>> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>>>> These versions incorporate all last call comments except as I > >> have > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> stated in > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> prior email. > >>>>>>>>>>> > >>>>>>>>>>> The majority of changes have to do with: > >>>>>>>>>>> * More explicit text and references to -profile for multiple > >>>>>>>>>>> locations > >>>>>>>>>>> > >>>>>>>>>>> * Requiring the return of dialstrings on LoST for sos service > >>>>>>>>>>> URNs. > >>>>>>>>>>> > >>>>>>>>>>> * Lots of typos and wording changes. > >>>>>>>>>>> > >>>>>>>>>>> I did end up adding a couple of requirements, and thus needed > to > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> renumber > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> the requirements, so diffs look bad. > >>>>>>>>>>> > >>>>>>>>>>> I ask commenters to look at the text to make sure I made all > the > >>>>>>>>>>> > >>>>>>>> changes > >>>>>>>> > >>>>>>>>>> you > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> requested (with the exceptions covered in the emails). > >>>>>>>>>>> > >>>>>>>>>>> Chairs can consider if they wish to hold a short 2nd WGLC. > >>>>>>>>>>> There are > >>>>>>>>>>> > >>>>>>>> a > >>>>>>>> > >>>>>>>>>>> couple of substantive changes and added requirements, but not > a > >>>>>>>>>>> whole > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> lot > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> text is modified in any but trivial ways. > >>>>>>>>>>> > >>>>>>>>>>> Brian > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> Ecrit mailing 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 Mon Jul 14 11:40:08 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D2F53A6AB5; Mon, 14 Jul 2008 11:40: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 6056D3A6AB5 for ; Mon, 14 Jul 2008 11:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ec03wd70JtSE for ; Mon, 14 Jul 2008 11:40:05 -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 77DEE3A692F for ; Mon, 14 Jul 2008 11:40:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,360,1212364800"; d="scan'208";a="52755037" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 14 Jul 2008 18:40:31 +0000 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 m6EIeVks030981; Mon, 14 Jul 2008 11:40:31 -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 m6EIeVEp009569; Mon, 14 Jul 2008 18:40:31 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); Mon, 14 Jul 2008 11:40:31 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.84.1]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 11:40:31 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Jul 2008 13:40:34 -0500 To: Hannes Tschofenig , Marc Linsner From: "James M. Polk" In-Reply-To: <487B94DB.7060701@gmx.net> References: <487B94DB.7060701@gmx.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 14 Jul 2008 18:40:31.0262 (UTC) FILETIME=[17F873E0:01C8E5E1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10140; t=1216060831; x=1216924831; 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]=20=22Derived=22=20method |Sender:=20; bh=3jVXe6b80FnCqjyYIA1WXXCgCswSvqy8eDYqPVutYSA=; b=O4hqNMmLbvLiTIpeluXd8qtXnsFWrduehYzGuCtj8dNHRk+5d7aw7GYL82 +zb/r6WAoJESpSXdiQwjufy/5UFZkJbvEC22rnq6h6Sn/aY0AVJ3M4RIr32s 3A1pKAzvPg; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 01:03 PM 7/14/2008, Hannes Tschofenig wrote: >That's actually a good question: Is the element really so useful? yes but it needs have to say only a little bit of information to make it useful without getting so bloated it doesn't make sense anymore. Think about which direction this element is defined from. It's from the point of view of the Target/LG, not from the network. In other words, how did the endpoint learn about its location. Looking at the original IANA registered list for method in 4119 and you should be able to see this easily. As soon as we start to think about this from a point of view of the network, someone's gonna bring up "is this method reeeally a method I can trust or not?" I.e., can the method be validated? then all hell breaks loose with complexity, because that cannot be solved within a text string. It has to include a URI to the asserter of the method... do we really want to go down that path? >Ciao >Hannes > >Marc Linsner wrote: >>I'm not convinced any of this information is useful to a LR. >> >>Would the pizza be warmer when delivered if the delivery person had this >>information? >> >>What would the LR do if the location information is wrong and they knew it >>was derived by a ouija board vs. a wiremap database vs. triangulation? >> >>What if the wiremap database was populated using gps? >> >>-Marc- >> >> >>On 7/14/08 1:30 PM, "Hannes Tschofenig" wrote: >> >> >>>RFC 4119 isn't super exhaustive in the description of the semantic of >>>the element and what it is being used for. >>> >>>What could be more useful for the Location Recipient to know: >>> >>>* Location was obtained using DHCP, or LLDP-MED >>> >>>OR >>> >>>* Location was determined using manual configuration, wiremap database, >>>triangulation. >>> >>> >>>Ciao >>>Hannes >>> >>> >>> >>>James M. Polk wrote: >>> >>>>At 09:18 AM 7/12/2008, Hannes Tschofenig wrote: >>>> >>>>>The problem is a bit with the semantic of the method token given that >>>>>it was supposed to be used to indicate the location determination >>>>>method. >>>>> >>>>this is simply not true. Your definition is adding meaning that isn't >>>>there. >>>> >>>>The element is the indication, solely created by the endpoint >>>>(as an LG), of how it received (i.e., "discovered") location >>>>information (not LO, but LI). >>>> >>>>Case in point, if a target has a sighter that derives location based >>>>on triangulating the position of the target, yet delivers that LI via >>>>DHCP, the would NOT say >>>> >>>> triangulation >>>> >>>>it would say >>>> >>>> dhcp >>>> >>>>and be correct. >>>> >>>> >>>>>There are some "wrong" entries in the table already with that >>>>>semantic since something like "DHCP" refers to an LCP rather than the >>>>>actual location determination method. >>>>> >>>>This is not true either. If a target (as an LG) discovers its LI from >>>>DHCP (Option 99 or 123), then this is the >>>> >>>> dhcp >>>> >>>>James W. added some additional semantics to the additional values >>>>without running them by the WG when he IANA registered them, so the >>>>non-4119 defined values haven't been fully vetted. >>>> >>>>This is because 4119 doesn't require any review of any kind before >>>>adding new IANA entries to this registry. >>>> >>>> >>>> >>>> >>>>>Now, I wonder whether it is possible to put more than one token into >>>>>the method element. The data type is string and hence it would be >>>>>possible. >>>>> >>>>>To pick your example, could you indicate gps derived? >>>>> >>>>>Ciao >>>>>Hannes >>>>> >>>>>PS: I wonder whether there is actually a way to deprecate certain >>>>>tokens from the registry. Nothing is indicated in RFC 4119. "802.11" >>>>>and "DHCP" "LLDP-MED" really does not belong in there. FCFS as a >>>>>policy for assignment does not sound useful to me either; expert >>>>>review would be more useful. >>>>> >>>>Hennes - these 4119 values were the only ones that ever were "expert >>>>reviewed", if you consider Geopriv a place where that can take place. >>>> >>>>BTW -- you were there for this expert review... perhaps you will >>>>reconsider this stance once you re-evaluate how these entries are 4119 >>>>intended. >>>> >>>> >>>> >>>> >>>> >>>>>Hannes Tschofenig wrote: >>>>> >>>>>>Thanks. >>>>>> >>>>>>Brian Rosen wrote: >>>>>> >>>>>>>The "Derived" method is used when the PIDF creator has a location >>>>>>>available >>>>>>>in one form (civic or geo) using another method, and derives a >>>>>>>location in >>>>>>>the other form. So for example, the determination method might be >>>>>>>GPS, >>>>>>>which creates a geo and the PIDF includes a civic derived from that >>>>>>>geo. >>>>>>> >>>>>>>Brian >>>>>>> >>>>>>> >>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>Sent: Saturday, July 12, 2008 5:04 AM >>>>>>>>To: Brian Rosen >>>>>>>>Cc: 'Karl Heinz Wolf'; 'ECRIT' >>>>>>>>Subject: "Derived" method >>>>>>>> >>>>>>>>Could you describe the semantic of the "Derived" method a bit more? >>>>>>>> >>>>>>>>Brian Rosen wrote: >>>>>>>> >>>>>>>> >>>>>>>>>I am sorry, I don't know how I missed these. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>page 7: "The phone gets location from the DHCP server in civic >>>>>>>>>>[RFC4676] or geo" -> should it be "and/or"? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>The text makes clear that multiple locations are problematic. >>>>>>>>>Multiple >>>>>>>>>versions of the same location are problematic. I worry about >>>>>>>>>systems >>>>>>>>> >>>>>>>>> >>>>>>>>trying >>>>>>>> >>>>>>>> >>>>>>>>>to be helpful and giving you a measured location and also giving >>>>>>>>>you a >>>>>>>>>derived (geo coded or reverse geo coded) version of the same >>>>>>>>>location. >>>>>>>>> >>>>>>>>>This does raise yet another issue about this general subject; >>>>>>>>>looking at >>>>>>>>> >>>>>>>>> >>>>>>>>the >>>>>>>> >>>>>>>> >>>>>>>>>list at: >>>>>>>>>http://www.iana.org/assignments/method-tokens >>>>>>>>>There is no method for "derived". So: >>>>>>>>>I will add text to -framework covering this subject >>>>>>>>>I will ask IANA to create a "Derived" method token >>>>>>>>>I will add a requirement to -phonebcp that says if you get both >>>>>>>>>and one >>>>>>>>> >>>>>>>>> >>>>>>>>is >>>>>>>> >>>>>>>> >>>>>>>>>derived, you must use the non-derived value. >>>>>>>>> >>>>>>>>>I've made the other changes in my source file and they will >>>>>>>>>appear in >>>>>>>>> >>>>>>>>> >>>>>>>>the >>>>>>>> >>>>>>>> >>>>>>>>>next version. >>>>>>>>> >>>>>>>>>Brian >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>-----Original Message----- >>>>>>>>>>From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >>>>>>>>>>Sent: Friday, July 11, 2008 6:00 AM >>>>>>>>>>To: Brian Rosen >>>>>>>>>>Cc: ECRIT >>>>>>>>>>Subject: Re: [Ecrit] New versions of -framework and -phonebcp >>>>>>>>>> >>>>>>>>>>Brian, >>>>>>>>>> >>>>>>>>>>thank you for submitting the new versions of your documents. >>>>>>>>>>However, I'm afraid you forgot my comments (except the LoSt >>>>>>>>>>dialstring >>>>>>>>>>"must"). >>>>>>>>>>My old posting: >>>>>>>>>>http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html >>>>>>>>>>In your reply to this mail you agreed to these points. >>>>>>>>>> >>>>>>>>>>Karl Heinz >>>>>>>>>> >>>>>>>>>>On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen >>>>>>>>>> >>>>>>>>>> >>>>>>>>wrote: >>>>>>>> >>>>>>>> >>>>>>>>>>>These versions incorporate all last call comments except as I have >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>stated in >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>prior email. >>>>>>>>>>> >>>>>>>>>>>The majority of changes have to do with: >>>>>>>>>>>* More explicit text and references to -profile for multiple >>>>>>>>>>>locations >>>>>>>>>>> >>>>>>>>>>>* Requiring the return of dialstrings on LoST for sos service >>>>>>>>>>>URNs. >>>>>>>>>>> >>>>>>>>>>>* Lots of typos and wording changes. >>>>>>>>>>> >>>>>>>>>>>I did end up adding a couple of requirements, and thus needed to >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>renumber >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>the requirements, so diffs look bad. >>>>>>>>>>> >>>>>>>>>>>I ask commenters to look at the text to make sure I made all the >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>changes >>>>>>>> >>>>>>>> >>>>>>>>>>you >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>requested (with the exceptions covered in the emails). >>>>>>>>>>> >>>>>>>>>>>Chairs can consider if they wish to hold a short 2nd WGLC. >>>>>>>>>>>There are >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>a >>>>>>>> >>>>>>>> >>>>>>>>>>>couple of substantive changes and added requirements, but not a >>>>>>>>>>>whole >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>lot >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>text is modified in any but trivial ways. >>>>>>>>>>> >>>>>>>>>>>Brian >>>>>>>>>>> >>>>>>>>>>>_______________________________________________ >>>>>>>>>>>Ecrit mailing 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 Mon Jul 14 11:43:02 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5F143A6B00; Mon, 14 Jul 2008 11:43: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 5ABC53A6AD5; Mon, 14 Jul 2008 11:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIGZrNGzOkHr; Mon, 14 Jul 2008 11:43:01 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D715028C0ED; Mon, 14 Jul 2008 11:42:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,360,1212364800"; d="scan'208";a="36973183" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 14 Jul 2008 18:43:17 +0000 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 m6EIhHK4020739; Mon, 14 Jul 2008 11:43:17 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6EIhHAw011940; Mon, 14 Jul 2008 18:43:17 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, 14 Jul 2008 11:43:17 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.84.1]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 11:43:16 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Jul 2008 13:43:19 -0500 To: Richard Barnes , Marc Linsner From: "James M. Polk" In-Reply-To: <487B9ADA.8020708@bbn.com> References: <487B9ADA.8020708@bbn.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 14 Jul 2008 18:43:16.0582 (UTC) FILETIME=[7A824860:01C8E5E1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10875; t=1216060997; x=1216924997; 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]=20=22Derived=22=20method |Sender:=20; bh=h2nGMEmTQEBVaReE3lOXY6DiUECjdgEjB3DLCQpMbRs=; b=SJkti+0HTvZBNV2BgFhcWt43Jh2WPZ2sZrPM70Ub/an9wJDN0zK97/werm v6cmD0MMl6eiuty0qPkHUnn/40ts2YZP85T0llFKwpGqHFN5uFor2fr1SlH9 FVBpihK+43m9xdB/WAaCzUtiWTS6eRPrj7nKbhvUvKtNZk85G7DVw=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'GEOPRIV' , 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 01:28 PM 7/14/2008, Richard Barnes wrote: >I don't have any suggestions for pizza warming, other than that it >seems to be inversely related to CO2 emissions -- the more the >delivery driver drives, the cooler my pizza gets. not if the drive has the pizza warmer tied to the engine d`oh! seriously, what pizza driver isn't environmentally friendly and drives an electric car? there should be a law saying this ;-) > (Perhaps if we all order enough pizza, this could offset global warming?) > >However, I would like to suggest that this conversation move over to >the GEOPRIV list. > >--Richard > > > >Marc Linsner wrote: >>Brian, >> >>>You can reasonably infer things based on it. >>This will make the pizza warmer how? >>-Marc- >> >>>For example, wiremap data would never change. GPS data might. If you >>>measured wiremap data with gps, it would not likely change. No guarantees. >>> >>> >>>Another example would be "cell". If you ask for an update later, in some >>>countries, you likely will get a better location (using a different method). >>> >>>Brian >>> >>> >>>>-----Original Message----- >>>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >>>>Marc Linsner >>>>Sent: Monday, July 14, 2008 1:55 PM >>>>To: Hannes Tschofenig; James Polk >>>>Cc: 'ECRIT' >>>>Subject: Re: [Ecrit] "Derived" method >>>> >>>>I'm not convinced any of this information is useful to a LR. >>>> >>>>Would the pizza be warmer when delivered if the delivery person had this >>>>information? >>>> >>>>What would the LR do if the location information is wrong and they knew it >>>>was derived by a ouija board vs. a wiremap database vs. triangulation? >>>> >>>>What if the wiremap database was populated using gps? >>>> >>>>-Marc- >>>> >>>> >>>>On 7/14/08 1:30 PM, "Hannes Tschofenig" wrote: >>>> >>>>>RFC 4119 isn't super exhaustive in the description of the semantic of >>>>>the element and what it is being used for. >>>>> >>>>>What could be more useful for the Location Recipient to know: >>>>> >>>>>* Location was obtained using DHCP, or LLDP-MED >>>>> >>>>>OR >>>>> >>>>>* Location was determined using manual configuration, wiremap database, >>>>>triangulation. >>>>> >>>>> >>>>>Ciao >>>>>Hannes >>>>> >>>>> >>>>> >>>>>James M. Polk wrote: >>>>>>At 09:18 AM 7/12/2008, Hannes Tschofenig wrote: >>>>>>>The problem is a bit with the semantic of the method token given that >>>>>>>it was supposed to be used to indicate the location determination >>>>>>>method. >>>>>>this is simply not true. Your definition is adding meaning that isn't >>>>>>there. >>>>>> >>>>>>The element is the indication, solely created by the endpoint >>>>>>(as an LG), of how it received (i.e., "discovered") location >>>>>>information (not LO, but LI). >>>>>> >>>>>>Case in point, if a target has a sighter that derives location based >>>>>>on triangulating the position of the target, yet delivers that LI via >>>>>>DHCP, the would NOT say >>>>>> >>>>>> triangulation >>>>>> >>>>>>it would say >>>>>> >>>>>> dhcp >>>>>> >>>>>>and be correct. >>>>>> >>>>>>>There are some "wrong" entries in the table already with that >>>>>>>semantic since something like "DHCP" refers to an LCP rather than the >>>>>>>actual location determination method. >>>>>>This is not true either. If a target (as an LG) discovers its LI from >>>>>>DHCP (Option 99 or 123), then this is the >>>>>> >>>>>> dhcp >>>>>> >>>>>>James W. added some additional semantics to the additional values >>>>>>without running them by the WG when he IANA registered them, so the >>>>>>non-4119 defined values haven't been fully vetted. >>>>>> >>>>>>This is because 4119 doesn't require any review of any kind before >>>>>>adding new IANA entries to this registry. >>>>>> >>>>>> >>>>>> >>>>>>>Now, I wonder whether it is possible to put more than one token into >>>>>>>the method element. The data type is string and hence it would be >>>>>>>possible. >>>>>>> >>>>>>>To pick your example, could you indicate gps derived? >>>>>>> >>>>>>>Ciao >>>>>>>Hannes >>>>>>> >>>>>>>PS: I wonder whether there is actually a way to deprecate certain >>>>>>>tokens from the registry. Nothing is indicated in RFC 4119. "802.11" >>>>>>>and "DHCP" "LLDP-MED" really does not belong in there. FCFS as a >>>>>>>policy for assignment does not sound useful to me either; expert >>>>>>>review would be more useful. >>>>>>Hennes - these 4119 values were the only ones that ever were "expert >>>>>>reviewed", if you consider Geopriv a place where that can take place. >>>>>> >>>>>>BTW -- you were there for this expert review... perhaps you will >>>>>>reconsider this stance once you re-evaluate how these entries are 4119 >>>>>>intended. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Hannes Tschofenig wrote: >>>>>>>>Thanks. >>>>>>>> >>>>>>>>Brian Rosen wrote: >>>>>>>>>The "Derived" method is used when the PIDF creator has a location >>>>>>>>>available >>>>>>>>>in one form (civic or geo) using another method, and derives a >>>>>>>>>location in >>>>>>>>>the other form. So for example, the determination method might be >>>>>>>>>GPS, >>>>>>>>>which creates a geo and the PIDF includes a civic derived from that >>>>>>>>>geo. >>>>>>>>> >>>>>>>>>Brian >>>>>>>>> >>>>>>>>> >>>>>>>>>>-----Original Message----- >>>>>>>>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>>>Sent: Saturday, July 12, 2008 5:04 AM >>>>>>>>>>To: Brian Rosen >>>>>>>>>>Cc: 'Karl Heinz Wolf'; 'ECRIT' >>>>>>>>>>Subject: "Derived" method >>>>>>>>>> >>>>>>>>>>Could you describe the semantic of the "Derived" method a bit more? >>>>>>>>>> >>>>>>>>>>Brian Rosen wrote: >>>>>>>>>> >>>>>>>>>>>I am sorry, I don't know how I missed these. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>page 7: "The phone gets location from the DHCP server in civic >>>>>>>>>>>>[RFC4676] or geo" -> should it be "and/or"? >>>>>>>>>>>> >>>>>>>>>>>The text makes clear that multiple locations are problematic. >>>>>>>>>>>Multiple >>>>>>>>>>>versions of the same location are problematic. I worry about >>>>>>>>>>>systems >>>>>>>>>>trying >>>>>>>>>> >>>>>>>>>>>to be helpful and giving you a measured location and also giving >>>>>>>>>>>you a >>>>>>>>>>>derived (geo coded or reverse geo coded) version of the same >>>>>>>>>>>location. >>>>>>>>>>> >>>>>>>>>>>This does raise yet another issue about this general subject; >>>>>>>>>>>looking at >>>>>>>>>>the >>>>>>>>>> >>>>>>>>>>>list at: >>>>>>>>>>>http://www.iana.org/assignments/method-tokens >>>>>>>>>>>There is no method for "derived". So: >>>>>>>>>>>I will add text to -framework covering this subject >>>>>>>>>>>I will ask IANA to create a "Derived" method token >>>>>>>>>>>I will add a requirement to -phonebcp that says if you get both >>>>>>>>>>>and one >>>>>>>>>>is >>>>>>>>>> >>>>>>>>>>>derived, you must use the non-derived value. >>>>>>>>>>> >>>>>>>>>>>I've made the other changes in my source file and they will >>>>>>>>>>>appear in >>>>>>>>>>the >>>>>>>>>> >>>>>>>>>>>next version. >>>>>>>>>>> >>>>>>>>>>>Brian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>-----Original Message----- >>>>>>>>>>>>From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >>>>>>>>>>>>Sent: Friday, July 11, 2008 6:00 AM >>>>>>>>>>>>To: Brian Rosen >>>>>>>>>>>>Cc: ECRIT >>>>>>>>>>>>Subject: Re: [Ecrit] New versions of -framework and -phonebcp >>>>>>>>>>>> >>>>>>>>>>>>Brian, >>>>>>>>>>>> >>>>>>>>>>>>thank you for submitting the new versions of your documents. >>>>>>>>>>>>However, I'm afraid you forgot my comments (except the LoSt >>>>>>>>>>>>dialstring >>>>>>>>>>>>"must"). >>>>>>>>>>>>My old posting: >>>>>>>>>>>>http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html >>>>>>>>>>>>In your reply to this mail you agreed to these points. >>>>>>>>>>>> >>>>>>>>>>>>Karl Heinz >>>>>>>>>>>> >>>>>>>>>>>>On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen >>>>>>>>>>wrote: >>>>>>>>>> >>>>>>>>>>>>>These versions incorporate all last call comments except as I >>>>have >>>>>>>>>>>>stated in >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>prior email. >>>>>>>>>>>>> >>>>>>>>>>>>>The majority of changes have to do with: >>>>>>>>>>>>>* More explicit text and references to -profile for multiple >>>>>>>>>>>>>locations >>>>>>>>>>>>> >>>>>>>>>>>>>* Requiring the return of dialstrings on LoST for sos service >>>>>>>>>>>>>URNs. >>>>>>>>>>>>> >>>>>>>>>>>>>* Lots of typos and wording changes. >>>>>>>>>>>>> >>>>>>>>>>>>>I did end up adding a couple of requirements, and thus needed to >>>>>>>>>>>>> >>>>>>>>>>>>renumber >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>the requirements, so diffs look bad. >>>>>>>>>>>>> >>>>>>>>>>>>>I ask commenters to look at the text to make sure I made all the >>>>>>>>>>changes >>>>>>>>>> >>>>>>>>>>>>you >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>requested (with the exceptions covered in the emails). >>>>>>>>>>>>> >>>>>>>>>>>>>Chairs can consider if they wish to hold a short 2nd WGLC. >>>>>>>>>>>>>There are >>>>>>>>>>a >>>>>>>>>> >>>>>>>>>>>>>couple of substantive changes and added requirements, but not a >>>>>>>>>>>>>whole >>>>>>>>>>>>> >>>>>>>>>>>>lot >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>text is modified in any but trivial ways. >>>>>>>>>>>>> >>>>>>>>>>>>>Brian >>>>>>>>>>>>> >>>>>>>>>>>>>_______________________________________________ >>>>>>>>>>>>>Ecrit mailing 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 14 14:16:57 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3D7528C2A7; Mon, 14 Jul 2008 14:16:57 -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 1152128C0E1 for ; Mon, 14 Jul 2008 14:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.724 X-Spam-Level: X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 90fMy-TabMKM for ; Mon, 14 Jul 2008 14:16:56 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id AD35628C41B for ; Mon, 14 Jul 2008 14:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1216070212; x=1247606212; h=mime-version:message-id:date:to:from:subject: content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|Date:=20Mon,=2014=20Jul=202008=2014:16:4 9=20-0700|To:=20,=20,=0D=0A=20=20=20=20=20=20=20=20"hannes.tschofenig@nsn. com"=0D=0A=09|From:=20Ted=20Ha rdie=20|Subject:=20Request=20for=20a genda=20time=20to=20discuss=20emergency=20call=20terminat ion|Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5338"=3B=20 a=3D"4701803"; bh=2zXxsUQm/r23Pu3AqK6rtwizJxGAXR3GQArY0bTKyok=; b=MmryH3QljiZKNOacDc9OjNsNTsBwmP1rwIj0AABPg8A7GJjjlSbYjQZk gwO5UxbjZS6QPq7r8QNuUW8IHTl5vLyUNXbY0HCFfFjxnnSspeC7N/5Sz 4rQFkBa3xV2mfyo5y8uVK7xRD5dQW9m5pvYB3XvNmXVqCpMifzC9LkKmc A=; X-IronPort-AV: E=McAfee;i="5200,2160,5338"; a="4701803" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jul 2008 14:16:52 -0700 Received: from msgtransport06.qualcomm.com (msgtransport06.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6ELGpR2003666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Jul 2008 14:16:51 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport06.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6ELGpF7019314 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 Jul 2008 14:16:51 -0700 Received: from [76.126.61.44] (129.46.226.27) by qcmail1.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 14 Jul 2008 14:16:50 -0700 MIME-Version: 1.0 Message-ID: Date: Mon, 14 Jul 2008 14:16:49 -0700 To: , , "hannes.tschofenig@nsn.com" From: Ted Hardie Subject: [Ecrit] Request for agenda time to discuss emergency call termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Howdy, I re-read the thread that discussed this with our colleagues at NENA, and I believe that the group would benefit from some in-person discussion of the issues. Could we have a 10-15 minute discussion on the agenda? Failing that, can we arrange a bar BoF on this? thanks, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 14 14:54:54 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C92428C147; Mon, 14 Jul 2008 14: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 826ED3A6B95 for ; Mon, 14 Jul 2008 14:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[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 ilx6woqhBq6S for ; Mon, 14 Jul 2008 14:54:51 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id AAC513A6B61 for ; Mon, 14 Jul 2008 14:54:51 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_07_14_17_10_28 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, 14 Jul 2008 17:10:27 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 16:54:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 16:53:39 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] "Derived" method Thread-Index: Acjl195HgGp45MiqQMSngQHsZ2z/KgAAmo2QAAhyprQ= References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com><023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com><48787395.1040507@gmx.net><053301c8e4fb$ac68e960$640fa8c0@cis.neustar.com> <093b01c8e5da$82b461f0$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "James M. Polk" , "Hannes Tschofenig" X-OriginalArrivalTime: 14 Jul 2008 21:54:19.0474 (UTC) FILETIME=[2AECCB20:01C8E5FC] Cc: ECRIT Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 already says this. If you have two different methods, they must reside in the separate elements. -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Brian Rosen Sent: Mon 7/14/2008 12:53 PM To: 'James M. Polk'; 'Hannes Tschofenig' Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method I would say this is an error. I think we need to determine what "method" should mean (prior email) first, but then we should fix this so that each location info section has its own method. Brian > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Monday, July 14, 2008 1:33 PM > To: Brian Rosen; 'Hannes Tschofenig' > Cc: 'ECRIT' > Subject: Re: [Ecrit] "Derived" method > > At 10:18 AM 7/13/2008, Brian Rosen wrote: > >I think we can get quite carried away with all the possibilities, and > there > >is no reason to be carried away. > > > >The possibilities are: > >1. There is exactly one location, and it's marked "Derived". There is no > >need for more information. > > I agree with this > > >2. There are exactly two locations, and one is marked "Derived". This > means > >the other is the original > > I do not agree with this. > > Here's how I got there > > The element is a sub-element of what element? > > Is it ? > > no -- it's parallel to it > > therefore the element has to be THE way the whole LO was > discovered, regardless of how many formats (civic, geo, > whatever's_coming_next) are in the LO. > > IF there are two locations, and they were discovered using different > methods, that's TWO PIDF-LOs; else there's confusion. > > >3. There are more than two locations and one or more is marked "Derived". > I > >think we can ignore this case, or at least say that there is no way to > >understand what is derived from what. > > > >Brian > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Saturday, July 12, 2008 10:37 PM > > > To: Hannes Tschofenig; Brian Rosen > > > Cc: ECRIT > > > Subject: RE: [Ecrit] "Derived" method > > > > > > Hi Brian, > > > > > > For derived to really have a clear meaning it needs to be totally > > > unambiguous what the location is derived from. > > > The example I always hear is a civic address derived from a geodetic > > > shape, or vice versa. In this case, you need to provide both locations > in > > > the PIDF-LO document, and somehow, there needs to be a link between > them. > > > Simply havinf both locations in the same document isn't sufficient, I > > > think you need the equivalent of an tag, or something like > that. > > > > > > Cheers > > > James > > > > > > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > > > Sent: Sat 7/12/2008 4:04 AM > > > To: Brian Rosen > > > Cc: 'ECRIT' > > > Subject: [Ecrit] "Derived" method > > > > > > Could you describe the semantic of the "Derived" method a bit more? > > > > > > Brian Rosen wrote: > > > > I am sorry, I don't know how I missed these. > > > > > > > > > > > >> page 7: "The phone gets location from the DHCP server in civic > > > >> [RFC4676] or geo" -> should it be "and/or"? > > > >> > > > > The text makes clear that multiple locations are problematic. > Multiple > > > > versions of the same location are problematic. I worry about > systems > > > trying > > > > to be helpful and giving you a measured location and also giving you > a > > > > derived (geo coded or reverse geo coded) version of the same > location. > > > > > > > > This does raise yet another issue about this general subject; > looking at > > > the > > > > list at: > > > > http://www.iana.org/assignments/method-tokens > > > > There is no method for "derived". So: > > > > I will add text to -framework covering this subject > > > > I will ask IANA to create a "Derived" method token > > > > I will add a requirement to -phonebcp that says if you get both and > one > > > is > > > > derived, you must use the non-derived value. > > > > > > > > I've made the other changes in my source file and they will appear > in > > > the > > > > next version. > > > > > > > > Brian > > > > > > > >> -----Original Message----- > > > >> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > > >> Sent: Friday, July 11, 2008 6:00 AM > > > >> To: Brian Rosen > > > >> Cc: ECRIT > > > >> Subject: Re: [Ecrit] New versions of -framework and -phonebcp > > > >> > > > >> Brian, > > > >> > > > >> thank you for submitting the new versions of your documents. > > > >> However, I'm afraid you forgot my comments (except the LoSt > dialstring > > > >> "must"). > > > >> My old posting: > > > >> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html > > > >> In your reply to this mail you agreed to these points. > > > >> > > > >> Karl Heinz > > > >> > > > >> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen > > > wrote: > > > >> > > > >>> These versions incorporate all last call comments except as I have > > > >>> > > > >> stated in > > > >> > > > >>> prior email. > > > >>> > > > >>> The majority of changes have to do with: > > > >>> * More explicit text and references to -profile for multiple > locations > > > >>> > > > >>> * Requiring the return of dialstrings on LoST for sos service > URNs. > > > >>> > > > >>> * Lots of typos and wording changes. > > > >>> > > > >>> I did end up adding a couple of requirements, and thus needed to > > > >>> > > > >> renumber > > > >> > > > >>> the requirements, so diffs look bad. > > > >>> > > > >>> I ask commenters to look at the text to make sure I made all the > > > changes > > > >>> > > > >> you > > > >> > > > >>> requested (with the exceptions covered in the emails). > > > >>> > > > >>> Chairs can consider if they wish to hold a short 2nd WGLC. There > are > > > a > > > >>> couple of substantive changes and added requirements, but not a > whole > > > >>> > > > >> lot > > > >> > > > >>> text is modified in any but trivial ways. > > > >>> > > > >>> Brian > > > >>> > > > >>> _______________________________________________ > > > >>> Ecrit mailing 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 Jul 14 15:00:45 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B71828C36A; Mon, 14 Jul 2008 15:00: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 1F3C328C36A for ; Mon, 14 Jul 2008 15:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[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 NdwktlyVgPMf for ; Mon, 14 Jul 2008 15:00:41 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 8648228C317 for ; Mon, 14 Jul 2008 15:00:41 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_07_14_17_16_18 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, 14 Jul 2008 17:16:16 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 17:01:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 16:58:37 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] "Derived" method Thread-Index: Acjl2rJ550Y6QF3avE2es8xxCUxJhAAAKd1AAAhaqyg= References: <487B8D31.4000402@gmx.net> <094e01c8e5db$f985c070$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Marc Linsner" , "Hannes Tschofenig" , "James Polk" X-OriginalArrivalTime: 14 Jul 2008 22:01:06.0190 (UTC) FILETIME=[1D58BAE0:01C8E5FD] Cc: ECRIT Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Brian it that its sole benefit is really an indicator to location recipients that it MAY be possible to get a better location. I say may, because in many cases A-GPS is not going to be as good as a cell-based location from a femto or pico-cell. Still I think it has some benefit, but as Marc says, probably not for the pizza delivery guy. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Brian Rosen Sent: Mon 7/14/2008 1:03 PM To: 'Marc Linsner'; 'Hannes Tschofenig'; 'James Polk' Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method You can reasonably infer things based on it. For example, wiremap data would never change. GPS data might. If you measured wiremap data with gps, it would not likely change. No guarantees. Another example would be "cell". If you ask for an update later, in some countries, you likely will get a better location (using a different method). Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Marc Linsner > Sent: Monday, July 14, 2008 1:55 PM > To: Hannes Tschofenig; James Polk > Cc: 'ECRIT' > Subject: Re: [Ecrit] "Derived" method > > I'm not convinced any of this information is useful to a LR. > > Would the pizza be warmer when delivered if the delivery person had this > information? > > What would the LR do if the location information is wrong and they knew it > was derived by a ouija board vs. a wiremap database vs. triangulation? > > What if the wiremap database was populated using gps? > > -Marc- > > > On 7/14/08 1:30 PM, "Hannes Tschofenig" wrote: > > > RFC 4119 isn't super exhaustive in the description of the semantic of > > the element and what it is being used for. > > > > What could be more useful for the Location Recipient to know: > > > > * Location was obtained using DHCP, or LLDP-MED > > > > OR > > > > * Location was determined using manual configuration, wiremap database, > > triangulation. > > > > > > Ciao > > Hannes > > > > > > > > James M. Polk wrote: > >> At 09:18 AM 7/12/2008, Hannes Tschofenig wrote: > >>> The problem is a bit with the semantic of the method token given that > >>> it was supposed to be used to indicate the location determination > >>> method. > >> > >> this is simply not true. Your definition is adding meaning that isn't > >> there. > >> > >> The element is the indication, solely created by the endpoint > >> (as an LG), of how it received (i.e., "discovered") location > >> information (not LO, but LI). > >> > >> Case in point, if a target has a sighter that derives location based > >> on triangulating the position of the target, yet delivers that LI via > >> DHCP, the would NOT say > >> > >> triangulation > >> > >> it would say > >> > >> dhcp > >> > >> and be correct. > >> > >>> There are some "wrong" entries in the table already with that > >>> semantic since something like "DHCP" refers to an LCP rather than the > >>> actual location determination method. > >> > >> This is not true either. If a target (as an LG) discovers its LI from > >> DHCP (Option 99 or 123), then this is the > >> > >> dhcp > >> > >> James W. added some additional semantics to the additional values > >> without running them by the WG when he IANA registered them, so the > >> non-4119 defined values haven't been fully vetted. > >> > >> This is because 4119 doesn't require any review of any kind before > >> adding new IANA entries to this registry. > >> > >> > >> > >>> Now, I wonder whether it is possible to put more than one token into > >>> the method element. The data type is string and hence it would be > >>> possible. > >>> > >>> To pick your example, could you indicate gps derived? > >>> > >>> Ciao > >>> Hannes > >>> > >>> PS: I wonder whether there is actually a way to deprecate certain > >>> tokens from the registry. Nothing is indicated in RFC 4119. "802.11" > >>> and "DHCP" "LLDP-MED" really does not belong in there. FCFS as a > >>> policy for assignment does not sound useful to me either; expert > >>> review would be more useful. > >> > >> Hennes - these 4119 values were the only ones that ever were "expert > >> reviewed", if you consider Geopriv a place where that can take place. > >> > >> BTW -- you were there for this expert review... perhaps you will > >> reconsider this stance once you re-evaluate how these entries are 4119 > >> intended. > >> > >> > >> > >> > >>> Hannes Tschofenig wrote: > >>>> Thanks. > >>>> > >>>> Brian Rosen wrote: > >>>>> The "Derived" method is used when the PIDF creator has a location > >>>>> available > >>>>> in one form (civic or geo) using another method, and derives a > >>>>> location in > >>>>> the other form. So for example, the determination method might be > >>>>> GPS, > >>>>> which creates a geo and the PIDF includes a civic derived from that > >>>>> geo. > >>>>> > >>>>> Brian > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>>> Sent: Saturday, July 12, 2008 5:04 AM > >>>>>> To: Brian Rosen > >>>>>> Cc: 'Karl Heinz Wolf'; 'ECRIT' > >>>>>> Subject: "Derived" method > >>>>>> > >>>>>> Could you describe the semantic of the "Derived" method a bit more? > >>>>>> > >>>>>> Brian Rosen wrote: > >>>>>> > >>>>>>> I am sorry, I don't know how I missed these. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> page 7: "The phone gets location from the DHCP server in civic > >>>>>>>> [RFC4676] or geo" -> should it be "and/or"? > >>>>>>>> > >>>>>>>> > >>>>>>> The text makes clear that multiple locations are problematic. > >>>>>>> Multiple > >>>>>>> versions of the same location are problematic. I worry about > >>>>>>> systems > >>>>>>> > >>>>>> trying > >>>>>> > >>>>>>> to be helpful and giving you a measured location and also giving > >>>>>>> you a > >>>>>>> derived (geo coded or reverse geo coded) version of the same > >>>>>>> location. > >>>>>>> > >>>>>>> This does raise yet another issue about this general subject; > >>>>>>> looking at > >>>>>>> > >>>>>> the > >>>>>> > >>>>>>> list at: > >>>>>>> http://www.iana.org/assignments/method-tokens > >>>>>>> There is no method for "derived". So: > >>>>>>> I will add text to -framework covering this subject > >>>>>>> I will ask IANA to create a "Derived" method token > >>>>>>> I will add a requirement to -phonebcp that says if you get both > >>>>>>> and one > >>>>>>> > >>>>>> is > >>>>>> > >>>>>>> derived, you must use the non-derived value. > >>>>>>> > >>>>>>> I've made the other changes in my source file and they will > >>>>>>> appear in > >>>>>>> > >>>>>> the > >>>>>> > >>>>>>> next version. > >>>>>>> > >>>>>>> Brian > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > >>>>>>>> Sent: Friday, July 11, 2008 6:00 AM > >>>>>>>> To: Brian Rosen > >>>>>>>> Cc: ECRIT > >>>>>>>> Subject: Re: [Ecrit] New versions of -framework and -phonebcp > >>>>>>>> > >>>>>>>> Brian, > >>>>>>>> > >>>>>>>> thank you for submitting the new versions of your documents. > >>>>>>>> However, I'm afraid you forgot my comments (except the LoSt > >>>>>>>> dialstring > >>>>>>>> "must"). > >>>>>>>> My old posting: > >>>>>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html > >>>>>>>> In your reply to this mail you agreed to these points. > >>>>>>>> > >>>>>>>> Karl Heinz > >>>>>>>> > >>>>>>>> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen > >>>>>>>> > >>>>>> wrote: > >>>>>> > >>>>>>>>> These versions incorporate all last call comments except as I > have > >>>>>>>>> > >>>>>>>>> > >>>>>>>> stated in > >>>>>>>> > >>>>>>>> > >>>>>>>>> prior email. > >>>>>>>>> > >>>>>>>>> The majority of changes have to do with: > >>>>>>>>> * More explicit text and references to -profile for multiple > >>>>>>>>> locations > >>>>>>>>> > >>>>>>>>> * Requiring the return of dialstrings on LoST for sos service > >>>>>>>>> URNs. > >>>>>>>>> > >>>>>>>>> * Lots of typos and wording changes. > >>>>>>>>> > >>>>>>>>> I did end up adding a couple of requirements, and thus needed to > >>>>>>>>> > >>>>>>>>> > >>>>>>>> renumber > >>>>>>>> > >>>>>>>> > >>>>>>>>> the requirements, so diffs look bad. > >>>>>>>>> > >>>>>>>>> I ask commenters to look at the text to make sure I made all the > >>>>>>>>> > >>>>>> changes > >>>>>> > >>>>>>>> you > >>>>>>>> > >>>>>>>> > >>>>>>>>> requested (with the exceptions covered in the emails). > >>>>>>>>> > >>>>>>>>> Chairs can consider if they wish to hold a short 2nd WGLC. > >>>>>>>>> There are > >>>>>>>>> > >>>>>> a > >>>>>> > >>>>>>>>> couple of substantive changes and added requirements, but not a > >>>>>>>>> whole > >>>>>>>>> > >>>>>>>>> > >>>>>>>> lot > >>>>>>>> > >>>>>>>> > >>>>>>>>> text is modified in any but trivial ways. > >>>>>>>>> > >>>>>>>>> Brian > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Ecrit mailing 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 ------------------------------------------------------------------------------------------------ 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 Jul 14 15:39:46 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 360513A6A7D; Mon, 14 Jul 2008 15:39: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 422D53A6A7D for ; Mon, 14 Jul 2008 15:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 Ae1RUV-xr5kH for ; Mon, 14 Jul 2008 15:39:42 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 9E2E03A68C7 for ; Mon, 14 Jul 2008 15:39:42 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KIWi7-0003Zb-2I; Mon, 14 Jul 2008 17:39:59 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'James M. Polk'" , "'Hannes Tschofenig'" References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com><023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com><48787395.1040507@gmx.net><053301c8e4fb$ac68e960$640fa8c0@cis.neustar.com> <093b01c8e5da$82b461f0$640fa8c0@cis.neustar.com> Date: Mon, 14 Jul 2008 18:40:04 -0400 Message-ID: <0c5b01c8e602$91120720$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acjl195HgGp45MiqQMSngQHsZ2z/KgAAmo2QAAhyprQAAUc/YA== 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: Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 had to go back and look at the structures again. I'm not enough of an XML expert here, but I gather that because we extended PIDF to include the geopriv element, and the extension is in a sequence, a single PIDF can have multiple geopriv elements, each of which has a location-info, method, usage-rules and provided-by elements. Multiple methods = multiple geopriv elements, but within one PIDF. So, we're back to seeing if we can agree on what method means. I think we should say it always means how location was determined, and not how it was configured. I think we should say if you send method=Derived, then you SHOULD send another geopriv element with method=something else, but in any case, you mark method=derived on the derived geopriv element. If you have more than two geopriv elements and one or more has method=derived, then relationships between determination methods and derivations cannot be determined. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Monday, July 14, 2008 5:54 PM > To: Brian Rosen; James M. Polk; Hannes Tschofenig > Cc: ECRIT > Subject: RE: [Ecrit] "Derived" method > > > PIDF-LO profile already says this. If you have two different methods, they > must reside in the separate elements. > > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of Brian Rosen > Sent: Mon 7/14/2008 12:53 PM > To: 'James M. Polk'; 'Hannes Tschofenig' > Cc: 'ECRIT' > Subject: Re: [Ecrit] "Derived" method > > I would say this is an error. > > I think we need to determine what "method" should mean (prior email) > first, > but then we should fix this so that each location info section has its own > method. > > Brian > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Monday, July 14, 2008 1:33 PM > > To: Brian Rosen; 'Hannes Tschofenig' > > Cc: 'ECRIT' > > Subject: Re: [Ecrit] "Derived" method > > > > At 10:18 AM 7/13/2008, Brian Rosen wrote: > > >I think we can get quite carried away with all the possibilities, and > > there > > >is no reason to be carried away. > > > > > >The possibilities are: > > >1. There is exactly one location, and it's marked "Derived". There is > no > > >need for more information. > > > > I agree with this > > > > >2. There are exactly two locations, and one is marked "Derived". This > > means > > >the other is the original > > > > I do not agree with this. > > > > Here's how I got there > > > > The element is a sub-element of what element? > > > > Is it ? > > > > no -- it's parallel to it > > > > therefore the element has to be THE way the whole LO was > > discovered, regardless of how many formats (civic, geo, > > whatever's_coming_next) are in the LO. > > > > IF there are two locations, and they were discovered using different > > methods, that's TWO PIDF-LOs; else there's confusion. > > > > >3. There are more than two locations and one or more is marked > "Derived". > > I > > >think we can ignore this case, or at least say that there is no way to > > >understand what is derived from what. > > > > > >Brian > > > > > > > -----Original Message----- > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > Sent: Saturday, July 12, 2008 10:37 PM > > > > To: Hannes Tschofenig; Brian Rosen > > > > Cc: ECRIT > > > > Subject: RE: [Ecrit] "Derived" method > > > > > > > > Hi Brian, > > > > > > > > For derived to really have a clear meaning it needs to be totally > > > > unambiguous what the location is derived from. > > > > The example I always hear is a civic address derived from a geodetic > > > > shape, or vice versa. In this case, you need to provide both > locations > > in > > > > the PIDF-LO document, and somehow, there needs to be a link between > > them. > > > > Simply havinf both locations in the same document isn't sufficient, > I > > > > think you need the equivalent of an tag, or something like > > that. > > > > > > > > Cheers > > > > James > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > > > > Sent: Sat 7/12/2008 4:04 AM > > > > To: Brian Rosen > > > > Cc: 'ECRIT' > > > > Subject: [Ecrit] "Derived" method > > > > > > > > Could you describe the semantic of the "Derived" method a bit more? > > > > > > > > Brian Rosen wrote: > > > > > I am sorry, I don't know how I missed these. > > > > > > > > > > > > > > >> page 7: "The phone gets location from the DHCP server in civic > > > > >> [RFC4676] or geo" -> should it be "and/or"? > > > > >> > > > > > The text makes clear that multiple locations are problematic. > > Multiple > > > > > versions of the same location are problematic. I worry about > > systems > > > > trying > > > > > to be helpful and giving you a measured location and also giving > you > > a > > > > > derived (geo coded or reverse geo coded) version of the same > > location. > > > > > > > > > > This does raise yet another issue about this general subject; > > looking at > > > > the > > > > > list at: > > > > > http://www.iana.org/assignments/method-tokens > > > > > There is no method for "derived". So: > > > > > I will add text to -framework covering this subject > > > > > I will ask IANA to create a "Derived" method token > > > > > I will add a requirement to -phonebcp that says if you get both > and > > one > > > > is > > > > > derived, you must use the non-derived value. > > > > > > > > > > I've made the other changes in my source file and they will appear > > in > > > > the > > > > > next version. > > > > > > > > > > Brian > > > > > > > > > >> -----Original Message----- > > > > >> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > > > >> Sent: Friday, July 11, 2008 6:00 AM > > > > >> To: Brian Rosen > > > > >> Cc: ECRIT > > > > >> Subject: Re: [Ecrit] New versions of -framework and -phonebcp > > > > >> > > > > >> Brian, > > > > >> > > > > >> thank you for submitting the new versions of your documents. > > > > >> However, I'm afraid you forgot my comments (except the LoSt > > dialstring > > > > >> "must"). > > > > >> My old posting: > > > > >> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html > > > > >> In your reply to this mail you agreed to these points. > > > > >> > > > > >> Karl Heinz > > > > >> > > > > >> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen > > > > wrote: > > > > >> > > > > >>> These versions incorporate all last call comments except as I > have > > > > >>> > > > > >> stated in > > > > >> > > > > >>> prior email. > > > > >>> > > > > >>> The majority of changes have to do with: > > > > >>> * More explicit text and references to -profile for multiple > > locations > > > > >>> > > > > >>> * Requiring the return of dialstrings on LoST for sos service > > URNs. > > > > >>> > > > > >>> * Lots of typos and wording changes. > > > > >>> > > > > >>> I did end up adding a couple of requirements, and thus needed to > > > > >>> > > > > >> renumber > > > > >> > > > > >>> the requirements, so diffs look bad. > > > > >>> > > > > >>> I ask commenters to look at the text to make sure I made all the > > > > changes > > > > >>> > > > > >> you > > > > >> > > > > >>> requested (with the exceptions covered in the emails). > > > > >>> > > > > >>> Chairs can consider if they wish to hold a short 2nd WGLC. > There > > are > > > > a > > > > >>> couple of substantive changes and added requirements, but not a > > whole > > > > >>> > > > > >> lot > > > > >> > > > > >>> text is modified in any but trivial ways. > > > > >>> > > > > >>> Brian > > > > >>> > > > > >>> _______________________________________________ > > > > >>> Ecrit mailing 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 Jul 14 17:44:45 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40EF33A6937; Mon, 14 Jul 2008 17:44: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 2A29E3A6937 for ; Mon, 14 Jul 2008 17:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[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 14KTlS8q1LRT for ; Mon, 14 Jul 2008 17:44:42 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 8AF7A3A68EC for ; Mon, 14 Jul 2008 17:44:42 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_07_14_20_00_18 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, 14 Jul 2008 20:00:17 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 19:45:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 19:45:01 -0500 Message-ID: In-Reply-To: <487B94DB.7060701@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] "Derived" method Thread-Index: Acjl3L9UDTTV2AoCSG6wUNxl3/bV2wANiuNQ References: <487B94DB.7060701@gmx.net> From: "Dawson, Martin" To: "Hannes Tschofenig" , "Marc Linsner" X-OriginalArrivalTime: 15 Jul 2008 00:45:01.0958 (UTC) FILETIME=[03EBD260:01C8E614] Cc: ECRIT Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 is useful in much the same way that it would be useful to know whether the person calling you on the PSTN is doing so from a POTS phone, a CDMA phone, a GSM phone.... that is, not very. In theory, more information is always better/nicer. In practice, I doubt this is going to appeal to anything more than very small niche applications. I can even see that network operators are not going to be in the least bit desirous of spelling out the location determination mechanisms from competitive and other perspectives. As such, we'll likely see some bland descriptor used if any at all. There are actually a lot of subtle nuances involved when it comes to real location determination mechanisms - especially in the wireless world and these will defy categorization anyway. A system that uses a combination of RF fingerprinting, propagation modelling, timing based multilateration, and device-based measurements such as GPS is going to be able to take its pick as far as which box to tick. Ultimately, I think the high runner question is going to be the same one that it always comes down to: how accurate is the information? To communicate this, you need uncertainty+confidence. And despite a strange comment on another thread, this applies just as much to GPS as anything else. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, 15 July 2008 4:03 AM To: Marc Linsner Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method That's actually a good question: Is the element really so useful? Ciao Hannes Marc Linsner wrote: > I'm not convinced any of this information is useful to a LR. > > Would the pizza be warmer when delivered if the delivery person had this > information? > > What would the LR do if the location information is wrong and they knew it > was derived by a ouija board vs. a wiremap database vs. triangulation? > > What if the wiremap database was populated using gps? > > -Marc- > > > On 7/14/08 1:30 PM, "Hannes Tschofenig" wrote: > > >> RFC 4119 isn't super exhaustive in the description of the semantic of >> the element and what it is being used for. >> >> What could be more useful for the Location Recipient to know: >> >> * Location was obtained using DHCP, or LLDP-MED >> >> OR >> >> * Location was determined using manual configuration, wiremap database, >> triangulation. >> >> >> Ciao >> Hannes >> >> >> >> James M. Polk wrote: >> >>> At 09:18 AM 7/12/2008, Hannes Tschofenig wrote: >>> >>>> The problem is a bit with the semantic of the method token given that >>>> it was supposed to be used to indicate the location determination >>>> method. >>>> >>> this is simply not true. Your definition is adding meaning that isn't >>> there. >>> >>> The element is the indication, solely created by the endpoint >>> (as an LG), of how it received (i.e., "discovered") location >>> information (not LO, but LI). >>> >>> Case in point, if a target has a sighter that derives location based >>> on triangulating the position of the target, yet delivers that LI via >>> DHCP, the would NOT say >>> >>> triangulation >>> >>> it would say >>> >>> dhcp >>> >>> and be correct. >>> >>> >>>> There are some "wrong" entries in the table already with that >>>> semantic since something like "DHCP" refers to an LCP rather than the >>>> actual location determination method. >>>> >>> This is not true either. If a target (as an LG) discovers its LI from >>> DHCP (Option 99 or 123), then this is the >>> >>> dhcp >>> >>> James W. added some additional semantics to the additional values >>> without running them by the WG when he IANA registered them, so the >>> non-4119 defined values haven't been fully vetted. >>> >>> This is because 4119 doesn't require any review of any kind before >>> adding new IANA entries to this registry. >>> >>> >>> >>> >>>> Now, I wonder whether it is possible to put more than one token into >>>> the method element. The data type is string and hence it would be >>>> possible. >>>> >>>> To pick your example, could you indicate gps derived? >>>> >>>> Ciao >>>> Hannes >>>> >>>> PS: I wonder whether there is actually a way to deprecate certain >>>> tokens from the registry. Nothing is indicated in RFC 4119. "802.11" >>>> and "DHCP" "LLDP-MED" really does not belong in there. FCFS as a >>>> policy for assignment does not sound useful to me either; expert >>>> review would be more useful. >>>> >>> Hennes - these 4119 values were the only ones that ever were "expert >>> reviewed", if you consider Geopriv a place where that can take place. >>> >>> BTW -- you were there for this expert review... perhaps you will >>> reconsider this stance once you re-evaluate how these entries are 4119 >>> intended. >>> >>> >>> >>> >>> >>>> Hannes Tschofenig wrote: >>>> >>>>> Thanks. >>>>> >>>>> Brian Rosen wrote: >>>>> >>>>>> The "Derived" method is used when the PIDF creator has a location >>>>>> available >>>>>> in one form (civic or geo) using another method, and derives a >>>>>> location in >>>>>> the other form. So for example, the determination method might be >>>>>> GPS, >>>>>> which creates a geo and the PIDF includes a civic derived from that >>>>>> geo. >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>> Sent: Saturday, July 12, 2008 5:04 AM >>>>>>> To: Brian Rosen >>>>>>> Cc: 'Karl Heinz Wolf'; 'ECRIT' >>>>>>> Subject: "Derived" method >>>>>>> >>>>>>> Could you describe the semantic of the "Derived" method a bit more? >>>>>>> >>>>>>> Brian Rosen wrote: >>>>>>> >>>>>>> >>>>>>>> I am sorry, I don't know how I missed these. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> page 7: "The phone gets location from the DHCP server in civic >>>>>>>>> [RFC4676] or geo" -> should it be "and/or"? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> The text makes clear that multiple locations are problematic. >>>>>>>> Multiple >>>>>>>> versions of the same location are problematic. I worry about >>>>>>>> systems >>>>>>>> >>>>>>>> >>>>>>> trying >>>>>>> >>>>>>> >>>>>>>> to be helpful and giving you a measured location and also giving >>>>>>>> you a >>>>>>>> derived (geo coded or reverse geo coded) version of the same >>>>>>>> location. >>>>>>>> >>>>>>>> This does raise yet another issue about this general subject; >>>>>>>> looking at >>>>>>>> >>>>>>>> >>>>>>> the >>>>>>> >>>>>>> >>>>>>>> list at: >>>>>>>> http://www.iana.org/assignments/method-tokens >>>>>>>> There is no method for "derived". So: >>>>>>>> I will add text to -framework covering this subject >>>>>>>> I will ask IANA to create a "Derived" method token >>>>>>>> I will add a requirement to -phonebcp that says if you get both >>>>>>>> and one >>>>>>>> >>>>>>>> >>>>>>> is >>>>>>> >>>>>>> >>>>>>>> derived, you must use the non-derived value. >>>>>>>> >>>>>>>> I've made the other changes in my source file and they will >>>>>>>> appear in >>>>>>>> >>>>>>>> >>>>>>> the >>>>>>> >>>>>>> >>>>>>>> next version. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >>>>>>>>> Sent: Friday, July 11, 2008 6:00 AM >>>>>>>>> To: Brian Rosen >>>>>>>>> Cc: ECRIT >>>>>>>>> Subject: Re: [Ecrit] New versions of -framework and -phonebcp >>>>>>>>> >>>>>>>>> Brian, >>>>>>>>> >>>>>>>>> thank you for submitting the new versions of your documents. >>>>>>>>> However, I'm afraid you forgot my comments (except the LoSt >>>>>>>>> dialstring >>>>>>>>> "must"). >>>>>>>>> My old posting: >>>>>>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html >>>>>>>>> In your reply to this mail you agreed to these points. >>>>>>>>> >>>>>>>>> Karl Heinz >>>>>>>>> >>>>>>>>> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen >>>>>>>>> >>>>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>>>> These versions incorporate all last call comments except as I have >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> stated in >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> prior email. >>>>>>>>>> >>>>>>>>>> The majority of changes have to do with: >>>>>>>>>> * More explicit text and references to -profile for multiple >>>>>>>>>> locations >>>>>>>>>> >>>>>>>>>> * Requiring the return of dialstrings on LoST for sos service >>>>>>>>>> URNs. >>>>>>>>>> >>>>>>>>>> * Lots of typos and wording changes. >>>>>>>>>> >>>>>>>>>> I did end up adding a couple of requirements, and thus needed to >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> renumber >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> the requirements, so diffs look bad. >>>>>>>>>> >>>>>>>>>> I ask commenters to look at the text to make sure I made all the >>>>>>>>>> >>>>>>>>>> >>>>>>> changes >>>>>>> >>>>>>> >>>>>>>>> you >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> requested (with the exceptions covered in the emails). >>>>>>>>>> >>>>>>>>>> Chairs can consider if they wish to hold a short 2nd WGLC. >>>>>>>>>> There are >>>>>>>>>> >>>>>>>>>> >>>>>>> a >>>>>>> >>>>>>> >>>>>>>>>> couple of substantive changes and added requirements, but not a >>>>>>>>>> whole >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> lot >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> text is modified in any but trivial ways. >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Ecrit mailing 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 Jul 14 21:51:35 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97AB3A67FD; Mon, 14 Jul 2008 21: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 9E0CA28C0E1 for ; Mon, 14 Jul 2008 21:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDs5+R5gyp8o for ; Mon, 14 Jul 2008 21:51:33 -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 9C7E93A67D1 for ; Mon, 14 Jul 2008 21:51:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,364,1212364800"; d="scan'208";a="126746196" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 15 Jul 2008 04:51:46 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6F4pkw9003153; Mon, 14 Jul 2008 21:51:46 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m6F4pkhW021367; Tue, 15 Jul 2008 04:51:46 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); Mon, 14 Jul 2008 21:51:46 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.84.1]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 21:51:45 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Jul 2008 23:51:48 -0500 To: Ted Hardie , , , "hannes.tschofenig@nsn.com" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 15 Jul 2008 04:51:45.0928 (UTC) FILETIME=[7BC66080:01C8E636] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1148; t=1216097506; x=1216961506; c=relaxed/simple; s=sjdkim4002; 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]=20Request=20for=20agenda=20time =20to=20discuss=20emergency=20call=0A=20=20termination |Sender:=20; bh=KXvveCfRqnOWum0+F6FLYAv5/lTw1zgRptmzMnvNBSs=; b=LuaFYXdpsElRHMqTsqompozV8NGdzZSS9YZXKIqiHay3GZfYxR6Vwg3hiJ JBLVj8Ny2ddsoLN4I6ukSzCGQb1EYkAaiwa+2AThOP2tZWGh+wvf5wHhKeYf 2IfFCuriLi; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Ecrit] Request for agenda time to discuss emergency call termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 04:16 PM 7/14/2008, Ted Hardie wrote: >Howdy, > I re-read the thread that discussed this with our colleagues >at NENA, and I believe that the group would benefit from some in-person >discussion of the issues. Could we have a 10-15 minute discussion on >the agenda? I'd like to understand what about the thread you didn't understand , or was otherwise unclear, as this topic pertains to the IETF? Within that context, and because there is no ID as a central point of focus, what would be your topic outline? Most the point raised was about US jurisdictions allowing caller termination, and the counter was a) everything is always subject to local laws, and b) is there a problem with the race condition between a caller and a callee hanging up the phone being worth chasing (when measured in fractions of a second)? >Failing that, can we arrange a bar BoF on this? > thanks, > Ted >_______________________________________________ >Ecrit mailing 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 Jul 14 21:58:00 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F04A23A67FD; Mon, 14 Jul 2008 21:57: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 60D453A67FD for ; Mon, 14 Jul 2008 21:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgB679saqIj2 for ; Mon, 14 Jul 2008 21:57:56 -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 D80583A67D1 for ; Mon, 14 Jul 2008 21:57:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,364,1212364800"; d="scan'208";a="65459371" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2008 04:58:23 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6F4wNja022003; Mon, 14 Jul 2008 21:58:23 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m6F4wN74024425; Tue, 15 Jul 2008 04:58:23 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 21:58:23 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.84.1]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 21:58:23 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Jul 2008 23:58:27 -0500 To: "Winterbottom, James" , "Brian Rosen" , "Hannes Tschofenig" From: "James M. Polk" In-Reply-To: References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> <023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com> <48787395.1040507@gmx.net> <053301c8e4fb$ac68e960$640fa8c0@cis.neustar.com> <093b01c8e5da$82b461f0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 15 Jul 2008 04:58:23.0115 (UTC) FILETIME=[68844DB0:01C8E637] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8865; t=1216097903; x=1216961903; 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]=20=22Derived=22=20method |Sender:=20; bh=rbLajf96pjXTA30n9Ca2TvO5XVti7+l/D9Se1ZALOsA=; b=pC2vQAr9JXbW2JMwTZNUGInA44odNjwx22njaSZLezn+5rQoQfPzMaurSo bKJ0DMtHprr2U3vvwGQ3plHzx83yjROaB48poRDmAzFyFKldvY2dazXBd0m6 dE1bjiW2jX; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: ECRIT Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 04:53 PM 7/14/2008, Winterbottom, James wrote: >PIDF-LO profile already says this. If you have two different >methods, they must reside in the separate elements. I agree with James (W) this should be good enough. Let me correct myself (from an earlier message) in saying (I think) 2 geopriv elements accomplishes the same thing as 2 PIDF-LOs, since a PIDF with 2 LOs has two geopriv elements. >-----Original Message----- >From: ecrit-bounces@ietf.org on behalf of Brian Rosen >Sent: Mon 7/14/2008 12:53 PM >To: 'James M. Polk'; 'Hannes Tschofenig' >Cc: 'ECRIT' >Subject: Re: [Ecrit] "Derived" method > >I would say this is an error. > >I think we need to determine what "method" should mean (prior email) first, >but then we should fix this so that each location info section has its own >method. > >Brian > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Monday, July 14, 2008 1:33 PM > > To: Brian Rosen; 'Hannes Tschofenig' > > Cc: 'ECRIT' > > Subject: Re: [Ecrit] "Derived" method > > > > At 10:18 AM 7/13/2008, Brian Rosen wrote: > > >I think we can get quite carried away with all the possibilities, and > > there > > >is no reason to be carried away. > > > > > >The possibilities are: > > >1. There is exactly one location, and it's marked "Derived". There is no > > >need for more information. > > > > I agree with this > > > > >2. There are exactly two locations, and one is marked "Derived". This > > means > > >the other is the original > > > > I do not agree with this. > > > > Here's how I got there > > > > The element is a sub-element of what element? > > > > Is it ? > > > > no -- it's parallel to it > > > > therefore the element has to be THE way the whole LO was > > discovered, regardless of how many formats (civic, geo, > > whatever's_coming_next) are in the LO. > > > > IF there are two locations, and they were discovered using different > > methods, that's TWO PIDF-LOs; else there's confusion. > > > > >3. There are more than two locations and one or more is marked "Derived". > > I > > >think we can ignore this case, or at least say that there is no way to > > >understand what is derived from what. > > > > > >Brian > > > > > > > -----Original Message----- > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > Sent: Saturday, July 12, 2008 10:37 PM > > > > To: Hannes Tschofenig; Brian Rosen > > > > Cc: ECRIT > > > > Subject: RE: [Ecrit] "Derived" method > > > > > > > > Hi Brian, > > > > > > > > For derived to really have a clear meaning it needs to be totally > > > > unambiguous what the location is derived from. > > > > The example I always hear is a civic address derived from a geodetic > > > > shape, or vice versa. In this case, you need to provide both locations > > in > > > > the PIDF-LO document, and somehow, there needs to be a link between > > them. > > > > Simply havinf both locations in the same document isn't sufficient, I > > > > think you need the equivalent of an tag, or something like > > that. > > > > > > > > Cheers > > > > James > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > > > > Sent: Sat 7/12/2008 4:04 AM > > > > To: Brian Rosen > > > > Cc: 'ECRIT' > > > > Subject: [Ecrit] "Derived" method > > > > > > > > Could you describe the semantic of the "Derived" method a bit more? > > > > > > > > Brian Rosen wrote: > > > > > I am sorry, I don't know how I missed these. > > > > > > > > > > > > > > >> page 7: "The phone gets location from the DHCP server in civic > > > > >> [RFC4676] or geo" -> should it be "and/or"? > > > > >> > > > > > The text makes clear that multiple locations are problematic. > > Multiple > > > > > versions of the same location are problematic. I worry about > > systems > > > > trying > > > > > to be helpful and giving you a measured location and also giving you > > a > > > > > derived (geo coded or reverse geo coded) version of the same > > location. > > > > > > > > > > This does raise yet another issue about this general subject; > > looking at > > > > the > > > > > list at: > > > > > http://www.iana.org/assignments/method-tokens > > > > > There is no method for "derived". So: > > > > > I will add text to -framework covering this subject > > > > > I will ask IANA to create a "Derived" method token > > > > > I will add a requirement to -phonebcp that says if you get both and > > one > > > > is > > > > > derived, you must use the non-derived value. > > > > > > > > > > I've made the other changes in my source file and they will appear > > in > > > > the > > > > > next version. > > > > > > > > > > Brian > > > > > > > > > >> -----Original Message----- > > > > >> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > > > >> Sent: Friday, July 11, 2008 6:00 AM > > > > >> To: Brian Rosen > > > > >> Cc: ECRIT > > > > >> Subject: Re: [Ecrit] New versions of -framework and -phonebcp > > > > >> > > > > >> Brian, > > > > >> > > > > >> thank you for submitting the new versions of your documents. > > > > >> However, I'm afraid you forgot my comments (except the LoSt > > dialstring > > > > >> "must"). > > > > >> My old posting: > > > > >> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html > > > > >> In your reply to this mail you agreed to these points. > > > > >> > > > > >> Karl Heinz > > > > >> > > > > >> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen > > > > wrote: > > > > >> > > > > >>> These versions incorporate all last call comments except as I have > > > > >>> > > > > >> stated in > > > > >> > > > > >>> prior email. > > > > >>> > > > > >>> The majority of changes have to do with: > > > > >>> * More explicit text and references to -profile for multiple > > locations > > > > >>> > > > > >>> * Requiring the return of dialstrings on LoST for sos service > > URNs. > > > > >>> > > > > >>> * Lots of typos and wording changes. > > > > >>> > > > > >>> I did end up adding a couple of requirements, and thus needed to > > > > >>> > > > > >> renumber > > > > >> > > > > >>> the requirements, so diffs look bad. > > > > >>> > > > > >>> I ask commenters to look at the text to make sure I made all the > > > > changes > > > > >>> > > > > >> you > > > > >> > > > > >>> requested (with the exceptions covered in the emails). > > > > >>> > > > > >>> Chairs can consider if they wish to hold a short 2nd WGLC. There > > are > > > > a > > > > >>> couple of substantive changes and added requirements, but not a > > whole > > > > >>> > > > > >> lot > > > > >> > > > > >>> text is modified in any but trivial ways. > > > > >>> > > > > >>> Brian > > > > >>> > > > > >>> _______________________________________________ > > > > >>> Ecrit mailing 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 Jul 14 22:04:10 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC5E13A695C; Mon, 14 Jul 2008 22:04: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 8AD3A3A67DD for ; Mon, 14 Jul 2008 22:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7xvXoXmeM3g for ; Mon, 14 Jul 2008 22:04: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 C649F3A6881 for ; Mon, 14 Jul 2008 22:04:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,364,1212364800"; d="scan'208";a="52960904" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 15 Jul 2008 05:04:32 +0000 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 m6F54Vmj030242; Mon, 14 Jul 2008 22:04:31 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6F54VhP010145; Tue, 15 Jul 2008 05:04:31 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, 14 Jul 2008 22:04:31 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.84.1]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 22:04:30 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 15 Jul 2008 00:04:34 -0500 To: "Winterbottom, James" , "Brian Rosen" , "Marc Linsner" , "Hannes Tschofenig" From: "James M. Polk" In-Reply-To: References: <487B8D31.4000402@gmx.net> <094e01c8e5db$f985c070$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 15 Jul 2008 05:04:30.0820 (UTC) FILETIME=[43AFA240:01C8E638] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12356; t=1216098272; x=1216962272; 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]=20=22Derived=22=20method |Sender:=20; bh=VbtFmLz+lzh2UZbi3hWDCXZ1qi+dDT3JY99U0FM8Vgc=; b=ODQyzUUSNt1bJXydzUdOlg19Ss1roq/8E1iFyk7zbWm8JiJJQ3m7p+km+n a32aEjr+ep69yr7+x3BITRAZeTrYiS9X+f0FVtXsH5BWLMhta1z4e6txQnWy 4fz/ASqy99; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: ECRIT Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 04:58 PM 7/14/2008, Winterbottom, James wrote: >I agree with Brian it that its sole benefit is really an indicator >to location recipients that it MAY be possible to get a better >location. I say may, because in many cases A-GPS is not going to be >as good as a cell-based location from a femto or pico-cell. I think - though I'm not 100% positive - that "cell" cannot distinguish between regular cell tower and femto or pico -- therefore if "cell" is the method, it should already have a very good fix on the target's position, given how small the range is of femto and pico cells. A classic "rebid" should accomplish little more resolution in determining where a target is. On an aside, I'd like to know if there is a way for a target to know which type of cell tower (access point-ish) thingy it is connecting through. Does anyone know this now? >Still I think it has some benefit, but as Marc says, probably not >for the pizza delivery guy. Well, it might if the (regular) cell tower determines call routing, but is too coarse for delivery -- and a subsequent location determination provides a greater precision (in time for the pizza to be delivery hot and toasty). >Cheers >James > >-----Original Message----- >From: ecrit-bounces@ietf.org on behalf of Brian Rosen >Sent: Mon 7/14/2008 1:03 PM >To: 'Marc Linsner'; 'Hannes Tschofenig'; 'James Polk' >Cc: 'ECRIT' >Subject: Re: [Ecrit] "Derived" method > >You can reasonably infer things based on it. > >For example, wiremap data would never change. GPS data might. If you >measured wiremap data with gps, it would not likely change. No guarantees. > > >Another example would be "cell". If you ask for an update later, in some >countries, you likely will get a better location (using a different method). > >Brian > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > > Marc Linsner > > Sent: Monday, July 14, 2008 1:55 PM > > To: Hannes Tschofenig; James Polk > > Cc: 'ECRIT' > > Subject: Re: [Ecrit] "Derived" method > > > > I'm not convinced any of this information is useful to a LR. > > > > Would the pizza be warmer when delivered if the delivery person had this > > information? > > > > What would the LR do if the location information is wrong and they knew it > > was derived by a ouija board vs. a wiremap database vs. triangulation? > > > > What if the wiremap database was populated using gps? > > > > -Marc- > > > > > > On 7/14/08 1:30 PM, "Hannes Tschofenig" wrote: > > > > > RFC 4119 isn't super exhaustive in the description of the semantic of > > > the element and what it is being used for. > > > > > > What could be more useful for the Location Recipient to know: > > > > > > * Location was obtained using DHCP, or LLDP-MED > > > > > > OR > > > > > > * Location was determined using manual configuration, wiremap database, > > > triangulation. > > > > > > > > > Ciao > > > Hannes > > > > > > > > > > > > James M. Polk wrote: > > >> At 09:18 AM 7/12/2008, Hannes Tschofenig wrote: > > >>> The problem is a bit with the semantic of the method token given that > > >>> it was supposed to be used to indicate the location determination > > >>> method. > > >> > > >> this is simply not true. Your definition is adding meaning that isn't > > >> there. > > >> > > >> The element is the indication, solely created by the endpoint > > >> (as an LG), of how it received (i.e., "discovered") location > > >> information (not LO, but LI). > > >> > > >> Case in point, if a target has a sighter that derives location based > > >> on triangulating the position of the target, yet delivers that LI via > > >> DHCP, the would NOT say > > >> > > >> triangulation > > >> > > >> it would say > > >> > > >> dhcp > > >> > > >> and be correct. > > >> > > >>> There are some "wrong" entries in the table already with that > > >>> semantic since something like "DHCP" refers to an LCP rather than the > > >>> actual location determination method. > > >> > > >> This is not true either. If a target (as an LG) discovers its LI from > > >> DHCP (Option 99 or 123), then this is the > > >> > > >> dhcp > > >> > > >> James W. added some additional semantics to the additional values > > >> without running them by the WG when he IANA registered them, so the > > >> non-4119 defined values haven't been fully vetted. > > >> > > >> This is because 4119 doesn't require any review of any kind before > > >> adding new IANA entries to this registry. > > >> > > >> > > >> > > >>> Now, I wonder whether it is possible to put more than one token into > > >>> the method element. The data type is string and hence it would be > > >>> possible. > > >>> > > >>> To pick your example, could you indicate gps derived? > > >>> > > >>> Ciao > > >>> Hannes > > >>> > > >>> PS: I wonder whether there is actually a way to deprecate certain > > >>> tokens from the registry. Nothing is indicated in RFC 4119. "802.11" > > >>> and "DHCP" "LLDP-MED" really does not belong in there. FCFS as a > > >>> policy for assignment does not sound useful to me either; expert > > >>> review would be more useful. > > >> > > >> Hennes - these 4119 values were the only ones that ever were "expert > > >> reviewed", if you consider Geopriv a place where that can take place. > > >> > > >> BTW -- you were there for this expert review... perhaps you will > > >> reconsider this stance once you re-evaluate how these entries are 4119 > > >> intended. > > >> > > >> > > >> > > >> > > >>> Hannes Tschofenig wrote: > > >>>> Thanks. > > >>>> > > >>>> Brian Rosen wrote: > > >>>>> The "Derived" method is used when the PIDF creator has a location > > >>>>> available > > >>>>> in one form (civic or geo) using another method, and derives a > > >>>>> location in > > >>>>> the other form. So for example, the determination method might be > > >>>>> GPS, > > >>>>> which creates a geo and the PIDF includes a civic derived from that > > >>>>> geo. > > >>>>> > > >>>>> Brian > > >>>>> > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > >>>>>> Sent: Saturday, July 12, 2008 5:04 AM > > >>>>>> To: Brian Rosen > > >>>>>> Cc: 'Karl Heinz Wolf'; 'ECRIT' > > >>>>>> Subject: "Derived" method > > >>>>>> > > >>>>>> Could you describe the semantic of the "Derived" method a bit more? > > >>>>>> > > >>>>>> Brian Rosen wrote: > > >>>>>> > > >>>>>>> I am sorry, I don't know how I missed these. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>>> page 7: "The phone gets location from the DHCP server in civic > > >>>>>>>> [RFC4676] or geo" -> should it be "and/or"? > > >>>>>>>> > > >>>>>>>> > > >>>>>>> The text makes clear that multiple locations are problematic. > > >>>>>>> Multiple > > >>>>>>> versions of the same location are problematic. I worry about > > >>>>>>> systems > > >>>>>>> > > >>>>>> trying > > >>>>>> > > >>>>>>> to be helpful and giving you a measured location and also giving > > >>>>>>> you a > > >>>>>>> derived (geo coded or reverse geo coded) version of the same > > >>>>>>> location. > > >>>>>>> > > >>>>>>> This does raise yet another issue about this general subject; > > >>>>>>> looking at > > >>>>>>> > > >>>>>> the > > >>>>>> > > >>>>>>> list at: > > >>>>>>> http://www.iana.org/assignments/method-tokens > > >>>>>>> There is no method for "derived". So: > > >>>>>>> I will add text to -framework covering this subject > > >>>>>>> I will ask IANA to create a "Derived" method token > > >>>>>>> I will add a requirement to -phonebcp that says if you get both > > >>>>>>> and one > > >>>>>>> > > >>>>>> is > > >>>>>> > > >>>>>>> derived, you must use the non-derived value. > > >>>>>>> > > >>>>>>> I've made the other changes in my source file and they will > > >>>>>>> appear in > > >>>>>>> > > >>>>>> the > > >>>>>> > > >>>>>>> next version. > > >>>>>>> > > >>>>>>> Brian > > >>>>>>> > > >>>>>>> > > >>>>>>>> -----Original Message----- > > >>>>>>>> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > >>>>>>>> Sent: Friday, July 11, 2008 6:00 AM > > >>>>>>>> To: Brian Rosen > > >>>>>>>> Cc: ECRIT > > >>>>>>>> Subject: Re: [Ecrit] New versions of -framework and -phonebcp > > >>>>>>>> > > >>>>>>>> Brian, > > >>>>>>>> > > >>>>>>>> thank you for submitting the new versions of your documents. > > >>>>>>>> However, I'm afraid you forgot my comments (except the LoSt > > >>>>>>>> dialstring > > >>>>>>>> "must"). > > >>>>>>>> My old posting: > > >>>>>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html > > >>>>>>>> In your reply to this mail you agreed to these points. > > >>>>>>>> > > >>>>>>>> Karl Heinz > > >>>>>>>> > > >>>>>>>> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen > > >>>>>>>> > > >>>>>> wrote: > > >>>>>> > > >>>>>>>>> These versions incorporate all last call comments except as I > > have > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>> stated in > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> prior email. > > >>>>>>>>> > > >>>>>>>>> The majority of changes have to do with: > > >>>>>>>>> * More explicit text and references to -profile for multiple > > >>>>>>>>> locations > > >>>>>>>>> > > >>>>>>>>> * Requiring the return of dialstrings on LoST for sos service > > >>>>>>>>> URNs. > > >>>>>>>>> > > >>>>>>>>> * Lots of typos and wording changes. > > >>>>>>>>> > > >>>>>>>>> I did end up adding a couple of requirements, and thus needed to > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>> renumber > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> the requirements, so diffs look bad. > > >>>>>>>>> > > >>>>>>>>> I ask commenters to look at the text to make sure I made all the > > >>>>>>>>> > > >>>>>> changes > > >>>>>> > > >>>>>>>> you > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> requested (with the exceptions covered in the emails). > > >>>>>>>>> > > >>>>>>>>> Chairs can consider if they wish to hold a short 2nd WGLC. > > >>>>>>>>> There are > > >>>>>>>>> > > >>>>>> a > > >>>>>> > > >>>>>>>>> couple of substantive changes and added requirements, but not a > > >>>>>>>>> whole > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>> lot > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> text is modified in any but trivial ways. > > >>>>>>>>> > > >>>>>>>>> Brian > > >>>>>>>>> > > >>>>>>>>> _______________________________________________ > > >>>>>>>>> Ecrit mailing 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 > > >------------------------------------------------------------------------------------------------ >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 Jul 14 22:17:01 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D76C028C1CA; Mon, 14 Jul 2008 22:17: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 95A453A693C for ; Mon, 14 Jul 2008 22:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxPc598ggtrI for ; Mon, 14 Jul 2008 22:16:58 -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 E01A528C275 for ; Mon, 14 Jul 2008 22:16:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,364,1212364800"; d="scan'208";a="126753349" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 15 Jul 2008 05:17:21 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6F5HLfJ013878; Mon, 14 Jul 2008 22:17:21 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m6F5HLxJ008425; Tue, 15 Jul 2008 05:17:21 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, 14 Jul 2008 22:17:20 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.84.1]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 22:17:20 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 15 Jul 2008 00:17:24 -0500 To: "Brian Rosen" , "'Winterbottom, James'" , "'Hannes Tschofenig'" From: "James M. Polk" In-Reply-To: <0c5b01c8e602$91120720$640fa8c0@cis.neustar.com> References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com> <023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com> <48787395.1040507@gmx.net> <053301c8e4fb$ac68e960$640fa8c0@cis.neustar.com> <093b01c8e5da$82b461f0$640fa8c0@cis.neustar.com> <0c5b01c8e602$91120720$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 15 Jul 2008 05:17:20.0287 (UTC) FILETIME=[0E52FAF0:01C8E63A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12109; t=1216099041; x=1216963041; 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]=20=22Derived=22=20method |Sender:=20; bh=XFq1RTyyDJpNvIaX6x6JU27KTxCSxSRkYrpw1tcpQaQ=; b=PnOYzxi00g7EqAyiywGd+pABy2Io2ktwpniakRJWH21PIcEeab4RfGaAWf 0iGEACsLYkQit2Qy5rCZ/B02BMglmdzIRy5JyEBvWHTbF3mlIqSkaIMYeyFl NApcSPg5cR; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian I think you're mixing capabilities between a PIDF-LO and what we shorten the acronym by calling it just a PIDF. The key is that each LO has one method, which is accomplished by the limitation of the geopriv element to only ever having one. 2 completely separate PIDF-LO message bodies has just as much location information as 1 PIDF with two geopriv elements (each with exactly 1 method). There is enough separation at this point. Having more than 1 method within a geopriv element means you have at least two different location formats, if not repetitive subelements of the same location format. This would be bad. I know when I wrote the sections of 4119 (it sez so in the acknowledgements section - so check it out) that I wrote/created the method element to be from the target's point of view, to give the call taker more information about how the target learned, or "discovered" its location. This is to, over time, give PSAP call takers more information about learning which methods are more precise during the first responder dispatch phase of what the location is used for. For example, with wifi, if the call taker knows this, s/he can tell the fire department the target is within 100m of a certain location -- because that is the radius of the radio tether of the AP. Whereas, if the call taker learns that gps is the method, and it is to a non-tall-building, the location supplied probably is trustworthy - regardless of where it looks like the caller is from. Malibu canyons came to mind, because the terrain is so rough, and so many die there and aren't found for years/decades. James At 05:40 PM 7/14/2008, Brian Rosen wrote: >I had to go back and look at the structures again. I'm not enough of an XML >expert here, but I gather that because we extended PIDF to include the >geopriv element, and the extension is in a sequence, a single PIDF can have >multiple geopriv elements, each of which has a location-info, method, >usage-rules and provided-by elements. Multiple methods = multiple geopriv >elements, but within one PIDF. > >So, we're back to seeing if we can agree on what method means. >I think we should say it always means how location was determined, and not >how it was configured. I think we should say if you send method=Derived, >then you SHOULD send another geopriv element with method=something else, but >in any case, you mark method=derived on the derived geopriv element. If you >have more than two geopriv elements and one or more has method=derived, then >relationships between determination methods and derivations cannot be >determined. > >Brian > > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Monday, July 14, 2008 5:54 PM > > To: Brian Rosen; James M. Polk; Hannes Tschofenig > > Cc: ECRIT > > Subject: RE: [Ecrit] "Derived" method > > > > > > PIDF-LO profile already says this. If you have two different methods, they > > must reside in the separate elements. > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org on behalf of Brian Rosen > > Sent: Mon 7/14/2008 12:53 PM > > To: 'James M. Polk'; 'Hannes Tschofenig' > > Cc: 'ECRIT' > > Subject: Re: [Ecrit] "Derived" method > > > > I would say this is an error. > > > > I think we need to determine what "method" should mean (prior email) > > first, > > but then we should fix this so that each location info section has its own > > method. > > > > Brian > > > > > -----Original Message----- > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > Sent: Monday, July 14, 2008 1:33 PM > > > To: Brian Rosen; 'Hannes Tschofenig' > > > Cc: 'ECRIT' > > > Subject: Re: [Ecrit] "Derived" method > > > > > > At 10:18 AM 7/13/2008, Brian Rosen wrote: > > > >I think we can get quite carried away with all the possibilities, and > > > there > > > >is no reason to be carried away. > > > > > > > >The possibilities are: > > > >1. There is exactly one location, and it's marked "Derived". There is > > no > > > >need for more information. > > > > > > I agree with this > > > > > > >2. There are exactly two locations, and one is marked "Derived". This > > > means > > > >the other is the original > > > > > > I do not agree with this. > > > > > > Here's how I got there > > > > > > The element is a sub-element of what element? > > > > > > Is it ? > > > > > > no -- it's parallel to it > > > > > > therefore the element has to be THE way the whole LO was > > > discovered, regardless of how many formats (civic, geo, > > > whatever's_coming_next) are in the LO. > > > > > > IF there are two locations, and they were discovered using different > > > methods, that's TWO PIDF-LOs; else there's confusion. > > > > > > >3. There are more than two locations and one or more is marked > > "Derived". > > > I > > > >think we can ignore this case, or at least say that there is no way to > > > >understand what is derived from what. > > > > > > > >Brian > > > > > > > > > -----Original Message----- > > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > > Sent: Saturday, July 12, 2008 10:37 PM > > > > > To: Hannes Tschofenig; Brian Rosen > > > > > Cc: ECRIT > > > > > Subject: RE: [Ecrit] "Derived" method > > > > > > > > > > Hi Brian, > > > > > > > > > > For derived to really have a clear meaning it needs to be totally > > > > > unambiguous what the location is derived from. > > > > > The example I always hear is a civic address derived from a geodetic > > > > > shape, or vice versa. In this case, you need to provide both > > locations > > > in > > > > > the PIDF-LO document, and somehow, there needs to be a link between > > > them. > > > > > Simply havinf both locations in the same document isn't sufficient, > > I > > > > > think you need the equivalent of an tag, or something like > > > that. > > > > > > > > > > Cheers > > > > > James > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > > > > > Sent: Sat 7/12/2008 4:04 AM > > > > > To: Brian Rosen > > > > > Cc: 'ECRIT' > > > > > Subject: [Ecrit] "Derived" method > > > > > > > > > > Could you describe the semantic of the "Derived" method a bit more? > > > > > > > > > > Brian Rosen wrote: > > > > > > I am sorry, I don't know how I missed these. > > > > > > > > > > > > > > > > > >> page 7: "The phone gets location from the DHCP server in civic > > > > > >> [RFC4676] or geo" -> should it be "and/or"? > > > > > >> > > > > > > The text makes clear that multiple locations are problematic. > > > Multiple > > > > > > versions of the same location are problematic. I worry about > > > systems > > > > > trying > > > > > > to be helpful and giving you a measured location and also giving > > you > > > a > > > > > > derived (geo coded or reverse geo coded) version of the same > > > location. > > > > > > > > > > > > This does raise yet another issue about this general subject; > > > looking at > > > > > the > > > > > > list at: > > > > > > http://www.iana.org/assignments/method-tokens > > > > > > There is no method for "derived". So: > > > > > > I will add text to -framework covering this subject > > > > > > I will ask IANA to create a "Derived" method token > > > > > > I will add a requirement to -phonebcp that says if you get both > > and > > > one > > > > > is > > > > > > derived, you must use the non-derived value. > > > > > > > > > > > > I've made the other changes in my source file and they will appear > > > in > > > > > the > > > > > > next version. > > > > > > > > > > > > Brian > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > > > > >> Sent: Friday, July 11, 2008 6:00 AM > > > > > >> To: Brian Rosen > > > > > >> Cc: ECRIT > > > > > >> Subject: Re: [Ecrit] New versions of -framework and -phonebcp > > > > > >> > > > > > >> Brian, > > > > > >> > > > > > >> thank you for submitting the new versions of your documents. > > > > > >> However, I'm afraid you forgot my comments (except the LoSt > > > dialstring > > > > > >> "must"). > > > > > >> My old posting: > > > > > >> http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html > > > > > >> In your reply to this mail you agreed to these points. > > > > > >> > > > > > >> Karl Heinz > > > > > >> > > > > > >> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen > > > > > wrote: > > > > > >> > > > > > >>> These versions incorporate all last call comments except as I > > have > > > > > >>> > > > > > >> stated in > > > > > >> > > > > > >>> prior email. > > > > > >>> > > > > > >>> The majority of changes have to do with: > > > > > >>> * More explicit text and references to -profile for multiple > > > locations > > > > > >>> > > > > > >>> * Requiring the return of dialstrings on LoST for sos service > > > URNs. > > > > > >>> > > > > > >>> * Lots of typos and wording changes. > > > > > >>> > > > > > >>> I did end up adding a couple of requirements, and thus needed to > > > > > >>> > > > > > >> renumber > > > > > >> > > > > > >>> the requirements, so diffs look bad. > > > > > >>> > > > > > >>> I ask commenters to look at the text to make sure I made all the > > > > > changes > > > > > >>> > > > > > >> you > > > > > >> > > > > > >>> requested (with the exceptions covered in the emails). > > > > > >>> > > > > > >>> Chairs can consider if they wish to hold a short 2nd WGLC. > > There > > > are > > > > > a > > > > > >>> couple of substantive changes and added requirements, but not a > > > whole > > > > > >>> > > > > > >> lot > > > > > >> > > > > > >>> text is modified in any but trivial ways. > > > > > >>> > > > > > >>> Brian > > > > > >>> > > > > > >>> _______________________________________________ > > > > > >>> Ecrit mailing 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 Jul 14 22:18:50 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46A713A6976; Mon, 14 Jul 2008 22:18: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 1138C3A6976 for ; Mon, 14 Jul 2008 22:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[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 pbU8-8RDiGdL for ; Mon, 14 Jul 2008 22:18:47 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id B9A603A6883 for ; Mon, 14 Jul 2008 22:18:47 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_07_15_00_34_24 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, 15 Jul 2008 00:34:24 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 00:19:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Jul 2008 00:19:11 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] "Derived" method Thread-Index: Acjl1bAyXjquyVrwTM6xJdib6LldggAY5+jg References: <009201c8e2c9$d7d0fa40$640fa8c0@cis.neustar.com><023901c8e361$f3ae04e0$640fa8c0@cis.neustar.com><48787395.1040507@gmx.net><03eb01c8e425$35b47180$640fa8c0@cis.neustar.com><4878B640.1050907@gmx.net> <4878BD4C.5070805@gmx.net> From: "Winterbottom, James" To: "James M. Polk" , "Hannes Tschofenig" X-OriginalArrivalTime: 15 Jul 2008 05:19:13.0429 (UTC) FILETIME=[51C31450:01C8E63A] Cc: ECRIT Subject: Re: [Ecrit] "Derived" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Dodging the comment about how I used a FCFS registry in the correct way. I actually think both James and Hannes are right. James is right, in that if an end-point learns its location from a DHCP server and then wants to construct a PIDF-LO, it has only three options for . 1) It simply doesn't set it at all 2) It sets it DHCP 3) It sets it to something else, like manual. I agree with James that dhcp is the most appropriate thing to set it to. However Hannes is also right. If I am using HELD, for example, and I received back a fully formed PIDF-LO, then the LIS that provided me that information should set the to be the way in which it determined the location of the Target. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > James M. Polk > Sent: Tuesday, 15 July 2008 3:18 AM > To: Hannes Tschofenig > Cc: 'ECRIT' > Subject: Re: [Ecrit] "Derived" method > > At 09:18 AM 7/12/2008, Hannes Tschofenig wrote: > >The problem is a bit with the semantic of the method token given > >that it was supposed to be used to indicate the location determination > method. > > this is simply not true. Your definition is adding meaning that isn't > there. > > The element is the indication, solely created by the > endpoint (as an LG), of how it received (i.e., "discovered") location > information (not LO, but LI). > > Case in point, if a target has a sighter that derives location based > on triangulating the position of the target, yet delivers that LI via > DHCP, the would NOT say > > triangulation > > it would say > > dhcp > > and be correct. > > >There are some "wrong" entries in the table already with that > >semantic since something like "DHCP" refers to an LCP rather than > >the actual location determination method. > > This is not true either. If a target (as an LG) discovers its LI > from DHCP (Option 99 or 123), then this is the > > dhcp > > James W. added some additional semantics to the additional values > without running them by the WG when he IANA registered them, so the > non-4119 defined values haven't been fully vetted. > > This is because 4119 doesn't require any review of any kind before > adding new IANA entries to this registry. > > > > >Now, I wonder whether it is possible to put more than one token into > >the method element. The data type is string and hence it would be > possible. > > > >To pick your example, could you indicate gps derived? > > > >Ciao > >Hannes > > > >PS: I wonder whether there is actually a way to deprecate certain > >tokens from the registry. Nothing is indicated in RFC 4119. "802.11" > >and "DHCP" "LLDP-MED" really does not belong in there. FCFS as a > >policy for assignment does not sound useful to me either; expert > >review would be more useful. > > Hennes - these 4119 values were the only ones that ever were "expert > reviewed", if you consider Geopriv a place where that can take place. > > BTW -- you were there for this expert review... perhaps you will > reconsider this stance once you re-evaluate how these entries are > 4119 intended. > > > > > >Hannes Tschofenig wrote: > >>Thanks. > >> > >>Brian Rosen wrote: > >>>The "Derived" method is used when the PIDF creator has a location > available > >>>in one form (civic or geo) using another method, and derives a location > in > >>>the other form. So for example, the determination method might be GPS, > >>>which creates a geo and the PIDF includes a civic derived from that geo. > >>> > >>>Brian > >>> > >>> > >>>>-----Original Message----- > >>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>Sent: Saturday, July 12, 2008 5:04 AM > >>>>To: Brian Rosen > >>>>Cc: 'Karl Heinz Wolf'; 'ECRIT' > >>>>Subject: "Derived" method > >>>> > >>>>Could you describe the semantic of the "Derived" method a bit more? > >>>> > >>>>Brian Rosen wrote: > >>>> > >>>>>I am sorry, I don't know how I missed these. > >>>>> > >>>>> > >>>>> > >>>>>>page 7: "The phone gets location from the DHCP server in civic > >>>>>>[RFC4676] or geo" -> should it be "and/or"? > >>>>>> > >>>>>> > >>>>>The text makes clear that multiple locations are problematic. > Multiple > >>>>>versions of the same location are problematic. I worry about systems > >>>>> > >>>>trying > >>>> > >>>>>to be helpful and giving you a measured location and also giving you > a > >>>>>derived (geo coded or reverse geo coded) version of the same location. > >>>>> > >>>>>This does raise yet another issue about this general subject; looking > at > >>>>> > >>>>the > >>>> > >>>>>list at: > >>>>>http://www.iana.org/assignments/method-tokens > >>>>>There is no method for "derived". So: > >>>>>I will add text to -framework covering this subject > >>>>>I will ask IANA to create a "Derived" method token > >>>>>I will add a requirement to -phonebcp that says if you get both and > one > >>>>> > >>>>is > >>>> > >>>>>derived, you must use the non-derived value. > >>>>> > >>>>>I've made the other changes in my source file and they will appear in > >>>>> > >>>>the > >>>> > >>>>>next version. > >>>>> > >>>>>Brian > >>>>> > >>>>> > >>>>>>-----Original Message----- > >>>>>>From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > >>>>>>Sent: Friday, July 11, 2008 6:00 AM > >>>>>>To: Brian Rosen > >>>>>>Cc: ECRIT > >>>>>>Subject: Re: [Ecrit] New versions of -framework and -phonebcp > >>>>>> > >>>>>>Brian, > >>>>>> > >>>>>>thank you for submitting the new versions of your documents. > >>>>>>However, I'm afraid you forgot my comments (except the LoSt > dialstring > >>>>>>"must"). > >>>>>>My old posting: > >>>>>>http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html > >>>>>>In your reply to this mail you agreed to these points. > >>>>>> > >>>>>>Karl Heinz > >>>>>> > >>>>>>On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen > >>>>>> > >>>>wrote: > >>>> > >>>>>>>These versions incorporate all last call comments except as I have > >>>>>>> > >>>>>>> > >>>>>>stated in > >>>>>> > >>>>>> > >>>>>>>prior email. > >>>>>>> > >>>>>>>The majority of changes have to do with: > >>>>>>>* More explicit text and references to -profile for multiple > locations > >>>>>>> > >>>>>>>* Requiring the return of dialstrings on LoST for sos service URNs. > >>>>>>> > >>>>>>>* Lots of typos and wording changes. > >>>>>>> > >>>>>>>I did end up adding a couple of requirements, and thus needed to > >>>>>>> > >>>>>>> > >>>>>>renumber > >>>>>> > >>>>>> > >>>>>>>the requirements, so diffs look bad. > >>>>>>> > >>>>>>>I ask commenters to look at the text to make sure I made all the > >>>>>>> > >>>>changes > >>>> > >>>>>>you > >>>>>> > >>>>>> > >>>>>>>requested (with the exceptions covered in the emails). > >>>>>>> > >>>>>>>Chairs can consider if they wish to hold a short 2nd WGLC. There > are > >>>>>>> > >>>>a > >>>> > >>>>>>>couple of substantive changes and added requirements, but not a > whole > >>>>>>> > >>>>>>> > >>>>>>lot > >>>>>> > >>>>>> > >>>>>>>text is modified in any but trivial ways. > >>>>>>> > >>>>>>>Brian > >>>>>>> > >>>>>>>_______________________________________________ > >>>>>>>Ecrit mailing 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 Jul 14 22:24:51 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 474523A6A10; Mon, 14 Jul 2008 22:24: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 08CAF3A6A10 for ; Mon, 14 Jul 2008 22:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 Rj7a0jq40Rjr for ; Mon, 14 Jul 2008 22:24:49 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id E633F3A6833 for ; Mon, 14 Jul 2008 22:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1216099516; x=1247635516; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20|References:=20=0D=0A=20|Date:=20Mon,=2014=20J ul=202008=2022:25:12=20-0700|To:=20"James=20M.=20Polk"=20 ,=20"ecrit@ietf.org"=20 ,=0D=0A=20=20=20=20=20=20=20=20"marc.linsner@cisco.com" =20,=0D=0A=20=20=20=20=20=20=20 =20"hannes.tschofenig@nsn.com"=20|From:=20Ted=20Hardie=20|Subject: =20Re:=20[Ecrit]=20Request=20for=20agenda=20time=20to=20d iscuss=20emergency=20call=20=20=0D=0A=20termination |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5338"=3B=20 a=3D"4713066"; bh=J4DI7TGQ527qhp09UMkj/IO4YDcJ8H/FTSus7vxnlmM=; b=dB7wkM+CbLWcZaNJo8FpXPpwbi/CJ7RTUJq4dTouFYniMSS7NYhlCNr3 TN7FAdLWYtCkyCuj8N8M6jiWyRN0PflqDxCLo4ffC6QIJQewpiKjgA6eR e0CZ4O+C2IIZBuEtr/HI3u0Yn7PNNCzDjo6QC5svIhQ6xr378idjoiMpW c=; X-IronPort-AV: E=McAfee;i="5200,2160,5338"; a="4713066" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jul 2008 22:25:16 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6F5PFgB029547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Jul 2008 22:25:15 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6F5PF40003075 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 Jul 2008 22:25:15 -0700 Received: from [76.126.61.44] (10.50.0.189) by qcmail1.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 14 Jul 2008 22:25:14 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: References: Date: Mon, 14 Jul 2008 22:25:12 -0700 To: "James M. Polk" , "ecrit@ietf.org" , "marc.linsner@cisco.com" , "hannes.tschofenig@nsn.com" From: Ted Hardie Subject: Re: [Ecrit] Request for agenda time to discuss emergency call termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 9:51 PM -0700 7/14/08, James M. Polk wrote: >At 04:16 PM 7/14/2008, Ted Hardie wrote: >>Howdy, >> I re-read the thread that discussed this with our colleagues >>at NENA, and I believe that the group would benefit from some in-person >>discussion of the issues. Could we have a 10-15 minute discussion on >>the agenda? > >I'd like to understand what about the thread you didn't understand , >or was otherwise unclear, as this topic pertains to the IETF? Part of it was simply what the protocol work, if any, there was in this requirement. If there is protocol work needed (for example, to update LoST's schema so that the rules applicable jurisdiction were sent down along with things like the dial strings for local emergency numbers), I'd like to understand the scope of that work and the anticipated timeline. On a less "IETF" and more personal level, I'd really like to understand how the behavior being proposed by some could be considered best practice (it's clearly current only in some jurisdictions for wireline phones and not current anywhere for wireless phones). As it stands, it appears to violate the principle of least surprise pretty fundamentally. My three-year old hits 911, and I hang up. It works in some parts of call set up and not others and in some jurisdictions and not others. This is good? >Within that context, and because there is no ID as a central point of >focus, what would be your topic outline? What changes are being proposed to -phonebcp and -framework? What are the consequences in follow-on protocol work of those changes (and, indeed of the current text, since that looks less clear to me now than it once did)? And, as above, what is the real best practice here? (that one would go first, in a rational discussion, but it's also non-terminating, so having the others go first with a "for choice a, the changes are XXX" structure is probably better. >Most the point raised was about US jurisdictions allowing caller >termination, and the counter was > > a) everything is always subject to local laws, and > b) is there a problem with the race condition between a > caller and a callee hanging up the phone being worth > chasing (when measured in fractions of a second)? Sorry for not being clear on the need before; thanks for asking before we got to Dublin. Ted > >Failing that, can we arrange a bar BoF on this? >> thanks, >> Ted >>_______________________________________________ >>Ecrit mailing 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 Jul 14 22:26:41 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C57813A6A10; Mon, 14 Jul 2008 22:26: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 67DEB3A6A27 for ; Mon, 14 Jul 2008 22:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uz2IG4Cqcg1M for ; Mon, 14 Jul 2008 22:26:39 -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 B6F253A6A10 for ; Mon, 14 Jul 2008 22:26:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,364,1212364800"; d="scan'208";a="126756179" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 15 Jul 2008 05:26:53 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6F5Qrd3012133; Mon, 14 Jul 2008 22:26:53 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m6F5QrQ7014392; Tue, 15 Jul 2008 05:26:53 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); Mon, 14 Jul 2008 22:26:53 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.84.1]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 22:26:52 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 15 Jul 2008 00:26:56 -0500 To: "'ECRIT'" From: "James M. Polk" Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 15 Jul 2008 05:26:52.0881 (UTC) FILETIME=[639DE410:01C8E63B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=630; t=1216099613; x=1216963613; c=relaxed/simple; s=sjdkim4002; 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:=20=22Derived=22=20or=20=22Converted=22=20method |Sender:=20; bh=hp8mEy0HzDiWrywy9QGMvITLUyNI7+q52XcfgI/RLkk=; b=RbU/RYhSuS0r5dlj7o+Sp6H+B9Ia9xu8flXLdAloOhrQoqH5+OsIMmBGna tiSFDEdIOF5ELXQ1u+2PqhckK15F+Vzx8ifrIy/3BsX9RmUJ6YV87gJBswPv EE5YX4Lej4; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Ecrit] "Derived" or "Converted" method X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Not meaning to throw a monkey-wrench into this discussion, but a synonym for derived is obtained, which mixes the meaning I understand this original method was to be suggested to be used for. Brian, correct me if I'm wrong, but you are trying to inform an LR that this PIDF-LO (or geopriv element) has been obtained from another piece of LI, or that is was converted into a new location format (i.e., geocoded)? If the latter, may I suggest using the word "Converted" or "Converted-from-geo" (plus "Converted-from-civic"), instead of "Derived", since that is exactly what your have done (as the LG). James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 15 06:15:37 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C88F3A69F1; Tue, 15 Jul 2008 06:15: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 316663A6A5F for ; Tue, 15 Jul 2008 06:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 wlWyPvZE2h3L for ; Tue, 15 Jul 2008 06:15:34 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 1EC4B3A69F1 for ; Tue, 15 Jul 2008 06:15:34 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KIkNp-0002hZ-Vt; Tue, 15 Jul 2008 08:15:58 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'James M. Polk'" , , , References: Date: Tue, 15 Jul 2008 09:15:57 -0400 Message-ID: <0db101c8e67c$ed5b83b0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjmOyUavHTZuzT/R5qcxxUQbzAfswAQH0zA 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] Request for agenda time to discuss emergency call termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 As I stated, in many jurisdictions, if your three year old hits 9-1-1 and you hang up, a cop will appear at your door inquiring if everything is all right. It's not true in all jurisdictions, but it is in some. There is always some period of time that elapses between the start of a call initiation and the trigger point for when the PSAP would actually get a notification of an "abandoned call", but it's usually pretty short. Certainly as soon as there is ringing in a current system, hanging up would be recorded as an abandoned call, and trigger a response in jurisdictions that do respond. The system used to work that way all of the time (that is, called party hold was implemented in the original 9-1-1 system in the U.S. and Canada). It got lost, much to the regret of many PSAP people. Getting it back would be a good thing for them. However, that is not universally agreed, and even where they want it, they need ways to have automatic termination on hang up. That was the basis for my suggestion that if hook state was signaled, then PSAPs could decide, without negotiation or UA implementation complexity, whether to hold the call or not. John Hearty is concerned about interim (before PSAPs are IP capable) systems, like the NENA "i2" systems. He has a point about gateways that has to be respected. I would definitely support an agenda slot, bar bof or any other venue to discuss the best way forward on this issue. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Ted Hardie > Sent: Tuesday, July 15, 2008 1:25 AM > To: James M. Polk; ecrit@ietf.org; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com > Subject: Re: [Ecrit] Request for agenda time to discuss emergency call > termination > > At 9:51 PM -0700 7/14/08, James M. Polk wrote: > >At 04:16 PM 7/14/2008, Ted Hardie wrote: > >>Howdy, > >> I re-read the thread that discussed this with our colleagues > >>at NENA, and I believe that the group would benefit from some in-person > >>discussion of the issues. Could we have a 10-15 minute discussion on > >>the agenda? > > > >I'd like to understand what about the thread you didn't understand , > >or was otherwise unclear, as this topic pertains to the IETF? > > Part of it was simply what the protocol work, if any, there was > in this requirement. If there is protocol work needed (for example, > to update LoST's schema so that the rules applicable jurisdiction > were sent down along with things like the dial strings for local > emergency numbers), I'd like to understand the scope of that > work and the anticipated timeline. > > On a less "IETF" and more personal level, I'd really like to understand > how the behavior being proposed by some could be considered > best practice (it's clearly current only in some jurisdictions for > wireline phones and not current anywhere for wireless phones). As > it stands, it appears to violate the principle of least surprise pretty > fundamentally. My three-year old hits 911, and I hang up. It works > in some parts of call set up and not others and in some jurisdictions > and not others. This is good? > > > >Within that context, and because there is no ID as a central point of > >focus, what would be your topic outline? > > What changes are being proposed to -phonebcp and -framework? > What are the consequences in follow-on protocol work of those > changes (and, indeed of the current text, since that looks less > clear to me now than it once did)? > And, as above, what is the real best practice here? (that one > would go first, in a rational discussion, but it's also non-terminating, > so having the others go first with a "for choice a, the changes are XXX" > structure is probably better. > > >Most the point raised was about US jurisdictions allowing caller > >termination, and the counter was > > > > a) everything is always subject to local laws, and > > b) is there a problem with the race condition between a > > caller and a callee hanging up the phone being worth > > chasing (when measured in fractions of a second)? > > Sorry for not being clear on the need before; thanks for asking > before we got to Dublin. > Ted > > > > > >Failing that, can we arrange a bar BoF on this? > >> thanks, > >> Ted > >>_______________________________________________ > >>Ecrit mailing 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 Jul 15 06:52:28 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09A9B3A6AE5; Tue, 15 Jul 2008 06:52: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 1A6993A6A07 for ; Tue, 15 Jul 2008 06:52:27 -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=[AWL=0.000, 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 ErscthbPKK2j for ; Tue, 15 Jul 2008 06:52:25 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id C28593A6AA5 for ; Tue, 15 Jul 2008 06:52:25 -0700 (PDT) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m6FDqapU014241; Tue, 15 Jul 2008 08:52:45 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 08:52:43 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 15:52:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Jul 2008 15:52:40 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800210E0CA@DEEXC1U01.de.lucent.com> In-Reply-To: <0db101c8e67c$ed5b83b0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Request for agenda time to discuss emergency calltermination Thread-Index: AcjmOyUavHTZuzT/R5qcxxUQbzAfswAQH0zAAAFY9DA= References: <0db101c8e67c$ed5b83b0$640fa8c0@cis.neustar.com> From: "DRAGE, Keith \(Keith\)" To: "Brian Rosen" , "Ted Hardie" , "James M. Polk" , , , X-OriginalArrivalTime: 15 Jul 2008 13:52:41.0468 (UTC) FILETIME=[0CC8C3C0:01C8E682] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [Ecrit] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 seem to be confusing two problems here. If all you need is the cop to appear at the door to enquire if everything is alright merely means that the original call details need to be recorded and delivered to the PSAP in some way. In fact all the information you need is likely to be in the INVITE request that has already been delivered to the PSAP, closely followed by your BYE request. If you desire to reestablish communication from the PSAP to the original calling UE, that may require a different solution. One solution in this case could just be emergency callback with compulsory draft-ietf-sip-answermode support on the phone, rather than trying to preserve the original session and prohibit BYE requests. Note that in those countries that allow privacy on emergency calls, I suspect that they would not need a solution to either problem anyway. I am concerned that we seem to be back in trying to impose the PSTN solution on a system where other solutions may be possible. Regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Tuesday, July 15, 2008 2:16 PM > To: 'Ted Hardie'; 'James M. Polk'; ecrit@ietf.org; > marc.linsner@cisco.com; hannes.tschofenig@nsn.com > Subject: Re: [Ecrit] Request for agenda time to discuss > emergency calltermination > > As I stated, in many jurisdictions, if your three year old > hits 9-1-1 and you hang up, a cop will appear at your door > inquiring if everything is all right. > > It's not true in all jurisdictions, but it is in some. There > is always some period of time that elapses between the start > of a call initiation and the trigger point for when the PSAP > would actually get a notification of an "abandoned call", but > it's usually pretty short. Certainly as soon as there is > ringing in a current system, hanging up would be recorded as > an abandoned call, and trigger a response in jurisdictions > that do respond. > > The system used to work that way all of the time (that is, > called party hold was implemented in the original 9-1-1 > system in the U.S. and Canada). It got lost, much to the > regret of many PSAP people. Getting it back would be a good > thing for them. However, that is not universally agreed, and > even where they want it, they need ways to have automatic > termination on hang up. > That was the basis for my suggestion that if hook state was > signaled, then PSAPs could decide, without negotiation or UA > implementation complexity, whether to hold the call or not. > > John Hearty is concerned about interim (before PSAPs are IP > capable) systems, like the NENA "i2" systems. He has a point > about gateways that has to be respected. > > I would definitely support an agenda slot, bar bof or any > other venue to discuss the best way forward on this issue. > > Brian > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Ted Hardie > > Sent: Tuesday, July 15, 2008 1:25 AM > > To: James M. Polk; ecrit@ietf.org; marc.linsner@cisco.com; > > hannes.tschofenig@nsn.com > > Subject: Re: [Ecrit] Request for agenda time to discuss > emergency call > > termination > > > > At 9:51 PM -0700 7/14/08, James M. Polk wrote: > > >At 04:16 PM 7/14/2008, Ted Hardie wrote: > > >>Howdy, > > >> I re-read the thread that discussed this with our > > >>colleagues at NENA, and I believe that the group would > benefit from > > >>some in-person discussion of the issues. Could we have a 10-15 > > >>minute discussion on the agenda? > > > > > >I'd like to understand what about the thread you didn't > understand , > > >or was otherwise unclear, as this topic pertains to the IETF? > > > > Part of it was simply what the protocol work, if any, there was in > > this requirement. If there is protocol work needed (for > example, to > > update LoST's schema so that the rules applicable jurisdiction were > > sent down along with things like the dial strings for local > emergency > > numbers), I'd like to understand the scope of that work and the > > anticipated timeline. > > > > On a less "IETF" and more personal level, I'd really like to > > understand how the behavior being proposed by some could be > considered > > best practice (it's clearly current only in some jurisdictions for > > wireline phones and not current anywhere for wireless > phones). As it > > stands, it appears to violate the principle of least > surprise pretty > > fundamentally. My three-year old hits 911, and I hang up. > It works > > in some parts of call set up and not others and in some > jurisdictions > > and not others. This is good? > > > > > > >Within that context, and because there is no ID as a > central point of > > >focus, what would be your topic outline? > > > > What changes are being proposed to -phonebcp and -framework? > > What are the consequences in follow-on protocol work of > those changes > > (and, indeed of the current text, since that looks less clear to me > > now than it once did)? > > And, as above, what is the real best practice here? (that > one would > > go first, in a rational discussion, but it's also > non-terminating, so > > having the others go first with a "for choice a, the > changes are XXX" > > structure is probably better. > > > > >Most the point raised was about US jurisdictions allowing caller > > >termination, and the counter was > > > > > > a) everything is always subject to local laws, and > > > b) is there a problem with the race condition between a > > > caller and a callee hanging up the phone being worth > > > chasing (when measured in fractions of a second)? > > > > Sorry for not being clear on the need before; thanks for > asking before > > we got to Dublin. > > Ted > > > > > > > > > >Failing that, can we arrange a bar BoF on this? > > >> thanks, > > >> Ted > > >>_______________________________________________ > > >>Ecrit mailing 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 Jul 15 07:51:14 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 423D93A692E; Tue, 15 Jul 2008 07:51: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 E36BE3A68E3 for ; Tue, 15 Jul 2008 07:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 tJpYxNDsnnJP for ; Tue, 15 Jul 2008 07:51:11 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 8FF8B3A67FB for ; Tue, 15 Jul 2008 07:51:11 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KIlsK-0006WH-8a; Tue, 15 Jul 2008 09:51:32 -0500 From: "Brian Rosen" To: "'DRAGE, Keith \(Keith\)'" , "'Ted Hardie'" , "'James M. Polk'" , , , References: <0db101c8e67c$ed5b83b0$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E0CA@DEEXC1U01.de.lucent.com> Date: Tue, 15 Jul 2008 10:51:33 -0400 Message-ID: <0ddc01c8e68a$47c22400$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjmOyUavHTZuzT/R5qcxxUQbzAfswAQH0zAAAFY9DAAAgAfAA== In-Reply-To: <5D1A7985295922448D5550C94DE291800210E0CA@DEEXC1U01.de.lucent.com> 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] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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, the goal of CPH on an abandoned call is to AVOID a response. If you don't hang up, then the call can be answered, the call taker can determine that no response is needed. If a response is needed, the right response can be dispatched. Abandoned calls are problematic: is there a problem or not? What responders are appropriate? Alternatively, after the call is completed established, CPH can be used to make sure the call taker gets all the information needed. You are correct that we jumped to solutions before defining the problem(s). We should fix that. I'll work on requirements. It's certainly possible to use an auto call back in lieu of CPH on an existing call, the result is roughly the same thing if: *Contact really does get you back to the same device (which -phonebcp requires) * The mechanics of the device work the right way (that is, it behaves just like the call was never terminated) Brian > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Tuesday, July 15, 2008 9:53 AM > To: Brian Rosen; Ted Hardie; James M. Polk; ecrit@ietf.org; > marc.linsner@cisco.com; hannes.tschofenig@nsn.com > Subject: RE: [Ecrit] Request for agenda time to discuss emergency > calltermination > > We seem to be confusing two problems here. > > If all you need is the cop to appear at the door to enquire if > everything is alright merely means that the original call details need > to be recorded and delivered to the PSAP in some way. In fact all the > information you need is likely to be in the INVITE request that has > already been delivered to the PSAP, closely followed by your BYE > request. > > If you desire to reestablish communication from the PSAP to the original > calling UE, that may require a different solution. One solution in this > case could just be emergency callback with compulsory > draft-ietf-sip-answermode support on the phone, rather than trying to > preserve the original session and prohibit BYE requests. > > Note that in those countries that allow privacy on emergency calls, I > suspect that they would not need a solution to either problem anyway. > > I am concerned that we seem to be back in trying to impose the PSTN > solution on a system where other solutions may be possible. > > Regards > > Keith > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of Brian Rosen > > Sent: Tuesday, July 15, 2008 2:16 PM > > To: 'Ted Hardie'; 'James M. Polk'; ecrit@ietf.org; > > marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > Subject: Re: [Ecrit] Request for agenda time to discuss > > emergency calltermination > > > > As I stated, in many jurisdictions, if your three year old > > hits 9-1-1 and you hang up, a cop will appear at your door > > inquiring if everything is all right. > > > > It's not true in all jurisdictions, but it is in some. There > > is always some period of time that elapses between the start > > of a call initiation and the trigger point for when the PSAP > > would actually get a notification of an "abandoned call", but > > it's usually pretty short. Certainly as soon as there is > > ringing in a current system, hanging up would be recorded as > > an abandoned call, and trigger a response in jurisdictions > > that do respond. > > > > The system used to work that way all of the time (that is, > > called party hold was implemented in the original 9-1-1 > > system in the U.S. and Canada). It got lost, much to the > > regret of many PSAP people. Getting it back would be a good > > thing for them. However, that is not universally agreed, and > > even where they want it, they need ways to have automatic > > termination on hang up. > > That was the basis for my suggestion that if hook state was > > signaled, then PSAPs could decide, without negotiation or UA > > implementation complexity, whether to hold the call or not. > > > > John Hearty is concerned about interim (before PSAPs are IP > > capable) systems, like the NENA "i2" systems. He has a point > > about gateways that has to be respected. > > > > I would definitely support an agenda slot, bar bof or any > > other venue to discuss the best way forward on this issue. > > > > Brian > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Ted Hardie > > > Sent: Tuesday, July 15, 2008 1:25 AM > > > To: James M. Polk; ecrit@ietf.org; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com > > > Subject: Re: [Ecrit] Request for agenda time to discuss > > emergency call > > > termination > > > > > > At 9:51 PM -0700 7/14/08, James M. Polk wrote: > > > >At 04:16 PM 7/14/2008, Ted Hardie wrote: > > > >>Howdy, > > > >> I re-read the thread that discussed this with our > > > >>colleagues at NENA, and I believe that the group would > > benefit from > > > >>some in-person discussion of the issues. Could we have a 10-15 > > > >>minute discussion on the agenda? > > > > > > > >I'd like to understand what about the thread you didn't > > understand , > > > >or was otherwise unclear, as this topic pertains to the IETF? > > > > > > Part of it was simply what the protocol work, if any, there was in > > > this requirement. If there is protocol work needed (for > > example, to > > > update LoST's schema so that the rules applicable jurisdiction were > > > sent down along with things like the dial strings for local > > emergency > > > numbers), I'd like to understand the scope of that work and the > > > anticipated timeline. > > > > > > On a less "IETF" and more personal level, I'd really like to > > > understand how the behavior being proposed by some could be > > considered > > > best practice (it's clearly current only in some jurisdictions for > > > wireline phones and not current anywhere for wireless > > phones). As it > > > stands, it appears to violate the principle of least > > surprise pretty > > > fundamentally. My three-year old hits 911, and I hang up. > > It works > > > in some parts of call set up and not others and in some > > jurisdictions > > > and not others. This is good? > > > > > > > > > >Within that context, and because there is no ID as a > > central point of > > > >focus, what would be your topic outline? > > > > > > What changes are being proposed to -phonebcp and -framework? > > > What are the consequences in follow-on protocol work of > > those changes > > > (and, indeed of the current text, since that looks less clear to me > > > now than it once did)? > > > And, as above, what is the real best practice here? (that > > one would > > > go first, in a rational discussion, but it's also > > non-terminating, so > > > having the others go first with a "for choice a, the > > changes are XXX" > > > structure is probably better. > > > > > > >Most the point raised was about US jurisdictions allowing caller > > > >termination, and the counter was > > > > > > > > a) everything is always subject to local laws, and > > > > b) is there a problem with the race condition between a > > > > caller and a callee hanging up the phone being worth > > > > chasing (when measured in fractions of a second)? > > > > > > Sorry for not being clear on the need before; thanks for > > asking before > > > we got to Dublin. > > > Ted > > > > > > > > > > > > > >Failing that, can we arrange a bar BoF on this? > > > >> thanks, > > > >> Ted > > > >>_______________________________________________ > > > >>Ecrit mailing 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 Jul 15 09:23:29 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3355C3A67EC; Tue, 15 Jul 2008 09:23: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 4DF653A6928 for ; Tue, 15 Jul 2008 09:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.69 X-Spam-Level: X-Spam-Status: No, score=-102.69 tagged_above=-999 required=5 tests=[AWL=-0.091, 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 dFWcshX+Aaw6 for ; Tue, 15 Jul 2008 09:23:26 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id CA0183A68CC for ; Tue, 15 Jul 2008 09:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1216139035; x=1247675035; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<0ddc01c8e68a$47c22400$64 0fa8c0@cis.neustar.com>|References:=20=0D=0A=20<0db101c8e67c$ed5b83b0$640fa8c0@cis.neus tar.com>=0D=0A=20<5D1A7985295922448D5550C94DE291800210E0C A@DEEXC1U01.de.lucent.com>=0D=0A=20<0ddc01c8e68a$47c22400 $640fa8c0@cis.neustar.com>|Date:=20Tue,=2015=20Jul=202008 =2009:23:50=20-0700|To:=20Brian=20Rosen=20,=0D=0A=20=20=20=20=20=20=20=20"'DRAGE,=20Keith=20(Ke ith)'"=0D=0A=09,=0D=0A=20=20=20 =20=20=20=20=20"'James=20M.=20Polk'"=20 ,=0D=0A=20=20=20=20=20=20=20=20"ecrit@ietf.org"=20,=0D=0A=20=20=20=20=20=20=20=20"marc.linsner@cis co.com"=0D=0A=09,=0D=0A=20=20=20 =20=20=20=20=20"hannes.tschofenig@nsn.com"=0D=0A=09|From:=20Ted=20Hardie=20|Subject:=20RE:=20[Ecrit]=20Request=20for=20agen da=20time=20to=20discuss=20emergency=20=0D=0A=20calltermi nation|Content-Type:=20text/plain=3B=20charset=3D"us-asci i"|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5338"=3B =20a=3D"4554851"; bh=oVTBWB/SgR6L73vYhl2Q54bmZRVTK91YLC9m41qepG4=; b=h8USrE5kU8jTJCz+LRJBfFRrWWdlqxig8UsJjWFwfNLZPCSiR1jG1RPa qnF/Rel4neFO5SOdf2fPkRhLvX97cF18EMtzTukDJW1taL/aXP6Y59uXO 14bT4kcHCKR/b0V39IH7JU+aI32Ki0BDIJjly/AQy0avXNCQ0upZvcJSS 8=; X-IronPort-AV: E=McAfee;i="5200,2160,5338"; a="4554851" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Jul 2008 09:23:54 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6FGNrCe000689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Jul 2008 09:23:54 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6FGNrOW000941 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 15 Jul 2008 09:23:53 -0700 (PDT) Received: from [129.46.226.27] (129.46.226.27) by qcmail1.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 15 Jul 2008 09:23:52 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <0ddc01c8e68a$47c22400$640fa8c0@cis.neustar.com> References: <0db101c8e67c$ed5b83b0$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E0CA@DEEXC1U01.de.lucent.com> <0ddc01c8e68a$47c22400$640fa8c0@cis.neustar.com> Date: Tue, 15 Jul 2008 09:23:50 -0700 To: Brian Rosen , "'DRAGE, Keith (Keith)'" , "'James M. Polk'" , "ecrit@ietf.org" , "marc.linsner@cisco.com" , "hannes.tschofenig@nsn.com" From: Ted Hardie Subject: Re: [Ecrit] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 7:51 AM -0700 7/15/08, Brian Rosen wrote: >No, the goal of CPH on an abandoned call is to AVOID a response. If you >don't hang up, then the call can be answered, the call taker can determine >that no response is needed. If a response is needed, the right response can >be dispatched. Abandoned calls are problematic: is there a problem or not? >What responders are appropriate? And one thing that confuses me here is that two different classes of abandoned calls seemed to be treated differently. Canceled calls and calls terminated by BYE seem to be handled differently; from the user perspective, these are exactly the same ("I pressed END on the phone"). They are different only to the internal hops and geeks like us. >Alternatively, after the call is completed established, CPH can be used to >make sure the call taker gets all the information needed. >You are correct that we jumped to solutions before defining the problem(s). >We should fix that. I'll work on requirements. Please be very clear in the requirements on what the user behavior aspects are, as well as the PSAP desires. Given that the PSAP desires here evidently vary considerably across jurisdictions, I am personally inclined to try to make sure we don't violate the principle of least surprise over-much to accommodate the variation. And if there is real protocol work to be done, some scope discussion in the slot/bar bof/whatever would be really, really nice. >It's certainly possible to use an auto call back in lieu of CPH on an >existing call, the result is roughly the same thing if: >*Contact really does get you back to the same device (which -phonebcp >requires) > >* The mechanics of the device work the right way (that is, it behaves just >like the call was never terminated) This second seems like a really odd requirement. If I call 911 and abandon the call, and I get a call back with an actual ring, why is that not sufficient? Why would you want the system to treat it as if the call was not terminated? As far as I can tell, that means the call taker is there if I do whatever my equivalent is for "pick up the handset again" but requires some other mechanism (howler tone?) to signal me to pick it up. I understand that it used to do that, but that was an artifact of how circuits work. It is a method to meet the underlying requirement (PSAP reconnect to callers who have abandoned calls) rather than a requirements in and of itself. regards, Ted >Brian > >> -----Original Message----- >> From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >> Sent: Tuesday, July 15, 2008 9:53 AM >> To: Brian Rosen; Ted Hardie; James M. Polk; ecrit@ietf.org; >> marc.linsner@cisco.com; hannes.tschofenig@nsn.com >> Subject: RE: [Ecrit] Request for agenda time to discuss emergency >> calltermination >> >> We seem to be confusing two problems here. >> >> If all you need is the cop to appear at the door to enquire if >> everything is alright merely means that the original call details need >> to be recorded and delivered to the PSAP in some way. In fact all the >> information you need is likely to be in the INVITE request that has >> already been delivered to the PSAP, closely followed by your BYE >> request. >> >> If you desire to reestablish communication from the PSAP to the original >> calling UE, that may require a different solution. One solution in this >> case could just be emergency callback with compulsory >> draft-ietf-sip-answermode support on the phone, rather than trying to >> preserve the original session and prohibit BYE requests. >> >> Note that in those countries that allow privacy on emergency calls, I >> suspect that they would not need a solution to either problem anyway. > > >> I am concerned that we seem to be back in trying to impose the PSTN >> solution on a system where other solutions may be possible. >> >> Regards >> >> Keith >> >> > -----Original Message----- >> > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> > On Behalf Of Brian Rosen >> > Sent: Tuesday, July 15, 2008 2:16 PM >> > To: 'Ted Hardie'; 'James M. Polk'; ecrit@ietf.org; >> > marc.linsner@cisco.com; hannes.tschofenig@nsn.com >> > Subject: Re: [Ecrit] Request for agenda time to discuss >> > emergency calltermination >> > >> > As I stated, in many jurisdictions, if your three year old >> > hits 9-1-1 and you hang up, a cop will appear at your door >> > inquiring if everything is all right. >> > >> > It's not true in all jurisdictions, but it is in some. There >> > is always some period of time that elapses between the start >> > of a call initiation and the trigger point for when the PSAP >> > would actually get a notification of an "abandoned call", but >> > it's usually pretty short. Certainly as soon as there is >> > ringing in a current system, hanging up would be recorded as >> > an abandoned call, and trigger a response in jurisdictions >> > that do respond. >> > >> > The system used to work that way all of the time (that is, >> > called party hold was implemented in the original 9-1-1 >> > system in the U.S. and Canada). It got lost, much to the >> > regret of many PSAP people. Getting it back would be a good >> > thing for them. However, that is not universally agreed, and >> > even where they want it, they need ways to have automatic >> > termination on hang up. >> > That was the basis for my suggestion that if hook state was >> > signaled, then PSAPs could decide, without negotiation or UA >> > implementation complexity, whether to hold the call or not. >> > >> > John Hearty is concerned about interim (before PSAPs are IP >> > capable) systems, like the NENA "i2" systems. He has a point >> > about gateways that has to be respected. >> > >> > I would definitely support an agenda slot, bar bof or any >> > other venue to discuss the best way forward on this issue. >> > >> > Brian >> > >> > > -----Original Message----- >> > > From: ecrit-bounces@ietf.org >> > [mailto:ecrit-bounces@ietf.org] On Behalf >> > > Of Ted Hardie >> > > Sent: Tuesday, July 15, 2008 1:25 AM >> > > To: James M. Polk; ecrit@ietf.org; marc.linsner@cisco.com; >> > > hannes.tschofenig@nsn.com >> > > Subject: Re: [Ecrit] Request for agenda time to discuss >> > emergency call >> > > termination >> > > >> > > At 9:51 PM -0700 7/14/08, James M. Polk wrote: >> > > >At 04:16 PM 7/14/2008, Ted Hardie wrote: >> > > >>Howdy, >> > > >> I re-read the thread that discussed this with our >> > > >>colleagues at NENA, and I believe that the group would >> > benefit from >> > > >>some in-person discussion of the issues. Could we have a 10-15 >> > > >>minute discussion on the agenda? >> > > > >> > > >I'd like to understand what about the thread you didn't >> > understand , >> > > >or was otherwise unclear, as this topic pertains to the IETF? >> > > >> > > Part of it was simply what the protocol work, if any, there was in >> > > this requirement. If there is protocol work needed (for >> > example, to >> > > update LoST's schema so that the rules applicable jurisdiction were >> > > sent down along with things like the dial strings for local >> > emergency >> > > numbers), I'd like to understand the scope of that work and the >> > > anticipated timeline. >> > > >> > > On a less "IETF" and more personal level, I'd really like to >> > > understand how the behavior being proposed by some could be >> > considered >> > > best practice (it's clearly current only in some jurisdictions for >> > > wireline phones and not current anywhere for wireless >> > phones). As it >> > > stands, it appears to violate the principle of least >> > surprise pretty >> > > fundamentally. My three-year old hits 911, and I hang up. >> > It works >> > > in some parts of call set up and not others and in some >> > jurisdictions >> > > and not others. This is good? >> > > >> > > >> > > >Within that context, and because there is no ID as a >> > central point of > > > > >focus, what would be your topic outline? >> > > >> > > What changes are being proposed to -phonebcp and -framework? >> > > What are the consequences in follow-on protocol work of >> > those changes >> > > (and, indeed of the current text, since that looks less clear to me >> > > now than it once did)? >> > > And, as above, what is the real best practice here? (that >> > one would >> > > go first, in a rational discussion, but it's also >> > non-terminating, so >> > > having the others go first with a "for choice a, the >> > changes are XXX" >> > > structure is probably better. >> > > >> > > >Most the point raised was about US jurisdictions allowing caller >> > > >termination, and the counter was >> > > > >> > > > a) everything is always subject to local laws, and >> > > > b) is there a problem with the race condition between a >> > > > caller and a callee hanging up the phone being worth >> > > > chasing (when measured in fractions of a second)? >> > > >> > > Sorry for not being clear on the need before; thanks for >> > asking before >> > > we got to Dublin. >> > > Ted >> > > >> > > >> > > >> > > > >Failing that, can we arrange a bar BoF on this? >> > > >> thanks, >> > > >> Ted >> > > >>_______________________________________________ >> > > >>Ecrit mailing 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 Jul 15 09:40:18 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35EB328C2A9; Tue, 15 Jul 2008 09:40: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 06F0728C2A9 for ; Tue, 15 Jul 2008 09:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 5XN09ZsaRFBp for ; Tue, 15 Jul 2008 09:40:16 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 0C10628C19D for ; Tue, 15 Jul 2008 09:40:16 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KInZt-0003RF-Rq; Tue, 15 Jul 2008 11:40:38 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'DRAGE, Keith \(Keith\)'" , "'James M. Polk'" , , , References: <0db101c8e67c$ed5b83b0$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E0CA@DEEXC1U01.de.lucent.com> <0ddc01c8e68a$47c22400$640fa8c0@cis.neustar.com> Date: Tue, 15 Jul 2008 12:40:39 -0400 Message-ID: <0e3701c8e699$85d54330$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjmlzQu2NA8h/UXSOeKELw6OR9FCAAAR32w 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] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 > And one thing that confuses me here is that two different classes of > abandoned calls seemed to be treated differently. Canceled calls > and calls terminated by BYE seem to be handled differently; > from the user perspective, these are exactly the same ("I pressed > END on the phone"). They are different only to the internal hops > and geeks like us. Agree that they shouldn't look different to the user. I think the only difference is "before dialog established vs after dialog established" to us geeks. > >We should fix that. I'll work on requirements. > > Please be very clear in the requirements on what the user behavior > aspects are, as well as the PSAP desires. Given that the PSAP desires > here evidently vary considerably across jurisdictions, I am personally > inclined to try to make sure we don't violate the principle of least > surprise over-much to accommodate the variation. And if there > is real protocol work to be done, some scope discussion in > the slot/bar bof/whatever would be really, really nice. Agree, recognizing that in reality, there are some conflicts (your example: you want to hang up, the PSAP wants you not to hang up). > > >It's certainly possible to use an auto call back in lieu of CPH on an > >existing call, the result is roughly the same thing if: > >*Contact really does get you back to the same device (which -phonebcp > >requires) > > > >* The mechanics of the device work the right way (that is, it behaves > just > >like the call was never terminated) > > This second seems like a really odd requirement. If I call 911 and > abandon the call, and I get a call back with an actual ring, why is > that not sufficient? Why would you want the system to treat it as if the > call was > not terminated? As far as I can tell, that means the call taker is there > if I do > whatever my equivalent is for "pick up the handset again" but requires > some > other mechanism (howler tone?) to signal me to pick it up. I understand > that it used to do that, but that was an artifact of how circuits work. > It is a method to meet the underlying requirement (PSAP reconnect > to callers who have abandoned calls) rather than a requirements in > and of itself. First of all, there is a difference between "on hook" and "handset put down, still off hook". Howler tone is used for the latter, and doesn't need any standardization really. The call remains in the same state. There is a great deal of variation on UI for devices that can be used to call for help. I'd like the device to require as few steps as possible to reconnect the caller. If you have a handset with no base, and "Send" and "Answer" buttons and nothing else, we have no choice, the phone rings and you have to press "Answer". However, if there was a hook switch, then we want immediate reconnect. We have to craft language that provides the right BCP advice. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 15 10:27:29 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDAF83A6A81; Tue, 15 Jul 2008 10:27: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 7B95C3A6A37 for ; Tue, 15 Jul 2008 10:27:28 -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=[AWL=0.000, 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 XqzYDD862r-o for ; Tue, 15 Jul 2008 10:27:27 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 400463A68E1 for ; Tue, 15 Jul 2008 10:27:26 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m6FHRJSS022604; Tue, 15 Jul 2008 12:27:45 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 12:27:18 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 19:27:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Jul 2008 19:27:14 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800210E16C@DEEXC1U01.de.lucent.com> In-Reply-To: <0e3701c8e699$85d54330$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Request for agenda time to discuss emergency calltermination Thread-Index: AcjmlzQu2NA8h/UXSOeKELw6OR9FCAAAR32wAAE5voA= References: <0db101c8e67c$ed5b83b0$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E0CA@DEEXC1U01.de.lucent.com> <0ddc01c8e68a$47c22400$640fa8c0@cis.neustar.com> <0e3701c8e699$85d54330$640fa8c0@cis.neustar.com> From: "DRAGE, Keith \(Keith\)" To: "Brian Rosen" , "Ted Hardie" , , X-OriginalArrivalTime: 15 Jul 2008 17:27:16.0100 (UTC) FILETIME=[06A9B440:01C8E6A0] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [Ecrit] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 must admit I am sitting on the same side of the fence as Ted here. I would add some further considerations into the discussion: 1) We obviously are not worrying about compatibility with old SIP implementations here, as I guess pretty much every existing SIP phone with a clear key will send a BYE as a result of hitting that key. Therefore asking a phone not to send BYE is something that phones will need to build in before it exists out there. So any solution to the requirements, when we have them, can presumably require new implementation in the phone before it works. 2) If there are requirements to solve, then presumably they will have to be implemented on all SIP phones, even if the networks that need this requirement are in a minority. It is impossible to roll out phones with the capability only to areas that need the capability. Therefore introduction of the extra capability in the phone should not have an adverse impact on networks (access or core) or on PSAPs that do not need the capability. 3) I suspect a solution that prevents BYE being sent only wins over other solutions to reestablish the call if you are able to preserve both signalling and media resources for the entire path between UA and PSAP by doing so. As the cost of preserving radio resources is high in respect of the number of times such a capability might be used, I suspect this is the reason why mobile networks do not do it. But there are also emergency call architectures where reserving resources in the network for such calls also have an adverse effect. In the UK network, with geographically centralised PSAPs, emergency calls are not routed until the resources are available to answer the call. If you are reserving resources on these paths until the PSAP has determined whether a further action is required on a discontinued call, then that means that you are potentially not routeing other emergency calls to the PSAPs that should still be serviced. Does the routeing and allocation of resources to other potential emergency calls take priority over the reservation of resources in case the PSAP wishes to return to a discontinued call? A simple call in the old PSTN with localised PSAPs, but a much more difficult question in the modern telecommunications architectures. 4) Note that the transition from PSTN to ISDN meant that most networks because 1st party release, rather than last party release or any other form of release. Essentially, this is also how SIP works in terms of the media resources. This means that any requirements for emergency call in this respect to preserve network resources mean that the network entities also need to identify emergency calls as distinct from other types of calls, and do this securely, so that the capability cannot be used fraudulently. But I do support that we identify the precise requirements, and understand those first. Regards Keith > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, July 15, 2008 5:41 PM > To: 'Ted Hardie'; DRAGE, Keith (Keith); 'James M. Polk'; > ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com > Subject: RE: [Ecrit] Request for agenda time to discuss > emergency calltermination > > > And one thing that confuses me here is that two different > classes of > > abandoned calls seemed to be treated differently. Canceled > calls and > > calls terminated by BYE seem to be handled differently; > from the user > > perspective, these are exactly the same ("I pressed END on the > > phone"). They are different only to the internal hops and > geeks like > > us. > Agree that they shouldn't look different to the user. > I think the only difference is "before dialog established vs > after dialog established" to us geeks. > > > >We should fix that. I'll work on requirements. > > > > Please be very clear in the requirements on what the user behavior > > aspects are, as well as the PSAP desires. Given that the > PSAP desires > > here evidently vary considerably across jurisdictions, I am > personally > > inclined to try to make sure we don't violate the principle of least > > surprise over-much to accommodate the variation. And if there > > is real protocol work to be done, some scope discussion in the > > slot/bar bof/whatever would be really, really nice. > Agree, recognizing that in reality, there are some conflicts > (your example: > you want to hang up, the PSAP wants you not to hang up). > > > > > >It's certainly possible to use an auto call back in lieu > of CPH on an > > >existing call, the result is roughly the same thing if: > > >*Contact really does get you back to the same device > (which -phonebcp > > >requires) > > > > > >* The mechanics of the device work the right way (that is, > it behaves > > just > > >like the call was never terminated) > > > > This second seems like a really odd requirement. If I call 911 and > > abandon the call, and I get a call back with an actual ring, why is > > that not sufficient? Why would you want the system to > treat it as if > > the call was not terminated? As far as I can tell, that means the > > call taker is there if I do whatever my equivalent is for > "pick up the > > handset again" but requires some other mechanism (howler tone?) to > > signal me to pick it up. I understand that it used to do that, but > > that was an artifact of how circuits work. > > It is a method to meet the underlying requirement (PSAP > reconnect to > > callers who have abandoned calls) rather than a > requirements in and of > > itself. > First of all, there is a difference between "on hook" and > "handset put down, still off hook". Howler tone is used for > the latter, and doesn't need any standardization really. The > call remains in the same state. > > There is a great deal of variation on UI for devices that can > be used to call for help. I'd like the device to require as > few steps as possible to reconnect the caller. If you have a > handset with no base, and "Send" and "Answer" buttons and > nothing else, we have no choice, the phone rings and you have > to press "Answer". However, if there was a hook switch, then > we want immediate reconnect. We have to craft language that > provides the right BCP advice. > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 15 10:48:26 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EFF828C16B; Tue, 15 Jul 2008 10:48: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 97E7E28C155 for ; Tue, 15 Jul 2008 10:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 8wkfg5pwgWK1 for ; Tue, 15 Jul 2008 10:48:23 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3A71428C16B for ; Tue, 15 Jul 2008 10:48:23 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2008 17:48:50 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp007) with SMTP; 15 Jul 2008 19:48:50 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Aojt+SSAAdqhdv01WKbmPhRnmwxlKL3JSVYijxJ 57L3Z0CbhF4v23 Message-ID: <487CE303.6090601@gmx.net> Date: Tue, 15 Jul 2008 20:48:51 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: 'ECRIT' X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 Subject: [Ecrit] "Derived" method: What is the conclusion? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I hear a couple of folks saying that the field probably isn't going to be a curtial piece of information to the LR. It does not harm to set it. Following strictly what RFC 4119 says it is used to describe how location information was determined and obtained. In some cases pointing to DHCP or LLDP-MED might be the only thing the end host knows. Brian can also add a "derived" token to the registry. Does not hurt. Maybe someone who is going to work on location based applications is going to decide what additional decisions they are able to make based on the availability of this information. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 15 10:59:11 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73A963A68E1; Tue, 15 Jul 2008 10:59: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 EA6873A68E1 for ; Tue, 15 Jul 2008 10:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 nub6NdHBqLKs for ; Tue, 15 Jul 2008 10:59:10 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id D77083A67D4 for ; Tue, 15 Jul 2008 10:59:09 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KIooF-0006sn-1t; Tue, 15 Jul 2008 12:59:31 -0500 From: "Brian Rosen" To: "'DRAGE, Keith \(Keith\)'" , "'Ted Hardie'" , , References: <0db101c8e67c$ed5b83b0$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E0CA@DEEXC1U01.de.lucent.com> <0ddc01c8e68a$47c22400$640fa8c0@cis.neustar.com> <0e3701c8e699$85d54330$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E16C@DEEXC1U01.de.lucent.com> Date: Tue, 15 Jul 2008 13:59:33 -0400 Message-ID: <0e4401c8e6a4$8b7a6b20$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjmlzQu2NA8h/UXSOeKELw6OR9FCAAAR32wAAE5voAAATai8A== In-Reply-To: <5D1A7985295922448D5550C94DE291800210E16C@DEEXC1U01.de.lucent.com> 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] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 > 1) We obviously are not worrying about compatibility with old SIP > implementations here, as I guess pretty much every existing SIP phone > with a clear key will send a BYE as a result of hitting that key. > Therefore asking a phone not to send BYE is something that phones will > need to build in before it exists out there. So any solution to the > requirements, when we have them, can presumably require new > implementation in the phone before it works. Yes > > 2) If there are requirements to solve, then presumably they will > have to be implemented on all SIP phones, even if the networks that need > this requirement are in a minority. It is impossible to roll out phones > with the capability only to areas that need the capability. Therefore > introduction of the extra capability in the phone should not have an > adverse impact on networks (access or core) or on PSAPs that do not need > the capability. Yes > > 3) I suspect a solution that prevents BYE being sent only wins over > other solutions to reestablish the call if you are able to preserve both > signalling and media resources for the entire path between UA and PSAP > by doing so. As the cost of preserving radio resources is high in > respect of the number of times such a capability might be used, I > suspect this is the reason why mobile networks do not do it. Nah, they don't do it because they didn't have to discuss it with the emergency guys before they designed the networks. It's less resources in most circumstances to keep a call up than to tear it down and re-establish it. The case here is that one end is trying to end the call and the other end is trying to keep the call up. The best way to solve that is leave the call up until they figure it out. > But there > are also emergency call architectures where reserving resources in the > network for such calls also have an adverse effect. In the UK network, > with geographically centralised PSAPs, emergency calls are not routed > until the resources are available to answer the call. If you are > reserving resources on these paths until the PSAP has determined whether > a further action is required on a discontinued call, then that means > that you are potentially not routeing other emergency calls to the PSAPs > that should still be serviced. Does the routeing and allocation of > resources to other potential emergency calls take priority over the > reservation of resources in case the PSAP wishes to return to a > discontinued call? A simple call in the old PSTN with localised PSAPs, > but a much more difficult question in the modern telecommunications > architectures. First of all, the goals of the next gen emergency calling networks is to be able to answer ALL calls, even in a mass calling event. I can get into why and how we do this, but that is the design goal; answer ALL calls. Secondly, all of the solutions we are discussing have minimal impact on how many messages are sent. We're not significantly increasing or decreasing the number of messages. A PSAP decides whether it will answer a new call or call back an old caller. That decision is solely in its purview. As with most SIP networks, you congest on media before you congest on signaling, but there are always circumstances where signaling congestion occurs. No magic is expected. As in nearly every call center with a well designed network, you nearly always run out of people before you run out of signaling or media capacity. Disasters could change that of course. On the other hand, call taker resources are the least expensive resource you have; better for the call taker to determine what the right thing to do is rather than blindly dispatch. > 4) Note that the transition from PSTN to ISDN meant that most > networks because 1st party release, rather than last party release or > any other form of release. Essentially, this is also how SIP works in > terms of the media resources. This means that any requirements for > emergency call in this respect to preserve network resources mean that > the network entities also need to identify emergency calls as distinct > from other types of calls, and do this securely, so that the capability > cannot be used fraudulently. This is why "don't send BYE" is a good solution; you aren't releasing media resources. Auto call back is problematic for this reason. There is the orthogonal issue of identifying call backs and treating them specially. So far, we haven't done that, but its useful. None of the proposed solutions depend on that, and none of them are subject to abuse. An emergency call should be identified by the UA, and it then knows whether to suppress BYE. I suspect if we keep that rule, we probably do need words in -framework and -phonebcp that deal with the currently allowed circumstance that a proxy detects the emergency dialstring. I suspect that if the UA doesn't detect the dial string, it doesn't suppress BYE. Otherwise, that creates an attack vector. > > But I do support that we identify the precise requirements, and > understand those first. Yah. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 15 11:17:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9A7D3A6AFD; Tue, 15 Jul 2008 11:17: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 3CC0C3A6B14 for ; Tue, 15 Jul 2008 11:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.682 X-Spam-Level: X-Spam-Status: No, score=-102.682 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 3CqzVdvr+bG2 for ; Tue, 15 Jul 2008 11:17:24 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 213123A6A5F for ; Tue, 15 Jul 2008 11:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1216145872; x=1247681872; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<0e4401c8e6a4$8b7a6b20$6 40fa8c0@cis.neustar.com>|References:=20=0D=0A=20<0db101c8e67c$ed5b83b0$640fa8c0@cis.n eustar.com>=0D=0A=20<5D1A7985295922448D5550C94DE291800210 E0CA@DEEXC1U01.de.lucent.com>=0D=0A=20<0ddc01c8e68a$47c22 400$640fa8c0@cis.neustar.com>=0D=0A=20=0D=0A=20<0e3701c8e699$85d54330$640fa8 c0@cis.neustar.com>=0D=0A=20<5D1A7985295922448D5550C94DE2 91800210E16C@DEEXC1U01.de.lucent.com>=0D=0A=20<0e4401c8e6 a4$8b7a6b20$640fa8c0@cis.neustar.com>|Date:=20Tue,=2015 =20Jul=202008=2011:17:48=20-0700|To:=20Brian=20Rosen=20,=0D=0A=20=20=20=20=20=20=20=20"'DRAGE, =20Keith=20(Keith)'"=0D=0A=09, =0D=0A=20=20=20=20=20=20=20=20"ecrit@ietf.org"=20,=0D=0A=20=20=20=20=20=20=20=20"marc.linsner@cisc o.com"=20|From:=20Ted=20Hardie=20 |Subject:=20RE:=20[Ecrit]=20Request =20for=20agenda=20time=20to=20discuss=20emergency=20=20 =0D=0A=20calltermination|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 200,2160,5339"=3B=20a=3D"4559793"; bh=mQ8Mq6owD9igdUyi/i/JeX90049QgaPi02zoBdSz8+U=; b=CN7u8ZkSKankcI64UK3V55Sky+QPb4UAA4Fe/PNSOAwMzeqSomD5i1am kw2A/B+QrrGnS+1SFv9dRwk8KmmsHSCZTwrFqT7YrwupzKjhlFTnoa9qk rMNUPPF7/6sLBz6MHKwRngCAvexz7KsRwlvhFvTBUiXGJeQTNHeHsmYnT 4=; X-IronPort-AV: E=McAfee;i="5200,2160,5339"; a="4559793" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Jul 2008 11:17:52 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6FIHp2v020680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Jul 2008 11:17:51 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6FIHpQM005155 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 15 Jul 2008 11:17:51 -0700 Received: from [129.46.226.27] (129.46.226.27) by qcmail1.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 15 Jul 2008 11:17:50 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <0e4401c8e6a4$8b7a6b20$640fa8c0@cis.neustar.com> References: <0db101c8e67c$ed5b83b0$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E0CA@DEEXC1U01.de.lucent.com> <0ddc01c8e68a$47c22400$640fa8c0@cis.neustar.com> <0e3701c8e699$85d54330$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E16C@DEEXC1U01.de.lucent.com> <0e4401c8e6a4$8b7a6b20$640fa8c0@cis.neustar.com> Date: Tue, 15 Jul 2008 11:17:48 -0700 To: Brian Rosen , "'DRAGE, Keith (Keith)'" , "ecrit@ietf.org" , "marc.linsner@cisco.com" From: Ted Hardie Subject: Re: [Ecrit] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 10:59 AM -0700 7/15/08, Brian Rosen wrote: > > > 3) I suspect a solution that prevents BYE being sent only wins over >> other solutions to reestablish the call if you are able to preserve both >> signalling and media resources for the entire path between UA and PSAP >> by doing so. As the cost of preserving radio resources is high in >> respect of the number of times such a capability might be used, I >> suspect this is the reason why mobile networks do not do it. >Nah, they don't do it because they didn't have to discuss it with the >emergency guys before they designed the networks. And your evidence for this is what, exactly? That they patterned the network behavior on the ISDN behavior? Did the ISDN folks also not talk to the emergency guys? Or did the emergency guys they talked to say something different from what you think they are saying now? >It's less resources in most circumstances to keep a call up than to tear it >down and re-establish it. The case here is that one end is trying to end >the call and the other end is trying to keep the call up. The best way to >solve that is leave the call up until they figure it out. Again, this presumes that the side wanting to keep the call up has its preferences followed in all cases; as has already been pointed out, there are cases like anonymous emergency calls where this may be neither practical nor desirable. > >An emergency call should be identified by the UA, and it then knows whether >to suppress BYE. I suspect if we keep that rule, we probably do need words >in -framework and -phonebcp that deal with the currently allowed >circumstance that a proxy detects the emergency dialstring. I suspect that >if the UA doesn't detect the dial string, it doesn't suppress BYE. >Otherwise, that creates an attack vector. And how do you propose to let the UA know whether suppress BYE is expected by a particular PSAP? If it suppresses BYE and the PSAP doesn't expect/support that behavior, it's a flat waste, isn't it? > > >> But I do support that we identify the precise requirements, and >> understand those first. >Yah. Yep, we have solid agreement on that step at least. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 15 11:38:09 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECD373A6B27; Tue, 15 Jul 2008 11:38: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 B83ED3A6AF6 for ; Tue, 15 Jul 2008 11:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 GCOxe9VRowEe for ; Tue, 15 Jul 2008 11:38:08 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 8F4BE3A6B27 for ; Tue, 15 Jul 2008 11:38:07 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2008 18:38:35 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp055) with SMTP; 15 Jul 2008 20:38:35 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18diLMSxnodsJw8QZXdgHuN0EDVCNKRDeZqIqFjpn l1n5JVMD8Is8Ue Message-ID: <487CEEAC.60703@gmx.net> Date: Tue, 15 Jul 2008 21:38:36 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: 'ECRIT' X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 Subject: [Ecrit] REMINDER: WGLC on draft-ietf-ecrit-specifying-holes-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Please read through this document. It is short -------- Original Message -------- Subject: [Ecrit] WGLC on draft-ietf-ecrit-specifying-holes-00 Date: Tue, 08 Jul 2008 00:43:59 +0300 From: Hannes Tschofenig To: 'ECRIT' Hi all, we would like to start the WGLC for the "Specifying Holes in LoST Service Boundaries" http://tools.ietf.org/html/draft-ietf-ecrit-specifying-holes-00 document. Please have all comments in by August 1, 2008. Ciao 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 Tue Jul 15 11:38:19 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 299363A6AB9; Tue, 15 Jul 2008 11:38: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 4F2E33A68F4 for ; Tue, 15 Jul 2008 11:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 zP11XAKNA-xK for ; Tue, 15 Jul 2008 11:38:17 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BF2CE3A6882 for ; Tue, 15 Jul 2008 11:38:16 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2008 18:38:44 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp053) with SMTP; 15 Jul 2008 20:38:44 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+JaEISIx2JNKfE7t8eztsEfEQ4tRkZHz77/5NmSz xhkfjzOZIjVmzg Message-ID: <487CEEB4.8090503@gmx.net> Date: Tue, 15 Jul 2008 21:38:44 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: 'ECRIT' X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 Subject: [Ecrit] REMINDER: WGLC on draft-ietf-ecrit-location-hiding-req-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Please read through this document. It is short -------- Original Message -------- Subject: [Ecrit] WGLC on draft-ietf-ecrit-location-hiding-req-00 Date: Tue, 08 Jul 2008 00:43:50 +0300 From: Hannes Tschofenig To: 'ECRIT' Hi all, we would like to start the WGLC for the "Location Hiding: Problem Statement and Requirements" http://tools.ietf.org/html/draft-ietf-ecrit-location-hiding-req-00 document. Please have all comments in by August 1, 2008. Ciao 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 Tue Jul 15 12:36:14 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 468443A689F; Tue, 15 Jul 2008 12:36: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 6869F3A6823 for ; Tue, 15 Jul 2008 12:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 IoN-efw-6S-6 for ; Tue, 15 Jul 2008 12:36:12 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 6AED63A689F for ; Tue, 15 Jul 2008 12:36:12 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KIqK6-0004sp-Rt; Tue, 15 Jul 2008 14:36:31 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'DRAGE, Keith \(Keith\)'" , , References: <0db101c8e67c$ed5b83b0$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E0CA@DEEXC1U01.de.lucent.com> <0ddc01c8e68a$47c22400$640fa8c0@cis.neustar.com> <0e3701c8e699$85d54330$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E16C@DEEXC1U01.de.lucent.com> <0e4401c8e6a4$8b7a6b20$640fa8c0@cis.neustar.com> Date: Tue, 15 Jul 2008 15:36:34 -0400 Message-ID: <0e6d01c8e6b2$18f7a870$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjmpxU4C2lBn/04TUq5q5eSyvaeZwACanDQ 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] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 > >Nah, they don't do it because they didn't have to discuss it with the > >emergency guys before they designed the networks. > > And your evidence for this is what, exactly? That they patterned > the network behavior on the ISDN behavior? Did the ISDN > folks also not talk to the emergency guys? Or did the emergency > guys they talked to say something different from what you > think they are saying now? I will give you a dozen old timers in the PSAP world who will tell you that they howled and screamed when the telcos took away called party hold. I will give you many more folks who learned how mobile networks worked when the call started coming in. In fact, the first discussions with the mobile guys and 9-1-1 are eerily familiar (this isn't really a telephony service, its not replacing wired phones, its not reliable and people won't depend on it to call 9-1-1). > > >It's less resources in most circumstances to keep a call up than to tear > it > >down and re-establish it. The case here is that one end is trying to end > >the call and the other end is trying to keep the call up. The best way > to > >solve that is leave the call up until they figure it out. > > Again, this presumes that the side wanting to keep the call up > has its preferences followed in all cases; as has already been pointed > out, there are cases like anonymous emergency calls where > this may be neither practical nor desirable. Anonymity is not linked to called party hold. It's true that CPH is not used, or required, in some jurisdictions. I'm looking for a simple solution, and I bias complexity at the PSAP to complexity at the UA. Its clear we need to control this feature. What won't work, I don't think, is Options negotiation. > > > > >An emergency call should be identified by the UA, and it then knows > whether > >to suppress BYE. I suspect if we keep that rule, we probably do need > words > >in -framework and -phonebcp that deal with the currently allowed > >circumstance that a proxy detects the emergency dialstring. I suspect > that > >if the UA doesn't detect the dial string, it doesn't suppress BYE. > >Otherwise, that creates an attack vector. > > And how do you propose to let the UA know whether suppress BYE is > expected by a particular PSAP? If it suppresses BYE and the PSAP > doesn't expect/support that behavior, it's a flat waste, isn't it? Well, first of all, I've agreed that requirements first, solutions later is appropriate. What I proposed was all UAs suppress BYE, and all UAs signal hook state. The PSAP end can then manually or automatically send BYE upon receipt of on hook state. No negotiations. No optional behavior. No determining capabilities. If a jurisdiction does not want to support CPH, they return BYE upon receipt of on-hook state automatically. > > > > > >> But I do support that we identify the precise requirements, and > >> understand those first. > >Yah. > > Yep, we have solid agreement on that step at least. > > Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 15 13:03:47 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FC923A6B5A; Tue, 15 Jul 2008 13:03: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 0CF453A6AD9 for ; Tue, 15 Jul 2008 13:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 lvvsMpuEsEzL for ; Tue, 15 Jul 2008 13:03:45 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id C9B213A6B47 for ; Tue, 15 Jul 2008 13:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1216152254; x=1247688254; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<0e6d01c8e6b2$18f7a870$6 40fa8c0@cis.neustar.com>|References:=20=0D=0A=20<0db101c8e67c$ed5b83b0$640fa8c0@cis.n eustar.com>=0D=0A=20<5D1A7985295922448D5550C94DE291800210 E0CA@DEEXC1U01.de.lucent.com>=0D=0A=20<0ddc01c8e68a$47c22 400$640fa8c0@cis.neustar.com>=0D=0A=20=0D=0A=20<0e3701c8e699$85d54330$640fa8 c0@cis.neustar.com>=0D=0A=20<5D1A7985295922448D5550C94DE2 91800210E16C@DEEXC1U01.de.lucent.com>=0D=0A=20<0e4401c8e6 a4$8b7a6b20$640fa8c0@cis.neustar.com>=0D=0A=20=0D=0A=20<0e6d01c8e6b2$18f7a8 70$640fa8c0@cis.neustar.com>|Date:=20Tue,=2015=20Jul=2020 08=2013:02:52=20-0700|To:=20Brian=20Rosen=20,=0D=0A=20=20=20=20=20=20=20=20"'DRAGE,=20Keith=20( Keith)'"=0D=0A=09,=0D=0A=20=20 =20=20=20=20=20=20"ecrit@ietf.org"=20,=0D =0A=20=20=20=20=20=20=20=20"marc.linsner@cisco.com"=20|From:=20Ted=20Hardie=20|Subject:=20RE:=20[Ecrit]=20Request=20for=20agen da=20time=20to=20discuss=20emergency=20=20=20=0D=0A=20cal ltermination|Content-Type:=20text/plain=3B=20charset=3D"u s-ascii"|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,533 9"=3B=20a=3D"4564632"; bh=YxeTA/whfJCpHP1ob5EjUHJ2wW07eZhbfbnh/pzZm8U=; b=ETc3KoshKS9lsomuKD8fgXIolB8XntNf4MzLqCPik9aOo9OKypPCfYF2 XYxhoeLH5V8F/U3gO267qd9I7UDE4QDkdsjPVDEhz9TW0jrzO7cHgCm9n fGke8jtnsYmx9t7ffsd+r7SW8XVJ/Fapu14IOGegSVBc3wFaxHMfqTktv Q=; X-IronPort-AV: E=McAfee;i="5200,2160,5339"; a="4564632" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Jul 2008 13:04:13 -0700 Received: from msgtransport06.qualcomm.com (msgtransport06.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6FK4DN0007826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Jul 2008 13:04:13 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport06.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6FK4962029045 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 15 Jul 2008 13:04:11 -0700 Received: from [129.46.226.27] (129.46.226.27) by qcmail1.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 15 Jul 2008 13:02:55 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <0e6d01c8e6b2$18f7a870$640fa8c0@cis.neustar.com> References: <0db101c8e67c$ed5b83b0$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E0CA@DEEXC1U01.de.lucent.com> <0ddc01c8e68a$47c22400$640fa8c0@cis.neustar.com> <0e3701c8e699$85d54330$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E16C@DEEXC1U01.de.lucent.com> <0e4401c8e6a4$8b7a6b20$640fa8c0@cis.neustar.com> <0e6d01c8e6b2$18f7a870$640fa8c0@cis.neustar.com> Date: Tue, 15 Jul 2008 13:02:52 -0700 To: Brian Rosen , "'DRAGE, Keith (Keith)'" , "ecrit@ietf.org" , "marc.linsner@cisco.com" From: Ted Hardie Subject: Re: [Ecrit] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 12:36 PM -0700 7/15/08, Brian Rosen wrote: > >I will give you a dozen old timers in the PSAP world who will tell you that >they howled and screamed when the telcos took away called party hold. You'll give them to me? Sweet. In any case, it sounds like this howling and screaming did not result in either comprehensive regulation to restore this nor did it convince the wireline telcos to put it back in. The result is that this is not currently common practice in all jurisdictions. Since we are putting together a general statement of best current practice, that's a pretty important fact. >I will give you many more folks who learned how mobile networks worked when >the call started coming in. In fact, the first discussions with the mobile >guys and 9-1-1 are eerily familiar (this isn't really a telephony service, >its not replacing wired phones, its not reliable and people won't depend on >it to call 9-1-1). We've crossed a wire here. I was saying that you seemed to be assuming that the mobile network guys didn't understand how emergency calls worked; you're saying that the emergency calling guys didn't understand how mobile networks worked. > >> >> >It's less resources in most circumstances to keep a call up than to tear >> it >> >down and re-establish it. The case here is that one end is trying to end >> >the call and the other end is trying to keep the call up. The best way >> to > > >solve that is leave the call up until they figure it out. >> >> Again, this presumes that the side wanting to keep the call up >> has its preferences followed in all cases; as has already been pointed >> out, there are cases like anonymous emergency calls where >> this may be neither practical nor desirable. >Anonymity is not linked to called party hold. It may be linked to other ways to resolve this same issue. If the resolution to the requirements involves call-back, rather than call-party hold, anonymous calls may get different behavior. The key question is whether that is the desired behavior. Having an anonymous caller *be unable to get off the phone without explaining the call* may not be good; having them get a call back from 911 may also be bad, depending on their reasons for the call and for the hang-up. Rolling a cop to those situations may be better or worse, but it isn't a slam-dunk which is the right thing to do. >It's true that CPH is not used, or required, in some jurisdictions. > >I'm looking for a simple solution, and I bias complexity at the PSAP to >complexity at the UA. Its clear we need to control this feature. What >won't work, I don't think, is Options negotiation. > You seem to presume that CPH is "this feature". Please, let's start the baseline requirements, not at this level. > > >> > > > >An emergency call should be identified by the UA, and it then knows >> whether >> >to suppress BYE. I suspect if we keep that rule, we probably do need >> words >> >in -framework and -phonebcp that deal with the currently allowed >> >circumstance that a proxy detects the emergency dialstring. I suspect >> that >> >if the UA doesn't detect the dial string, it doesn't suppress BYE. >> >Otherwise, that creates an attack vector. >> >> And how do you propose to let the UA know whether suppress BYE is >> expected by a particular PSAP? If it suppresses BYE and the PSAP >> doesn't expect/support that behavior, it's a flat waste, isn't it? >Well, first of all, I've agreed that requirements first, solutions later is >appropriate. > >What I proposed was all UAs suppress BYE, and all UAs signal hook state. >The PSAP end can then manually or automatically send BYE upon receipt of on >hook state. > >No negotiations. No optional behavior. No determining capabilities. > >If a jurisdiction does not want to support CPH, they return BYE upon receipt >of on-hook state automatically. As you pointed out, this doesn't work when the UA isn't aware it is an emergency call. The "hook state" signalling also strikes me as something not that easy to model in some of our current devices and contexts, but we'd need more work on this. regards, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 15 13:29:56 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72CB83A68F4; Tue, 15 Jul 2008 13:29: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 663EB3A6882 for ; Tue, 15 Jul 2008 13:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[AWL=-1.098, BAYES_00=-2.599, MANGLED_PREMTR=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtdLuARtBNA5 for ; Tue, 15 Jul 2008 13:29:54 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 5DAA93A68F4 for ; Tue, 15 Jul 2008 13:29:54 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KIrA2-0007Cq-Ma; Tue, 15 Jul 2008 15:30:14 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'DRAGE, Keith \(Keith\)'" , , References: <0db101c8e67c$ed5b83b0$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E0CA@DEEXC1U01.de.lucent.com> <0ddc01c8e68a$47c22400$640fa8c0@cis.neustar.com> <0e3701c8e699$85d54330$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E16C@DEEXC1U01.de.lucent.com> <0e4401c8e6a4$8b7a6b20$640fa8c0@cis.neustar.com> <0e6d01c8e6b2$18f7a870$640fa8c0@cis.neustar.com> Date: Tue, 15 Jul 2008 16:30:14 -0400 Message-ID: <0e7d01c8e6b9$9ab3ec00$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acjmte//xIXeEn1ORSexrJHs1ZePlgAADzUQ 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] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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'll give them to me? Sweet. No charge. > > In any case, it sounds like this howling and screaming did not result in > either comprehensive regulation to restore this nor did it convince > the wireline telcos to put it back in. The result is that this is not > currently > common practice in all jurisdictions. Since we are putting together > a general statement of best current practice, that's a pretty important > fact. It's a fact, but the removal was undesirable, and in many cases they really want it back. However, the request is coming from Canada, who never lost it, and doesn't want to lose it now. There are other jurisdictions in the same situation. > > >I will give you many more folks who learned how mobile networks worked > when > >the call started coming in. In fact, the first discussions with the > mobile > >guys and 9-1-1 are eerily familiar (this isn't really a telephony > service, > >its not replacing wired phones, its not reliable and people won't depend > on > >it to call 9-1-1). > > We've crossed a wire here. I was saying that you seemed to be assuming > that the mobile network guys didn't understand how emergency calls > worked; you're saying that the emergency calling guys didn't understand > how mobile networks worked. I'm saying that the wireless guys and the emergency services people have not had a serious negotiation on the called party hold feature. Actually, the wireless folks and the emergency service folks have had a very contentious and somewhat acrimonious relationship in the U.S., which many on both sides are trying get away from. The opportunity for NENA and some of the PSAP people on the list to participate in the setting of IP based standards before the calls start coming in is a welcome change, which they sincerely appreciate. > >Anonymity is not linked to called party hold. > > It may be linked to other ways to resolve this same issue. > If the resolution to the requirements involves call-back, rather > than call-party hold, anonymous calls may get different behavior. > The key question is whether that is the desired behavior. Having > an anonymous caller *be unable to get off the phone without explaining > the call* may not be good; having them get a call back from > 911 may also be bad, depending on their reasons for the call > and for the hang-up. In nearly all, but not all jurisdictions, there is no such thing as anonymous emergency calls. I accept the necessity to support them, because there are some jurisdictions that require them. I'll work on requirements and we'll see where we get to. So far, as far as I can see, there are no implications on anonymous emergency calls in the proposed solutions. > > Rolling a cop to those situations may be better or worse, but > it isn't a slam-dunk which is the right thing to do. You, and the IETF, don't get to decide that. The jurisdictions that roll cops do. Even where they do not respond, many jurisdictions really would like to know why a call was abandoned. There is decades of experience with called party hold. The downsides are pretty small. I'll still grant that it's a specific solution to a problem, and we don't need to replicate the solution as long as we solve the problem. > > >It's true that CPH is not used, or required, in some jurisdictions. > > > >I'm looking for a simple solution, and I bias complexity at the PSAP to > >complexity at the UA. Its clear we need to control this feature. What > >won't work, I don't think, is Options negotiation. > > > > You seem to presume that CPH is "this feature". Please, let's start > the baseline requirements, not at this level. Nah, the "feature" is control of abandoned calls and control of established calls with pre-mature hang up. Agree, requirements first. > > > > As you pointed out, this doesn't work when the UA isn't aware it > is an emergency call. The "hook state" signalling also strikes me > as something not that easy to model in some of our current devices > and contexts, but we'd need more work on this. Yeah, agree. In we're always in danger of implementers cherry picking features to implement in -phonebcp. We'll have to be careful in -framework to explain the rationale, and in the security section of both to deal with side effects like tricking the UA into thinking it's an emergency call in order to suppress BYE if that is the solution we arrive at. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 15 15:23:14 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 810BB3A6A5F; Tue, 15 Jul 2008 15:23: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 CE5773A6A5F for ; Tue, 15 Jul 2008 15:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6mjPqgsvGt6 for ; Tue, 15 Jul 2008 15:23: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 CDB913A69A3 for ; Tue, 15 Jul 2008 15:23:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,368,1212364800"; d="scan'208";a="14407874" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 15 Jul 2008 22:23:40 +0000 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 m6FMNebn012982; Tue, 15 Jul 2008 18:23:40 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6FMNe7U004368; Tue, 15 Jul 2008 22:23:40 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); Tue, 15 Jul 2008 18:23:40 -0400 Received: from [10.116.195.115] ([10.116.195.115]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 18:23:40 -0400 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 15 Jul 2008 18:23:39 -0400 From: Marc Linsner To: Brian Rosen , Message-ID: Thread-Topic: [Ecrit] Request for agenda time to discuss emergency calltermination Thread-Index: AcjmpxU4C2lBn/04TUq5q5eSyvaeZwACanDQAAYryHY= In-Reply-To: <0e6d01c8e6b2$18f7a870$640fa8c0@cis.neustar.com> Mime-version: 1.0 X-OriginalArrivalTime: 15 Jul 2008 22:23:40.0212 (UTC) FILETIME=[6ED1D740:01C8E6C9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1643; t=1216160620; x=1217024620; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20Request=20for=20agenda=20time =20to=20discuss=20emergency=20=20=0A=20calltermination |Sender:=20 |To:=20Brian=20Rosen=20,=20; bh=snuvOzIKZcvNYYD9ZMnpUsr0XaVce20LzT9RvuOw6hQ=; b=WaotBWuJPCuZI7c/vnPNngbX4Tnf9OSIzPvdnM5qnvh2Ew5n933m6uFdIR j1cNgle1xip/dm8fVTwDUVbDzOlyniaosTPTXYz9tJroybEHHukOcpD+llLt CjsCHi8P9A; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Ecrit] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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, On 7/15/08 3:36 PM, "Brian Rosen" wrote: >>> Nah, they don't do it because they didn't have to discuss it with the >>> emergency guys before they designed the networks. >> >> And your evidence for this is what, exactly? That they patterned >> the network behavior on the ISDN behavior? Did the ISDN >> folks also not talk to the emergency guys? Or did the emergency >> guys they talked to say something different from what you >> think they are saying now? > > I will give you a dozen old timers in the PSAP world who will tell you that > they howled and screamed when the telcos took away called party hold. CPH was necessary in the electro-mechanical switch days. There was no CDR, no way to post mortem trace a call. CPH to the PSAPs started to fade as 'E' 9-1-1 was rolled out. As the PSAPs gained a way to identify the caller, the need for CPH became less important. Apparently, some PSAPs have found a use for CPH in addition to having ANI/ALI. Of course, they only have this feature on 35% of the 9-1-1 calls. Malicious Call Hold used CPH also, but it went by the way of CDRs from modern digital switches. Hence, the courts accept switch CDRs as evidence. I don't believe CPH is supported on SS7, hence this may be the reason cellular doesn't support it as it's based on a derivative of SS7 (IS41?). So, my assertion is that CPH is only supported on CAS (channel associated signaling) trunks. CCS (common channel signaling) doesn't support such. SIP is CCS, not CAS. (I wish it were that easy :^) Bottom line, CPH is a very antiquated feature. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 15 16:34:15 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AACF3A685C; Tue, 15 Jul 2008 16:34: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 8CA593A685C for ; Tue, 15 Jul 2008 16:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LVSApM3Ax2l for ; Tue, 15 Jul 2008 16:34:13 -0700 (PDT) Received: from mail157.messagelabs.com (mail157.messagelabs.com [85.158.136.211]) by core3.amsl.com (Postfix) with ESMTP id 32A233A67CF for ; Tue, 15 Jul 2008 16:34:13 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-14.tower-157.messagelabs.com!1216164878!10320985!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [206.47.0.173] Received: (qmail 5747 invoked from network); 15 Jul 2008 23:34:39 -0000 Received: from dm1c8f.bell.ca (HELO TLS.Exchange.Bell.ca) (206.47.0.173) by server-14.tower-157.messagelabs.com with RC4-SHA encrypted SMTP; 15 Jul 2008 23:34:39 -0000 Received: from hub02-wyn.bell.corp.bce.ca (142.182.199.50) by dm1c8f.exchange1.bell.ca (198.235.102.112) with Microsoft SMTP Server id 8.1.278.0; Tue, 15 Jul 2008 19:34:38 -0400 Received: from TOROONDC918.bell.corp.bce.ca (142.182.89.79) by hub02-wyn.bell.corp.bce.ca (142.182.199.50) with Microsoft SMTP Server id 8.1.278.0; Tue, 15 Jul 2008 19:34:38 -0400 Received: from toroondc254.bell.corp.bce.ca ([142.182.4.53]) by TOROONDC918.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 19:34:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Jul 2008 19:34:30 -0400 Message-ID: <2DE9A51895931C4CBCAEFA9306AE480E3D7BE0@toroondc254.bell.corp.bce.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Request for agenda time to discuss emergency calltermination Thread-Index: AcjmpxU4C2lBn/04TUq5q5eSyvaeZwACanDQAAYryHYAAnmLkg== From: To: , , X-OriginalArrivalTime: 15 Jul 2008 23:34:37.0755 (UTC) FILETIME=[588358B0:01C8E6D3] Subject: Re: [Ecrit] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org TWFyYywNCg0KSSBoYXZlIHRvIGludGVyamVjdCBoZXJlLg0KDQpGaXJzdCwgQ1BIIGlzIHN1cHBv cnRlZCBpbiBTUzcgc2lnbmFsaW5nIHRvZGF5IChzZWUgQU5TSSBUMS42NjYpIGFuZCB2ZW5kb3Jz IGhhdmUgaW1wbGVtZW50ZWQgaXQuDQoNClNlY29uZCwgdGhlIGZhY3QgdGhhdCBDUEggaXMgKmN1 cnJlbnRseSogdXNlZCBpbiBDYW5hZGEgYW5kIEphcGFuICh0aGVyZSBtYXkgYmUgb3RoZXJzIHRv byEpICBzaG91bGQgcHJvdmlkZSBlbm91Z2ggZXZpZGVuY2UgdGhhdCB0aGUgZmVhdHVyZSBpcyBu b3QgYW50aXF1YXRlZC4NCg0KV2hhdCB3YXMgYm9ybiBmcm9tIHRlY2hub2xvZ3kgbGltaXRhdGlv bnMgaW4gdGhlIGVhcmx5IGRheXMgaGFzIGJlY29tZSBhIHZlcnkgbXVjaCBhcHByZWNpYXRlZCBm ZWF0dXJlIGZvciBzb21lIFBTQVBzIHdoaWxlIGV2b2x2aW5nIHRvIEU5LTEtMS4gVGhleSBqdXN0 IGRvbid0IHdhbnQgdG8gbG9vc2UgaXQgaWYgaXQgaXMgdGVjaG5pY2FsbHkgcG9zc2libGUuIEFu ZCB0aGlzIGRpc2N1c3Npb24gaXMgdGVsbGluZyBtZSBpdCBjb3VsZCBiZSBwb3NzaWJsZS4NCg0K VGhhbmtzLA0KX19fX19fX19fX19fX18NCkd1eSBDYXJvbiANCkJlbGwgQ2FuYWRhDQooNDE4KSA2 OTEtMTExOQ0KDQotLS0tLSBNZXNzYWdlIGQnb3JpZ2luZSAtLS0tLQ0KRGUgOiBlY3JpdC1ib3Vu Y2VzQGlldGYub3JnIDxlY3JpdC1ib3VuY2VzQGlldGYub3JnPg0Kw4AgOiBCcmlhbiBSb3NlbiA8 YnJAYnJpYW5yb3Nlbi5uZXQ+OyBlY3JpdEBpZXRmLm9yZyA8ZWNyaXRAaWV0Zi5vcmc+DQpFbnZv ecOpIDogVHVlIEp1bCAxNSAxODoyMzozOSAyMDA4DQpPYmpldCA6IFJlOiBbRWNyaXRdIFJlcXVl c3QgZm9yIGFnZW5kYSB0aW1lIHRvIGRpc2N1c3MgZW1lcmdlbmN5IGNhbGx0ZXJtaW5hdGlvbg0K DQpCcmlhbiwNCg0KDQpPbiA3LzE1LzA4IDM6MzYgUE0sICJCcmlhbiBSb3NlbiIgPGJyQGJyaWFu cm9zZW4ubmV0PiB3cm90ZToNCg0KPj4+IE5haCwgdGhleSBkb24ndCBkbyBpdCBiZWNhdXNlIHRo ZXkgZGlkbid0IGhhdmUgdG8gZGlzY3VzcyBpdCB3aXRoIHRoZQ0KPj4+IGVtZXJnZW5jeSBndXlz IGJlZm9yZSB0aGV5IGRlc2lnbmVkIHRoZSBuZXR3b3Jrcy4NCj4+IA0KPj4gQW5kIHlvdXIgZXZp ZGVuY2UgZm9yIHRoaXMgaXMgd2hhdCwgZXhhY3RseT8gVGhhdCB0aGV5IHBhdHRlcm5lZA0KPj4g dGhlIG5ldHdvcmsgYmVoYXZpb3Igb24gdGhlIElTRE4gYmVoYXZpb3I/ICBEaWQgdGhlIElTRE4N Cj4+IGZvbGtzIGFsc28gbm90IHRhbGsgdG8gdGhlIGVtZXJnZW5jeSBndXlzPyAgT3IgZGlkIHRo ZSBlbWVyZ2VuY3kNCj4+IGd1eXMgdGhleSB0YWxrZWQgdG8gc2F5IHNvbWV0aGluZyBkaWZmZXJl bnQgZnJvbSB3aGF0IHlvdQ0KPj4gdGhpbmsgdGhleSBhcmUgc2F5aW5nIG5vdz8NCj4gDQo+IEkg d2lsbCBnaXZlIHlvdSBhIGRvemVuIG9sZCB0aW1lcnMgaW4gdGhlIFBTQVAgd29ybGQgd2hvIHdp bGwgdGVsbCB5b3UgdGhhdA0KPiB0aGV5IGhvd2xlZCBhbmQgc2NyZWFtZWQgd2hlbiB0aGUgdGVs Y29zIHRvb2sgYXdheSBjYWxsZWQgcGFydHkgaG9sZC4NCg0KQ1BIIHdhcyBuZWNlc3NhcnkgaW4g dGhlIGVsZWN0cm8tbWVjaGFuaWNhbCBzd2l0Y2ggZGF5cy4gIFRoZXJlIHdhcyBubyBDRFIsDQpu byB3YXkgdG8gcG9zdCBtb3J0ZW0gdHJhY2UgYSBjYWxsLiAgQ1BIIHRvIHRoZSBQU0FQcyBzdGFy dGVkIHRvIGZhZGUgYXMgJ0UnDQo5LTEtMSB3YXMgcm9sbGVkIG91dC4gIEFzIHRoZSBQU0FQcyBn YWluZWQgYSB3YXkgdG8gaWRlbnRpZnkgdGhlIGNhbGxlciwgdGhlDQpuZWVkIGZvciBDUEggYmVj YW1lIGxlc3MgaW1wb3J0YW50LiAgQXBwYXJlbnRseSwgc29tZSBQU0FQcyBoYXZlIGZvdW5kIGEg dXNlDQpmb3IgQ1BIIGluIGFkZGl0aW9uIHRvIGhhdmluZyBBTkkvQUxJLiAgT2YgY291cnNlLCB0 aGV5IG9ubHkgaGF2ZSB0aGlzDQpmZWF0dXJlIG9uIDM1JSBvZiB0aGUgOS0xLTEgY2FsbHMuDQoN Ck1hbGljaW91cyBDYWxsIEhvbGQgdXNlZCBDUEggYWxzbywgYnV0IGl0IHdlbnQgYnkgdGhlIHdh eSBvZiBDRFJzIGZyb20NCm1vZGVybiBkaWdpdGFsIHN3aXRjaGVzLiAgSGVuY2UsIHRoZSBjb3Vy dHMgYWNjZXB0IHN3aXRjaCBDRFJzIGFzIGV2aWRlbmNlLg0KDQpJIGRvbid0IGJlbGlldmUgQ1BI IGlzIHN1cHBvcnRlZCBvbiBTUzcsIGhlbmNlIHRoaXMgbWF5IGJlIHRoZSByZWFzb24NCmNlbGx1 bGFyIGRvZXNuJ3Qgc3VwcG9ydCBpdCBhcyBpdCdzIGJhc2VkIG9uIGEgZGVyaXZhdGl2ZSBvZiBT UzcgKElTNDE/KS4NCg0KU28sIG15IGFzc2VydGlvbiBpcyB0aGF0IENQSCBpcyBvbmx5IHN1cHBv cnRlZCBvbiBDQVMgKGNoYW5uZWwgYXNzb2NpYXRlZA0Kc2lnbmFsaW5nKSB0cnVua3MuICBDQ1Mg KGNvbW1vbiBjaGFubmVsIHNpZ25hbGluZykgZG9lc24ndCBzdXBwb3J0IHN1Y2guDQpTSVAgaXMg Q0NTLCBub3QgQ0FTLiAgKEkgd2lzaCBpdCB3ZXJlIHRoYXQgZWFzeSA6XikNCg0KQm90dG9tIGxp bmUsIENQSCBpcyBhIHZlcnkgYW50aXF1YXRlZCBmZWF0dXJlLg0KDQotTWFyYy0NCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRWNyaXQgbWFpbGlu ZyBsaXN0DQpFY3JpdEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9lY3JpdA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KRWNyaXQgbWFpbGluZyBsaXN0CkVjcml0QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZWNyaXQK From ecrit-bounces@ietf.org Tue Jul 15 16:50:49 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9149B3A685C; Tue, 15 Jul 2008 16:50: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 638593A67BD for ; Tue, 15 Jul 2008 16:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7BtO-RLGp6k for ; Tue, 15 Jul 2008 16:50:48 -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 0D40A3A6782 for ; Tue, 15 Jul 2008 16:50:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,368,1212364800"; d="scan'208";a="14429846" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 15 Jul 2008 23:51:16 +0000 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 m6FNpGmH002322; Tue, 15 Jul 2008 19:51:16 -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.13.8/8.13.8) with ESMTP id m6FNpGrO012803; Tue, 15 Jul 2008 23:51:16 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); Tue, 15 Jul 2008 19:51:15 -0400 Received: from [10.116.195.115] ([10.116.195.115]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 19:51:14 -0400 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 15 Jul 2008 19:51:13 -0400 From: Marc Linsner To: , , Message-ID: Thread-Topic: [Ecrit] Request for agenda time to discuss emergency calltermination Thread-Index: AcjmpxU4C2lBn/04TUq5q5eSyvaeZwACanDQAAYryHYAAnmLkgAAlV33 In-Reply-To: <2DE9A51895931C4CBCAEFA9306AE480E3D7BE0@toroondc254.bell.corp.bce.ca> Mime-version: 1.0 X-OriginalArrivalTime: 15 Jul 2008 23:51:15.0480 (UTC) FILETIME=[AB341980:01C8E6D5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3365; t=1216165876; x=1217029876; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20Request=20for=20agenda=20time =20to=20discuss=20emergency=0A=20calltermination |Sender:=20 |To:=20,=20,=20; bh=Vy1vYZGSYLBk9KqI0xRp3XnBAXOa+Eue9Mskt+s3sq0=; b=ivP6yB8higq5ZsCTI/JNFekXcangZlBkLjWP6+SmnHZC/50Ni8pebX97oG 4WvM+LgbAbq2ElZsqFqUm3604zqzOUtDOEcqQQEoQDUbb5vXJyc901V0go8P t8CaUoAX14; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Ecrit] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Guy, Thanks for the update. I obviously haven't kept up on every national variant of SS7. Regardless, I believe the cellular network is based on IS41 which is a derivative of the base CCITT spec. It depends on what functionality you are believing is possible. IMO, there is quite a difference in not responding to SIP BYE and 'taking control' of the far-end SIP UA. The fact remains that 65% of 911 calls do not support CPH. -Marc- > Marc, > = > I have to interject here. > = > First, CPH is supported in SS7 signaling today (see ANSI T1.666) and vend= ors > have implemented it. > = > Second, the fact that CPH is *currently* used in Canada and Japan (there = may > be others too!) should provide enough evidence that the feature is not > antiquated. > = > What was born from technology limitations in the early days has become a = very > much appreciated feature for some PSAPs while evolving to E9-1-1. They ju= st > don't want to loose it if it is technically possible. And this discussion= is > telling me it could be possible. > = > Thanks, > ______________ > Guy Caron = > Bell Canada > (418) 691-1119 > = > ----- Message d'origine ----- > De : ecrit-bounces@ietf.org > =C0 : Brian Rosen ; ecrit@ietf.org > Envoy=E9 : Tue Jul 15 18:23:39 2008 > Objet : Re: [Ecrit] Request for agenda time to discuss emergency > calltermination > = > Brian, > = > = > On 7/15/08 3:36 PM, "Brian Rosen" wrote: > = >>>> Nah, they don't do it because they didn't have to discuss it with the >>>> emergency guys before they designed the networks. >>> = >>> And your evidence for this is what, exactly? That they patterned >>> the network behavior on the ISDN behavior? Did the ISDN >>> folks also not talk to the emergency guys? Or did the emergency >>> guys they talked to say something different from what you >>> think they are saying now? >> = >> I will give you a dozen old timers in the PSAP world who will tell you t= hat >> they howled and screamed when the telcos took away called party hold. > = > CPH was necessary in the electro-mechanical switch days. There was no CD= R, > no way to post mortem trace a call. CPH to the PSAPs started to fade as = 'E' > 9-1-1 was rolled out. As the PSAPs gained a way to identify the caller, = the > need for CPH became less important. Apparently, some PSAPs have found a = use > for CPH in addition to having ANI/ALI. Of course, they only have this > feature on 35% of the 9-1-1 calls. > = > Malicious Call Hold used CPH also, but it went by the way of CDRs from > modern digital switches. Hence, the courts accept switch CDRs as evidenc= e. > = > I don't believe CPH is supported on SS7, hence this may be the reason > cellular doesn't support it as it's based on a derivative of SS7 (IS41?). > = > So, my assertion is that CPH is only supported on CAS (channel associated > signaling) trunks. CCS (common channel signaling) doesn't support such. > SIP is CCS, not CAS. (I wish it were that easy :^) > = > Bottom line, CPH is a very antiquated feature. > = > -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 Tue Jul 15 16:54:12 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32C2B3A67BD; Tue, 15 Jul 2008 16:54: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 D14DD3A67BD for ; Tue, 15 Jul 2008 16:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ARepk5aTDPtl for ; Tue, 15 Jul 2008 16:54:09 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id BC2153A6782 for ; Tue, 15 Jul 2008 16:54:09 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_07_15_19_09_48 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, 15 Jul 2008 19:09:48 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 18:54:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Jul 2008 18:54:33 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Request for agenda time to discuss emergency calltermination Thread-Index: AcjmpxU4C2lBn/04TUq5q5eSyvaeZwACanDQAAYryHYAAnmLkgAAlV33AAAWlqA= References: <2DE9A51895931C4CBCAEFA9306AE480E3D7BE0@toroondc254.bell.corp.bce.ca> From: "Winterbottom, James" To: "Marc Linsner" , , , X-OriginalArrivalTime: 15 Jul 2008 23:54:36.0703 (UTC) FILETIME=[23244AF0:01C8E6D6] Subject: Re: [Ecrit] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 that greater question is should those 65% support it? Without open discussion in the forum I don't think this question can be ans= wered adequately. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Marc Linsner > Sent: Wednesday, 16 July 2008 9:51 AM > To: g.caron@bell.ca; br@brianrosen.net; ecrit@ietf.org > Subject: Re: [Ecrit] Request for agenda time to discuss emergency > calltermination > = > Guy, > = > Thanks for the update. I obviously haven't kept up on every national > variant of SS7. Regardless, I believe the cellular network is based on > IS41 > which is a derivative of the base CCITT spec. > = > It depends on what functionality you are believing is possible. IMO, > there > is quite a difference in not responding to SIP BYE and 'taking control' of > the far-end SIP UA. > = > The fact remains that 65% of 911 calls do not support CPH. > = > -Marc- > = > > Marc, > > > > I have to interject here. > > > > First, CPH is supported in SS7 signaling today (see ANSI T1.666) and > vendors > > have implemented it. > > > > Second, the fact that CPH is *currently* used in Canada and Japan (there > may > > be others too!) should provide enough evidence that the feature is not > > antiquated. > > > > What was born from technology limitations in the early days has become a > very > > much appreciated feature for some PSAPs while evolving to E9-1-1. They > just > > don't want to loose it if it is technically possible. And this > discussion is > > telling me it could be possible. > > > > Thanks, > > ______________ > > Guy Caron > > Bell Canada > > (418) 691-1119 > > > > ----- Message d'origine ----- > > De : ecrit-bounces@ietf.org > > =C0 : Brian Rosen ; ecrit@ietf.org > > Envoy=E9 : Tue Jul 15 18:23:39 2008 > > Objet : Re: [Ecrit] Request for agenda time to discuss emergency > > calltermination > > > > Brian, > > > > > > On 7/15/08 3:36 PM, "Brian Rosen" wrote: > > > >>>> Nah, they don't do it because they didn't have to discuss it with the > >>>> emergency guys before they designed the networks. > >>> > >>> And your evidence for this is what, exactly? That they patterned > >>> the network behavior on the ISDN behavior? Did the ISDN > >>> folks also not talk to the emergency guys? Or did the emergency > >>> guys they talked to say something different from what you > >>> think they are saying now? > >> > >> I will give you a dozen old timers in the PSAP world who will tell you > that > >> they howled and screamed when the telcos took away called party hold. > > > > CPH was necessary in the electro-mechanical switch days. There was no > CDR, > > no way to post mortem trace a call. CPH to the PSAPs started to fade as > 'E' > > 9-1-1 was rolled out. As the PSAPs gained a way to identify the caller, > the > > need for CPH became less important. Apparently, some PSAPs have found a > use > > for CPH in addition to having ANI/ALI. Of course, they only have this > > feature on 35% of the 9-1-1 calls. > > > > Malicious Call Hold used CPH also, but it went by the way of CDRs from > > modern digital switches. Hence, the courts accept switch CDRs as > evidence. > > > > I don't believe CPH is supported on SS7, hence this may be the reason > > cellular doesn't support it as it's based on a derivative of SS7 (IS41?= ). > > > > So, my assertion is that CPH is only supported on CAS (channel > associated > > signaling) trunks. CCS (common channel signaling) doesn't support such. > > SIP is CCS, not CAS. (I wish it were that easy :^) > > > > Bottom line, CPH is a very antiquated feature. > > > > -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 ---------------------------------------------------------------------------= --------------------- 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 Jul 15 16:57:20 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B3D23A683B; Tue, 15 Jul 2008 16:57: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 3DDE63A67AF for ; Tue, 15 Jul 2008 16:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5bwoMEBZ0JY for ; Tue, 15 Jul 2008 16:57:18 -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 C4B9B3A683B for ; Tue, 15 Jul 2008 16:57:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,369,1212364800"; d="scan'208";a="14413509" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 15 Jul 2008 23:57:30 +0000 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 m6FNvU5q010459; Tue, 15 Jul 2008 19:57:30 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6FNvU08003019; Tue, 15 Jul 2008 23:57: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); Tue, 15 Jul 2008 19:57:30 -0400 Received: from [10.116.195.115] ([10.116.195.115]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 19:57:29 -0400 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 15 Jul 2008 19:57:28 -0400 From: Marc Linsner To: "Winterbottom, James" , Message-ID: Thread-Topic: [Ecrit] Request for agenda time to discuss emergency calltermination Thread-Index: AcjmpxU4C2lBn/04TUq5q5eSyvaeZwACanDQAAYryHYAAnmLkgAAlV33AAAWlqAAACFL0w== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 15 Jul 2008 23:57:29.0983 (UTC) FILETIME=[8A6CB8F0:01C8E6D6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5779; t=1216166250; x=1217030250; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20Request=20for=20agenda=20time =20to=20discuss=20emergency=0A=20calltermination |Sender:=20 |To:=20=22Winterbottom,=20James=22=20,=20; bh=5qaYti980YhN/ZnuuX2jCESug//6dAqTMIEsd5VEisU=; b=NpYo4/Sn6AskV4eJG4+jbs9+l052pjKNDQkRqtLSgfyRaaxvULu3nEJ50I ZFAUkQQC+0WforTVbmNbHFB9HLbxXE1p4GqOokgIJLBhp7P1e8TfvH85fObT 4PvMInzNuo; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Ecrit] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 agree, we need to discuss it. A draft with detailed requirements is the first step. -Marc- On 7/15/08 7:54 PM, "Winterbottom, James" wrote: > I think that greater question is should those 65% support it? > = > Without open discussion in the forum I don't think this question can be > answered adequately. > = > = > = > Cheers > = > James > = > = > = > = > = >> -----Original Message----- > = >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > = >> Marc Linsner > = >> Sent: Wednesday, 16 July 2008 9:51 AM > = >> To: g.caron@bell.ca; br@brianrosen.net; ecrit@ietf.org > = >> Subject: Re: [Ecrit] Request for agenda time to discuss emergency > = >> calltermination > = >> = > = >> Guy, > = >> = > = >> Thanks for the update. I obviously haven't kept up on every national > = >> variant of SS7. Regardless, I believe the cellular network is based on > = >> IS41 > = >> which is a derivative of the base CCITT spec. > = >> = > = >> It depends on what functionality you are believing is possible. IMO, > = >> there > = >> is quite a difference in not responding to SIP BYE and 'taking control' = of > = >> the far-end SIP UA. > = >> = > = >> The fact remains that 65% of 911 calls do not support CPH. > = >> = > = >> -Marc- > = >> = > = >>> Marc, > = >>> = > = >>> I have to interject here. > = >>> = > = >>> First, CPH is supported in SS7 signaling today (see ANSI T1.666) and > = >> vendors > = >>> have implemented it. > = >>> = > = >>> Second, the fact that CPH is *currently* used in Canada and Japan (there > = >> may > = >>> be others too!) should provide enough evidence that the feature is not > = >>> antiquated. > = >>> = > = >>> What was born from technology limitations in the early days has become a > = >> very > = >>> much appreciated feature for some PSAPs while evolving to E9-1-1. They > = >> just > = >>> don't want to loose it if it is technically possible. And this > = >> discussion is > = >>> telling me it could be possible. > = >>> = > = >>> Thanks, > = >>> ______________ > = >>> Guy Caron > = >>> Bell Canada > = >>> (418) 691-1119 > = >>> = > = >>> ----- Message d'origine ----- > = >>> De : ecrit-bounces@ietf.org > = >>> =C0 : Brian Rosen ; ecrit@ietf.org > = >>> Envoy=E9 : Tue Jul 15 18:23:39 2008 > = >>> Objet : Re: [Ecrit] Request for agenda time to discuss emergency > = >>> calltermination > = >>> = > = >>> Brian, > = >>> = > = >>> = > = >>> On 7/15/08 3:36 PM, "Brian Rosen" wrote: > = >>> = > = >>>>>> Nah, they don't do it because they didn't have to discuss it with the > = >>>>>> emergency guys before they designed the networks. > = >>>>> = > = >>>>> And your evidence for this is what, exactly? That they patterned > = >>>>> the network behavior on the ISDN behavior? Did the ISDN > = >>>>> folks also not talk to the emergency guys? Or did the emergency > = >>>>> guys they talked to say something different from what you > = >>>>> think they are saying now? > = >>>> = > = >>>> I will give you a dozen old timers in the PSAP world who will tell you > = >> that > = >>>> they howled and screamed when the telcos took away called party hold. > = >>> = > = >>> CPH was necessary in the electro-mechanical switch days. There was no > = >> CDR, > = >>> no way to post mortem trace a call. CPH to the PSAPs started to fade as > = >> 'E' > = >>> 9-1-1 was rolled out. As the PSAPs gained a way to identify the caller, > = >> the > = >>> need for CPH became less important. Apparently, some PSAPs have found a > = >> use > = >>> for CPH in addition to having ANI/ALI. Of course, they only have this > = >>> feature on 35% of the 9-1-1 calls. > = >>> = > = >>> Malicious Call Hold used CPH also, but it went by the way of CDRs from > = >>> modern digital switches. Hence, the courts accept switch CDRs as > = >> evidence. > = >>> = > = >>> I don't believe CPH is supported on SS7, hence this may be the reason > = >>> cellular doesn't support it as it's based on a derivative of SS7 (IS41?= ). > = >>> = > = >>> So, my assertion is that CPH is only supported on CAS (channel > = >> associated > = >>> signaling) trunks. CCS (common channel signaling) doesn't support such. > = >>> SIP is CCS, not CAS. (I wish it were that easy :^) > = >>> = > = >>> Bottom line, CPH is a very antiquated feature. > = >>> = > = >>> -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 > = > = > = > -------------------------------------------------------------------------= ----- > ------------------ > = > 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 Jul 15 16:58:09 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D96B83A683B; Tue, 15 Jul 2008 16:58: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 6F1973A683B for ; Tue, 15 Jul 2008 16:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[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 fwy-NijZRkTF for ; Tue, 15 Jul 2008 16:58:07 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 5206F3A6782 for ; Tue, 15 Jul 2008 16:58:07 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_07_15_19_13_46 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, 15 Jul 2008 19:13:46 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 18:58:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Jul 2008 18:58:32 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Request for agenda time to discuss emergency calltermination Thread-Index: AcjmpxU4C2lBn/04TUq5q5eSyvaeZwACanDQAAYryHYAAnmLkgAAlV33AAAWlqAAACFL0wAABx2Q References: From: "Winterbottom, James" To: "Marc Linsner" , X-OriginalArrivalTime: 15 Jul 2008 23:58:34.0863 (UTC) FILETIME=[B1189FF0:01C8E6D6] Subject: Re: [Ecrit] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 totally agree, but I am not volunteering to write it! > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Wednesday, 16 July 2008 9:57 AM > To: Winterbottom, James; ecrit@ietf.org > Subject: Re: [Ecrit] Request for agenda time to discuss emergency > calltermination > = > I agree, we need to discuss it. A draft with detailed requirements is the > first step. > = > -Marc- > = > = > On 7/15/08 7:54 PM, "Winterbottom, James" > wrote: > = > > I think that greater question is should those 65% support it? > > > > Without open discussion in the forum I don't think this question can be > > answered adequately. > > > > > > > > Cheers > > > > James > > > > > > > > > > > >> -----Original Message----- > > > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > > >> Marc Linsner > > > >> Sent: Wednesday, 16 July 2008 9:51 AM > > > >> To: g.caron@bell.ca; br@brianrosen.net; ecrit@ietf.org > > > >> Subject: Re: [Ecrit] Request for agenda time to discuss emergency > > > >> calltermination > > > >> > > > >> Guy, > > > >> > > > >> Thanks for the update. I obviously haven't kept up on every national > > > >> variant of SS7. Regardless, I believe the cellular network is based on > > > >> IS41 > > > >> which is a derivative of the base CCITT spec. > > > >> > > > >> It depends on what functionality you are believing is possible. IMO, > > > >> there > > > >> is quite a difference in not responding to SIP BYE and 'taking control' > of > > > >> the far-end SIP UA. > > > >> > > > >> The fact remains that 65% of 911 calls do not support CPH. > > > >> > > > >> -Marc- > > > >> > > > >>> Marc, > > > >>> > > > >>> I have to interject here. > > > >>> > > > >>> First, CPH is supported in SS7 signaling today (see ANSI T1.666) and > > > >> vendors > > > >>> have implemented it. > > > >>> > > > >>> Second, the fact that CPH is *currently* used in Canada and Japan > (there > > > >> may > > > >>> be others too!) should provide enough evidence that the feature is > not > > > >>> antiquated. > > > >>> > > > >>> What was born from technology limitations in the early days has become > a > > > >> very > > > >>> much appreciated feature for some PSAPs while evolving to E9-1-1. They > > > >> just > > > >>> don't want to loose it if it is technically possible. And this > > > >> discussion is > > > >>> telling me it could be possible. > > > >>> > > > >>> Thanks, > > > >>> ______________ > > > >>> Guy Caron > > > >>> Bell Canada > > > >>> (418) 691-1119 > > > >>> > > > >>> ----- Message d'origine ----- > > > >>> De : ecrit-bounces@ietf.org > > > >>> =C0 : Brian Rosen ; ecrit@ietf.org > > > >>> Envoy=E9 : Tue Jul 15 18:23:39 2008 > > > >>> Objet : Re: [Ecrit] Request for agenda time to discuss emergency > > > >>> calltermination > > > >>> > > > >>> Brian, > > > >>> > > > >>> > > > >>> On 7/15/08 3:36 PM, "Brian Rosen" wrote: > > > >>> > > > >>>>>> Nah, they don't do it because they didn't have to discuss it with > the > > > >>>>>> emergency guys before they designed the networks. > > > >>>>> > > > >>>>> And your evidence for this is what, exactly? That they patterned > > > >>>>> the network behavior on the ISDN behavior? Did the ISDN > > > >>>>> folks also not talk to the emergency guys? Or did the emergency > > > >>>>> guys they talked to say something different from what you > > > >>>>> think they are saying now? > > > >>>> > > > >>>> I will give you a dozen old timers in the PSAP world who will tell > you > > > >> that > > > >>>> they howled and screamed when the telcos took away called party hold. > > > >>> > > > >>> CPH was necessary in the electro-mechanical switch days. There was no > > > >> CDR, > > > >>> no way to post mortem trace a call. CPH to the PSAPs started to fade > as > > > >> 'E' > > > >>> 9-1-1 was rolled out. As the PSAPs gained a way to identify the > caller, > > > >> the > > > >>> need for CPH became less important. Apparently, some PSAPs have found > a > > > >> use > > > >>> for CPH in addition to having ANI/ALI. Of course, they only have this > > > >>> feature on 35% of the 9-1-1 calls. > > > >>> > > > >>> Malicious Call Hold used CPH also, but it went by the way of CDRs from > > > >>> modern digital switches. Hence, the courts accept switch CDRs as > > > >> evidence. > > > >>> > > > >>> I don't believe CPH is supported on SS7, hence this may be the reason > > > >>> cellular doesn't support it as it's based on a derivative of SS7 > (IS41?). > > > >>> > > > >>> So, my assertion is that CPH is only supported on CAS (channel > > > >> associated > > > >>> signaling) trunks. CCS (common channel signaling) doesn't support > such. > > > >>> SIP is CCS, not CAS. (I wish it were that easy :^) > > > >>> > > > >>> Bottom line, CPH is a very antiquated feature. > > > >>> > > > >>> -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 > > > > > > > > ------------------------------------------------------------------------ > ------ > > ------------------ > > > > 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 Jul 15 23:03:03 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 066A03A6925; Tue, 15 Jul 2008 23:03:03 -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 1CDAB3A6901 for ; Tue, 15 Jul 2008 23:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PM1kgmxoM2SL for ; Tue, 15 Jul 2008 23:03:00 -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 C61993A6829 for ; Tue, 15 Jul 2008 23:03:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,371,1212364800"; d="scan'208";a="65898260" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 16 Jul 2008 06:03:29 +0000 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 m6G63TrO006722; Tue, 15 Jul 2008 23:03:29 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6G63Tos006452; Wed, 16 Jul 2008 06:03:29 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); Tue, 15 Jul 2008 23:03:29 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.94.233]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 23:03:28 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 16 Jul 2008 01:03:29 -0500 To: "Winterbottom, James" , "Marc Linsner" , , , From: "James M. Polk" In-Reply-To: References: <2DE9A51895931C4CBCAEFA9306AE480E3D7BE0@toroondc254.bell.corp.bce.ca> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 16 Jul 2008 06:03:28.0433 (UTC) FILETIME=[AAAE4A10:01C8E709] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5301; t=1216188209; x=1217052209; 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]=20Request=20for=20agenda=20time =20to=20discuss=20emergency=0A=20=20calltermination |Sender:=20; bh=mZYl1Mjg2Hm2B2B5I3UZDigznyjCjxfccFeLaC8D5LQ=; b=S/Rn8B+P4N0ePbRati2OMk1h0i+HAYSQUhIzUL9c5EG1/q18ZPrZlTfYAz SxKeFvqb//eKgkFX+OUhhOob7Ng/VClyrdy6uTWcSORM/I+cN4cs7am5DJg5 0Im+F+hcAr; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Ecrit] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 06:54 PM 7/15/2008, Winterbottom, James wrote: >I think that greater question is should those 65% support it? >Without open discussion in the forum I don't = >think this question can be answered adequately. I think this is a SIP WG question, not an ECRIT question. An advocate needs to write a draft, it can be = discussed in ECRIT, but it has to be IMO = discussed in SIP to fully vet the SIP protocol modification question. >Cheers >James > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of > > Marc Linsner > > Sent: Wednesday, 16 July 2008 9:51 AM > > To: g.caron@bell.ca; br@brianrosen.net; ecrit@ietf.org > > Subject: Re: [Ecrit] Request for agenda time to discuss emergency > > calltermination > > > > Guy, > > > > Thanks for the update. I obviously haven't kept up on every national > > variant of SS7. Regardless, I believe the cellular network is based on > > IS41 > > which is a derivative of the base CCITT spec. > > > > It depends on what functionality you are believing is possible. IMO, > > there > > is quite a difference in not responding to SIP BYE and 'taking control'= of > > the far-end SIP UA. > > > > The fact remains that 65% of 911 calls do not support CPH. > > > > -Marc- > > > > > Marc, > > > > > > I have to interject here. > > > > > > First, CPH is supported in SS7 signaling today (see ANSI T1.666) and > > vendors > > > have implemented it. > > > > > > Second, the fact that CPH is *currently* used in Canada and Japan (th= ere > > may > > > be others too!) should provide enough evidence that the feature is n= ot > > > antiquated. > > > > > > What was born from technology limitations in the early days has becom= e a > > very > > > much appreciated feature for some PSAPs while evolving to E9-1-1. They > > just > > > don't want to loose it if it is technically possible. And this > > discussion is > > > telling me it could be possible. > > > > > > Thanks, > > > ______________ > > > Guy Caron > > > Bell Canada > > > (418) 691-1119 > > > > > > ----- Message d'origine ----- > > > De : ecrit-bounces@ietf.org > > > =C0 : Brian Rosen ; ecrit@ietf.org > > > Envoy=E9 : Tue Jul 15 18:23:39 2008 > > > Objet : Re: [Ecrit] Request for agenda time to discuss emergency > > > calltermination > > > > > > Brian, > > > > > > > > > On 7/15/08 3:36 PM, "Brian Rosen" wrote: > > > > > >>>> Nah, they don't do it because they didn't have to discuss it with = the > > >>>> emergency guys before they designed the networks. > > >>> > > >>> And your evidence for this is what, exactly? That they patterned > > >>> the network behavior on the ISDN behavior? Did the ISDN > > >>> folks also not talk to the emergency guys? Or did the emergency > > >>> guys they talked to say something different from what you > > >>> think they are saying now? > > >> > > >> I will give you a dozen old timers in the PSAP world who will tell y= ou > > that > > >> they howled and screamed when the telcos took away called party hold. > > > > > > CPH was necessary in the electro-mechanical switch days. There was no > > CDR, > > > no way to post mortem trace a call. CPH to the PSAPs started to fade= as > > 'E' > > > 9-1-1 was rolled out. As the PSAPs gained a way to identify the call= er, > > the > > > need for CPH became less important. Apparently, some PSAPs have foun= d a > > use > > > for CPH in addition to having ANI/ALI. Of course, they only have this > > > feature on 35% of the 9-1-1 calls. > > > > > > Malicious Call Hold used CPH also, but it went by the way of CDRs from > > > modern digital switches. Hence, the courts accept switch CDRs as > > evidence. > > > > > > I don't believe CPH is supported on SS7, hence this may be the reason > > > cellular doesn't support it as it's based on a derivative of SS7 (IS4= 1?). > > > > > > So, my assertion is that CPH is only supported on CAS (channel > > associated > > > signaling) trunks. CCS (common channel signaling) doesn't support su= ch. > > > SIP is CCS, not CAS. (I wish it were that easy :^) > > > > > > Bottom line, CPH is a very antiquated feature. > > > > > > -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 > >--------------------------------------------------------------------------= ---------------------- >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 Tue Jul 15 23:20:29 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D8C93A6864; Tue, 15 Jul 2008 23:20: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 A72693A6892 for ; Tue, 15 Jul 2008 23:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.253 X-Spam-Level: X-Spam-Status: No, score=-1.253 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 OyqVZBpQKyqf for ; Tue, 15 Jul 2008 23:20:26 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 6111C3A6829 for ; Tue, 15 Jul 2008 23:20:25 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_07_16_01_36_02 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, 16 Jul 2008 01:36:01 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jul 2008 01:20:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Jul 2008 01:20:47 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Request for agenda time to discuss emergency calltermination Thread-Index: AcjnCa1t2Slg3fUEQ9SiscODy1snXQAAld4w References: <2DE9A51895931C4CBCAEFA9306AE480E3D7BE0@toroondc254.bell.corp.bce.ca> From: "Winterbottom, James" To: "James M. Polk" , "Marc Linsner" , , , X-OriginalArrivalTime: 16 Jul 2008 06:20:50.0178 (UTC) FILETIME=[179BF620:01C8E70C] Subject: Re: [Ecrit] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Not that I really mind too much, but wouldn't the requirements come from EC= RIT but the solution come SIP? Cheers James > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Wednesday, 16 July 2008 4:03 PM > To: Winterbottom, James; Marc Linsner; g.caron@bell.ca; br@brianrosen.net; > ecrit@ietf.org > Subject: Re: [Ecrit] Request for agenda time to discuss emergency > calltermination > = > At 06:54 PM 7/15/2008, Winterbottom, James wrote: > >I think that greater question is should those 65% support it? > >Without open discussion in the forum I don't > >think this question can be answered adequately. > = > I think this is a SIP WG question, not an ECRIT question. > = > An advocate needs to write a draft, it can be > discussed in ECRIT, but it has to be IMO > discussed in SIP to fully vet the SIP protocol modification question. > = > = > >Cheers > >James > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > > Marc Linsner > > > Sent: Wednesday, 16 July 2008 9:51 AM > > > To: g.caron@bell.ca; br@brianrosen.net; ecrit@ietf.org > > > Subject: Re: [Ecrit] Request for agenda time to discuss emergency > > > calltermination > > > > > > Guy, > > > > > > Thanks for the update. I obviously haven't kept up on every national > > > variant of SS7. Regardless, I believe the cellular network is based > on > > > IS41 > > > which is a derivative of the base CCITT spec. > > > > > > It depends on what functionality you are believing is possible. IMO, > > > there > > > is quite a difference in not responding to SIP BYE and 'taking > control' of > > > the far-end SIP UA. > > > > > > The fact remains that 65% of 911 calls do not support CPH. > > > > > > -Marc- > > > > > > > Marc, > > > > > > > > I have to interject here. > > > > > > > > First, CPH is supported in SS7 signaling today (see ANSI T1.666) and > > > vendors > > > > have implemented it. > > > > > > > > Second, the fact that CPH is *currently* used in Canada and Japan > (there > > > may > > > > be others too!) should provide enough evidence that the feature is > not > > > > antiquated. > > > > > > > > What was born from technology limitations in the early days has > become a > > > very > > > > much appreciated feature for some PSAPs while evolving to E9-1-1. > They > > > just > > > > don't want to loose it if it is technically possible. And this > > > discussion is > > > > telling me it could be possible. > > > > > > > > Thanks, > > > > ______________ > > > > Guy Caron > > > > Bell Canada > > > > (418) 691-1119 > > > > > > > > ----- Message d'origine ----- > > > > De : ecrit-bounces@ietf.org > > > > =C0 : Brian Rosen ; ecrit@ietf.org > > > > Envoy=E9 : Tue Jul 15 18:23:39 2008 > > > > Objet : Re: [Ecrit] Request for agenda time to discuss emergency > > > > calltermination > > > > > > > > Brian, > > > > > > > > > > > > On 7/15/08 3:36 PM, "Brian Rosen" wrote: > > > > > > > >>>> Nah, they don't do it because they didn't have to discuss it with > the > > > >>>> emergency guys before they designed the networks. > > > >>> > > > >>> And your evidence for this is what, exactly? That they patterned > > > >>> the network behavior on the ISDN behavior? Did the ISDN > > > >>> folks also not talk to the emergency guys? Or did the emergency > > > >>> guys they talked to say something different from what you > > > >>> think they are saying now? > > > >> > > > >> I will give you a dozen old timers in the PSAP world who will tell > you > > > that > > > >> they howled and screamed when the telcos took away called party > hold. > > > > > > > > CPH was necessary in the electro-mechanical switch days. There was > no > > > CDR, > > > > no way to post mortem trace a call. CPH to the PSAPs started to > fade as > > > 'E' > > > > 9-1-1 was rolled out. As the PSAPs gained a way to identify the > caller, > > > the > > > > need for CPH became less important. Apparently, some PSAPs have > found a > > > use > > > > for CPH in addition to having ANI/ALI. Of course, they only have > this > > > > feature on 35% of the 9-1-1 calls. > > > > > > > > Malicious Call Hold used CPH also, but it went by the way of CDRs > from > > > > modern digital switches. Hence, the courts accept switch CDRs as > > > evidence. > > > > > > > > I don't believe CPH is supported on SS7, hence this may be the > reason > > > > cellular doesn't support it as it's based on a derivative of SS7 > (IS41?). > > > > > > > > So, my assertion is that CPH is only supported on CAS (channel > > > associated > > > > signaling) trunks. CCS (common channel signaling) doesn't support > such. > > > > SIP is CCS, not CAS. (I wish it were that easy :^) > > > > > > > > Bottom line, CPH is a very antiquated feature. > > > > > > > > -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 > > > >------------------------------------------------------------------------- > ----------------------- > >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 Jul 15 23:48:48 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2F013A6979; Tue, 15 Jul 2008 23:48: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 EC52A3A63CB for ; Tue, 15 Jul 2008 23:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.881 X-Spam-Level: X-Spam-Status: No, score=-5.881 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luQGhoZI5SCh for ; Tue, 15 Jul 2008 23:48:45 -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 8EEE03A6979 for ; Tue, 15 Jul 2008 23:48:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,371,1212364800"; d="scan'208";a="127296451" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 16 Jul 2008 06:49:14 +0000 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 m6G6nEGe004107; Tue, 15 Jul 2008 23:49:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6G6nEUq023170; Wed, 16 Jul 2008 06:49:14 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, 15 Jul 2008 23:49:14 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.94.233]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 23:49:13 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 16 Jul 2008 01:49:17 -0500 To: "Winterbottom, James" , "Marc Linsner" , , , From: "James M. Polk" In-Reply-To: References: <2DE9A51895931C4CBCAEFA9306AE480E3D7BE0@toroondc254.bell.corp.bce.ca> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 16 Jul 2008 06:49:13.0952 (UTC) FILETIME=[0F233E00:01C8E710] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7070; t=1216190954; x=1217054954; 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]=20Request=20for=20agenda=20time =20to=20discuss=20emergency=20=0A=20=20calltermination |Sender:=20; bh=Hsf6RqWYzG2e787X+TKsxAwNii0ZwkfD+FzZOTc2iY0=; b=m713nIiBgJUHP8dZgzUEuHeq6kieZ4L7wL5e4Ym3D8D5Xw77GSWuJ7HaSX nURzRCtr6vdLrMOnTydVT4WBHALKpVoVTWG7Os6law5giEZgnjMbkA5wDrDn 8BlU6ENU55DoctRjde7+W/cqAIamZ/CwRSq9l8/hcF9h8haZp7DD4=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 01:20 AM 7/16/2008, Winterbottom, James wrote: >Not that I really mind too much, but wouldn't = >the requirements come from ECRIT but the solution come SIP? I think this would work, understanding that SIP = might not think this is a good idea. >Cheers >James > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Wednesday, 16 July 2008 4:03 PM > > To: Winterbottom, James; Marc Linsner; g.caron@bell.ca; br@brianrosen.n= et; > > ecrit@ietf.org > > Subject: Re: [Ecrit] Request for agenda time to discuss emergency > > calltermination > > > > At 06:54 PM 7/15/2008, Winterbottom, James wrote: > > >I think that greater question is should those 65% support it? > > >Without open discussion in the forum I don't > > >think this question can be answered adequately. > > > > I think this is a SIP WG question, not an ECRIT question. > > > > An advocate needs to write a draft, it can be > > discussed in ECRIT, but it has to be IMO > > discussed in SIP to fully vet the SIP protocol modification question. > > > > > > >Cheers > > >James > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Beh= alf > > Of > > > > Marc Linsner > > > > Sent: Wednesday, 16 July 2008 9:51 AM > > > > To: g.caron@bell.ca; br@brianrosen.net; ecrit@ietf.org > > > > Subject: Re: [Ecrit] Request for agenda time to discuss emergency > > > > calltermination > > > > > > > > Guy, > > > > > > > > Thanks for the update. I obviously haven't kept up on every nation= al > > > > variant of SS7. Regardless, I believe the cellular network is based > > on > > > > IS41 > > > > which is a derivative of the base CCITT spec. > > > > > > > > It depends on what functionality you are believing is possible. IM= O, > > > > there > > > > is quite a difference in not responding to SIP BYE and 'taking > > control' of > > > > the far-end SIP UA. > > > > > > > > The fact remains that 65% of 911 calls do not support CPH. > > > > > > > > -Marc- > > > > > > > > > Marc, > > > > > > > > > > I have to interject here. > > > > > > > > > > First, CPH is supported in SS7 signaling today (see ANSI T1.666) = and > > > > vendors > > > > > have implemented it. > > > > > > > > > > Second, the fact that CPH is *currently* used in Canada and Japan > > (there > > > > may > > > > > be others too!) should provide enough evidence that the feature = is > > not > > > > > antiquated. > > > > > > > > > > What was born from technology limitations in the early days has > > become a > > > > very > > > > > much appreciated feature for some PSAPs while evolving to E9-1-1. > > They > > > > just > > > > > don't want to loose it if it is technically possible. And this > > > > discussion is > > > > > telling me it could be possible. > > > > > > > > > > Thanks, > > > > > ______________ > > > > > Guy Caron > > > > > Bell Canada > > > > > (418) 691-1119 > > > > > > > > > > ----- Message d'origine ----- > > > > > De : ecrit-bounces@ietf.org > > > > > =C0 : Brian Rosen ; ecrit@ietf.org > > > > > Envoy=E9 : Tue Jul 15 18:23:39 2008 > > > > > Objet : Re: [Ecrit] Request for agenda time to discuss emergency > > > > > calltermination > > > > > > > > > > Brian, > > > > > > > > > > > > > > > On 7/15/08 3:36 PM, "Brian Rosen" wrote: > > > > > > > > > >>>> Nah, they don't do it because they didn't have to discuss it w= ith > > the > > > > >>>> emergency guys before they designed the networks. > > > > >>> > > > > >>> And your evidence for this is what, exactly? That they patterned > > > > >>> the network behavior on the ISDN behavior? Did the ISDN > > > > >>> folks also not talk to the emergency guys? Or did the emergency > > > > >>> guys they talked to say something different from what you > > > > >>> think they are saying now? > > > > >> > > > > >> I will give you a dozen old timers in the PSAP world who will te= ll > > you > > > > that > > > > >> they howled and screamed when the telcos took away called party > > hold. > > > > > > > > > > CPH was necessary in the electro-mechanical switch days. There w= as > > no > > > > CDR, > > > > > no way to post mortem trace a call. CPH to the PSAPs started to > > fade as > > > > 'E' > > > > > 9-1-1 was rolled out. As the PSAPs gained a way to identify the > > caller, > > > > the > > > > > need for CPH became less important. Apparently, some PSAPs have > > found a > > > > use > > > > > for CPH in addition to having ANI/ALI. Of course, they only have > > this > > > > > feature on 35% of the 9-1-1 calls. > > > > > > > > > > Malicious Call Hold used CPH also, but it went by the way of CDRs > > from > > > > > modern digital switches. Hence, the courts accept switch CDRs as > > > > evidence. > > > > > > > > > > I don't believe CPH is supported on SS7, hence this may be the > > reason > > > > > cellular doesn't support it as it's based on a derivative of SS7 > > (IS41?). > > > > > > > > > > So, my assertion is that CPH is only supported on CAS (channel > > > > associated > > > > > signaling) trunks. CCS (common channel signaling) doesn't support > > such. > > > > > SIP is CCS, not CAS. (I wish it were that easy :^) > > > > > > > > > > Bottom line, CPH is a very antiquated feature. > > > > > > > > > > -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 > > > > > >----------------------------------------------------------------------= --- > > ----------------------- > > >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 Jul 16 02:31:35 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775C53A689D; Wed, 16 Jul 2008 02:31: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 852463A689D for ; Wed, 16 Jul 2008 02:31: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=[AWL=0.000, 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 tKNPWFbGfEf9 for ; Wed, 16 Jul 2008 02:31:33 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 5F2AC3A6820 for ; Wed, 16 Jul 2008 02:31:33 -0700 (PDT) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m6G9VogV003577; Wed, 16 Jul 2008 04:31:50 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jul 2008 04:31:50 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jul 2008 11:31:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Jul 2008 11:31:45 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800210E276@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Request for agenda time to discuss emergency calltermination Thread-Index: AcjnCba11Z13PRSZT32Hph0Qq8FKaAAHJGoQ References: <2DE9A51895931C4CBCAEFA9306AE480E3D7BE0@toroondc254.bell.corp.bce.ca> From: "DRAGE, Keith \(Keith\)" To: "James M. Polk" , "Winterbottom, James" , "Marc Linsner" , , , X-OriginalArrivalTime: 16 Jul 2008 09:31:46.0563 (UTC) FILETIME=[C4259530:01C8E726] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [Ecrit] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 everyone is agreed that we need to get requirements that elucidate = what problem is actually solved for these PSAPs. SIP does not draft requirements except for security issues. Therefore I think it is appropriate for ECRIT to identify and achieve conse= nsus on a list of requirements. Once we have that, a allocation of work on = a solution to those requirements can be discussed between the various invol= ved WG chairs and the ADs. Regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] = > On Behalf Of James M. Polk > Sent: Wednesday, July 16, 2008 7:03 AM > To: Winterbottom, James; Marc Linsner; g.caron@bell.ca; = > br@brianrosen.net; ecrit@ietf.org > Subject: Re: [Ecrit] Request for agenda time to discuss = > emergency calltermination > = > At 06:54 PM 7/15/2008, Winterbottom, James wrote: > >I think that greater question is should those 65% support it? > >Without open discussion in the forum I don't think this = > question can be = > >answered adequately. > = > I think this is a SIP WG question, not an ECRIT question. > = > An advocate needs to write a draft, it can be discussed in = > ECRIT, but it has to be IMO discussed in SIP to fully vet the = > SIP protocol modification question. > = > = > >Cheers > >James > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = > > > Behalf Of Marc Linsner > > > Sent: Wednesday, 16 July 2008 9:51 AM > > > To: g.caron@bell.ca; br@brianrosen.net; ecrit@ietf.org > > > Subject: Re: [Ecrit] Request for agenda time to discuss emergency = > > > calltermination > > > > > > Guy, > > > > > > Thanks for the update. I obviously haven't kept up on every = > > > national variant of SS7. Regardless, I believe the = > cellular network = > > > is based on > > > IS41 > > > which is a derivative of the base CCITT spec. > > > > > > It depends on what functionality you are believing is possible. = > > > IMO, there is quite a difference in not responding to SIP BYE and = > > > 'taking control' of the far-end SIP UA. > > > > > > The fact remains that 65% of 911 calls do not support CPH. > > > > > > -Marc- > > > > > > > Marc, > > > > > > > > I have to interject here. > > > > > > > > First, CPH is supported in SS7 signaling today (see = > ANSI T1.666) = > > > > and > > > vendors > > > > have implemented it. > > > > > > > > Second, the fact that CPH is *currently* used in Canada = > and Japan = > > > > (there > > > may > > > > be others too!) should provide enough evidence that = > the feature = > > > > is not antiquated. > > > > > > > > What was born from technology limitations in the early days has = > > > > become a > > > very > > > > much appreciated feature for some PSAPs while evolving = > to E9-1-1. = > > > > They > > > just > > > > don't want to loose it if it is technically possible. And this > > > discussion is > > > > telling me it could be possible. > > > > > > > > Thanks, > > > > ______________ > > > > Guy Caron > > > > Bell Canada > > > > (418) 691-1119 > > > > > > > > ----- Message d'origine ----- > > > > De : ecrit-bounces@ietf.org =C0 : Brian = > > > > Rosen ; ecrit@ietf.org = > Envoy=E9 = > > > > : Tue Jul 15 18:23:39 2008 Objet : Re: [Ecrit] Request = > for agenda = > > > > time to discuss emergency calltermination > > > > > > > > Brian, > > > > > > > > > > > > On 7/15/08 3:36 PM, "Brian Rosen" wrote: > > > > > > > >>>> Nah, they don't do it because they didn't have to discuss it = > > > >>>> with the emergency guys before they designed the networks. > > > >>> > > > >>> And your evidence for this is what, exactly? That = > they patterned = > > > >>> the network behavior on the ISDN behavior? Did the = > ISDN folks = > > > >>> also not talk to the emergency guys? Or did the = > emergency guys = > > > >>> they talked to say something different from what you = > think they = > > > >>> are saying now? > > > >> > > > >> I will give you a dozen old timers in the PSAP world who will = > > > >> tell you > > > that > > > >> they howled and screamed when the telcos took away = > called party hold. > > > > > > > > CPH was necessary in the electro-mechanical switch days. There = > > > > was no > > > CDR, > > > > no way to post mortem trace a call. CPH to the PSAPs = > started to = > > > > fade as > > > 'E' > > > > 9-1-1 was rolled out. As the PSAPs gained a way to = > identify the = > > > > caller, > > > the > > > > need for CPH became less important. Apparently, some = > PSAPs have = > > > > found a > > > use > > > > for CPH in addition to having ANI/ALI. Of course, they = > only have = > > > > this feature on 35% of the 9-1-1 calls. > > > > > > > > Malicious Call Hold used CPH also, but it went by the = > way of CDRs = > > > > from modern digital switches. Hence, the courts accept switch = > > > > CDRs as > > > evidence. > > > > > > > > I don't believe CPH is supported on SS7, hence this may be the = > > > > reason cellular doesn't support it as it's based on a = > derivative of SS7 (IS41?). > > > > > > > > So, my assertion is that CPH is only supported on CAS (channel > > > associated > > > > signaling) trunks. CCS (common channel signaling) = > doesn't support such. > > > > SIP is CCS, not CAS. (I wish it were that easy :^) > > > > > > > > Bottom line, CPH is a very antiquated feature. > > > > > > > > -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 > > > >------------------------------------------------------------- > ---------- > >------------------------- 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 Wed Jul 16 06:05:15 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8C623A69C9; Wed, 16 Jul 2008 06:05: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 7AC883A69C9 for ; Wed, 16 Jul 2008 06:05:14 -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=[AWL=0.000, 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 WpG5iMCAYk8h for ; Wed, 16 Jul 2008 06:05:13 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 3CF0B3A688F for ; Wed, 16 Jul 2008 06:05:13 -0700 (PDT) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m6GD5WXE021262; Wed, 16 Jul 2008 08:05:33 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jul 2008 08:05:32 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jul 2008 15:05:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Jul 2008 15:05:28 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918002142490@DEEXC1U01.de.lucent.com> In-Reply-To: <0e6d01c8e6b2$18f7a870$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Request for agenda time to discuss emergency calltermination Thread-Index: AcjmpxU4C2lBn/04TUq5q5eSyvaeZwACanDQACSnmsA= References: <0db101c8e67c$ed5b83b0$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E0CA@DEEXC1U01.de.lucent.com> <0ddc01c8e68a$47c22400$640fa8c0@cis.neustar.com> <0e3701c8e699$85d54330$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E16C@DEEXC1U01.de.lucent.com> <0e4401c8e6a4$8b7a6b20$640fa8c0@cis.neustar.com> <0e6d01c8e6b2$18f7a870$640fa8c0@cis.neustar.com> From: "DRAGE, Keith \(Keith\)" To: "Brian Rosen" , "Ted Hardie" , , X-OriginalArrivalTime: 16 Jul 2008 13:05:30.0208 (UTC) FILETIME=[9FA28600:01C8E744] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [Ecrit] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 least from the 3GPP side, my understanding is that emergency calls were defined pretty much from day 1. You'll finf the EMERGENCY SETUP message in very early documents. My understanding is that for 3GPP networks, there is a tradeoff here, not a set of absolutes. The tradeoff is that retaining the emergency call requires retention of the radio access bearer. It was decided not to retain the radio access bearer (which on a CS call is kept all the time the call is in progress). If the radio access bearer is retained for emergency calls, or worse still for all calls, provision of more radio channels per cell site, or more cell sites would be required of the operators. The operators obviously won out against any regulators on this decision, particular given that the retention is a national capability anyway. Therefore you cannot assume that just because some PSAPs want it, it must be provided as a capability. Moreover from the operator side, any phone requirement that retains the radio access bearer unnecessarily in a network where this is not required to be supported will not be accepted. Now obviously the situation gets more complex in IMS over GPRS circumstances, but I think you will find the same cost tradeoff still applies. Regards Keith > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, July 15, 2008 8:37 PM > To: 'Ted Hardie'; DRAGE, Keith (Keith); ecrit@ietf.org; > marc.linsner@cisco.com > Subject: RE: [Ecrit] Request for agenda time to discuss > emergency calltermination > > > >Nah, they don't do it because they didn't have to discuss > it with the > > >emergency guys before they designed the networks. > > > > And your evidence for this is what, exactly? That they > patterned the > > network behavior on the ISDN behavior? Did the ISDN folks also not > > talk to the emergency guys? Or did the emergency guys they > talked to > > say something different from what you think they are saying now? > > I will give you a dozen old timers in the PSAP world who will > tell you that they howled and screamed when the telcos took > away called party hold. > > I will give you many more folks who learned how mobile > networks worked when the call started coming in. In fact, > the first discussions with the mobile guys and 9-1-1 are > eerily familiar (this isn't really a telephony service, its > not replacing wired phones, its not reliable and people won't > depend on it to call 9-1-1). > > > > > > >It's less resources in most circumstances to keep a call > up than to > > >tear > > it > > >down and re-establish it. The case here is that one end > is trying to > > >end the call and the other end is trying to keep the call up. The > > >best way > > to > > >solve that is leave the call up until they figure it out. > > > > Again, this presumes that the side wanting to keep the call > up has its > > preferences followed in all cases; as has already been pointed out, > > there are cases like anonymous emergency calls where this may be > > neither practical nor desirable. > Anonymity is not linked to called party hold. > > It's true that CPH is not used, or required, in some jurisdictions. > > I'm looking for a simple solution, and I bias complexity at > the PSAP to complexity at the UA. Its clear we need to > control this feature. What won't work, I don't think, is > Options negotiation. > > > > > > > > > >An emergency call should be identified by the UA, and it then knows > > whether > > >to suppress BYE. I suspect if we keep that rule, we > probably do need > > words > > >in -framework and -phonebcp that deal with the currently allowed > > >circumstance that a proxy detects the emergency dialstring. I > > >suspect > > that > > >if the UA doesn't detect the dial string, it doesn't suppress BYE. > > >Otherwise, that creates an attack vector. > > > > And how do you propose to let the UA know whether suppress BYE is > > expected by a particular PSAP? If it suppresses BYE and the PSAP > > doesn't expect/support that behavior, it's a flat waste, isn't it? > Well, first of all, I've agreed that requirements first, > solutions later is appropriate. > > What I proposed was all UAs suppress BYE, and all UAs signal > hook state. > > The PSAP end can then manually or automatically send BYE upon > receipt of on hook state. > > No negotiations. No optional behavior. No determining capabilities. > > If a jurisdiction does not want to support CPH, they return > BYE upon receipt of on-hook state automatically. > > > > > > > > >> But I do support that we identify the precise requirements, and > > >> understand those first. > > >Yah. > > > > Yep, we have solid agreement on that step at least. > > > > Ted > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 16 07:26:14 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2856B3A6913; Wed, 16 Jul 2008 07:26: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 B3C6B3A6978 for ; Wed, 16 Jul 2008 07:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 viZnikql+1lS for ; Wed, 16 Jul 2008 07:26:11 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 90C6D3A69CB for ; Wed, 16 Jul 2008 07:26:11 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KJ7xk-0006CG-8j; Wed, 16 Jul 2008 09:26:36 -0500 From: "Brian Rosen" To: "'DRAGE, Keith \(Keith\)'" , "'Ted Hardie'" , , References: <0db101c8e67c$ed5b83b0$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E0CA@DEEXC1U01.de.lucent.com> <0ddc01c8e68a$47c22400$640fa8c0@cis.neustar.com> <0e3701c8e699$85d54330$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E16C@DEEXC1U01.de.lucent.com> <0e4401c8e6a4$8b7a6b20$640fa8c0@cis.neustar.com> <0e6d01c8e6b2$18f7a870$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE2918002142490@DEEXC1U01.de.lucent.com> Date: Wed, 16 Jul 2008 10:26:36 -0400 Message-ID: <008f01c8e74f$f65be7b0$81d83d48@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjmpxU4C2lBn/04TUq5q5eSyvaeZwACanDQACSnmsAAArPtUA== In-Reply-To: <5D1A7985295922448D5550C94DE2918002142490@DEEXC1U01.de.lucent.com> 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] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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, I certainly agree that 3GPP mechanisms considered emergency calls from day 1. I do think PSAP participation in that effort was minimal, but you probably can't fault the operators or vendors for that. I think the notion that CPH on an emergency call is an unnecessary waste of radio bandwidth which would negatively affect capacity is an argument crying for statistics. To be real, the incidence of the problem would have to be something measured in unit calls per busy hour. I'd bet the actual statistic was more like 1/100 of a call per busy hour per MSC. Many PSAPs can go a day or more without needing to use CPH, although abandoned emergency calls in large cities happen pretty frequently. Lots of things we do with emergency calls have low incidence, but big impact when you need it. There also could be some tradeoffs associated with the interaction of CPH and non-initialized devices. A really important use for CPH is to help stop the incidence of inappropriate emergency calls from non-initialized devices. If you can't hang up such a call, you may not be so willing to place one. That might help everyone. Brian > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Wednesday, July 16, 2008 9:05 AM > To: Brian Rosen; Ted Hardie; ecrit@ietf.org; marc.linsner@cisco.com > Subject: RE: [Ecrit] Request for agenda time to discuss emergency > calltermination > > At least from the 3GPP side, my understanding is that emergency calls > were defined pretty much from day 1. You'll finf the EMERGENCY SETUP > message in very early documents. > > My understanding is that for 3GPP networks, there is a tradeoff here, > not a set of absolutes. > > The tradeoff is that retaining the emergency call requires retention of > the radio access bearer. It was decided not to retain the radio access > bearer (which on a CS call is kept all the time the call is in > progress). If the radio access bearer is retained for emergency calls, > or worse still for all calls, provision of more radio channels per cell > site, or more cell sites would be required of the operators. The > operators obviously won out against any regulators on this decision, > particular given that the retention is a national capability anyway. > > Therefore you cannot assume that just because some PSAPs want it, it > must be provided as a capability. Moreover from the operator side, any > phone requirement that retains the radio access bearer unnecessarily in > a network where this is not required to be supported will not be > accepted. Now obviously the situation gets more complex in IMS over GPRS > circumstances, but I think you will find the same cost tradeoff still > applies. > > Regards > > Keith > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, July 15, 2008 8:37 PM > > To: 'Ted Hardie'; DRAGE, Keith (Keith); ecrit@ietf.org; > > marc.linsner@cisco.com > > Subject: RE: [Ecrit] Request for agenda time to discuss > > emergency calltermination > > > > > >Nah, they don't do it because they didn't have to discuss > > it with the > > > >emergency guys before they designed the networks. > > > > > > And your evidence for this is what, exactly? That they > > patterned the > > > network behavior on the ISDN behavior? Did the ISDN folks also not > > > talk to the emergency guys? Or did the emergency guys they > > talked to > > > say something different from what you think they are saying now? > > > > I will give you a dozen old timers in the PSAP world who will > > tell you that they howled and screamed when the telcos took > > away called party hold. > > > > I will give you many more folks who learned how mobile > > networks worked when the call started coming in. In fact, > > the first discussions with the mobile guys and 9-1-1 are > > eerily familiar (this isn't really a telephony service, its > > not replacing wired phones, its not reliable and people won't > > depend on it to call 9-1-1). > > > > > > > > > > >It's less resources in most circumstances to keep a call > > up than to > > > >tear > > > it > > > >down and re-establish it. The case here is that one end > > is trying to > > > >end the call and the other end is trying to keep the call up. The > > > >best way > > > to > > > >solve that is leave the call up until they figure it out. > > > > > > Again, this presumes that the side wanting to keep the call > > up has its > > > preferences followed in all cases; as has already been pointed out, > > > there are cases like anonymous emergency calls where this may be > > > neither practical nor desirable. > > Anonymity is not linked to called party hold. > > > > It's true that CPH is not used, or required, in some jurisdictions. > > > > I'm looking for a simple solution, and I bias complexity at > > the PSAP to complexity at the UA. Its clear we need to > > control this feature. What won't work, I don't think, is > > Options negotiation. > > > > > > > > > > > > > > >An emergency call should be identified by the UA, and it then knows > > > whether > > > >to suppress BYE. I suspect if we keep that rule, we > > probably do need > > > words > > > >in -framework and -phonebcp that deal with the currently allowed > > > >circumstance that a proxy detects the emergency dialstring. I > > > >suspect > > > that > > > >if the UA doesn't detect the dial string, it doesn't suppress BYE. > > > >Otherwise, that creates an attack vector. > > > > > > And how do you propose to let the UA know whether suppress BYE is > > > expected by a particular PSAP? If it suppresses BYE and the PSAP > > > doesn't expect/support that behavior, it's a flat waste, isn't it? > > Well, first of all, I've agreed that requirements first, > > solutions later is appropriate. > > > > What I proposed was all UAs suppress BYE, and all UAs signal > > hook state. > > > > The PSAP end can then manually or automatically send BYE upon > > receipt of on hook state. > > > > No negotiations. No optional behavior. No determining capabilities. > > > > If a jurisdiction does not want to support CPH, they return > > BYE upon receipt of on-hook state automatically. > > > > > > > > > > > >> But I do support that we identify the precise requirements, and > > > >> understand those first. > > > >Yah. > > > > > > Yep, we have solid agreement on that step at least. > > > > > > Ted > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 16 08:28:35 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F338E28C0F7; Wed, 16 Jul 2008 08:28:34 -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 E6C4D28C0DD for ; Wed, 16 Jul 2008 08:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.67 X-Spam-Level: X-Spam-Status: No, score=-102.67 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 BSTb+D+tkjNH for ; Wed, 16 Jul 2008 08:28:33 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id E028E28C0DF for ; Wed, 16 Jul 2008 08:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1216222143; x=1247758143; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<008f01c8e74f$f65be7b0$8 1d83d48@cis.neustar.com>|References:=20=0D=0A=20<0db101c8e67c$ed5b83b0$640fa8c0@cis.n eustar.com>=0D=0A=20<5D1A7985295922448D5550C94DE291800210 E0CA@DEEXC1U01.de.lucent.com>=0D=0A=20<0ddc01c8e68a$47c22 400$640fa8c0@cis.neustar.com>=0D=0A=20=0D=0A=20<0e3701c8e699$85d54330$640fa8 c0@cis.neustar.com>=0D=0A=20<5D1A7985295922448D5550C94DE2 91800210E16C@DEEXC1U01.de.lucent.com>=0D=0A=20<0e4401c8e6 a4$8b7a6b20$640fa8c0@cis.neustar.com>=0D=0A=20=0D=0A=20<0e6d01c8e6b2$18f7a8 70$640fa8c0@cis.neustar.com>=0D=0A=20<5D1A7985295922448D5 550C94DE2918002142490@DEEXC1U01.de.lucent.com>=0D=0A=20<0 08f01c8e74f$f65be7b0$81d83d48@cis.neustar.com>|Date:=20We d,=2016=20Jul=202008=2008:28:39=20-0700|To:=20Brian=20Ros en=20,=0D=0A=20=20=20=20=20=20=20=20"' DRAGE,=20Keith=20(Keith)'"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"ecrit@ietf.org"=20,=0D=0A=20=20=20=20=20=20=20=20"marc.linsner @cisco.com"=20|From:=20Ted=20Hard ie=20|Subject:=20RE:=20[Ecrit]=20Req uest=20for=20agenda=20time=20to=20discuss=20emergency=20 =20=20=0D=0A=20calltermination|Content-Type:=20text/plain =3B=20charset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcAfee=3B i=3D"5200,2160,5339"=3B=20a=3D"4593206"; bh=0jsEmx7Q+ooh9Kg3unqU+dVPoacFrWYPJeiOqQmErQo=; b=xrCYSmQuCuIwV5v5ghLVBYRXj/4G5S91NLa6678EUqOrcwS5WF+LCU3u dUbaGdTgDYpwsxTCzeZLRYggk+ytjfnGj4Cmxuh97cQQYaSeSK5aatsCr Bppa5/gYV+tSh4hCIcMja6RS2ase7UkMU3uKLPrXmHyd8W+N3TqBwAbBP M=; X-IronPort-AV: E=McAfee;i="5200,2160,5339"; a="4593206" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jul 2008 08:28:44 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6GFSiYq026898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Jul 2008 08:28:44 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6GFSfCo028375 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 16 Jul 2008 08:28:43 -0700 (PDT) Received: from [76.126.61.44] (10.50.0.103) by qcmail1.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 16 Jul 2008 08:28:43 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <008f01c8e74f$f65be7b0$81d83d48@cis.neustar.com> References: <0db101c8e67c$ed5b83b0$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E0CA@DEEXC1U01.de.lucent.com> <0ddc01c8e68a$47c22400$640fa8c0@cis.neustar.com> <0e3701c8e699$85d54330$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E16C@DEEXC1U01.de.lucent.com> <0e4401c8e6a4$8b7a6b20$640fa8c0@cis.neustar.com> <0e6d01c8e6b2$18f7a870$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE2918002142490@DEEXC1U01.de.lucent.com> <008f01c8e74f$f65be7b0$81d83d48@cis.neustar.com> Date: Wed, 16 Jul 2008 08:28:39 -0700 To: Brian Rosen , "'DRAGE, Keith (Keith)'" , "ecrit@ietf.org" , "marc.linsner@cisco.com" From: Ted Hardie Subject: Re: [Ecrit] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 7:26 AM -0700 7/16/08, Brian Rosen wrote: >I think the notion that CPH on an emergency call is an unnecessary waste of >radio bandwidth which would negatively affect capacity is an argument crying >for statistics. But for those statistics to be useful, you'd need to have a mechanism to defined. As Keith's message indicated, a solution that forced the retention of radio bearers for all calls until the called party terminated the call or acknowledged termination would have the result that the radio bearer would be retained on all calls. That has a very much larger impact than a solution that clearly identifies which calls need this behavior, but the lower-impact solution space has a trade-off that you now have to have two code paths and a way for the terminal and probably the network to distinguish between them. >To be real, the incidence of the problem would have to be >something measured in unit calls per busy hour. I'd bet the actual >statistic was more like 1/100 of a call per busy hour per MSC. Many PSAPs >can go a day or more without needing to use CPH, although abandoned >emergency calls in large cities happen pretty frequently. Lots of things we >do with emergency calls have low incidence, but big impact when you need it. > >There also could be some tradeoffs associated with the interaction of CPH >and non-initialized devices. A really important use for CPH is to help stop >the incidence of inappropriate emergency calls from non-initialized devices. >If you can't hang up such a call, you may not be so willing to place one. >That might help everyone. I'd actually been thinking that these calls would make things much worse from a radio bearer perspective since they would all need CPH. Since the caller has only to say "Sorry, mis-dial" or the equivalent, I am not sure how much of a deterrent CPH would be. Actually rolling the police would be much more, since a lot of these are grey market phones. The costs on *that* are, of course, much, much higher. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 16 11:28:54 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C6D3A68B0; Wed, 16 Jul 2008 11:28: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 5CE963A68B0 for ; Wed, 16 Jul 2008 11:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 8gI4zolyFKS6 for ; Wed, 16 Jul 2008 11:28:52 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 71ABE3A687C for ; Wed, 16 Jul 2008 11:28:52 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KJBkZ-00018C-AK; Wed, 16 Jul 2008 13:29:15 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'DRAGE, Keith \(Keith\)'" , , References: <0db101c8e67c$ed5b83b0$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E0CA@DEEXC1U01.de.lucent.com> <0ddc01c8e68a$47c22400$640fa8c0@cis.neustar.com> <0e3701c8e699$85d54330$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E16C@DEEXC1U01.de.lucent.com> <0e4401c8e6a4$8b7a6b20$640fa8c0@cis.neustar.com> <0e6d01c8e6b2$18f7a870$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE2918002142490@DEEXC1U01.de.lucent.com> <008f01c8e74f$f65be7b0$81d83d48@cis.neustar.com> Date: Wed, 16 Jul 2008 14:29:18 -0400 Message-ID: <00d301c8e771$dda5cb10$81d83d48@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjnWKAlVd7uSjd1S9SmppCJbYMCKgAALNlQ 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] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 IETF protocols, we know which calls are emergency calls. In the current 3GPP PS mechanisms, the endpoint, and the network knows which calls are emergency calls. Only emergency calls would need CPH. In current CS, the network knows which calls are emergency calls, although the endpoints do not. Only emergency calls would need CPH. On non initialized phones, the only calls allowed are emergency calls. They need CPH. I don't see the problem. Brian > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Wednesday, July 16, 2008 11:29 AM > To: Brian Rosen; 'DRAGE, Keith (Keith)'; ecrit@ietf.org; > marc.linsner@cisco.com > Subject: RE: [Ecrit] Request for agenda time to discuss emergency > calltermination > > At 7:26 AM -0700 7/16/08, Brian Rosen wrote: > >I think the notion that CPH on an emergency call is an unnecessary waste > of > >radio bandwidth which would negatively affect capacity is an argument > crying > >for statistics. > > But for those statistics to be useful, you'd need to have a mechanism > to defined. As Keith's message indicated, a solution that forced > the retention of radio bearers for all calls until the called party > terminated the call or acknowledged termination would have the result > that the radio bearer would be retained on all calls. That has a very > much larger impact than a solution that clearly identifies which calls > need > this behavior, but the lower-impact solution space has a trade-off that > you now > have to have two code paths and a way for the terminal and probably the > network to distinguish between them. > > >To be real, the incidence of the problem would have to be > >something measured in unit calls per busy hour. I'd bet the actual > >statistic was more like 1/100 of a call per busy hour per MSC. Many > PSAPs > >can go a day or more without needing to use CPH, although abandoned > >emergency calls in large cities happen pretty frequently. Lots of things > we > >do with emergency calls have low incidence, but big impact when you need > it. > > > >There also could be some tradeoffs associated with the interaction of CPH > >and non-initialized devices. A really important use for CPH is to help > stop > >the incidence of inappropriate emergency calls from non-initialized > devices. > >If you can't hang up such a call, you may not be so willing to place one. > >That might help everyone. > > I'd actually been thinking that these calls would make things much worse > from a radio bearer perspective since they would all need CPH. Since the > caller has only to say "Sorry, mis-dial" or the equivalent, I am not sure > how much of a deterrent CPH would be. Actually rolling the police would > be much more, since a lot of these are grey market phones. The costs > on *that* are, of course, much, much higher. > > Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 17 01:54:58 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5590B3A6ADB; Thu, 17 Jul 2008 01:54: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 4E6AA3A6ADB for ; Thu, 17 Jul 2008 01:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cs386puUFb-T for ; Thu, 17 Jul 2008 01:54:56 -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 48B063A6A96 for ; Thu, 17 Jul 2008 01:54:55 -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 m6H8rtXd014225Thu, 17 Jul 2008 08:53:57 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1KJP7l-000Lvc-00; Thu, 17 Jul 2008 09:46:05 +0100 Date: Thu, 17 Jul 2008 09:46:04 +0100 From: "Clive D.W. Feather" To: Brian Rosen Message-ID: <20080717084604.GA83877@finch-staff-1.thus.net> References: <5D1A7985295922448D5550C94DE291800210E0CA@DEEXC1U01.de.lucent.com> <0ddc01c8e68a$47c22400$640fa8c0@cis.neustar.com> <0e3701c8e699$85d54330$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E16C@DEEXC1U01.de.lucent.com> <0e4401c8e6a4$8b7a6b20$640fa8c0@cis.neustar.com> <0e6d01c8e6b2$18f7a870$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE2918002142490@DEEXC1U01.de.lucent.com> <008f01c8e74f$f65be7b0$81d83d48@cis.neustar.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <008f01c8e74f$f65be7b0$81d83d48@cis.neustar.com> User-Agent: Mutt/1.5.3i Cc: marc.linsner@cisco.com, ecrit@ietf.org Subject: Re: [Ecrit] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 said: > I think the notion that CPH on an emergency call is an unnecessary waste of > radio bandwidth which would negatively affect capacity is an argument crying > for statistics. To be real, the incidence of the problem would have to be > something measured in unit calls per busy hour. According to one of my colleagues, the UK telcos handle: - approximately 15 million genuine 999/112 calls per year, plus - approximately 15 million silent 999/112 calls from mobiles per year, presumed to be from "locked" phones. I'll let you turn that into bandwidth figures for yourself. -- 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 Thu Jul 17 07:07:19 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5289A3A69DE; Thu, 17 Jul 2008 07:07: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 0DD543A69DD for ; Thu, 17 Jul 2008 07:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 KH1vEhn5PGoZ for ; Thu, 17 Jul 2008 07:07:17 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id E5E063A69C2 for ; Thu, 17 Jul 2008 07:07:16 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KJU90-00004t-Gq; Thu, 17 Jul 2008 09:07:42 -0500 From: "Brian Rosen" To: "'Clive D.W. Feather'" References: <5D1A7985295922448D5550C94DE291800210E0CA@DEEXC1U01.de.lucent.com> <0ddc01c8e68a$47c22400$640fa8c0@cis.neustar.com> <0e3701c8e699$85d54330$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE291800210E16C@DEEXC1U01.de.lucent.com> <0e4401c8e6a4$8b7a6b20$640fa8c0@cis.neustar.com> <0e6d01c8e6b2$18f7a870$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE2918002142490@DEEXC1U01.de.lucent.com> <008f01c8e74f$f65be7b0$81d83d48@cis.neustar.com> <20080717084604.GA83877@finch-staff-1.thus.net> Date: Thu, 17 Jul 2008 10:07:43 -0400 Message-ID: <01ce01c8e816$7d16cd30$81d83d48@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acjn6tmmxR6UNRc+QWmwV7cEBg8stwAKeSFQ In-Reply-To: <20080717084604.GA83877@finch-staff-1.thus.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: Cc: marc.linsner@cisco.com, ecrit@ietf.org Subject: Re: [Ecrit] Request for agenda time to discuss emergency calltermination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 many phones are there? Most importantly, how many calls to 999/112 in the busy hour and what is the fraction of those calls to other calls? You are making a capacity argument for the RAN. If the total volume of 999/112 calls vs other calls is a small fraction, you don't have a capacity issue if you increase the hold time of the 999/112 calls. UK statistics are a bit off from other countries because of the unfortunate dial string which is easier to accidentally dial. U.S. statistics are much better than that. There are some PSAPs collecting numbers because the regulator has opened an inquery into non initialized phones, so we may have some hard numbers. Informal numbers I know are less than 10%. Since the feature only holds the call when the user tries to hang up but the call taker is not ready to let it hang up, or in the case of a fraudulent or erroneous 9-1-1 call to determine if it's a genuine call, you have to look at the incidence of that event and the additional call hold time. For North American PSAPs, that's very small, a fraction of a percent of minutes. Again, the proposal allows automatic disconnect when handling BYE, if that is the desired action. Brian > -----Original Message----- > From: Clive D.W. Feather [mailto:clive@demon.net] > Sent: Thursday, July 17, 2008 4:46 AM > To: Brian Rosen > Cc: 'DRAGE, Keith (Keith)'; 'Ted Hardie'; ecrit@ietf.org; > marc.linsner@cisco.com > Subject: Re: [Ecrit] Request for agenda time to discuss emergency > calltermination > > Brian Rosen said: > > I think the notion that CPH on an emergency call is an unnecessary waste > of > > radio bandwidth which would negatively affect capacity is an argument > crying > > for statistics. To be real, the incidence of the problem would have to > be > > something measured in unit calls per busy hour. > > According to one of my colleagues, the UK telcos handle: > > - approximately 15 million genuine 999/112 calls per year, plus > - approximately 15 million silent 999/112 calls from mobiles per year, > presumed to be from "locked" phones. > > I'll let you turn that into bandwidth figures for yourself. > > -- > 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 Jul 21 04:54:10 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BB073A6A56; Mon, 21 Jul 2008 04:54: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 1F1623A6A52 for ; Mon, 21 Jul 2008 04:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.367 X-Spam-Level: X-Spam-Status: No, score=-5.367 tagged_above=-999 required=5 tests=[AWL=1.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDaaABXQedNe for ; Mon, 21 Jul 2008 04:54:08 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 0D0583A6A3A for ; Mon, 21 Jul 2008 04:54:07 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m6LBsjWE001287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Jul 2008 13:54:45 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m6LBsiI8011743 for ; Mon, 21 Jul 2008 13:54:44 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 13:54:44 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 13:54:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Jul 2008 14:54:43 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda Thread-Index: AcjrKJB7nMvg0oCBS+iwIRFDC4bxuA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 21 Jul 2008 11:54:43.0141 (UTC) FILETIME=[90404750:01C8EB28] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16044.007 X-TM-AS-Result: No-8.580000-8.000000-31 Subject: [Ecrit] =?utf-8?q?Spam=3A_Spam=3A_Agenda?= X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 uploaded a version of the agenda: http://www.ietf.org/proceedings/08jul/agenda/ecrit.txt Thanks to Roger for compiling it _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 23 04:21:02 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D4BD3A6AEA; Wed, 23 Jul 2008 04:21: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 5867C3A6AE8 for ; Wed, 23 Jul 2008 04:21:00 -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 Ul8IqWr5bxhd for ; Wed, 23 Jul 2008 04:20:59 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 603AC3A6AE1 for ; Wed, 23 Jul 2008 04:20:58 -0700 (PDT) Received: (qmail invoked by alias); 23 Jul 2008 11:21:40 -0000 Received: from unknown (EHLO [10.183.180.149]) [192.100.124.156] by mail.gmx.net (mp039) with SMTP; 23 Jul 2008 13:21:40 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+b8oEk82ubBhTeCANi9FdmXbdeDmXNxYd03b7tan X/7Ai4Gfqrov7S Message-ID: <48871444.7020706@gmx.net> Date: Wed, 23 Jul 2008 14:21:40 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: 'ECRIT' X-Y-GMX-Trusted: 0 X-FuHaFi: 0.82 Subject: [Ecrit] Reminder about ongoing WGLCs X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Please read and comment http://tools.ietf.org/html/draft-ietf-ecrit-location-hiding-req-00 http://tools.ietf.org/html/draft-ietf-ecrit-specifying-holes-00 Deadline: August 1, 2008 Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 24 09:03:56 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E0303A6A19; Thu, 24 Jul 2008 09:03: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 A2CEB3A6932 for ; Thu, 24 Jul 2008 09:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 S5ueB5-mQFk9 for ; Thu, 24 Jul 2008 09:03:55 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6F00D3A683B for ; Thu, 24 Jul 2008 09:03:54 -0700 (PDT) Received: (qmail invoked by alias); 24 Jul 2008 15:57:57 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp056) with SMTP; 24 Jul 2008 17:57:57 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/c+JhM6I/cGCxjX/bRgVAJyMu78EC3ug/j55uhwP 5eIRQ9FxJXKPLW Message-ID: <4888A680.4070506@gmx.net> Date: Thu, 24 Jul 2008 18:57:52 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: 'ECRIT' X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 Subject: [Ecrit] Our meeting next week X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org As you have noticed from the agenda http://www.ietf.org/proceedings/08jul/agenda/ecrit.txt we are going to have a tough meeting. With the rechartering discussion we are have to figure out where the group should be heading. In a discussion with Marc we thought it would be best to apply the following approach for the meeting. We, Marc and myself, are going to prepare a single slide per draft to highlight the idea of the proposed work. This should give the audience a quick overview. Then, we should use the remaining time to discuss what we should do in the group in the future. Draft authors are obviously encouraged to join the discussion to add things and to answer the questions from the group. Does this sound like a good idea? Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 24 09:16:02 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B89E3A6889; Thu, 24 Jul 2008 09:16: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 186F33A6A0C for ; Thu, 24 Jul 2008 09:16:01 -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 hmt6BtvZYspD for ; Thu, 24 Jul 2008 09:16:00 -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 353033A6934 for ; Thu, 24 Jul 2008 09:16:00 -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 ; Thu, 24 Jul 2008 09:16:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 09:16:48 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750A5ECAF0@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <4888A680.4070506@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Our meeting next week Thread-Index: Acjtpvy5sAHBHcy0Tz2MIAxRduUE1QAAZ81Q References: <4888A680.4070506@gmx.net> From: "Roger Marshall" To: "Hannes Tschofenig" , "ECRIT" Subject: Re: [Ecrit] Our meeting next week X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 sounds reasonable. -roger. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Hannes Tschofenig > Sent: Thursday, July 24, 2008 8:58 AM > To: 'ECRIT' > Subject: [Ecrit] Our meeting next week > > As you have noticed from the agenda > http://www.ietf.org/proceedings/08jul/agenda/ecrit.txt > we are going to have a tough meeting. > > With the rechartering discussion we are have to figure out > where the group should be heading. In a discussion with Marc > we thought it would be best to apply the following approach > for the meeting. We, Marc and myself, are going to prepare a > single slide per draft to highlight the idea of the proposed > work. This should give the audience a quick overview. Then, > we should use the remaining time to discuss what we should do > in the group in the future. Draft authors are obviously > encouraged to join the discussion to add things and to answer > the questions from the group. > > Does this sound like a good idea? > > Ciao > Hannes & Marc > > > _______________________________________________ > 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 Thu Jul 24 12:30:18 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD9743A6A67; Thu, 24 Jul 2008 12: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 C68CD28C0E0 for ; Thu, 24 Jul 2008 12:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104 X-Spam-Level: X-Spam-Status: No, score=-104 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4, 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 PQu5qNPS1tSC for ; Thu, 24 Jul 2008 12:30:17 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.245.3]) by core3.amsl.com (Postfix) with ESMTP id D19393A6804 for ; Thu, 24 Jul 2008 12:30:13 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-11.tower-146.messagelabs.com!1216927807!6170791!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 27168 invoked from network); 24 Jul 2008 19:30:08 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-11.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 24 Jul 2008 19:30:07 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m6OJU7gQ008650 for ; Thu, 24 Jul 2008 15:30:07 -0400 Received: from 01GAF5142010623.AD.BLS.COM ([139.76.131.87]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with SMTP id m6OJTxMC008126 for ; Thu, 24 Jul 2008 15:30:00 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 24 Jul 2008 15:29:58 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 24 Jul 2008 15:29:58 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 15:29:57 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0A004E0B@crexc41p> In-Reply-To: <48871444.7020706@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Trivial comment on location-hiding-req thread-index: Acjstk8NLPgvfLruS0a/l/oM24tXLgBDL7jQ References: <48871444.7020706@gmx.net> From: "Stark, Barbara" To: "ECRIT" X-OriginalArrivalTime: 24 Jul 2008 19:29:58.0510 (UTC) FILETIME=[A8B810E0:01C8EDC3] Subject: [Ecrit] Trivial comment on location-hiding-req X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 the following requirement might read better if "fail, " were deleted. Req-9: UAs MUST NOT have to deduce the desired behavior by trial- and-error operations, such as LbyR resolutions, fail, as failures add latency during call setup. The solution MUST NOT significantly increase call setup latency. Other than that, I have no comments. Barbara ***** 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 Jul 28 20:26:22 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 996613A68DA; Mon, 28 Jul 2008 20:26: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 7107F3A6874; Mon, 28 Jul 2008 20:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.128 X-Spam-Level: X-Spam-Status: No, score=-1.128 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 vAJCdk3d+gM6; Mon, 28 Jul 2008 20:26:20 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 85EB93A698A; Mon, 28 Jul 2008 20:26:19 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_07_28_22_41_56 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, 28 Jul 2008 22:41:56 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 22:26:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 22:26:27 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Announce: Specifying Derived Location in a PIDF-LO Thread-Index: AcjxKuKe83koN3LKQsCn0+fcWF86xQ== From: "Winterbottom, James" To: X-OriginalArrivalTime: 29 Jul 2008 03:26:29.0637 (UTC) FILETIME=[E402D350:01C8F12A] Cc: ecrit@ietf.org Subject: [Ecrit] Announce: Specifying Derived Location in a PIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0950260879==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0950260879== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F12A.E383BEA8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F12A.E383BEA8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://tools.ietf.org/html/draft-winterbottom-geopriv-derived-loc-00=0D=0A=0D= =0A=20=0D=0A=0D=0ASpecifying Derived Location in a PIDF-LO=0D=0A=0D=0A=20=0D= =0A=0D=0AAbstract=0D=0A=20=0D=0A This document describes how specify that= a location in a PIDF-LO has=0D=0A been derived or converted from a diffe= rent location. The source=0D=0A location may reside in the same PIDF-LO = or be a remote document=0D=0A referenced by a location URI and associated= id fragement.=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0AFeedback appreciate= d.=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 may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C8F12A.E383BEA8 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

http://tools.ietf.org/html/draf= t-winterbottom-geopriv-derived-loc-00

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

Sp= ecifying Derived Location in a PIDF-LO

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

Abstract

&nbs=
p;
<=
span style=3D'font-size:10.0pt'>   This document describes how sp=
ecify that a location in a PIDF-LO has
<=
font=0D=0Asize=3D2 face=3D"Courier New">&n=
bsp;  been derived or converted from a different location.  The s=
ource
   location may reside in=
 the same PIDF-LO or be a remote document
   referenced by a location URI and associated id fragement.=0D=0A=0D=0A

 

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

 

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

 

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

Cheers

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

 

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


-----------------------= -------------------------------------------------------------------------=0D=0AThis message is for the designated re= cipient only and may
=0D=0Acontain privileged, = proprietary, or otherwise private information. &nb= sp;
=0D=0AIf you have received it in error= , please notify the sender
=0D=0Aimmediately an= d delete the original.  Any unauthorized = ;use of
=0D=0Athis email is prohibited.
=0D=0A---= ---------------------------------------------------------------------------= ------------------
=0D=0A[mf2]=0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01C8F12A.E383BEA8-- --===============0950260879== 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 --===============0950260879==-- From ecrit-bounces@ietf.org Tue Jul 29 03:31:20 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB6103A6B41; Tue, 29 Jul 2008 03:31: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 64E3E3A6B4B for ; Tue, 29 Jul 2008 03:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 LSwUak2VNXMj for ; Tue, 29 Jul 2008 03:31:19 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 211353A6B41 for ; Tue, 29 Jul 2008 03:31:18 -0700 (PDT) Received: (qmail invoked by alias); 29 Jul 2008 10:31:29 -0000 Received: from unknown (EHLO [130.129.20.103]) [130.129.20.103] by mail.gmx.net (mp039) with SMTP; 29 Jul 2008 12:31:29 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19smYVTFKRsWejpYVpul629bAbf+JMTxCiWPag7F6 cBMaCwdNtFcLEp Message-ID: <488EF181.8080105@gmx.net> Date: Tue, 29 Jul 2008 13:31:29 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Winterbottom, James" References: In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.74 Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in a PIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Sounds like a useful way to indicate the derived location Winterbottom, James wrote: > > http://tools.ietf.org/html/draft-winterbottom-geopriv-derived-loc-00 > > > > Specifying Derived Location in a PIDF-LO > > > > Abstract > > This document describes how specify that a location in a PIDF-LO has > been derived or converted from a different location. The source > location may reside in the same PIDF-LO or be a remote document > referenced by a location URI and associated id fragement. > > > > > > Feedback appreciated. > > > > Cheers > > James > > > > > > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > ------------------------------------------------------------------------ > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 29 05:21:44 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E52C28C171; Tue, 29 Jul 2008 05:21: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 6605B28C17A; Tue, 29 Jul 2008 05:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Za93E9xeF6zZ; Tue, 29 Jul 2008 05:21:42 -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 80ED128C106; Tue, 29 Jul 2008 05:21:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,272,1215388800"; d="scan'208";a="58877478" Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-1.cisco.com with ESMTP; 29 Jul 2008 12:21:51 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id m6TCLpm7005136; Tue, 29 Jul 2008 05:21:51 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6TCLpb8017055; Tue, 29 Jul 2008 12:21:51 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 05:21:51 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.149.41]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 05:21:46 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 29 Jul 2008 07:21:49 -0500 To: Hannes Tschofenig , "Winterbottom, James" From: "James M. Polk" In-Reply-To: <488EF181.8080105@gmx.net> References: <488EF181.8080105@gmx.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 29 Jul 2008 12:21:46.0917 (UTC) FILETIME=[AB66D550:01C8F175] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1901; t=1217334111; x=1218198111; c=relaxed/simple; s=sjdkim6002; 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]=20[Geopriv]=20Announce=3A=20Spe cifying=20Derived=20Location=20in=0A=20=20a=20PIDF-LO |Sender:=20; bh=9ki9YOPHqfa4/7D2cADuwrGD3thDJW3Q9R6R+lr46Ns=; b=ln87uyiZUOaxhnScGFMLyy0imcfCljT2Idgrkortars51RatQkUYyGVjxI tsZJtFbuVf7lddg0Yc9TSW6rJvdUoHbNR6c0Yz4gUKKJHJnWIaFDEzSJj5Hh h6y2Ml+jd0; Authentication-Results: sj-dkim-6; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in a PIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 05:31 AM 7/29/2008, Hannes Tschofenig wrote: >Sounds like a useful way to indicate the derived location this does not to me, as it greatly (almost doubles as far as I can see) the number of bytes in the LO. We shouldn't willfully put blinders up to the contraints of a viable, in fact built for, transport protocol (i.e., SIP and the considerations it has taken great lengths to go to towards MTU limitations of UDP over Ethernet). >Winterbottom, James wrote: >> >>http://tools.ietf.org/html/draft-winterbottom-geopriv-derived-loc-00 >> >> >> >>Specifying Derived Location in a PIDF-LO >> >> >> >>Abstract >> >> This document describes how specify that a location in a PIDF-LO has >> been derived or converted from a different location. The source >> location may reside in the same PIDF-LO or be a remote document >> referenced by a location URI and associated id fragement. >> >> >> >> >> >>Feedback appreciated. >> >> >> >>Cheers >> >>James >> >> >> >> >> >> >>------------------------------------------------------------------------------------------------ >>This message is for the designated recipient only and may >>contain privileged, proprietary, or otherwise private information. >>If you have received it in error, please notify the sender >>immediately and delete the original. Any unauthorized use of >>this email is prohibited. >>------------------------------------------------------------------------------------------------ >>[mf2] >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>Geopriv mailing list >>Geopriv@ietf.org >>https://www.ietf.org/mailman/listinfo/geopriv >> > >_______________________________________________ >Ecrit mailing 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 Jul 29 05:56:10 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8262528C27F; Tue, 29 Jul 2008 05:56: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 4FEDA28C231; Tue, 29 Jul 2008 05:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.143 X-Spam-Level: X-Spam-Status: No, score=-1.143 tagged_above=-999 required=5 tests=[AWL=0.060, 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 18luQmFs57Aq; Tue, 29 Jul 2008 05:56:08 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 355503A6852; Tue, 29 Jul 2008 05:56:08 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_07_29_08_11_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); Tue, 29 Jul 2008 08:11:47 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 07:56:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 07:53:54 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Geopriv] Announce: Specifying Derived Location in a PIDF-LO Thread-Index: Acjxda87lki4lBC1Q/ytQobrY3kKPQABHlGA References: <488EF181.8080105@gmx.net> From: "Winterbottom, James" To: "James M. Polk" , "Hannes Tschofenig" X-OriginalArrivalTime: 29 Jul 2008 12:56:20.0007 (UTC) FILETIME=[7F0F4370:01C8F17A] Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in a PIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 use a reference to an external location how is this doubling the size of the PIDF-LO? I also though that location information was generally only going be sent if TLS was used, which would rule out the use of UDP as a viable transport wouldn't it? Certainly I would be uncomfortable sending my location in an unencrypted UDP packet as I hardly think that that meets the general requirements of a using protocol. Cheers James -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Tue 7/29/2008 7:21 AM To: Hannes Tschofenig; Winterbottom, James Cc: geopriv@ietf.org; ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in a PIDF-LO At 05:31 AM 7/29/2008, Hannes Tschofenig wrote: >Sounds like a useful way to indicate the derived location this does not to me, as it greatly (almost doubles as far as I can see) the number of bytes in the LO. We shouldn't willfully put blinders up to the contraints of a viable, in fact built for, transport protocol (i.e., SIP and the considerations it has taken great lengths to go to towards MTU limitations of UDP over Ethernet). >Winterbottom, James wrote: >> >>http://tools.ietf.org/html/draft-winterbottom-geopriv-derived-loc-00 >> >> >> >>Specifying Derived Location in a PIDF-LO >> >> >> >>Abstract >> >> This document describes how specify that a location in a PIDF-LO has >> been derived or converted from a different location. The source >> location may reside in the same PIDF-LO or be a remote document >> referenced by a location URI and associated id fragement. >> >> >> >> >> >>Feedback appreciated. >> >> >> >>Cheers >> >>James >> >> >> >> >> >> >>------------------------------------------------------------------------------------------------ >>This message is for the designated recipient only and may >>contain privileged, proprietary, or otherwise private information. >>If you have received it in error, please notify the sender >>immediately and delete the original. Any unauthorized use of >>this email is prohibited. >>------------------------------------------------------------------------------------------------ >>[mf2] >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>Geopriv mailing list >>Geopriv@ietf.org >>https://www.ietf.org/mailman/listinfo/geopriv >> > >_______________________________________________ >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 Jul 29 05:59:07 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDE2328C29C; Tue, 29 Jul 2008 05:59: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 5309B28C298; Tue, 29 Jul 2008 05:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.153 X-Spam-Level: X-Spam-Status: No, score=-1.153 tagged_above=-999 required=5 tests=[AWL=0.050, 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 IND5n3ncITTE; Tue, 29 Jul 2008 05:59:01 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 2141528C27F; Tue, 29 Jul 2008 05:59:01 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_07_29_08_14_40 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, 29 Jul 2008 08:14:40 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 07:59:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 07:56:26 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO Thread-Index: AcjxZzSaFiJIO6WZRHiYjTcDfYJO3gADq8YwAAEn05Q= References: <488EF181.8080105@gmx.net> From: "Winterbottom, James" To: "Marc Berryman" , "Hannes Tschofenig" X-OriginalArrivalTime: 29 Jul 2008 12:59:12.0932 (UTC) FILETIME=[E6218640:01C8F17A] Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in a PIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Marc don't shoot the messenger. There was discussion in ECRIT that having a method of derived was a necessary thing. What I have tried to say is that if you are going to have that method then it is pretty important to know from what the location was derived. The draft basically provides you a way to tie the derived location back to the source, and it says that if you can't find the source then be careful of how much faith you put into the location. Yup, it has quite a few typos and grammatical problems that I will fix in the enxt rev. Cheers James -----Original Message----- From: Marc Berryman [mailto:MBerryman@911.org] Sent: Tue 7/29/2008 7:50 AM To: Hannes Tschofenig; Winterbottom, James Cc: geopriv@ietf.org; ecrit@ietf.org Subject: RE: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO I see very real issues with deriving a civic location from a geodetic location, when wireless geodetic locations became widely available this "reverse geocoding" caused many problems. Personally I see no value but many issues that can come about from a derived civic location. I will try to expand on these issues (while not being able to draw pictures to illustrate) from a "Lessons Learned" aspect. 1.) Geodetic location comes in and a civic location is derived from the nearest know civic location, but the geodetic location is centered on a building in a large campus or a large apartment building. The nearest civic location is the entrance to the large campus or apartment complex, so you have lost desirable information of the more precise location in favor of the civic location given to the campus or apartment building. 2.) Same scenario as above, but this time the nearest civic location is NOT the same as the civic location provided to the apartment complex or campus. The nearest civic location is provided and a delayed response is caused by providing the incorrect civic location. 3.) A geodetic location come in from a boat in the lake, river, or bay. The derived civic location is a home on the lake, river, or bay. Delayed response due to incorrect location being provided. 4.) Vehicle on interstate highway (limited access highway) provides geodetic location, derived civic location is along the highway but a delayed response takes place because not only is the civic location derived incorrect but the responding agency has to drive miles to gain access to the limited access highway when the correct responding agency is near the access point of the limited access highway. I could and can go on and on on scenarios that can (and have) occurred due to derived locations, but let me put forth another consideration. The service providing the derived location is using a spatial dataset, but it is not being maintained to the same level as the spatial data being used at the PSAP, out of date information is passed to the PSAP - LIBALITY ISSUE. We update our spatial data on a minute by minute basis, with literaily hundreds of changes taking place each day. There are just so many little differences that could exist between the derived location and the actual location provided by a trained call taker, that is familiar with the local geography, that this could easily become a disaster and gain major news coverage that could deal the industry and the confidence of the public a significant setback. Aside from these concerns I did notice a few gramatical inconsistancies in the draft. Thanks, Marc B -----Original Message----- From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, July 29, 2008 5:31 AM To: Winterbottom, James Cc: geopriv@ietf.org; ecrit@ietf.org Subject: Re: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO Sounds like a useful way to indicate the derived location Winterbottom, James wrote: > > http://tools.ietf.org/html/draft-winterbottom-geopriv-derived-loc-00 > > > > Specifying Derived Location in a PIDF-LO > > > > Abstract > > This document describes how specify that a location in a PIDF-LO has > been derived or converted from a different location. The source > location may reside in the same PIDF-LO or be a remote document > referenced by a location URI and associated id fragement. > > > > > > Feedback appreciated. > > > > Cheers > > James > > > > > > > ------------------------------------------------------------------------ ------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ ------------------------ > [mf2] > > ------------------------------------------------------------------------ > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv ------------------------------------------------------------------------------------------------ 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 Jul 29 06:09:15 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A75328C2B2; Tue, 29 Jul 2008 06:09: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 83CAF28C266 for ; Tue, 29 Jul 2008 06:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 s4lUwkCe3AFB for ; Tue, 29 Jul 2008 06:09:13 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id EAEAB28C2AF for ; Tue, 29 Jul 2008 06:09:12 -0700 (PDT) Received: (qmail invoked by alias); 29 Jul 2008 13:02:44 -0000 Received: from unknown (EHLO [130.129.20.103]) [130.129.20.103] by mail.gmx.net (mp031) with SMTP; 29 Jul 2008 15:02:44 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+1Om5gYyi1QjZPTKm2l6EPVjTjJhxH6DN6ol0S6/ MPnZG8BWywQKQB Message-ID: <488F14F1.8050208@gmx.net> Date: Tue, 29 Jul 2008 16:02:41 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "James M. Polk" References: <488EF181.8080105@gmx.net> In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in a PIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org When you want to convey information about * your derived location, and * the original information then this is a good way to go. I agree that XML isn't super small. I do, however, think that just providing a token saying that the current location is "derived" does not provide a lot of info for the recipient. Ciao Hannes James M. Polk wrote: > At 05:31 AM 7/29/2008, Hannes Tschofenig wrote: >> Sounds like a useful way to indicate the derived location > > this does not to me, as it greatly (almost doubles as far as I can > see) the number of bytes in the LO. > > We shouldn't willfully put blinders up to the contraints of a viable, > in fact built for, transport protocol (i.e., SIP and the > considerations it has taken great lengths to go to towards MTU > limitations of UDP over Ethernet). > > > > >> Winterbottom, James wrote: >>> >>> http://tools.ietf.org/html/draft-winterbottom-geopriv-derived-loc-00 >>> >>> >>> >>> Specifying Derived Location in a PIDF-LO >>> >>> >>> >>> Abstract >>> >>> This document describes how specify that a location in a PIDF-LO has >>> been derived or converted from a different location. The source >>> location may reside in the same PIDF-LO or be a remote document >>> referenced by a location URI and associated id fragement. >>> >>> >>> >>> >>> >>> Feedback appreciated. >>> >>> >>> >>> Cheers >>> >>> James >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------------------------ >>> >>> This message is for the designated recipient only and may >>> contain privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender >>> immediately and delete the original. Any unauthorized use of >>> this email is prohibited. >>> ------------------------------------------------------------------------------------------------ >>> >>> [mf2] >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www.ietf.org/mailman/listinfo/geopriv >>> >> >> _______________________________________________ >> Ecrit mailing 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 Jul 29 06:10:43 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 756F028C2B9; Tue, 29 Jul 2008 06:10: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 4445B28C2B4; Tue, 29 Jul 2008 06:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id od7vrA8cs-eG; Tue, 29 Jul 2008 06:10:41 -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 BA30728C2B2; Tue, 29 Jul 2008 06:10:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,272,1215388800"; d="scan'208";a="58898089" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 29 Jul 2008 13:10:53 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m6TDAr3D021244; Tue, 29 Jul 2008 06:10:53 -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.13.8/8.13.8) with ESMTP id m6TDArCx029758; Tue, 29 Jul 2008 13:10:53 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); Tue, 29 Jul 2008 06:10:52 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.149.41]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 06:10:52 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 29 Jul 2008 08:10:47 -0500 To: "Winterbottom, James" , "Hannes Tschofenig" From: "James M. Polk" In-Reply-To: References: <488EF181.8080105@gmx.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 29 Jul 2008 13:10:52.0364 (UTC) FILETIME=[870660C0:01C8F17C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4013; t=1217337053; x=1218201053; 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[Geopriv]=20[Ecrit]=20Announce=3A=20Spe cifying=20Derived=20Location=20in=0A=20=20a=20PIDF-LO |Sender:=20; bh=ogtJnAUq2aAsq0Za0Z+xoxrWVqjDjX65eyCpt37IKe4=; b=cwBKqzhAo7Ad5PivDefwbjEBaaPEbMd8gn4ngUUarECN2dasHzePa6YeRX Q2gaJ9oSQEqKkkuZwHbwWDkHFEUzkay5CV6KrXDiGhjzwjYaOtOjKv0ZXZ4B sES/49eWrE; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in a PIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 07:53 AM 7/29/2008, Winterbottom, James wrote: >If I use a reference to an external location how is this doubling >the size of the PIDF-LO? Are there 2 (as in TWO) elements? that doubles the size I see 2 in the example IN YOUR ID... you've made this point in a previous message and I still see TWO elements, where there should be only one in as many cases as we we can limit this isn't *just* a URI element added to what's already there in the LO >I also though that location information was generally only going be >sent if TLS was used, which would rule out the use of UDP as a >viable transport wouldn't it? Certainly I would be uncomfortable >sending my location in an unencrypted UDP packet as I hardly think >that that meets the general requirements of a using protocol. James, YOU keep making these points as if everyone has YOUR values and uses protocols only YOUR way. Are you (as a single entity) representative of the entire human race? >Cheers >James > > > > > >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: Tue 7/29/2008 7:21 AM >To: Hannes Tschofenig; Winterbottom, James >Cc: geopriv@ietf.org; ecrit@ietf.org >Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location >in a PIDF-LO > >At 05:31 AM 7/29/2008, Hannes Tschofenig wrote: > >Sounds like a useful way to indicate the derived location > >this does not to me, as it greatly (almost doubles as far as I can >see) the number of bytes in the LO. > >We shouldn't willfully put blinders up to the contraints of a viable, >in fact built for, transport protocol (i.e., SIP and the >considerations it has taken great lengths to go to towards MTU >limitations of UDP over Ethernet). > > > > > >Winterbottom, James wrote: > >> > >>http://tools.ietf.org/html/draft-winterbottom-geopriv-derived-loc-00 > >> > >> > >> > >>Specifying Derived Location in a PIDF-LO > >> > >> > >> > >>Abstract > >> > >> This document describes how specify that a location in a PIDF-LO has > >> been derived or converted from a different location. The source > >> location may reside in the same PIDF-LO or be a remote document > >> referenced by a location URI and associated id fragement. > >> > >> > >> > >> > >> > >>Feedback appreciated. > >> > >> > >> > >>Cheers > >> > >>James > >> > >> > >> > >> > >> > >> > >>------------------------------------------------------------------ > ------------------------------ > >>This message is for the designated recipient only and may > >>contain privileged, proprietary, or otherwise private information. > >>If you have received it in error, please notify the sender > >>immediately and delete the original. Any unauthorized use of > >>this email is prohibited. > >>------------------------------------------------------------------ > ------------------------------ > >>[mf2] > >> > >>------------------------------------------------------------------------ > >> > >>_______________________________________________ > >>Geopriv mailing list > >>Geopriv@ietf.org > >>https://www.ietf.org/mailman/listinfo/geopriv > >> > > > >_______________________________________________ > >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] > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 29 06:20:07 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21DCA28C2C1; Tue, 29 Jul 2008 06:20: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 BBF9528C2BD for ; Tue, 29 Jul 2008 06:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 CmbIz7riEVat for ; Tue, 29 Jul 2008 06:20:05 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 30FDC28C2B7 for ; Tue, 29 Jul 2008 06:20:04 -0700 (PDT) Received: (qmail invoked by alias); 29 Jul 2008 13:13:36 -0000 Received: from unknown (EHLO [130.129.20.103]) [130.129.20.103] by mail.gmx.net (mp066) with SMTP; 29 Jul 2008 15:13:36 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/xvmYxX8XxgtU9tvnmMOuxdhz1QzkY5blDfOGkdI Tcr0x+oydJwh9i Message-ID: <488F177F.1020305@gmx.net> Date: Tue, 29 Jul 2008 16:13:35 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Marc Berryman References: <488EF181.8080105@gmx.net> In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55 Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in a PIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Marc, I agree with you that re-coding isn't the ideal solution. Now, the question is: What do we do when someone still does it? We are = not the deployment police. Should we indicate the fact that re-coding has happened? How should we = indicate it? Ciao Hannes Marc Berryman wrote: > > I see very real issues with deriving a civic location from a geodetic = > location, when wireless geodetic locations became widely available = > this =93reverse geocoding=94 caused many problems. Personally I see no = > value but many issues that can come about from a derived civic location. > > I will try to expand on these issues (while not being able to draw = > pictures to illustrate) from a =93Lessons Learned=94 aspect. > > 1.) Geodetic location comes in and a civic location is derived from = > the nearest know civic location, but the geodetic location is centered = > on a building in a large campus or a large apartment building. The = > nearest civic location is the entrance to the large campus or = > apartment complex, so you have lost desirable information of the more = > precise location in favor of the civic location given to the campus or = > apartment building. > > 2.) Same scenario as above, but this time the nearest civic location = > is NOT the same as the civic location provided to the apartment = > complex or campus. The nearest civic location is provided and a = > delayed response is caused by providing the incorrect civic location. > > 3.) A geodetic location come in from a boat in the lake, river, or = > bay. The derived civic location is a home on the lake, river, or bay. = > Delayed response due to incorrect location being provided. > > 4.) Vehicle on interstate highway (limited access highway) provides = > geodetic location, derived civic location is along the highway but a = > delayed response takes place because not only is the civic location = > derived incorrect but the responding agency has to drive miles to gain = > access to the limited access highway when the correct responding = > agency is near the access point of the limited access highway. > > I could and can go on and on on scenarios that can (and have) occurred = > due to derived locations, but let me put forth another consideration. > > The service providing the derived location is using a spatial dataset, = > but it is not being maintained to the same level as the spatial data = > being used at the PSAP, out of date information is passed to the PSAP = > - LIBALITY ISSUE. We update our spatial data on a minute by minute = > basis, with literaily hundreds of changes taking place each day. There = > are just so many little differences that could exist between the = > derived location and the actual location provided by a trained call = > taker, that is familiar with the local geography, that this could = > easily become a disaster and gain major news coverage that could deal = > the industry and the confidence of the public a significant setback. > > Aside from these concerns I did notice a few gramatical = > inconsistancies in the draft. > > Thanks, > > Marc B > > -----Original Message----- > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On = > Behalf Of Hannes Tschofenig > Sent: Tuesday, July 29, 2008 5:31 AM > To: Winterbottom, James > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: Re: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO > > Sounds like a useful way to indicate the derived location > > Winterbottom, James wrote: > > > > > > http://tools.ietf.org/html/draft-winterbottom-geopriv-derived-loc-00 > > > > > > > > > > > > Specifying Derived Location in a PIDF-LO > > > > > > > > > > > > Abstract > > > > > > This document describes how specify that a location in a PIDF-LO has > > > been derived or converted from a different location. The source > > > location may reside in the same PIDF-LO or be a remote document > > > referenced by a location URI and associated id fragement. > > > > > > > > > > > > > > > > > > Feedback appreciated. > > > > > > > > > > > > Cheers > > > > > > James > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------------------= ------------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > -----------------------------------------------------------------------= ------------------------- > > > [mf2] > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www.ietf.org/mailman/listinfo/geopriv > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 29 06:25:40 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 409683A6AD4; Tue, 29 Jul 2008 06:25: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 25F073A69F9 for ; Tue, 29 Jul 2008 06:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 IN-l8AMYPC-I for ; Tue, 29 Jul 2008 06:25:38 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D2AF23A6A34 for ; Tue, 29 Jul 2008 06:25:37 -0700 (PDT) Received: (qmail invoked by alias); 29 Jul 2008 13:25:49 -0000 Received: from unknown (EHLO [130.129.20.103]) [130.129.20.103] by mail.gmx.net (mp058) with SMTP; 29 Jul 2008 15:25:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/3DkV+oBf3ajWpLLudncDLKm5bCLoXLIisJ0xZTs GG8PnTQbZMzrU2 Message-ID: <488F1A5D.6000001@gmx.net> Date: Tue, 29 Jul 2008 16:25:49 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "James M. Polk" References: <488EF181.8080105@gmx.net> In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6899999999999999 Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in a PIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > >> I also though that location information was generally only going be >> sent if TLS was used, which would rule out the use of UDP as a viable >> transport wouldn't it? Certainly I would be uncomfortable sending my >> location in an unencrypted UDP packet as I hardly think that that >> meets the general requirements of a using protocol. > > James, YOU keep making these points as if everyone has YOUR values and > uses protocols only YOUR way. Are you (as a single entity) > representative of the entire human race? > I am not sure why you guys are arguing around on this issue. * We know that location information is encoded in XML and not particularly small. * We also know that there are security issues with passing location information around. Hence, we use security protocols. What we should think about is whether it makes sense to indicate that location was derived. If you want to indicate that location was derived then there is the question on how to express that fact. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 29 06:31:07 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4162D28C2EC; Tue, 29 Jul 2008 06:31: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 09E2E28C165; Tue, 29 Jul 2008 05:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yq9zyJWc-JzQ; Tue, 29 Jul 2008 05:50:46 -0700 (PDT) Received: from mail1.911.org (mail1.911.org [65.67.130.186]) by core3.amsl.com (Postfix) with ESMTP id A08D828C176; Tue, 29 Jul 2008 05:50:45 -0700 (PDT) Received: from ghcmail [192.168.6.230] by mail1.911.org - SurfControl E-mail Filter (5.5.0); Tue, 29 Jul 2008 07:53:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 07:50:54 -0500 Message-ID: In-Reply-To: <488EF181.8080105@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO Thread-Index: AcjxZzSaFiJIO6WZRHiYjTcDfYJO3gADq8Yw References: <488EF181.8080105@gmx.net> From: "Marc Berryman" To: "Hannes Tschofenig" , "Winterbottom, James" X-SEF-7853D99-ADF1-478E-8894-213D316B8FFA: 1 X-SEF-Processed: 5_5_0_191__2008_07_29_07_53_24 X-Mailman-Approved-At: Tue, 29 Jul 2008 06:31:05 -0700 Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in a PIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0345919274==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0345919274== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F179.BD12B0C8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F179.BD12B0C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I see very real issues with deriving a civic location from a geodetic location, when wireless geodetic locations became widely available this "reverse geocoding" caused many problems. Personally I see no value but many issues that can come about from a derived civic location. =20 I will try to expand on these issues (while not being able to draw pictures to illustrate) from a "Lessons Learned" aspect. =20 1.) Geodetic location comes in and a civic location is derived from the nearest know civic location, but the geodetic location is centered on a building in a large campus or a large apartment building. The nearest civic location is the entrance to the large campus or apartment complex, so you have lost desirable information of the more precise location in favor of the civic location given to the campus or apartment building. =20 2.) Same scenario as above, but this time the nearest civic location is NOT the same as the civic location provided to the apartment complex or campus. The nearest civic location is provided and a delayed response is caused by providing the incorrect civic location. =20 3.) A geodetic location come in from a boat in the lake, river, or bay. The derived civic location is a home on the lake, river, or bay. Delayed response due to incorrect location being provided. =20 4.) Vehicle on interstate highway (limited access highway) provides geodetic location, derived civic location is along the highway but a delayed response takes place because not only is the civic location derived incorrect but the responding agency has to drive miles to gain access to the limited access highway when the correct responding agency is near the access point of the limited access highway. =20 I could and can go on and on on scenarios that can (and have) occurred due to derived locations, but let me put forth another consideration.=20 =20 The service providing the derived location is using a spatial dataset, but it is not being maintained to the same level as the spatial data being used at the PSAP, out of date information is passed to the PSAP - LIBALITY ISSUE. We update our spatial data on a minute by minute basis, with literaily hundreds of changes taking place each day. There are just so many little differences that could exist between the derived location and the actual location provided by a trained call taker, that is familiar with the local geography, that this could easily become a disaster and gain major news coverage that could deal the industry and the confidence of the public a significant setback. =20 Aside from these concerns I did notice a few gramatical inconsistancies in the draft. =20 Thanks, Marc B =20 -----Original Message----- From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, July 29, 2008 5:31 AM To: Winterbottom, James Cc: geopriv@ietf.org; ecrit@ietf.org Subject: Re: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO =20 Sounds like a useful way to indicate the derived location =20 =20 =20 Winterbottom, James wrote: >=20 > http://tools.ietf.org/html/draft-winterbottom-geopriv-derived-loc-00 >=20 > =20 >=20 > Specifying Derived Location in a PIDF-LO >=20 > =20 >=20 > Abstract > =20 > This document describes how specify that a location in a PIDF-LO has > been derived or converted from a different location. The source > location may reside in the same PIDF-LO or be a remote document > referenced by a location URI and associated id fragement. >=20 > =20 >=20 > =20 >=20 > Feedback appreciated. >=20 > =20 >=20 > Cheers >=20 > James >=20 > =20 >=20 >=20 >=20 >=20 > ------------------------------------------------------------------------ ------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ ------------------------ > [mf2] >=20 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > =20 =20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv =20 ------_=_NextPart_001_01C8F179.BD12B0C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I see very real issues with deriving a civic = location from a geodetic location, when wireless geodetic locations became widely available this “reverse geocoding” caused many problems. = Personally I see no value but many issues that can come about from a derived civic location.

 

I will try to expand on these issues (while = not being able to draw pictures to illustrate) from a “Lessons = Learned” aspect.

 

1.) Geodetic location comes in and a civic = location is derived from the nearest know civic location, but the geodetic location = is centered on a building in a large campus or a large apartment building. = The nearest civic location is the entrance to the large campus or apartment complex, so you have lost desirable information of the more precise = location in favor of the civic location given to the campus or apartment = building.

 

2.) Same scenario as above, but this time the = nearest civic location is NOT the same as the civic location provided to the = apartment complex or campus. The nearest civic location is provided and a delayed response is caused by providing the incorrect civic = location.

 

3.) A geodetic location come in from a boat = in the lake, river,  or bay. The derived civic location is a home on the = lake, river, or bay. Delayed response due to incorrect location being = provided.

 

4.) Vehicle on interstate highway (limited = access highway) provides geodetic location, derived civic location is along the highway but a delayed response takes place because not only is the civic location derived incorrect but the responding agency has to drive miles = to gain access to the limited access highway when the correct responding agency = is near the access point of the limited access = highway.

 

I could and can go on and on on scenarios = that can (and have) occurred due to derived locations, but let me put forth = another consideration.

 

The service providing the derived location is = using a spatial dataset, but it is not being maintained to the same level as the spatial data being used at the PSAP, out of date information is passed = to the PSAP - LIBALITY ISSUE. We update our spatial data on a minute by minute = basis, with literaily hundreds of changes taking place each day. There are just = so many little differences that could exist between the derived location = and the actual location provided by a trained call taker, that is familiar with = the local geography, that this could easily become a disaster and gain major = news coverage that could deal the industry and the confidence of the public a = significant setback.

 

Aside from these concerns I did notice a few gramatical inconsistancies in the draft.

 

Thanks,

 Marc B

 

-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On = Behalf Of Hannes Tschofenig
Sent: Tuesday, July 29, 2008 5:31 AM
To: Winterbottom, James
Cc: geopriv@ietf.org; ecrit@ietf.org
Subject: Re: [Geopriv] Announce: Specifying Derived Location in a = PIDF-LO

 

Sounds like a useful way to indicate the = derived location

 

 

 

Winterbottom, James = wrote:

> 

> http://tools.ietf.org/html/draft-winterbottom-geopriv-derived-loc-00=

> 

> 

> 

> Specifying Derived Location in a = PIDF-LO

> 

> 

> 

> Abstract

> 

>    This document = describes how specify that a location in a PIDF-LO has

>    been derived or = converted from a different location.  The source

>    location may reside in = the same PIDF-LO or be a remote document

>    referenced by a = location URI and associated id fragement.

> 

> 

> 

> 

> 

> Feedback = appreciated.

> 

> 

> 

> Cheers

> 

> James

> 

> 

> 

> 

> 

> 

> -------------------------------------------------------------------------= -----------------------

> This message is for the designated = recipient only and may

> contain privileged, proprietary, or = otherwise private information. 

> If you have received it in error, please = notify the sender

> immediately and delete the = original.  Any unauthorized use of

> this email is = prohibited.

> -------------------------------------------------------------------------= -----------------------

> [mf2]

> 

> ------------------------------------------------------------------------<= o:p>

> 

> = _______________________________________________<= /p>

> Geopriv mailing = list

> = Geopriv@ietf.org

> = https://www.ietf.org/mailman/listinfo/geopriv

>   =

 

______________________________________________= _

Geopriv mailing = list

Geopriv@ietf.org

https://www.ietf.org/mailman/listinfo/geopriv<= o:p>

 

------_=_NextPart_001_01C8F179.BD12B0C8-- --===============0345919274== 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 --===============0345919274==-- From ecrit-bounces@ietf.org Tue Jul 29 06:31:07 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6899228C2F0; Tue, 29 Jul 2008 06:31: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 3A1C43A6AB7; Tue, 29 Jul 2008 06:19: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=[AWL=0.001, 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 wrQ5knASRIav; Tue, 29 Jul 2008 06:19:37 -0700 (PDT) Received: from mail1.911.org (mail1.911.org [65.67.130.186]) by core3.amsl.com (Postfix) with ESMTP id 7A4493A69F9; Tue, 29 Jul 2008 06:19:37 -0700 (PDT) Received: from ghcmail [192.168.6.230] by mail1.911.org - SurfControl E-mail Filter (5.5.0); Tue, 29 Jul 2008 08:22:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 08:19:47 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO Thread-Index: AcjxZzSaFiJIO6WZRHiYjTcDfYJO3gADq8YwAAEn05QAAMfW8A== References: <488EF181.8080105@gmx.net> From: "Marc Berryman" To: "Winterbottom, James" , "Hannes Tschofenig" X-SEF-7853D99-ADF1-478E-8894-213D316B8FFA: 1 X-SEF-Processed: 5_5_0_191__2008_07_29_08_22_13 X-Mailman-Approved-At: Tue, 29 Jul 2008 06:31:05 -0700 Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in a PIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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, Did not intend to send flaming arrows toward the messenger, just pointing out the operational issues to the rest of the group. Marc B -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Tuesday, July 29, 2008 7:56 AM To: Marc Berryman; Hannes Tschofenig Cc: geopriv@ietf.org; ecrit@ietf.org Subject: RE: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO Marc don't shoot the messenger. There was discussion in ECRIT that having a method of derived was a necessary thing. What I have tried to say is that if you are going to have that method then it is pretty important to know from what the location was derived. The draft basically provides you a way to tie the derived location back to the source, and it says that if you can't find the source then be careful of how much faith you put into the location. Yup, it has quite a few typos and grammatical problems that I will fix in the enxt rev. Cheers James -----Original Message----- From: Marc Berryman [mailto:MBerryman@911.org] Sent: Tue 7/29/2008 7:50 AM To: Hannes Tschofenig; Winterbottom, James Cc: geopriv@ietf.org; ecrit@ietf.org Subject: RE: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO I see very real issues with deriving a civic location from a geodetic location, when wireless geodetic locations became widely available this "reverse geocoding" caused many problems. Personally I see no value but many issues that can come about from a derived civic location. I will try to expand on these issues (while not being able to draw pictures to illustrate) from a "Lessons Learned" aspect. 1.) Geodetic location comes in and a civic location is derived from the nearest know civic location, but the geodetic location is centered on a building in a large campus or a large apartment building. The nearest civic location is the entrance to the large campus or apartment complex, so you have lost desirable information of the more precise location in favor of the civic location given to the campus or apartment building. 2.) Same scenario as above, but this time the nearest civic location is NOT the same as the civic location provided to the apartment complex or campus. The nearest civic location is provided and a delayed response is caused by providing the incorrect civic location. 3.) A geodetic location come in from a boat in the lake, river, or bay. The derived civic location is a home on the lake, river, or bay. Delayed response due to incorrect location being provided. 4.) Vehicle on interstate highway (limited access highway) provides geodetic location, derived civic location is along the highway but a delayed response takes place because not only is the civic location derived incorrect but the responding agency has to drive miles to gain access to the limited access highway when the correct responding agency is near the access point of the limited access highway. I could and can go on and on on scenarios that can (and have) occurred due to derived locations, but let me put forth another consideration. The service providing the derived location is using a spatial dataset, but it is not being maintained to the same level as the spatial data being used at the PSAP, out of date information is passed to the PSAP - LIBALITY ISSUE. We update our spatial data on a minute by minute basis, with literaily hundreds of changes taking place each day. There are just so many little differences that could exist between the derived location and the actual location provided by a trained call taker, that is familiar with the local geography, that this could easily become a disaster and gain major news coverage that could deal the industry and the confidence of the public a significant setback. Aside from these concerns I did notice a few gramatical inconsistancies in the draft. Thanks, Marc B -----Original Message----- From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, July 29, 2008 5:31 AM To: Winterbottom, James Cc: geopriv@ietf.org; ecrit@ietf.org Subject: Re: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO Sounds like a useful way to indicate the derived location Winterbottom, James wrote: > > http://tools.ietf.org/html/draft-winterbottom-geopriv-derived-loc-00 > > > > Specifying Derived Location in a PIDF-LO > > > > Abstract > > This document describes how specify that a location in a PIDF-LO has > been derived or converted from a different location. The source > location may reside in the same PIDF-LO or be a remote document > referenced by a location URI and associated id fragement. > > > > > > Feedback appreciated. > > > > Cheers > > James > > > > > > > ------------------------------------------------------------------------ ------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ ------------------------ > [mf2] > > ------------------------------------------------------------------------ > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv ------------------------------------------------------------------------ ------------------------ 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 Jul 29 06:57:20 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B2B13A6A87; Tue, 29 Jul 2008 06:57: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 0FB433A69D6 for ; Tue, 29 Jul 2008 06:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hW1M3a9lLPzi for ; Tue, 29 Jul 2008 06:57:18 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 2E30128C16A for ; Tue, 29 Jul 2008 06:57:18 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KNphZ-0002rp-P8 for ecrit@ietf.org; Tue, 29 Jul 2008 08:57:22 -0500 From: "Brian Rosen" To: Date: Tue, 29 Jul 2008 09:57:23 -0400 Message-ID: <010301c8f183$094696d0$12178182@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjxfisFRJBqUAlwR4a+rR4j3ji8BQABHTcw 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: [Ecrit] FW: New Version Notification for draft-rosen-ecrit-premature-disconnect-rqmts-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 draft is the requirements for the "Called Party Hold" and related feature requests that relate to -phonebcp currently saying "don't send BYE". This is the only open item in -phonebcp, and I will discuss this issue in the slot in the ecrit agenda for -phonebcp. This document represents the consensus NENA view of what the problem is, since NENA raised the issue in the first place. Brian -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tuesday, July 29, 2008 9:22 AM To: br@brianrosen.net Subject: New Version Notification for draft-rosen-ecrit-premature-disconnect-rqmts-00 A new version of I-D, draft-rosen-ecrit-premature-disconnect-rqmts-00.txt has been successfuly submitted by Brian Rosen and posted to the IETF repository. Filename: draft-rosen-ecrit-premature-disconnect-rqmts Revision: 00 Title: Requirements for handling abandoned calls and premature disconnects in emergency calls on the Internet Creation_date: 2008-07-28 WG ID: Independent Submission Number_of_pages: 7 Abstract: The -phonebcp draft currently requires endpoints to disable sending a BYE on an emergency call. Insufficient justification and lack of attention to the entire problem has caused comment on that section of the document. This document attempts to define the problem and the requirements to controlling disconnect on emergency calls. The IETF Secretariat. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 29 07:04:47 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 241CC28C315; Tue, 29 Jul 2008 07:04: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 A975028C2E6; Tue, 29 Jul 2008 07:04:45 -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 vPE3BFcrtN1u; Tue, 29 Jul 2008 07:04:41 -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 A27B228C17C; Tue, 29 Jul 2008 07:04: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, 29 Jul 2008 07:04:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 07:04:39 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750A5EDA96@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO Thread-Index: AcjxfOyT1zQp5SikRSWT2ySycVYYBAABWbVQAAA2UqA= References: <488EF181.8080105@gmx.net><488F177F.1020305@gmx.net> From: "Roger Marshall" To: "Marc Berryman" , "Hannes Tschofenig" Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in a PIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 is right to point out that it is better to be clear than to assume. PIDF-LO has already has had capability of providing multiple locations - even more than 2. If there is a label 'derived', for one of them, there needs to be a identifier that points back to the original. This is better than guessing. -roger marshall. > -----Original Message----- > From: geopriv-bounces@ietf.org > [mailto:geopriv-bounces@ietf.org] On Behalf Of Marc Berryman > Sent: Tuesday, July 29, 2008 6:57 AM > To: Hannes Tschofenig > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: Re: [Geopriv] Announce: Specifying Derived Location > in a PIDF-LO > > As long as it clearly noted that the location is derived from > geodetic then I am fine. How to indicate? Provide both > geodetic and derived. If geodetic is provided then one can > safely assume the provided civic is derived (I would hope). > > Marc B > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, July 29, 2008 8:14 AM > To: Marc Berryman > Cc: Winterbottom, James; geopriv@ietf.org; ecrit@ietf.org > Subject: Re: [Geopriv] Announce: Specifying Derived Location > in a PIDF-LO > > Hi Marc, > > I agree with you that re-coding isn't the ideal solution. > Now, the question is: What do we do when someone still does > it? We are not the deployment police. > Should we indicate the fact that re-coding has happened? How > should we indicate it? > > Ciao > Hannes > > Marc Berryman wrote: > > > > I see very real issues with deriving a civic location from > a geodetic > > location, when wireless geodetic locations became widely available > > this "reverse geocoding" caused many problems. Personally I see no > > value but many issues that can come about from a derived civic > location. > > > > I will try to expand on these issues (while not being able to draw > > pictures to illustrate) from a "Lessons Learned" aspect. > > > > 1.) Geodetic location comes in and a civic location is derived from > > the nearest know civic location, but the geodetic location > is centered > > > on a building in a large campus or a large apartment building. The > > nearest civic location is the entrance to the large campus or > > apartment complex, so you have lost desirable information > of the more > > precise location in favor of the civic location given to > the campus or > > > apartment building. > > > > 2.) Same scenario as above, but this time the nearest civic > location > > is NOT the same as the civic location provided to the apartment > > complex or campus. The nearest civic location is provided and a > > delayed response is caused by providing the incorrect civic > location. > > > > 3.) A geodetic location come in from a boat in the lake, river, or > > bay. The derived civic location is a home on the lake, > river, or bay. > > Delayed response due to incorrect location being provided. > > > > 4.) Vehicle on interstate highway (limited access highway) provides > > geodetic location, derived civic location is along the > highway but a > > delayed response takes place because not only is the civic location > > derived incorrect but the responding agency has to drive > miles to gain > > > access to the limited access highway when the correct responding > > agency is near the access point of the limited access highway. > > > > I could and can go on and on on scenarios that can (and > have) occurred > > > due to derived locations, but let me put forth another > consideration. > > > > The service providing the derived location is using a > spatial dataset, > > > but it is not being maintained to the same level as the > spatial data > > being used at the PSAP, out of date information is passed > to the PSAP > > - LIBALITY ISSUE. We update our spatial data on a minute by minute > > basis, with literaily hundreds of changes taking place each > day. There > > > are just so many little differences that could exist between the > > derived location and the actual location provided by a trained call > > taker, that is familiar with the local geography, that this could > > easily become a disaster and gain major news coverage that > could deal > > the industry and the confidence of the public a significant setback. > > > > Aside from these concerns I did notice a few gramatical > > inconsistancies in the draft. > > > > Thanks, > > > > Marc B > > > > -----Original Message----- > > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On > > Behalf Of Hannes Tschofenig > > Sent: Tuesday, July 29, 2008 5:31 AM > > To: Winterbottom, James > > Cc: geopriv@ietf.org; ecrit@ietf.org > > Subject: Re: [Geopriv] Announce: Specifying Derived Location in a > PIDF-LO > > > > Sounds like a useful way to indicate the derived location > > > > Winterbottom, James wrote: > > > > > > > > > > > http://tools.ietf.org/html/draft-winterbottom-geopriv-derived-loc-00 > > > > > > > > > > > > > > > > > > > > Specifying Derived Location in a PIDF-LO > > > > > > > > > > > > > > > > > > > > Abstract > > > > > > > > > > This document describes how specify that a location in a > PIDF-LO has > > > > > been derived or converted from a different location. The source > > > > > location may reside in the same PIDF-LO or be a remote document > > > > > referenced by a location URI and associated id fragement. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Feedback appreciated. > > > > > > > > > > > > > > > > > > > > Cheers > > > > > > > > > > James > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > ---------- > ------------------------ > > > > > This message is for the designated recipient only and may > > > > > contain privileged, proprietary, or otherwise private information. > > > > > If you have received it in error, please notify the sender > > > > > immediately and delete the original. Any unauthorized use of > > > > > this email is prohibited. > > > > > > -------------------------------------------------------------- > ---------- > ------------------------ > > > > > [mf2] > > > > > > > > > > > -------------------------------------------------------------- > ---------- > > > > > > > > > > _______________________________________________ > > > > > Geopriv mailing list > > > > > Geopriv@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/geopriv > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www.ietf.org/mailman/listinfo/geopriv > > > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > 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 Jul 29 07:31:45 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 089FA28C2F7; Tue, 29 Jul 2008 07:31: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 374C128C2DA; Tue, 29 Jul 2008 07:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjSKtVHi9zmK; Tue, 29 Jul 2008 07:31:42 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 6D97728C231; Tue, 29 Jul 2008 07:31:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,272,1215388800"; d="scan'208";a="90835501" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 29 Jul 2008 14:31:52 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6TEVq0Q028460; Tue, 29 Jul 2008 07:31:52 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m6TEVpXN020359; Tue, 29 Jul 2008 14:31:52 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); Tue, 29 Jul 2008 07:31:37 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.149.41]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 07:31:36 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 29 Jul 2008 09:31:39 -0500 To: Hannes Tschofenig From: "James M. Polk" In-Reply-To: <488F1A5D.6000001@gmx.net> References: <488EF181.8080105@gmx.net> <488F1A5D.6000001@gmx.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 29 Jul 2008 14:31:36.0948 (UTC) FILETIME=[CE9F3B40:01C8F187] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1568; t=1217341912; x=1218205912; c=relaxed/simple; s=sjdkim4002; 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[Geopriv]=20[Ecrit]=20Announce=3A=20Spe cifying=20Derived=20Location=20in=0A=20=20=20a=20PIDF-LO |Sender:=20; bh=g+u8ORACfCVwYTdf6GCGS16HEQRx+97jtdfaVDv/ov4=; b=fzAZCwupVx90ju7lDuUiDUkpPJLoEijA4q3HlH8pxtAtXBrBDjturHck0B FH8E/uXWBLJoD0TIBMXyWEgYb1y6bo0oT3sfZbk97snjyFsTcppcjh/FTImy JWFOYAnboa; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in a PIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 08:25 AM 7/29/2008, Hannes Tschofenig wrote: >>>I also though that location information was generally only going >>>be sent if TLS was used, which would rule out the use of UDP as a >>>viable transport wouldn't it? Certainly I would be uncomfortable >>>sending my location in an unencrypted UDP packet as I hardly think >>>that that meets the general requirements of a using protocol. >> >>James, YOU keep making these points as if everyone has YOUR values >>and uses protocols only YOUR way. Are you (as a single entity) >>representative of the entire human race? > > >I am not sure why you guys are arguing around on this issue. > >* We know that location information is encoded in XML and not >particularly small. >* We also know that there are security issues with passing location >information around. Hence, we use security protocols. > >What we should think about is whether it makes sense to indicate >that location was derived. If you want to indicate that location was >derived then there is the question on how to express that fact. no it should be talked about in a way to determine whether this id done at all. I do not believe that someone can say "well, it's being done now, so we might as well standardize it"... that won't stop me (or someone else) from doing the same thing about another topic the rest of the WG might not like/accept. Some things ought to remain out of the standards, and I am not hearing a good enough reason to include this one in our efforts. >Ciao >Hannes > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 29 08:21:30 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 115763A6A4F; Tue, 29 Jul 2008 08:21: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 6F1EB3A6A4F for ; Tue, 29 Jul 2008 08:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7NyfczxfUjf for ; Tue, 29 Jul 2008 08:21:27 -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 852C03A680B for ; Tue, 29 Jul 2008 08:21:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,272,1215388800"; d="scan'208";a="70104583" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2008 15:21:39 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6TFLdvV011826; Tue, 29 Jul 2008 08:21:39 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m6TFLdgf005949; Tue, 29 Jul 2008 15:21:39 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, 29 Jul 2008 08:21:39 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.149.41]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 08:21:38 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 29 Jul 2008 10:21:41 -0500 To: "Brian Rosen" , From: "James M. Polk" In-Reply-To: <010301c8f183$094696d0$12178182@cis.neustar.com> References: <010301c8f183$094696d0$12178182@cis.neustar.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 29 Jul 2008 15:21:38.0573 (UTC) FILETIME=[CBBADBD0:01C8F18E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2607; t=1217344899; x=1218208899; 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]=20FW=3A=20draft-rosen-ecrit-pre mature-disconnect-rqmts-00 |Sender:=20; bh=DM67DQi+8+phpBXCEwXOVH96agYfFrSAYgU9wmdmC98=; b=Eu8wgJF4xesR51v4g5Lo9xNX/aWC59ucxDZUxhi+MOQqaH4I9Nqqq1xwS3 SgP4ZxGoJZDj2COeSgtdsEtE7k7B4WcRBB1wi4d264oihPl6K/llicAnxEfP W+WS12l2AIWhEcRPvxoRyiN4AXtMHwnZg/bWAi1w5ph4TxO1Fvm5c=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] FW: draft-rosen-ecrit-premature-disconnect-rqmts-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I believe that there a enough scenarios in which no matter what is specified, even if the protocol/mechanism is done right, will still fail to accomplish the intended affect. Therefore, I do not believe this effort should move forward and the WG needs specific implementation experience before we EVEN CONSIDER making this possible in any protocol or mechanism (for several reasons) -- especially a BCP-type guideline document. As much as this is needed in some jurisdictions, we just don't know how to do it at this time for nearly all cases. This, alone, is going to prevent phoneBCP *and* Framework from being RFC'd for more than a year. I do not at all believe this one function is worth delaying these two documents. That said, I believe this issue, by itself, should move forward towards a consensus solution *after* we reach consensus on the requirements. At 08:57 AM 7/29/2008, Brian Rosen wrote: >This draft is the requirements for the "Called Party Hold" and related >feature requests that relate to -phonebcp currently saying "don't send BYE". > >This is the only open item in -phonebcp, and I will discuss this issue in >the slot in the ecrit agenda for -phonebcp. > >This document represents the consensus NENA view of what the problem is, >since NENA raised the issue in the first place. > >Brian > >-----Original Message----- >From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >Sent: Tuesday, July 29, 2008 9:22 AM >To: br@brianrosen.net >Subject: New Version Notification for >draft-rosen-ecrit-premature-disconnect-rqmts-00 > > >A new version of I-D, draft-rosen-ecrit-premature-disconnect-rqmts-00.txt >has been successfuly submitted by Brian Rosen and posted to the IETF >repository. > >Filename: draft-rosen-ecrit-premature-disconnect-rqmts >Revision: 00 >Title: Requirements for handling abandoned calls and premature >disconnects in emergency calls on the Internet >Creation_date: 2008-07-28 >WG ID: Independent Submission >Number_of_pages: 7 > >Abstract: >The -phonebcp draft currently requires endpoints to disable sending a >BYE on an emergency call. Insufficient justification and lack of >attention to the entire problem has caused comment on that section of >the document. This document attempts to define the problem and the >requirements to controlling disconnect on emergency calls. > > > > >The IETF Secretariat. > > >_______________________________________________ >Ecrit mailing 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 Jul 29 08:39:53 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B6413A6BBF; Tue, 29 Jul 2008 08:39: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 AC5CC28C2DE; Tue, 29 Jul 2008 08:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.440, 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 IG4NVSpuFA2t; Tue, 29 Jul 2008 08:39:51 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 1A2703A6BBF; Tue, 29 Jul 2008 08:39:48 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KNrIo-0008IH-LY; Tue, 29 Jul 2008 10:39:55 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'James M. Polk'" References: <488EF181.8080105@gmx.net> <488F1A5D.6000001@gmx.net> Date: Tue, 29 Jul 2008 11:39:56 -0400 Message-ID: <014501c8f191$5c8fa990$12178182@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <488F1A5D.6000001@gmx.net> Thread-Index: Acjxf6+kb2Ho2EMZRY2IM37m6hqGqwAAaPcw 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: Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in a PIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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, no. All you need to specify that a location is derived is to have the method token set to derived. James thinks there is value in linking the derived PIDF to the original PIDF. That is a separate question. I think there is some merit in the basic idea of linking. I wonder if this is a specific case of a more general notion: expressing a relationship between two PIDFs? Brian > -----Original Message----- > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Tuesday, July 29, 2008 9:26 AM > To: James M. Polk > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: Re: [Geopriv] [Ecrit] Announce: Specifying Derived Location in a > PIDF-LO > > > > > >> I also though that location information was generally only going be > >> sent if TLS was used, which would rule out the use of UDP as a viable > >> transport wouldn't it? Certainly I would be uncomfortable sending my > >> location in an unencrypted UDP packet as I hardly think that that > >> meets the general requirements of a using protocol. > > > > James, YOU keep making these points as if everyone has YOUR values and > > uses protocols only YOUR way. Are you (as a single entity) > > representative of the entire human race? > > > > > I am not sure why you guys are arguing around on this issue. > > * We know that location information is encoded in XML and not > particularly small. > * We also know that there are security issues with passing location > information around. Hence, we use security protocols. > > What we should think about is whether it makes sense to indicate that > location was derived. If you want to indicate that location was derived > then there is the question on how to express that fact. > > Ciao > Hannes > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 29 08:48:47 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714EA28C355; Tue, 29 Jul 2008 08:48: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 768E928C34C; Tue, 29 Jul 2008 08:48:40 -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 PchtGFbDhgss; Tue, 29 Jul 2008 08:48:36 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 6F28D28C34B; Tue, 29 Jul 2008 08:48:35 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_07_29_11_04_15 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, 29 Jul 2008 11:04:15 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 10:48:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 10:48:46 -0500 Message-ID: In-Reply-To: <8C837214C95C864C9F34F3635C2A65750A5EDA96@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO Thread-Index: AcjxfOyT1zQp5SikRSWT2ySycVYYBAABWbVQAAA2UqAAARunMA== References: <488EF181.8080105@gmx.net><488F177F.1020305@gmx.net> <8C837214C95C864C9F34F3635C2A65750A5EDA96@SEA-EXCHVS-2.telecomsys.com> From: "Thomson, Martin" To: "Roger Marshall" , "Marc Berryman" , "Hannes Tschofenig" X-OriginalArrivalTime: 29 Jul 2008 15:48:47.0612 (UTC) FILETIME=[96B67BC0:01C8F192] Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in a PIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Read the draft folks. This is _exactly_ what the draft does: it defines how to indicate that a location is derived. It also specifies how to identify the location that it was derived from. Cheers, Martin > -----Original Message----- > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On > Behalf Of Roger Marshall > Sent: Tuesday, 29 July 2008 3:05 PM > To: Marc Berryman; Hannes Tschofenig > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: Re: [Geopriv] Announce: Specifying Derived Location in a PIDF- > LO > > Hannes is right to point out that it is better to be clear than to > assume. > > PIDF-LO has already has had capability of providing multiple locations > - > even more than 2. If there is a label 'derived', for one of them, > there > needs to be a identifier that points back to the original. This is > better than guessing. > > -roger marshall. > > > -----Original Message----- > > From: geopriv-bounces@ietf.org > > [mailto:geopriv-bounces@ietf.org] On Behalf Of Marc Berryman > > Sent: Tuesday, July 29, 2008 6:57 AM > > To: Hannes Tschofenig > > Cc: geopriv@ietf.org; ecrit@ietf.org > > Subject: Re: [Geopriv] Announce: Specifying Derived Location > > in a PIDF-LO > > > > As long as it clearly noted that the location is derived from > > geodetic then I am fine. How to indicate? Provide both > > geodetic and derived. If geodetic is provided then one can > > safely assume the provided civic is derived (I would hope). > > > > Marc B > > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Tuesday, July 29, 2008 8:14 AM > > To: Marc Berryman > > Cc: Winterbottom, James; geopriv@ietf.org; ecrit@ietf.org > > Subject: Re: [Geopriv] Announce: Specifying Derived Location > > in a PIDF-LO > > > > Hi Marc, > > > > I agree with you that re-coding isn't the ideal solution. > > Now, the question is: What do we do when someone still does > > it? We are not the deployment police. > > Should we indicate the fact that re-coding has happened? How > > should we indicate it? > > > > Ciao > > Hannes > > > > Marc Berryman wrote: > > > > > > I see very real issues with deriving a civic location from > > a geodetic > > > location, when wireless geodetic locations became widely available > > > this "reverse geocoding" caused many problems. Personally I see no > > > value but many issues that can come about from a derived civic > > location. > > > > > > I will try to expand on these issues (while not being able to draw > > > pictures to illustrate) from a "Lessons Learned" aspect. > > > > > > 1.) Geodetic location comes in and a civic location is derived from > > > the nearest know civic location, but the geodetic location > > is centered > > > > > on a building in a large campus or a large apartment building. The > > > nearest civic location is the entrance to the large campus or > > > apartment complex, so you have lost desirable information > > of the more > > > precise location in favor of the civic location given to > > the campus or > > > > > apartment building. > > > > > > 2.) Same scenario as above, but this time the nearest civic > > location > > > is NOT the same as the civic location provided to the apartment > > > complex or campus. The nearest civic location is provided and a > > > delayed response is caused by providing the incorrect civic > > location. > > > > > > 3.) A geodetic location come in from a boat in the lake, river, or > > > bay. The derived civic location is a home on the lake, > > river, or bay. > > > Delayed response due to incorrect location being provided. > > > > > > 4.) Vehicle on interstate highway (limited access highway) provides > > > geodetic location, derived civic location is along the > > highway but a > > > delayed response takes place because not only is the civic location > > > derived incorrect but the responding agency has to drive > > miles to gain > > > > > access to the limited access highway when the correct responding > > > agency is near the access point of the limited access highway. > > > > > > I could and can go on and on on scenarios that can (and > > have) occurred > > > > > due to derived locations, but let me put forth another > > consideration. > > > > > > The service providing the derived location is using a > > spatial dataset, > > > > > but it is not being maintained to the same level as the > > spatial data > > > being used at the PSAP, out of date information is passed > > to the PSAP > > > - LIBALITY ISSUE. We update our spatial data on a minute by minute > > > basis, with literaily hundreds of changes taking place each > > day. There > > > > > are just so many little differences that could exist between the > > > derived location and the actual location provided by a trained call > > > taker, that is familiar with the local geography, that this could > > > easily become a disaster and gain major news coverage that > > could deal > > > the industry and the confidence of the public a significant > setback. > > > > > > Aside from these concerns I did notice a few gramatical > > > inconsistancies in the draft. > > > > > > Thanks, > > > > > > Marc B > > > > > > -----Original Message----- > > > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On > > > Behalf Of Hannes Tschofenig > > > Sent: Tuesday, July 29, 2008 5:31 AM > > > To: Winterbottom, James > > > Cc: geopriv@ietf.org; ecrit@ietf.org > > > Subject: Re: [Geopriv] Announce: Specifying Derived Location in a > > PIDF-LO > > > > > > Sounds like a useful way to indicate the derived location > > > > > > Winterbottom, James wrote: > > > > > > > > > > > > > > > > http://tools.ietf.org/html/draft-winterbottom-geopriv-derived-loc-00 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Specifying Derived Location in a PIDF-LO > > > > > > > > > > > > > > > > > > > > > > > > > > > > Abstract > > > > > > > > > > > > > > This document describes how specify that a location in a > > PIDF-LO has > > > > > > > been derived or converted from a different location. The source > > > > > > > location may reside in the same PIDF-LO or be a remote document > > > > > > > referenced by a location URI and associated id fragement. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Feedback appreciated. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers > > > > > > > > > > > > > > James > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > ------------------------ > > > > > > > This message is for the designated recipient only and may > > > > > > > contain privileged, proprietary, or otherwise private > information. > > > > > > > If you have received it in error, please notify the sender > > > > > > > immediately and delete the original. Any unauthorized use of > > > > > > > this email is prohibited. > > > > > > > > > -------------------------------------------------------------- > > ---------- > > ------------------------ > > > > > > > [mf2] > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Geopriv mailing list > > > > > > > Geopriv@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > > _______________________________________________ > > > > > > Geopriv mailing list > > > > > > Geopriv@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www.ietf.org/mailman/listinfo/geopriv > > > > > 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. > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv ------------------------------------------------------------------------------------------------ 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 Jul 29 08:54:09 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DB1B3A6853; Tue, 29 Jul 2008 08:54: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 A27DD3A6B14 for ; Tue, 29 Jul 2008 08:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 KLU5lcENERZX for ; Tue, 29 Jul 2008 08:54:07 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 7CAE13A6853 for ; Tue, 29 Jul 2008 08:54:07 -0700 (PDT) Received: from [130.129.19.238] ([130.129.19.238]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m6TFsFWI010994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 29 Jul 2008 11:54:18 -0400 (EDT) Message-Id: <672D6824-7FEF-4D90-944A-85FCC5D3E14C@cs.columbia.edu> From: Henning Schulzrinne To: ECRIT Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 29 Jul 2008 11:54:14 -0400 X-Mailer: Apple Mail (2.926) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6 Subject: [Ecrit] LoST demo for non-emergency services X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1944424519==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============1944424519== Content-Type: multipart/alternative; boundary=Apple-Mail-3-668969463 --Apple-Mail-3-668969463 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit The LoST Client and Server for the IETF conference is now online. The client can be accessed from any device on http://lost.cs.columbia.edu:8080/Lost You can discover nearby services by accessing the client from a JavaScript enabled browser. Application developers who want to utilize the LoST server can send the extended LoST queries to http://lost.cs.columbia.edu:8080/Lost/ajaxServlet A brief introduction to the LoST server, client and the various types of queries can be found at http://lost.cs.columbia.edu:8080/LostSite/about.html The server currently contains service listings for Dublin and Manhattan. The system was written by Milind Nimesh and Andrea Fort, at Columbia University. --Apple-Mail-3-668969463 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable The LoST Client and Server for = the IETF conference is now online. The client can be accessed from any = device on http://lost.cs.columbia.edu= :8080/Lost 
You can discover nearby services by accessing = the client from a JavaScript enabled = browser.  

Application developers who want to utilize = the LoST server can send the extended LoST queries to http://lost.cs.= columbia.edu:8080/Lost/ajaxServlet

A brief introduction to = the LoST server, client and the various types of queries can be found = at http://lost.= cs.columbia.edu:8080/LostSite/about.html  

The = server currently contains service listings for Dublin and = Manhattan. 

The system was written by Milind Nimesh and = Andrea Fort, at Columbia University.
= --Apple-Mail-3-668969463-- --===============1944424519== 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 --===============1944424519==-- From ecrit-bounces@ietf.org Tue Jul 29 10:29:24 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C43553A6A95; Tue, 29 Jul 2008 10:29: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 4A21D3A6A95; Tue, 29 Jul 2008 10:29:23 -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 p7SQ2Y-Z6rBm; Tue, 29 Jul 2008 10:29:22 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 954683A6A88; Tue, 29 Jul 2008 10:29:21 -0700 (PDT) Received: from [128.89.255.202] (helo=Lab-Macbook-Pro.meeting.ietf.org) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1KNt0m-0006R6-Fj; Tue, 29 Jul 2008 13:29:25 -0400 Message-ID: <488F5374.7000908@bbn.com> Date: Tue, 29 Jul 2008 18:29:24 +0100 From: Richard Barnes User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: "Thomson, Martin" References: <488EF181.8080105@gmx.net><488F177F.1020305@gmx.net> <8C837214C95C864C9F34F3635C2A65750A5EDA96@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: Cc: geopriv@ietf.org, ecrit@ietf.org, Marc Berryman Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in a PIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Moreover, it doesn't just *identify* what location the derived location was derived from, it enables the recipient to get the source location (or at least request it, with LbyR). This seems to me like a major step toward providing better location even when people do geo-code. For this function, I think a little bit of length is unavoidable I don't think there's a way to do the above (provide source location) without either including the source or a reference to it. And, of course, the use of this extension is optional; maybe you just can't use it in a low-bandwidth environment. --Richard Thomson, Martin wrote: > Read the draft folks. > > This is _exactly_ what the draft does: it defines how to indicate that a location is derived. It also specifies how to identify the location that it was derived from. > > Cheers, > Martin > >> -----Original Message----- >> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On >> Behalf Of Roger Marshall >> Sent: Tuesday, 29 July 2008 3:05 PM >> To: Marc Berryman; Hannes Tschofenig >> Cc: geopriv@ietf.org; ecrit@ietf.org >> Subject: Re: [Geopriv] Announce: Specifying Derived Location in a PIDF- >> LO >> >> Hannes is right to point out that it is better to be clear than to >> assume. >> >> PIDF-LO has already has had capability of providing multiple locations >> - >> even more than 2. If there is a label 'derived', for one of them, >> there >> needs to be a identifier that points back to the original. This is >> better than guessing. >> >> -roger marshall. >> >>> -----Original Message----- >>> From: geopriv-bounces@ietf.org >>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Marc Berryman >>> Sent: Tuesday, July 29, 2008 6:57 AM >>> To: Hannes Tschofenig >>> Cc: geopriv@ietf.org; ecrit@ietf.org >>> Subject: Re: [Geopriv] Announce: Specifying Derived Location >>> in a PIDF-LO >>> >>> As long as it clearly noted that the location is derived from >>> geodetic then I am fine. How to indicate? Provide both >>> geodetic and derived. If geodetic is provided then one can >>> safely assume the provided civic is derived (I would hope). >>> >>> Marc B >>> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Tuesday, July 29, 2008 8:14 AM >>> To: Marc Berryman >>> Cc: Winterbottom, James; geopriv@ietf.org; ecrit@ietf.org >>> Subject: Re: [Geopriv] Announce: Specifying Derived Location >>> in a PIDF-LO >>> >>> Hi Marc, >>> >>> I agree with you that re-coding isn't the ideal solution. >>> Now, the question is: What do we do when someone still does >>> it? We are not the deployment police. >>> Should we indicate the fact that re-coding has happened? How >>> should we indicate it? >>> >>> Ciao >>> Hannes >>> >>> Marc Berryman wrote: >>>> I see very real issues with deriving a civic location from >>> a geodetic >>>> location, when wireless geodetic locations became widely available >>>> this "reverse geocoding" caused many problems. Personally I see no >>>> value but many issues that can come about from a derived civic >>> location. >>>> I will try to expand on these issues (while not being able to draw >>>> pictures to illustrate) from a "Lessons Learned" aspect. >>>> >>>> 1.) Geodetic location comes in and a civic location is derived from >>>> the nearest know civic location, but the geodetic location >>> is centered >>> >>>> on a building in a large campus or a large apartment building. The >>>> nearest civic location is the entrance to the large campus or >>>> apartment complex, so you have lost desirable information >>> of the more >>>> precise location in favor of the civic location given to >>> the campus or >>> >>>> apartment building. >>>> >>>> 2.) Same scenario as above, but this time the nearest civic >>> location >>>> is NOT the same as the civic location provided to the apartment >>>> complex or campus. The nearest civic location is provided and a >>>> delayed response is caused by providing the incorrect civic >>> location. >>>> 3.) A geodetic location come in from a boat in the lake, river, or >>>> bay. The derived civic location is a home on the lake, >>> river, or bay. >>>> Delayed response due to incorrect location being provided. >>>> >>>> 4.) Vehicle on interstate highway (limited access highway) provides >>>> geodetic location, derived civic location is along the >>> highway but a >>>> delayed response takes place because not only is the civic location >>>> derived incorrect but the responding agency has to drive >>> miles to gain >>> >>>> access to the limited access highway when the correct responding >>>> agency is near the access point of the limited access highway. >>>> >>>> I could and can go on and on on scenarios that can (and >>> have) occurred >>> >>>> due to derived locations, but let me put forth another >>> consideration. >>>> The service providing the derived location is using a >>> spatial dataset, >>> >>>> but it is not being maintained to the same level as the >>> spatial data >>>> being used at the PSAP, out of date information is passed >>> to the PSAP >>>> - LIBALITY ISSUE. We update our spatial data on a minute by minute >>>> basis, with literaily hundreds of changes taking place each >>> day. There >>> >>>> are just so many little differences that could exist between the >>>> derived location and the actual location provided by a trained call >>>> taker, that is familiar with the local geography, that this could >>>> easily become a disaster and gain major news coverage that >>> could deal >>>> the industry and the confidence of the public a significant >> setback. >>>> Aside from these concerns I did notice a few gramatical >>>> inconsistancies in the draft. >>>> >>>> Thanks, >>>> >>>> Marc B >>>> >>>> -----Original Message----- >>>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On >>>> Behalf Of Hannes Tschofenig >>>> Sent: Tuesday, July 29, 2008 5:31 AM >>>> To: Winterbottom, James >>>> Cc: geopriv@ietf.org; ecrit@ietf.org >>>> Subject: Re: [Geopriv] Announce: Specifying Derived Location in a >>> PIDF-LO >>>> Sounds like a useful way to indicate the derived location >>>> >>>> Winterbottom, James wrote: >>>> >>> http://tools.ietf.org/html/draft-winterbottom-geopriv-derived-loc-00 >>>>> Specifying Derived Location in a PIDF-LO >>>>> Abstract >>>>> This document describes how specify that a location in a >>> PIDF-LO has >>>>> been derived or converted from a different location. The source >>>>> location may reside in the same PIDF-LO or be a remote document >>>>> referenced by a location URI and associated id fragement. >>>>> Feedback appreciated. >>>>> Cheers >>>>> James >>> -------------------------------------------------------------- >>> ---------- >>> ------------------------ >>>>> This message is for the designated recipient only and may >>>>> contain privileged, proprietary, or otherwise private >> information. >>>>> If you have received it in error, please notify the sender >>>>> immediately and delete the original. Any unauthorized use of >>>>> this email is prohibited. >>> -------------------------------------------------------------- >>> ---------- >>> ------------------------ >>>>> [mf2] >>> -------------------------------------------------------------- >>> ---------- >>>>> _______________________________________________ >>>>> Geopriv mailing list >>>>> Geopriv@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>> _______________________________________________ >>>> >>>> Geopriv mailing list >>>> >>>> Geopriv@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/geopriv >>>> >>> >>> >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www.ietf.org/mailman/listinfo/geopriv >>> >> >> 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. >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv > > ------------------------------------------------------------------------------------------------ > 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 Tue Jul 29 10:37:03 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09093A6A0A; Tue, 29 Jul 2008 10:37:03 -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 BDBD73A69EC; Tue, 29 Jul 2008 10:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, URIBL_GREY=0.25] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rPdIVWqbxYI; Tue, 29 Jul 2008 10:37:01 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id D2B053A69EB; Tue, 29 Jul 2008 10:37:01 -0700 (PDT) Received: from [128.89.255.202] (helo=Lab-Macbook-Pro.meeting.ietf.org) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1KNt8M-0006Zd-EL; Tue, 29 Jul 2008 13:37:14 -0400 Message-ID: <488F5544.3010907@bbn.com> Date: Tue, 29 Jul 2008 18:37:08 +0100 From: Richard Barnes User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: 'GEOPRIV' , ECRIT , IETF Discussion Subject: [Ecrit] GEOPRIV and ECRIT experiments at IETF 72 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I wanted to let folks know about an experiment that some folks from the GEOPRIV and ECRIT working groups have been working to set up at IETF 71 to see if we can deliver some basic location-based applications (including emergency calling), using the IETF network as a platform. The prinicpal challenge in creating location-based applications is getting location in the first place. This experiment is getting location via the IETF network: When you send the location server a request for your location, it looks up which AP you're connected to and returns the location of that AP (if it knows it). Based on this location platform, we've created a few different applications, including -- Basic location mapping -- ECRIT emergency calling -- Location-enhanced Jabber presence -- LoST-based discovery of nearby points of interest (e.g., museums) Much more information is available on the web page we've created at the following URI: Please feel free to send email to me if you're interested in participating or helping out in any way, or if you have any feedback on the experiment. Thanks --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 29 10:38:16 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2925E3A6AC2; Tue, 29 Jul 2008 10:38: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 6755C3A6AC2; Tue, 29 Jul 2008 10:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, URIBL_GREY=0.25] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tudjztq-Mym; Tue, 29 Jul 2008 10:38:14 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 939463A6AB9; Tue, 29 Jul 2008 10:38:14 -0700 (PDT) Received: from [128.89.255.202] (helo=Lab-Macbook-Pro.meeting.ietf.org) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1KNt9X-0006b9-DE; Tue, 29 Jul 2008 13:38:27 -0400 Message-ID: <488F5592.4070306@bbn.com> Date: Tue, 29 Jul 2008 18:38:26 +0100 From: Richard Barnes User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Richard Barnes References: <488F5544.3010907@bbn.com> In-Reply-To: <488F5544.3010907@bbn.com> Cc: 'GEOPRIV' , ECRIT , IETF Discussion Subject: Re: [Ecrit] GEOPRIV and ECRIT experiments at IETF 72 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org ... and of course, I mean IETF 72 in the first paragraph ... Richard Barnes wrote: > I wanted to let folks know about an experiment that some folks from the > GEOPRIV and ECRIT working groups have been working to set up at IETF 71 > to see if we can deliver some basic location-based applications > (including emergency calling), using the IETF network as a platform. > > The prinicpal challenge in creating location-based applications is > getting location in the first place. This experiment is getting > location via the IETF network: When you send the location server a > request for your location, it looks up which AP you're connected to and > returns the location of that AP (if it knows it). > > Based on this location platform, we've created a few different > applications, including > -- Basic location mapping > -- ECRIT emergency calling > -- Location-enhanced Jabber presence > -- LoST-based discovery of nearby points of interest (e.g., museums) > > Much more information is available on the web page we've created at the > following URI: > > > Please feel free to send email to me if you're interested in > participating or helping out in any way, or if you have any feedback on > the experiment. > > Thanks > --Richard > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 29 14:34:22 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E3593A6AF8; Tue, 29 Jul 2008 14:34: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 B93823A6AF8; Tue, 29 Jul 2008 14:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9SFNMKkBoXo; Tue, 29 Jul 2008 14:34:20 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 654693A6A3E; Tue, 29 Jul 2008 14:34:19 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_07_29_16_50_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); Tue, 29 Jul 2008 16:50:00 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 16:34:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 16:34:31 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] [Ecrit] Announce: Specifying Derived Location in a PIDF-LO Thread-Index: AcjxfJ8HFr6/UzZWQXa11vCRrpY1MAARTFQF References: <488EF181.8080105@gmx.net> From: "Winterbottom, James" To: "James M. Polk" , "Hannes Tschofenig" X-OriginalArrivalTime: 29 Jul 2008 21:34:32.0704 (UTC) FILETIME=[E3C05000:01C8F1C2] Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in a PIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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, Please look at the example below and tell me how this is twice the size of an existing PIDF-LO? This is in the draft, and IS just adding a URI element, it is just that we have the flexibility to have the URI point to an element in the same document. AU NSW Wollongong North Wollongong FlindersStreet Campbell Street 2500 Private Box 15 Derived 2008-07-24T12:28:04Z Next, please explain to me how an unencrypted plain-text UDP packet containing my SIP identity and my location information complies with 3863? YOU go on and on and on about this stuff, yet then YOU turn around with complete and utter this kind of garbage. It would be nice, just once, to see you say something constructive rather than feeling you always have to compete. Cheers James -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Tue 7/29/2008 8:10 AM To: Winterbottom, James; Hannes Tschofenig Cc: geopriv@ietf.org; ecrit@ietf.org Subject: Re: [Geopriv] [Ecrit] Announce: Specifying Derived Location in a PIDF-LO At 07:53 AM 7/29/2008, Winterbottom, James wrote: >If I use a reference to an external location how is this doubling >the size of the PIDF-LO? Are there 2 (as in TWO) elements? that doubles the size I see 2 in the example IN YOUR ID... you've made this point in a previous message and I still see TWO elements, where there should be only one in as many cases as we we can limit this isn't *just* a URI element added to what's already there in the LO >I also though that location information was generally only going be >sent if TLS was used, which would rule out the use of UDP as a >viable transport wouldn't it? Certainly I would be uncomfortable >sending my location in an unencrypted UDP packet as I hardly think >that that meets the general requirements of a using protocol. James, YOU keep making these points as if everyone has YOUR values and uses protocols only YOUR way. Are you (as a single entity) representative of the entire human race? >Cheers >James > > > > > >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: Tue 7/29/2008 7:21 AM >To: Hannes Tschofenig; Winterbottom, James >Cc: geopriv@ietf.org; ecrit@ietf.org >Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location >in a PIDF-LO > >At 05:31 AM 7/29/2008, Hannes Tschofenig wrote: > >Sounds like a useful way to indicate the derived location > >this does not to me, as it greatly (almost doubles as far as I can >see) the number of bytes in the LO. > >We shouldn't willfully put blinders up to the contraints of a viable, >in fact built for, transport protocol (i.e., SIP and the >considerations it has taken great lengths to go to towards MTU >limitations of UDP over Ethernet). > > > > > >Winterbottom, James wrote: > >> > >>http://tools.ietf.org/html/draft-winterbottom-geopriv-derived-loc-00 > >> > >> > >> > >>Specifying Derived Location in a PIDF-LO > >> > >> > >> > >>Abstract > >> > >> This document describes how specify that a location in a PIDF-LO has > >> been derived or converted from a different location. The source > >> location may reside in the same PIDF-LO or be a remote document > >> referenced by a location URI and associated id fragement. > >> > >> > >> > >> > >> > >>Feedback appreciated. > >> > >> > >> > >>Cheers > >> > >>James > >> > >> > >> > >> > >> > >> > >>------------------------------------------------------------------ > ------------------------------ > >>This message is for the designated recipient only and may > >>contain privileged, proprietary, or otherwise private information. > >>If you have received it in error, please notify the sender > >>immediately and delete the original. Any unauthorized use of > >>this email is prohibited. > >>------------------------------------------------------------------ > ------------------------------ > >>[mf2] > >> > >>------------------------------------------------------------------------ > >> > >>_______________________________________________ > >>Geopriv mailing list > >>Geopriv@ietf.org > >>https://www.ietf.org/mailman/listinfo/geopriv > >> > > > >_______________________________________________ > >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] > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www.ietf.org/mailman/listinfo/geopriv ------------------------------------------------------------------------------------------------ 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 Jul 29 14:37:45 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47D8428C155; Tue, 29 Jul 2008 14:37: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 01F573A6AF8; Tue, 29 Jul 2008 14:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.165 X-Spam-Level: X-Spam-Status: No, score=-1.165 tagged_above=-999 required=5 tests=[AWL=0.038, 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 oUgpkZ8y87Zx; Tue, 29 Jul 2008 14:37:43 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id BD02E28B56A; Tue, 29 Jul 2008 14:37:42 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_07_29_16_53_23 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, 29 Jul 2008 16:53:23 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 16:37:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 16:37:02 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO Thread-Index: AcjxfOyT1zQp5SikRSWT2ySycVYYBAABWbVQABA6Ym0= References: <488EF181.8080105@gmx.net> <488F177F.1020305@gmx.net> From: "Winterbottom, James" To: "Marc Berryman" , "Hannes Tschofenig" X-OriginalArrivalTime: 29 Jul 2008 21:37:55.0679 (UTC) FILETIME=[5CBBD6F0:01C8F1C3] Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in a PIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 Marc, that is what the draft does. It also gives you the option of not transporting the geodetic location, but provides a pointer to where it can be obtained to address the size issue that the other James is talking about. Cheers James -----Original Message----- From: Marc Berryman [mailto:MBerryman@911.org] Sent: Tue 7/29/2008 8:56 AM To: Hannes Tschofenig Cc: Winterbottom, James; geopriv@ietf.org; ecrit@ietf.org Subject: RE: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO As long as it clearly noted that the location is derived from geodetic then I am fine. How to indicate? Provide both geodetic and derived. If geodetic is provided then one can safely assume the provided civic is derived (I would hope). Marc B -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Tuesday, July 29, 2008 8:14 AM To: Marc Berryman Cc: Winterbottom, James; geopriv@ietf.org; ecrit@ietf.org Subject: Re: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO Hi Marc, I agree with you that re-coding isn't the ideal solution. Now, the question is: What do we do when someone still does it? We are not the deployment police. Should we indicate the fact that re-coding has happened? How should we indicate it? Ciao Hannes Marc Berryman wrote: > > I see very real issues with deriving a civic location from a geodetic > location, when wireless geodetic locations became widely available > this "reverse geocoding" caused many problems. Personally I see no > value but many issues that can come about from a derived civic location. > > I will try to expand on these issues (while not being able to draw > pictures to illustrate) from a "Lessons Learned" aspect. > > 1.) Geodetic location comes in and a civic location is derived from > the nearest know civic location, but the geodetic location is centered > on a building in a large campus or a large apartment building. The > nearest civic location is the entrance to the large campus or > apartment complex, so you have lost desirable information of the more > precise location in favor of the civic location given to the campus or > apartment building. > > 2.) Same scenario as above, but this time the nearest civic location > is NOT the same as the civic location provided to the apartment > complex or campus. The nearest civic location is provided and a > delayed response is caused by providing the incorrect civic location. > > 3.) A geodetic location come in from a boat in the lake, river, or > bay. The derived civic location is a home on the lake, river, or bay. > Delayed response due to incorrect location being provided. > > 4.) Vehicle on interstate highway (limited access highway) provides > geodetic location, derived civic location is along the highway but a > delayed response takes place because not only is the civic location > derived incorrect but the responding agency has to drive miles to gain > access to the limited access highway when the correct responding > agency is near the access point of the limited access highway. > > I could and can go on and on on scenarios that can (and have) occurred > due to derived locations, but let me put forth another consideration. > > The service providing the derived location is using a spatial dataset, > but it is not being maintained to the same level as the spatial data > being used at the PSAP, out of date information is passed to the PSAP > - LIBALITY ISSUE. We update our spatial data on a minute by minute > basis, with literaily hundreds of changes taking place each day. There > are just so many little differences that could exist between the > derived location and the actual location provided by a trained call > taker, that is familiar with the local geography, that this could > easily become a disaster and gain major news coverage that could deal > the industry and the confidence of the public a significant setback. > > Aside from these concerns I did notice a few gramatical > inconsistancies in the draft. > > Thanks, > > Marc B > > -----Original Message----- > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On > Behalf Of Hannes Tschofenig > Sent: Tuesday, July 29, 2008 5:31 AM > To: Winterbottom, James > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: Re: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO > > Sounds like a useful way to indicate the derived location > > Winterbottom, James wrote: > > > > > > http://tools.ietf.org/html/draft-winterbottom-geopriv-derived-loc-00 > > > > > > > > > > > > Specifying Derived Location in a PIDF-LO > > > > > > > > > > > > Abstract > > > > > > This document describes how specify that a location in a PIDF-LO has > > > been derived or converted from a different location. The source > > > location may reside in the same PIDF-LO or be a remote document > > > referenced by a location URI and associated id fragement. > > > > > > > > > > > > > > > > > > Feedback appreciated. > > > > > > > > > > > > Cheers > > > > > > James > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ ------------------------ > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > ------------------------------------------------------------------------ ------------------------ > > > [mf2] > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www.ietf.org/mailman/listinfo/geopriv > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www.ietf.org/mailman/listinfo/geopriv > ------------------------------------------------------------------------------------------------ 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 Jul 29 14:42:57 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2C6A3A69C2; Tue, 29 Jul 2008 14:42:57 -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 E4F173A67F8; Tue, 29 Jul 2008 14:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.17 X-Spam-Level: X-Spam-Status: No, score=-1.17 tagged_above=-999 required=5 tests=[AWL=0.033, 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 cIzgvGsq+Fp0; Tue, 29 Jul 2008 14:42:56 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id EDABC3A69C2; Tue, 29 Jul 2008 14:42:55 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_07_29_16_58_35 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, 29 Jul 2008 16:58:35 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 16:43:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 16:41:28 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Geopriv] Announce: Specifying Derived Location in aPIDF-LO Thread-Index: Acjxf6+kb2Ho2EMZRY2IM37m6hqGqwAAaPcwABCiDhM= References: <488EF181.8080105@gmx.net><488F1A5D.6000001@gmx.net> <014501c8f191$5c8fa990$12178182@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Hannes Tschofenig" , "James M. Polk" X-OriginalArrivalTime: 29 Jul 2008 21:43:08.0252 (UTC) FILETIME=[170AB1C0:01C8F1C4] Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in aPIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 To be clear, this is expressing a relationship between any two things that have an XML attribute. The draft shows how this can be done to link two location chunks providing the location chunks follow the rules laid out in PIDF-LO profile. Derived from is one way this can be used. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Brian Rosen Sent: Tue 7/29/2008 10:39 AM To: 'Hannes Tschofenig'; 'James M. Polk' Cc: geopriv@ietf.org; ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in aPIDF-LO Actually, no. All you need to specify that a location is derived is to have the method token set to derived. James thinks there is value in linking the derived PIDF to the original PIDF. That is a separate question. I think there is some merit in the basic idea of linking. I wonder if this is a specific case of a more general notion: expressing a relationship between two PIDFs? Brian > -----Original Message----- > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Tuesday, July 29, 2008 9:26 AM > To: James M. Polk > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: Re: [Geopriv] [Ecrit] Announce: Specifying Derived Location in a > PIDF-LO > > > > > >> I also though that location information was generally only going be > >> sent if TLS was used, which would rule out the use of UDP as a viable > >> transport wouldn't it? Certainly I would be uncomfortable sending my > >> location in an unencrypted UDP packet as I hardly think that that > >> meets the general requirements of a using protocol. > > > > James, YOU keep making these points as if everyone has YOUR values and > > uses protocols only YOUR way. Are you (as a single entity) > > representative of the entire human race? > > > > > I am not sure why you guys are arguing around on this issue. > > * We know that location information is encoded in XML and not > particularly small. > * We also know that there are security issues with passing location > information around. Hence, we use security protocols. > > What we should think about is whether it makes sense to indicate that > location was derived. If you want to indicate that location was derived > then there is the question on how to express that fact. > > Ciao > Hannes > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv _______________________________________________ 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 Jul 29 15:21:46 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B460628C15B; Tue, 29 Jul 2008 15:21: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 8B0F028C15B; Tue, 29 Jul 2008 15:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=0.330, 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 QjNDYmZ-xayt; Tue, 29 Jul 2008 15:21:44 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 810993A687E; Tue, 29 Jul 2008 15:21:44 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KNxZh-0003x2-Na; Tue, 29 Jul 2008 17:21:46 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Hannes Tschofenig'" , "'James M. Polk'" References: <488EF181.8080105@gmx.net><488F1A5D.6000001@gmx.net> <014501c8f191$5c8fa990$12178182@cis.neustar.com> Date: Tue, 29 Jul 2008 18:21:49 -0400 Message-ID: <01d301c8f1c9$814d5ab0$12178182@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: Thread-Index: Acjxf6+kb2Ho2EMZRY2IM37m6hqGqwAAaPcwABCiDhMAAU464A== 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: Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in aPIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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 you were generalizing it: 1. You would want some more generalized id I think. Perhaps that is what you have, but I don't really see it so far. Specifically, it has to be unique across PIDFs/XML documents/message bodies. A GUID might be appropriate 2. You want to specify the relationship. "Derived from" is one relationship. "Same target, different time" is another. > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Tuesday, July 29, 2008 5:41 PM > To: Brian Rosen; Hannes Tschofenig; James M. Polk > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: RE: [Ecrit] [Geopriv] Announce: Specifying Derived Location in > aPIDF-LO > > To be clear, this is expressing a relationship between any two things that > have an XML attribute. > The draft shows how this can be done to link two location chunks providing > the location chunks follow the rules laid out in PIDF-LO profile. > > Derived from is one way this can be used. > > Cheers > James > > > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of Brian Rosen > Sent: Tue 7/29/2008 10:39 AM > To: 'Hannes Tschofenig'; 'James M. Polk' > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in > aPIDF-LO > > Actually, no. > > All you need to specify that a location is derived is to have the method > token set to derived. > > James thinks there is value in linking the derived PIDF to the original > PIDF. > > That is a separate question. > > I think there is some merit in the basic idea of linking. > > I wonder if this is a specific case of a more general notion: expressing a > relationship between two PIDFs? > > Brian > > > > -----Original Message----- > > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On > Behalf > > Of Hannes Tschofenig > > Sent: Tuesday, July 29, 2008 9:26 AM > > To: James M. Polk > > Cc: geopriv@ietf.org; ecrit@ietf.org > > Subject: Re: [Geopriv] [Ecrit] Announce: Specifying Derived Location in > a > > PIDF-LO > > > > > > > > > >> I also though that location information was generally only going be > > >> sent if TLS was used, which would rule out the use of UDP as a viable > > >> transport wouldn't it? Certainly I would be uncomfortable sending my > > >> location in an unencrypted UDP packet as I hardly think that that > > >> meets the general requirements of a using protocol. > > > > > > James, YOU keep making these points as if everyone has YOUR values and > > > uses protocols only YOUR way. Are you (as a single entity) > > > representative of the entire human race? > > > > > > > > > I am not sure why you guys are arguing around on this issue. > > > > * We know that location information is encoded in XML and not > > particularly small. > > * We also know that there are security issues with passing location > > information around. Hence, we use security protocols. > > > > What we should think about is whether it makes sense to indicate that > > location was derived. If you want to indicate that location was derived > > then there is the question on how to express that fact. > > > > Ciao > > Hannes > > > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ > 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 Jul 29 17:19:00 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0097B28C19D; Tue, 29 Jul 2008 17:19: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 DEF8328C18D; Tue, 29 Jul 2008 17:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.173 X-Spam-Level: X-Spam-Status: No, score=-1.173 tagged_above=-999 required=5 tests=[AWL=0.030, 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 nkNUTAjzSILe; Tue, 29 Jul 2008 17:18:58 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id BAF9328C18B; Tue, 29 Jul 2008 17:18:56 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_07_29_19_34_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); Tue, 29 Jul 2008 19:34:32 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 19:19:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 19:19:02 -0500 Message-ID: In-Reply-To: <01d301c8f1c9$814d5ab0$12178182@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Geopriv] Announce: Specifying Derived Location in aPIDF-LO Thread-Index: Acjxf6+kb2Ho2EMZRY2IM37m6hqGqwAAaPcwABCiDhMAAU464AAEBfIg References: <488EF181.8080105@gmx.net><488F1A5D.6000001@gmx.net> <014501c8f191$5c8fa990$12178182@cis.neustar.com> <01d301c8f1c9$814d5ab0$12178182@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Hannes Tschofenig" , "James M. Polk" X-OriginalArrivalTime: 30 Jul 2008 00:19:04.0992 (UTC) FILETIME=[E017EA00:01C8F1D9] Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in aPIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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, Thanks for the constructive input. I do think that we need to determine if this is something that people think is generally worthwhile doing. I am hearing one resounding no, and at least one saying they would prefer that derived locations didn't happen but if they are going to then it is better we can see where they came from. So before we decide to make a generic solution for any linking between any PIDF elements, can we have a clear yes or no whether people want a linkage mechanism. If we decide we want to do this, then we have to decide where to do it, ECRIT, GEOPRIV, or SIMPLE (since this is the organization that owns PIDF). Cheers James > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, 30 July 2008 8:22 AM > To: Winterbottom, James; 'Hannes Tschofenig'; 'James M. Polk' > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: RE: [Ecrit] [Geopriv] Announce: Specifying Derived Location in > aPIDF-LO > > If you were generalizing it: > 1. You would want some more generalized id I think. Perhaps that is what > you have, but I don't really see it so far. Specifically, it has to be > unique across PIDFs/XML documents/message bodies. A GUID might be > appropriate > > 2. You want to specify the relationship. "Derived from" is one > relationship. "Same target, different time" is another. > > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Tuesday, July 29, 2008 5:41 PM > > To: Brian Rosen; Hannes Tschofenig; James M. Polk > > Cc: geopriv@ietf.org; ecrit@ietf.org > > Subject: RE: [Ecrit] [Geopriv] Announce: Specifying Derived Location in > > aPIDF-LO > > > > To be clear, this is expressing a relationship between any two things > that > > have an XML attribute. > > The draft shows how this can be done to link two location chunks > providing > > the location chunks follow the rules laid out in PIDF-LO profile. > > > > Derived from is one way this can be used. > > > > Cheers > > James > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org on behalf of Brian Rosen > > Sent: Tue 7/29/2008 10:39 AM > > To: 'Hannes Tschofenig'; 'James M. Polk' > > Cc: geopriv@ietf.org; ecrit@ietf.org > > Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in > > aPIDF-LO > > > > Actually, no. > > > > All you need to specify that a location is derived is to have the method > > token set to derived. > > > > James thinks there is value in linking the derived PIDF to the original > > PIDF. > > > > That is a separate question. > > > > I think there is some merit in the basic idea of linking. > > > > I wonder if this is a specific case of a more general notion: expressing > a > > relationship between two PIDFs? > > > > Brian > > > > > > > -----Original Message----- > > > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On > > Behalf > > > Of Hannes Tschofenig > > > Sent: Tuesday, July 29, 2008 9:26 AM > > > To: James M. Polk > > > Cc: geopriv@ietf.org; ecrit@ietf.org > > > Subject: Re: [Geopriv] [Ecrit] Announce: Specifying Derived Location > in > > a > > > PIDF-LO > > > > > > > > > > > > > >> I also though that location information was generally only going be > > > >> sent if TLS was used, which would rule out the use of UDP as a > viable > > > >> transport wouldn't it? Certainly I would be uncomfortable sending > my > > > >> location in an unencrypted UDP packet as I hardly think that that > > > >> meets the general requirements of a using protocol. > > > > > > > > James, YOU keep making these points as if everyone has YOUR values > and > > > > uses protocols only YOUR way. Are you (as a single entity) > > > > representative of the entire human race? > > > > > > > > > > > > > I am not sure why you guys are arguing around on this issue. > > > > > > * We know that location information is encoded in XML and not > > > particularly small. > > > * We also know that there are security issues with passing location > > > information around. Hence, we use security protocols. > > > > > > What we should think about is whether it makes sense to indicate that > > > location was derived. If you want to indicate that location was > derived > > > then there is the question on how to express that fact. > > > > > > Ciao > > > Hannes > > > > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ > > 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 Jul 30 03:11:11 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AEA528C2DB; Wed, 30 Jul 2008 03:11: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 7922028C2BB; Wed, 30 Jul 2008 03:11:09 -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 DRAsLRlMBh+q; Wed, 30 Jul 2008 03:11:07 -0700 (PDT) Received: from ann-mimesweep-1.telecomsys.com (ann-mimesweep-1.telecomsys.com [205.244.233.171]) by core3.amsl.com (Postfix) with ESMTP id 6E7C128C2CF; Wed, 30 Jul 2008 03:11:07 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by ann-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Wed, 30 Jul 2008 06:10:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 03:05:22 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750A660A4B@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] [Ecrit] Announce: Specifying Derived Location inaPIDF-LO Thread-Index: Acjxf6+kb2Ho2EMZRY2IM37m6hqGqwAAaPcwABCiDhMAAU464AAEBfIgABSBbsA= References: <488EF181.8080105@gmx.net><488F1A5D.6000001@gmx.net><014501c8f191$5c8fa990$12178182@cis.neustar.com><01d301c8f1c9$814d5ab0$12178182@cis.neustar.com> From: "Roger Marshall" To: "Winterbottom, James" , "Brian Rosen" , "Hannes Tschofenig" , "James M. Polk" Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location inaPIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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'm an advocate of a linking mechanism. Though I'm not sure that it needs to be as general as Brian suggests. -roger. > -----Original Message----- > From: geopriv-bounces@ietf.org > [mailto:geopriv-bounces@ietf.org] On Behalf Of Winterbottom, James > Sent: Tuesday, July 29, 2008 5:19 PM > To: Brian Rosen; Hannes Tschofenig; James M. Polk > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: Re: [Geopriv] [Ecrit] Announce: Specifying Derived > Location inaPIDF-LO > > Hi Brian, > > Thanks for the constructive input. > I do think that we need to determine if this is something > that people think is generally worthwhile doing. I am hearing > one resounding no, and at least one saying they would prefer > that derived locations didn't happen but if they are going to > then it is better we can see where they came from. > > So before we decide to make a generic solution for any > linking between any PIDF elements, can we have a clear yes or > no whether people want a linkage mechanism. If we decide we > want to do this, then we have to decide where to do it, > ECRIT, GEOPRIV, or SIMPLE (since this is the organization > that owns PIDF). > > Cheers > James > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, 30 July 2008 8:22 AM > > To: Winterbottom, James; 'Hannes Tschofenig'; 'James M. Polk' > > Cc: geopriv@ietf.org; ecrit@ietf.org > > Subject: RE: [Ecrit] [Geopriv] Announce: Specifying Derived Location > in > > aPIDF-LO > > > > If you were generalizing it: > > 1. You would want some more generalized id I think. Perhaps that is > what > > you have, but I don't really see it so far. Specifically, it has to > be > > unique across PIDFs/XML documents/message bodies. A GUID might be > > appropriate > > > > 2. You want to specify the relationship. "Derived from" is one > > relationship. "Same target, different time" is another. > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Tuesday, July 29, 2008 5:41 PM > > > To: Brian Rosen; Hannes Tschofenig; James M. Polk > > > Cc: geopriv@ietf.org; ecrit@ietf.org > > > Subject: RE: [Ecrit] [Geopriv] Announce: Specifying > Derived Location > in > > > aPIDF-LO > > > > > > To be clear, this is expressing a relationship between any two > things > > that > > > have an XML attribute. > > > The draft shows how this can be done to link two location chunks > > providing > > > the location chunks follow the rules laid out in PIDF-LO profile. > > > > > > Derived from is one way this can be used. > > > > > > Cheers > > > James > > > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org on behalf of Brian Rosen > > > Sent: Tue 7/29/2008 10:39 AM > > > To: 'Hannes Tschofenig'; 'James M. Polk' > > > Cc: geopriv@ietf.org; ecrit@ietf.org > > > Subject: Re: [Ecrit] [Geopriv] Announce: Specifying > Derived Location > in > > > aPIDF-LO > > > > > > Actually, no. > > > > > > All you need to specify that a location is derived is to have the > method > > > token set to derived. > > > > > > James thinks there is value in linking the derived PIDF to the > original > > > PIDF. > > > > > > That is a separate question. > > > > > > I think there is some merit in the basic idea of linking. > > > > > > I wonder if this is a specific case of a more general notion: > expressing > > a > > > relationship between two PIDFs? > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] > On > > > Behalf > > > > Of Hannes Tschofenig > > > > Sent: Tuesday, July 29, 2008 9:26 AM > > > > To: James M. Polk > > > > Cc: geopriv@ietf.org; ecrit@ietf.org > > > > Subject: Re: [Geopriv] [Ecrit] Announce: Specifying Derived > Location > > in > > > a > > > > PIDF-LO > > > > > > > > > > > > > > > > > >> I also though that location information was generally only > going be > > > > >> sent if TLS was used, which would rule out the use > of UDP as a > > viable > > > > >> transport wouldn't it? Certainly I would be uncomfortable > sending > > my > > > > >> location in an unencrypted UDP packet as I hardly think that > that > > > > >> meets the general requirements of a using protocol. > > > > > > > > > > James, YOU keep making these points as if everyone has YOUR > values > > and > > > > > uses protocols only YOUR way. Are you (as a single entity) > > > > > representative of the entire human race? > > > > > > > > > > > > > > > > > I am not sure why you guys are arguing around on this issue. > > > > > > > > * We know that location information is encoded in XML and not > > > > particularly small. > > > > * We also know that there are security issues with passing > location > > > > information around. Hence, we use security protocols. > > > > > > > > What we should think about is whether it makes sense to indicate > that > > > > location was derived. If you want to indicate that location was > > derived > > > > then there is the question on how to express that fact. > > > > > > > > Ciao > > > > Hannes > > > > > > > > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www.ietf.org/mailman/listinfo/geopriv > > > > > > _______________________________________________ > > > 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] > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > 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 Jul 30 05:15:59 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C81F028C2B6; Wed, 30 Jul 2008 05:15: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 1571628C150; Wed, 30 Jul 2008 05:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI8cxrXjWery; Wed, 30 Jul 2008 05:15:57 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id C4F2D3A67FC; Wed, 30 Jul 2008 05:15:56 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KOAaV-00078G-H1; Wed, 30 Jul 2008 07:15:31 -0500 From: "Brian Rosen" To: "'Marc Berryman'" , "'Winterbottom, James'" , "'Hannes Tschofenig'" References: <488EF181.8080105@gmx.net><488F177F.1020305@gmx.net> Date: Wed, 30 Jul 2008 08:15:27 -0400 Message-ID: <028c01c8f23d$f83a8250$12178182@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: Thread-Index: AcjxfOyT1zQp5SikRSWT2ySycVYYBAABWbVQABA6Ym0AHbhfQAAA6lmg 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: Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in a PIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1254576663==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1254576663== Content-Type: multipart/alternative; boundary="----=_NextPart_000_028D_01C8F21C.7128E250" This is a multi-part message in MIME format. ------=_NextPart_000_028D_01C8F21C.7128E250 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Marc B We would state that derived locations MUST NOT be sent in an emergency call. I could imagine sending derived locations within an ESInet, although I would discourage that. Brian _____ From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Marc Berryman Sent: Wednesday, July 30, 2008 7:51 AM To: Winterbottom, James; Hannes Tschofenig Cc: geopriv@ietf.org; ecrit@ietf.org Subject: Re: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO James, Existing NENA Standards state that when geodetic is available it will be delivered. I think it is preferred that a pointer provide the derived location and to always deliver the geodetic location in the PIDF-LO, either LbV or LbR. Marc B -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Tuesday, July 29, 2008 4:37 PM To: Marc Berryman; Hannes Tschofenig Cc: geopriv@ietf.org; ecrit@ietf.org Subject: RE: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO Thanks Marc, that is what the draft does. It also gives you the option of not transporting the geodetic location, but provides a pointer to where it can be obtained to address the size issue that the other James is talking about. Cheers James -----Original Message----- From: Marc Berryman [mailto:MBerryman@911.org] Sent: Tue 7/29/2008 8:56 AM To: Hannes Tschofenig Cc: Winterbottom, James; geopriv@ietf.org; ecrit@ietf.org Subject: RE: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO As long as it clearly noted that the location is derived from geodetic then I am fine. How to indicate? Provide both geodetic and derived. If geodetic is provided then one can safely assume the provided civic is derived (I would hope). Marc B -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Tuesday, July 29, 2008 8:14 AM To: Marc Berryman Cc: Winterbottom, James; geopriv@ietf.org; ecrit@ietf.org Subject: Re: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO Hi Marc, I agree with you that re-coding isn't the ideal solution. Now, the question is: What do we do when someone still does it? We are not the deployment police. Should we indicate the fact that re-coding has happened? How should we indicate it? Ciao Hannes Marc Berryman wrote: > > I see very real issues with deriving a civic location from a geodetic > location, when wireless geodetic locations became widely available > this "reverse geocoding" caused many problems. Personally I see no > value but many issues that can come about from a derived civic location. > > I will try to expand on these issues (while not being able to draw > pictures to illustrate) from a "Lessons Learned" aspect. > > 1.) Geodetic location comes in and a civic location is derived from > the nearest know civic location, but the geodetic location is centered > on a building in a large campus or a large apartment building. The > nearest civic location is the entrance to the large campus or > apartment complex, so you have lost desirable information of the more > precise location in favor of the civic location given to the campus or > apartment building. > > 2.) Same scenario as above, but this time the nearest civic location > is NOT the same as the civic location provided to the apartment > complex or campus. The nearest civic location is provided and a > delayed response is caused by providing the incorrect civic location. > > 3.) A geodetic location come in from a boat in the lake, river, or > bay. The derived civic location is a home on the lake, river, or bay. > Delayed response due to incorrect location being provided. > > 4.) Vehicle on interstate highway (limited access highway) provides > geodetic location, derived civic location is along the highway but a > delayed response takes place because not only is the civic location > derived incorrect but the responding agency has to drive miles to gain > access to the limited access highway when the correct responding > agency is near the access point of the limited access highway. > > I could and can go on and on on scenarios that can (and have) occurred > due to derived locations, but let me put forth another consideration. > > The service providing the derived location is using a spatial dataset, > but it is not being maintained to the same level as the spatial data > being used at the PSAP, out of date information is passed to the PSAP > - LIBALITY ISSUE. We update our spatial data on a minute by minute > basis, with literaily hundreds of changes taking place each day. There > are just so many little differences that could exist between the > derived location and the actual location provided by a trained call > taker, that is familiar with the local geography, that this could > easily become a disaster and gain major news coverage that could deal > the industry and the confidence of the public a significant setback. > > Aside from these concerns I did notice a few gramatical > inconsistancies in the draft. > > Thanks, > > Marc B > > -----Original Message----- > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On > Behalf Of Hannes Tschofenig > Sent: Tuesday, July 29, 2008 5:31 AM > To: Winterbottom, James > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: Re: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO > > Sounds like a useful way to indicate the derived location > > Winterbottom, James wrote: > > > > > > http://tools.ietf.org/html/draft-winterbottom-geopriv-derived-loc-00 > > > > > > > > > > > > Specifying Derived Location in a PIDF-LO > > > > > > > > > > > > Abstract > > > > > > This document describes how specify that a location in a PIDF-LO has > > > been derived or converted from a different location. The source > > > location may reside in the same PIDF-LO or be a remote document > > > referenced by a location URI and associated id fragement. > > > > > > > > > > > > > > > > > > Feedback appreciated. > > > > > > > > > > > > Cheers > > > > > > James > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ ------------------------ > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > ------------------------------------------------------------------------ ------------------------ > > > [mf2] > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www.ietf.org/mailman/listinfo/geopriv > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www.ietf.org/mailman/listinfo/geopriv > ---------------------------------------------------------------------------- -------------------- 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] ------=_NextPart_000_028D_01C8F21C.7128E250 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Marc B

 

We would state that derived = locations MUST NOT be sent in an emergency call.  I could imagine sending derived locations within an ESInet, although I would discourage = that.

 

Brian

 

From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Marc Berryman
Sent: Wednesday, July 30, = 2008 7:51 AM
To: Winterbottom, James; = Hannes Tschofenig
Cc: geopriv@ietf.org; ecrit@ietf.org
Subject: Re: [Geopriv] = Announce: Specifying Derived Location in a PIDF-LO

 

James,

Existing NENA Standards = state that when geodetic is available it will be delivered. I think it is preferred = that a pointer provide the derived location and to always deliver the geodetic location in the PIDF-LO, either LbV or LbR.

Marc = B

 

-----Original = Message-----
From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
Sent: Tuesday, July 29, 2008 4:37 PM
To: Marc Berryman; Hannes = Tschofenig
Cc: geopriv@ietf.org; ecrit@ietf.org
Subject: RE: [Geopriv] Announce: Specifying Derived Location in a = PIDF-LO

 

 

Thanks Marc, that is what = the draft does.

It also gives you the = option of not transporting the geodetic location, but provides a pointer to where it = can be obtained to address the size issue that the other James is talking = about.

 

Cheers

James

 

 

-----Original = Message-----

From: Marc Berryman = [mailto:MBerryman@911.org]

Sent: Tue 7/29/2008 8:56 = AM

To: Hannes = Tschofenig

Cc: Winterbottom, James; geopriv@ietf.org; ecrit@ietf.org

Subject: RE: [Geopriv] = Announce: Specifying Derived Location in a PIDF-LO

 

As long as it clearly noted = that the location is derived from geodetic

then I am fine. How to = indicate? Provide both geodetic and derived. If

geodetic is provided then = one can safely assume the provided civic is

derived (I would = hope).

 

Marc = B

 

-----Original = Message-----

From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]

Sent: Tuesday, July 29, = 2008 8:14 AM

To: Marc Berryman

Cc: Winterbottom, James; geopriv@ietf.org; ecrit@ietf.org

Subject: Re: [Geopriv] = Announce: Specifying Derived Location in a

PIDF-LO

 

Hi = Marc,

 

I agree with you that = re-coding isn't the ideal solution.

Now, the question is: What = do we do when someone still does it? We are

not the deployment = police.

Should we indicate the fact = that re-coding has happened? How should we

indicate = it?

 

Ciao

Hannes

 

Marc = Berryman = wrote:

> =

> I see very real issues = with deriving a civic location from a geodetic

> location, when = wireless geodetic locations became widely available

> this "reverse geocoding" caused many problems. Personally I see no =

> value but many issues = that can come about from a derived civic

location.<= /font>

> =

> I will try to expand = on these issues (while not being able to draw

> pictures to = illustrate) from a "Lessons Learned" aspect.

> =

> 1.) Geodetic location = comes in and a civic location is derived from

> the nearest know civic location, but the geodetic location is = centered

 

> on a building in a = large campus or a large apartment building. The

> nearest civic location = is the entrance to the large campus or

> apartment complex, so = you have lost desirable information of the more

> precise location in = favor of the civic location given to the campus or

 

> apartment = building.

> =

> 2.) Same scenario as = above, but this time the nearest civic location

> is NOT the same as the = civic location provided to the apartment

> complex or campus. The = nearest civic location is provided and a

> delayed response is = caused by providing the incorrect civic location.

> =

> 3.) A geodetic = location come in from a boat in the lake, river, or

> bay. The derived civic = location is a home on the lake, river, or bay.

> Delayed response due = to incorrect location being provided.

> =

> 4.) Vehicle on = interstate highway (limited access highway) provides

> geodetic location, = derived civic location is along the highway but a

> delayed response takes = place because not only is the civic location

> derived incorrect but = the responding agency has to drive miles to gain

 

> access to the limited = access highway when the correct responding

> agency is near the = access point of the limited access highway.

> =

> I could and can go on = and on on scenarios that can (and have) occurred

 

> due to derived = locations, but let me put forth another consideration.

> =

> The service providing = the derived location is using a spatial = dataset,

 

> but it is not being = maintained to the same level as the spatial data

> being used at the = PSAP, out of date information is passed to the PSAP

> - LIBALITY ISSUE. We = update our spatial data on a minute by minute

> basis, with literaily = hundreds of changes taking place each day. There

 

> are just so many = little differences that could exist between the

> derived location and = the actual location provided by a trained call

> taker, that is = familiar with the local geography, that this could

> easily become a = disaster and gain major news coverage that could deal

> the industry and the = confidence of the public a significant setback.

> =

> Aside from these = concerns I did notice a few gramatical

> inconsistancies in the = draft.

> =

> = Thanks,

> =

> Marc = B

> =

> -----Original = Message-----

> From: = geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On

> Behalf Of Hannes = Tschofenig

> Sent: Tuesday, July = 29, 2008 5:31 AM

> To: Winterbottom, = James

> Cc: geopriv@ietf.org; ecrit@ietf.org

> Subject: Re: [Geopriv] Announce: Specifying Derived Location in a

PIDF-LO

> =

> Sounds like a useful = way to indicate the derived location

> =

> Winterbottom, James = wrote:

> =

> = >

> =

> > http://tools.ietf.org/html/draft-winterbottom-geopriv-derived-loc-00=

> =

> = >

> =

> = >

> =

> = >

> =

> > Specifying = Derived Location in a PIDF-LO

> =

> = >

> =

> = >

> =

> = >

> =

> > = Abstract

> =

> = >

> =

> > This document = describes how specify that a location in a PIDF-LO = has

> =

> > been derived or = converted from a different location. The source

> =

> > location may = reside in the same PIDF-LO or be a remote document

> =

> > referenced by a = location URI and associated id fragement.

> =

> = >

> =

> = >

> =

> = >

> =

> = >

> =

> = >

> =

> > Feedback = appreciated.

> =

> = >

> =

> = >

> =

> = >

> =

> > = Cheers

> =

> = >

> =

> > = James

> =

> = >

> =

> = >

> =

> = >

> =

> = >

> =

> = >

> =

> = >

> =

> = >

----------------------------= --------------------------------------------

=

------------------------

> =

> > This message is = for the designated recipient only and may

> =

> > contain = privileged, proprietary, or otherwise private = information.

> =

> > If you have = received it in error, please notify the sender

> =

> > immediately and = delete the original. Any unauthorized use of

> =

> > this email is = prohibited.

> =

> = >

----------------------------= --------------------------------------------

=

------------------------

> =

> > = [mf2]

> =

> = >

> =

> = >

----------------------------= --------------------------------------------

=

> =

> = >

> =

> > _______________________________________________<= /p>

> =

> > Geopriv mailing = list

> =

> > = Geopriv@ietf.org

> =

> > https://www.ietf.org/mailman/listinfo/geopriv

> =

> = >

> =

> _______________________________________________<= /p>

> =

> Geopriv mailing = list

> =

> = Geopriv@ietf.org

> =

> https://www.ietf.org/mailman/listinfo/geopriv

> =

 

 

 

 

 

----------------------------= --------------------------------------------------------------------=

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]

 

 

------=_NextPart_000_028D_01C8F21C.7128E250-- --===============1254576663== 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 --===============1254576663==-- From ecrit-bounces@ietf.org Wed Jul 30 14:26:40 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 734253A69BD; Wed, 30 Jul 2008 14:26: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 E2DB93A69CA; Wed, 30 Jul 2008 14:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.176 X-Spam-Level: X-Spam-Status: No, score=-1.176 tagged_above=-999 required=5 tests=[AWL=0.027, 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 i21LCVliGp7p; Wed, 30 Jul 2008 14:26:38 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 78D063A6840; Wed, 30 Jul 2008 14:26:37 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_07_30_16_42_22 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, 30 Jul 2008 16:42:21 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 16:26:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 16:25:49 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO Thread-Index: AcjxfOyT1zQp5SikRSWT2ySycVYYBAABWbVQABA6Ym0AHbhfQAAULguX References: <488EF181.8080105@gmx.net> <488F177F.1020305@gmx.net> From: "Winterbottom, James" To: "Marc Berryman" , "Hannes Tschofenig" X-OriginalArrivalTime: 30 Jul 2008 21:26:52.0899 (UTC) FILETIME=[FC196330:01C8F28A] Cc: geopriv@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in a PIDF-LO X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: 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, Thanks for that, though that does seem like a matter for ECRIT to think about. The draft doesn't say which one to send, just how to link the locations. Cheers James -----Original Message----- From: Marc Berryman [mailto:MBerryman@911.org] Sent: Wed 7/30/2008 6:50 AM To: Winterbottom, James; Hannes Tschofenig Cc: geopriv@ietf.org; ecrit@ietf.org Subject: RE: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO James, Existing NENA Standards state that when geodetic is available it will be delivered. I think it is preferred that a pointer provide the derived location and to always deliver the geodetic location in the PIDF-LO, either LbV or LbR. Marc B -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Tuesday, July 29, 2008 4:37 PM To: Marc Berryman; Hannes Tschofenig Cc: geopriv@ietf.org; ecrit@ietf.org Subject: RE: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO Thanks Marc, that is what the draft does. It also gives you the option of not transporting the geodetic location, but provides a pointer to where it can be obtained to address the size issue that the other James is talking about. Cheers James -----Original Message----- From: Marc Berryman [mailto:MBerryman@911.org] Sent: Tue 7/29/2008 8:56 AM To: Hannes Tschofenig Cc: Winterbottom, James; geopriv@ietf.org; ecrit@ietf.org Subject: RE: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO As long as it clearly noted that the location is derived from geodetic then I am fine. How to indicate? Provide both geodetic and derived. If geodetic is provided then one can safely assume the provided civic is derived (I would hope). Marc B -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Tuesday, July 29, 2008 8:14 AM To: Marc Berryman Cc: Winterbottom, James; geopriv@ietf.org; ecrit@ietf.org Subject: Re: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO Hi Marc, I agree with you that re-coding isn't the ideal solution. Now, the question is: What do we do when someone still does it? We are not the deployment police. Should we indicate the fact that re-coding has happened? How should we indicate it? Ciao Hannes Marc Berryman wrote: > > I see very real issues with deriving a civic location from a geodetic > location, when wireless geodetic locations became widely available > this "reverse geocoding" caused many problems. Personally I see no > value but many issues that can come about from a derived civic location. > > I will try to expand on these issues (while not being able to draw > pictures to illustrate) from a "Lessons Learned" aspect. > > 1.) Geodetic location comes in and a civic location is derived from > the nearest know civic location, but the geodetic location is centered > on a building in a large campus or a large apartment building. The > nearest civic location is the entrance to the large campus or > apartment complex, so you have lost desirable information of the more > precise location in favor of the civic location given to the campus or > apartment building. > > 2.) Same scenario as above, but this time the nearest civic location > is NOT the same as the civic location provided to the apartment > complex or campus. The nearest civic location is provided and a > delayed response is caused by providing the incorrect civic location. > > 3.) A geodetic location come in from a boat in the lake, river, or > bay. The derived civic location is a home on the lake, river, or bay. > Delayed response due to incorrect location being provided. > > 4.) Vehicle on interstate highway (limited access highway) provides > geodetic location, derived civic location is along the highway but a > delayed response takes place because not only is the civic location > derived incorrect but the responding agency has to drive miles to gain > access to the limited access highway when the correct responding > agency is near the access point of the limited access highway. > > I could and can go on and on on scenarios that can (and have) occurred > due to derived locations, but let me put forth another consideration. > > The service providing the derived location is using a spatial dataset, > but it is not being maintained to the same level as the spatial data > being used at the PSAP, out of date information is passed to the PSAP > - LIBALITY ISSUE. We update our spatial data on a minute by minute > basis, with literaily hundreds of changes taking place each day. There > are just so many little differences that could exist between the > derived location and the actual location provided by a trained call > taker, that is familiar with the local geography, that this could > easily become a disaster and gain major news coverage that could deal > the industry and the confidence of the public a significant setback. > > Aside from these concerns I did notice a few gramatical > inconsistancies in the draft. > > Thanks, > > Marc B > > -----Original Message----- > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On > Behalf Of Hannes Tschofenig > Sent: Tuesday, July 29, 2008 5:31 AM > To: Winterbottom, James > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: Re: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO > > Sounds like a useful way to indicate the derived location > > Winterbottom, James wrote: > > > > > > http://tools.ietf.org/html/draft-winterbottom-geopriv-derived-loc-00 > > > > > > > > > > > > Specifying Derived Location in a PIDF-LO > > > > > > > > > > > > Abstract > > > > > > This document describes how specify that a location in a PIDF-LO has > > > been derived or converted from a different location. The source > > > location may reside in the same PIDF-LO or be a remote document > > > referenced by a location URI and associated id fragement. > > > > > > > > > > > > > > > > > > Feedback appreciated. > > > > > > > > > > > > Cheers > > > > > > James > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ ------------------------ > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > ------------------------------------------------------------------------ ------------------------ > > > [mf2] > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www.ietf.org/mailman/listinfo/geopriv > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www.ietf.org/mailman/listinfo/geopriv > ------------------------------------------------------------------------ ------------------------ 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 Thu Jul 31 11:21:35 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B8BB28C29F; Thu, 31 Jul 2008 11:21: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 228AC28C273 for ; Thu, 31 Jul 2008 11:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 KsJSAIoot97n for ; Thu, 31 Jul 2008 11:21:33 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2B47328C249 for ; Thu, 31 Jul 2008 11:21:33 -0700 (PDT) Received: (qmail invoked by alias); 31 Jul 2008 18:15:10 -0000 Received: from unknown (EHLO [130.129.20.103]) [130.129.20.103] by mail.gmx.net (mp021) with SMTP; 31 Jul 2008 20:15:10 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+SQq4hZcWSwr5N3NW3Zr58J8bJ4jW9WBFQyQZCxH JErQvbfsBemZAX Message-ID: <48920132.9080108@gmx.net> Date: Thu, 31 Jul 2008 21:15:14 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: GEOPRIV , dime@ietf.org, 'ECRIT' , keyprov@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.84 Subject: [Ecrit] Chillout, IETF#72 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org In case you are still in Dublin on Friday evening and if you are interested to hang around with other IETF folks please drop me a note. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit