From mlinsner@cisco.com Fri Jan 8 07:46:34 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D97A03A67EA for ; Fri, 8 Jan 2010 07:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EFudmf2xAlB for ; Fri, 8 Jan 2010 07:46:33 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9A4BB3A67B0 for ; Fri, 8 Jan 2010 07:46:33 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAELiRktAZnwN/2dsb2JhbACcO6QNlBOELwQ X-IronPort-AV: E=Sophos;i="4.49,242,1262563200"; d="scan'208";a="78986755" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 Jan 2010 15:46:31 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o08FkVqu012182 for ; Fri, 8 Jan 2010 15:46:31 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 16:46:30 +0100 Received: from [10.116.195.126] ([10.116.195.126]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 16:46:30 +0100 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 08 Jan 2010 10:46:26 -0500 From: Marc Linsner To: "ecrit@ietf.org" Message-ID: Thread-Topic: ECRIT Virtual Interim Meeting - February Thread-Index: AcqQebxqK0TfvUSYEUSBOdFU6CL1sw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Jan 2010 15:46:30.0271 (UTC) FILETIME=[BEF5E8F0:01CA9079] Subject: [Ecrit] ECRIT Virtual Interim Meeting - February 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: , X-List-Received-Date: Fri, 08 Jan 2010 15:46:34 -0000 In an effort to continue progress, we've decided to hold a Virtual Interim Meeting in February. The agenda for the meeting will be posted a couple of weeks prior to the call. If you think you might attend, we're offering a few different days/times for the call, please visit the doodle page below and select your preference. http://www.doodle.com/29pns6waen77stgt We'll close the selection process at COB on Friday, January 15. Thanks, Marc & Hannes From hannes.tschofenig@nsn.com Mon Jan 11 00:53:16 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE6BC3A68C3 for ; Mon, 11 Jan 2010 00:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.550, 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 8bnQVDznzyTC for ; Mon, 11 Jan 2010 00:53:15 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 6A3DD3A68B7 for ; Mon, 11 Jan 2010 00:53:15 -0800 (PST) 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 o0B8rAjO009968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 11 Jan 2010 09:53:10 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o0B8r8ol013060 for ; Mon, 11 Jan 2010 09:53:09 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 09:53:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jan 2010 10:56:56 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45020B7F36@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review Request for Rough Location Document Thread-Index: AcqRn23FKWr+sBn3S720UlHOzH8PxgA9s/kA From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 11 Jan 2010 08:53:01.0628 (UTC) FILETIME=[7B18A7C0:01CA929B] Subject: [Ecrit] FW: Review Request for Rough Location Document 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: , X-List-Received-Date: Mon, 11 Jan 2010 08:53:16 -0000 Henning did a detailed review of the rough location document.=20 Thanks, Henning! Ciao Hannes PS: I removed the scanned document with Henning's mark-up (because of size restrictions on this mailing list).=20 >-----Original Message----- >From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 >Sent: 10 January, 2010 04:47 >To: Tschofenig, Hannes (NSN - FI/Espoo) >Cc: L.Liess@telekom.de; akutt@ebay.com; Stark, Barbara; ext=20 >Richard Barnes; Roger Marshall; Marc Linsner >Subject: Re: Review Request for Rough Location Document > >Hannes, > >I've done a quick pass though the document. Judging from the=20 >assortment of typos still left, the number of people who have=20 >read this document seems very small :-) > >I'm including my usual red-pen mark-up. Please let me know if=20 >you cannot read the mark-up. Some general stylistic and=20 >technical remarks, in no particular order: > >- The highly-parenthetical style makes reading tedious.=20 >Consider rewriting sentences to flow more naturally, with more=20 >conjunctions and "glue". > >- It's mentioned in passing, but I think it should be=20 >emphasized that the rough location returned can be either a=20 >single point or some other area (polygon). The document=20 >sometimes seems to assume one, sometimes the other, and it=20 >isn't always clear where the distinction matters. > >- I was unable to understand the civic location description.=20 >Consider rewriting the section, and at least providing an example. > >- The privacy motivation in the introduction seems=20 >disingenuous. We all know that the primary motivation is=20 >business, not privacy. I can kind of follow the privacy issue=20 >discussion in the security considerations, although I would=20 >reorganize the description by starting with the problem of=20 >identifier trustworthiness. I think it would be more honest to=20 >have the e.g., in the introduction refer to business reasons=20 >or at least provide a reference to the security considerations=20 >section for an explanation, since not providing location to=20 >the device itself for privacy reasons is rather=20 >counter-intuitive, given that most privacy laws stipulate=20 >access to your own information as a fundamental tenet of good=20 >privacy practices. > >- Out-of-area PSAPs may well need access to precise location=20 >information if they serve as backup PSAPs. This is the common=20 >model, e.g., for statewide emergencies. > >- I found Section 3.1 et seq. very hard to follow. I don't=20 >think adding more text helps - it would likely just add=20 >confusion. If I understand the concept correctly, the=20 >mechanism is relatively simple: You overlay all the service=20 >areas for the different service URNs for the whole area served=20 >by a location provider, as if you were drawing them all on a=20 >single piece of paper, with the same color pen. Since the=20 >service regions are polygons, these contiguous regions will=20 >also be polygons. These regions have the property that all=20 >points within the region return the same service URL for all=20 >possible (emergency) service URNs. > >I'm not sure how this would translate to civic addresses. > >The figure (Fig. 1) is not helpful at all. > >In summary, I think this draft needs at least one more revision. > >Henning > > From hannes.tschofenig@nsn.com Tue Jan 12 03:20:44 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FC6E3A69B0 for ; Tue, 12 Jan 2010 03:20:44 -0800 (PST) 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 dNI2pcKuVuZO for ; Tue, 12 Jan 2010 03:20:43 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 99CEB3A67BE for ; Tue, 12 Jan 2010 03:20:42 -0800 (PST) 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 o0CBKTXa004865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Jan 2010 12:20:29 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o0CBKSvV011231; Tue, 12 Jan 2010 12:20:29 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Jan 2010 12:20:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jan 2010 13:24:23 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45020DF542@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Emergency Text Messaging Contributions Thread-Index: AcqTecq6gkXh1AV9QVKTMaqPRQ0tNQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: , , , , X-OriginalArrivalTime: 12 Jan 2010 11:20:28.0698 (UTC) FILETIME=[3EC627A0:01CA9379] Cc: ecrit@ietf.org Subject: [Ecrit] Emergency Text Messaging Contributions 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: , X-List-Received-Date: Tue, 12 Jan 2010 11:20:44 -0000 Hi Henning, Jong, Wonsang, Piotr, Michael,=20 Thanks for your contributions regarding emergency text messaging. I looked at two documents, namely at your draft and your paper. The two documents are:=20 --------------------------- *** draft draft-kim-ecrit-text-00 http://tools.ietf.org/id/draft-kim-ecrit-text-00.txt Abstract:=20 This memo describes best current practices on how to use the SIP MESSAGE method for emergency text messaging from citizen and visitors to authorities. *** Using IM and SMS for for Emergency Text Communications http://iptcomm.org/iptcomm2009papers/1569204635.pdf Abstract: Currently, text communication cannot be used to ask for help in emergency situations. Even in the Next Generation 9-1-1 system, an IP/SIP-based emergency communication system, there has been no investigation into how text communications such as Instant Messaging (IM) and Short Message Service (SMS) can be integrated. We identify the technical challenges in the integration of IM and SMS networks with the NG9-1-1 system, and propose a solution for each challenge. We also describe a working prototype system using our approach. --------------------------- I was wonder whether you have had some thoughts already of what should be done in the ECRIT working group with your new draft. * Are you requesting a presentation slot for the next IETF meeting?=20 * Are you suggesting that the group investigates different alternatives for emergency text messaging (e.g., session-based and non-session based methods)? Ciao Hannes PS: You might find it interesting that NENA has also done some work in this area (including a detailed scenario activity in the NG Messaging working group). Additionally, there are two EU funded projects investigating this subject, namely the REACH-112 project and the PEACE project.=20 From hannes.tschofenig@nsn.com Tue Jan 19 04:18:12 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A1833A683F for ; Tue, 19 Jan 2010 04:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.138, 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 EL0fdyV4Nczy for ; Tue, 19 Jan 2010 04:18:11 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 375A03A6A13 for ; Tue, 19 Jan 2010 04:18:11 -0800 (PST) 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 o0JCI5lb004679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 19 Jan 2010 13:18:05 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o0JCI1B3006558 for ; Tue, 19 Jan 2010 13:18:05 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 13:18:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jan 2010 14:22:04 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45021310CE@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for draft-ietf-ecrit-lost-servicelistboundary-01.txt Thread-Index: AcqZAgLEzPvK0PL+RVmh7rydsHgH8Q== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 19 Jan 2010 12:18:03.0437 (UTC) FILETIME=[72D9BDD0:01CA9901] Subject: [Ecrit] WGLC for draft-ietf-ecrit-lost-servicelistboundary-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: , X-List-Received-Date: Tue, 19 Jan 2010 12:18:12 -0000 Folks, Karl Heinz indicated that the current version of the ServiceListBoundary draft is ready for a WGLC. Here is the latest draft: http://www.ietf.org/id/draft-ietf-ecrit-lost-servicelistboundary-01.txt So, please, have a look at this version and provide your feedback. This WGLC will end on the 2nd Feb. 2010. Ciao Hannes & Marc From root@core3.amsl.com Tue Jan 19 08:15:02 2010 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7926A3A6AB5; Tue, 19 Jan 2010 08:15:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100119161502.7926A3A6AB5@core3.amsl.com> Date: Tue, 19 Jan 2010 08:15:02 -0800 (PST) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-14.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: , X-List-Received-Date: Tue, 19 Jan 2010 16:15:03 -0000 --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-14.txt Pages : 45 Date : 2010-01-19 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. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 23, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-14.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-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-19080549.I-D@ietf.org> --NextPart-- From brian.rosen@neustar.biz Tue Jan 19 08:16:15 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726C63A6AB7 for ; Tue, 19 Jan 2010 08:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 j9Noi57wRBdk for ; Tue, 19 Jan 2010 08:16:14 -0800 (PST) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id 3BDA23A6A2F for ; Tue, 19 Jan 2010 08:16:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=neustar.biz; s=neustarbiz; t=1263917758; x=1579277096; q=dns/txt; h=Date: Subject:From:Message-ID:Content-type:Content-transfer-encoding; bh=eqiBBEaZ5pO772D0LOMJ6HmNy153z07gBFSfhw6JiIA=; b=NtEdlocFmM3X6 llDHVzQBGJtwp1htpo0DqlC/6Bqana6KHKOgz8uJkI4/AzuLZTZlYdly5XDUqiKI yPeriNQ8g== Received: from ([10.31.13.50]) by chihiron2.nc.neustar.com with ESMTP id 5202415.21665114; Tue, 19 Jan 2010 11:15:57 -0500 Received: from 192.168.128.104 ([192.168.128.104]) by STNTEXCH11.cis.neustar.com ([10.31.13.50]) with Microsoft Exchange Server HTTP-DAV ; Tue, 19 Jan 2010 16:15:57 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 19 Jan 2010 11:15:55 -0500 From: "Rosen, Brian" To: Message-ID: Thread-Topic: Update to phonebcp Thread-Index: AcqZIq1dr1KWc0XGa0mQmiNqGeX/aA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [Ecrit] Update to 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: , X-List-Received-Date: Tue, 19 Jan 2010 16:16:15 -0000 I've updated phonebcp. The changes are: A) update ED-65 to change the SDP to SHOULD. There is text on why an offerless INVITE is problematic, but acceptable. B) update references C) edit ED-24 to remove reference to LLDP-MED in favor of a more generic "other location technologies that are specific to the type of access network" From Hannes.Tschofenig@gmx.net Tue Jan 19 10:38:09 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3A9D3A67AA for ; Tue, 19 Jan 2010 10:38:09 -0800 (PST) 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 fifAVT2RwZGs for ; Tue, 19 Jan 2010 10:38:07 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D81553A6782 for ; Tue, 19 Jan 2010 10:37:03 -0800 (PST) Received: (qmail invoked by alias); 19 Jan 2010 18:36:31 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO 4FIL42860) [88.115.222.204] by mail.gmx.net (mp061) with SMTP; 19 Jan 2010 19:36:31 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18WFFlqmp4WdH7J/Gd3RnV1qDjT86UZMliEEigvmN 0YDdlui7Pcdf2t From: "Hannes Tschofenig" To: "'Rosen, Brian'" , References: Date: Tue, 19 Jan 2010 20:40:22 +0200 Message-ID: <02a401ca9936$e2efa3c0$02ffa8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcqZIq1dr1KWc0XGa0mQmiNqGeX/aAAFBN/A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57999999999999996 Subject: Re: [Ecrit] Update to 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: , X-List-Received-Date: Tue, 19 Jan 2010 18:38:09 -0000 Thanks Brian for addressing the IESG feedback in order to move the document along through the publication process. The changes make sense to me. Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Rosen, Brian >Sent: 19 January, 2010 18:16 >To: ecrit@ietf.org >Subject: [Ecrit] Update to phonebcp > >I've updated phonebcp. The changes are: >A) update ED-65 to change the SDP to SHOULD. There is text on >why an offerless INVITE is problematic, but acceptable. >B) update references >C) edit ED-24 to remove reference to LLDP-MED in favor of a >more generic "other location technologies that are specific to >the type of access network" > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > From andreaf@cs.columbia.edu Tue Jan 19 12:51:41 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 467103A67F7 for ; Tue, 19 Jan 2010 12:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ab2+x6dNrvvz for ; Tue, 19 Jan 2010 12:51:40 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 1D2FB3A67D8 for ; Tue, 19 Jan 2010 12:51:40 -0800 (PST) Received: from [128.59.20.159] (irt-af.cs.columbia.edu [128.59.20.159]) (user=agf2104 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o0JKpYGp012964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 19 Jan 2010 15:51:35 -0500 (EST) Message-ID: <4B561B56.2080204@cs.columbia.edu> Date: Tue, 19 Jan 2010 15:51:34 -0500 From: "Andrea G. Forte" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ECRIT Content-Type: multipart/alternative; boundary="------------070100070104050505090803" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Subject: [Ecrit] draft-forte-ecrit-service-classification-03 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: , X-List-Received-Date: Tue, 19 Jan 2010 20:51:41 -0000 This is a multi-part message in MIME format. --------------070100070104050505090803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit A new version of the draft is available for your consideration. Abstract: "This document creates a registry for describing the types of services available at a specific location. The registry is expected to be referenced by other protocols that need a common set of service terms as protocol constants. In particular, we define location-based service as either a point at a specific geographic location (e.g., bus stop) or a service covering a specific region (e.g., pizza delivery)." http://www.ietf.org/id/draft-forte-ecrit-service-classification-03.txt Thanks, -Andrea P.S. Yes, I am aware that the year in the draft is wrong ... old habits ... -- http://www.cs.columbia.edu/~andreaf --------------070100070104050505090803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit A new version of the draft is available for your consideration.

Abstract:
"This document creates a registry for describing the types of services available at a specific location. The registry is expected to be referenced by other protocols that need a common set of service terms as protocol constants. In particular, we define location-based service as either a point at a specific geographic location (e.g., bus stop) or a service covering a specific region (e.g., pizza delivery)."

http://www.ietf.org/id/draft-forte-ecrit-service-classification-03.txt

Thanks,
-Andrea

P.S.
Yes, I am aware that the year in the draft is wrong ... old habits ...

--
http://www.cs.columbia.edu/~andreaf
--------------070100070104050505090803-- From rbarnes@bbn.com Tue Jan 19 15:14:59 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40B333A68AD for ; Tue, 19 Jan 2010 15:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.108, 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 nBzNkt2OGH+o for ; Tue, 19 Jan 2010 15:14:58 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id E1C003A62C1 for ; Tue, 19 Jan 2010 15:14:57 -0800 (PST) Received: from ros-dhcp192-1-51-107.bbn.com ([192.1.51.107]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NXNHh-0004y1-BL for ecrit@ietf.org; Tue, 19 Jan 2010 18:14:53 -0500 Message-Id: From: "Richard L. Barnes" To: ECRIT Content-Type: multipart/alternative; boundary=Apple-Mail-26-20366984 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 19 Jan 2010 18:14:52 -0500 References: <20100119231149.505D83A6872@core3.amsl.com> X-Mailer: Apple Mail (2.936) Subject: [Ecrit] Fwd: New Version Notification for draft-ietf-ecrit-rough-loc-01 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: , X-List-Received-Date: Tue, 19 Jan 2010 23:14:59 -0000 --Apple-Mail-26-20366984 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable This document has been updated to reflect comments from a few post-=20 WGLC reviews. -- Expanded explanation of diagrams=20 -- New, simpler algorithm for location filter computation -- Editorial changes throughout Thanks to Henning Schulzrinne, Andres K=FCtt, and Laura Liess for =20 detailed comments. --Richard Begin forwarded message: > From: IETF I-D Submission Tool > Date: January 19, 2010 6:11:48 PM EST > To: rbarnes@bbn.com > Cc: mlepinski@bbn.com > Subject: New Version Notification for draft-ietf-ecrit-rough-loc-01 > > > A new version of I-D, draft-ietf-ecrit-rough-loc-01.txt has been =20 > successfuly submitted by Richard Barnes and posted to the IETF =20 > repository. > > Filename: draft-ietf-ecrit-rough-loc > Revision: 01 > Title: Using Imprecise Location for Emergency Context = Resolution > Creation_date: 2010-01-20 > WG ID: ecrit > Number_of_pages: 17 > > Abstract: > Emergency calling works best when precise location is available for > emergency call routing. However, there are situations in which a > location provider is unable or unwilling to provide precise location, > yet still wishes to enable subscribers to make emergency calls. This > document describes the level of location accuracy that providers must > provide to enable emergency call routing. In addition, we descibe > how emergency services and non-emergency services can be invoked by > an endpoint that does not have access to its precise location. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on July 24, 2010. > > Copyright Notice > > Copyright (c) 2010 IETF Trust and the persons identified as the > document authors. All rights reserved. > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > > > The IETF Secretariat. > > --Apple-Mail-26-20366984 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This document has been updated = to reflect comments from a few post-WGLC reviews.  
-- Expanded = explanation of diagrams 
-- New, simpler algorithm for = location filter computation
-- Editorial changes = throughout

Thanks to Henning Schulzrinne, = Andres K=FCtt, and Laura Liess for detailed = comments.

--Richard


<= br>
Begin forwarded message:

From: = IETF I-D Submission Tool <idsubmission@ietf.org>=
Date: January 19, 2010 6:11:48 PM = EST
Subject: = New Version Notification for = draft-ietf-ecrit-rough-loc-01 


A new = version of I-D, draft-ietf-ecrit-rough-loc-01.txt has been successfuly = submitted by Richard Barnes and posted to the IETF = repository.

Filename: = draft-ietf-ecrit-rough-loc
Revision: 01
Title: Using = Imprecise Location for Emergency Context = Resolution
Creation_date: 2010-01-20
WG ID: = ecrit
Number_of_pages: 17

Abstract:
Emergency calling works = best when precise location is available for
emergency call routing. =  However, there are situations in which a
location provider is = unable or unwilling to provide precise location,
yet still wishes to = enable subscribers to make emergency calls.  This
document = describes the level of location accuracy that providers must
provide = to enable emergency call routing.  In addition, we descibe
how = emergency services and non-emergency services can be invoked by
an = endpoint that does not have access to its precise = location.

Status of this Memo

This Internet-Draft is = submitted to IETF in full conformance with the
provisions of BCP 78 = and BCP 79.

Internet-Drafts are working documents of the Internet = Engineering
Task Force (IETF), its areas, and its working groups. =  Note that
other groups may also distribute working documents as = Internet-
Drafts.

Internet-Drafts are draft documents valid = for a maximum of six months
and may be updated, replaced, or = obsoleted by other documents at any
time.  It is inappropriate = to use Internet-Drafts as reference
material or to cite them other = than as "work in progress."

The list of current Internet-Drafts = can be accessed at
http://www.ietf.org/ie= tf/1id-abstracts.txt.

The list of Internet-Draft Shadow = Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 24, = 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and = the persons identified as the
document authors.  All rights = reserved.
This document is subject to BCP 78 and the IETF Trust's = Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/lice= nse-info) in effect on the date of
publication of this document. =  Please review these documents
carefully, as they describe your = rights and restrictions with respect
to this document.  Code = Components extracted from this document must
include Simplified BSD = License text as described in Section 4.e of
the Trust Legal = Provisions and are provided without warranty as
described in the BSD = License.



The IETF = Secretariat.



= --Apple-Mail-26-20366984-- From root@core3.amsl.com Tue Jan 19 15:15:01 2010 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B41A43A6921; Tue, 19 Jan 2010 15:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100119231501.B41A43A6921@core3.amsl.com> Date: Tue, 19 Jan 2010 15:15:01 -0800 (PST) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-rough-loc-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: , X-List-Received-Date: Tue, 19 Jan 2010 23:15:01 -0000 --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 : Using Imprecise Location for Emergency Context Resolution Author(s) : R. Barnes, M. Lepinski Filename : draft-ietf-ecrit-rough-loc-01.txt Pages : 17 Date : 2010-01-19 Emergency calling works best when precise location is available for emergency call routing. However, there are situations in which a location provider is unable or unwilling to provide precise location, yet still wishes to enable subscribers to make emergency calls. This document describes the level of location accuracy that providers must provide to enable emergency call routing. In addition, we descibe how emergency services and non-emergency services can be invoked by an endpoint that does not have access to its precise location. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 24, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-rough-loc-01.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-rough-loc-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-19151145.I-D@ietf.org> --NextPart-- From Martin.Thomson@andrew.com Wed Jan 20 15:52:04 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA8D23A6AA4 for ; Wed, 20 Jan 2010 15:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 KdabqPTasxm7 for ; Wed, 20 Jan 2010 15:52:03 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 9F0AC28C0F3 for ; Wed, 20 Jan 2010 15:52:01 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:43586 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S68509Ab0ATXv5 (ORCPT ); Wed, 20 Jan 2010 17:51:57 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 20 Jan 2010 17:51:57 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 21 Jan 2010 07:51:55 +0800 From: "Thomson, Martin" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ecrit@ietf.org" Date: Thu, 21 Jan 2010 07:52:59 +0800 Thread-Topic: WGLC for draft-ietf-ecrit-lost-servicelistboundary-01.txt Thread-Index: AcqZAgLEzPvK0PL+RVmh7rydsHgH8QBIlj4A Message-ID: <8B0A9FCBB9832F43971E38010638454F032E4A9A88@SISPE7MB1.commscope.com> References: <3D3C75174CB95F42AD6BCC56E5555B45021310CE@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45021310CE@FIESEXC015.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Ecrit] WGLC for draft-ietf-ecrit-lost-servicelistboundary-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: , X-List-Received-Date: Wed, 20 Jan 2010 23:52:04 -0000 VGhpcyBkb2N1bWVudCBuZWVkcyBhIGxpdHRsZSBtb3JlIGF0dGVudGlvbiB0byB0aGUgWE1MLCBw YXJ0aWN1bGFybHkgdGhlIFJlbGF4Tkcgc2NoZW1hLCB3aGljaCBJIGJlbGlldmUgaGFzIHNvbWUg ZXJyb3JzLiAgVGhlIHRleHQgaXMgY2xlYXIgYW5kIHJlYWRhYmxlIGFuZCB0aGUgZXhhbXBsZXMg Y29udmV5IHRoZSBpbnRlbnQgd2VsbCwgYnV0IGFjY3VyYXRlIHNjaGVtYSBpcyBhbiBpbXBvcnRh bnQgcGFydCBvZiB0aGVzZSBzcGVjaWZpY2F0aW9ucy4NCg0KSSBzZWUgbm8gcmVhc29uIGZvciB0 aGUgZG9jdW1lbnQgdG8gc3RheSBpbiB0aGUgV0cgb25jZSB0aGlzIHByb2JsZW0gaXMgcmVzb2x2 ZWQuDQoNClNlY3Rpb24gMyAoZ2VuZXJhbCk6IA0KICBJcyBpdCBpbnRlbnRpb25hbCB0byB1c2Ug dGhlIHNhbWUgZWxlbWVudHMgZm9yIHRoZSByZXF1ZXN0IGFuZCByZXNwb25zZSAtIHRoZXkgaGF2 ZSBkcmFtYXRpY2FsbHkgZGlmZmVyZW50IGNvbnRlbnQgbW9kZWxzLiAgV2hpbGUgcG9zc2libGUs IHRoaXMgY2FuIGJlIGNvbmZ1c2luZywgbm90IHRvIG1lbnRpb24gaW5jb252ZW5pZW50IGZvciBz Y2hlbWEgZGVzaWduLiAgUGVyaGFwcyB0aGUgcmVxdWVzdCBjb3VsZCBiZSBpZGVudGlmaWVkIGRp ZmZlcmVudGx5Lg0KDQpTZWN0aW9uIDMuMToNCiAtIHMvaXN0L2lzLw0KIC0gSSBhc3N1bWUgdGhh dCB0aGUgZXhhbXBsZSBjaXZpYyBhZGRyZXNzIGJvdW5kYXJ5IGlzIGluIEVuZ2xpc2g/IHhtbDps YW5nPSJlbiINCg0KDQpTZWN0aW9uIDUuMToNCiAgTXkgUmVsYXhORy1mdSBpcyBub3QgYXMgZ29v ZCBhcyBteSBYTUwgU2NoZW1hLWZ1LCBlc3BlY2lhbGx5IHNpbmNlIEkgcHJlZmVyIHRoZSBjb21w YWN0IHN5bnRheCwgYnV0IEkgdGhpbmsgdGhhdCB0aGlzIGlzbid0IHJpZ2h0LiAgIFVuZXhwbGFp bmVkIGVsbGlwc2VzIGFyZSBhIGRlYWQgZ2l2ZWF3YXkuDQoNCkkgd291bGQgaGF2ZSBleHBlY3Rl ZCBzb21ldGhpbmcgbGlrZSB3aGF0IEkndmUgc2tldGNoZWQgb3V0IGJlbG93LCB3aXRoIHRoZSBu b3RlIHRoYXQgdGhlIGVudGlyZSA8aW5jbHVkZT4gc2VjdGlvbiBpc24ndCByZWFsbHkgbmVlZGVk ICh0aG91Z2ggdGhpcyBjaGFuZ2VzIHdoZXJlIHRoZSBlbGVtZW50cyBhcmUgaW5jbHVkZWQgLSB0 aGUgZHJhZnQgdGFja3MgdGhlbSBvbiB0aGUgZW5kLCBhcyBpcyBuYXR1cmFsLCBidXQgdGhlIGFj dHVhbCBleHRlbnNpb24gcG9pbnQgaXMgYWJvdmUgdGhlIGxvY2F0aW9uVXNlZCBpbiB0aGUgcmVz cG9uc2UpLg0KDQpJJ2xsIG5vdGUgYWxzbyB0aGF0IHRoZSBzdGFydCBlbGVtZW50IGFsc28gbmVl ZHMgdG8gYmUgcmVkZWZpbmVkLiAgSXQncyBhIHJlYWwgbnVpc2FuY2UgdGhhdCBMb1NUIGRpZG4n dCBtYWtlIHRoaXMgZWFzeSBieSBkZWZpbmluZyBhIHN0YXJ0LWdyb3VwLCBvciBieSBhZGRpbmcg bm90TG9zdCB0byB0aGUgZGVmYXVsdCBzdGFydCBncm91cC4gIE9oIHdlbGwuDQoNCjxncmFtbWFy IC4uLj4NCg0KICA8aW5jbHVkZSBocmVmPSI/Pz9sb3N0IHNjaGVtYT8/PyI+DQogICAgPCEtLSBy ZWRlZmluaXRpb24gb2YgTG9TVCBlbGVtZW50cyAtLT4NCg0KICAgICAgICAgICA8c3RhcnQ+DQog ICAgICAgPGNob2ljZT4NCiAgICAgICAgIDxyZWYgbmFtZT0iZmluZFNlcnZpY2UiLz4NCiAgICAg ICAgIDxyZWYgbmFtZT0ibGlzdFNlcnZpY2VzIi8+DQogICAgICAgICA8cmVmIG5hbWU9Imxpc3RT ZXJ2aWNlc0J5TG9jYXRpb24iLz4NCiAgICAgICAgIDxyZWYgbmFtZT0iZ2V0U2VydmljZUJvdW5k YXJ5Ii8+DQogICAgICAgICA8cmVmIG5hbWU9ImZpbmRTZXJ2aWNlUmVzcG9uc2UiLz4NCiAgICAg ICAgIDxyZWYgbmFtZT0ibGlzdFNlcnZpY2VzUmVzcG9uc2UiLz4NCiAgICAgICAgIDxyZWYgbmFt ZT0ibGlzdFNlcnZpY2VzQnlMb2NhdGlvblJlc3BvbnNlIi8+DQogICAgICAgICA8cmVmIG5hbWU9 ImdldFNlcnZpY2VCb3VuZGFyeVJlc3BvbnNlIi8+DQogICAgICAgICA8cmVmIG5hbWU9ImVycm9y cyIvPg0KICAgICAgICAgPHJlZiBuYW1lPSJyZWRpcmVjdCIvPg0KICAgICAgICAgPHJlZiBuYW1l PSJzbGI6Z2V0U2VydmljZUxpc3RCb3VuZGFyeSAiLz4NCiAgICAgICAgIDxyZWYgbmFtZT0ic2xi OmdldFNlcnZpY2VMaXN0Qm91bmRhcnlSZXNwb25zZSIvPg0KICAgICAgIDwvY2hvaWNlPg0KICAg ICAgICAgICA8L3N0YXJ0Pg0KDQogICAgICAgPGRlZmluZSBuYW1lPSJsaXN0U2VydmljZXMiPg0K ICAgICAgICAgPGVsZW1lbnQgbmFtZT0ibGlzdFNlcnZpY2VzIj4NCiAgICAgICAgICAgPHJlZiBu YW1lPSJjb21tb25SZXF1ZXN0UGF0dGVybiIvPg0KCSAgICAgPHJlZiBuYW1lPSJzbGI6c2Vydmlj ZUxpc3RCb3VuZGFyeVJlcXVlc3QiLz4NCiAgICAgICAgIDwvZWxlbWVudD4NCiAgICAgICA8L2Rl ZmluZT4NCg0KICAgICAgIDxkZWZpbmUgbmFtZT0ibGlzdFNlcnZpY2VzQnlMb2NhdGlvblJlc3Bv bnNlIj4NCiAgICAgICAgIDxlbGVtZW50IG5hbWU9Imxpc3RTZXJ2aWNlc0J5TG9jYXRpb25SZXNw b25zZSI+DQogICAgICAgICAgIDxyZWYgbmFtZT0ic2VydmljZUxpc3QiLz4NCiAgICAgICAgICAg PHJlZiBuYW1lPSJjb21tb25SZXNwb25zZVBhdHRlcm4iLz4NCiAgICAgICAgICAgPHJlZiBuYW1l PSJsb2NhdGlvblVzZWQiLz4NCiAgICAgICAgICAgPGNob2ljZT4NCgkgICAgICAgPHJlZiBuYW1l PSJzbGI6c2VydmljZUxpc3RCb3VuZGFyeVJlc3BvbnNlIi8+DQoJIAkgPHJlZiBuYW1lPSJzbGI6 c2VydmljZUxpc3RCb3VuZGFyeVJlZmVyZW5jZSIvPg0KICAgICAgICAgICA8L2Nob2ljZT4NCiAg ICAgICAgIDwvZWxlbWVudD4NCiAgICAgICA8L2RlZmluZT4NCg0KICA8L2luY2x1ZGU+DQoNCg0K ICAgICAgICAgPGRlZmluZSBuYW1lPSJzZXJ2aWNlTGlzdEJvdW5kYXJ5UmVxdWVzdCI+DQogICAg ICAgICAgIDxlbGVtZW50IG5hbWU9InNlcnZpY2VMaXN0Qm91bmRhcnkiPg0KICAgICAgICAgICAg IDxyZWYgbmFtZT0ic2xiOnNlcnZpY2VMaXN0Qm91bmRhcnkiLz4NCiAgICAgICAgICAgICAgIDxj aG9pY2U+DQogICAgICAgICAgICAgICAgPHZhbHVlPnZhbHVlPC92YWx1ZT4NCiAgICAgICAgICAg ICAgICA8dmFsdWU+cmVmZXJlbmNlPC92YWx1ZT4NCiAgICAgICAgICAgICA8L2Nob2ljZT4NCiAg ICAgICAgICAgPC9lbGVtZW50Pg0KICAgICAgICAgPC9kZWZpbmU+DQoNCiAgICAgICAgIDxkZWZp bmUgbmFtZT0ic2VydmljZUxpc3RCb3VuZGFyeVJlc3BvbnNlIj4NCiAgICAgICAgICAgPGVsZW1l bnQgbmFtZT0ic2VydmljZUxpc3RCb3VuZGFyeSI+DQogICAgICAgICAgICAgPHJlZiBuYW1lPSJz bGI6c2VydmljZUxpc3RCb3VuZGFyeSIvPg0KICAgICAgICAgICAgICAgPGF0dHJpYnV0ZSBuYW1l PSJwcm9maWxlIi8+DQogICAgICAgICAgICAgICA8cmVmIG5hbWU9ImxzOmxvY2F0aW9uSW5mb3Jt YXRpb24iLz4NCiAgICAgICAgICAgPC9lbGVtZW50Pg0KICAgICAgICAgPC9kZWZpbmU+DQoNCiAg ICAgICAgIDxkZWZpbmUgbmFtZT0ic2VydmljZUxpc3RCb3VuZGFyeVJlZmVyZW5jZSI+DQogICAg ICAgICAgIDxlbGVtZW50IG5hbWU9InNlcnZpY2VMaXN0Qm91bmRhcnlSZWZlcmVuY2UiPg0KICAg ICAgICAgICAgIDxyZWYgbmFtZT0ic2xiOnNlcnZpY2VMaXN0Qm91bmRhcnlSZWZlcmVuY2UiLz4N CiAgICAgICAgICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0ic291cmNlIi8+DQogICAgICAgICAgICAg ICA8YXR0cmlidXRlIG5hbWU9InNlcnZpY2VMaXN0S2V5Ii8+DQogICAgICAgICAgIDwvZWxlbWVu dD4NCiAgICAgICAgIDwvZGVmaW5lPg0KDQo8IS0tIHRoZW4gdGhlIGdldCBzZXJ2aWNlIGxpc3Qg Ym91bmRhcnkgc3R1ZmYsIHdoaWNoIGxvb2tzIE9LIC0tPg0KDQo8L2dyYW1tYXI+DQoNCi0tTWFy dGluDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZWNyaXQtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBP ZiBUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAtIEZJL0VzcG9vKQ0KPiBTZW50OiBUdWVzZGF5LCAx OSBKYW51YXJ5IDIwMTAgMTE6MjIgUE0NCj4gVG86IGVjcml0QGlldGYub3JnDQo+IFN1YmplY3Q6 IFtFY3JpdF0gV0dMQyBmb3IgZHJhZnQtaWV0Zi1lY3JpdC1sb3N0LXNlcnZpY2VsaXN0Ym91bmRh cnktDQo+IDAxLnR4dA0KPiANCj4gRm9sa3MsDQo+IA0KPiBLYXJsIEhlaW56IGluZGljYXRlZCB0 aGF0IHRoZSBjdXJyZW50IHZlcnNpb24gb2YgdGhlDQo+IFNlcnZpY2VMaXN0Qm91bmRhcnkNCj4g ZHJhZnQgaXMgcmVhZHkgZm9yIGEgV0dMQy4gSGVyZSBpcyB0aGUgbGF0ZXN0IGRyYWZ0Og0KPiBo dHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtZWNyaXQtbG9zdC1zZXJ2aWNlbGlzdGJv dW5kYXJ5LTAxLnR4dA0KPiANCj4gU28sIHBsZWFzZSwgaGF2ZSBhIGxvb2sgYXQgdGhpcyB2ZXJz aW9uIGFuZCBwcm92aWRlIHlvdXIgZmVlZGJhY2suDQo+IA0KPiBUaGlzIFdHTEMgd2lsbCBlbmQg b24gdGhlIDJuZCBGZWIuIDIwMTAuDQo+IA0KPiBDaWFvDQo+IEhhbm5lcyAmIE1hcmMNCg== From apenniston@geo-comm.com Thu Jan 21 07:03:01 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB1993A697E for ; Thu, 21 Jan 2010 07:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.993 X-Spam-Level: X-Spam-Status: No, score=0.993 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_PENIS1=3.592] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-FD3-mMum73 for ; Thu, 21 Jan 2010 07:03:00 -0800 (PST) Received: from mail.geo-comm.com (geo-comm.com [66.173.42.242]) by core3.amsl.com (Postfix) with ESMTP id 128B03A6A0F for ; Thu, 21 Jan 2010 07:02:59 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jan 2010 09:05:36 -0600 Message-ID: <909A20ADCD98AD4FB9984A87063A560503A7AAF1@exchange.geo-comm.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LoST Caching Question Thread-Index: AcqaqzAF5zk4tVM6RyyEP5gg0AKGAA== From: "Avery Penniston" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , X-ST-MF-Message-Resent: 1/21/2010 09:05 Subject: [Ecrit] LoST Caching Question 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: , X-List-Received-Date: Thu, 21 Jan 2010 15:03:01 -0000 I had a question regarding cached mappings in LoST that perhaps someone here can enlighten me. With regards to the request location, a LoST server that has a cached mapping will return that mapping if either: 1.) The request 'location' element exactly matches the cached mapping's original request 'location'. OR 2.) The request 'location' element intersects with the cached mapping's service boundary. I'm trying to understand whether it was intended to use literal text comparison of the request location to the original request location, or whether caching is supposed to try and match the request location with the cached mapping's service boundary and shouldn't care about the original request that generated the cached mapping. Avery Penniston - Software Developer GeoComm Inc. 601 W. Saint Germain St., Saint Cloud, MN 56301 Office: 320.240.0040 Fax: 320.240.2389 Toll Free: 888.436.2666 click here to visit www.geo-comm.com From mlinsner@cisco.com Mon Jan 25 13:20:35 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94A7F3A68E1 for ; Mon, 25 Jan 2010 13:20:35 -0800 (PST) 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 4ybs4ysCx098 for ; Mon, 25 Jan 2010 13:20:34 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 45A0B3A68DC for ; Mon, 25 Jan 2010 13:20:34 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAEaaXUuQ/uCWe2dsb2JhbACcCgEBFiQGJ6dzli6EOQQ X-IronPort-AV: E=Sophos;i="4.49,342,1262563200"; d="scan'208";a="2764988" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 25 Jan 2010 20:50:48 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0PLKeM8000161 for ; Mon, 25 Jan 2010 21:20:40 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 22:20:40 +0100 Received: from [10.116.195.117] ([10.116.195.117]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 22:20:39 +0100 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 25 Jan 2010 16:20:35 -0500 From: Marc Linsner To: "ecrit@ietf.org" Message-ID: Thread-Topic: ECRIT Interim Virtual Meeting Thread-Index: AcqeBDuSl3HttD9/YEy5XhCLYLzAuw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Jan 2010 21:20:39.0727 (UTC) FILETIME=[3E63DBF0:01CA9E04] Subject: [Ecrit] ECRIT Interim Virtual Meeting 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: , X-List-Received-Date: Mon, 25 Jan 2010 21:20:35 -0000 We will have an ECRIT Interim Virtual Meeting on Thursday Feb. 11 8AM-10AM EST (New York). The agenda and dial-in details will follow shortly. Thanks, -Marc, Hannes, Roger- From Martin.Thomson@andrew.com Tue Jan 26 20:48:20 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045143A6881 for ; Tue, 26 Jan 2010 20:48:20 -0800 (PST) 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 TC2zNyB4LGrx for ; Tue, 26 Jan 2010 20:48:19 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 35CB23A676A for ; Tue, 26 Jan 2010 20:48:19 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:33246 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S9171363Ab0A0Esb (ORCPT ); Tue, 26 Jan 2010 22:48:31 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 26 Jan 2010 22:48:31 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 27 Jan 2010 12:48:27 +0800 From: "Thomson, Martin" To: "ecrit@ietf.org" Date: Wed, 27 Jan 2010 12:49:30 +0800 Thread-Topic: Civic boundary draft Thread-Index: AcqfDBzzwJHTaMAKSX200qZWS6CCUw== Message-ID: <8B0A9FCBB9832F43971E38010638454F032E4AA4BD@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: [Ecrit] Civic boundary draft 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: , X-List-Received-Date: Wed, 27 Jan 2010 04:48:20 -0000 VGhpcyBkcmFmdCBkZXNjcmliZXMgd2hhdCBhIGJvdW5kYXJ5IG1lYW5zIGZvciBjaXZpYyBhZGRy ZXNzZXM6DQoNCiAgPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRob21zb24tZWNy aXQtY2l2aWMtYm91bmRhcnktMDA+DQoNCkkndmUgc2FpZCBpbiB0aGUgcGFzdCB0aGF0IHRoZSBk ZWZpbml0aW9uIG9mIHNlcnZpY2UgYm91bmRhcmllcyBmb3IgY2l2aWMgYWRkcmVzc2VzIGhhcyBi ZWVuIGluYWRlcXVhdGUgaW4gYm90aCBMb1NUIGFuZCB0aGUgcm91Z2gtbG9jIHdvcmsuDQoNClRo aXMgZHJhZnQgc2Vla3MgdG8gYWRkcmVzcyB0aGF0IGRlZmljaWVuY3kuICBUaGVyZSdzIGEgc2lt cGxlIGFsZ29yaXRobSB0aGF0IGNhbiBiZSB1c2VkIHRvIHRlc3Qgd2hldGhlciBvbmUgY2l2aWMg YWRkcmVzcyBpcyAid2l0aGluIiBhbm90aGVyLiAgVGhlcmUncyBhbHNvIHNvbWUgZGlzY3Vzc2lv biBvbiB0aGUgc2hvcnRjb21pbmdzIG9mIHN1Y2ggc2ltcGxlIHRlc3RzLCBhbmQgc29tZSBhZGRy ZXNzLSBhbmQgYm9yZGVyLWNvbWJpbmluZyBhbGdvcml0aG1zLg0KDQotLU1hcnRpbg0K From rbarnes@bbn.com Wed Jan 27 21:05:42 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EADAF3A69BD for ; Wed, 27 Jan 2010 21:05:42 -0800 (PST) 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 NwGJnTVjq9r5 for ; Wed, 27 Jan 2010 21:05:41 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id BAFEF3A698D for ; Wed, 27 Jan 2010 21:05:41 -0800 (PST) Received: from [128.89.254.82] (helo=[192.168.1.45]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NaMZp-0000S3-BE; Thu, 28 Jan 2010 00:05:58 -0500 Message-Id: <31620B80-EF99-4917-9F84-AE058B47EE71@bbn.com> From: "Richard L. Barnes" To: "Thomson, Martin" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F032E4A9A88@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 28 Jan 2010 00:05:55 -0500 References: <3D3C75174CB95F42AD6BCC56E5555B45021310CE@FIESEXC015.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F032E4A9A88@SISPE7MB1.commscope.com> X-Mailer: Apple Mail (2.936) Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC for draft-ietf-ecrit-lost-servicelistboundary-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: , X-List-Received-Date: Thu, 28 Jan 2010 05:05:43 -0000 I generally agree with Martin's comments regarding changes to the XML structure, especially having different elements for requesting and returning service list boundaries. I would also like to see a little more explanation in the Security Considerations, e.g.: " This document extends the LoST protocol [RFC5222] to allow it to carry service list boundaries (and requests for them). While this information cannot be directly derived from information in the current protocol, it is generally considered to have the same level of sensitivity -- namely, it is generally public information -- and thus the same access control and confidentiality requirements as the base LoST protocol. As a result, the security measures incorporated in the base LoST specification provide sufficient protection for LoST messages that use the service list boundary extension. " Other than that, I think this document is ready to go. --Richard On Jan 20, 2010, at 6:52 PM, Thomson, Martin wrote: > This document needs a little more attention to the XML, particularly > the RelaxNG schema, which I believe has some errors. The text is > clear and readable and the examples convey the intent well, but > accurate schema is an important part of these specifications. > > I see no reason for the document to stay in the WG once this problem > is resolved. > > Section 3 (general): > Is it intentional to use the same elements for the request and > response - they have dramatically different content models. While > possible, this can be confusing, not to mention inconvenient for > schema design. Perhaps the request could be identified differently. > > Section 3.1: > - s/ist/is/ > - I assume that the example civic address boundary is in English? > xml:lang="en" > > > Section 5.1: > My RelaxNG-fu is not as good as my XML Schema-fu, especially since > I prefer the compact syntax, but I think that this isn't right. > Unexplained ellipses are a dead giveaway. > > I would have expected something like what I've sketched out below, > with the note that the entire section isn't really needed > (though this changes where the elements are included - the draft > tacks them on the end, as is natural, but the actual extension point > is above the locationUsed in the response). > > I'll note also that the start element also needs to be redefined. > It's a real nuisance that LoST didn't make this easy by defining a > start-group, or by adding notLost to the default start group. Oh > well. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > value > reference > > > > > > > > > > > > > > > > > > > > > > > > > --Martin > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf >> Of Tschofenig, Hannes (NSN - FI/Espoo) >> Sent: Tuesday, 19 January 2010 11:22 PM >> To: ecrit@ietf.org >> Subject: [Ecrit] WGLC for draft-ietf-ecrit-lost-servicelistboundary- >> 01.txt >> >> Folks, >> >> Karl Heinz indicated that the current version of the >> ServiceListBoundary >> draft is ready for a WGLC. Here is the latest draft: >> http://www.ietf.org/id/draft-ietf-ecrit-lost-servicelistboundary-01.txt >> >> So, please, have a look at this version and provide your feedback. >> >> This WGLC will end on the 2nd Feb. 2010. >> >> Ciao >> Hannes & Marc > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From mlinsner@cisco.com Thu Jan 28 12:16:13 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5B4C3A68FC for ; Thu, 28 Jan 2010 12:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wBSzcVOboC1 for ; Thu, 28 Jan 2010 12:16:12 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 891B13A68F4 for ; Thu, 28 Jan 2010 12:16:12 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAE9/YUurR7Ht/2dsb2JhbADCFIl1CY01AoIzFYFyBA X-IronPort-AV: E=Sophos;i="4.49,362,1262563200"; d="scan'208";a="293427850" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 28 Jan 2010 20:16:31 +0000 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.14.3) with ESMTP id o0SKGVXH021952; Thu, 28 Jan 2010 20:16:31 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.3959); Thu, 28 Jan 2010 12:16:31 -0800 Received: from [10.13.13.46] ([10.82.254.16]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 12:16:30 -0800 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 28 Jan 2010 15:16:26 -0500 From: Marc Linsner To: Message-ID: Thread-Topic: Upcoming ES Conference Call, Friday 2 pm PST Thread-Index: Acqf73tgQFPVOAR3R0uF8ZTaLZkXYwAQo7xwAAkulME= In-Reply-To: <18B307BFDE5098438B0BF42A4E508FB50A3B2A48@xmb-sjc-228.amer.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Jan 2010 20:16:31.0249 (UTC) FILETIME=[C7C1F810:01CAA056] Cc: ecsg-802-emergencyservices@ieee.org, ecrit@ietf.org Subject: Re: [Ecrit] Upcoming ES Conference Call, Friday 2 pm PST 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: , X-List-Received-Date: Thu, 28 Jan 2010 20:16:13 -0000 Geoff, Unfortunately, I will not be able to make the conference call below. I did however quickly peruse your documents at the given URL. I will take the time to review them in depth later, but my reaction at this point is that you have not correctly captured the ECRIT Requirements for 802. A few glaring points: - ECRIT does not have a requirement for support of unauthenticated access. - ECRIT does not have a requirement for emergency calls given 'priority in the 802 network' - In the context of 802, I'm not sure what is meant by "Callback is currently a problem" - I'm not sure what is meant by "Provide better location than just the router" I will review the documents in more depth in the upcoming days and provide more input. Please feel free to discuss your ideas within the ECRIT list, and more importantly, please review the ECRIT WG documents. There is an important distinction between WG documents and individuals submissions. So feel free to ask questions regarding any document you read with 'ECRIT' in the title. Thanks, -Marc Linsner- IETF ECRIT Co-chair -----Original Message----- From: ecsg-802-emergencyservices@ieee.org [mailto:ecsg-802-emergencyservices@ieee.org] On Behalf Of Geoff Thompson Sent: Wednesday, January 27, 2010 11:56 PM To: ecsg-802-emergencyservices@LISTSERV.IEEE.ORG Subject: Upcoming ES Conference Call, Friday 2 pm PST Colleagues- At our interim meeting in La Jolla we completed work on our PAR & 5 Criteria and approved them for distribution to the 802 EC in time to be considered at the March Plenary That material may be found at: https://mentor.ieee.org/802-sg-emergency-services/documents as 2010 Document # 9 We also did a fair amount of work preparing material for the Tutorial that we are supposed to give in March and arranged a time slot for an initial conference call to do further work on the tutorial material. That call will be held: Date: Friday, January 29, 2010 Time: 2:00 PM PST Phone: 1 (218) 862-6420 Code: 893-0211 Agenda - Quick review of actions since the interim - Further work on Tutorial - Plan for future conference calls I look forward to your participation on the call. Best regards, Geoff Geoffrey O. Thompson Chair, 802 Emergency Services EC Study Group Member Emeritus, 802 Executive Committee GraCaSI Standards Advisory Services +1.650.938.2582 +1.540.227.0059 (Google Voice) <= Best bet ------ End of Forwarded Message From bernard_aboba@hotmail.com Thu Jan 28 23:22:36 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2526F3A6942 for ; Thu, 28 Jan 2010 23:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 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 gu2N+GUmRJam for ; Thu, 28 Jan 2010 23:22:34 -0800 (PST) Received: from blu0-omc1-s18.blu0.hotmail.com (blu0-omc1-s18.blu0.hotmail.com [65.55.116.29]) by core3.amsl.com (Postfix) with ESMTP id 64B963A6912 for ; Thu, 28 Jan 2010 23:22:34 -0800 (PST) Received: from BLU137-DS2 ([65.55.116.9]) by blu0-omc1-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 23:22:55 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Marc Linsner'" , References: <18B307BFDE5098438B0BF42A4E508FB50A3B2A48@xmb-sjc-228.amer.cisco.com> In-Reply-To: Date: Thu, 28 Jan 2010 23:23:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqf73tgQFPVOAR3R0uF8ZTaLZkXYwAQo7xwAAkulMEAFf2K4A== Content-Language: en-us X-OriginalArrivalTime: 29 Jan 2010 07:22:55.0615 (UTC) FILETIME=[E04C08F0:01CAA0B3] Cc: ecsg-802-emergencyservices@ieee.org, ecrit@ietf.org Subject: Re: [Ecrit] Upcoming ES Conference Call, Friday 2 pm PST 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: , X-List-Received-Date: Fri, 29 Jan 2010 07:22:36 -0000 Some comments on the requirements document: https://mentor.ieee.org/802-sg-emergency-services/dcn/10/sg-emergency-servic es-10-0018-00-ESSG-presentation-to-802-1-referenced-reqts.pdf 1. It is possible to track endpoint location in IEEE 802 networks using existing MIBs and protocols defined in IEEE 802 documents. Therefore before creating yet another approach, it would be useful to understand how what is being proposed would be different (and presumably better) than what already exists. SNMP approaches include the LLDP-MED MIB (which provides endpoint location information within an SNMP Trap, which is more convenient and less prone to fragmentation than polling), as well as approaches utilizing combinations of the Bridge MIB (RFC 4188, now owned by IEEE 802.1) and the IP MIB (RFC 4293). Another way of obtaining this information is via RADIUS (described in IEEE 802.1X-2004 and RFC 3580) which can be used both in authenticated (IEEE 802.1X) and non-authenticating modes (via "Call Check"). 2. IEEE 802.1 recently completed IEEE 802.1X-REV, which among other things, enables simultaneous support for authenticated and non-authenticated access. As a result, it's not clear to me that this represents a gap. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Thursday, January 28, 2010 12:16 PM To: thompson@ieee.org Cc: ecsg-802-emergencyservices@ieee.org; ecrit@ietf.org Subject: Re: [Ecrit] Upcoming ES Conference Call, Friday 2 pm PST Geoff, Unfortunately, I will not be able to make the conference call below. I did however quickly peruse your documents at the given URL. I will take the time to review them in depth later, but my reaction at this point is that you have not correctly captured the ECRIT Requirements for 802. A few glaring points: - ECRIT does not have a requirement for support of unauthenticated access. - ECRIT does not have a requirement for emergency calls given 'priority in the 802 network' - In the context of 802, I'm not sure what is meant by "Callback is currently a problem" - I'm not sure what is meant by "Provide better location than just the router" I will review the documents in more depth in the upcoming days and provide more input. Please feel free to discuss your ideas within the ECRIT list, and more importantly, please review the ECRIT WG documents. There is an important distinction between WG documents and individuals submissions. So feel free to ask questions regarding any document you read with 'ECRIT' in the title. Thanks, -Marc Linsner- IETF ECRIT Co-chair -----Original Message----- From: ecsg-802-emergencyservices@ieee.org [mailto:ecsg-802-emergencyservices@ieee.org] On Behalf Of Geoff Thompson Sent: Wednesday, January 27, 2010 11:56 PM To: ecsg-802-emergencyservices@LISTSERV.IEEE.ORG Subject: Upcoming ES Conference Call, Friday 2 pm PST Colleagues- At our interim meeting in La Jolla we completed work on our PAR & 5 Criteria and approved them for distribution to the 802 EC in time to be considered at the March Plenary That material may be found at: https://mentor.ieee.org/802-sg-emergency-services/documents as 2010 Document # 9 We also did a fair amount of work preparing material for the Tutorial that we are supposed to give in March and arranged a time slot for an initial conference call to do further work on the tutorial material. That call will be held: Date: Friday, January 29, 2010 Time: 2:00 PM PST Phone: 1 (218) 862-6420 Code: 893-0211 Agenda - Quick review of actions since the interim - Further work on Tutorial - Plan for future conference calls I look forward to your participation on the call. Best regards, Geoff Geoffrey O. Thompson Chair, 802 Emergency Services EC Study Group Member Emeritus, 802 Executive Committee GraCaSI Standards Advisory Services +1.650.938.2582 +1.540.227.0059 (Google Voice) <= Best bet ------ End of Forwarded Message _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit