From ecrit-bounces@ietf.org Tue Jun 3 06:23: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 4DCDE28C24E; Tue, 3 Jun 2008 06:23:15 -0700 (PDT) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id D593A28C10D; Tue, 3 Jun 2008 06:02:27 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20080603130228.D593A28C10D@core3.amsl.com> Date: Tue, 3 Jun 2008 06:02:27 -0700 (PDT) X-Mailman-Approved-At: Tue, 03 Jun 2008 06:23:14 -0700 Cc: ecrit chair , Internet Architecture Board , ecrit mailing list , RFC Editor Subject: [Ecrit] Protocol Action: 'A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure' to Proposed Standard 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The IESG has approved the following document: - 'A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure ' as a Proposed Standard This document is the product of the Emergency Context Resolution with Internet Technologies Working Group. The IESG contact persons are Jon Peterson and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-03.txt Technical Summary The Location-to-Service Translation Protocol (LoST) describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere but a placement closer to the end host, e.g., in the access network, is desirable. Such a LoST server placement provides benefits in disaster situations with intermittent network connectivity regarding the resiliency of emergency service communication. This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). Working Group Summary There is consensus in the WG to publish this document. Protocol Quality Although the LoST specification has been implemented there are no implementations known for the DHCP-based discovery procedure. From a deployment point of view it is likely that the DNS-based discovery procedure will be available before this document will see a deployment. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 17 12:25: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 E11113A6AB3; Tue, 17 Jun 2008 12:25: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 DC2833A6AB3 for ; Tue, 17 Jun 2008 12:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 L+wJ8A4jJCYu for ; Tue, 17 Jun 2008 12:25:48 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id F143B3A6B67 for ; Tue, 17 Jun 2008 12:25:47 -0700 (PDT) Received: (qmail invoked by alias); 17 Jun 2008 19:26:32 -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; 17 Jun 2008 21:26:32 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX189cXl858Y9PQYMTziv9AZetdA+3zwKApn6T4KOHc YY79ofzOQzIsiF Message-ID: <48580FE7.9010302@gmx.net> Date: Tue, 17 Jun 2008 22:26:31 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: 'ECRIT' X-Y-GMX-Trusted: 0 Subject: [Ecrit] Request for Agenda Items 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, we need to prepare the agenda for the meeting. Please let me know what you believe we should definitely discuss or shouldn't discuss anymore. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 17 13:16: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 E17E73A68C8; Tue, 17 Jun 2008 13:16: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 2FE783A6805 for ; Tue, 17 Jun 2008 13:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 kRySO1gakwbZ for ; Tue, 17 Jun 2008 13:16:14 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 546A428C115 for ; Tue, 17 Jun 2008 13:16:05 -0700 (PDT) Received: (qmail invoked by alias); 17 Jun 2008 20:16:49 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp010) with SMTP; 17 Jun 2008 22:16:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Sp5IdBLgShxPn8A5cIp8gQP0OT8ijbznmbtvqUn UBHkNTrfmIIRhq Message-ID: <48581BAF.4020106@gmx.net> Date: Tue, 17 Jun 2008 23:16:47 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Henning Schulzrinne References: In-Reply-To: X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Hum: draft-schulzrinne-ecrit-lost-sync 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 Henning, please submit your document as WG item. Ciao Hannes hannes.tschofenig@nsn.com wrote: > > Hi all, > > Henning gave a presentation about this draft at previous IETF > meetings. There was very positive feedback from the group. We would > therefore like to confirm the hum on the mailing list. If you have not > stated your opinion or if you object please let us know. > > Deadline for your response: 30 May 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 Jun 17 13:16:17 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 3A6EA28C0E2; Tue, 17 Jun 2008 13:16:17 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBAE328C11C for ; Tue, 17 Jun 2008 13:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 mQLYnwGVTUK9 for ; Tue, 17 Jun 2008 13:16:15 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DC4AC3A6846 for ; Tue, 17 Jun 2008 13:16:13 -0700 (PDT) Received: (qmail invoked by alias); 17 Jun 2008 20:16:58 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp005) with SMTP; 17 Jun 2008 22:16:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19+hyEdYVp+C65Rd24BryyuaD4LnuBhH+/hdRgR4A KK9xwO5PMNTRzB Message-ID: <48581BB8.2090703@gmx.net> Date: Tue, 17 Jun 2008 23:16:56 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Winterbottom, James" References: In-Reply-To: X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Hum: draft-winterbottom-ecrit-specifying-holes-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 James, please submit your document as WG item. Ciao Hannes hannes.tschofenig@nsn.com wrote: > Hi all, > > James gave a presentation about this draft at previous IETF meetings. > There was positive feedback from the group. We would therefore like to > confirm the hum on the mailing list. If you have not stated your opinion > or if you object please let us know. > > Deadline for your response: 30 May 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 Jun 17 13:45: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 78AD128C0D9; Tue, 17 Jun 2008 13:45:21 -0700 (PDT) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7342D3A6B76; Tue, 17 Jun 2008 13: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: <20080617204502.7342D3A6B76@core3.amsl.com> Date: Tue, 17 Jun 2008 13:45:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-location-hiding-req-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 : Location Hiding: Problem Statement and Requirements Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-ecrit-location-hiding-req-00.txt Pages : 10 Date : 2008-06-17 The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to end points in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). For determining the PSAP Uniform Resource Identifier (URI) the usage of the Location-to-Service Translation (LoST) Protocol is envisioned. This document explores the architectural impact for the IETF emergency services architecture for situations where the Internet Access Provider (IAP) and/or the Internet Service Provider (ISP) are only willing to disclose limited or no location information. This document provides a problem statement and lists requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-location-hiding-req-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-location-hiding-req-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-17133141.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 Jun 17 13: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 3E0BE3A6B7E; Tue, 17 Jun 2008 13: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 079253A6ABF; Tue, 17 Jun 2008 13:45:02 -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: <20080617204507.079253A6ABF@core3.amsl.com> Date: Tue, 17 Jun 2008 13:45:02 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-specifying-holes-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 : Specifying Holes in LoST Service Boundaries Author(s) : J. Winterbottom, M. Thomson Filename : draft-ietf-ecrit-specifying-holes-00.txt Pages : 18 Date : 2008-06-17 This document describes how holes can be specified in service boundaries. One means of implementing a solution is described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-specifying-holes-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-specifying-holes-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-17133325.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 Jun 17 14:11: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 9A3CF3A6B72; Tue, 17 Jun 2008 14:11: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 969263A6B72 for ; Tue, 17 Jun 2008 14:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 Krgub7typO5O for ; Tue, 17 Jun 2008 14:11:54 -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 B7CAC3A6900 for ; Tue, 17 Jun 2008 14:11:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,660,1204531200"; d="scan'208";a="32777088" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 17 Jun 2008 14:12:40 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m5HLCetY012986; Tue, 17 Jun 2008 14:12:40 -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 m5HLCenx009092; Tue, 17 Jun 2008 21:12:40 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jun 2008 14:12:40 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.78.55]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jun 2008 14:12:39 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 17 Jun 2008 16:12:39 -0500 To: Hannes Tschofenig , "'ECRIT'" From: "James M. Polk" In-Reply-To: <48580FE7.9010302@gmx.net> References: <48580FE7.9010302@gmx.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 17 Jun 2008 21:12:39.0968 (UTC) FILETIME=[DFF33200:01C8D0BE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1073; t=1213737160; x=1214601160; 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=20Item s |Sender:=20; bh=uv+7OOhpgLAxwrT1zJ80SjiUSe32c5v/msuST00l/J4=; b=mmcS5UNBsWmyHBdaXBSLdpfbT5MRjEdUIZoDFwstKum/Tn5BqF2M9yOdi+ IY1N/Y7jnBqjA42w8lq+R/R4GxQEyihrSPT8hzW+Kho1YclHuNV0kuonddWg y0+1E6rRnw; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Ecrit] Request for Agenda Items 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 02:26 PM 6/17/2008, Hannes Tschofenig wrote: >Hi all, > >we need to prepare the agenda for the meeting. Please let me know what >you believe we should definitely discuss or shouldn't discuss anymore. 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. The SIP WG chair has discussed taking this work on while maintaining the 3GPP requirements (stated above). Does this become something that isn't blessed by ECRIT yet still progresses towards publication? (this is not a threat - btw, as I'd prefer this be a ECRIT effort) James >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 Thu Jun 26 05:01: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 7E3453A67EC; Thu, 26 Jun 2008 05:01: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 011DB3A67EC for ; Thu, 26 Jun 2008 05:01: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 iE6xDEC6nYMV for ; Thu, 26 Jun 2008 05:01:01 -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 EA05C3A67AE for ; Thu, 26 Jun 2008 05:01:00 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id y36so260675ugd.46 for ; Thu, 26 Jun 2008 05:01:01 -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:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=PYMfC+ETbPP8rjyaF0uI9lk1ULzVJNNnOe4G3MdQA4Q=; b=sSjyq2+KOCJdzwI2S9mJnAMKVUx+jYODD8a7lQ+PkNKTq0tLm2g2sGfDcawzJpDDoQ GfG5SnPtjx57v7LwqV2Wn3R5GXwBMxEFCG0pT5rqomoHG2HB6JJrN/teL5ZgMRiv1MXA 5LfV4A6kNzIlUvYyGRLvr2LjvbGvsi8t0X3G4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Ws3wzNzUpsyBoY+z3X/GF2xIak1d3WXsa27NynvPyH6J4Iain/322bueHlqGAN7ko0 9SnWjVa7agyFO7+jfmUr5K2DMZRPVpy8t9hSnLbH1TM6BI+21FXuZ+mIB1Sz3sGEqbR9 PnP+u/11M05t6CfQl34w49kYOOK0qPUOkD1l0= Received: by 10.66.255.20 with SMTP id c20mr1162601ugi.87.1214481660747; Thu, 26 Jun 2008 05:01:00 -0700 (PDT) Received: by 10.67.30.1 with HTTP; Thu, 26 Jun 2008 05:01:00 -0700 (PDT) Message-ID: Date: Thu, 26 Jun 2008 14:01:00 +0200 From: "Karl Heinz Wolf" To: ecrit@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <20080528194502.7D0D03A6A7A@core3.amsl.com> 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 There is a little mistake in Figure 12 and 13: The sample shows "urn:service:sos.suicide", but according to RFC 5031 this does not exist, it is "urn:service:counseling.suicide", and therefore has to be removed from the exemplary response. karl heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 27 12:53: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 80C0A28C1C5; Fri, 27 Jun 2008 12:53: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 D8EE528C1C8 for ; Fri, 27 Jun 2008 12:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 AyssmdCPtwac for ; Fri, 27 Jun 2008 12:53:01 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id AB8BB28C1BF for ; Fri, 27 Jun 2008 12:53:01 -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 1KCK08-0006IR-ED; Fri, 27 Jun 2008 14:52:56 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'Stark, Barbara'" , , References: <47EFF025.9000705@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA080ECEF5@crexc41p> <20080331130825.115280@gmx.net> Date: Fri, 27 Jun 2008 15:53:01 -0400 Message-ID: <17af01c8d88f$69cd14f0$bf320446@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080331130825.115280@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciTME9oqfC3NXT9Ro65tv1p9u8u0RD1zKFg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-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 added references to -profile in -framework and -phonebcp. In the latter, I added a new requirement that the device/LIS must follow it when constructing a PIDF. I am not sure what else to do. I'm willing to add text from DSLF if that is desired. I'm not sure that it's really all that important to do so. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Monday, March 31, 2008 9:08 AM > To: Stark, Barbara; ecrit@ietf.org; James.Winterbottom@andrew.com > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > Should we at least reference PIDF-LO profile and indicate constraints? > > > -------- Original-Nachricht -------- > > Datum: Mon, 31 Mar 2008 09:05:34 -0400 > > Von: "Stark, Barbara" > > An: "Winterbottom, James" , "Hannes > Tschofenig" , ecrit@ietf.org > > Betreff: RE: [Ecrit] Phone BCP: Multiple Location > > > It's my understanding that PIDF-LO only describes multiple location > > precedence within a single message. It doesn't describe how to > > prioritize multiple locations received from various sources, received > > in multiple messages (or statically configured) at various times. > > > > I did include that sort of logic in my latest DSLF draft. If there is a > > desire to have some of this in phonebcp, I'm fine with that. > > Barbara > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Winterbottom, James > > Sent: Sunday, March 30, 2008 4:36 PM > > To: Hannes Tschofenig; ecrit@ietf.org > > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > > > PIDF-LO profile describes how to choose the correct location for exactly > > this purpose. > > That is the application form which the original requirements were drawn. > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > > Sent: Sun 3/30/2008 2:55 PM > > To: ecrit@ietf.org > > Subject: [Ecrit] Phone BCP: Multiple Location > > > > " > > ED-39 If a UA has more than one location available to it, it MUST > > choose one location to route the call towards the PSAP. > > > > SP-16 If a proxy inserts location on behalf of an endpoint, and it > > has multiple locations available for the endpoint it MUST choose one > > location to use to route the call towards the PSAP. > > " > > > > I could imagine that someone might ask how to make a decision. > > So, how does the decision making look like? > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > ------------------------------------------------------------------------ > > ------------------------ > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > ------------------------------------------------------------------------ > > ------------------------ > > [mf2] > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 27 12:53: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 B6E4F28C1C5; Fri, 27 Jun 2008 12:53: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 4B64928C1DC for ; Fri, 27 Jun 2008 12:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 z4e94n5+w1Gr for ; Fri, 27 Jun 2008 12:53:13 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id E19CF28C1BF for ; Fri, 27 Jun 2008 12:53: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 1KCK0M-0006J3-5T; Fri, 27 Jun 2008 14:53:10 -0500 From: "Brian Rosen" To: , , References: <47CAE9CA.9010901@gmx.net> Date: Fri, 27 Jun 2008 15:53:15 -0400 Message-ID: <17b001c8d88f$71f84c80$bf320446@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: Ach8jolv/STC1rK7RIKB7KJgoR54QAASL2dgFSnbEGA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-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 your comments. I have dealt with most of them in the -05 version of -phonebcp. Please note that -phonebcp must be read in conjunction with -framework, as the latter does not explain why the requirement is in place, where framework does. Some of your comments imply you want more motivation for the requirement. -framework is where you can find that motivation. If the motivation in -framework is not sufficient, we can improve it there. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Gabor.Bajko@nokia.com > Sent: Sunday, March 02, 2008 11:37 PM > To: Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 > > Few comments below: > > 1. The title of the document does not explicitely say that this document > is about "VoIP" emergency calls. > Suggestion: add "VoIP" to the title (... Communications Services in > support of VoIP Emergency Calling) My co-author answered this item. Communications services encompasses all forms of interactive media including voice, video and text. Therefore, VoIP is not an appropriate term > > 2. The title of the documents says "Best Current Practice for ...", > while the document is not a collection nor a subset of the currently > used practices for emergency calling. And there is no 'current practice' > for VoIP emergency calling yet, thus a 'best current practice' of yet > nonexisting practices is confusing. > Suggestion: change the title eg to "Requirements for Communication > Services in support of VoIP Emergency Calling" > (and revise the abstract section accordingly) My co-author dealt with this issue. BCP is what the IETF uses for this kind of document. > > 3. "ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the > Request-URI of the INVITE." > Marked by whom, the endpoints, the proxies or both? Clarify Since the requirement is labeled "ED-4/SP-3" it is marked by the End Device, with the Service Provider assuring that if the end device doesn't do it, the SP does. > > 4. "ED-5/SP-4 Local dial strings MUST be recognized." and "ED-6/SP-5 > Home dial strings MAY be recognized." > Recognized by whom? Clarify See above > > 5. "ED-10 Devices SHOULD NOT have one button emergency calling > initiation." > While I understand that the intention is to discourage vendors to design > devices with a button dedicated only for emergency calls, current mobile > phones have the possibility of 'speed dial', when a preset dial string > (including 112 or 911) can be assigned to any button. Requirement ED-10 > can be also read to ban this feature in the phone. Clarify. > I do not have a suggestion, but as today's devices do not have such a > dedicated red button any more, I see no value in this requirement, it > just creates confusion. I added some text in -framework that says that speed dials with the emergency dial string should be prohibited. The requirement is ED-68. > > 6. "ED-11/SP-9 All emergency services specified in > [I-D.ietf-ecrit-service-urn] MUST be recognized." > Recognized by whom? Clarify. See above > > 7. "6.1. Types of location information > > There are several forms of location. In IETF protocols , civic and > geospatial (geo) forms are both supported." > The term "IETF protocols" is too broad. UDP/TCP/DNS/ARP etc. are all > 'IETF protocols', but they do not support location. Be more specific. I reworded the text to "IETF location configuration and location conveyance" > > 8. section 6.1 > "Other forms of > location representation must be mapped into either a geo or civic for > use in emergency calls." > Currently most mobile network carriers use cell-id for directing the > call to the correct psap. That technique will not go away for yet a long > time. While cell-id could be mapped into either civic or geo, there is > no added value in doing so, as cell-id based routing serves the purpose > just as well as civic or geo based routing. I would suggest relaxing the > requirement, otherwise the draft will go against current practices. I believe this issue was discussed and the conclusion is that cell id should not be used as location when sent to a PSAP (or a device for that matter). Cell ID is, and will be used within wireless networks, but they will not be used in the places this document deals with. No changes were made > > 9. "ED-17/INT-8/AN-7 Devices that support endpoint measuring of location > MUST have at least a coarse location capability (typically <1km > accuracy when not location hiding) at all times for routing of > calls." > I do not understand the text in the brackets. What is location hiding > (add reference to it) and what happens when it is applied, will the req > become n/a? clarify. See the text in -framework for an explanation. > Same comment for AN-9 > > 10. same paragraph as above. "This mechanism MAY be a service provided > by the access network." It is not clear what 'this mechanism' refers to. I fixed the text to say "The location determination mechanism" > > 11. "AN-8 Access networks MAY provide network-measured location > determination. Wireless access network which do not support network > measured location MUST require that all devices connected to the > network have end-system measured location. " > What kind of wireless access networks are we talking about? Commercial, > public, private, academic or all of them? I could hardly believe that a > free public network like the google one in Mountain View (which does not > support network measured location) would have a means to restrict my > laptop's access (which does not have an end-system measured location). > Suggestion: be more specific. Say 'commercial wireless access networks' > or 'subscription based wireless access networks'. It has to be a managed > network, otherwise nothing can be enforced. All access networks must make sure location can be provided for emergency calls. There are no exceptions. The free google network must supply location one way or another. > > 12. "ED-27/INT-20 If the device sends a DHCP INFORM message" > The text should say 'DHCPINFORM' (no space between, rfc2131). Fixed > > 13. "ED-28/INT-21 To minimize the effects of VPNs that do not allow > split > tunneling VPNs, location configuration SHOULD be attempted before > such tunnels are established." > Add reference to 'split tunneling VPNs'(if exists). If there is no > reference, then be more explicit. Say that using an LCP while on a VPN > may result in getting the location of the vpn gateway. Avoid using > non-defined terms. I reworded the text to say " To minimize the effects of VPNs that do not allow packets to be sent via the native hardware interface rather than via the VPN tunnel" > > 14. "ED-47 Endpoints MUST support one or more mechanisms that allow them > to determine their public IP address. Examples include ICE ..." > It should be STUN instead of ICE. Fixed > > 15. " ED-68/SP-38 The emergency dialstrings SHOULD NOT be permitted in > Call > Forward numbers or speed dial lists." > There is no such regulatory requirement in place. Vendors comply with > regulatory requirements when it comes to emergency services. This draft > is not an amendment to any regulatory document, thus this requirement is > inappropriate. Remove it. Emergency service professionals recommend such features be disabled. See comment above > > 16. general comment: the draft seem to focus on 802.11 access networks. > The term "access point" is used all over. Access networks other than > wi-fi use terms like base station, rnc, node-b, etc. If the draft is > meant to be applicable to access networks other than wi-fi, then a more > generic term should be used instead of 'Access Point'. I didn't make a change, but I'm willing to if we can agree on a term. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 27 12:53: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 2A7BF28C1C8; Fri, 27 Jun 2008 12:53: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 B63F928C1E4 for ; Fri, 27 Jun 2008 12:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 vTA8q5AuqklY for ; Fri, 27 Jun 2008 12:53:47 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id C015A28C1DE for ; Fri, 27 Jun 2008 12:53:47 -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 1KCK0s-0006L4-DI; Fri, 27 Jun 2008 14:53:45 -0500 From: "Brian Rosen" To: "'Stark, Barbara'" , References: <7582BC68E4994F4ABF0BD4723975C3FA080ECE5C@crexc41p> Date: Fri, 27 Jun 2008 15:53:47 -0400 Message-ID: <17b101c8d88f$86ef93f0$bf320446@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA080ECE5C@crexc41p> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciRB9vLHaJTnHq9Q0yXx0elTeXdwBFPkx4A 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] phonebcp-04 comments 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 Barbara Thanks for your continuing careful reading of these documents. I have dealt with all of your comments by changes in the text except: > 6. ED-62 5. > "A Route header SHOULD be present with a PSAP URI obtained from LoST > (see Section 8) and the loose route parameter." > The loose route parameter part of this really confused me. Is this > saying that the loose route parameter should be present in the Route > header? If so, is it suggesting there is a requirement on the End Device > to validate for the presence of lr, and insert it if it isn't there? Or > is it expected that URIs sent by LoST will simply include the lr > parameter? If the expectation is for the LoST server, then that needs to > go in the LoST doc, and not in and ED requirement. If the expectation is > for the LoST server, I recommend deleting " and the loose route > parameter", because the ED simply includes the URI exactly as provided > by LoST. If the expectation is that the ED ensure the presence of the lr > parameter, then this needs to be explicitly stated. The requirement is on the end device. The parameter is not a URI parameter but a header parameter: you are signaling that the call must hit the PSAP URI, but need not do so directly (loose route). It would not come from the LoST server. The server should NOT have an lr parameter under any circumstances. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 27 14:03: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 EE47B28C1EC; Fri, 27 Jun 2008 14:03: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 B62553A6951 for ; Fri, 27 Jun 2008 14:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 ZLeZFjNyUo6d for ; Fri, 27 Jun 2008 14:03:39 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id B392E3A687C for ; Fri, 27 Jun 2008 14:03: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 1KCK11-0006Lf-EJ; Fri, 27 Jun 2008 14:53:51 -0500 From: "Brian Rosen" To: "'Brian Rosen'" , "'Henning Schulzrinne'" References: <47CAE9D4.9080702@gmx.net><022001c88b61$99562f70$6901a8c0@cis.neustar.com><5A9E3E25-6ABB-4498-9B15-9BD7D626D028@cs.columbia.edu> <023c01c88b70$51b95e80$6901a8c0@cis.neustar.com> Date: Fri, 27 Jun 2008 15:53:56 -0400 Message-ID: <17b201c8d88f$8a93e3d0$bf320446@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <023c01c88b70$51b95e80$6901a8c0@cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciLZQasuCKNyJp1RVOlR+mDMQ83mQACzC7AEYYDXHA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-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 editing -framework and -phonebcp and I have a problem implementing this decision: Currently, there are no other requirements on LoST servers. All -phonebcp requirements are prefaced by the entity to whom they apply (ED- for end devices, AN for access network, SP for service provider and INT for intermediate devices). I don't have a prefix for the LoST server. It's not clear who will run the LoST server in every jurisdiction. In North America, the "9-1-1 Authority" will provide a LoST server, but an access network, or a calling network can arrange a local copy of the server for its use. So my problem is, what prefix do I put on the requirement that the LoST server MUST return dial strings for emergency services? I don't have a good answer, but if no one else has a better answer I will label it "AN", and note that it applies to whomever runs the LoST server, who may or may not be the access network. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Friday, March 21, 2008 12:26 PM > To: 'Henning Schulzrinne' > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05 > > Anyone else on the list have a problem in making this a must (small must > in > framework, MUST in phonebcp)? > > Brian > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, March 21, 2008 11:06 AM > To: Brian Rosen > Cc: 'Karl Heinz Wolf'; 'Hannes Tschofenig'; ecrit@ietf.org > Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05 > > > On Mar 21, 2008, at 10:41 AM, Brian Rosen wrote: > > > Thanks a lot for your comments. I agree with all of your comments > > except > > the page 10 LoST return of dialstring may/must. I don't think it's > > possible > > to make it MUST because there are systems such as 3GPP that work > > without it. > > I could see a SHOULD, where the exception is a closed system where > > the LoST > > operator knows for certain that all devices that query it have the > > correct > > dial string via some other mechanism. > > > > Henning, does that sound about right to you? > > > > I'm ok with documenting a clear exception, but I wonder whether there > is harm in requiring that LoST always returns the dial string, for > several reasons: > > - You never know who will connect to a server, even if you believe > that it can only be accessed from within a certain physical network. > This also tends to change over time; upgrading servers and data sets > at that time seems more error-prone, easy to forget and painful. > > - It doesn't seem particularly onerous to include this information. > It's not secret, it's not hard to maintain and it doesn't change. > > - Longer term, IMS may get more open (see Verizon...), so it may be > harder to make the distinction. > > - It seems difficult to describe the exception in a way that covers > what we want without encouraging "bad" behavior. > > Thus, I think interoperability and robustness argue for MUST. If > certain specialized systems end up ignoring the information in favor > of local configuration, that's a separate problem. Given that > disagreement over the dialstring seems unlikely and obvious, I'd > rather have two sources than none. > > Henning > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit