From root@core3.amsl.com Thu Jul 9 08:15:01 2009 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9018128C237; Thu, 9 Jul 2009 08:15: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: <20090709151501.9018128C237@core3.amsl.com> Date: Thu, 9 Jul 2009 08:15:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-12.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, 09 Jul 2009 15: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 : Best Current Practice for Communications Services in support of Emergency Calling Author(s) : B. Rosen, J. Polk Filename : draft-ietf-ecrit-phonebcp-12.txt Pages : 45 Date : 2009-07-09 The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-12.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-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-09080016.I-D@ietf.org> --NextPart-- From br@brianrosen.net Thu Jul 9 08:21:54 2009 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 8CAB03A6C1A for ; Thu, 9 Jul 2009 08:21:54 -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 m+xl-gsLFzh5 for ; Thu, 9 Jul 2009 08:21:53 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id C15A53A6CE5 for ; Thu, 9 Jul 2009 08:21:53 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MOvRp-0007Kl-Ts for ecrit@ietf.org; Thu, 09 Jul 2009 10:22:13 -0500 From: "Brian Rosen" To: "'ecrit'" Date: Thu, 9 Jul 2009 11:22:13 -0400 Message-ID: <002201ca00a9$0d8f2b40$28ad81c0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoAqBiOeqm8mg3BSgWMjdmXiTA/YQAAJ+5g Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: [Ecrit] FW: I-D Action:draft-ietf-ecrit-phonebcp-12.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, 09 Jul 2009 15:21:54 -0000 This version replaces ED-6, which requires devices to have a configurable home country code, deleted by mistake, and noticed by Karl Heinz Wolf. It does not have the applicability statement. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, July 09, 2009 11:15 AM To: i-d-announce@ietf.org Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-12.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Best Current Practice for Communications Services in support of Emergency Calling Author(s) : B. Rosen, J. Polk Filename : draft-ietf-ecrit-phonebcp-12.txt Pages : 45 Date : 2009-07-09 The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-12.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. From Hannes.Tschofenig@gmx.net Fri Jul 10 12:27:20 2009 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 F3A3F28C2AF for ; Fri, 10 Jul 2009 12:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.073 X-Spam-Level: X-Spam-Status: No, score=-1.073 tagged_above=-999 required=5 tests=[AWL=-0.774, BAYES_00=-2.599, MANGLED_ONLINE=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHGnHyuUKriT for ; Fri, 10 Jul 2009 12:27:18 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3713E28C3BE for ; Fri, 10 Jul 2009 12:27:15 -0700 (PDT) Received: (qmail invoked by alias); 10 Jul 2009 19:27:40 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp069) with SMTP; 10 Jul 2009 21:27:40 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+13EcR+6S13Gk3wLkdqV2PXXbFCrUUE7KV7hwFrk Zo7aOXHiN8aLgR From: "Hannes Tschofenig" To: "'Ben Campbell'" References: <00e801c9d31c$9df95d00$0301a8c0@nsnintra.net> Date: Fri, 10 Jul 2009 22:29:57 +0300 Message-ID: <16c901ca0194$cfc7dd10$501ca20a@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: <00e801c9d31c$9df95d00$0301a8c0@nsnintra.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcnPYXNNttuRG1Q7QPeA5YK3H2BbnwDuyEnQC5EKqWA= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.46 Cc: 'ECRIT' Subject: Re: [Ecrit] FW: Gen-ART LC review ofdraft-ietf-ecrit-location-hiding-req-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: Fri, 10 Jul 2009 19:27:20 -0000 Hi Ben, Thanks for your review. Please find some comments below: >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Hannes Tschofenig >Sent: 12 May, 2009 19:14 >To: 'ECRIT' >Subject: [Ecrit] FW: Gen-ART LC review >ofdraft-ietf-ecrit-location-hiding-req-01 > >FYI > >>-----Original Message----- >>From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On >Behalf Of >>Ben Campbell >>Sent: 08 May, 2009 01:16 >>To: hgs+ecrit@cs.columbia.edu; Laura.Liess@t-systems.com; >>Hannes.Tschofenig@gmx.net; barbara.stark@att.com; >>andres.kytt@skype.net; General Area Review Team >>Cc: Cullen Jennings; marc.linsner@cisco.com; ietf@ietf.org >>Subject: Gen-ART LC review of draft-ietf-ecrit-location-hiding-req-01 >> >>I have been selected as the General Area Review Team >(Gen-ART) reviewer >>for this draft (for background on Gen-ART, please see >>http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >> >>Please resolve these comments along with any other Last Call comments >>you may receive. >> >>Document: draft-ietf-ecrit-location-hiding-req-01 >>Reviewer: Ben Campbell >>Review Date: 20090507 >>IETF LC End Date: 20090511 >>IESG Telechat date: (if known) >> >>Summary: >> >>This document is almost ready for publication as an informational RFC. >>There are some minor clarity issues where the reader is left to infer >>some things that could be more explicit. >> >>Major issues: >> >>None >> >> >> >>Minor issues: >> >>-- 1.1, last paragraph: >> >>Can you expand on how withholding information information needed for >>call routing concretely differs from withholding information from >>emergency personnel? I assume there is more to this than the >intent of >>the ISP. Also, by saying an ISP is "not interested", I think >the point >>is to say that they have legal obligations to disclose to emergency >>personnel, regardless of any interest otherwise, right? I updated the text. To answer your question: the regulator is the problem. They often do not clearly describe how the responsibilities are shared. Not providing location info to the PSAP is typically a problem from a law point of view. >> >>-- 1.2, first paragraph: >> >>I think this leaves out what I assume to be the actual problem >>statement, which is we need a way that an ISP/IAP can hide location >>info from the user agent of the VSP in such a fashion that it >is still >>available for PSAP routing, correct? I can infer that pretty easily, >>but I don't see where it is explicitly stated in one place. >> >>Is there a case where an ISP is simply unable to provide location >>information? I assume that would be out of scope for this >document, but >>it should be stated as such. I updated the text to make it more clear. Technically, there are challenges but none that cannot be addressed. Needless to say that the additional functionality costs money. The costs vary when it comes to the accuracy requirements. This document does not talk about accuracy requirements. >> >> >> >>-- 1.3, fourth paragraph: >> >>This paragraph could be more clear--how does the PSAP having >>credentials meet a requirement to _hide_ information? I infer the >>assumption is that the caller does _not_ have the necessary >>credentials. If so, it would be better to state it explicitly I extended the paragraph to make the credential story more concrete. >> >>-- Fifth paragraph: >> >>is compatibility with LoST a requirement? We use LoST as a mechanism to provide location based routing. I changed the wording of the text. >> >>-- Req-B >> >>Is it appropriate for this document to put requirements on the ISP/ >>IAP? Or do you mean to say they MUST be _able_ to support this, while >>hiding information location from the VSP and/or UA? A lot of the emergency services work relies on assumptions of what various parties provide or do not provide. For this specific requirement the group thought it would be important that the ISP/IAP allows either the end point or the VSP to do some form of emergency call routing. >> >>-- Req-C >> >>I don't really understand what is being said here. Is the >point to say >>that they must be able to validate that the URI identifies a "bona >>fide" emergency service contact, and that a call to that URI actually >>routes to the right place? How does this interact with the later >>requirement that the entities need not be SIP aware? >> Thanks for raising this issue. This requirement actually relates to a security threat we identified quite early with the work in the ECRIT group. See Section 5.1 of http://www.ietf.org/rfc/rfc5069.txt. >>-- Req-D >> >>this is stated as a requirement on the ISP rather than a statement >>about the solution. I _think_ you are saying there is a >requirement to >>be _able_ to provide location info to the PSAP while withholding it >>from the caller. Is that correct?. >>Also how does "by value or by reference" interact with the previous >>statement concerning LoST requiring LbyV? I changed the wording based on your suggestion. >> >>-- Req-5 >> >>How does the requirement that the ISP/IAP not need to know >SIP interact >>with the statement in Req-D that the ISP must be able to >determine if a >>call is being routed to a bona-fide location service? >>Also, does Req-5 imply a requirement to work with non-SIP VoIP >>services? I changed the working to make it more clear: " The solution SHOULD work without the ISP/IAP having to support SIP and without the need to utilize SIP between the endpoint and the VSP. " >> >>-- Req-6 >> >>What does it mean for a PSAP boundary to have holes? I added text and an informative reference to http://www.ietf.org/internet-drafts/draft-ietf-ecrit-specifying-holes-01.txt . >> >>-- Req 12: >> >>"Minimal impact" is vague--can you add clarifying text to make this >>more concrete? During the discussions we noticed that some solutions would require procedures that are totally different compared to the normal handling of emergency calls when no location hiding is performed. I added some text. >> >>-- Req 15: >> >>Is that really a requirement, or just an observation of fact? >> Changed the wording. >>-- Security Considerations: >> >>I'm a little skeptical of this statement that this does not raise >>additional considerations. For example, would you consider >that a human >>might be endangered because an ISP wanted to reserve location >>information as a "for pay" service a security consideration, >in that it >>requires the solution to be more fail-safe than other >protocols? On the >>other hand, is the need to keep the UA from inferring >location when an >>ISP wants to hide it a security consideration? I at least did not know what to write into the security consideration section. >> >>Nits/editorial comments: >> >>-- Abstract, paragraph 2: >> >>It's not clear to me that the document described >architectural impacts. >>It refers to architecture, but I don't see explicit statements about >>how the architecture breaks if the ISP is not willing to disclose. >> Fixed. >>-- 1.1, list item "3." >> >>Please expand VSP on first use. >> Fixed. >>-- Req-A: >> >>I don't think the requirement is to be able to withold location from >>"any entity it wishes", since that would include the PSAP, etc. Fixed. >> >>-- Req-2: "jurisdiction of the PSAP" >> >>Geographical jurisdiction? >> Fixed. >>-- Req-10: The solution MUST allow the end host to determine PSAP/ >>ESRP URLs prior to the call, for all emergency services. >> >>Who is the "end host"? The end host is the end point, such as a PC, laptop or a mobile phone. >> >>-- 3.3, first bullet: >> >>Is it appropriate to have "MUST"s in a section on "desirable >>properties"? Hmmm. Not sure. >> >>-- Third bullet: >> >>That's an implementation detail. I think you mean to say something to >>the effect of the presence of NATs SHOULD not break the mechanism. Fixed. Thanks again for your review comments. They helped to improve the quality of the document. Here is the updated document: http://www.tschofenig.priv.at/svn/draft-schulzrinne-ecrit-location-hiding-re quirements/draft-ietf-ecrit-location-hiding-req-02.txt Ciao Hannes >> >> >> >> >> >> >>-- idnits reports the following (which I include without prejudice): >> >>idnits 2.11.11 >> >>tmp/draft-ietf-ecrit-location-hiding-req-01.txt: >> >> Checking boilerplate required by RFC 5378 and the IETF Trust (see >> http://trustee.ietf.org/license-info): >> >>--------------------------------------------------------------- >>------------- >> >> ** It looks like you're using RFC 3978 boilerplate. You >>should update this >> to the boilerplate described in the IETF Trust License >>Policy document >> (see http://trustee.ietf.org/license-info), which is >>required from >> December 16, 2008. Version 1.34 of xml2rfc can be used >>to produce >> documents with boilerplate according to the mentioned >>Trust License >> Policy document. >> >> -- Found old boilerplate from RFC 3978 Section 5.1 on line 22. >> >> -- Found old boilerplate from RFC 3978 Section 5.5 updated by RFC >>4748 on >> line 377. >> >> -- Found old boilerplate from RFC 3979 Section 5 paragraph >>1 on line 388. >> >> -- Found old boilerplate from RFC 3979 Section 5 paragraph >>2 on line 395. >> >> -- Found old boilerplate from RFC 3979 Section 5 paragraph >>3 on line 401. >> >>_______________________________________________ >>Ietf mailing list >>Ietf@ietf.org >>https://www.ietf.org/mailman/listinfo/ietf >> > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > From root@core3.amsl.com Mon Jul 13 10:15:01 2009 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DD71F28C55F; Mon, 13 Jul 2009 10:15: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: <20090713171501.DD71F28C55F@core3.amsl.com> Date: Mon, 13 Jul 2009 10:15:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-location-hiding-req-02.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: Mon, 13 Jul 2009 17:15:02 -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 : Location Hiding: Problem Statement and Requirements Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-ecrit-location-hiding-req-02.txt Pages : 11 Date : 2009-07-13 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 or VoIP service providers 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 provides a problem statement and lists requirements 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-location-hiding-req-02.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-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13100119.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 13 10:30:04 2009 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 74E9E28C55D; Mon, 13 Jul 2009 10:30: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: <20090713173003.74E9E28C55D@core3.amsl.com> Date: Mon, 13 Jul 2009 10:30:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-sync-05.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 17:30:04 -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 : Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements Author(s) : H. Schulzrinne, H. Tschofenig Filename : draft-ietf-ecrit-lost-sync-05.txt Pages : 24 Date : 2009-07-13 The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The main data structure, the element, used for encapsulating information about service boundaries is defined in the LoST protocol specification and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism can be used for bulk exchange of elements between two entities. As such, this document can also be used without the LoST protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-lost-sync-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13101541.I-D@ietf.org> --NextPart-- From dromasca@avaya.com Tue Jul 14 03:33:05 2009 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 0FE533A6896; Tue, 14 Jul 2009 03:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 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 qojHRwjqXWdX; Tue, 14 Jul 2009 03:33:04 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id E9C173A67E5; Tue, 14 Jul 2009 03:33:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,396,1243828800"; d="scan'208";a="176852647" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Jul 2009 06:32:30 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Jul 2009 06:32:29 -0400 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, 14 Jul 2009 12:32:27 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Project Approval Request (PAR) for IEEE 802.21.1 on Emergency Services thread-index: AcoEbmIdb5aNUSglSfyLKikN8iKBHg== From: "Romascanu, Dan (Dan)" To: Cc: Donald Eastlake , IAB IAB , The IESG Subject: [Ecrit] New Project Approval Request (PAR) for IEEE 802.21.1 on Emergency Services X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 10:33:05 -0000 FYI, the IEEE 802 Plenary meeting which happens this week in San Francisco has a PAR (equivalent with a WG charter) for approval for an Emergency Services project.=20 http://www.ieee802.org/PARs/2009-07/21-09-0027-06-00es-emergency-service s-par-and-5c.doc I think Donald attends the meeting, probably Bernard as well.=20 Dan From bernard_aboba@hotmail.com Tue Jul 14 10:01:01 2009 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 B495A3A6A07; Tue, 14 Jul 2009 10:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.035 X-Spam-Level: X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ID1A0n0KMAXJ; Tue, 14 Jul 2009 10:01:00 -0700 (PDT) Received: from blu0-omc2-s1.blu0.hotmail.com (blu0-omc2-s1.blu0.hotmail.com [65.55.111.76]) by core3.amsl.com (Postfix) with ESMTP id 6F5C73A685A; Tue, 14 Jul 2009 10:01:00 -0700 (PDT) Received: from BLU137-DS5 ([65.55.111.73]) by blu0-omc2-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 09:59:56 -0700 X-Originating-IP: [12.197.88.101] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Donald Eastlake'" , "'Romascanu, Dan \(Dan\)'" References: <1028365c0907140710p1fe2d0fas8a4b5ab9f3bff957@mail.gmail.com> In-Reply-To: <1028365c0907140710p1fe2d0fas8a4b5ab9f3bff957@mail.gmail.com> Date: Tue, 14 Jul 2009 09:59:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoEjNk7sGkbYdCqSfiskf/ki7mtawAF2J1w Content-Language: en-us X-OriginalArrivalTime: 14 Jul 2009 16:59:56.0413 (UTC) FILETIME=[83B252D0:01CA04A4] Cc: 'IAB IAB' , ecrit@ietf.org, 'The IESG' Subject: Re: [Ecrit] New Project Approval Request (PAR) for IEEE 802.21.1 on Emergency Services X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 17:01:01 -0000 I am also in San Francisco, in the IEEE 802.21 meeting. FWIW, Tony Jeffree (chair of IEEE 802.1) has recently sent in his PAR evaluation, which is Enclosed below. My sense is that the PAR could be headed for "rough waters" in the IEEE 802 EC. ==================================== -----Original Message----- From: IEEE 802.1 list HELP only [mailto:hdk-918.xb9n_m63sj@att.net] On Behalf Of Tony Jeffree Sent: Tuesday, July 14, 2009 7:52 AM To: STDS-802-1-L@LISTSERV.IEEE.ORG Subject: [802.1 - 6573] Emergency services PAR This list strips out HTML. For more format and size rules, see "Sending" at 802.1 list help: www.ieee802.org/1/email-pages/rvbkx609.html ----- Vivek - I have significant problems with this draft PAR, some of which cannot be fixed simply by changing the wording of the draft. Firstly, the PAR reads like a charter for the working group to boil the ocean. The problem that the PAR offers to solve is large, multi-faceted, complex, and will inevitably involve expertise across the breadth of 802 technologies, as well as expertise in the political and regulatory issues surrounding this area, and the ways in which they interact with the technical solutions. A PAR is a charter to write a single standard; given the scope of the problem, I don't believe that the solution is going to consist of a single document; neither do I believe that the set of documents that would eventually be needed will be possible to write within a single working group. So, in short, the scope of the project is way too broad, and is consequently unlikely to be achievable in any realistic timeframe. A starting point that might have some chance of success would be to develop an architecture for emergency services support across 802; a competently written architecture can (and should) inform the set of documents that are needed in order to address the technology issues, and how they relate to each other. However, that is not what this draft PAR proposes. Secondly, the subject matter of the PAR has no relationship to the current charter of the 802.21 WG. Simply changing the 802.21 charter to make it "fit" is not, in my view, the correct solution here; past experience during the development of the existing 802.21 standard gives me no confidence either in 802.21's will to develop truly cross-802 standards or its ability to do so. I believe that the answer to 802.1's charter issues is simple; if you are done doing work on the subject matter of your original standard, then it is time you did the right thing and closed down the WG, rather than starting unrelated work. If there are further topic areas that your members desire to work on, and that are not a good fit with your current charter, then the right thing to do is to create one or more EC study groups to look at those topics and determine, on an 802-wide basis, how they should be tackled. That way, we stand a better chance of getting participation in the process by interested parties across 802, and less chance of the activity becoming either wireline or wireless centric. Once each EC study group has done its job, the EC will get to determine where any work that is proposed should best be done, and whether there is a need to create a new WG to tackle it. So, I will oppose the approval of this PAR on Friday. I will also oppose any change to 802.21's charter beyond the subject matter of its existing standard and approved projects. I would, however, support the establishment of an EC study group to study what (if anything) 802 should do about emergency services, should anyone choose to propose forming one. Regards, Tony ==================================== -----Original Message----- From: Donald Eastlake [mailto:d3e3e3@gmail.com] Sent: Tuesday, July 14, 2009 7:11 AM To: Romascanu, Dan (Dan) Cc: ecrit@ietf.org; The IESG; IAB IAB; Bernard Aboba Subject: Re: New Project Approval Request (PAR) for IEEE 802.21.1 on Emergency Services Yes, I am in San Francisco at the 802 Plenary, although mostly tied up in 802.11 (Wi-Fi) chairing 802.11s (Mesh Networking), a position I've held for several years but from which I have resigned effective with the end of this week. And to the extent I'm not tied up in 802.11, I'll be in 802.1, particularly the 802.1 Interworking and DCB task forces... Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Jul 14, 2009 at 6:32 AM, Romascanu, Dan (Dan) wrote: > FYI, the IEEE 802 Plenary meeting which happens this week in San > Francisco has a PAR (equivalent with a WG charter) for approval for an > Emergency Services project. > > http://www.ieee802.org/PARs/2009-07/21-09-0027-06-00es-emergency-service > s-par-and-5c.doc > > I think Donald attends the meeting, probably Bernard as well. > > Dan > From rbarnes@bbn.com Tue Jul 14 13:52:25 2009 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 E62F63A699C for ; Tue, 14 Jul 2009 13:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNRL2YW+X4E4 for ; Tue, 14 Jul 2009 13:52:24 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 7DD1D3A67A5 for ; Tue, 14 Jul 2009 13:52:24 -0700 (PDT) Received: from ros-dhcp192-1-51-62.bbn.com ([192.1.51.62]) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1MQohd-000752-B5; Tue, 14 Jul 2009 16:34:17 -0400 Message-ID: <4A5CEBC9.90906@bbn.com> Date: Tue, 14 Jul 2009 16:34:17 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Bernard Aboba References: <1028365c0907140710p1fe2d0fas8a4b5ab9f3bff957@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Donald Eastlake' , ecrit@ietf.org Subject: Re: [Ecrit] New Project Approval Request (PAR) for IEEE 802.21.1 on Emergency Services X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 20:52:26 -0000 [Removed IAB, IESG] Thanks for bringing this up, Dan. I share many of Tony's concerns, especially under his first heading. The scope of the proposed project is very broad, and overlaps significantly with existing standards developed at other SDOs (notably ECRIT). I don't know enough about the IEEE organization to know whether the concerns about WG structure are valid, but if some organization is chartered with this work, they will need to coordinate very closely with the groups that have been working on this problem or a while. --Richard Bernard Aboba wrote: > I am also in San Francisco, in the IEEE 802.21 meeting. FWIW, Tony Jeffree > (chair of IEEE 802.1) has recently sent in his PAR evaluation, which is > Enclosed below. My sense is that the PAR could be headed for "rough > waters" in the IEEE 802 EC. > > ==================================== > > -----Original Message----- > From: IEEE 802.1 list HELP only [mailto:hdk-918.xb9n_m63sj@att.net] On > Behalf Of Tony Jeffree > Sent: Tuesday, July 14, 2009 7:52 AM > To: STDS-802-1-L@LISTSERV.IEEE.ORG > Subject: [802.1 - 6573] Emergency services PAR > > This list strips out HTML. For more format and size rules, see "Sending" at > 802.1 list help: www.ieee802.org/1/email-pages/rvbkx609.html > ----- > > Vivek - > > I have significant problems with this draft PAR, some of which cannot be > fixed simply by > changing the wording of the draft. > > Firstly, the PAR reads like a charter for the working group to boil the > ocean. The problem > that the PAR offers to solve is large, multi-faceted, complex, and will > inevitably involve > expertise across the breadth of 802 technologies, as well as expertise in > the political > and regulatory issues surrounding this area, and the ways in which they > interact with the > technical solutions. A PAR is a charter to write a single standard; given > the scope of the > problem, I don't believe that the solution is going to consist of a single > document; > neither do I believe that the set of documents that would eventually be > needed will be > possible to write within a single working group. So, in short, the scope of > the project is > way too broad, and is consequently unlikely to be achievable in any > realistic timeframe. A > starting point that might have some chance of success would be to develop an > architecture > for emergency services support across 802; a competently written > architecture can (and > should) inform the set of documents that are needed in order to address the > technology > issues, and how they relate to each other. However, that is not what this > draft PAR > proposes. > > Secondly, the subject matter of the PAR has no relationship to the current > charter of the > 802.21 WG. Simply changing the 802.21 charter to make it "fit" is not, in my > view, the > correct solution here; past experience during the development of the > existing 802.21 > standard gives me no confidence either in 802.21's will to develop truly > cross-802 > standards or its ability to do so. I believe that the answer to 802.1's > charter issues is > simple; if you are done doing work on the subject matter of your original > standard, then > it is time you did the right thing and closed down the WG, rather than > starting unrelated > work. If there are further topic areas that your members desire to work on, > and that are > not a good fit with your current charter, then the right thing to do is to > create one or > more EC study groups to look at those topics and determine, on an 802-wide > basis, how they > should be tackled. That way, we stand a better chance of getting > participation in the > process by interested parties across 802, and less chance of the activity > becoming either > wireline or wireless centric. Once each EC study group has done its job, the > EC will get > to determine where any work that is proposed should best be done, and > whether there is a > need to create a new WG to tackle it. > > So, I will oppose the approval of this PAR on Friday. I will also oppose any > change to > 802.21's charter beyond the subject matter of its existing standard and > approved projects. > I would, however, support the establishment of an EC study group to study > what (if > anything) 802 should do about emergency services, should anyone choose to > propose forming > one. > > Regards, > Tony > ==================================== > > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@gmail.com] > Sent: Tuesday, July 14, 2009 7:11 AM > To: Romascanu, Dan (Dan) > Cc: ecrit@ietf.org; The IESG; IAB IAB; Bernard Aboba > Subject: Re: New Project Approval Request (PAR) for IEEE 802.21.1 on > Emergency Services > > Yes, I am in San Francisco at the 802 Plenary, although mostly tied up > in 802.11 (Wi-Fi) chairing 802.11s (Mesh Networking), a position I've > held for several years but from which I have resigned effective with > the end of this week. And to the extent I'm not tied up in 802.11, > I'll be in 802.1, particularly the 802.1 Interworking and DCB task > forces... > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-634-2066 (home) > 155 Beaver Street > Milford, MA 01757 USA > d3e3e3@gmail.com > > > On Tue, Jul 14, 2009 at 6:32 AM, Romascanu, Dan (Dan) > wrote: >> FYI, the IEEE 802 Plenary meeting which happens this week in San >> Francisco has a PAR (equivalent with a WG charter) for approval for an >> Emergency Services project. >> >> http://www.ieee802.org/PARs/2009-07/21-09-0027-06-00es-emergency-service >> s-par-and-5c.doc >> >> I think Donald attends the meeting, probably Bernard as well. >> >> Dan >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From Hannes.Tschofenig@gmx.net Wed Jul 15 14:05:46 2009 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 A70C13A6BF8 for ; Wed, 15 Jul 2009 14:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[AWL=-0.818, BAYES_40=-0.185, 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 EGm63qckfRnC for ; Wed, 15 Jul 2009 14:05:45 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 68FBE3A6B76 for ; Wed, 15 Jul 2009 14:05:44 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2009 20:58:41 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp023) with SMTP; 15 Jul 2009 22:58:41 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19b2DVllENbrP105rofU0poeGnmStDnml3q9M7D0E xOGne8fXvASu4b From: "Hannes Tschofenig" To: "ECRIT" Date: Thu, 16 Jul 2009 00:01:01 +0300 Message-ID: <025d01ca058f$5c5f92b0$1116a20a@nsnintra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_025E_01CA05A8.81ACCAB0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 thread-index: AcoFj1uGf2quOMlAQ8SLHgZ+VgK+yg== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78,0.78 Subject: [Ecrit] Agenda (v1) 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, 15 Jul 2009 21:05:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_025E_01CA05A8.81ACCAB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, here is a first try for the agenda: http://www.ietf.org/proceedings/09jul/agenda/ecrit.txt Please take a look at it - you might find your name there. Ciao Hannes ------=_NextPart_000_025E_01CA05A8.81ACCAB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda (v1)

Hi all,

here is a first try for the = agenda:
http://www.ietf.org/proceedings/09jul/agenda/ecrit.txt

Please take a look at it - you = might find your name there.

Ciao
Hannes


------=_NextPart_000_025E_01CA05A8.81ACCAB0-- From bernard_aboba@hotmail.com Wed Jul 15 17:25:33 2009 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 DB0C23A6819 for ; Wed, 15 Jul 2009 17:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.04 X-Spam-Level: X-Spam-Status: No, score=-1.04 tagged_above=-999 required=5 tests=[AWL=-1.020, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lefEJUJgwf7Z for ; Wed, 15 Jul 2009 17:25:32 -0700 (PDT) Received: from blu0-omc4-s35.blu0.hotmail.com (blu0-omc4-s35.blu0.hotmail.com [65.55.111.174]) by core3.amsl.com (Postfix) with ESMTP id 7616728C17B for ; Wed, 15 Jul 2009 17:25:32 -0700 (PDT) Received: from BLU137-DS7 ([65.55.111.136]) by blu0-omc4-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 17:25:24 -0700 X-Originating-IP: [12.197.88.101] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Richard Barnes'" References: <1028365c0907140710p1fe2d0fas8a4b5ab9f3bff957@mail.gmail.com> <4A5CEBC9.90906@bbn.com> In-Reply-To: <4A5CEBC9.90906@bbn.com> Date: Thu, 16 Jul 2009 02:25:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcoEwnXMWhF1IQkURCO0mcCwV3kfswA6TF7Q Content-Language: en-us X-OriginalArrivalTime: 16 Jul 2009 00:25:24.0332 (UTC) FILETIME=[E930DAC0:01CA05AB] Cc: 'Donald Eastlake' , ecrit@ietf.org Subject: Re: [Ecrit] New Project Approval Request (PAR) for IEEE 802.21.1 on Emergency Services X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 00:25:34 -0000 After some discussion, it appears that the Emergency Services PAR proposal is once again being withdrawn, and replaced with a request to form an Executive Committee Study Group (ECSG). Such a study group, if approved, would take issue a Call for Interest within IEEE 802, and would be focused on developing a future PAR, most probably outside of IEEE 802.21. -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com] Sent: Tuesday, July 14, 2009 10:34 PM To: Bernard Aboba Cc: 'Donald Eastlake'; 'Romascanu, Dan (Dan)'; ecrit@ietf.org Subject: Re: [Ecrit] New Project Approval Request (PAR) for IEEE 802.21.1 on Emergency Services [Removed IAB, IESG] Thanks for bringing this up, Dan. I share many of Tony's concerns, especially under his first heading. The scope of the proposed project is very broad, and overlaps significantly with existing standards developed at other SDOs (notably ECRIT). I don't know enough about the IEEE organization to know whether the concerns about WG structure are valid, but if some organization is chartered with this work, they will need to coordinate very closely with the groups that have been working on this problem or a while. --Richard Bernard Aboba wrote: > I am also in San Francisco, in the IEEE 802.21 meeting. FWIW, Tony Jeffree > (chair of IEEE 802.1) has recently sent in his PAR evaluation, which is > Enclosed below. My sense is that the PAR could be headed for "rough > waters" in the IEEE 802 EC. > > ==================================== > > -----Original Message----- > From: IEEE 802.1 list HELP only [mailto:hdk-918.xb9n_m63sj@att.net] On > Behalf Of Tony Jeffree > Sent: Tuesday, July 14, 2009 7:52 AM > To: STDS-802-1-L@LISTSERV.IEEE.ORG > Subject: [802.1 - 6573] Emergency services PAR > > This list strips out HTML. For more format and size rules, see "Sending" at > 802.1 list help: www.ieee802.org/1/email-pages/rvbkx609.html > ----- > > Vivek - > > I have significant problems with this draft PAR, some of which cannot be > fixed simply by > changing the wording of the draft. > > Firstly, the PAR reads like a charter for the working group to boil the > ocean. The problem > that the PAR offers to solve is large, multi-faceted, complex, and will > inevitably involve > expertise across the breadth of 802 technologies, as well as expertise in > the political > and regulatory issues surrounding this area, and the ways in which they > interact with the > technical solutions. A PAR is a charter to write a single standard; given > the scope of the > problem, I don't believe that the solution is going to consist of a single > document; > neither do I believe that the set of documents that would eventually be > needed will be > possible to write within a single working group. So, in short, the scope of > the project is > way too broad, and is consequently unlikely to be achievable in any > realistic timeframe. A > starting point that might have some chance of success would be to develop an > architecture > for emergency services support across 802; a competently written > architecture can (and > should) inform the set of documents that are needed in order to address the > technology > issues, and how they relate to each other. However, that is not what this > draft PAR > proposes. > > Secondly, the subject matter of the PAR has no relationship to the current > charter of the > 802.21 WG. Simply changing the 802.21 charter to make it "fit" is not, in my > view, the > correct solution here; past experience during the development of the > existing 802.21 > standard gives me no confidence either in 802.21's will to develop truly > cross-802 > standards or its ability to do so. I believe that the answer to 802.1's > charter issues is > simple; if you are done doing work on the subject matter of your original > standard, then > it is time you did the right thing and closed down the WG, rather than > starting unrelated > work. If there are further topic areas that your members desire to work on, > and that are > not a good fit with your current charter, then the right thing to do is to > create one or > more EC study groups to look at those topics and determine, on an 802-wide > basis, how they > should be tackled. That way, we stand a better chance of getting > participation in the > process by interested parties across 802, and less chance of the activity > becoming either > wireline or wireless centric. Once each EC study group has done its job, the > EC will get > to determine where any work that is proposed should best be done, and > whether there is a > need to create a new WG to tackle it. > > So, I will oppose the approval of this PAR on Friday. I will also oppose any > change to > 802.21's charter beyond the subject matter of its existing standard and > approved projects. > I would, however, support the establishment of an EC study group to study > what (if > anything) 802 should do about emergency services, should anyone choose to > propose forming > one. > > Regards, > Tony > ==================================== > > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@gmail.com] > Sent: Tuesday, July 14, 2009 7:11 AM > To: Romascanu, Dan (Dan) > Cc: ecrit@ietf.org; The IESG; IAB IAB; Bernard Aboba > Subject: Re: New Project Approval Request (PAR) for IEEE 802.21.1 on > Emergency Services > > Yes, I am in San Francisco at the 802 Plenary, although mostly tied up > in 802.11 (Wi-Fi) chairing 802.11s (Mesh Networking), a position I've > held for several years but from which I have resigned effective with > the end of this week. And to the extent I'm not tied up in 802.11, > I'll be in 802.1, particularly the 802.1 Interworking and DCB task > forces... > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-634-2066 (home) > 155 Beaver Street > Milford, MA 01757 USA > d3e3e3@gmail.com > > > On Tue, Jul 14, 2009 at 6:32 AM, Romascanu, Dan (Dan) > wrote: >> FYI, the IEEE 802 Plenary meeting which happens this week in San >> Francisco has a PAR (equivalent with a WG charter) for approval for an >> Emergency Services project. >> >> http://www.ieee802.org/PARs/2009-07/21-09-0027-06-00es-emergency-service >> s-par-and-5c.doc >> >> I think Donald attends the meeting, probably Bernard as well. >> >> Dan >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From jmpolk@cisco.com Thu Jul 16 16:19:21 2009 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 BAE6028C10B for ; Thu, 16 Jul 2009 16:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.37 X-Spam-Level: X-Spam-Status: No, score=-6.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 ju6Nn-v0oWTS for ; Thu, 16 Jul 2009 16:19:20 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D4F523A6405 for ; Thu, 16 Jul 2009 16:19:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0IANVRX0qrR7PD/2dsb2JhbACIQ7AfiCORDgWEDQ X-IronPort-AV: E=Sophos;i="4.42,413,1243814400"; d="scan'208";a="215220119" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 16 Jul 2009 23:19:54 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6GNJrOp022916 for ; Thu, 16 Jul 2009 16:19:53 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6GNJrqM010257 for ; Thu, 16 Jul 2009 23:19:53 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 16:19:53 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.4.15]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 16:19:52 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 16 Jul 2009 18:19:51 -0500 To: "'ECRIT'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 16 Jul 2009 23:19:52.0853 (UTC) FILETIME=[EC428450:01CA066B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=530; t=1247786393; x=1248650393; 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:=20New=20ID=20creating=20Geocoding=20URN |Sender:=20; bh=QH2C3uiGXQThSop7oeYr0b/IwVrr9S7QQE7YmKTEQw4=; b=Eeuyunxw9fKoJKG2yomiezQuQpnP4ZWnsA8VYwp7jAu0zJ9cnF59CD3In9 nUdjZbkoIUdaJ1Bl7EoSEQPn+T8XFZBmje5X4r9yy2uSeqVbHYM7a9ZLHGdk HIxCZFocZY; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Ecrit] New ID creating Geocoding URN 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, 16 Jul 2009 23:19:21 -0000 ECRIT I have written a new ID creating URNs for Geocoding and Reverse-Geocoding using LoST. http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-geocoding-00.txt This draft is not in a preliminary state, and I hope to have a more complete version out by Stockholm. This is a fairly simple draft that merely creates the URNs, and specifies how LoST can be used to convert Geo to civic, and civic to Geo. I hope this idea will not become anything that's complicated. Comments are appreciated. James From ben@estacado.net Thu Jul 16 13:24:28 2009 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 619BB3A6DD2; Thu, 16 Jul 2009 13:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 2jTcHM4qkry3; Thu, 16 Jul 2009 13:24:27 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id E26B83A6CB3; Thu, 16 Jul 2009 13:24:26 -0700 (PDT) Received: from [10.0.1.2] (adsl-68-94-0-215.dsl.rcsntx.swbell.net [68.94.0.215]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n6GKOnno078749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Jul 2009 15:24:54 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: From: Ben Campbell To: Hannes Tschofenig In-Reply-To: <16c901ca0194$cfc7dd10$501ca20a@nsnintra.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 16 Jul 2009 15:24:44 -0500 References: <00e801c9d31c$9df95d00$0301a8c0@nsnintra.net> <16c901ca0194$cfc7dd10$501ca20a@nsnintra.net> X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Fri, 17 Jul 2009 03:27:29 -0700 Cc: General Area Review Team , ECRIT Subject: Re: [Ecrit] FW: Gen-ART LC review ofdraft-ietf-ecrit-location-hiding-req-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: Thu, 16 Jul 2009 20:24:28 -0000 Hi, Thanks for the response. Comments imbedded. I removed sections in which I think we are in agreement. On Jul 10, 2009, at 2:29 PM, Hannes Tschofenig wrote: > Hi Ben, > > Thanks for your review. > > Please find some comments below: > [...] > > >>> >>> -- Req-B >>> >>> Is it appropriate for this document to put requirements on the ISP/ >>> IAP? Or do you mean to say they MUST be _able_ to support this, >>> while >>> hiding information location from the VSP and/or UA? > > A lot of the emergency services work relies on assumptions of what > various > parties provide or do not provide. > > For this specific requirement the group thought it would be > important that > the ISP/IAP allows either the end point or the VSP to do some form of > emergency call routing. Assuming that we expect to build protocol mechanisms around these requirements (Is that the intent?), how would you determine compliance with a requirement on an ISP? [...] > > >>> -- Security Considerations: >>> >>> I'm a little skeptical of this statement that this does not raise >>> additional considerations. For example, would you consider >> that a human >>> might be endangered because an ISP wanted to reserve location >>> information as a "for pay" service a security consideration, >> in that it >>> requires the solution to be more fail-safe than other >> protocols? On the >>> other hand, is the need to keep the UA from inferring >> location when an >>> ISP wants to hide it a security consideration? > > > I at least did not know what to write into the security consideration > section. > > I'm not sure I understand your meaning--do you mean to say that you think the section is adequate as is, or do you think in needs more text/work? [...] > >>> >>> -- 3.3, first bullet: >>> >>> Is it appropriate to have "MUST"s in a section on "desirable >>> properties"? > > Hmmm. Not sure. I took the section title of "desirable properties" to mean "properties that are (perhaps very) nice to have, but not hard requirements." If that's what it means, then it seems odd to have a MUST here (except perhaps as a sub-requirement of some feature, where the feature itself is "nice to have". Was the intent something different? Thanks! Ben. From rbarnes@bbn.com Fri Jul 17 06:49:36 2009 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 415973A6B68 for ; Fri, 17 Jul 2009 06:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 47NHa9MeDwii for ; Fri, 17 Jul 2009 06:49:35 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id EF0D43A682B for ; Fri, 17 Jul 2009 06:48:59 -0700 (PDT) Received: from [192.1.255.201] (helo=col-rbarnes-l1.local) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1MRnnw-00039a-Bk; Fri, 17 Jul 2009 09:48:52 -0400 Message-ID: <4A608144.7090107@bbn.com> Date: Fri, 17 Jul 2009 09:48:52 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "James M. Polk" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'ECRIT' Subject: Re: [Ecrit] New ID creating Geocoding URN 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, 17 Jul 2009 13:49:36 -0000 James, I'm a little puzzled as to why you would want to use LoST for [reverse] geocoding -- unless you were trying to discover a geocoding service for a particular region. For just trading civic vs. geodetic information, it would seem much more appropriate to use HELD as a baseline, as in --Richard James M. Polk wrote: > ECRIT > > I have written a new ID creating URNs for Geocoding and > Reverse-Geocoding using LoST. > > http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-geocoding-00.txt > > This draft is not in a preliminary state, and I hope to have a more > complete version out by Stockholm. > > This is a fairly simple draft that merely creates the URNs, and > specifies how LoST can be used to convert Geo to civic, and civic to Geo. > > I hope this idea will not become anything that's complicated. > > Comments are appreciated. > > James > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From jmpolk@cisco.com Fri Jul 17 12:19:35 2009 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 1AA8D3A6C89 for ; Fri, 17 Jul 2009 12:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.379 X-Spam-Level: X-Spam-Status: No, score=-6.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 Pl2N9IzoWitL for ; Fri, 17 Jul 2009 12:19:34 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 3993B28C325 for ; Fri, 17 Jul 2009 12:19:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYFAIJrYEqrR7O6/2dsb2JhbACIQ69IiCORAAWEDQ X-IronPort-AV: E=Sophos;i="4.43,223,1246838400"; d="scan'208";a="187360457" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 17 Jul 2009 19:19:44 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6HJJiJ4005424; Fri, 17 Jul 2009 12:19:44 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6HJJh6H011057; Fri, 17 Jul 2009 19:19:43 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.3959); Fri, 17 Jul 2009 12:19:43 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.9.13]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 12:19:43 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 17 Jul 2009 14:19:41 -0500 To: Richard Barnes From: "James M. Polk" In-Reply-To: <4A608144.7090107@bbn.com> References: <4A608144.7090107@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 17 Jul 2009 19:19:43.0440 (UTC) FILETIME=[89FE5500:01CA0713] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1832; t=1247858384; x=1248722384; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20New=20ID=20creating=20Geocodi ng=20URN |Sender:=20; bh=Wq/3fOFgaSuGCJAOtkxiIOZ0a8ez7sBblCfPty7nUMI=; b=sVBalMKIMQsPBHlHLVzz2aRk9gst8EHHhpfCFjX+PQOwCVbaIcHGxTfQ2Z RL4TaBBeB4dXFysZa2GJvcGVI5lS+IUxh7IFo2hzSzBCtQ2v3A63jgJfooD2 RCJvbMw8hI; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] New ID creating Geocoding URN 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, 17 Jul 2009 19:19:35 -0000 At 08:48 AM 7/17/2009, Richard Barnes wrote: >James, > >I'm a little puzzled as to why you would want to use LoST for >[reverse] geocoding -- unless you were trying to discover a >geocoding service for a particular region. It seems to me that LoST servers will not be that overloaded (though I could be underestimating), and these servers will have both formats for each location anyway. Why not have them just do the conversion between the formats too, as a service. >For just trading civic vs. geodetic information, it would seem much >more appropriate to use HELD as a baseline, as in > I'm not sure HELD will be in every device, which would be required for/by this ID, correct? We believe LoST will be in every current (at some point) and future device, so this seems like a natural fit, given the LoST function is already there. Anything else would be new (unless you consider SIP subscribe to do geocoding - which will likely also be there in each current and future device). James >--Richard > > > > >James M. Polk wrote: >>ECRIT >>I have written a new ID creating URNs for Geocoding and >>Reverse-Geocoding using LoST. >>http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-geocoding-00.txt >>This draft is not in a preliminary state, and I hope to have a more >>complete version out by Stockholm. >>This is a fairly simple draft that merely creates the URNs, and >>specifies how LoST can be used to convert Geo to civic, and civic to Geo. >>I hope this idea will not become anything that's complicated. >>Comments are appreciated. >>James >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Fri Jul 17 13:29:16 2009 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 A2EB03A6E8D for ; Fri, 17 Jul 2009 13:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ol0+RNCU8PDJ for ; Fri, 17 Jul 2009 13:29:15 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 8DAF83A680A for ; Fri, 17 Jul 2009 13:29:15 -0700 (PDT) Received: from [192.1.255.201] (helo=col-rbarnes-l1.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MRt7r-0003lE-Ea; Fri, 17 Jul 2009 15:29:47 -0400 Message-ID: <4A60DF3C.2050401@bbn.com> Date: Fri, 17 Jul 2009 16:29:48 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "James M. Polk" References: <4A608144.7090107@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'ECRIT' Subject: Re: [Ecrit] New ID creating Geocoding URN 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, 17 Jul 2009 20:29:16 -0000 Hey James, >> I'm a little puzzled as to why you would want to use LoST for >> [reverse] geocoding ... > It seems to me that LoST servers will not be that overloaded (though I > could be underestimating), There's nothing preventing these servers from offering a different interface. Heck, both LoST and HELD are HTTP-based, so it'll probably just be another servlet / script / etc. >> For just trading civic vs. geodetic information, it would seem much >> more appropriate to use HELD as a baseline, as in >> > > I'm not sure HELD will be in every device, which would be required > for/by this ID, correct? Last I read phonebcp, HELD and DHCP were required in the same places. Moreover, geocoding is useful in many cases outside of emergency services, so devices that aren't capable of emergency calling might still want to do it. These devices won't necessarily have LoST libraries, so there's no inherent advantage there to using LoST. --Richard From jmpolk@cisco.com Fri Jul 17 16:06:24 2009 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 1900A3A682E for ; Fri, 17 Jul 2009 16:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.389 X-Spam-Level: X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 jJITFinWzPzs for ; Fri, 17 Jul 2009 16:06:23 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1421B3A67E1 for ; Fri, 17 Jul 2009 16:06:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwFAIWgYEqrR7PD/2dsb2JhbACIQ68viCOQcwWCOYFT X-IronPort-AV: E=Sophos;i="4.43,224,1246838400"; d="scan'208";a="349025062" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 17 Jul 2009 23:06:57 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6HN6vp1025781; Fri, 17 Jul 2009 16:06:57 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6HN6vaV014046; Fri, 17 Jul 2009 23:06:57 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 16:06:56 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.9.13]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 16:06:56 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 17 Jul 2009 18:06:56 -0500 To: Richard Barnes From: "James M. Polk" In-Reply-To: <4A60DF3C.2050401@bbn.com> References: <4A608144.7090107@bbn.com> <4A60DF3C.2050401@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 17 Jul 2009 23:06:56.0766 (UTC) FILETIME=[4816C9E0:01CA0733] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2750; t=1247872017; x=1248736017; 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]=20New=20ID=20creating=20Geocodi ng=20URN |Sender:=20; bh=7lBx9zW2jvtXDClclrek+4oyzkRKu91+gnoOw0wU7gQ=; b=CgDbw01lBrJfY4S+BUEZhnKKw2WKJY2bdaJQrqSP1RqGTTrBz1Ern6lgpa /u+CQ4TQjA+oZvR4tUqLD9RoLVcjQ4DJfAyDoJL4qEC8BG9Zc+X1+KM+cUXv VCJ4Kr4wyQ; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] New ID creating Geocoding URN 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, 17 Jul 2009 23:06:24 -0000 At 03:29 PM 7/17/2009, Richard Barnes wrote: >Hey James, > >>>I'm a little puzzled as to why you would want to use LoST for >>>[reverse] geocoding ... >>It seems to me that LoST servers will not be that overloaded >>(though I could be underestimating), > >There's nothing preventing these servers from offering a different >interface. Heck, both LoST and HELD are HTTP-based, so it'll >probably just be another servlet / script / etc. fair comment - but this is a draw IMO >>>For just trading civic vs. geodetic information, it would seem >>>much more appropriate to use HELD as a baseline, as in >>> >>I'm not sure HELD will be in every device, which would be required >>for/by this ID, correct? > >Last I read phonebcp, HELD and DHCP were required in the same places. true - but since devices are made by vendors, they will choose to implement what they want to implement (and I'm not just talking about Cisco), regardless of what a spec says. The all mighty RFP is mightier than the RFC (regrettably) ;-) >Moreover, geocoding is useful in many cases outside of emergency >services, so devices that aren't capable of emergency calling might >still want to do it. ok - to that I'd say that LoST is definitely more useful than just for emergency calling too. The ECRIT WG reached consensus that LoST and the service URNs are to be extended in ECRIT even if the particular service has nothing to do with emergency calling. There was a lively and open debate about this in Vancouver. I'd further say that applications that likely are intelligent enough to know the difference between the two formats will be more intelligent than a palette, thus making them (probably) more often than not able to signal an emergency - even if the likely won't in their lifetime. Smart phones is a good example of this. Not-so-smart phones probably will also have LoST in them, so coding the new URN seems like a no-brainer to me. >These devices which devices? boxes, palettes or phones? >won't necessarily have LoST libraries, so there's no inherent >advantage there to using LoST. I believe the latter of the list above will, and will probably be the type of devices that knows enough to do the geocoding transaction. I'm not thinking palettes or boxes will have the choice of more than one location format, much less know to ask for another one. My draft is targeted at devices that have applications that are smart enough to know there is a difference and to ask for the more preferred format if they only receive a format that know isn't what they prefer. James >--Richard From gunnar.hellstrom@omnitor.se Tue Jul 21 02:09:49 2009 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 494FC3A6BFA for ; Tue, 21 Jul 2009 02:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.211 X-Spam-Level: X-Spam-Status: No, score=0.211 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQoZe0kDkv54 for ; Tue, 21 Jul 2009 02:09:41 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 283DB3A6828 for ; Tue, 21 Jul 2009 02:09:39 -0700 (PDT) Received: (qmail 41948 invoked from network); 21 Jul 2009 09:09:41 -0000 Received: from s34.loopia.se (HELO s128.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 21 Jul 2009 09:09:41 -0000 Received: (qmail 63053 invoked from network); 21 Jul 2009 09:09:37 -0000 Received: from 136.240.13.217.in-addr.dgcsystems.net (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[217.13.240.136]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with SMTP for ; 21 Jul 2009 09:09:37 -0000 From: "Gunnar Hellstrom" To: "Ecrit@Ietf. Org" Date: Tue, 21 Jul 2009 11:09:48 +0200 Message-ID: <02a801ca09e2$ff25b2c0$e800a8c0@GunnarH> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02A9_01CA09F3.C2AE82C0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcoEWDkry5gceNuaTmufX++f5S1pYQ== Subject: [Ecrit] Drafts on real-time text of interest for ECRIT 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, 21 Jul 2009 09:09:49 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02A9_01CA09F3.C2AE82C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A point has been included in the ECRIT agenda on drafts for real-time = text handling. =20 This is a brief description of the drafts and motivation for presenting = them in ECRIT. =20 =20 Title: Real-time text refinements =20 Presenter: Gunnar Hellstrom =20 Drafts:=20 draft-hellstrom-text-conference-01 draft-hellstrom-textpreview-06 draft-hellstrom-text-turntaking-02 draft-hellstrom-textgwy-01 =20 =20 Links: http://www.ietf.org/internet-drafts/draft-hellstrom-text-conference-01.tx= t = http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-06.txt =20 http://www.ietf.org/internet-drafts/draft-hellstrom-text-turntaking-02.tx= t http://www.ietf.org/internet-drafts/draft-hellstrom-txtgwy-01.txt Motivation: Consistent presentation of RFC 4103 real-time text media in SIP sessions have become essential by its adoption for emergency services in the IETF ECRIT specifications. Therefore, specifications are needed that nail = down presentation related details so that the view of a text conversation can = be maintained in synchronism at the participants of a session. One use case is when a relay service is included in the call for = translation between a text conversation with the user and a spoken conversation with = the PSAP, still presenting also the typed dialogue to the PSAP. This = scenario requires a three-party call handling of the real-time text as well as = other media in the call. Text can be used as a single medium in a call, or in various combinations with video and audio to carry all from the whole dialogue to small pieces of information that is easier to transfer by = text than by audio or video.=20 The following drafts will be presented. The basic information on the use = of real-time text is found in RFC 4103, RFC 5194, RFC 5012, draft-ietf-ecrit-phonebcp and draft-ietf-ecrit-framework. 1. draft-hellstrom-text-conference-01 gives details on how to use the = RTP translator model and the mixer model for multi-party conferences with real-time text. Both models have their pros and cons. The translator = model requires no specific marking in the media stream, but instead advanced = RTP handling of multiple SSRC:s in the same RTP session that all RTP implementations MUST have but in practice seldom has. The mixer model requires new source marking at the media level but simpler RTP handling. = It is proposed to agree on the use of one of these methods. 2. draft-hellstrom-textpreview-06 gives details on how real-time text sessions can be presented, and adds details on the scope of erasure and division of text into paragraphs or messages. These clarifications are important to keep a common view of a text conversation for the = participants. 3. draft-hellstrom-text-turntaking-02 is a registration of a media = feature tag of importance for smooth interoperation with legacy text = communication protocols. Gateways to legacy text communication is important where the emergency services provide access for legacy text terminals. The feature = tag is needed because the legacy equipment has functional limitations in simultaneity that the SIP user must consider when in contact with legacy equipment. =20 4. draft-hellstrom-textgwy-01 specifies call control and media handling = for gateways for real-time text between SIP with RFC 4103 for text and PSTN with textphones such as TTY. Gateways to legacy text communication is important where the emergency services provide access for legacy text terminals. =20 =20 More information on the drafts: =20 -------------------------------------------------------------------------= --- ------------- 1. Title : Text media handling in RTP based real-time conferences Author(s) : G. Hellstrom, A. Wijk Filename : draft-hellstrom-text-conference-01.txt Pages : 9 Date : 2009-07-12 This memo specifies methods for text media handling in multi-party = calls, where the text is carried by the RTP protocol. Real-time text is carried = in a time-sampled mode according to RFC 4103. Centralized multi-party = handling of real-time text is achieved through a media control unit coordinating multiple RTP text streams into one RTP session, identifying each stream = with its own SSRC. Identification for the streams are provided through the = RTCP messages. This mechanism enables the receiving application to present = the received real-time text medium in different ways according to user preferences. Some presentation related features are also described explaining suitable variations of transmission and presentation of text. Call control features are described for the SIP environment, while the transport mechanisms should be suitable for any IP based call control environment using RTP transport. An alternative method using a single = RTP stream and source identification inline in the text stream is also described. A URL for this Internet-Draft is: =20 http://www.ietf.org/internet-drafts/draft-hellstrom-text-conference-01.tx= t -------------------------------------------------------------------------= --- --------------------------------- 2. Title : Presentation of Text Conversation in realtime and en-bloc = form Author(s) : G. Hellstrom, et al. Filename : draft-hellstrom-textpreview-06.txt Pages : 17 Date : 2009-07-11 This specification defines methods for presentation of a text = conversation with focus on the real-time features. The aim is to give the = participants in a conversation a good opportunity to perceive the real-time flow of the conversation and also provide a display of the history of the = conversation that makes it easy to read. Both two-party and multi-party situations = are defined. A URL for this Internet-Draft is: = http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-06.txt -------------------------------------------------------------------------= --- ----------- =20 3 Title : Registration of the Real-time-text Media Feature Tag Author(s) : G. Hellstrom, A. Wijk Filename : draft-hellstrom-text-turntaking-02.txt Pages : 6 Date : 2009-07-12 This memo defines a new Media Feature Tag "real-time-text" for use in = SIP registration and session establishment. This is used to indicate if a = device capable of text communication has full real-time text capabilities or limitations in its capabilities requiring the users to apply some turn-taking habits. A URL for this Internet-Draft is: =20 http://www.ietf.org/internet-drafts/draft-hellstrom-text-turntaking-02.tx= t -------------------------------------------------------------------------= --- ---------------------------------- 4. Title : Real-time text interworking between PSTN and IP networks Author(s) : G. Hellstrom, et al. Filename : draft-hellstrom-txtgwy-01.txt Pages : 16 Date : 2009-07-13 IP networks can support real-time text communication. SIP-based real- time text is called Text-over-IP or ToIP. PSTN networks support real-time text using textphones (or TTYs). When real-time text is = supported by different networks, gateways are needed to provide interoperability. Real-time text capable gateways may also support real-time voice. This specification describes procedures for interworking between ToIP = and PSTN textphones using a real-time text capable gateway (RTT gateway). It also describes ways to route calls to RTT gateways for several call scenarios. Procedures that support the phased introduction of RTT gateways and procedures that support the invocation of text channels at any time = during the call are included. Interworking of PSTN textphones that do not = support simultaneity of voice and text with IP User Agents that support = simultaneous voice and text is also described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hellstrom-txtgwy-01.txt ------------------------------------------------------------------ The drafts have not got any working group assignments yet. They are of interest for ECRIT, but probably not of such central interest that they should be made ECRIT working group items. =20 /Gunnar ------------------------------------------------------------------- Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se Tel: +46708204288 www.omnitor.se =20 =20 ------=_NextPart_000_02A9_01CA09F3.C2AE82C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A point has = been included=20 in the ECRIT agenda on drafts for real-time text = handling.
 
This is a brief = description=20 of the drafts and motivation for presenting them in = ECRIT.
 
 
Title: Real-time text refinements
 
Presenter: = Gunnar=20 Hellstrom
 
Drafts:=20
draft-hellstrom-text-conference-01
draft-hellstrom-textpreview-06
draft-hellstrom-text-turntaking-02
draft-hellstrom-textgwy-01
 
 
Links:

http://www.ietf.org/internet-drafts/draft-hellstrom-text-confe= rence-01.txt

http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-= 06.txt

http://www.ietf.org/internet-drafts/draft-hellstrom-text-turntak= ing-02.txt

http://www.ietf.org/internet-drafts/draft-hellstrom-txtgwy-0= 1.txt

Motivation:

Consistent presentation of RFC 4103 real-time = text media in SIP sessions = have=20 become essential by its adoption for emergency services in the IETF = ECRIT=20 specifications. Therefore, specifications are needed that nail down = presentation related details so that the view of a text = conversation can be=20 maintained in synchronism at the participants of a=20 session.

One use case is when a relay service is = included in the=20 call for translation between a text conversation with the user and a = spoken=20 conversation with the PSAP, still presenting also the typed dialogue to = the=20 PSAP. This scenario requires a three-party call handling of the = real-time text=20 as well as other media in the call. Text can be used as a single medium = in a=20 call, or in various combinations with video and audio to carry all from = the=20 whole dialogue to small pieces of information that is easier to transfer = by text=20 than by audio or video.

The = following drafts=20 will be presented. The basic information on the use of real-time text is = found=20 in RFC 4103, RFC 5194, RFC 5012, draft-ietf-ecrit-phonebcp and=20 draft-ietf-ecrit-framework.

1. draft-hellstrom-text-conference-01 gives = details on=20 how to use the RTP translator model and the mixer model for multi-party=20 conferences with real-time text. Both models have their pros and = cons. The translator model requires no specific = marking in=20 the media stream, but instead advanced RTP handling of multiple SSRC:s = in the=20 same RTP session that all RTP implementations MUST have but in practice = seldom=20 has. The mixer model requires new source marking at the media level = but=20 simpler RTP handling. It is = proposed to agree on the use of one of these methods.

2.=20 draft-hellstrom-textpreview-06 gives details on how real-time text = sessions can=20 be presented, and adds details on the scope of erasure and division = of=20 text into paragraphs or messages. = These=20 clarifications are important to keep a common view of a text = conversation for=20 the participants. 

3. draft-hellstrom-text-turntaking-02 is a registration of a = media=20 feature tag of importance for smooth interoperation with legacy text=20 communication protocols. Gateways = to legacy=20 text communication is important where the emergency services provide = access for=20 legacy text terminals. The feature tag is needed because the legacy = equipment has functional limitations in simultaneity that the SIP user = must=20 consider when in contact with legacy=20 equipment.
 
4. draft-hellstrom-textgwy-01 =20 specifies call control and media handling for gateways for real-time=20 text between SIP with RFC 4103 for text  and PSTN with = textphones such=20 as TTY. Gateways to legacy text communication is important where = the=20 emergency services provide access for legacy text=20 terminals.
 
 
More=20 information on the=20 drafts:
 
------------------------------------------------------------= -----------------------------

1. Title : Text media handling = in RTP=20 based real-time conferences

Author(s) : G. Hellstrom, A. = Wijk

Filename :=20 draft-hellstrom-text-conference-01.txt

Pages : 9

Date : 2009-07-12

This memo specifies methods for text = media handling=20 in multi-party calls, where the text is carried by the RTP protocol. = Real-time=20 text is carried in a time-sampled mode according to RFC 4103. = Centralized=20 multi-party handling of real-time text is achieved through a media = control unit=20 coordinating multiple RTP text streams into one RTP session, identifying = each=20 stream with its own SSRC. Identification for the streams are provided = through=20 the RTCP messages. This mechanism enables the receiving application to = present=20 the received real-time text medium in different ways according to user=20 preferences. Some presentation related features are also described = explaining=20 suitable variations of transmission and presentation of text. Call = control=20 features are described for the SIP environment, while the transport = mechanisms=20 should be suitable for any IP based call control environment using RTP=20 transport. An alternative method using a single RTP stream and source=20 identification inline in the text stream is also described.

A URL for this Internet-Draft = is:

http://www.ietf.org/internet-drafts/draft-hellstrom-text-confere= nce-01.txt

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

2. Title : Presentation of Text = Conversation in realtime and en-bloc form

Author(s) : G. Hellstrom, et al.

Filename : = draft-hellstrom-textpreview-06.txt

Pages : 17

Date : 2009-07-11

This specification defines methods for presentation of = a text=20 conversation with focus on the real-time features. The aim is to give = the=20 participants in a conversation a good opportunity to perceive the = real-time flow=20 of the conversation and also provide a display of the history of the=20 conversation that makes it easy to read. Both two-party and multi-party=20 situations are defined.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-= 06.txt

------------------------------------------------------------= ---------------------------
 
3 Title : Registration of the = Real-time-text=20 Media Feature Tag

Author(s) : G. Hellstrom, A. Wijk

Filename : = draft-hellstrom-text-turntaking-02.txt

Pages : 6

Date : 2009-07-12

This memo defines a new Media Feature Tag = "real-time-text" for=20 use in SIP registration and session establishment. This is used to = indicate if a=20 device capable of text communication has full real-time text = capabilities or=20 limitations in its capabilities requiring the users to apply some = turn-taking=20 habits.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-hellstrom-text-turntak= ing-02.txt

-----------------------------------------------= ---------------------------------------------------------------
4. Title : Real-time text interworking = between=20 PSTN and IP networks

Author(s) : G. Hellstrom, et al.

Filename : = draft-hellstrom-txtgwy-01.txt

Pages : 16

Date : 2009-07-13

IP networks can support real-time text = communication.=20 SIP-based

real- time text is called Text-over-IP or ToIP. = PSTN=20 networks support real-time text using textphones (or TTYs). When = real-time text=20 is supported by different networks, gateways are needed to provide=20 interoperability. Real-time text capable gateways may also support = real-time=20 voice.

This specification describes procedures for = interworking=20 between ToIP and PSTN textphones using a real-time text capable gateway = (RTT=20 gateway). It also describes ways to route calls to RTT gateways for = several call=20 scenarios.

Procedures that support the phased introduction of = RTT=20 gateways and procedures that support the invocation of text channels at = any time=20 during the call are included. Interworking of PSTN textphones that do = not=20 support simultaneity of voice and text with IP User Agents that support=20 simultaneous voice and text is also described.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-hellstrom-txtgwy-0= 1.txt

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

The drafts have = not got any=20 working group assignments yet. They are of interest for ECRIT, but = probably not=20 of such central interest that they should be made ECRIT working group=20 items.
 
/Gunnar
----------------------------------------------------------------= ---
Gunnar = Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se
Tel: = +46708204288
www.omnitor.se
 
------=_NextPart_000_02A9_01CA09F3.C2AE82C0-- From root@core3.amsl.com Mon Jul 27 09:45:01 2009 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BEB8828C0FF; Mon, 27 Jul 2009 09: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: <20090727164501.BEB8828C0FF@core3.amsl.com> Date: Mon, 27 Jul 2009 09:45:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-framework-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: , X-List-Received-Date: Mon, 27 Jul 2009 16:45: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 : Framework for Emergency Calling using Internet Multimedia Author(s) : B. Rosen, et al. Filename : draft-ietf-ecrit-framework-10.txt Pages : 37 Date : 2009-07-27 The IETF has standardized various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-framework-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-27093025.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 27 10:30:01 2009 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 60DD23A6C80; Mon, 27 Jul 2009 10:30: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: <20090727173001.60DD23A6C80@core3.amsl.com> Date: Mon, 27 Jul 2009 10:30:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-13.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: Mon, 27 Jul 2009 17:30: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 : Best Current Practice for Communications Services in support of Emergency Calling Author(s) : B. Rosen, J. Polk Filename : draft-ietf-ecrit-phonebcp-13.txt Pages : 45 Date : 2009-07-27 The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-13.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-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-27101914.I-D@ietf.org> --NextPart-- From RMarshall@telecomsys.com Mon Jul 27 12:46:07 2009 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 DE5F63A6D1E for ; Mon, 27 Jul 2009 12:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PArPi9Ob9uu2 for ; Mon, 27 Jul 2009 12:46:06 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [199.165.246.12]) by core3.amsl.com (Postfix) with ESMTP id CD4563A6A02 for ; Mon, 27 Jul 2009 12:46:06 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Mon, 27 Jul 2009 12:46:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0EF2.D655AD6C" Date: Mon, 27 Jul 2009 12:45:47 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750D7E23EF@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <02a801ca09e2$ff25b2c0$e800a8c0@GunnarH> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda is changing - need feedback and slides Thread-Index: AcoEWDkry5gceNuaTmufX++f5S1pYQKZnuRg References: <02a801ca09e2$ff25b2c0$e800a8c0@GunnarH> From: "Roger Marshall" To: "Ecrit@Ietf. Org" Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: [Ecrit] Agenda is changing - need feedback and slides 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, 27 Jul 2009 19:46:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0EF2.D655AD6C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since Henning and Hannes weren't able to attend this IETF, we need to decide what to do with a few drafts. =20 Of the following consolidated agenda, I need slides from the presenters soon, and no later than 12 noon tomorrow (Tues). =20 Emergency Context Resolution with Internet Technologies (ecrit) WEDNESDAY, July 29, 2009 0900-1130 Morning Session I =20 * Status Update (Chairs, 15 min) * Specifying Holes in LoST Service Boundaries (Martin, 15 min) * IANA Registering a SIP RPH Namespace for Local Emergency Communications (James, 10 min) * Using Imprecise Location for Emergency Context Resolution (Richard, 10 min)=20 >* Policy for defining new service-identifying labels (Henning, 15 min) * Location-to-Service Translation Protocol (LoST) Extension: ServiceListBoundary (Karl-Heinz, 10 min) =20 * Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices (Dirk, 15 min) =20 >* Marking of Calls initiated by PSAPs (Henning, 15 min) >* Premature Disconnect Indication (Henning, 15 min) * Trustworthy Location Information (Bernard, 15 min) =20 * Real-time text activities relevant for ECRIT (Gunnar, 15 min) =20 Brian has agreed to present in place of Henning for: =20 * Premature Disconnect Indication (Henning, 15 min) http://tools.ietf.org/html/draft-rosen-ecrit-premature-disconnect-rqmts =20 =20 =20 The other two presentations we will cancel. * Policy for defining new service-identifying labels (Henning, 15 min) http://tools.ietf.org/id/draft-forte-ecrit-service-urn-policy =20 =20 * Marking of Calls initiated by PSAPs (Henning, 15 min) http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-00.txt =20 =20 If anyone needs more time than presently allotted, let Marc & I know quick. =20 thanks. =20 Roger Marshall/Marc Linsner CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. ------_=_NextPart_001_01CA0EF2.D655AD6C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Since=20 Henning and Hannes weren't able to attend this IETF, we need to decide what= to=20 do with a few drafts.
 
Of the=20 following consolidated agenda, I need slides from the presen= ters=20 soon, and no later than 12 noon tomorrow (Tues).
 
Emergency Context Resolution with Internet Techn= ologies=20 (ecrit)
WEDNESDAY, July 29, 2009
0900-1130 Morning Session=20 I
 
*=20 Status Update (Chairs, 15 min)
* Specifying Holes in LoST Service Bounda= ries=20 (Martin, 15 min)
* IANA Registering a SIP RPH Namespace for Local Emerge= ncy=20 Communications  (James, 10 min)
* Using Imprecise Location for Emer= gency=20 Context Resolution (Richard, 10 min)
>* Policy for defining new=20 service-identifying labels (Henning, 15 min) 
* Location-to-Servic= e=20 Translation Protocol (LoST) Extension: ServiceListBoundary (Karl-Heinz, 10= =20 min) 
* Extensions to the Emergency Services Architecture for deal= ing=20 with
Unauthenticated and Unauthorized Devices (Dirk, 15 min) 
&= gt;*=20 Marking of Calls initiated by PSAPs (Henning, 15 min)
>* Premature=20 Disconnect Indication (Henning, 15 min)
* Trustworthy Location Informati= on=20 (Bernard, 15 min)  
* Real-time text activities relevant for = ECRIT=20 (Gunnar, 15 min)
 
Brian=20 has agreed to present in place of Henning for:
 
* Premature Disconnect Ind= ication=20 (Henning, 15 min)
http://tools.ietf.org/html/draft-rosen-ecrit-premature-disconnect-= rqmts
 
 
The=20 other two presentations we will cancel.

* Policy for defining = new=20 service-identifying labels (Henning, 15 min)
http://tools.ietf.org/id/draft-forte-ecrit-service-urn-policy
 

* Marking of Calls ini= tiated by=20 PSAPs (Henning, 15 min)
http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-00.= txt
 
If anyone=20 needs more time than presently allotted, let Marc & I know=20 quick.
 
thanks.
 
Roger Marshall/Marc=20 Linsner


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

------_=_NextPart_001_01CA0EF2.D655AD6C-- From br@brianrosen.net Mon Jul 27 13:33:30 2009 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 93A973A6C7B; Mon, 27 Jul 2009 13:33:30 -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 FuJIuKM+-xAB; Mon, 27 Jul 2009 13:33:29 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id CF4EC3A6A02; Mon, 27 Jul 2009 13:33:29 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MVWsm-0003Pt-AV; Mon, 27 Jul 2009 15:33:20 -0500 From: "Brian Rosen" To: , References: <20090727164501.BEB8828C0FF@core3.amsl.com> In-Reply-To: <20090727164501.BEB8828C0FF@core3.amsl.com> Date: Mon, 27 Jul 2009 16:33:20 -0400 Message-ID: <008401ca0ef9$80f18d40$82d4a7c0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoO2aakInzg+9g0SmGaqhzQy8DJCQAH8EJA Content-Language: en-us 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] I-D Action:draft-ietf-ecrit-framework-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: , X-List-Received-Date: Mon, 27 Jul 2009 20:33:30 -0000 This update fixes idnits, and that is it. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Monday, July 27, 2009 12:45 PM > To: i-d-announce@ietf.org > Cc: ecrit@ietf.org > Subject: [Ecrit] I-D Action:draft-ietf-ecrit-framework-10.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Emergency Context Resolution with > Internet Technologies Working Group of the IETF. > > > Title : Framework for Emergency Calling using Internet > Multimedia > Author(s) : B. Rosen, et al. > Filename : draft-ietf-ecrit-framework-10.txt > Pages : 37 > Date : 2009-07-27 > > The IETF has standardized various aspects of placing emergency calls. > This document describes how all of those component parts are used to > support emergency calls from citizens and visitors to authorities. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-10.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From br@brianrosen.net Mon Jul 27 13:35:34 2009 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 C9F183A6A0F for ; Mon, 27 Jul 2009 13:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4v8GnVM0KK3I for ; Mon, 27 Jul 2009 13:35:34 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 0AEA03A67E4 for ; Mon, 27 Jul 2009 13:35:34 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MVWup-0003Vq-Ln for ecrit@ietf.org; Mon, 27 Jul 2009 15:35:24 -0500 From: "Brian Rosen" To: References: <20090727173001.60DD23A6C80@core3.amsl.com> In-Reply-To: <20090727173001.60DD23A6C80@core3.amsl.com> Date: Mon, 27 Jul 2009 16:35:30 -0400 Message-ID: <008501ca0ef9$cb02e2d0$6108a870$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoO39zl4BsVe/S6T9yyS2qj9Z0FhQAGaKXw Content-Language: en-us 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] I-D Action:draft-ietf-ecrit-phonebcp-13.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: Mon, 27 Jul 2009 20:35:34 -0000 This update fixes idnits. Note that there is a problem with the "Intended Status" of -location-conveyance, which is PS. The tools don't recognize the status because it says "Standards Track (PS)" and not simply "Standards Track", and assume Informational. Therefore we can ignore the error generated by idnits. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Monday, July 27, 2009 1:30 PM > To: i-d-announce@ietf.org > Cc: ecrit@ietf.org > Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-13.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Emergency Context Resolution with > Internet Technologies Working Group of the IETF. > > > Title : Best Current Practice for Communications > Services in support of Emergency Calling > Author(s) : B. Rosen, J. Polk > Filename : draft-ietf-ecrit-phonebcp-13.txt > Pages : 45 > Date : 2009-07-27 > > The IETF and other standards organization have efforts targeted at > standardizing various aspects of placing emergency calls on IP > networks. This memo describes best current practice on how devices, > networks and services should use such standards to make emergency > calls. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-13.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. From jmpolk@cisco.com Mon Jul 27 16:20:33 2009 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 AC3F63A69D3 for ; Mon, 27 Jul 2009 16:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 fUKM4-qna0IN for ; Mon, 27 Jul 2009 16:20:32 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 52F903A6B89 for ; Mon, 27 Jul 2009 16:20:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8FAMLSbUqrR7PE/2dsb2JhbACIR7FCiCiOewWCN4FVgU2CEA X-IronPort-AV: E=Sophos;i="4.43,278,1246838400"; d="scan'208";a="219822445" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 27 Jul 2009 23:20:12 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n6RNKCOF001514; Mon, 27 Jul 2009 16:20:12 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6RNKCan021286; Mon, 27 Jul 2009 23:20:12 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 16:20:12 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.2.97]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 16:20:10 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Jul 2009 18:19:53 -0500 To: "Roger Marshall" , "Ecrit@Ietf. Org" From: "James M. Polk" In-Reply-To: <8C837214C95C864C9F34F3635C2A65750D7E23EF@SEA-EXCHVS-2.tele comsys.com> References: <02a801ca09e2$ff25b2c0$e800a8c0@GunnarH> <8C837214C95C864C9F34F3635C2A65750D7E23EF@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 27 Jul 2009 23:20:11.0532 (UTC) FILETIME=[C9EFF4C0:01CA0F10] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3087; t=1248736812; x=1249600812; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Agenda=20is=20changing=20-=20 need=20feedback=20and=20slides |Sender:=20; bh=j8sDaZiVrG8c2hJ8sc35wg593IV+zncBHqmDSc8uHa8=; b=LclVtpwyAh3WCSxW77YpMJgJw5hq9QmjBYlrOGOVlZs67DR5KkRl2LmSA7 yLgUaZYmUMJ2hTNka4x8BB1ZNsAa/nvDZVZKveHkcjV4YHtfrMQIL3E70DAh y5hxH8eMqk; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [Ecrit] Agenda is changing - need feedback and slides 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, 27 Jul 2009 23:20:33 -0000 At 02:45 PM 7/27/2009, Roger Marshall wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01CA0EF2.D655AD6C" > >Since Henning and Hannes weren't able to attend this IETF, we need >to decide what to do with a few drafts. > >Of the following consolidated agenda, I need slides from the >presenters soon, and no later than 12 noon tomorrow (Tues). > >Emergency Context Resolution with Internet Technologies (ecrit) >WEDNESDAY, July 29, 2009 >0900-1130 Morning Session I > >* Status Update (Chairs, 15 min) >* Specifying Holes in LoST Service Boundaries (Martin, 15 min) >* IANA Registering a SIP RPH Namespace for Local Emergency >Communications (James, 10 min) Roger - I didn't update this ID for IETF75 (didn't get to it among all I did update). - I have a detailed review from Keith, which will be the basis for my next rev of this ID. James >* Using Imprecise Location for Emergency Context Resolution (Richard, 10 min) > >* Policy for defining new service-identifying labels (Henning, 15 min) >* Location-to-Service Translation Protocol (LoST) Extension: >ServiceListBoundary (Karl-Heinz, 10 min) >* Extensions to the Emergency Services Architecture for dealing with >Unauthenticated and Unauthorized Devices (Dirk, 15 min) > >* Marking of Calls initiated by PSAPs (Henning, 15 min) > >* Premature Disconnect Indication (Henning, 15 min) >* Trustworthy Location Information (Bernard, 15 min) >* Real-time text activities relevant for ECRIT (Gunnar, 15 min) > >Brian has agreed to present in place of Henning for: > >* Premature Disconnect Indication (Henning, 15 min) >http://tools.ietf.org/html/draft-rosen-ecrit-premature-disconnect-rqmts > > >The other two presentations we will cancel. > >* Policy for defining new service-identifying labels (Henning, 15 min) >http://tools.ietf.org/id/draft-forte-ecrit-service-urn-policy > > >* Marking of Calls initiated by PSAPs (Henning, 15 min) >http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-00.txt > >If anyone needs more time than presently allotted, let Marc & I know quick. > >thanks. > >Roger Marshall/Marc Linsner > > >CONFIDENTIALITY NOTICE: The information contained in this message >may be privileged and/or confidential. If you are not the intended >recipient, or responsible for delivering this message to the >intended recipient, any review, forwarding, dissemination, >distribution or copying of this communication or any attachment(s) >is strictly prohibited. If you have received this message in error, >please notify the sender immediately, and delete it and all >attachments from your computer and network. >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From Martin.Thomson@andrew.com Tue Jul 28 01:00:36 2009 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 29E113A67BD for ; Tue, 28 Jul 2009 01:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.177, 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 Gx2SuynKUQH4 for ; Tue, 28 Jul 2009 01:00:35 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id C368A3A691A for ; Tue, 28 Jul 2009 01:00:34 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_28_03_23_07 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 28 Jul 2009 03:23:06 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 03:00:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0F59.7CC93854" Date: Tue, 28 Jul 2009 03:00:32 -0500 Message-ID: In-Reply-To: <8C837214C95C864C9F34F3635C2A65750D7E23EF@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Agenda is changing - need feedback and slides Thread-Index: AcoEWDkry5gceNuaTmufX++f5S1pYQKZnuRgACachFA= References: <02a801ca09e2$ff25b2c0$e800a8c0@GunnarH> <8C837214C95C864C9F34F3635C2A65750D7E23EF@SEA-EXCHVS-2.telecomsys.com> From: "Thomson, Martin" To: "Roger Marshall" , "Ecrit@Ietf. Org" X-OriginalArrivalTime: 28 Jul 2009 08:00:35.0999 (UTC) FILETIME=[7D2B82F0:01CA0F59] Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [Ecrit] Agenda is changing - need feedback and slides 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, 28 Jul 2009 08:00:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0F59.7CC93854 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9nZXIsDQoNCiANCg0KSSByZWFsbHkgZG9u4oCZdCBuZWVkIChvciB3YW50KSAxNSBtaW51 dGVzLiAgQ3VsbGVuIHJhaXNlZCBhIHZlcnkgc21hbGwgaXNzdWUsIHdlIHJlc29sdmVkIGl0IGFu ZCBJ4oCZbGwganVzdCBuZWVkIHRvIGdldCBhIGNvbmZpcm1hdGlvbi4gIE1heWJlIHdlIGNhbiBn ZXQgbW9yZSBvdXQgb2YgZGlzY3Vzc2luZyB0cnVzdHdvcnRoeSBsb2NhdGlvbi4NCg0KIA0KDQpJ 4oCZbGwgYWxzbyBub3RlIHRoYXQgS2FybC1IZWlueiBpc27igJl0IGhlcmUgKG9yIEkgaGF2ZW7i gJl0IHNlZW4gaGltKS4NCg0KIA0KDQpGcm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIFttYWls dG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvZ2VyIE1hcnNoYWxsDQpT ZW50OiBNb25kYXksIDI3IEp1bHkgMjAwOSA5OjQ2IFBNDQpUbzogRWNyaXRASWV0Zi4gT3JnDQpD YzogVHNjaG9mZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3BvbykNClN1YmplY3Q6IFtFY3JpdF0g QWdlbmRhIGlzIGNoYW5naW5nIC0gbmVlZCBmZWVkYmFjayBhbmQgc2xpZGVzDQoNCiANCg0KU2lu Y2UgSGVubmluZyBhbmQgSGFubmVzIHdlcmVuJ3QgYWJsZSB0byBhdHRlbmQgdGhpcyBJRVRGLCB3 ZSBuZWVkIHRvIGRlY2lkZSB3aGF0IHRvIGRvIHdpdGggYSBmZXcgZHJhZnRzLg0KDQogDQoNCk9m IHRoZSBmb2xsb3dpbmcgY29uc29saWRhdGVkIGFnZW5kYSwgSSBuZWVkIHNsaWRlcyBmcm9tIHRo ZSBwcmVzZW50ZXJzIHNvb24sIGFuZCBubyBsYXRlciB0aGFuIDEyIG5vb24gdG9tb3Jyb3cgKFR1 ZXMpLg0KDQogDQoNCkVtZXJnZW5jeSBDb250ZXh0IFJlc29sdXRpb24gd2l0aCBJbnRlcm5ldCBU ZWNobm9sb2dpZXMgKGVjcml0KQ0KV0VETkVTREFZLCBKdWx5IDI5LCAyMDA5DQowOTAwLTExMzAg TW9ybmluZyBTZXNzaW9uIEkNCg0KIA0KDQoqIFN0YXR1cyBVcGRhdGUgKENoYWlycywgMTUgbWlu KQ0KKiBTcGVjaWZ5aW5nIEhvbGVzIGluIExvU1QgU2VydmljZSBCb3VuZGFyaWVzIChNYXJ0aW4s IDE1IG1pbikNCiogSUFOQSBSZWdpc3RlcmluZyBhIFNJUCBSUEggTmFtZXNwYWNlIGZvciBMb2Nh bCBFbWVyZ2VuY3kgQ29tbXVuaWNhdGlvbnMgIChKYW1lcywgMTAgbWluKQ0KKiBVc2luZyBJbXBy ZWNpc2UgTG9jYXRpb24gZm9yIEVtZXJnZW5jeSBDb250ZXh0IFJlc29sdXRpb24gKFJpY2hhcmQs IDEwIG1pbikgDQo+KiBQb2xpY3kgZm9yIGRlZmluaW5nIG5ldyBzZXJ2aWNlLWlkZW50aWZ5aW5n IGxhYmVscyAoSGVubmluZywgMTUgbWluKSAgDQoqIExvY2F0aW9uLXRvLVNlcnZpY2UgVHJhbnNs YXRpb24gUHJvdG9jb2wgKExvU1QpIEV4dGVuc2lvbjogU2VydmljZUxpc3RCb3VuZGFyeSAoS2Fy bC1IZWlueiwgMTAgbWluKSAgDQoqIEV4dGVuc2lvbnMgdG8gdGhlIEVtZXJnZW5jeSBTZXJ2aWNl cyBBcmNoaXRlY3R1cmUgZm9yIGRlYWxpbmcgd2l0aA0KVW5hdXRoZW50aWNhdGVkIGFuZCBVbmF1 dGhvcml6ZWQgRGV2aWNlcyAoRGlyaywgMTUgbWluKSAgDQo+KiBNYXJraW5nIG9mIENhbGxzIGlu aXRpYXRlZCBieSBQU0FQcyAoSGVubmluZywgMTUgbWluKQ0KPiogUHJlbWF0dXJlIERpc2Nvbm5l Y3QgSW5kaWNhdGlvbiAoSGVubmluZywgMTUgbWluKQ0KKiBUcnVzdHdvcnRoeSBMb2NhdGlvbiBJ bmZvcm1hdGlvbiAoQmVybmFyZCwgMTUgbWluKSAgIA0KKiBSZWFsLXRpbWUgdGV4dCBhY3Rpdml0 aWVzIHJlbGV2YW50IGZvciBFQ1JJVCAoR3VubmFyLCAxNSBtaW4pDQoNCiANCg0KQnJpYW4gaGFz IGFncmVlZCB0byBwcmVzZW50IGluIHBsYWNlIG9mIEhlbm5pbmcgZm9yOg0KDQogDQoNCiogUHJl bWF0dXJlIERpc2Nvbm5lY3QgSW5kaWNhdGlvbiAoSGVubmluZywgMTUgbWluKQ0KaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcm9zZW4tZWNyaXQtcHJlbWF0dXJlLWRpc2Nvbm5lY3Qt cnFtdHMgPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJvc2VuLWVjcml0LXByZW1h dHVyZS1kaXNjb25uZWN0LXJxbXRzPiANCg0KIA0KDQogDQoNClRoZSBvdGhlciB0d28gcHJlc2Vu dGF0aW9ucyB3ZSB3aWxsIGNhbmNlbC4NCg0KDQoqIFBvbGljeSBmb3IgZGVmaW5pbmcgbmV3IHNl cnZpY2UtaWRlbnRpZnlpbmcgbGFiZWxzIChIZW5uaW5nLCAxNSBtaW4pDQpodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaWQvZHJhZnQtZm9ydGUtZWNyaXQtc2VydmljZS11cm4tcG9saWN5IDxodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtZm9ydGUtZWNyaXQtc2VydmljZS11cm4tcG9saWN5PiAN Cg0KIA0KDQoNCiogTWFya2luZyBvZiBDYWxscyBpbml0aWF0ZWQgYnkgUFNBUHMgKEhlbm5pbmcs IDE1IG1pbikNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1zY2h1bHpyaW5uZS1lY3Jp dC1wc2FwLWNhbGxiYWNrLTAwLnR4dCA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXNj aHVsenJpbm5lLWVjcml0LXBzYXAtY2FsbGJhY2stMDAudHh0PiANCg0KIA0KDQpJZiBhbnlvbmUg bmVlZHMgbW9yZSB0aW1lIHRoYW4gcHJlc2VudGx5IGFsbG90dGVkLCBsZXQgTWFyYyAmIEkga25v dyBxdWljay4NCg0KIA0KDQp0aGFua3MuDQoNCiANCg0KUm9nZXIgTWFyc2hhbGwvTWFyYyBMaW5z bmVyDQoNCiANCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIHByaXZpbGVnZWQgYW5kL29yIGNvbmZpZGVudGlh bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgb3IgcmVzcG9uc2libGUg Zm9yIGRlbGl2ZXJpbmcgdGhpcyBtZXNzYWdlIHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIGFu eSByZXZpZXcsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5 aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBvciBhbnkgYXR0YWNobWVudChzKSBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSwgYW5kIGRlbGV0ZSBpdCBhbmQg YWxsIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlciBhbmQgbmV0d29yay4NCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRo ZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwg cHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3Ug aGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1l ZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9m DQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClttZjJdDQo= ------_=_NextPart_001_01CA0F59.7CC93854 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDov L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KDQo8bWV0YSBuYW1lPUdlbmVy YXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5 bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6 MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzI0NDA2MTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LlNlY3Rp b24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQog PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5n PUVOLUFVIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+SGkgUm9nZXIsPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9y OiMyNDQwNjEnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz5JIHJlYWxseSBkb27igJl0IG5lZWQgKG9yIHdh bnQpIDE1IG1pbnV0ZXMuwqAgQ3VsbGVuIHJhaXNlZCBhIHZlcnkNCnNtYWxsIGlzc3VlLCB3ZSBy ZXNvbHZlZCBpdCBhbmQgSeKAmWxsIGp1c3QgbmVlZCB0byBnZXQgYSBjb25maXJtYXRpb24uwqAg TWF5YmUgd2UNCmNhbiBnZXQgbW9yZSBvdXQgb2YgZGlzY3Vzc2luZyB0cnVzdHdvcnRoeSBsb2Nh dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KY29sb3I6IzI0NDA2MSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMyNDQwNjEnPknigJlsbCBhbHNvIG5vdGUgdGhh dCBLYXJsLUhlaW56IGlzbuKAmXQgaGVyZSAob3IgSSBoYXZlbuKAmXQgc2Vlbg0KaGltKS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6 IzI0NDA2MSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2IHN0eWxlPSdib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQnPg0KDQo8ZGl2Pg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5Og0KIlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIic+IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcNClttYWlsdG86ZWNyaXQtYm91 bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5Sb2dlciBNYXJzaGFsbDxicj4NCjxi PlNlbnQ6PC9iPiBNb25kYXksIDI3IEp1bHkgMjAwOSA5OjQ2IFBNPGJyPg0KPGI+VG86PC9iPiBF Y3JpdEBJZXRmLiBPcmc8YnI+DQo8Yj5DYzo8L2I+IFRzY2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0g RkkvRXNwb28pPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFY3JpdF0gQWdlbmRhIGlzIGNoYW5naW5n IC0gbmVlZCBmZWVkYmFjayBhbmQgc2xpZGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rp dj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KY29sb3I6Ymx1ZSc+U2luY2Ug SGVubmluZyBhbmQgSGFubmVzIHdlcmVuJ3QgYWJsZSB0byBhdHRlbmQgdGhpcyBJRVRGLCB3ZSBu ZWVkDQp0byBkZWNpZGUgd2hhdCB0byBkbyB3aXRoIGEgZmV3IGRyYWZ0cy48L3NwYW4+PG86cD48 L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7 PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7DQpjb2xvcjpibHVlJz5PZiB0aGUgZm9sbG93aW5nIGNvbnNvbGlkYXRlZCBhZ2VuZGEs IEkgbmVlZCBzbGlkZXMgZnJvbSB0aGUNCnByZXNlbnRlcnMgc29vbiwgYW5kIG5vIGxhdGVyIHRo YW4gMTIgbm9vbiB0b21vcnJvdyAoVHVlcykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rp dj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K DQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KY29sb3I6Ymx1 ZSc+RW1lcmdlbmN5IENvbnRleHQgUmVzb2x1dGlvbiB3aXRoIEludGVybmV0IFRlY2hub2xvZ2ll cyAoZWNyaXQpPGJyPg0KV0VETkVTREFZLCBKdWx5IDI5LCAyMDA5PGJyPg0KMDkwMC0xMTMwIE1v cm5pbmcgU2Vzc2lvbiBJPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0K PGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KY29sb3I6Ymx1ZSc+KiBTdGF0dXMg VXBkYXRlIChDaGFpcnMsIDE1IG1pbik8YnI+DQoqIFNwZWNpZnlpbmcgSG9sZXMgaW4gTG9TVCBT ZXJ2aWNlIEJvdW5kYXJpZXMgKE1hcnRpbiwgMTUgbWluKTxicj4NCiogSUFOQSBSZWdpc3Rlcmlu ZyBhIFNJUCBSUEggTmFtZXNwYWNlIGZvciBMb2NhbCBFbWVyZ2VuY3kgQ29tbXVuaWNhdGlvbnMm bmJzcDsNCihKYW1lcywgMTAgbWluKTxicj4NCiogVXNpbmcgSW1wcmVjaXNlIExvY2F0aW9uIGZv ciBFbWVyZ2VuY3kgQ29udGV4dCBSZXNvbHV0aW9uIChSaWNoYXJkLCAxMCBtaW4pIDxicj4NCiZn dDsqIFBvbGljeSBmb3IgZGVmaW5pbmcgbmV3IHNlcnZpY2UtaWRlbnRpZnlpbmcgbGFiZWxzIChI ZW5uaW5nLCAxNQ0KbWluKSZuYnNwOyA8YnI+DQoqIExvY2F0aW9uLXRvLVNlcnZpY2UgVHJhbnNs YXRpb24gUHJvdG9jb2wgKExvU1QpIEV4dGVuc2lvbjoNClNlcnZpY2VMaXN0Qm91bmRhcnkgKEth cmwtSGVpbnosIDEwIG1pbikmbmJzcDsgPGJyPg0KKiBFeHRlbnNpb25zIHRvIHRoZSBFbWVyZ2Vu Y3kgU2VydmljZXMgQXJjaGl0ZWN0dXJlIGZvciBkZWFsaW5nIHdpdGg8YnI+DQpVbmF1dGhlbnRp Y2F0ZWQgYW5kIFVuYXV0aG9yaXplZCBEZXZpY2VzIChEaXJrLCAxNSBtaW4pJm5ic3A7IDxicj4N CiZndDsqIE1hcmtpbmcgb2YgQ2FsbHMgaW5pdGlhdGVkIGJ5IFBTQVBzIChIZW5uaW5nLCAxNSBt aW4pPGJyPg0KJmd0OyogUHJlbWF0dXJlIERpc2Nvbm5lY3QgSW5kaWNhdGlvbiAoSGVubmluZywg MTUgbWluKTxicj4NCiogVHJ1c3R3b3J0aHkgTG9jYXRpb24gSW5mb3JtYXRpb24gKEJlcm5hcmQs IDE1IG1pbikmbmJzcDsmbmJzcDsgPGJyPg0KKiBSZWFsLXRpbWUgdGV4dCBhY3Rpdml0aWVzIHJl bGV2YW50IGZvciBFQ1JJVCAoR3VubmFyLCAxNSBtaW4pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K DQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KY29s b3I6Ymx1ZSc+QnJpYW4gaGFzIGFncmVlZCB0byBwcmVzZW50IGluIHBsYWNlIG9mIEhlbm5pbmcg Zm9yOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOmJsdWUnPiogUHJlbWF0dXJlIERpc2Nvbm5l Y3QgSW5kaWNhdGlvbiAoSGVubmluZywgMTUgbWluKTxicj4NCjwvc3Bhbj48YQ0KaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcm9zZW4tZWNyaXQtcHJlbWF0dXJlLWRpc2Nv bm5lY3QtcnFtdHMiPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIic+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcm9z ZW4tZWNyaXQtcHJlbWF0dXJlLWRpc2Nvbm5lY3QtcnFtdHM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiOw0KY29sb3I6Ymx1ZSc+VGhlIG90aGVyIHR3byBwcmVzZW50YXRpb25zIHdlIHdpbGwg Y2FuY2VsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48YnI+DQo8c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz4qDQpQb2xpY3kgZm9yIGRlZmlu aW5nIG5ldyBzZXJ2aWNlLWlkZW50aWZ5aW5nIGxhYmVscyAoSGVubmluZywgMTUgbWluKTxicj4N Cjwvc3Bhbj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtZm9ydGUtZWNy aXQtc2VydmljZS11cm4tcG9saWN5Ij48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9k cmFmdC1mb3J0ZS1lY3JpdC1zZXJ2aWNlLXVybi1wb2xpY3k8L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxicj4N CjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO2NvbG9yOmJsdWUnPioNCk1hcmtpbmcgb2YgQ2FsbHMgaW5pdGlhdGVkIGJ5IFBTQVBz IChIZW5uaW5nLCAxNSBtaW4pPGJyPg0KPC9zcGFuPjxhDQpocmVmPSJodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaWQvZHJhZnQtc2NodWx6cmlubmUtZWNyaXQtcHNhcC1jYWxsYmFjay0wMC50eHQiPjxz cGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIic+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXNjaHVsenJpbm5lLWVjcml0LXBz YXAtY2FsbGJhY2stMDAudHh0PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoN CjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPC9k aXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOmJsdWUnPklm IGFueW9uZSBuZWVkcyZuYnNwO21vcmUgdGltZSB0aGFuIHByZXNlbnRseSBhbGxvdHRlZCwgbGV0 IE1hcmMNCiZhbXA7IEkga25vdyBxdWljay48L3NwYW4+PG86cD48L286cD48L3A+DQoNCjwvZGl2 Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+DQoN CjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQpjb2xvcjpibHVl Jz50aGFua3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KY29sb3I6Ymx1ZSc+Um9nZXIgTWFyc2hhbGwv TWFyYyBMaW5zbmVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PG86cD4mbmJz cDs8L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8cD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5DT05GSURFTlRJQUxJVFkNCk5PVElD RTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIHByaXZp bGVnZWQgYW5kL29yDQpjb25maWRlbnRpYWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIG9yIHJlc3BvbnNpYmxlIGZvcg0KZGVsaXZlcmluZyB0aGlzIG1lc3NhZ2UgdG8g dGhlIGludGVuZGVkIHJlY2lwaWVudCwgYW55IHJldmlldywgZm9yd2FyZGluZywNCmRpc3NlbWlu YXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBvciBh bnkNCmF0dGFjaG1lbnQocykgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBtZXNzYWdlIGluDQplcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5LCBhbmQgZGVsZXRlIGl0IGFuZCBhbGwgYXR0YWNobWVudHMNCmZyb20geW91ciBj b21wdXRlciBhbmQgbmV0d29yay48L3NwYW4+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8 L2Rpdj4NCg0KPGJyPjxicj48dGFibGUgYmdjb2xvcj13aGl0ZSBzdHlsZT0iY29sb3I6YmxhY2si Pjx0cj48dGQ+PGJyPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N ClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aXMmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDtkZXNpZ25h dGVkJm5ic3A7cmVjaXBpZW50Jm5ic3A7b25seSZuYnNwO2FuZCZuYnNwO21heTxicj4NCmNvbnRh aW4mbmJzcDtwcml2aWxlZ2VkLCZuYnNwO3Byb3ByaWV0YXJ5LCZuYnNwO29yJm5ic3A7b3RoZXJ3 aXNlJm5ic3A7cHJpdmF0ZSZuYnNwO2luZm9ybWF0aW9uLiZuYnNwOyZuYnNwOzxicj4NCklmJm5i c3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7aXQmbmJzcDtpbiZuYnNwO2Vycm9y LCZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO3NlbmRlcjxicj4NCmltbWVk aWF0ZWx5Jm5ic3A7YW5kJm5ic3A7ZGVsZXRlJm5ic3A7dGhlJm5ic3A7b3JpZ2luYWwuJm5ic3A7 Jm5ic3A7QW55Jm5ic3A7dW5hdXRob3JpemVkJm5ic3A7dXNlJm5ic3A7b2Y8YnI+DQp0aGlzJm5i c3A7ZW1haWwmbmJzcDtpcyZuYnNwO3Byb2hpYml0ZWQuPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KW21mMl08L3RkPjwvdHI+PC90YWJsZT48L2JvZHk+ DQoNCjwvaHRtbD4NCg== ------_=_NextPart_001_01CA0F59.7CC93854-- From alexander.mayrhofer@nic.at Tue Jul 28 01:16:37 2009 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 082353A6B7D for ; Tue, 28 Jul 2009 01:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.936 X-Spam-Level: X-Spam-Status: No, score=-8.936 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, 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 HxmT6hzwcYqX for ; Tue, 28 Jul 2009 01:16:36 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id CB2D73A6B70 for ; Tue, 28 Jul 2009 01:16:35 -0700 (PDT) Received: from localhost [127.0.0.1] by mail.sbg.nic.at with XWall v3.44 ; Tue, 28 Jul 2009 10:16:35 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 28 Jul 2009 10:16:36 +0200 Message-ID: <8BC845943058D844ABFC73D2220D46650876F4BE@nics-mail.sbg.nic.at> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Agenda is changing - need feedback and slides Thread-Index: AcoEWDkry5gceNuaTmufX++f5S1pYQKZnuRgACachFAAAJ8O8A== References: <02a801ca09e2$ff25b2c0$e800a8c0@GunnarH><8C837214C95C864C9F34F3635C2A65750D7E23EF@SEA-EXCHVS-2.telecomsys.com> From: "Alexander Mayrhofer" To: "Thomson, Martin" , "Roger Marshall" , "Ecrit@Ietf. Org" X-XWALL-BCKS: auto Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [Ecrit] Agenda is changing - need feedback and slides 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, 28 Jul 2009 08:16:37 -0000 > I really don't need (or want) 15 minutes. Cullen raised a=20 > very small issue, we resolved it and I'll just need to get a=20 > confirmation. Maybe we can get more out of discussing=20 > trustworthy location. >=20 > =20 >=20 > I'll also note that Karl-Heinz isn't here (or I haven't seen him). I'm prepared to talk about the service list boundaries draft - Karl Heinz has briefed me, and we have slides for it. Alex From mlinsner@cisco.com Tue Jul 28 03:19:10 2009 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 BFF023A69D5 for ; Tue, 28 Jul 2009 03:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=0.699, 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 kk+5PWqosf4y for ; Tue, 28 Jul 2009 03:19:10 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id F272A3A69CD for ; Tue, 28 Jul 2009 03:19:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADhtbkpAZnmf/2dsb2JhbAC6S4gnj0AFgjeBVQ X-IronPort-AV: E=Sophos;i="4.43,282,1246838400"; d="scan'208";a="40134232" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 28 Jul 2009 10:19:11 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6SAJAkl013958; Tue, 28 Jul 2009 06:19:10 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6SAJAsk028657; Tue, 28 Jul 2009 10:19:10 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 06:19:10 -0400 Received: from [192.168.1.143] ([10.61.103.55]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 06:19:09 -0400 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 28 Jul 2009 12:19:08 +0200 From: Marc Linsner To: Brian Rosen , Message-ID: Thread-Topic: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-13.txt Thread-Index: AcoO39zl4BsVe/S6T9yyS2qj9Z0FhQAGaKXwABzWAmo= In-Reply-To: <008501ca0ef9$cb02e2d0$6108a870$@net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Jul 2009 10:19:09.0932 (UTC) FILETIME=[D8A902C0:01CA0F6C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2413; t=1248776350; x=1249640350; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20I-D=20Action=3Adraft-ietf-ecr it-phonebcp-13.txt |Sender:=20 |To:=20Brian=20Rosen=20,=20; bh=qFlNAx6V5hIMx2rbCUrtg9/Fkr07QjRRV312IxxTaGw=; b=pfGYzINQDxeKz0ipoYk2t/w2S1UYmB+gGncIaMPithJw2FCl0jA0GAXEty V3oQlNCB/nGpnMS16hGzIAB+UG+YngxYXimWm03LfAGVpfjaBYmfgMnUZI+E ftynvI/OR7; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-13.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, 28 Jul 2009 10:19:10 -0000 Brian, The location conveyance reference in PhoneBCP and Framework is: draft-ietf-sip-location-conveyance-13 Shouldn't it be: http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance-01 I guess I don't understand if the reference to the old wg draft will continue to be updated....I assume not. IOW, old wg -13 isn't the same as new wg -01...??? -Marc- On 7/27/09 10:35 PM, "Brian Rosen" wrote: > This update fixes idnits. > > Note that there is a problem with the "Intended Status" of > -location-conveyance, which is PS. The tools don't recognize the status > because it says "Standards Track (PS)" and not simply "Standards Track", and > assume Informational. Therefore we can ignore the error generated by > idnits. > > Brian > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Internet-Drafts@ietf.org >> Sent: Monday, July 27, 2009 1:30 PM >> To: i-d-announce@ietf.org >> Cc: ecrit@ietf.org >> Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-13.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Emergency Context Resolution with >> Internet Technologies Working Group of the IETF. >> >> >> Title : Best Current Practice for Communications >> Services in support of Emergency Calling >> Author(s) : B. Rosen, J. Polk >> Filename : draft-ietf-ecrit-phonebcp-13.txt >> Pages : 45 >> Date : 2009-07-27 >> >> The IETF and other standards organization have efforts targeted at >> standardizing various aspects of placing emergency calls on IP >> networks. This memo describes best current practice on how devices, >> networks and services should use such standards to make emergency >> calls. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-13.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From jmpolk@cisco.com Tue Jul 28 03:33:32 2009 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 817C03A6DB9 for ; Tue, 28 Jul 2009 03:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 14W36KJcyoGm for ; Tue, 28 Jul 2009 03:33:31 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 673983A6CDA for ; Tue, 28 Jul 2009 03:33:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIGAPdwbkqrR7O6/2dsb2JhbACIR7INiCePQgWCN4FVg10 X-IronPort-AV: E=Sophos;i="4.43,282,1246838400"; d="scan'208";a="220034495" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 28 Jul 2009 10:33:20 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6SAXKVY025685; Tue, 28 Jul 2009 03:33:20 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n6SAXKVN018186; Tue, 28 Jul 2009 10:33:20 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 03:33:20 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.11.121]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 03:33:19 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 28 Jul 2009 05:33:12 -0500 To: "Roger Marshall" , "Ecrit@Ietf. Org" From: "James M. Polk" In-Reply-To: <8C837214C95C864C9F34F3635C2A65750D7E23EF@SEA-EXCHVS-2.tele comsys.com> References: <02a801ca09e2$ff25b2c0$e800a8c0@GunnarH> <8C837214C95C864C9F34F3635C2A65750D7E23EF@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 28 Jul 2009 10:33:19.0631 (UTC) FILETIME=[D31EC9F0:01CA0F6E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3101; t=1248777200; x=1249641200; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Agenda=20is=20changing=20-=20 need=20feedback=20and=20slides |Sender:=20; bh=bdCRQVjmLKSi/3i1725qN+tUx4xKljJjW08NvnDPmzU=; b=ajitTuqhfX5iiG2bJeIgFWVSRrcW9SyVrTdzOfwAuSFevrqjug5cSHpM1n NljJdHqtw0+CiIaeJcynD2JPpb4/RSVMRYo85rZkoCnSScUjBTXknMkyaL44 cHcZjXQY9C; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [Ecrit] Agenda is changing - need feedback and slides 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, 28 Jul 2009 10:33:32 -0000 Roger I just noticed that my ID on a new URN for geocoding is not on the agenda, yet I have a message from Hannes saying I was put on the agenda. Can you clarify/confirm one way or the other? James At 02:45 PM 7/27/2009, Roger Marshall wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01CA0EF2.D655AD6C" > >Since Henning and Hannes weren't able to attend this IETF, we need >to decide what to do with a few drafts. > >Of the following consolidated agenda, I need slides from the >presenters soon, and no later than 12 noon tomorrow (Tues). > >Emergency Context Resolution with Internet Technologies (ecrit) >WEDNESDAY, July 29, 2009 >0900-1130 Morning Session I > >* Status Update (Chairs, 15 min) >* Specifying Holes in LoST Service Boundaries (Martin, 15 min) >* IANA Registering a SIP RPH Namespace for Local Emergency >Communications (James, 10 min) >* Using Imprecise Location for Emergency Context Resolution (Richard, 10 min) > >* Policy for defining new service-identifying labels (Henning, 15 min) >* Location-to-Service Translation Protocol (LoST) Extension: >ServiceListBoundary (Karl-Heinz, 10 min) >* Extensions to the Emergency Services Architecture for dealing with >Unauthenticated and Unauthorized Devices (Dirk, 15 min) > >* Marking of Calls initiated by PSAPs (Henning, 15 min) > >* Premature Disconnect Indication (Henning, 15 min) >* Trustworthy Location Information (Bernard, 15 min) >* Real-time text activities relevant for ECRIT (Gunnar, 15 min) > >Brian has agreed to present in place of Henning for: > >* Premature Disconnect Indication (Henning, 15 min) >http://tools.ietf.org/html/draft-rosen-ecrit-premature-disconnect-rqmts > > >The other two presentations we will cancel. > >* Policy for defining new service-identifying labels (Henning, 15 min) >http://tools.ietf.org/id/draft-forte-ecrit-service-urn-policy > > >* Marking of Calls initiated by PSAPs (Henning, 15 min) >http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-00.txt > >If anyone needs more time than presently allotted, let Marc & I know quick. > >thanks. > >Roger Marshall/Marc Linsner > > >CONFIDENTIALITY NOTICE: The information contained in this message >may be privileged and/or confidential. If you are not the intended >recipient, or responsible for delivering this message to the >intended recipient, any review, forwarding, dissemination, >distribution or copying of this communication or any attachment(s) >is strictly prohibited. If you have received this message in error, >please notify the sender immediately, and delete it and all >attachments from your computer and network. >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From jmpolk@cisco.com Tue Jul 28 04:17:05 2009 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 84F263A6DC4 for ; Tue, 28 Jul 2009 04:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 kqQXHG5rgFgJ for ; Tue, 28 Jul 2009 04:17:04 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7917B3A6CF3 for ; Tue, 28 Jul 2009 04:17:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIGAAt7bkqrR7O6/2dsb2JhbACIR7IXiCePSwWCN4FV X-IronPort-AV: E=Sophos;i="4.43,282,1246838400"; d="scan'208";a="355416834" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 28 Jul 2009 11:17:06 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6SBH638019822; Tue, 28 Jul 2009 04:17:06 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6SBH5o2011456; Tue, 28 Jul 2009 11:17:05 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 04:17:05 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.11.121]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 04:17:04 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 28 Jul 2009 06:16:58 -0500 To: Marc Linsner , Brian Rosen , From: "James M. Polk" In-Reply-To: References: <008501ca0ef9$cb02e2d0$6108a870$@net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 28 Jul 2009 11:17:05.0045 (UTC) FILETIME=[EFFD2C50:01CA0F74] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2788; t=1248779826; x=1249643826; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20I-D=20Action=3Adraft-ietf-ecr it-phonebcp-13.txt |Sender:=20; bh=cusb0dTRnoC/BNHQTi8cladd1fiVxd6Am2walO3hbjk=; b=lY1UXRCUR3s+AAR2PFDzweP6wnEnjvUf9g9DB+N16mIy7MnWttl37UXD5R y2Xu3Ef5OqcPb+tUPPBxnoRmVINFiKmako4RD9ViQc+K9znbRXQlqkalF2g/ +FOT1K47cT; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-13.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, 28 Jul 2009 11:17:05 -0000 At 05:19 AM 7/28/2009, Marc Linsner wrote: >Brian, > >The location conveyance reference in PhoneBCP and Framework is: > >draft-ietf-sip-location-conveyance-13 > >Shouldn't it be: > >http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance-01 good catch Marc -- this SIPCORE ID is the right reference for Conveyance >I guess I don't understand if the reference to the old wg draft will >continue to be updated....I assume not. IOW, old wg -13 isn't the same as >new wg -01...??? > >-Marc- > > >On 7/27/09 10:35 PM, "Brian Rosen" wrote: > > > This update fixes idnits. > > > > Note that there is a problem with the "Intended Status" of > > -location-conveyance, which is PS. The tools don't recognize the status > > because it says "Standards Track (PS)" and not simply "Standards > Track", and > > assume Informational. Therefore we can ignore the error generated by > > idnits. > > > > Brian > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >> Of Internet-Drafts@ietf.org > >> Sent: Monday, July 27, 2009 1:30 PM > >> To: i-d-announce@ietf.org > >> Cc: ecrit@ietf.org > >> Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-13.txt > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> This draft is a work item of the Emergency Context Resolution with > >> Internet Technologies Working Group of the IETF. > >> > >> > >> Title : Best Current Practice for Communications > >> Services in support of Emergency Calling > >> Author(s) : B. Rosen, J. Polk > >> Filename : draft-ietf-ecrit-phonebcp-13.txt > >> Pages : 45 > >> Date : 2009-07-27 > >> > >> The IETF and other standards organization have efforts targeted at > >> standardizing various aspects of placing emergency calls on IP > >> networks. This memo describes best current practice on how devices, > >> networks and services should use such standards to make emergency > >> calls. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-13.txt > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> Below is the data which will enable a MIME compliant mail reader > >> implementation to automatically retrieve the ASCII version of the > >> Internet-Draft. > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Tue Jul 28 04:34:11 2009 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 9AF733A6AC8 for ; Tue, 28 Jul 2009 04:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdRC37DnfcQ1 for ; Tue, 28 Jul 2009 04:34:10 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 769973A6E76 for ; Tue, 28 Jul 2009 04:33:40 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MVkw0-0008J3-BF; Tue, 28 Jul 2009 06:33:36 -0500 From: "Brian Rosen" To: "'James M. Polk'" , "'Marc Linsner'" , References: <008501ca0ef9$cb02e2d0$6108a870$@net> In-Reply-To: Date: Tue, 28 Jul 2009 07:33:31 -0400 Message-ID: <005a01ca0f77$41542980$c3fc7c80$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoPdO9d0dDMdIdLTj+b4ScNYM4ZEgAAj7Eg Content-Language: en-us 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] I-D Action:draft-ietf-ecrit-phonebcp-13.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, 28 Jul 2009 11:34:11 -0000 Okay, I'll change it, but for the purposes of IESG review, it's okay. Brian > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Tuesday, July 28, 2009 7:17 AM > To: Marc Linsner; Brian Rosen; ecrit@ietf.org > Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-13.txt > > At 05:19 AM 7/28/2009, Marc Linsner wrote: > >Brian, > > > >The location conveyance reference in PhoneBCP and Framework is: > > > >draft-ietf-sip-location-conveyance-13 > > > >Shouldn't it be: > > > >http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance-01 > > good catch Marc -- this SIPCORE ID is the right reference for > Conveyance > > > >I guess I don't understand if the reference to the old wg draft will > >continue to be updated....I assume not. IOW, old wg -13 isn't the > same as > >new wg -01...??? > > > >-Marc- > > > > > >On 7/27/09 10:35 PM, "Brian Rosen" wrote: > > > > > This update fixes idnits. > > > > > > Note that there is a problem with the "Intended Status" of > > > -location-conveyance, which is PS. The tools don't recognize the > status > > > because it says "Standards Track (PS)" and not simply "Standards > > Track", and > > > assume Informational. Therefore we can ignore the error generated > by > > > idnits. > > > > > > Brian > > > > > >> -----Original Message----- > > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > > >> Of Internet-Drafts@ietf.org > > >> Sent: Monday, July 27, 2009 1:30 PM > > >> To: i-d-announce@ietf.org > > >> Cc: ecrit@ietf.org > > >> Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-13.txt > > >> > > >> A New Internet-Draft is available from the on-line Internet-Drafts > > >> directories. > > >> This draft is a work item of the Emergency Context Resolution with > > >> Internet Technologies Working Group of the IETF. > > >> > > >> > > >> Title : Best Current Practice for Communications > > >> Services in support of Emergency Calling > > >> Author(s) : B. Rosen, J. Polk > > >> Filename : draft-ietf-ecrit-phonebcp-13.txt > > >> Pages : 45 > > >> Date : 2009-07-27 > > >> > > >> The IETF and other standards organization have efforts targeted at > > >> standardizing various aspects of placing emergency calls on IP > > >> networks. This memo describes best current practice on how > devices, > > >> networks and services should use such standards to make emergency > > >> calls. > > >> > > >> A URL for this Internet-Draft is: > > >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp- > 13.txt > > >> > > >> Internet-Drafts are also available by anonymous FTP at: > > >> ftp://ftp.ietf.org/internet-drafts/ > > >> > > >> Below is the data which will enable a MIME compliant mail reader > > >> implementation to automatically retrieve the ASCII version of the > > >> Internet-Draft. > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit From mlinsner@cisco.com Tue Jul 28 06:26:14 2009 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 8F4E63A6F38 for ; Tue, 28 Jul 2009 06:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.318 X-Spam-Level: X-Spam-Status: No, score=-5.318 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VujFrkKxLkWt for ; Tue, 28 Jul 2009 06:26:07 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A82303A6ADD for ; Tue, 28 Jul 2009 06:26:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAEeZbkpAZnmf/2dsb2JhbACCJS+WE6J+iCePYQWCN4FV X-IronPort-AV: E=Sophos;i="4.43,283,1246838400"; d="scan'208,217";a="52041550" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 28 Jul 2009 13:26:07 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6SDQ7Tp016575 for ; Tue, 28 Jul 2009 09:26:07 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6SDQ7YQ004077 for ; Tue, 28 Jul 2009 13:26:07 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 09:26:07 -0400 Received: from [10.43.1.100] ([10.61.70.35]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 09:26:03 -0400 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 28 Jul 2009 15:25:59 +0200 From: Marc Linsner To: "'ecrit'" Message-ID: Thread-Topic: Proto for Framework.... Thread-Index: AcoPhvHJ0vNpd09150OfeBk8Xx0adQ== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3331639563_1067890" X-OriginalArrivalTime: 28 Jul 2009 13:26:04.0150 (UTC) FILETIME=[F4DAE160:01CA0F86] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=18402; t=1248787567; x=1249651567; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Proto=20for=20Framework.... |Sender:=20 |To:=20=22'ecrit'=22=20; bh=KC5NOeporchFKLLKvSEIbTb2nCsofGcqrjb8MGqtcK0=; b=rVcS8P65aXlCS/JyVFu4lWXkg5GKYHFqu1IonzZF+rR8FsLO09NhCSdG+f Zcda9Jx5qE8UJDBT2eTV+OBWEzRWcZgT9mCpLyxX+xKTYKIvo/zn8UM7EGzO hQvuMVtUM/; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [Ecrit] Proto for Framework.... 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, 28 Jul 2009 13:26:14 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3331639563_1067890 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Proto for draft-ietf-ecrit-framework http://tools.ietf.org/html/draft-ietf-ecrit-framework-10 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Marc Linsner (mlinsner@cisco.com) - Yes, this version is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has had multiple WG reviews from key WG members. This document was vetted via the Emergency Services Workshop at several of it=B9s meetings. Organizations participating include: 3GPP, 3GPP2, ETSI EMTEL, NENA, IEEE, EENA, etc. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? No further review required. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No specific concerns about this document. No known IPR has been filed nor discussed. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? While there has been some past controversy around some of the exact wording in this document, there is overall WG consensus that this document - in its present form - should be published. The WG as a whole has been working on the document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No known threats for an appeal. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. There are no ID-NITs in this document. There is one informative reference that points to an old SIP document (draft-ietf-sip-location-conveyance-13). This will be changed to point to the current sipcore document with the next version. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. This is a framework document, therefore all references are informative. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? No IANA considerations for this document are required. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? This document is a BCP, no protocol validation required. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. =B3The IETF has standardized various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities.=B2 --B_3331639563_1067890 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Proto for Framework.... Proto for draft-ietf-ecrit-framework

http://tools.ietf.org/html/draft-ietf-ecrit-framework-10

   (1.a)  Who is the Document Shepherd for this documen= t?  Has the
          Document Shephe= rd personally reviewed this version of the
          document and, i= n particular, does he or she believe this
          version is read= y for forwarding to the IESG for publication?

Marc Linsner (mlinsne= r@cisco.com) - Yes, this version is ready for publication.

   (1.b)  Has the document had adequate review both fro= m key WG members
          and from key no= n-WG members?  Does the Document Shepherd have
          any concerns ab= out the depth or breadth of the reviews that
          have been perfo= rmed?

This document has had multiple WG reviews from key WG members.  This d= ocument was vetted via the Emergency Services Workshop at several of it̵= 7;s meetings.  Organizations participating include: 3GPP, 3GPP2, ETSI E= MTEL, NENA, IEEE, EENA, etc.

   (1.c)  Does the Document Shepherd have concerns that= the document
          needs more revi= ew from a particular or broader perspective,
          e.g., security,= operational complexity, someone familiar with
          AAA, internatio= nalization, or XML?

No further review required.

   (1.d)  Does the Document Shepherd have any specific = concerns or
          issues with thi= s document that the Responsible Area Director
          and/or the IESG= should be aware of?  For example, perhaps he
          or she is uncom= fortable with certain parts of the document, or
          has concerns wh= ether there really is a need for it.  In any
          event, if the W= G has discussed those issues and has indicated
          that it still w= ishes to advance the document, detail those
          concerns here. =  Has an IPR disclosure related to this document
          been filed? &nb= sp;If so, please include a reference to the
          disclosure and = summarize the WG discussion and conclusion on
          this issue.

No specific concerns about this document.  No known IPR has been filed= nor discussed.


   (1.e)  How solid is the WG consensus behind this doc= ument?  Does it
          represent the s= trong concurrence of a few individuals, with
          others being si= lent, or does the WG as a whole understand and
          agree with it?<= BR>
While there has been some past controversy around some of the exact wording= in this document, there is overall WG consensus that this document - in its= present form - should be published. The WG as a whole has been working on t= he document.


   (1.f)  Has anyone threatened an appeal or otherwise = indicated extreme
          discontent? &nb= sp;If so, please summarize the areas of conflict in
          separate email = messages to the Responsible Area Director.  (It
          should be in a = separate email because this questionnaire is
          entered into th= e ID Tracker.)

No known threats for an appeal.


   (1.g)  Has the Document Shepherd personally verified= that the
          document satisf= ies all ID nits?  (See
          http://www.ietf.or= g/ID-Checklist.html and
          http://tools.ietf.or= g/tools/idnits/.)  Boilerplate checks are
          not enough; thi= s check needs to be thorough.  Has the document
          met all formal = review criteria it needs to, such as the MIB
          Doctor, media t= ype, and URI type reviews?  If the document
          does not alread= y indicate its intended status at the top of
          the first page,= please indicate the intended status here.

There are no ID-NITs in this document.  There is one informative refer= ence that points to an old SIP document (draft-ietf-sip-location-conveyance-= 13).  This will be changed to point to the current sipcore document wit= h the next version.


   (1.h)  Has the document split its references into no= rmative and
          informative? &n= bsp;Are there normative references to documents that
          are not ready f= or advancement or are otherwise in an unclear
          state?  If= such normative references exist, what is the
          strategy for th= eir completion?  Are there normative references
          that are downwa= rd references, as described in [RFC3967]= ?  If
          so, list these = downward references to support the Area
          Director in the= Last Call procedure for them [RFC3967].=

This is a framework document, therefore all references are informative.


   (1.i)  Has the Document Shepherd verified that the d= ocument's IANA
          Considerations = section exists and is consistent with the body
          of the document= ?  If the document specifies protocol
          extensions, are= reservations requested in appropriate IANA
          registries? &nb= sp;Are the IANA registries clearly identified?  If
          the document cr= eates a new registry, does it define the
          proposed initia= l contents of the registry and an allocation
          procedure for f= uture registrations?  Does it suggest a
          reasonable name= for the new registry?  See [RFC2434].  If the
          document descri= bes an Expert Review process, has the Document
          Shepherd confer= red with the Responsible Area Director so that
          the IESG can ap= point the needed Expert during IESG Evaluation?

No IANA considerations for this document are required.


   (1.j)  Has the Document Shepherd verified that secti= ons of the
          document that a= re written in a formal language, such as XML
          code, BNF rules= , MIB definitions, etc., validate correctly in
          an automated ch= ecker?

This document is a BCP, no protocol validation required.


   (1.k)  The IESG approval announcement includes a Doc= ument
          Announcement Wr= ite-Up.  Please provide such a Document
          Announcement Wr= ite-Up.  Recent examples can be found in the
          "Action&qu= ot; announcements for approved documents.  The approval
          announcement co= ntains the following sections:

          Technical Summa= ry
            &nb= sp;Relevant content can frequently be found in the abstract
            &nb= sp;and/or introduction of the document.  If not, this may be
            &nb= sp;an indication that there are deficiencies in the abstract
            &nb= sp;or introduction.


“The IETF has standardized various aspects of placing emergency calls= . This document describes how all of those component parts are used to suppo= rt emergency calls from citizens and visitors to authorities.”
 --B_3331639563_1067890-- From mlinsner@cisco.com Tue Jul 28 06:27:07 2009 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 A6C8D3A6ADD for ; Tue, 28 Jul 2009 06:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.302 X-Spam-Level: X-Spam-Status: No, score=-5.302 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id op3qqVjkTsG3 for ; Tue, 28 Jul 2009 06:26:57 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D34903A6F82 for ; Tue, 28 Jul 2009 06:26:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAPqZbkpAZnme/2dsb2JhbACCJS+WE6MEiCePYQWCN4FV X-IronPort-AV: E=Sophos;i="4.43,283,1246838400"; d="scan'208,217";a="52088924" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 28 Jul 2009 13:26:57 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6SDQvSt009416 for ; Tue, 28 Jul 2009 09:26:57 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6SDQveW000795 for ; Tue, 28 Jul 2009 13:26:57 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 09:26:57 -0400 Received: from [10.43.1.100] ([10.61.70.35]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 09:26:53 -0400 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 28 Jul 2009 15:26:47 +0200 From: Marc Linsner To: "'ecrit'" Message-ID: Thread-Topic: Proto for PhoneBCP Thread-Index: AcoPhw5lp3/iB2Y+IkiTQm1autA0Sg== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3331639613_1049781" X-OriginalArrivalTime: 28 Jul 2009 13:26:54.0148 (UTC) FILETIME=[12A7F840:01CA0F87] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=20212; t=1248787617; x=1249651617; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Proto=20for=20PhoneBCP |Sender:=20 |To:=20=22'ecrit'=22=20; bh=ktlxHl1upRQBllOaAwTvm43gV4cOOhp7n4oRmAdNHU8=; b=lnDDyDigIiO9wgHd+bkfVPkC0vPmCSYkft3EBONl6bBJ6K+RVP7jQRlCGz k3lH+0T6yQlsI33INjEm1xYu0hD/wYkO4F1zC+udvhfmrEnBQjhb4Kr/IG/B 0x/2BTpY7c; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Ecrit] Proto for 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, 28 Jul 2009 13:27:07 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3331639613_1049781 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Proto for draft-ietf-ecrit-phonebcp http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-13 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Marc Linsner (mlinsner@cisco.com) - Yes, this version is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has had multiple WG reviews from key WG members. This document was vetted via the Emergency Services Workshop at of it=B9s several meetings. Organizations participating include: 3GPP, 3GPP2, ETSI EMTEL, NENA, IEEE, EENA, etc. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? No further review required. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No specific concerns about this document. No known IPR has been filed nor discussed. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? While there has been some past controversy around some of the exact wording in this document, there is overall wg consensus that this document - in its present form - should be published. The WG as a whole has been working on the document. The last remaining issue was a discussion titled =8CApplicability Statement=B9. Text was submitted and rejected by the WG. See: http://www.ietf.org/mail-archive/web/ecrit/current/msg06434.html (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No known threats for an appeal. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. One reference is wrongly identified with id-nits as informational, it=B9s actually Standards Track, hence we ignored this idnits warning. All other idnits have been resolved. There is one reference that points to an old SI= P document (draft-ietf-sip-location-conveyance-13). This will be changed to point to the current sipcore document with the next version. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split into Informative and Normative. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? No IANA considerations for this document are required. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? This document is a BCP, no protocol validation required. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. =B3This document describes how access networks, SIP user agents, proxy servers and PSAPs support emergency calling, as outlined in [I-D.ietf-ecrit-framework], which is designed to complement the present document in section headings, numbering and content. This BCP succinctly describes the requirements of end devices and applications, access networks (including enterprise access networks), service providers and PSAPs to achieve globally interoperable emergency calling on the Internet. This document also defines requirements for "Intermediate" devices which exist between end devices or applications and the access network. For example, a home router is an "Intermediate" device.=B2 --B_3331639613_1049781 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Proto for PhoneBCP Proto for draft-ietf-ecrit-phonebcp

http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-13<= BR>
   (1.a)  Who is the Document Shepherd for this documen= t?  Has the
          Document Shephe= rd personally reviewed this version of the
          document and, i= n particular, does he or she believe this
          version is read= y for forwarding to the IESG for publication?

Marc Linsner (mlinsne= r@cisco.com) - Yes, this version is ready for publication.

   (1.b)  Has the document had adequate review both fro= m key WG members
          and from key no= n-WG members?  Does the Document Shepherd have
          any concerns ab= out the depth or breadth of the reviews that
          have been perfo= rmed?

This document has had multiple WG reviews from key WG members.  This d= ocument was vetted via the Emergency Services Workshop at of it’s seve= ral meetings.  Organizations participating include: 3GPP, 3GPP2, ETSI E= MTEL, NENA, IEEE, EENA, etc.

   (1.c)  Does the Document Shepherd have concerns that= the document
          needs more revi= ew from a particular or broader perspective,
          e.g., security,= operational complexity, someone familiar with
          AAA, internatio= nalization, or XML?

No further review required.

   (1.d)  Does the Document Shepherd have any specific = concerns or
          issues with thi= s document that the Responsible Area Director
          and/or the IESG= should be aware of?  For example, perhaps he
          or she is uncom= fortable with certain parts of the document, or
          has concerns wh= ether there really is a need for it.  In any
          event, if the W= G has discussed those issues and has indicated
          that it still w= ishes to advance the document, detail those
          concerns here. =  Has an IPR disclosure related to this document
          been filed? &nb= sp;If so, please include a reference to the
          disclosure and = summarize the WG discussion and conclusion on
          this issue.

No specific concerns about this document.  No known IPR has been filed= nor discussed.


   (1.e)  How solid is the WG consensus behind this doc= ument?  Does it
          represent the s= trong concurrence of a few individuals, with
          others being si= lent, or does the WG as a whole understand and
          agree with it?<= BR>
While there has been some past controversy around some of the exact wording= in this document, there is overall wg consensus that this document - in its= present form - should be published. The WG as a whole has been working on t= he document.
The last remaining issue was a discussion titled ‘Applicability State= ment’.  Text was submitted and rejected by the WG.  See: http= ://www.ietf.org/mail-archive/web/ecrit/current/msg06434.html

   (1.f)  Has anyone threatened an appeal or otherwise = indicated extreme
          discontent? &nb= sp;If so, please summarize the areas of conflict in
          separate email = messages to the Responsible Area Director.  (It
          should be in a = separate email because this questionnaire is
          entered into th= e ID Tracker.)

No known threats for an appeal.


   (1.g)  Has the Document Shepherd personally verified= that the
          document satisf= ies all ID nits?  (See
          http://www.ietf.or= g/ID-Checklist.html and
          http://tools.ietf.or= g/tools/idnits/.)  Boilerplate checks are
          not enough; thi= s check needs to be thorough.  Has the document
          met all formal = review criteria it needs to, such as the MIB
          Doctor, media t= ype, and URI type reviews?  If the document
          does not alread= y indicate its intended status at the top of
          the first page,= please indicate the intended status here.


One reference is wrongly identified with id-nits as informational, it’= ;s actually Standards Track, hence we ignored this idnits warning.  All= other idnits have been resolved.  There is one reference that points t= o an old SIP document (draft-ietf-sip-location-conveyance-13).  This wi= ll be changed to point to the current sipcore document with the next version= .


   (1.h)  Has the document split its references into no= rmative and
          informative? &n= bsp;Are there normative references to documents that
          are not ready f= or advancement or are otherwise in an unclear
          state?  If= such normative references exist, what is the
          strategy for th= eir completion?  Are there normative references
          that are downwa= rd references, as described in [RFC3967]= ?  If
          so, list these = downward references to support the Area
          Director in the= Last Call procedure for them [RFC3967].=

References are split into Informative and Normative.


   (1.i)  Has the Document Shepherd verified that the d= ocument's IANA
          Considerations = section exists and is consistent with the body
          of the document= ?  If the document specifies protocol
          extensions, are= reservations requested in appropriate IANA
          registries? &nb= sp;Are the IANA registries clearly identified?  If
          the document cr= eates a new registry, does it define the
          proposed initia= l contents of the registry and an allocation
          procedure for f= uture registrations?  Does it suggest a
          reasonable name= for the new registry?  See [RFC2434].  If the
          document descri= bes an Expert Review process, has the Document
          Shepherd confer= red with the Responsible Area Director so that
          the IESG can ap= point the needed Expert during IESG Evaluation?

No IANA considerations for this document are required.


   (1.j)  Has the Document Shepherd verified that secti= ons of the
          document that a= re written in a formal language, such as XML
          code, BNF rules= , MIB definitions, etc., validate correctly in
          an automated ch= ecker?

This document is a BCP, no protocol validation required.


   (1.k)  The IESG approval announcement includes a Doc= ument
          Announcement Wr= ite-Up.  Please provide such a Document
          Announcement Wr= ite-Up.  Recent examples can be found in the
          "Action&qu= ot; announcements for approved documents.  The approval
          announcement co= ntains the following sections:

          Technical Summa= ry
            &nb= sp;Relevant content can frequently be found in the abstract
            &nb= sp;and/or introduction of the document.  If not, this may be
            &nb= sp;an indication that there are deficiencies in the abstract
            &nb= sp;or introduction.


“This document describes how access networks, SIP user agents, proxy =    servers and PSAPs support emergency calling, as outlined i= n [I-D.ietf-ecrit-framework], which is d= esigned to complement the present document in section headings, numbering an= d content.  This BCP succinctly describes the requirements of end devic= es and applications, access networks (including enterprise access networks),= service providers and PSAPs to achieve globally interoperable emergency cal= ling on the Internet.

This document also defines requirements for "Intermediate" device= s which exist between end devices or applications and the access network. &n= bsp;For example, a home router is an "Intermediate" device.”=
--B_3331639613_1049781-- From br@brianrosen.net Tue Jul 28 06:37:03 2009 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 C93A73A6F8A for ; Tue, 28 Jul 2009 06:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 2fHH8qK+u+hd for ; Tue, 28 Jul 2009 06:36:54 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 7D8CB3A6F91 for ; Tue, 28 Jul 2009 06:36:54 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MVmrH-000740-5h; Tue, 28 Jul 2009 08:36:49 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , "'ecrit'" References: In-Reply-To: Date: Tue, 28 Jul 2009 09:36:47 -0400 Message-ID: <00ea01ca0f88$77d88d50$6789a7f0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EB_01CA0F66.F0C6ED50" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoPhvHJ0vNpd09150OfeBk8Xx0adQAATsQA Content-Language: en-us 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] Proto for Framework.... 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, 28 Jul 2009 13:37:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00EB_01CA0F66.F0C6ED50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Framework is Informational, not BCP (1,j) From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Tuesday, July 28, 2009 9:26 AM To: 'ecrit' Subject: [Ecrit] Proto for Framework.... Proto for draft-ietf-ecrit-framework http://tools.ietf.org/html/draft-ietf-ecrit-framework-10 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Marc Linsner (mlinsner@cisco.com) - Yes, this version is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has had multiple WG reviews from key WG members. This document was vetted via the Emergency Services Workshop at several of it's meetings. Organizations participating include: 3GPP, 3GPP2, ETSI EMTEL, NENA, IEEE, EENA, etc. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? No further review required. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No specific concerns about this document. No known IPR has been filed nor discussed. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? While there has been some past controversy around some of the exact wording in this document, there is overall WG consensus that this document - in its present form - should be published. The WG as a whole has been working on the document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No known threats for an appeal. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. There are no ID-NITs in this document. There is one informative reference that points to an old SIP document (draft-ietf-sip-location-conveyance-13). This will be changed to point to the current sipcore document with the next version. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. This is a framework document, therefore all references are informative. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? No IANA considerations for this document are required. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? This document is a BCP, no protocol validation required. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. "The IETF has standardized various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities." ------=_NextPart_000_00EB_01CA0F66.F0C6ED50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Proto for Framework....

Framework is Informational, not BCP = (1,j)

 

From:= = ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner
Sent: Tuesday, July 28, 2009 9:26 AM
To: 'ecrit'
Subject: [Ecrit] Proto for Framework....

 

Proto for draft-ietf-ecrit-framework

http://= tools.ietf.org/html/draft-ietf-ecrit-framework-10

   (1.a)  Who is the Document Shepherd for this = document?  Has the
          Document = Shepherd personally reviewed this version of the
          document = and, in particular, does he or she believe this
          version is = ready for forwarding to the IESG for publication?

Marc Linsner (mlinsner@cisco.com) - Yes, this version is ready for publication.


   (1.b)  Has the document had adequate review both = from key WG members
          and from key = non-WG members?  Does the Document Shepherd have
          any concerns = about the depth or breadth of the reviews that
          have been performed?

This document has had multiple WG reviews from key WG members. =  This document was vetted via the Emergency Services Workshop at several of = it’s meetings.  Organizations participating include: 3GPP, 3GPP2, ETSI = EMTEL, NENA, IEEE, EENA, etc.

   (1.c)  Does the Document Shepherd have concerns = that the document
          needs more = review from a particular or broader perspective,
          e.g., = security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

No further review required.

   (1.d)  Does the Document Shepherd have any = specific concerns or
          issues with = this document that the Responsible Area Director
          and/or the = IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if = the WG has discussed those issues and has indicated
          that it = still wishes to advance the document, detail those
          concerns = here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure = and summarize the WG discussion and conclusion on
          this = issue.

No specific concerns about this document.  No known IPR has been = filed nor discussed.


   (1.e)  How solid is the WG consensus behind this document?  Does it
          represent = the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with = it?

While there has been some past controversy around some of the exact = wording in this document, there is overall WG consensus that this document - in its present form - should be published. The WG as a whole has been working = on the document.


   (1.f)  Has anyone threatened an appeal or = otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate = email messages to the Responsible Area Director.  (It
          should be in = a separate email because this questionnaire is
          entered into = the ID Tracker.)

No known threats for an appeal.


   (1.g)  Has the Document Shepherd personally = verified that the
          document = satisfies all ID nits?  (See
          http://www.ietf.org/ID-Che= cklist.html and
          http://tools.ietf.org/tools/= idnits/.)  Boilerplate checks are
          not enough; = this check needs to be thorough.  Has the document
          met all = formal review criteria it needs to, such as the MIB
          Doctor, = media type, and URI type reviews?  If the document
          does not = already indicate its intended status at the top of
          the first = page, please indicate the intended status here.

There are no ID-NITs in this document.  There is one informative = reference that points to an old SIP document = (draft-ietf-sip-location-conveyance-13).  This will be changed to point to the current sipcore document with = the next version.


   (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not = ready for advancement or are otherwise in an unclear
          state? =  If such normative references exist, what is the
          strategy for = their completion?  Are there normative references
          that are = downward references, as described in [RFC3967]?  If
          so, list = these downward references to support the Area
          Director in = the Last Call procedure for them [RFC3967].

This is a framework document, therefore all references are = informative.


   (1.i)  Has the Document Shepherd verified that = the document's IANA
          Consideration= s section exists and is consistent with the body
          of the = document?  If the document specifies protocol
          extensions, = are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed = initial contents of the registry and an allocation
          procedure = for future registrations?  Does it suggest a
          reasonable = name for the new registry?  See [RFC2434].  If the
          document = describes an Expert Review process, has the Document
          Shepherd = conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

No IANA considerations for this document are required.


   (1.j)  Has the Document Shepherd verified that = sections of the
          document = that are written in a formal language, such as XML
          code, BNF = rules, MIB definitions, etc., validate correctly in
          an automated checker?

This document is a BCP, no protocol validation required.


   (1.k)  The IESG approval announcement includes a Document
          Announcement = Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action&= quot; announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical = Summary
            &= nbsp;Relevant content can frequently be found in the abstract
            &= nbsp;and/or introduction of the document.  If not, this may be
            &= nbsp;an indication that there are deficiencies in the abstract
            &= nbsp;or introduction.


“The IETF has standardized various aspects of placing emergency = calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to = authorities.”

------=_NextPart_000_00EB_01CA0F66.F0C6ED50-- From hardie@qualcomm.com Tue Jul 28 07:46:03 2009 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 61E1D3A6FE3 for ; Tue, 28 Jul 2009 07:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuX6xmK6uppn for ; Tue, 28 Jul 2009 07:46:02 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id D89B53A6DB1 for ; Tue, 28 Jul 2009 07:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1248792363; x=1280328363; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20|References:=20|Date:=20Tue,=2028=20Jul=202009=2016:43:53=20+0200|To: =20Marc=20Linsner=20,=20"'ecrit'"=20< ecrit@ietf.org>|From:=20Ted=20Hardie=20|Subject:=20Re:=20[Ecrit]=20Proto=20for=20PhoneBCP |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5690"=3B=20 a=3D"21344100"; bh=rxNyaqv/+SSKNUcaPng/2cokkcpx39Ih9ft4d558iXI=; b=Fwa/1YZrPVJAhhWnnxEHaG1MFl8sB4ArxqYfrAhJv0NPkjYDxwZKd/yL j1B6O4c0TxavlFo4BLWBBaTxiFzZ0Ocw7JG+BwLOGt4gILQX8y7odzAJY TSkLMEjJzM4ahPNtYbjl4gjHnKJEqVEY8PdOOe0jIbT/KWNPgREn0PWwB U=; X-IronPort-AV: E=McAfee;i="5300,2777,5690"; a="21344100" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jul 2009 07:45:56 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6SEjPv9025250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Jul 2009 07:45:36 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6SEhvos000420 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 Jul 2009 07:44:35 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 28 Jul 2009 07:43:59 -0700 Received: from [78.64.88.113] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 28 Jul 2009 07:43:58 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: References: Date: Tue, 28 Jul 2009 16:43:53 +0200 To: Marc Linsner , "'ecrit'" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Subject: Re: [Ecrit] Proto for 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, 28 Jul 2009 14:46:03 -0000 At 6:26 AM -0700 7/28/09, Marc Linsner wrote: > > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? > >While there has been some past controversy around some of the exact wording in this document, there is overall wg consensus that this document - in its present form - should be published. The WG as a whole has been working on the document. >The last remaining issue was a discussion titled 'Applicability Statement'. Text was submitted and rejected by the WG. See: http://www.ietf.org/mail-archive/web/ecrit/current/msg06434.html > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarize the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) > >No known threats for an appeal. I think it would be valuable to add the history of requests for liaison and the liaisons from 3gpp here. I understand that the current liaison is not very useful, since it simply promises and eventual technical comment, but I think the history here needs to be said. thanks, Ted From br@brianrosen.net Tue Jul 28 07:52:46 2009 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 C805D3A6F17 for ; Tue, 28 Jul 2009 07:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pg2n1VHDUQYL for ; Tue, 28 Jul 2009 07:52:45 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id D47ED3A6E24 for ; Tue, 28 Jul 2009 07:52:45 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MVo2h-0002ts-ID; Tue, 28 Jul 2009 09:52:40 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Marc Linsner'" , "'ecrit'" References: In-Reply-To: Date: Tue, 28 Jul 2009 10:52:42 -0400 Message-ID: <014601ca0f93$11c2f900$3548eb00$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoPkiExtZeqZlyhSoSku0un/4rXjAAAMT7A Content-Language: en-us 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] Proto for 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, 28 Jul 2009 14:52:46 -0000 I'm not at all unhappy with adding the requests for review by 3GPP. Far from it. I wondered if there was any implication of putting your note under the part that says "threat of appeal"? Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Ted Hardie > Sent: Tuesday, July 28, 2009 10:44 AM > To: Marc Linsner; 'ecrit' > Subject: Re: [Ecrit] Proto for PhoneBCP > > At 6:26 AM -0700 7/28/09, Marc Linsner wrote: > > > > (1.e) How solid is the WG consensus behind this document? Does it > > represent the strong concurrence of a few individuals, with > > others being silent, or does the WG as a whole understand > and > > agree with it? > > > >While there has been some past controversy around some of the exact > wording in this document, there is overall wg consensus that this > document - in its present form - should be published. The WG as a whole > has been working on the document. > >The last remaining issue was a discussion titled 'Applicability > Statement'. Text was submitted and rejected by the WG. See: > archive/web/ecrit/current/msg06434.html>http://www.ietf.org/mail- > archive/web/ecrit/current/msg06434.html > > > (1.f) Has anyone threatened an appeal or otherwise indicated > extreme > > discontent? If so, please summarize the areas of conflict > in > > separate email messages to the Responsible Area Director. > (It > > should be in a separate email because this questionnaire is > > entered into the ID Tracker.) > > > >No known threats for an appeal. > > I think it would be valuable to add the history of requests for > liaison and the liaisons from 3gpp here. I understand that the > current liaison is not very useful, since it simply promises and > eventual technical comment, but I think the history here > needs to be said. > > thanks, > Ted > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From jmpolk@cisco.com Tue Jul 28 08:25:24 2009 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 E4C123A7066 for ; Tue, 28 Jul 2009 08:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 8b4gW+-TNANe for ; Tue, 28 Jul 2009 08:25:24 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2C9603A706C for ; Tue, 28 Jul 2009 08:25:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIGAO+0bkqrR7MV/2dsb2JhbACIR7RYiCePeAWEDA X-IronPort-AV: E=Sophos;i="4.43,283,1246838400"; d="scan'208";a="220177843" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 28 Jul 2009 15:25:25 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6SFPPQZ013693; Tue, 28 Jul 2009 08:25:25 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6SFPOI6003458; Tue, 28 Jul 2009 15:25:25 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 08:25:05 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.3.154]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 08:25:05 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 28 Jul 2009 10:25:02 -0500 To: Ted Hardie , Marc Linsner , "'ecrit'" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 28 Jul 2009 15:25:05.0274 (UTC) FILETIME=[954BEDA0:01CA0F97] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1770; t=1248794725; x=1249658725; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Proto=20for=20PhoneBCP |Sender:=20; bh=/5I7Cmz0O/ez75P4shTNzCEfadjdQ1lbIVQhr84lW3k=; b=Nmk6gcirHsdciaBSrWDJMe6/UrEUV+7995VihaV3qlPduyVEqTZVFduVGb ODvb0RWSeSKrIPo5cGrFZPMWs18C3SF+ztWlD5wJHftds2B1HQbp8hYivqQp LQgd8j8zlGgfYtYXXy2mEGrqTKkMSp5iCCFHUEjjUklUyyQSsTEuU=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] Proto for 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, 28 Jul 2009 15:25:25 -0000 At 09:43 AM 7/28/2009, Ted Hardie wrote: >At 6:26 AM -0700 7/28/09, Marc Linsner wrote: > > > > (1.e) How solid is the WG consensus behind this document? Does it > > represent the strong concurrence of a few individuals, with > > others being silent, or does the WG as a whole understand and > > agree with it? > > > >While there has been some past controversy around some of the > exact wording in this document, there is overall wg consensus that > this document - in its present form - should be published. The WG > as a whole has been working on the document. > >The last remaining issue was a discussion titled 'Applicability > Statement'. Text was submitted and rejected by the WG. See: > http://www.ietf.org/mail-archive/web/ecrit/current/msg06434.html > > > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > > discontent? If so, please summarize the areas of conflict in > > separate email messages to the Responsible Area Director. (It > > should be in a separate email because this questionnaire is > > entered into the ID Tracker.) > > > >No known threats for an appeal. > >I think it would be valuable to add the history of requests for >liaison and the liaisons from 3gpp here. I understand that the >current liaison is not very useful, since it simply promises and >eventual technical comment, but I think the history here >needs to be said. +1 > thanks, > Ted >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From hardie@qualcomm.com Tue Jul 28 08:39:31 2009 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 A8E173A70AA for ; Tue, 28 Jul 2009 08:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkjPVeeWJNhT for ; Tue, 28 Jul 2009 08:39:30 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id BAF353A706D for ; Tue, 28 Jul 2009 08:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1248795572; x=1280331572; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<014601ca0f93$11c2f900$35 48eb00$@net>|References:=20=0D=0A=20=0D =0A=20<014601ca0f93$11c2f900$3548eb00$@net>|Date:=20Tue, =2028=20Jul=202009=2017:39:19=20+0200|To:=20Brian=20Rosen =20,=20"'Marc=20Linsner'"=20,=0D=0A=20=20=20=20=20=20=20=20"'ecrit'"=20|From:=20Ted=20Hardie=20 |Subject:=20RE:=20[Ecrit]=20Proto=20for=20PhoneBCP |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5691"=3B=20 a=3D"21347001"; bh=9YJwebu4QSP4TAbtLMowAf1Mu3nDtDvRwuRiEdSeYoc=; b=Vt7axO7aQdIl6KVO56yenojNp1sW2fndgLcSX5q7x19MlTITOrFNKDU0 xA77z/M3rdh2+DJtsW442mGGn1e6k1QcO+W80EYYIIMxaPIQPo+pVVyHZ /ZgVpr56R2WM1ZBciZBjvPdp11XQxy5Wji3o/hpcQFMXJYHBbMCBhtWre I=; X-IronPort-AV: E=McAfee;i="5300,2777,5691"; a="21347001" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jul 2009 08:39:26 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6SFdQFM031511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Jul 2009 08:39:26 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6SFdP4v017808 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 Jul 2009 08:39:25 -0700 (PDT) Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 28 Jul 2009 08:39:25 -0700 Received: from [78.64.88.113] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 28 Jul 2009 08:39:24 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <014601ca0f93$11c2f900$3548eb00$@net> References: <014601ca0f93$11c2f900$3548eb00$@net> Date: Tue, 28 Jul 2009 17:39:19 +0200 To: Brian Rosen , "'Marc Linsner'" , "'ecrit'" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Subject: Re: [Ecrit] Proto for 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, 28 Jul 2009 15:39:31 -0000 At 7:52 AM -0700 7/28/09, Brian Rosen wrote: >I'm not at all unhappy with adding the requests for review by 3GPP. Far from >it. I wondered if there was any implication of putting your note under the >part that says "threat of appeal"? > >Brian It was meant to be a comment related to both sections I quoted, not specific to "threat of appeal". Ted > > -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Ted Hardie >> Sent: Tuesday, July 28, 2009 10:44 AM >> To: Marc Linsner; 'ecrit' >> Subject: Re: [Ecrit] Proto for PhoneBCP >> >> At 6:26 AM -0700 7/28/09, Marc Linsner wrote: >> > >> > (1.e) How solid is the WG consensus behind this document? Does it >> > represent the strong concurrence of a few individuals, with >> > others being silent, or does the WG as a whole understand >> and >> > agree with it? >> > >> >While there has been some past controversy around some of the exact >> wording in this document, there is overall wg consensus that this >> document - in its present form - should be published. The WG as a whole >> has been working on the document. >> >The last remaining issue was a discussion titled 'Applicability >> Statement'. Text was submitted and rejected by the WG. See: >> > archive/web/ecrit/current/msg06434.html>http://www.ietf.org/mail- >> archive/web/ecrit/current/msg06434.html >> >> > (1.f) Has anyone threatened an appeal or otherwise indicated >> extreme >> > discontent? If so, please summarize the areas of conflict >> in >> > separate email messages to the Responsible Area Director. >> (It >> > should be in a separate email because this questionnaire is >> > entered into the ID Tracker.) >> > >> >No known threats for an appeal. >> >> I think it would be valuable to add the history of requests for >> liaison and the liaisons from 3gpp here. I understand that the >> current liaison is not very useful, since it simply promises and >> eventual technical comment, but I think the history here >> needs to be said. >> >> thanks, >> Ted >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit From RMarshall@telecomsys.com Tue Jul 28 13:30:39 2009 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 325363A6ACD for ; Tue, 28 Jul 2009 13:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqPoC3itFKHJ for ; Tue, 28 Jul 2009 13:30:38 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [199.165.246.12]) by core3.amsl.com (Postfix) with ESMTP id 306C63A68B3 for ; Tue, 28 Jul 2009 13:30:38 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Tue, 28 Jul 2009 13:30:38 -0700 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, 28 Jul 2009 13:27:24 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750D7E2CFC@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Agenda is changing - need feedback and slides Thread-Index: AcoPbtUbSPVxdsZWQP+Kj0y5h/hzlQAUr7NQ References: <02a801ca09e2$ff25b2c0$e800a8c0@GunnarH> <8C837214C95C864C9F34F3635C2A65750D7E23EF@SEA-EXCHVS-2.telecomsys.com> From: "Roger Marshall" To: "James M. Polk" , "Ecrit@Ietf. Org" Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [Ecrit] Agenda is changing - need feedback and slides 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, 28 Jul 2009 20:30:39 -0000 James: I conferred with Marc, and he agreed to have it presented. I will add it to the agenda as having 15min. Please send the slides for the URN for Geocoding draft. Thanks. -roger. > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: Tuesday, July 28, 2009 3:33 AM > To: Roger Marshall; Ecrit@Ietf. Org > Cc: Tschofenig, Hannes (NSN - FI/Espoo) > Subject: Re: [Ecrit] Agenda is changing - need feedback and slides >=20 > Roger >=20 > I just noticed that my ID on a new URN for geocoding is not=20 > on the agenda, yet I have a message from Hannes saying I was=20 > put on the agenda. >=20 > Can you clarify/confirm one way or the other? >=20 > James >=20 > At 02:45 PM 7/27/2009, Roger Marshall wrote: > >Content-class: urn:content-classes:message > >Content-Type: multipart/alternative; > > boundary=3D"----_=3D_NextPart_001_01CA0EF2.D655AD6C" > > > >Since Henning and Hannes weren't able to attend this IETF,=20 > we need to=20 > >decide what to do with a few drafts. > > > >Of the following consolidated agenda, I need slides from the=20 > presenters=20 > >soon, and no later than 12 noon tomorrow (Tues). > > > >Emergency Context Resolution with Internet Technologies (ecrit)=20 > >WEDNESDAY, July 29, 2009 0900-1130 Morning Session I > > > >* Status Update (Chairs, 15 min) > >* Specifying Holes in LoST Service Boundaries (Martin, 15 min) > >* IANA Registering a SIP RPH Namespace for Local Emergency=20 > >Communications (James, 10 min) > >* Using Imprecise Location for Emergency Context Resolution=20 > (Richard,=20 > >10 min) > > >* Policy for defining new service-identifying labels (Henning, 15=20 > > >min) > >* Location-to-Service Translation Protocol (LoST) Extension:=20 > >ServiceListBoundary (Karl-Heinz, 10 min) > >* Extensions to the Emergency Services Architecture for dealing with=20 > >Unauthenticated and Unauthorized Devices (Dirk, 15 min) > > >* Marking of Calls initiated by PSAPs (Henning, 15 min) > > >* Premature Disconnect Indication (Henning, 15 min) > >* Trustworthy Location Information (Bernard, 15 min) > >* Real-time text activities relevant for ECRIT (Gunnar, 15 min) > > > >Brian has agreed to present in place of Henning for: > > > >* Premature Disconnect Indication (Henning, 15 min)=20 > > nnect-rqmt > >s>http://tools.ietf.org/html/draft-rosen-ecrit-premature-disc > onnect-rqm > >ts > > > > > >The other two presentations we will cancel. > > > >* Policy for defining new service-identifying labels=20 > (Henning, 15 min)=20 > > y>http://t > >ools.ietf.org/id/draft-forte-ecrit-service-urn-policy > > > > > >* Marking of Calls initiated by PSAPs (Henning, 15 min)=20 > > ck-00.txt> > >http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-00.txt > > > >If anyone needs more time than presently allotted, let Marc=20 > & I know quick. > > > >thanks. > > > >Roger Marshall/Marc Linsner > > > > > >CONFIDENTIALITY NOTICE: The information contained in this=20 > message may=20 > >be privileged and/or confidential. If you are not the intended=20 > >recipient, or responsible for delivering this message to the=20 > intended=20 > >recipient, any review, forwarding, dissemination, distribution or=20 > >copying of this communication or any attachment(s) is strictly=20 > >prohibited. If you have received this message in error,=20 > please notify=20 > >the sender immediately, and delete it and all attachments from your=20 > >computer and network. > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 From spencer@wonderhamster.org Wed Jul 29 02:31:25 2009 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 026843A6F3B for ; Wed, 29 Jul 2009 02:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.055 X-Spam-Level: X-Spam-Status: No, score=-1.055 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_20=-0.74, 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 xhus2C046ShG for ; Wed, 29 Jul 2009 02:31:18 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 2E2433A6E8C for ; Wed, 29 Jul 2009 02:31:18 -0700 (PDT) Received: from S73602b (dhcp-63fb.meeting.ietf.org [130.129.99.251]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1MW5VE2byk-0000zj; Wed, 29 Jul 2009 05:31:19 -0400 Message-ID: <3BF419D723804339A778280AED3D0AFA@china.huawei.com> From: "Spencer Dawkins" To: "ECRIT" Date: Wed, 29 Jul 2009 11:31:10 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_054F_01CA1040.127417F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1/965MRfhVeQsMiQ/oFDaAYw47ywtxtOwwAo2T IWuZ+QTa9AkaiApqJEz8fXcRKJ2+AOqjBcOMYYfq7H3TjeAOvV 1zBMQ4VK8u8cUQPgfOr+SRUbKrUq0uQiMEa5xXscvk= Subject: [Ecrit] Fw: Proposal to add "applicability" statement to-framework/-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: Wed, 29 Jul 2009 09:31:25 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_054F_01CA1040.127417F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I THOUGHT the original suggestion was that the applicability statement = would be in both documents (see below) - my apologies for not noticing = that it was only added in a previous revision of phonebcp ... Spencer ----- Original Message -----=20 From: Rosen, Brian=20 To: ECRIT=20 Sent: Tuesday, March 24, 2009 1:17 AM Subject: [Ecrit] Proposal to add "applicability" statement = to-framework/-phonebcp In the meeting, there was not consensus on having applicability = statements. I would like to propose the following be added to both = documents: =20 This document describes a typical Internet environment where the = endpoint device bears most of the burden of implementing emergency = calls, and the origination network has a minor role. The underlying = specifications permit the network to take a more expansive role in = emergency calls, which Is not covered extensively in this document. -------------------------------------------------------------------------= ------- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------=_NextPart_000_054F_01CA1040.127417F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I THOUGHT the original suggestion was that the = applicability=20 statement would be in both documents (see below) - my apologies for not = noticing=20 that it was only added in a previous revision of phonebcp=20 ...
 
Spencer
 
----- Original Message -----=20
From: Rosen,=20 Brian
To: ECRIT=20
Sent: Tuesday, March 24, 2009 1:17 AM
Subject: [Ecrit] Proposal to add "applicability" statement=20 to-framework/-phonebcp

In the meeting, there was not consensus on  = having=20 applicability statements.  I would like to propose the following be = added=20 to both documents:

 

This document describes a typical Internet = environment where=20 the endpoint device bears most of the burden of implementing emergency = calls,=20 and the origination network has a minor role.  The underlying=20 specifications permit the network to take a more expansive role in = emergency=20 calls, which Is not covered extensively in this = document.

_______________________________________________
Ecrit mailing=20 list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
= ------=_NextPart_000_054F_01CA1040.127417F0-- From brian.rosen@neustar.biz Wed Jul 29 02:32:04 2009 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 ED52F3A6F3B for ; Wed, 29 Jul 2009 02:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czpySQEHps+c for ; Wed, 29 Jul 2009 02:32:04 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id E38863A6F23 for ; Wed, 29 Jul 2009 02:32:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1248859913; x=1248946313; h=From:Date:Subject:Message-ID:Content-class:Content-Type:Content-Transfer-Encod ing; b=KAivSPfyCq0f/3dZsPXwXo6h9kg1ESrswosVLO79/0RJyw7ljFwFYq95A+rG6lz0TRBBUnJthwCsi1 9CZZ8klA== Received: from ([10.31.13.50]) by stihiron1.va.neustar.com with ESMTP id 5202702.20975262; Wed, 29 Jul 2009 05:31:37 -0400 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: Wed, 29 Jul 2009 05:31:29 -0400 Message-ID: <580F3FFD9207B545B48957A92BECEE0A508EB5@STNTEXCH11.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Problem statement for Premature Disconnect Thread-Index: AcoQL1oZuKBSx9XaTT2+vFzbYGen7Q== From: "Rosen, Brian" To: Subject: [Ecrit] Problem statement for Premature Disconnect 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, 29 Jul 2009 09:32:05 -0000 I was asked to reword a problem statement on premature disconnect that might be acceptable to begin work on, probably a design team on requirements. I propose: In emergency calls, people are stressed. They sometimes try to disconnect a call where communication between the caller and the call taker has begun, but before the call taker has acquired enough information to direct appropriate response. That circumstance is known as "premature disconnect". In those circumstances the device should behave differently. For example, the device may alert rather than disconnect. The behavior of the device would be UI driven, and thus not specifiable by the IETF, although advice might be given. =20 Special behavior is not always desirable. For example, in high call volume circumstances, the call may be answered by the PSAP at an IVR, in which case no special behavior is desired. The device may not implement the specification, or for some reason, it may not be available for a particular emergency call. For this reason, some form of signaling at the beginning of the call is needed to negotiate enabling the special behavior. =20 It is desirable that the PSAP be aware that the user has attempted to disconnect/reconnect, and it may be useful for the PSAP to be able to influence the behavior of the device. Some form of signaling for this purpose is desirable, but need not be reliable, since it is advisory. =20 In all circumstances the user must maintain control of his device, and it must be possible for the user to take some action to complete a disconnect. The geopriv work group would complete requirements for handling premature disconnect. Some of the resulting protocol work may need to be accomplished in other RAI work groups.=20 From khwolf1@gmail.com Wed Jul 29 05:01:07 2009 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 3BAC83A7011 for ; Wed, 29 Jul 2009 05:01:07 -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 nOZfgLcr9wyg for ; Wed, 29 Jul 2009 05:01:06 -0700 (PDT) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by core3.amsl.com (Postfix) with ESMTP id 2316A3A7023 for ; Wed, 29 Jul 2009 05:01:05 -0700 (PDT) Received: by bwz21 with SMTP id 21so638161bwz.37 for ; Wed, 29 Jul 2009 05:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=u1kziTzxBWmlDqyOemY1rvpG59450wVGV0scPsm8UoA=; b=cTYIYXuue6daUgXmBp9REkFPyHPYgizVYNm9ZRwqi93483FTeNK/i/5a6YC3pLugR8 34t5TKgWFqYX2TSXXck9BT5U3lC3058qTPB6vaAI0cO/GtPpUeSSgLkc/4dJamFMntO5 dTS0rBR3Djz35Ln0IqCFvJFHCs2vE/o5+WeTU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=UscKxvD1gVJyZL7rwi3akSXeVyZTbs54gw5w2+rc/JQNEFk3Ej176eUKU7WaU8Q+SA 6W9YMBC15yX8mr7YLq34vWYQBNI0XbIr6Y7VwgZAjScbrzc+ynXh2SUMt/j91ieRfhiv ozztRTyNbxgECiPYwFm7VnOuonVtXa3TXWemg= MIME-Version: 1.0 Received: by 10.103.193.10 with SMTP id v10mr4629914mup.126.1248868865338; Wed, 29 Jul 2009 05:01:05 -0700 (PDT) Date: Wed, 29 Jul 2009 14:01:05 +0200 Message-ID: From: Karl Heinz Wolf To: ECRIT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Ecrit] servicelistboundary - discussion in the meeting today 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, 29 Jul 2009 12:01:07 -0000 There was some discussion during the meeting today on my draft http://tools.ietf.org/html/draft-wolf-ecrit-lost-servicelistboundary-01 My main concern is how to ensure that a client never misses a change in available services and consequently learns all location dependent dialstrings for the current location in order to be able to detect an emergency call based on the dialstring. Currently the listServiceByLocation response does not give any information on the area the service list is valid for. So a client might miss a change in the available services, so it won't have the dialstring configured and is not able to detect an emergency call. The problem arises in countries not having a single emergency dialstring, like 911, but having different dialstrings for different services and dialstrings as well as services depend on location. When travelling around, the availability of services may change, as well as the dialstrings. So there needs to be some kind of rule on when to update the service list. Since the service boundary tells when to do a findService again, I thought it would be consistent to introduce another boundary to tell the client when to update the service list (as proposed in the draft). Since I was just listening remotely to the discussion, I'd like to ask if I understood Ted's idea correctly: instead of a boundary indicating the area, the service list is valid for, the LoST Server should also return services that are NOT available at the current location. This would mean: when a client does a findService for urn:service:sos.ambulance for its current location, it would also get back a mapping for urn:service:sos.physician for a different location? So when moving to this other area, the client already knows which services and dialstrings are available there. I'm afraid this approach would just solve the problem in case the LoST Server would dump more or less it's complete database to the client. If the LoST Server would just send a couple of mappings, and others not, the client could still be lost. Besides, traffic and complexity for the client would increase. The servicelistboundary wouldn't increase complexity too much for a client already evaluating the service boundary, since all the necessary functionality should be already in place. On the server side, the complexity should also be manageable (the servicelistboundary could be pre-calculated for the area the server has data for). Please let me know if I missed something in the discussion. karl heinz From Martin.Thomson@andrew.com Wed Jul 29 05:10:38 2009 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 CB54D3A62C1 for ; Wed, 29 Jul 2009 05:10:38 -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 tkxZeGlYHI9k for ; Wed, 29 Jul 2009 05:10:38 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id B3C063A6E92 for ; Wed, 29 Jul 2009 05:10:37 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_29_07_33_11 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 29 Jul 2009 07:33:11 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 07:10:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 29 Jul 2009 07:10:34 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] servicelistboundary - discussion in the meeting today Thread-Index: AcoQREP+dfkh5yH3TLOSxad2UxH4jAAAEdOA References: From: "Thomson, Martin" To: "Karl Heinz Wolf" , "ECRIT" X-OriginalArrivalTime: 29 Jul 2009 12:10:38.0772 (UTC) FILETIME=[95EEBF40:01CA1045] Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting today 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, 29 Jul 2009 12:10:38 -0000 TXkgY29uY2x1c2lvbiBmcm9tIHRoZSBkaXNjdXNzaW9uIHdhcyB0aGF0IFRlZCBoYWQgc29tZSBj b25jZXJucyByZWxhdGluZyB0byB0aGUgY29tYmluYXRvcmlhbCBjb21wbGV4aXR5IGltcGxpZWQg Ynkgd2hhdCBpcyBwcm9wb3NlZC4gIEkgYWxzbyBnb3QgdGhlIGltcHJlc3Npb24gdGhhdCB0aGUg ZG9jdW1lbnQgY291bGQgc3RpbGwgYmUgYWNjZXB0ZWQsIGJ1dCB0aGF0IGlzc3VlIHdvdWxkIG5l ZWQgdG8gYmUgcmVzb2x2ZWQuDQoNCkl0IGFwcGVhcnMgdGhhdCBUZWQncyBhbHRlcm5hdGl2ZSBz b2x1dGlvbiBkb2Vzbid0IHdvcmsgdmVyeSB3ZWxsLCBhcyB5b3Ugc2F5Lg0KDQpNYXliZSBJIGNh biBwcm9wb3NlIHRoYXQgdGhlIGNoYWlycyBhc2sgZm9yIGEpIGNvbnNlbnN1cyBvbiB0aGUgcHJv YmxlbSwgYikgYWRvcHRpb24gb2YgdGhlIGRyYWZ0LiAgV2UgcHJvYmFibHkgc2hvdWxkIGhhdmUg ZG9uZSB0aGF0IGluIHRoZSBtZWV0aW5nLg0KDQpNYXliZSBUZWQgd2lsbCBkaXNhZ3JlZSwgYnV0 IEknbSBzdXJlIHRoYXQgd2UnbGwgYmUgaGVhcmluZyBhbnkgb2JqZWN0aW9ucyBpZiB0aGF0J3Mg dGhlIGNhc2UuDQoNCi0tTWFydGluDQogDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYNCj4gT2YgS2FybCBIZWlueiBXb2xmDQo+IFNlbnQ6IFdlZG5lc2RheSwg MjkgSnVseSAyMDA5IDI6MDEgUE0NCj4gVG86IEVDUklUDQo+IFN1YmplY3Q6IFtFY3JpdF0gc2Vy dmljZWxpc3Rib3VuZGFyeSAtIGRpc2N1c3Npb24gaW4gdGhlIG1lZXRpbmcgdG9kYXkNCj4gDQo+ IFRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24gZHVyaW5nIHRoZSBtZWV0aW5nIHRvZGF5IG9uIG15 IGRyYWZ0DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdvbGYtZWNyaXQtbG9z dC1zZXJ2aWNlbGlzdGJvdW5kYXJ5LTAxDQo+IA0KPiBNeSBtYWluIGNvbmNlcm4gaXMgaG93IHRv IGVuc3VyZSB0aGF0IGEgY2xpZW50IG5ldmVyIG1pc3NlcyBhIGNoYW5nZQ0KPiBpbiBhdmFpbGFi bGUgc2VydmljZXMgYW5kIGNvbnNlcXVlbnRseSBsZWFybnMgYWxsIGxvY2F0aW9uIGRlcGVuZGVu dA0KPiBkaWFsc3RyaW5ncyBmb3IgdGhlIGN1cnJlbnQgbG9jYXRpb24gaW4gb3JkZXIgdG8gYmUg YWJsZSB0byBkZXRlY3QgYW4NCj4gZW1lcmdlbmN5IGNhbGwgYmFzZWQgb24gdGhlIGRpYWxzdHJp bmcuDQo+IEN1cnJlbnRseSB0aGUgbGlzdFNlcnZpY2VCeUxvY2F0aW9uIHJlc3BvbnNlIGRvZXMg bm90IGdpdmUgYW55DQo+IGluZm9ybWF0aW9uIG9uIHRoZSBhcmVhIHRoZSBzZXJ2aWNlIGxpc3Qg aXMgdmFsaWQgZm9yLiBTbyBhIGNsaWVudA0KPiBtaWdodCBtaXNzIGEgY2hhbmdlIGluIHRoZSBh dmFpbGFibGUgc2VydmljZXMsIHNvIGl0IHdvbid0IGhhdmUgdGhlDQo+IGRpYWxzdHJpbmcgY29u ZmlndXJlZCBhbmQgaXMgbm90IGFibGUgdG8gZGV0ZWN0IGFuIGVtZXJnZW5jeSBjYWxsLg0KPiBU aGUgcHJvYmxlbSBhcmlzZXMgaW4gY291bnRyaWVzIG5vdCBoYXZpbmcgYSBzaW5nbGUgZW1lcmdl bmN5DQo+IGRpYWxzdHJpbmcsIGxpa2UgOTExLCBidXQgaGF2aW5nIGRpZmZlcmVudCBkaWFsc3Ry aW5ncyBmb3IgZGlmZmVyZW50DQo+IHNlcnZpY2VzIGFuZCBkaWFsc3RyaW5ncyBhcyB3ZWxsIGFz IHNlcnZpY2VzIGRlcGVuZCBvbiBsb2NhdGlvbi4gV2hlbg0KPiB0cmF2ZWxsaW5nIGFyb3VuZCwg dGhlIGF2YWlsYWJpbGl0eSBvZiBzZXJ2aWNlcyBtYXkgY2hhbmdlLCBhcyB3ZWxsIGFzDQo+IHRo ZSBkaWFsc3RyaW5ncy4gU28gdGhlcmUgbmVlZHMgdG8gYmUgc29tZSBraW5kIG9mIHJ1bGUgb24g d2hlbiB0bw0KPiB1cGRhdGUgdGhlIHNlcnZpY2UgbGlzdC4gU2luY2UgdGhlIHNlcnZpY2UgYm91 bmRhcnkgdGVsbHMgd2hlbiB0byBkbyBhDQo+IGZpbmRTZXJ2aWNlIGFnYWluLCBJIHRob3VnaHQg aXQgd291bGQgYmUgY29uc2lzdGVudCB0byBpbnRyb2R1Y2UNCj4gYW5vdGhlciBib3VuZGFyeSB0 byB0ZWxsIHRoZSBjbGllbnQgd2hlbiB0byB1cGRhdGUgdGhlIHNlcnZpY2UgbGlzdA0KPiAoYXMg cHJvcG9zZWQgaW4gdGhlIGRyYWZ0KS4NCj4gDQo+IFNpbmNlIEkgd2FzIGp1c3QgbGlzdGVuaW5n IHJlbW90ZWx5IHRvIHRoZSBkaXNjdXNzaW9uLCBJJ2QgbGlrZSB0byBhc2sNCj4gaWYgSSB1bmRl cnN0b29kIFRlZCdzIGlkZWEgY29ycmVjdGx5OiBpbnN0ZWFkIG9mIGEgYm91bmRhcnkgaW5kaWNh dGluZw0KPiB0aGUgYXJlYSwgdGhlIHNlcnZpY2UgbGlzdCBpcyB2YWxpZCBmb3IsIHRoZSBMb1NU IFNlcnZlciBzaG91bGQgYWxzbw0KPiByZXR1cm4gc2VydmljZXMgdGhhdCBhcmUgTk9UIGF2YWls YWJsZSBhdCB0aGUgY3VycmVudCBsb2NhdGlvbi4NCj4gVGhpcyB3b3VsZCBtZWFuOiB3aGVuIGEg Y2xpZW50IGRvZXMgYSBmaW5kU2VydmljZSBmb3INCj4gdXJuOnNlcnZpY2U6c29zLmFtYnVsYW5j ZSBmb3IgaXRzIGN1cnJlbnQgbG9jYXRpb24sIGl0IHdvdWxkIGFsc28gZ2V0DQo+IGJhY2sgYSBt YXBwaW5nIGZvciB1cm46c2VydmljZTpzb3MucGh5c2ljaWFuIGZvciBhIGRpZmZlcmVudCBsb2Nh dGlvbj8NCj4gU28gd2hlbiBtb3ZpbmcgdG8gdGhpcyBvdGhlciBhcmVhLCB0aGUgY2xpZW50IGFs cmVhZHkga25vd3Mgd2hpY2gNCj4gc2VydmljZXMgYW5kIGRpYWxzdHJpbmdzIGFyZSBhdmFpbGFi bGUgdGhlcmUuDQo+IEknbSBhZnJhaWQgdGhpcyBhcHByb2FjaCB3b3VsZCBqdXN0IHNvbHZlIHRo ZSBwcm9ibGVtIGluIGNhc2UgdGhlIExvU1QNCj4gU2VydmVyIHdvdWxkIGR1bXAgbW9yZSBvciBs ZXNzIGl0J3MgY29tcGxldGUgZGF0YWJhc2UgdG8gdGhlIGNsaWVudC4NCj4gSWYgdGhlIExvU1Qg U2VydmVyIHdvdWxkIGp1c3Qgc2VuZCBhIGNvdXBsZSBvZiBtYXBwaW5ncywgYW5kIG90aGVycw0K PiBub3QsIHRoZSBjbGllbnQgY291bGQgc3RpbGwgYmUgbG9zdC4NCj4gQmVzaWRlcywgdHJhZmZp YyBhbmQgY29tcGxleGl0eSBmb3IgdGhlIGNsaWVudCB3b3VsZCBpbmNyZWFzZS4gVGhlDQo+IHNl cnZpY2VsaXN0Ym91bmRhcnkgd291bGRuJ3QgaW5jcmVhc2UgY29tcGxleGl0eSB0b28gbXVjaCBm b3IgYSBjbGllbnQNCj4gYWxyZWFkeSBldmFsdWF0aW5nIHRoZSBzZXJ2aWNlIGJvdW5kYXJ5LCBz aW5jZSBhbGwgdGhlIG5lY2Vzc2FyeQ0KPiBmdW5jdGlvbmFsaXR5IHNob3VsZCBiZSBhbHJlYWR5 IGluIHBsYWNlLiBPbiB0aGUgc2VydmVyIHNpZGUsIHRoZQ0KPiBjb21wbGV4aXR5IHNob3VsZCBh bHNvIGJlIG1hbmFnZWFibGUgKHRoZSBzZXJ2aWNlbGlzdGJvdW5kYXJ5IGNvdWxkIGJlDQo+IHBy ZS1jYWxjdWxhdGVkIGZvciB0aGUgYXJlYSB0aGUgc2VydmVyIGhhcyBkYXRhIGZvcikuDQo+IA0K PiBQbGVhc2UgbGV0IG1lIGtub3cgaWYgSSBtaXNzZWQgc29tZXRoaW5nIGluIHRoZSBkaXNjdXNz aW9uLg0KPiANCj4ga2FybCBoZWlueg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhl IGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBw cm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBo YXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVk aWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YN CnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KW21mMl0NCg== From rbarnes@bbn.com Wed Jul 29 05:18:11 2009 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 9AF763A7035 for ; Wed, 29 Jul 2009 05:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 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 N1pIoNVTKE-O for ; Wed, 29 Jul 2009 05:18:10 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 9A3F03A6FF4 for ; Wed, 29 Jul 2009 05:18:10 -0700 (PDT) Received: from [128.89.254.2] (helo=dhcp-14e6.meeting.ietf.org) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1MW86l-0005BV-AY; Wed, 29 Jul 2009 08:18:11 -0400 Message-ID: <4A703E02.4070001@bbn.com> Date: Wed, 29 Jul 2009 14:18:10 +0200 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Karl Heinz Wolf References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ECRIT Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting today 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, 29 Jul 2009 12:18:11 -0000 I agree with Karl Heinz's analysis. Contrasting the two options: service-list-boundary: -- Server has to compute all of the serviceListBoundaries that it can serve. The computational complexity of this operation is O(2^#services) (one polygon per combination of services on/off), which isn't huge as long as #services is reasonably small (and should be significantly lower than that in many cases). -- Client has to make queries only for services that are actually available to it -- Client is aware of when it needs to update its service list. Ted's proposal: -- Client has to make queries for all services that are served by the LoST server, regardless of whether the service is available or not. -- Client is unaware of when it needs to update its service list (since queries for unavailable services will fail) -- Server has to handle more transactions per client, many of which will fail. IMO, service-list-boundary seems like the more straightforward solution. --Richard Karl Heinz Wolf wrote: > There was some discussion during the meeting today on my draft > http://tools.ietf.org/html/draft-wolf-ecrit-lost-servicelistboundary-01 > > My main concern is how to ensure that a client never misses a change > in available services and consequently learns all location dependent > dialstrings for the current location in order to be able to detect an > emergency call based on the dialstring. > Currently the listServiceByLocation response does not give any > information on the area the service list is valid for. So a client > might miss a change in the available services, so it won't have the > dialstring configured and is not able to detect an emergency call. > The problem arises in countries not having a single emergency > dialstring, like 911, but having different dialstrings for different > services and dialstrings as well as services depend on location. When > travelling around, the availability of services may change, as well as > the dialstrings. So there needs to be some kind of rule on when to > update the service list. Since the service boundary tells when to do a > findService again, I thought it would be consistent to introduce > another boundary to tell the client when to update the service list > (as proposed in the draft). > > Since I was just listening remotely to the discussion, I'd like to ask > if I understood Ted's idea correctly: instead of a boundary indicating > the area, the service list is valid for, the LoST Server should also > return services that are NOT available at the current location. > This would mean: when a client does a findService for > urn:service:sos.ambulance for its current location, it would also get > back a mapping for urn:service:sos.physician for a different location? > So when moving to this other area, the client already knows which > services and dialstrings are available there. > I'm afraid this approach would just solve the problem in case the LoST > Server would dump more or less it's complete database to the client. > If the LoST Server would just send a couple of mappings, and others > not, the client could still be lost. > Besides, traffic and complexity for the client would increase. The > servicelistboundary wouldn't increase complexity too much for a client > already evaluating the service boundary, since all the necessary > functionality should be already in place. On the server side, the > complexity should also be manageable (the servicelistboundary could be > pre-calculated for the area the server has data for). > > Please let me know if I missed something in the discussion. > > karl heinz > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From khwolf1@gmail.com Wed Jul 29 05:19:10 2009 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 528DE3A684C for ; Wed, 29 Jul 2009 05:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezYG7Tldiz9A for ; Wed, 29 Jul 2009 05:19:09 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id CD77E3A6D3B for ; Wed, 29 Jul 2009 05:19:08 -0700 (PDT) Received: by fxm18 with SMTP id 18so348308fxm.37 for ; Wed, 29 Jul 2009 05:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IiJXEgvqtjB8XYW0xL3sm+E2Pgc/r4MvaumESDbPJLA=; b=WLeJJYVJMegBoWyykl0ZF+ljyN0oEjY5w+S75ndKdqPiyCYTool3DOGNjz3Jm6whIG CTxj2P9z1jrW6zjRunfJB1JqEkIzil7N0KkkpecOjlRsINJPV2wDyuRTdDOEFASJSoWZ Pv4e3QQ1vl3Hg0p0o8HFecDCy/oZ/l+YQj8Yw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=AfyaOJMdUbA0ZWD9f3RTV01aGC+2Itf868/U1mn37Xo+Fw8ILHMM+kwiyiatd3r94d HtnKC96bSVrUyHymXJCbZUNGvGNQQ8iXHWlKJTinP810yBvRFk1GgTabbfMykiT21m10 DQrd9vdb/9t7rahZt8LKVXweYd4qqzsrP9Ddw= MIME-Version: 1.0 Received: by 10.103.170.4 with SMTP id x4mr732629muo.116.1248869946032; Wed, 29 Jul 2009 05:19:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Jul 2009 14:19:06 +0200 Message-ID: From: Karl Heinz Wolf To: "Thomson, Martin" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ECRIT Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting today 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, 29 Jul 2009 12:19:10 -0000 On Wed, Jul 29, 2009 at 2:10 PM, Thomson, Martin wrote: > My conclusion from the discussion was that Ted had some concerns relating= to the combinatorial complexity implied by what is proposed. =A0I also got= the impression that the document could still be accepted, but that issue w= ould need to be resolved. > regarding the complexity of the resulting boundary information, I tried to explain that in section 3.4.1 of the draft. The calculation of the largest possible area for which the service list stays the same might be a complex task. An alternative would be to return smaller areas that are easier to compute. In such a case some unneeded queries to the LoST server are the consequence, but still the main purpose of the serviceListBoundary is achieved: Never miss a change of available services. So a reasonable trade-off between the effort to generate the boundary information and the saved queries to the LoST server has to be considered. does this make sense? > It appears that Ted's alternative solution doesn't work very well, as you= say. > > Maybe I can propose that the chairs ask for a) consensus on the problem, = b) adoption of the draft. =A0We probably should have done that in the meeti= ng. > I think a) was already asked on the mailinglist: http://www.ietf.org/mail-archive/web/ecrit/current/msg06246.html karl heinz > Maybe Ted will disagree, but I'm sure that we'll be hearing any objection= s if that's the case. > > --Martin > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Karl Heinz Wolf >> Sent: Wednesday, 29 July 2009 2:01 PM >> To: ECRIT >> Subject: [Ecrit] servicelistboundary - discussion in the meeting today >> >> There was some discussion during the meeting today on my draft >> http://tools.ietf.org/html/draft-wolf-ecrit-lost-servicelistboundary-01 >> >> My main concern is how to ensure that a client never misses a change >> in available services and consequently learns all location dependent >> dialstrings for the current location in order to be able to detect an >> emergency call based on the dialstring. >> Currently the listServiceByLocation response does not give any >> information on the area the service list is valid for. So a client >> might miss a change in the available services, so it won't have the >> dialstring configured and is not able to detect an emergency call. >> The problem arises in countries not having a single emergency >> dialstring, like 911, but having different dialstrings for different >> services and dialstrings as well as services depend on location. When >> travelling around, the availability of services may change, as well as >> the dialstrings. So there needs to be some kind of rule on when to >> update the service list. Since the service boundary tells when to do a >> findService again, I thought it would be consistent to introduce >> another boundary to tell the client when to update the service list >> (as proposed in the draft). >> >> Since I was just listening remotely to the discussion, I'd like to ask >> if I understood Ted's idea correctly: instead of a boundary indicating >> the area, the service list is valid for, the LoST Server should also >> return services that are NOT available at the current location. >> This would mean: when a client does a findService for >> urn:service:sos.ambulance for its current location, it would also get >> back a mapping for urn:service:sos.physician for a different location? >> So when moving to this other area, the client already knows which >> services and dialstrings are available there. >> I'm afraid this approach would just solve the problem in case the LoST >> Server would dump more or less it's complete database to the client. >> If the LoST Server would just send a couple of mappings, and others >> not, the client could still be lost. >> Besides, traffic and complexity for the client would increase. The >> servicelistboundary wouldn't increase complexity too much for a client >> already evaluating the service boundary, since all the necessary >> functionality should be already in place. On the server side, the >> complexity should also be manageable (the servicelistboundary could be >> pre-calculated for the area the server has data for). >> >> Please let me know if I missed something in the discussion. >> >> karl heinz >> _______________________________________________ >> 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. =A0Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------= ----------------------- > [mf2] > From Martin.Thomson@andrew.com Wed Jul 29 05:25:21 2009 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 F1D393A7016 for ; Wed, 29 Jul 2009 05:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 3VzkgvAxmm4Z for ; Wed, 29 Jul 2009 05:25:19 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 780F13A6966 for ; Wed, 29 Jul 2009 05:25:19 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_29_07_47_50 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 29 Jul 2009 07:47:50 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 07:25:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 29 Jul 2009 07:25:14 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] servicelistboundary - discussion in the meeting today Thread-Index: AcoQRsYBebCxRgE1QGCXemiO25G5LgAAD+CA References: From: "Thomson, Martin" To: "Karl Heinz Wolf" X-OriginalArrivalTime: 29 Jul 2009 12:25:17.0580 (UTC) FILETIME=[A1BE34C0:01CA1047] Cc: ECRIT Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting today 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, 29 Jul 2009 12:25:21 -0000 T2YgY291cnNlLCBpZiB0aGUgc2VydmVyIGlzIHVuYWJsZSB0byBkbyB0aGUgZnVsbCBjb21wdXRh dGlvbiwgaXQgZG9lcyBub3QgbmVlZCB0byByZXBvcnQgdGhlIGNvbXBsZXRlIGFyZWEgbmVjZXNz YXJ5LiAgDQoNCkl0J3MgTyhuKSByYXRoZXIgdGhhbiBPKDJebikgaXNuJ3QgaXQ/ICBGb3IgZWFj aCBzZXJ2aWNlIHRoYXQgdGhlIHRhcmdldCBjYW4gdXNlIGN1cnJlbnRseSwgYW5kIGdpdmVuIHRo ZSBleHRlbnRzIG9mIHRoZSBzZXJ2aWNlIChmb3VuZCBieSBmb3JtaW5nIHRoZSB1bmlvbiBvZiBh bGwgc2VydmljZSBhcmVhcyAtIGFuIG9wIHRoYXQgY2FuIGJlIHBlcmZvcm1lZCBiZWZvcmVoYW5k KSwgdGhlIGV4dGVudHMgb2YgdGhlIHNlcnZpY2UgbGlzdCBib3VuZGFyeSBhcmUgZm91bmQgYnkg ZmluZGluZyB0aGUgaW50ZXJzZWN0aW9uIG9mIGFsbCB0aGUgYXJlYXMuICBEdXJpbmcgdGhpcyBz dGFnZSwgdGhlIGJvdW5kYXJ5IGZvciBhIHBhcnRpY3VsYXIgc2VydmljZSBjYW4gYmUgc2hydW5r IGlmIHRoYXQgbWFrZXMgaXQgZWFzaWVyLg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogS2FybCBIZWlueiBXb2xmIFttYWlsdG86a2h3b2xmMUBnbWFpbC5jb21dDQo+ IFNlbnQ6IFdlZG5lc2RheSwgMjkgSnVseSAyMDA5IDI6MTkgUE0NCj4gVG86IFRob21zb24sIE1h cnRpbg0KPiBDYzogRUNSSVQNCj4gU3ViamVjdDogUmU6IFtFY3JpdF0gc2VydmljZWxpc3Rib3Vu ZGFyeSAtIGRpc2N1c3Npb24gaW4gdGhlIG1lZXRpbmcNCj4gdG9kYXkNCj4gDQo+IE9uIFdlZCwg SnVsIDI5LCAyMDA5IGF0IDI6MTAgUE0sIFRob21zb24sDQo+IE1hcnRpbjxNYXJ0aW4uVGhvbXNv bkBhbmRyZXcuY29tPiB3cm90ZToNCj4gPiBNeSBjb25jbHVzaW9uIGZyb20gdGhlIGRpc2N1c3Np b24gd2FzIHRoYXQgVGVkIGhhZCBzb21lIGNvbmNlcm5zDQo+IHJlbGF0aW5nIHRvIHRoZSBjb21i aW5hdG9yaWFsIGNvbXBsZXhpdHkgaW1wbGllZCBieSB3aGF0IGlzIHByb3Bvc2VkLg0KPiDCoEkg YWxzbyBnb3QgdGhlIGltcHJlc3Npb24gdGhhdCB0aGUgZG9jdW1lbnQgY291bGQgc3RpbGwgYmUg YWNjZXB0ZWQsDQo+IGJ1dCB0aGF0IGlzc3VlIHdvdWxkIG5lZWQgdG8gYmUgcmVzb2x2ZWQuDQo+ ID4NCj4gDQo+IHJlZ2FyZGluZyB0aGUgY29tcGxleGl0eSBvZiB0aGUgcmVzdWx0aW5nIGJvdW5k YXJ5IGluZm9ybWF0aW9uLCBJDQo+IHRyaWVkIHRvIGV4cGxhaW4gdGhhdCBpbiBzZWN0aW9uIDMu NC4xIG9mIHRoZSBkcmFmdC4NCj4gDQo+ICAgIFRoZSBjYWxjdWxhdGlvbiBvZiB0aGUgbGFyZ2Vz dCBwb3NzaWJsZSBhcmVhIGZvciB3aGljaCB0aGUgc2VydmljZQ0KPiAgICBsaXN0IHN0YXlzIHRo ZSBzYW1lIG1pZ2h0IGJlIGEgY29tcGxleCB0YXNrLiAgQW4gYWx0ZXJuYXRpdmUgd291bGQNCj4g YmUNCj4gICAgdG8gcmV0dXJuIHNtYWxsZXIgYXJlYXMgdGhhdCBhcmUgZWFzaWVyIHRvIGNvbXB1 dGUuICBJbiBzdWNoIGEgY2FzZQ0KPiAgICBzb21lIHVubmVlZGVkIHF1ZXJpZXMgdG8gdGhlIExv U1Qgc2VydmVyIGFyZSB0aGUgY29uc2VxdWVuY2UsIGJ1dA0KPiAgICBzdGlsbCB0aGUgbWFpbiBw dXJwb3NlIG9mIHRoZSBzZXJ2aWNlTGlzdEJvdW5kYXJ5IGlzIGFjaGlldmVkOiBOZXZlcg0KPiAg ICBtaXNzIGEgY2hhbmdlIG9mIGF2YWlsYWJsZSBzZXJ2aWNlcy4gIFNvIGEgcmVhc29uYWJsZSB0 cmFkZS1vZmYNCj4gICAgYmV0d2VlbiB0aGUgZWZmb3J0IHRvIGdlbmVyYXRlIHRoZSBib3VuZGFy eSBpbmZvcm1hdGlvbiBhbmQgdGhlDQo+IHNhdmVkDQo+ICAgIHF1ZXJpZXMgdG8gdGhlIExvU1Qg c2VydmVyIGhhcyB0byBiZSBjb25zaWRlcmVkLg0KPiANCj4gZG9lcyB0aGlzIG1ha2Ugc2Vuc2U/ DQo+IA0KPiA+IEl0IGFwcGVhcnMgdGhhdCBUZWQncyBhbHRlcm5hdGl2ZSBzb2x1dGlvbiBkb2Vz bid0IHdvcmsgdmVyeSB3ZWxsLCBhcw0KPiB5b3Ugc2F5Lg0KPiA+DQo+ID4gTWF5YmUgSSBjYW4g cHJvcG9zZSB0aGF0IHRoZSBjaGFpcnMgYXNrIGZvciBhKSBjb25zZW5zdXMgb24gdGhlDQo+IHBy b2JsZW0sIGIpIGFkb3B0aW9uIG9mIHRoZSBkcmFmdC4gwqBXZSBwcm9iYWJseSBzaG91bGQgaGF2 ZSBkb25lIHRoYXQNCj4gaW4gdGhlIG1lZXRpbmcuDQo+ID4NCj4gDQo+IEkgdGhpbmsgYSkgd2Fz IGFscmVhZHkgYXNrZWQgb24gdGhlIG1haWxpbmdsaXN0Og0KPiANCj4gaHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL2Vjcml0L2N1cnJlbnQvbXNnMDYyNDYuaHRtbA0KPiANCj4g a2FybCBoZWlueg0KPiANCj4gPiBNYXliZSBUZWQgd2lsbCBkaXNhZ3JlZSwgYnV0IEknbSBzdXJl IHRoYXQgd2UnbGwgYmUgaGVhcmluZyBhbnkNCj4gb2JqZWN0aW9ucyBpZiB0aGF0J3MgdGhlIGNh c2UuDQo+ID4NCj4gPiAtLU1hcnRpbg0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4+IEZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1ib3Vu Y2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYNCj4gPj4gT2YgS2FybCBIZWlueiBXb2xmDQo+ID4+ IFNlbnQ6IFdlZG5lc2RheSwgMjkgSnVseSAyMDA5IDI6MDEgUE0NCj4gPj4gVG86IEVDUklUDQo+ ID4+IFN1YmplY3Q6IFtFY3JpdF0gc2VydmljZWxpc3Rib3VuZGFyeSAtIGRpc2N1c3Npb24gaW4g dGhlIG1lZXRpbmcNCj4gdG9kYXkNCj4gPj4NCj4gPj4gVGhlcmUgd2FzIHNvbWUgZGlzY3Vzc2lv biBkdXJpbmcgdGhlIG1lZXRpbmcgdG9kYXkgb24gbXkgZHJhZnQNCj4gPj4gaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtd29sZi1lY3JpdC1sb3N0LQ0KPiBzZXJ2aWNlbGlzdGJvdW5k YXJ5LTAxDQo+ID4+DQo+ID4+IE15IG1haW4gY29uY2VybiBpcyBob3cgdG8gZW5zdXJlIHRoYXQg YSBjbGllbnQgbmV2ZXIgbWlzc2VzIGEgY2hhbmdlDQo+ID4+IGluIGF2YWlsYWJsZSBzZXJ2aWNl cyBhbmQgY29uc2VxdWVudGx5IGxlYXJucyBhbGwgbG9jYXRpb24gZGVwZW5kZW50DQo+ID4+IGRp YWxzdHJpbmdzIGZvciB0aGUgY3VycmVudCBsb2NhdGlvbiBpbiBvcmRlciB0byBiZSBhYmxlIHRv IGRldGVjdA0KPiBhbg0KPiA+PiBlbWVyZ2VuY3kgY2FsbCBiYXNlZCBvbiB0aGUgZGlhbHN0cmlu Zy4NCj4gPj4gQ3VycmVudGx5IHRoZSBsaXN0U2VydmljZUJ5TG9jYXRpb24gcmVzcG9uc2UgZG9l cyBub3QgZ2l2ZSBhbnkNCj4gPj4gaW5mb3JtYXRpb24gb24gdGhlIGFyZWEgdGhlIHNlcnZpY2Ug bGlzdCBpcyB2YWxpZCBmb3IuIFNvIGEgY2xpZW50DQo+ID4+IG1pZ2h0IG1pc3MgYSBjaGFuZ2Ug aW4gdGhlIGF2YWlsYWJsZSBzZXJ2aWNlcywgc28gaXQgd29uJ3QgaGF2ZSB0aGUNCj4gPj4gZGlh bHN0cmluZyBjb25maWd1cmVkIGFuZCBpcyBub3QgYWJsZSB0byBkZXRlY3QgYW4gZW1lcmdlbmN5 IGNhbGwuDQo+ID4+IFRoZSBwcm9ibGVtIGFyaXNlcyBpbiBjb3VudHJpZXMgbm90IGhhdmluZyBh IHNpbmdsZSBlbWVyZ2VuY3kNCj4gPj4gZGlhbHN0cmluZywgbGlrZSA5MTEsIGJ1dCBoYXZpbmcg ZGlmZmVyZW50IGRpYWxzdHJpbmdzIGZvciBkaWZmZXJlbnQNCj4gPj4gc2VydmljZXMgYW5kIGRp YWxzdHJpbmdzIGFzIHdlbGwgYXMgc2VydmljZXMgZGVwZW5kIG9uIGxvY2F0aW9uLg0KPiBXaGVu DQo+ID4+IHRyYXZlbGxpbmcgYXJvdW5kLCB0aGUgYXZhaWxhYmlsaXR5IG9mIHNlcnZpY2VzIG1h eSBjaGFuZ2UsIGFzIHdlbGwNCj4gYXMNCj4gPj4gdGhlIGRpYWxzdHJpbmdzLiBTbyB0aGVyZSBu ZWVkcyB0byBiZSBzb21lIGtpbmQgb2YgcnVsZSBvbiB3aGVuIHRvDQo+ID4+IHVwZGF0ZSB0aGUg c2VydmljZSBsaXN0LiBTaW5jZSB0aGUgc2VydmljZSBib3VuZGFyeSB0ZWxscyB3aGVuIHRvIGRv DQo+IGENCj4gPj4gZmluZFNlcnZpY2UgYWdhaW4sIEkgdGhvdWdodCBpdCB3b3VsZCBiZSBjb25z aXN0ZW50IHRvIGludHJvZHVjZQ0KPiA+PiBhbm90aGVyIGJvdW5kYXJ5IHRvIHRlbGwgdGhlIGNs aWVudCB3aGVuIHRvIHVwZGF0ZSB0aGUgc2VydmljZSBsaXN0DQo+ID4+IChhcyBwcm9wb3NlZCBp biB0aGUgZHJhZnQpLg0KPiA+Pg0KPiA+PiBTaW5jZSBJIHdhcyBqdXN0IGxpc3RlbmluZyByZW1v dGVseSB0byB0aGUgZGlzY3Vzc2lvbiwgSSdkIGxpa2UgdG8NCj4gYXNrDQo+ID4+IGlmIEkgdW5k ZXJzdG9vZCBUZWQncyBpZGVhIGNvcnJlY3RseTogaW5zdGVhZCBvZiBhIGJvdW5kYXJ5DQo+IGlu ZGljYXRpbmcNCj4gPj4gdGhlIGFyZWEsIHRoZSBzZXJ2aWNlIGxpc3QgaXMgdmFsaWQgZm9yLCB0 aGUgTG9TVCBTZXJ2ZXIgc2hvdWxkIGFsc28NCj4gPj4gcmV0dXJuIHNlcnZpY2VzIHRoYXQgYXJl IE5PVCBhdmFpbGFibGUgYXQgdGhlIGN1cnJlbnQgbG9jYXRpb24uDQo+ID4+IFRoaXMgd291bGQg bWVhbjogd2hlbiBhIGNsaWVudCBkb2VzIGEgZmluZFNlcnZpY2UgZm9yDQo+ID4+IHVybjpzZXJ2 aWNlOnNvcy5hbWJ1bGFuY2UgZm9yIGl0cyBjdXJyZW50IGxvY2F0aW9uLCBpdCB3b3VsZCBhbHNv DQo+IGdldA0KPiA+PiBiYWNrIGEgbWFwcGluZyBmb3IgdXJuOnNlcnZpY2U6c29zLnBoeXNpY2lh biBmb3IgYSBkaWZmZXJlbnQNCj4gbG9jYXRpb24/DQo+ID4+IFNvIHdoZW4gbW92aW5nIHRvIHRo aXMgb3RoZXIgYXJlYSwgdGhlIGNsaWVudCBhbHJlYWR5IGtub3dzIHdoaWNoDQo+ID4+IHNlcnZp Y2VzIGFuZCBkaWFsc3RyaW5ncyBhcmUgYXZhaWxhYmxlIHRoZXJlLg0KPiA+PiBJJ20gYWZyYWlk IHRoaXMgYXBwcm9hY2ggd291bGQganVzdCBzb2x2ZSB0aGUgcHJvYmxlbSBpbiBjYXNlIHRoZQ0K PiBMb1NUDQo+ID4+IFNlcnZlciB3b3VsZCBkdW1wIG1vcmUgb3IgbGVzcyBpdCdzIGNvbXBsZXRl IGRhdGFiYXNlIHRvIHRoZSBjbGllbnQuDQo+ID4+IElmIHRoZSBMb1NUIFNlcnZlciB3b3VsZCBq dXN0IHNlbmQgYSBjb3VwbGUgb2YgbWFwcGluZ3MsIGFuZCBvdGhlcnMNCj4gPj4gbm90LCB0aGUg Y2xpZW50IGNvdWxkIHN0aWxsIGJlIGxvc3QuDQo+ID4+IEJlc2lkZXMsIHRyYWZmaWMgYW5kIGNv bXBsZXhpdHkgZm9yIHRoZSBjbGllbnQgd291bGQgaW5jcmVhc2UuIFRoZQ0KPiA+PiBzZXJ2aWNl bGlzdGJvdW5kYXJ5IHdvdWxkbid0IGluY3JlYXNlIGNvbXBsZXhpdHkgdG9vIG11Y2ggZm9yIGEN Cj4gY2xpZW50DQo+ID4+IGFscmVhZHkgZXZhbHVhdGluZyB0aGUgc2VydmljZSBib3VuZGFyeSwg c2luY2UgYWxsIHRoZSBuZWNlc3NhcnkNCj4gPj4gZnVuY3Rpb25hbGl0eSBzaG91bGQgYmUgYWxy ZWFkeSBpbiBwbGFjZS4gT24gdGhlIHNlcnZlciBzaWRlLCB0aGUNCj4gPj4gY29tcGxleGl0eSBz aG91bGQgYWxzbyBiZSBtYW5hZ2VhYmxlICh0aGUgc2VydmljZWxpc3Rib3VuZGFyeSBjb3VsZA0K PiBiZQ0KPiA+PiBwcmUtY2FsY3VsYXRlZCBmb3IgdGhlIGFyZWEgdGhlIHNlcnZlciBoYXMgZGF0 YSBmb3IpLg0KPiA+Pg0KPiA+PiBQbGVhc2UgbGV0IG1lIGtub3cgaWYgSSBtaXNzZWQgc29tZXRo aW5nIGluIHRoZSBkaXNjdXNzaW9uLg0KPiA+Pg0KPiA+PiBrYXJsIGhlaW56DQo+ID4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IEVjcml0IG1h aWxpbmcgbGlzdA0KPiA+PiBFY3JpdEBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWdu YXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQo+ID4gY29udGFpbiBwcml2aWxlZ2VkLCBwcm9w cmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uDQo+ID4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KPiA+IGlt bWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiDCoEFueSB1bmF1dGhvcml6ZWQgdXNl IG9mDQo+ID4gdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBbbWYyXQ0KPiA+DQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVz aWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3By aWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUg cmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRl bHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhp cyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpbbWYyXQ0K From hardie@qualcomm.com Wed Jul 29 05:27:53 2009 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 A0CE93A7035 for ; Wed, 29 Jul 2009 05:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIMcumLWqsWH for ; Wed, 29 Jul 2009 05:27:52 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 901D53A6966 for ; Wed, 29 Jul 2009 05:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1248870473; x=1280406473; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20|References:=20 |Date:=20Wed,=2029=20Jul=202009=2014:27:31=20+0200|To:=20 Karl=20Heinz=20Wolf=20,=20ECRIT=20|From:=20Ted=20Hardie=20 |Subject:=20Re:=20[Ecrit]=20servicelistboundary=20-=20dis cussion=20in=20the=20meeting=20today|Content-Type:=20text /plain=3B=20charset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcA fee=3Bi=3D"5300,2777,5691"=3B=20a=3D"21381241"; bh=i6/ZW6J/lOlY6FyavzkirmSWtZLFkQtK01X2qBhbLQU=; b=uFGdEnQp8JyDofFlnlaWHfbh3J5GWINqZxoHGIxQzt5FFhrp6GDEEpp1 YQkZ5w5p8rCIdJ6EtIwYfIsXuipEVp26RerukEZ14GsQTt4OOiX758lOk /0tnUQ1RDVQqBUgLbisXrUzImnywT8HSpgaMvLoIhUhzmXjMy3tNo++IC U=; X-IronPort-AV: E=McAfee;i="5300,2777,5691"; a="21381241" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jul 2009 05:27:39 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6TCRd6k004936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Jul 2009 05:27:39 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6TCRcMd031420 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Jul 2009 05:27:38 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 29 Jul 2009 05:27:38 -0700 Received: from [130.129.80.242] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 29 Jul 2009 05:27:37 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: References: Date: Wed, 29 Jul 2009 14:27:31 +0200 To: Karl Heinz Wolf , ECRIT From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting today 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, 29 Jul 2009 12:27:53 -0000 At 5:01 AM -0700 7/29/09, Karl Heinz Wolf wrote: >There was some discussion during the meeting today on my draft >http://tools.ietf.org/html/draft-wolf-ecrit-lost-servicelistboundary-01 > >My main concern is how to ensure that a client never misses a change >in available services and consequently learns all location dependent >dialstrings for the current location in order to be able to detect an >emergency call based on the dialstring. I think this is where the draft is a bit unclear. Let's start from what RFC 5222 says: A LoST client can ask a LoST server for the list of services it knows about for a particular area. The query contains one or more elements, each from a different location profile (Section 12), and may contain the element. As for , the server selects the first location element that has a profile the server understands and it can operate either recursively or iteratively; elements track the progress of the request. The query indicates the services that the server can enumerate from within the forest structure of which it is a part. Because LoST does not presume a single, overarching organization of all potential service types, there may be services available within a geographic area that could be described by other LoST servers connected to other forest structures. As an example, the emergency services forest for a region may be distinct from the forests that locate commercial services within the same region. If the query contains the element, the LoST server returns only immediate child services of the queried service that are available for the provided location. If the element is absent, the LoST service returns all top-level services available for the provided location that it knows about. The current mechanism only works within a single forest structure. This draft is not clear, at least to me, in being scoped to a single forest structure, and the discussion in the room wandered around that topic (partly by referring to the services for which the responding servers are authoritative). >Currently the listServiceByLocation response does not give any >information on the area the service list is valid for. So a client >might miss a change in the available services, so it won't have the >dialstring configured and is not able to detect an emergency call. But there are many more available services than emergency services. These will also change. Are we clear that this only captures changes to those within a service hierarchy? >The problem arises in countries not having a single emergency >dialstring, like 911, but having different dialstrings for different >services and dialstrings as well as services depend on location. When >travelling around, the availability of services may change, as well as >the dialstrings. So there needs to be some kind of rule on when to >update the service list. Since the service boundary tells when to do a >findService again, I thought it would be consistent to introduce >another boundary to tell the client when to update the service list >(as proposed in the draft). In the past, we discussed this in terms of time, rather than movement; this was because the list could also change because of additions (again, not so much for emergency servies, but potentially for other services) >Since I was just listening remotely to the discussion, I'd like to ask >if I understood Ted's idea correctly: instead of a boundary indicating >the area, the service list is valid for, the LoST Server should also >return services that are NOT available at the current location. >This would mean: when a client does a findService for >urn:service:sos.ambulance for its current location, it would also get >back a mapping for urn:service:sos.physician for a different location? No; it sounds like something got lost here. I was first proposing that this should be limited in applicability, essentially to a single forest or service type. Then I was suggesting that a server able to traverse that forest respond with a list of relevant services but without location boundary information for those not available in the area relevant to the query. That is, you do a query using findServicebyLocation for urn:service:geg and get back urn:service:geg.orthozog with a boundary, and urn:service:geg.mumblefratz. with no boundary. That avoids dumping the database (and the current server having to collect the information about where geg.mumblefratz is available); it simply lets the client know that there are other services out there which are explicitly not available at the target site of the first query. If the client wants to use geg.mumblefratz, it needs to re-query. It can requery at some specified time scale, or it can requery on only when it wants to use geg.mumblefratz. I was somewhat surprised, honestly, to see Henning arguing for this, since he has argued against this idea in the past. This makes me suspect I am missing some subtle difference, and I would not be surprised to find that this is so. I would like, however, if we did not concentrate on the emergency services use case to the exclusion of other use cases; that tends to skew the design in ways that will limit LoST's usefulness in other realms. regards, Ted Hardie >So when moving to this other area, the client already knows which >services and dialstrings are available there. >I'm afraid this approach would just solve the problem in case the LoST >Server would dump more or less it's complete database to the client. >If the LoST Server would just send a couple of mappings, and others >not, the client could still be lost. >Besides, traffic and complexity for the client would increase. The >servicelistboundary wouldn't increase complexity too much for a client >already evaluating the service boundary, since all the necessary >functionality should be already in place. On the server side, the >complexity should also be manageable (the servicelistboundary could be >pre-calculated for the area the server has data for). > >Please let me know if I missed something in the discussion. > >karl heinz >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From Martin.Thomson@andrew.com Wed Jul 29 05:31:05 2009 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 26C373A7067 for ; Wed, 29 Jul 2009 05:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 dZ+JaeZEGrvL for ; Wed, 29 Jul 2009 05:31:03 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id BE5F93A7035 for ; Wed, 29 Jul 2009 05:29:33 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_29_07_52_07 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 29 Jul 2009 07:52:07 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 07:29:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 29 Jul 2009 07:29:31 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] servicelistboundary - discussion in the meeting today Thread-Index: AcoQRsYBebCxRgE1QGCXemiO25G5LgAAD+CAAABACKA= References: From: "Thomson, Martin" To: "Thomson, Martin" , "Karl Heinz Wolf" X-OriginalArrivalTime: 29 Jul 2009 12:29:34.0831 (UTC) FILETIME=[3B1397F0:01CA1048] Cc: ECRIT Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting today 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, 29 Jul 2009 12:31:05 -0000 SSBzaG91bGQgcmVhbGx5IHJlYWQgbXkgZW1haWwgYmVmb3JlIEkgc2VuZCBpdC4gIFRoYXQgZmly c3Qgc2VudGVuY2UgbWFrZXMgbm8gc2Vuc2UgdG8gbWUuICBJZ25vcmUgaXQuDQoNCk1heWJlIHRo ZSB0ZXh0IGNvdWxkIGRlc2NyaWJlLCBpbiBnZW5lcmFsIHRlcm1zIHRoZSBhbGdvcml0aG0gdXNl ZCB0byBnZW5lcmF0ZSB0aGVzZSB0aGluZ3MgLSBhbmQgdGhlcmVieSBoZWFkIG9mZiBhbnkgc3Vj aCBjb25jZXJucy4NCg0KT2gsIGFuZCBJIGFsd2F5cyB0aG91Z2h0IHRoYXQgd2UgaGFkIGNvbnNl bnN1cyB0byB3b3JrIG9uIHRoZSBwcm9ibGVtLiAgQWRkIHRoZSBtaWxlc3RvbmUgYW5kIGFkb3B0 IHRoZSBkcmFmdC4NCg0KLS1NYXJ0aW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmDQo+IE9mIFRob21zb24sIE1hcnRpbg0KPiBTZW50OiBXZWRuZXNkYXks IDI5IEp1bHkgMjAwOSAyOjI1IFBNDQo+IFRvOiBLYXJsIEhlaW56IFdvbGYNCj4gQ2M6IEVDUklU DQo+IFN1YmplY3Q6IFJlOiBbRWNyaXRdIHNlcnZpY2VsaXN0Ym91bmRhcnkgLSBkaXNjdXNzaW9u IGluIHRoZSBtZWV0aW5nDQo+IHRvZGF5DQo+IA0KPiBPZiBjb3Vyc2UsIGlmIHRoZSBzZXJ2ZXIg aXMgdW5hYmxlIHRvIGRvIHRoZSBmdWxsIGNvbXB1dGF0aW9uLCBpdCBkb2VzDQo+IG5vdCBuZWVk IHRvIHJlcG9ydCB0aGUgY29tcGxldGUgYXJlYSBuZWNlc3NhcnkuDQo+IA0KPiBJdCdzIE8obikg cmF0aGVyIHRoYW4gTygyXm4pIGlzbid0IGl0PyAgRm9yIGVhY2ggc2VydmljZSB0aGF0IHRoZQ0K PiB0YXJnZXQgY2FuIHVzZSBjdXJyZW50bHksIGFuZCBnaXZlbiB0aGUgZXh0ZW50cyBvZiB0aGUg c2VydmljZSAoZm91bmQNCj4gYnkgZm9ybWluZyB0aGUgdW5pb24gb2YgYWxsIHNlcnZpY2UgYXJl YXMgLSBhbiBvcCB0aGF0IGNhbiBiZSBwZXJmb3JtZWQNCj4gYmVmb3JlaGFuZCksIHRoZSBleHRl bnRzIG9mIHRoZSBzZXJ2aWNlIGxpc3QgYm91bmRhcnkgYXJlIGZvdW5kIGJ5DQo+IGZpbmRpbmcg dGhlIGludGVyc2VjdGlvbiBvZiBhbGwgdGhlIGFyZWFzLiAgRHVyaW5nIHRoaXMgc3RhZ2UsIHRo ZQ0KPiBib3VuZGFyeSBmb3IgYSBwYXJ0aWN1bGFyIHNlcnZpY2UgY2FuIGJlIHNocnVuayBpZiB0 aGF0IG1ha2VzIGl0DQo+IGVhc2llci4NCj4gDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gRnJvbTogS2FybCBIZWlueiBXb2xmIFttYWlsdG86a2h3b2xmMUBnbWFpbC5j b21dDQo+ID4gU2VudDogV2VkbmVzZGF5LCAyOSBKdWx5IDIwMDkgMjoxOSBQTQ0KPiA+IFRvOiBU aG9tc29uLCBNYXJ0aW4NCj4gPiBDYzogRUNSSVQNCj4gPiBTdWJqZWN0OiBSZTogW0Vjcml0XSBz ZXJ2aWNlbGlzdGJvdW5kYXJ5IC0gZGlzY3Vzc2lvbiBpbiB0aGUgbWVldGluZw0KPiA+IHRvZGF5 DQo+ID4NCj4gPiBPbiBXZWQsIEp1bCAyOSwgMjAwOSBhdCAyOjEwIFBNLCBUaG9tc29uLA0KPiA+ IE1hcnRpbjxNYXJ0aW4uVGhvbXNvbkBhbmRyZXcuY29tPiB3cm90ZToNCj4gPiA+IE15IGNvbmNs dXNpb24gZnJvbSB0aGUgZGlzY3Vzc2lvbiB3YXMgdGhhdCBUZWQgaGFkIHNvbWUgY29uY2VybnMN Cj4gPiByZWxhdGluZyB0byB0aGUgY29tYmluYXRvcmlhbCBjb21wbGV4aXR5IGltcGxpZWQgYnkg d2hhdCBpcyBwcm9wb3NlZC4NCj4gPiDCoEkgYWxzbyBnb3QgdGhlIGltcHJlc3Npb24gdGhhdCB0 aGUgZG9jdW1lbnQgY291bGQgc3RpbGwgYmUgYWNjZXB0ZWQsDQo+ID4gYnV0IHRoYXQgaXNzdWUg d291bGQgbmVlZCB0byBiZSByZXNvbHZlZC4NCj4gPiA+DQo+ID4NCj4gPiByZWdhcmRpbmcgdGhl IGNvbXBsZXhpdHkgb2YgdGhlIHJlc3VsdGluZyBib3VuZGFyeSBpbmZvcm1hdGlvbiwgSQ0KPiA+ IHRyaWVkIHRvIGV4cGxhaW4gdGhhdCBpbiBzZWN0aW9uIDMuNC4xIG9mIHRoZSBkcmFmdC4NCj4g Pg0KPiA+ICAgIFRoZSBjYWxjdWxhdGlvbiBvZiB0aGUgbGFyZ2VzdCBwb3NzaWJsZSBhcmVhIGZv ciB3aGljaCB0aGUgc2VydmljZQ0KPiA+ICAgIGxpc3Qgc3RheXMgdGhlIHNhbWUgbWlnaHQgYmUg YSBjb21wbGV4IHRhc2suICBBbiBhbHRlcm5hdGl2ZSB3b3VsZA0KPiA+IGJlDQo+ID4gICAgdG8g cmV0dXJuIHNtYWxsZXIgYXJlYXMgdGhhdCBhcmUgZWFzaWVyIHRvIGNvbXB1dGUuICBJbiBzdWNo IGENCj4gY2FzZQ0KPiA+ICAgIHNvbWUgdW5uZWVkZWQgcXVlcmllcyB0byB0aGUgTG9TVCBzZXJ2 ZXIgYXJlIHRoZSBjb25zZXF1ZW5jZSwgYnV0DQo+ID4gICAgc3RpbGwgdGhlIG1haW4gcHVycG9z ZSBvZiB0aGUgc2VydmljZUxpc3RCb3VuZGFyeSBpcyBhY2hpZXZlZDoNCj4gTmV2ZXINCj4gPiAg ICBtaXNzIGEgY2hhbmdlIG9mIGF2YWlsYWJsZSBzZXJ2aWNlcy4gIFNvIGEgcmVhc29uYWJsZSB0 cmFkZS1vZmYNCj4gPiAgICBiZXR3ZWVuIHRoZSBlZmZvcnQgdG8gZ2VuZXJhdGUgdGhlIGJvdW5k YXJ5IGluZm9ybWF0aW9uIGFuZCB0aGUNCj4gPiBzYXZlZA0KPiA+ICAgIHF1ZXJpZXMgdG8gdGhl IExvU1Qgc2VydmVyIGhhcyB0byBiZSBjb25zaWRlcmVkLg0KPiA+DQo+ID4gZG9lcyB0aGlzIG1h a2Ugc2Vuc2U/DQo+ID4NCj4gPiA+IEl0IGFwcGVhcnMgdGhhdCBUZWQncyBhbHRlcm5hdGl2ZSBz b2x1dGlvbiBkb2Vzbid0IHdvcmsgdmVyeSB3ZWxsLA0KPiBhcw0KPiA+IHlvdSBzYXkuDQo+ID4g Pg0KPiA+ID4gTWF5YmUgSSBjYW4gcHJvcG9zZSB0aGF0IHRoZSBjaGFpcnMgYXNrIGZvciBhKSBj b25zZW5zdXMgb24gdGhlDQo+ID4gcHJvYmxlbSwgYikgYWRvcHRpb24gb2YgdGhlIGRyYWZ0LiDC oFdlIHByb2JhYmx5IHNob3VsZCBoYXZlIGRvbmUgdGhhdA0KPiA+IGluIHRoZSBtZWV0aW5nLg0K PiA+ID4NCj4gPg0KPiA+IEkgdGhpbmsgYSkgd2FzIGFscmVhZHkgYXNrZWQgb24gdGhlIG1haWxp bmdsaXN0Og0KPiA+DQo+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2Vj cml0L2N1cnJlbnQvbXNnMDYyNDYuaHRtbA0KPiA+DQo+ID4ga2FybCBoZWlueg0KPiA+DQo+ID4g PiBNYXliZSBUZWQgd2lsbCBkaXNhZ3JlZSwgYnV0IEknbSBzdXJlIHRoYXQgd2UnbGwgYmUgaGVh cmluZyBhbnkNCj4gPiBvYmplY3Rpb25zIGlmIHRoYXQncyB0aGUgY2FzZS4NCj4gPiA+DQo+ID4g PiAtLU1hcnRpbg0KPiA+ID4NCj4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ ID4+IEZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1ib3VuY2VzQGll dGYub3JnXSBPbg0KPiA+IEJlaGFsZg0KPiA+ID4+IE9mIEthcmwgSGVpbnogV29sZg0KPiA+ID4+ IFNlbnQ6IFdlZG5lc2RheSwgMjkgSnVseSAyMDA5IDI6MDEgUE0NCj4gPiA+PiBUbzogRUNSSVQN Cj4gPiA+PiBTdWJqZWN0OiBbRWNyaXRdIHNlcnZpY2VsaXN0Ym91bmRhcnkgLSBkaXNjdXNzaW9u IGluIHRoZSBtZWV0aW5nDQo+ID4gdG9kYXkNCj4gPiA+Pg0KPiA+ID4+IFRoZXJlIHdhcyBzb21l IGRpc2N1c3Npb24gZHVyaW5nIHRoZSBtZWV0aW5nIHRvZGF5IG9uIG15IGRyYWZ0DQo+ID4gPj4g aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd29sZi1lY3JpdC1sb3N0LQ0KPiA+IHNl cnZpY2VsaXN0Ym91bmRhcnktMDENCj4gPiA+Pg0KPiA+ID4+IE15IG1haW4gY29uY2VybiBpcyBo b3cgdG8gZW5zdXJlIHRoYXQgYSBjbGllbnQgbmV2ZXIgbWlzc2VzIGENCj4gY2hhbmdlDQo+ID4g Pj4gaW4gYXZhaWxhYmxlIHNlcnZpY2VzIGFuZCBjb25zZXF1ZW50bHkgbGVhcm5zIGFsbCBsb2Nh dGlvbg0KPiBkZXBlbmRlbnQNCj4gPiA+PiBkaWFsc3RyaW5ncyBmb3IgdGhlIGN1cnJlbnQgbG9j YXRpb24gaW4gb3JkZXIgdG8gYmUgYWJsZSB0byBkZXRlY3QNCj4gPiBhbg0KPiA+ID4+IGVtZXJn ZW5jeSBjYWxsIGJhc2VkIG9uIHRoZSBkaWFsc3RyaW5nLg0KPiA+ID4+IEN1cnJlbnRseSB0aGUg bGlzdFNlcnZpY2VCeUxvY2F0aW9uIHJlc3BvbnNlIGRvZXMgbm90IGdpdmUgYW55DQo+ID4gPj4g aW5mb3JtYXRpb24gb24gdGhlIGFyZWEgdGhlIHNlcnZpY2UgbGlzdCBpcyB2YWxpZCBmb3IuIFNv IGEgY2xpZW50DQo+ID4gPj4gbWlnaHQgbWlzcyBhIGNoYW5nZSBpbiB0aGUgYXZhaWxhYmxlIHNl cnZpY2VzLCBzbyBpdCB3b24ndCBoYXZlDQo+IHRoZQ0KPiA+ID4+IGRpYWxzdHJpbmcgY29uZmln dXJlZCBhbmQgaXMgbm90IGFibGUgdG8gZGV0ZWN0IGFuIGVtZXJnZW5jeSBjYWxsLg0KPiA+ID4+ IFRoZSBwcm9ibGVtIGFyaXNlcyBpbiBjb3VudHJpZXMgbm90IGhhdmluZyBhIHNpbmdsZSBlbWVy Z2VuY3kNCj4gPiA+PiBkaWFsc3RyaW5nLCBsaWtlIDkxMSwgYnV0IGhhdmluZyBkaWZmZXJlbnQg ZGlhbHN0cmluZ3MgZm9yDQo+IGRpZmZlcmVudA0KPiA+ID4+IHNlcnZpY2VzIGFuZCBkaWFsc3Ry aW5ncyBhcyB3ZWxsIGFzIHNlcnZpY2VzIGRlcGVuZCBvbiBsb2NhdGlvbi4NCj4gPiBXaGVuDQo+ ID4gPj4gdHJhdmVsbGluZyBhcm91bmQsIHRoZSBhdmFpbGFiaWxpdHkgb2Ygc2VydmljZXMgbWF5 IGNoYW5nZSwgYXMNCj4gd2VsbA0KPiA+IGFzDQo+ID4gPj4gdGhlIGRpYWxzdHJpbmdzLiBTbyB0 aGVyZSBuZWVkcyB0byBiZSBzb21lIGtpbmQgb2YgcnVsZSBvbiB3aGVuIHRvDQo+ID4gPj4gdXBk YXRlIHRoZSBzZXJ2aWNlIGxpc3QuIFNpbmNlIHRoZSBzZXJ2aWNlIGJvdW5kYXJ5IHRlbGxzIHdo ZW4gdG8NCj4gZG8NCj4gPiBhDQo+ID4gPj4gZmluZFNlcnZpY2UgYWdhaW4sIEkgdGhvdWdodCBp dCB3b3VsZCBiZSBjb25zaXN0ZW50IHRvIGludHJvZHVjZQ0KPiA+ID4+IGFub3RoZXIgYm91bmRh cnkgdG8gdGVsbCB0aGUgY2xpZW50IHdoZW4gdG8gdXBkYXRlIHRoZSBzZXJ2aWNlDQo+IGxpc3QN Cj4gPiA+PiAoYXMgcHJvcG9zZWQgaW4gdGhlIGRyYWZ0KS4NCj4gPiA+Pg0KPiA+ID4+IFNpbmNl IEkgd2FzIGp1c3QgbGlzdGVuaW5nIHJlbW90ZWx5IHRvIHRoZSBkaXNjdXNzaW9uLCBJJ2QgbGlr ZSB0bw0KPiA+IGFzaw0KPiA+ID4+IGlmIEkgdW5kZXJzdG9vZCBUZWQncyBpZGVhIGNvcnJlY3Rs eTogaW5zdGVhZCBvZiBhIGJvdW5kYXJ5DQo+ID4gaW5kaWNhdGluZw0KPiA+ID4+IHRoZSBhcmVh LCB0aGUgc2VydmljZSBsaXN0IGlzIHZhbGlkIGZvciwgdGhlIExvU1QgU2VydmVyIHNob3VsZA0K PiBhbHNvDQo+ID4gPj4gcmV0dXJuIHNlcnZpY2VzIHRoYXQgYXJlIE5PVCBhdmFpbGFibGUgYXQg dGhlIGN1cnJlbnQgbG9jYXRpb24uDQo+ID4gPj4gVGhpcyB3b3VsZCBtZWFuOiB3aGVuIGEgY2xp ZW50IGRvZXMgYSBmaW5kU2VydmljZSBmb3INCj4gPiA+PiB1cm46c2VydmljZTpzb3MuYW1idWxh bmNlIGZvciBpdHMgY3VycmVudCBsb2NhdGlvbiwgaXQgd291bGQgYWxzbw0KPiA+IGdldA0KPiA+ ID4+IGJhY2sgYSBtYXBwaW5nIGZvciB1cm46c2VydmljZTpzb3MucGh5c2ljaWFuIGZvciBhIGRp ZmZlcmVudA0KPiA+IGxvY2F0aW9uPw0KPiA+ID4+IFNvIHdoZW4gbW92aW5nIHRvIHRoaXMgb3Ro ZXIgYXJlYSwgdGhlIGNsaWVudCBhbHJlYWR5IGtub3dzIHdoaWNoDQo+ID4gPj4gc2VydmljZXMg YW5kIGRpYWxzdHJpbmdzIGFyZSBhdmFpbGFibGUgdGhlcmUuDQo+ID4gPj4gSSdtIGFmcmFpZCB0 aGlzIGFwcHJvYWNoIHdvdWxkIGp1c3Qgc29sdmUgdGhlIHByb2JsZW0gaW4gY2FzZSB0aGUNCj4g PiBMb1NUDQo+ID4gPj4gU2VydmVyIHdvdWxkIGR1bXAgbW9yZSBvciBsZXNzIGl0J3MgY29tcGxl dGUgZGF0YWJhc2UgdG8gdGhlDQo+IGNsaWVudC4NCj4gPiA+PiBJZiB0aGUgTG9TVCBTZXJ2ZXIg d291bGQganVzdCBzZW5kIGEgY291cGxlIG9mIG1hcHBpbmdzLCBhbmQNCj4gb3RoZXJzDQo+ID4g Pj4gbm90LCB0aGUgY2xpZW50IGNvdWxkIHN0aWxsIGJlIGxvc3QuDQo+ID4gPj4gQmVzaWRlcywg dHJhZmZpYyBhbmQgY29tcGxleGl0eSBmb3IgdGhlIGNsaWVudCB3b3VsZCBpbmNyZWFzZS4gVGhl DQo+ID4gPj4gc2VydmljZWxpc3Rib3VuZGFyeSB3b3VsZG4ndCBpbmNyZWFzZSBjb21wbGV4aXR5 IHRvbyBtdWNoIGZvciBhDQo+ID4gY2xpZW50DQo+ID4gPj4gYWxyZWFkeSBldmFsdWF0aW5nIHRo ZSBzZXJ2aWNlIGJvdW5kYXJ5LCBzaW5jZSBhbGwgdGhlIG5lY2Vzc2FyeQ0KPiA+ID4+IGZ1bmN0 aW9uYWxpdHkgc2hvdWxkIGJlIGFscmVhZHkgaW4gcGxhY2UuIE9uIHRoZSBzZXJ2ZXIgc2lkZSwg dGhlDQo+ID4gPj4gY29tcGxleGl0eSBzaG91bGQgYWxzbyBiZSBtYW5hZ2VhYmxlICh0aGUgc2Vy dmljZWxpc3Rib3VuZGFyeQ0KPiBjb3VsZA0KPiA+IGJlDQo+ID4gPj4gcHJlLWNhbGN1bGF0ZWQg Zm9yIHRoZSBhcmVhIHRoZSBzZXJ2ZXIgaGFzIGRhdGEgZm9yKS4NCj4gPiA+Pg0KPiA+ID4+IFBs ZWFzZSBsZXQgbWUga25vdyBpZiBJIG1pc3NlZCBzb21ldGhpbmcgaW4gdGhlIGRpc2N1c3Npb24u DQo+ID4gPj4NCj4gPiA+PiBrYXJsIGhlaW56DQo+ID4gPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4g PiA+PiBFY3JpdEBpZXRmLm9yZw0KPiA+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZWNyaXQNCj4gPiA+DQo+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+ID4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiBUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNp Z25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCj4gPiA+IGNvbnRhaW4gcHJpdmlsZWdlZCwg cHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLg0KPiA+ID4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0K PiA+ID4gaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuIMKgQW55IHVuYXV0aG9y aXplZCB1c2Ugb2YNCj4gPiA+IHRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCj4gPiA+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gLS0NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+IFttZjJd DQo+ID4gPg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiBUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFu ZCBtYXkNCj4gY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHBy aXZhdGUgaW5mb3JtYXRpb24uDQo+IElmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCj4gaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3Jp Z2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KPiB0aGlzIGVtYWlsIGlzIHByb2hpYml0 ZWQuDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gW21m Ml0NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g RWNyaXQgbWFpbGluZyBsaXN0DQo+IEVjcml0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQg b25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndp c2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUg b3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJp dGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ0K From khwolf1@gmail.com Wed Jul 29 06:20:57 2009 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 8C3323A69B8 for ; Wed, 29 Jul 2009 06:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTJEjBQhR4q6 for ; Wed, 29 Jul 2009 06:20:56 -0700 (PDT) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by core3.amsl.com (Postfix) with ESMTP id A162C3A67AC for ; Wed, 29 Jul 2009 06:20:55 -0700 (PDT) Received: by bwz21 with SMTP id 21so682718bwz.37 for ; Wed, 29 Jul 2009 06:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=j+HwntZNAO9nTOfMUb39YFuzBer1csPbWhPW4HTeHIU=; b=pXbeWAmbVKqD61YM58v1UtHgxqeDab24DJ7nJQDNehsjMP0cLkQO9Z1fSJrqSws8IL 7WI5MzmIpBVh76U7zNWeniOqdrUC+UPpKmhLUP8vPV8esXCjWawygO/lfWGiI43NRbVF KjHE5tDLpHDIbC8lrURx8JFOPp7PvDw84OEqM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ttDh+Iy9KeqVHOIJfRUZqBrYDi7JTfSNV5dtykMZ8AMRdcQ8EODqq08PdW3aGQNcfK 4/cLI4GS49eeekYVWCh8RZrrHuKy9hHFkXqHXu6rfSA6Hja04kosA5CLRHjWGVwOLT09 zgTYrlY0mdARACK3e7D4l2RBPyaiwh6Td10NI= MIME-Version: 1.0 Received: by 10.103.175.8 with SMTP id c8mr4620871mup.75.1248873654125; Wed, 29 Jul 2009 06:20:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Jul 2009 15:20:54 +0200 Message-ID: From: Karl Heinz Wolf To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ECRIT Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting today 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, 29 Jul 2009 13:20:57 -0000 Ted, thank you for your clarification. You might be correct, I probably focused too much on emergency services. But there it hurts the most: if you're unaware of the service, you don't have the dialstring and you definitely cannot detect the emergency call to this service. On Wed, Jul 29, 2009 at 2:27 PM, Ted Hardie wrote: > At 5:01 AM -0700 7/29/09, Karl Heinz Wolf wrote: >>There was some discussion during the meeting today on my draft >>http://tools.ietf.org/html/draft-wolf-ecrit-lost-servicelistboundary-01 >> >>My main concern is how to ensure that a client never misses a change >>in available services and consequently learns all location dependent >>dialstrings for the current location in order to be able to detect an >>emergency call based on the dialstring. > > I think this is where the draft is a bit unclear. =A0Let's start from > what RFC 5222 says: > > =A0A LoST client can ask a LoST server for the list of services it knows > =A0 about for a particular area. =A0The query > =A0 contains one or more elements, each from a different > =A0 location profile (Section 12), and may contain the element. > =A0 As for , the server selects the first location element > =A0 that has a profile the server understands and it can operate either > =A0 recursively or iteratively; elements track the progress of the > =A0 request. =A0The query indicates the services that the server can > =A0 enumerate from within the forest structure of which it is a part. > =A0 Because LoST does not presume a single, overarching organization of > =A0 all potential service types, there may be services available within a > =A0 geographic area that could be described by other LoST servers > =A0 connected to other forest structures. =A0As an example, the emergency > =A0 services forest for a region may be distinct from the forests that > =A0 locate commercial services within the same region. > > =A0 If the query contains the element, the LoST server returns > =A0 only immediate child services of the queried service that are > =A0 available for the provided location. =A0If the element is > =A0 absent, the LoST service returns all top-level services available for > =A0 the provided location that it knows about. > > The current mechanism only works within a single forest structure. > This draft is not clear, at least to me, in being scoped to a single > forest structure, and the discussion in the room wandered around > that topic (partly by referring to the services for which the responding > servers are authoritative). > right, the draft does not explicitly say this at the moment. Thank you for pointing this out, it helps me understanding the discussion better. > >>Currently the listServiceByLocation response does not give any >>information on the area the service list is valid for. So a client >>might miss a change in the available services, so it won't have the >>dialstring configured and is not able to detect an emergency call. > > But there are many more available services than emergency services. > These will also change. =A0Are we clear that this only captures changes > to those within a service hierarchy? > but you don't need to know the dialstring for pizza in advance: if you press the pizza button on your device, it can simply do the service discovery. > >>The problem arises in countries not having a single emergency >>dialstring, like 911, but having different dialstrings for different >>services and dialstrings as well as services depend on location. When >>travelling around, the availability of services may change, as well as >>the dialstrings. So there needs to be some kind of rule on when to >>update the service list. Since the service boundary tells when to do a >>findService again, I thought it would be consistent to introduce >>another boundary to tell the client when to update the service list >>(as proposed in the draft). > > In the past, we discussed this in terms of time, rather than movement; > this was because the list could also change because of additions (again, > not so much for emergency servies, but potentially for other services) > I wasn't talking about changes in time - sorry if didn't express that clearly. Besides, the changes in time would be addressed by the expires attribute. > >>Since I was just listening remotely to the discussion, I'd like to ask >>if I understood Ted's idea correctly: instead of a boundary indicating >>the area, the service list is valid for, the LoST Server should also >>return services that are NOT available at the current location. >>This would mean: when a client does a findService for >>urn:service:sos.ambulance for its current location, it would also get >>back a mapping for urn:service:sos.physician for a different location? > > No; it sounds like something got lost here. =A0I was first proposing that > this should be limited in applicability, essentially to a single forest o= r > service type. =A0Then I was suggesting that a server able to traverse tha= t > forest respond with a list of relevant services but without location > boundary information for those not available in the area relevant > to the query. =A0That is, you do a query using findServicebyLocation for > urn:service:geg and get back urn:service:geg.orthozog with a boundary, > and urn:service:geg.mumblefratz. with no boundary. =A0That avoids > dumping the database (and the current server having to collect the > information about where geg.mumblefratz is available); it simply > lets the client know that there are other services out there which > are explicitly not available at the target site of the first query. > > If the client wants to use geg.mumblefratz, it needs to re-query. > It can requery at some specified time scale, or it can requery on > only when it wants to use geg.mumblefratz. > hm, as I understand it, the client has still the same problem: when does the service become available? The only information the client gets is that this service is available "somewhere". I'm not sure this is helpful? Moreover, considering the emergency service case, you have to know the dialstring right before the call. I know I'm concentrating on emergency services... > I was somewhat surprised, honestly, to see Henning arguing > for this, since he has argued against this idea in the past. =A0This > makes me suspect I am missing some subtle difference, > and I would not be surprised to find that this is so. =A0I would > like, however, if we did not concentrate on the emergency > services use case to the exclusion of other use cases; that > tends to skew the design in ways that will limit LoST's usefulness > in other realms. I'm afraid we need some kind of rule on when to update the service list when travelling. And this is crucial for figuring out the dialstings as long as there is not a single emergency dialstring all over the world. I'm not sure if the servicelistboundary makes much sense for other services, since as you pointed out, they may just get discovered on demand without any problems. However, also the service boundary is optional in LoST, also the servicelistboundary could just be optional and only be returned in case the server knows it or it's about emergency services. karl heinz > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regards, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ted Hardie > >>So when moving to this other area, the client already knows which >>services and dialstrings are available there. >>I'm afraid this approach would just solve the problem in case the LoST >>Server would dump more or less it's complete database to the client. >>If the LoST Server would just send a couple of mappings, and others >>not, the client could still be lost. >>Besides, traffic and complexity for the client would increase. The >>servicelistboundary wouldn't increase complexity too much for a client >>already evaluating the service boundary, since all the necessary >>functionality should be already in place. On the server side, the >>complexity should also be manageable (the servicelistboundary could be >>pre-calculated for the area the server has data for). >> >>Please let me know if I missed something in the discussion. >> >>karl heinz >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit > > From br@brianrosen.net Wed Jul 29 06:22:24 2009 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 4F0583A6F49 for ; Wed, 29 Jul 2009 06:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiHuQdcfuNG0 for ; Wed, 29 Jul 2009 06:22:23 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 77EAB3A684C for ; Wed, 29 Jul 2009 06:22:23 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MW96n-0001RA-SR for ecrit@ietf.org; Wed, 29 Jul 2009 08:22:18 -0500 From: "Brian Rosen" To: References: <580F3FFD9207B545B48957A92BECEE0A508EB5@STNTEXCH11.cis.neustar.com> In-Reply-To: <580F3FFD9207B545B48957A92BECEE0A508EB5@STNTEXCH11.cis.neustar.com> Date: Wed, 29 Jul 2009 09:22:20 -0400 Message-ID: <023d01ca104f$9c7a9320$d56fb960$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoQL1oZuKBSx9XaTT2+vFzbYGen7QAIAPgg Content-Language: en-us 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] Problem statement for Premature Disconnect 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, 29 Jul 2009 13:22:24 -0000 There is a small typo in this. The ECRIT work group would complete requirements for handling premature disconnect. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Rosen, Brian > Sent: Wednesday, July 29, 2009 5:31 AM > To: ecrit@ietf.org > Subject: [Ecrit] Problem statement for Premature Disconnect > > I was asked to reword a problem statement on premature disconnect that > might be acceptable to begin work on, probably a design team on > requirements. I propose: > > In emergency calls, people are stressed. They sometimes try to > disconnect a call where communication between the caller and the call > taker has begun, but before the call taker has acquired enough > information to direct appropriate response. That circumstance is known > as "premature disconnect". In those circumstances the device should > behave differently. For example, the device may alert rather than > disconnect. The behavior of the device would be UI driven, and thus > not > specifiable by the IETF, although advice might be given. > > Special behavior is not always desirable. For example, in high call > volume circumstances, the call may be answered by the PSAP at an IVR, > in > which case no special behavior is desired. The device may not > implement > the specification, or for some reason, it may not be available for a > particular emergency call. For this reason, some form of signaling at > the beginning of the call is needed to negotiate enabling the special > behavior. > > It is desirable that the PSAP be aware that the user has attempted to > disconnect/reconnect, and it may be useful for the PSAP to be able to > influence the behavior of the device. Some form of signaling for this > purpose is desirable, but need not be reliable, since it is advisory. > > In all circumstances the user must maintain control of his device, and > it must be possible for the user to take some action to complete a > disconnect. > > The geopriv work group would complete requirements for handling > premature disconnect. Some of the resulting protocol work may need to > be accomplished in other RAI work groups. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Wed Jul 29 06:33:27 2009 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 5230D3A7081 for ; Wed, 29 Jul 2009 06:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwoQV9aNoe0F for ; Wed, 29 Jul 2009 06:33:26 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 019633A700B for ; Wed, 29 Jul 2009 06:33:26 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MW9HT-00027O-0L; Wed, 29 Jul 2009 08:33:19 -0500 From: "Brian Rosen" To: "'Karl Heinz Wolf'" , "'Ted Hardie'" References: In-Reply-To: Date: Wed, 29 Jul 2009 09:33:21 -0400 Message-ID: <024101ca1051$26a6c720$73f45560$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoQT2eYoI99lzAqQ7e4qAhc1pM8MAAAMikw Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting today 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, 29 Jul 2009 13:33:27 -0000 Perhaps the service URN has some sub urns, like urn:service:servicelistboundary.sos > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Karl Heinz Wolf > Sent: Wednesday, July 29, 2009 9:21 AM > To: Ted Hardie > Cc: ECRIT > Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting > today >=20 > Ted, >=20 > thank you for your clarification. >=20 > You might be correct, I probably focused too much on emergency > services. But there it hurts the most: if you're unaware of the > service, you don't have the dialstring and you definitely cannot > detect the emergency call to this service. >=20 > On Wed, Jul 29, 2009 at 2:27 PM, Ted Hardie = wrote: > > At 5:01 AM -0700 7/29/09, Karl Heinz Wolf wrote: > >>There was some discussion during the meeting today on my draft > = >>http://tools.ietf.org/html/draft-wolf-ecrit-lost-servicelistboundary- > 01 > >> > >>My main concern is how to ensure that a client never misses a change > >>in available services and consequently learns all location dependent > >>dialstrings for the current location in order to be able to detect = an > >>emergency call based on the dialstring. > > > > I think this is where the draft is a bit unclear. =A0Let's start = from > > what RFC 5222 says: > > > > =A0A LoST client can ask a LoST server for the list of services it > knows > > =A0 about for a particular area. =A0The = query > > =A0 contains one or more elements, each from a different > > =A0 location profile (Section 12), and may contain the > element. > > =A0 As for , the server selects the first location = element > > =A0 that has a profile the server understands and it can operate = either > > =A0 recursively or iteratively; elements track the progress of > the > > =A0 request. =A0The query indicates the services that the server can > > =A0 enumerate from within the forest structure of which it is a = part. > > =A0 Because LoST does not presume a single, overarching organization = of > > =A0 all potential service types, there may be services available = within > a > > =A0 geographic area that could be described by other LoST servers > > =A0 connected to other forest structures. =A0As an example, the = emergency > > =A0 services forest for a region may be distinct from the forests = that > > =A0 locate commercial services within the same region. > > > > =A0 If the query contains the element, the LoST server > returns > > =A0 only immediate child services of the queried service that are > > =A0 available for the provided location. =A0If the element = is > > =A0 absent, the LoST service returns all top-level services = available > for > > =A0 the provided location that it knows about. > > > > The current mechanism only works within a single forest structure. > > This draft is not clear, at least to me, in being scoped to a single > > forest structure, and the discussion in the room wandered around > > that topic (partly by referring to the services for which the > responding > > servers are authoritative). > > > right, the draft does not explicitly say this at the moment. > Thank you for pointing this out, it helps me understanding the > discussion better. > > > >>Currently the listServiceByLocation response does not give any > >>information on the area the service list is valid for. So a client > >>might miss a change in the available services, so it won't have the > >>dialstring configured and is not able to detect an emergency call. > > > > But there are many more available services than emergency services. > > These will also change. =A0Are we clear that this only captures = changes > > to those within a service hierarchy? > > >=20 > but you don't need to know the dialstring for pizza in advance: if you > press the pizza button on your device, it can simply do the service > discovery. >=20 > > > >>The problem arises in countries not having a single emergency > >>dialstring, like 911, but having different dialstrings for different > >>services and dialstrings as well as services depend on location. = When > >>travelling around, the availability of services may change, as well > as > >>the dialstrings. So there needs to be some kind of rule on when to > >>update the service list. Since the service boundary tells when to do > a > >>findService again, I thought it would be consistent to introduce > >>another boundary to tell the client when to update the service list > >>(as proposed in the draft). > > > > In the past, we discussed this in terms of time, rather than > movement; > > this was because the list could also change because of additions > (again, > > not so much for emergency servies, but potentially for other > services) > > >=20 > I wasn't talking about changes in time - sorry if didn't express that > clearly. Besides, the changes in time would be addressed by the > expires attribute. >=20 > > > >>Since I was just listening remotely to the discussion, I'd like to > ask > >>if I understood Ted's idea correctly: instead of a boundary > indicating > >>the area, the service list is valid for, the LoST Server should also > >>return services that are NOT available at the current location. > >>This would mean: when a client does a findService for > >>urn:service:sos.ambulance for its current location, it would also = get > >>back a mapping for urn:service:sos.physician for a different > location? > > > > No; it sounds like something got lost here. =A0I was first proposing > that > > this should be limited in applicability, essentially to a single > forest or > > service type. =A0Then I was suggesting that a server able to = traverse > that > > forest respond with a list of relevant services but without location > > boundary information for those not available in the area relevant > > to the query. =A0That is, you do a query using findServicebyLocation > for > > urn:service:geg and get back urn:service:geg.orthozog with a > boundary, > > and urn:service:geg.mumblefratz. with no boundary. =A0That avoids > > dumping the database (and the current server having to collect the > > information about where geg.mumblefratz is available); it simply > > lets the client know that there are other services out there which > > are explicitly not available at the target site of the first query. > > > > If the client wants to use geg.mumblefratz, it needs to re-query. > > It can requery at some specified time scale, or it can requery on > > only when it wants to use geg.mumblefratz. > > >=20 > hm, as I understand it, the client has still the same problem: when > does the service become available? The only information the client > gets is that this service is available "somewhere". I'm not sure this > is helpful? > Moreover, considering the emergency service case, you have to know the > dialstring right before the call. I know I'm concentrating on > emergency services... >=20 > > I was somewhat surprised, honestly, to see Henning arguing > > for this, since he has argued against this idea in the past. =A0This > > makes me suspect I am missing some subtle difference, > > and I would not be surprised to find that this is so. =A0I would > > like, however, if we did not concentrate on the emergency > > services use case to the exclusion of other use cases; that > > tends to skew the design in ways that will limit LoST's usefulness > > in other realms. >=20 > I'm afraid we need some kind of rule on when to update the service > list when travelling. And this is crucial for figuring out the > dialstings as long as there is not a single emergency dialstring all > over the world. > I'm not sure if the servicelistboundary makes much sense for other > services, since as you pointed out, they may just get discovered on > demand without any problems. > However, also the service boundary is optional in LoST, also the > servicelistboundary could just be optional and only be returned in > case the server knows it or it's about emergency services. >=20 > karl heinz >=20 > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regards, > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ted = Hardie > > > >>So when moving to this other area, the client already knows which > >>services and dialstrings are available there. > >>I'm afraid this approach would just solve the problem in case the > LoST > >>Server would dump more or less it's complete database to the client. > >>If the LoST Server would just send a couple of mappings, and others > >>not, the client could still be lost. > >>Besides, traffic and complexity for the client would increase. The > >>servicelistboundary wouldn't increase complexity too much for a > client > >>already evaluating the service boundary, since all the necessary > >>functionality should be already in place. On the server side, the > >>complexity should also be manageable (the servicelistboundary could > be > >>pre-calculated for the area the server has data for). > >> > >>Please let me know if I missed something in the discussion. > >> > >>karl heinz > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www.ietf.org/mailman/listinfo/ecrit > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From khwolf1@gmail.com Wed Jul 29 06:44:47 2009 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 176413A6F38 for ; Wed, 29 Jul 2009 06:44:47 -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 4znJHVQiI8bc for ; Wed, 29 Jul 2009 06:44:45 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 2AE253A6BD4 for ; Wed, 29 Jul 2009 06:44:44 -0700 (PDT) Received: by fxm18 with SMTP id 18so397881fxm.37 for ; Wed, 29 Jul 2009 06:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NhC9BmWS0PejiC8kcVqpktjoXay41+67lfVg6K7TLBI=; b=rl0tYP9LrWgjmYUGHbofVYbOXxYYMm3hVc+1y7q19LXCSxKONJipbrAzbsZjNdF36C UpxHqZNCqUE9Gx20F/R2NJD/K5l99JffAtDJPug2mi9AiCYbNNvG4f2K7wP6OvYoVtM+ RGvoHyAWWae3FTo8B8ZadT5NwRiCY/r+3o0IM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=s/kvJWNLpUccs8z3lHDc7PVtQAte9oeUZxR8siRbr12LwTyKei8sJUzTHHf2fsDal+ DCGh8xAgHAzISm27l6nlAhOmx2GTnqYzUA9+u1KCptf1tMx69qkCIxAPpH+df6McnyQ+ GdMo3goUUBBBF4saUYkoJu8vQKpG9ZoHqJiE8= MIME-Version: 1.0 Received: by 10.103.177.1 with SMTP id e1mr854603mup.23.1248875083346; Wed, 29 Jul 2009 06:44:43 -0700 (PDT) In-Reply-To: <024101ca1051$26a6c720$73f45560$@net> References: <024101ca1051$26a6c720$73f45560$@net> Date: Wed, 29 Jul 2009 15:44:43 +0200 Message-ID: From: Karl Heinz Wolf To: Brian Rosen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ECRIT Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting today 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, 29 Jul 2009 13:44:47 -0000 On Wed, Jul 29, 2009 at 3:33 PM, Brian Rosen wrote: > Perhaps the service URN has some sub urns, like > urn:service:servicelistboundary.sos > Brian, are you talking of sub-services, like proposed in http://tools.ietf.org/html/draft-robins-ecrit-sub-services-00 ? > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Karl Heinz Wolf >> Sent: Wednesday, July 29, 2009 9:21 AM >> To: Ted Hardie >> Cc: ECRIT >> Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting >> today >> >> Ted, >> >> thank you for your clarification. >> >> You might be correct, I probably focused too much on emergency >> services. But there it hurts the most: if you're unaware of the >> service, you don't have the dialstring and you definitely cannot >> detect the emergency call to this service. >> >> On Wed, Jul 29, 2009 at 2:27 PM, Ted Hardie wrote: >> > At 5:01 AM -0700 7/29/09, Karl Heinz Wolf wrote: >> >>There was some discussion during the meeting today on my draft >> >>http://tools.ietf.org/html/draft-wolf-ecrit-lost-servicelistboundary- >> 01 >> >> >> >>My main concern is how to ensure that a client never misses a change >> >>in available services and consequently learns all location dependent >> >>dialstrings for the current location in order to be able to detect an >> >>emergency call based on the dialstring. >> > >> > I think this is where the draft is a bit unclear. =A0Let's start from >> > what RFC 5222 says: >> > >> > =A0A LoST client can ask a LoST server for the list of services it >> knows >> > =A0 about for a particular area. =A0The query >> > =A0 contains one or more elements, each from a different >> > =A0 location profile (Section 12), and may contain the >> element. >> > =A0 As for , the server selects the first location elemen= t >> > =A0 that has a profile the server understands and it can operate eithe= r >> > =A0 recursively or iteratively; elements track the progress of >> the >> > =A0 request. =A0The query indicates the services that the server can >> > =A0 enumerate from within the forest structure of which it is a part. >> > =A0 Because LoST does not presume a single, overarching organization o= f >> > =A0 all potential service types, there may be services available withi= n >> a >> > =A0 geographic area that could be described by other LoST servers >> > =A0 connected to other forest structures. =A0As an example, the emerge= ncy >> > =A0 services forest for a region may be distinct from the forests that >> > =A0 locate commercial services within the same region. >> > >> > =A0 If the query contains the element, the LoST server >> returns >> > =A0 only immediate child services of the queried service that are >> > =A0 available for the provided location. =A0If the element i= s >> > =A0 absent, the LoST service returns all top-level services available >> for >> > =A0 the provided location that it knows about. >> > >> > The current mechanism only works within a single forest structure. >> > This draft is not clear, at least to me, in being scoped to a single >> > forest structure, and the discussion in the room wandered around >> > that topic (partly by referring to the services for which the >> responding >> > servers are authoritative). >> > >> right, the draft does not explicitly say this at the moment. >> Thank you for pointing this out, it helps me understanding the >> discussion better. >> > >> >>Currently the listServiceByLocation response does not give any >> >>information on the area the service list is valid for. So a client >> >>might miss a change in the available services, so it won't have the >> >>dialstring configured and is not able to detect an emergency call. >> > >> > But there are many more available services than emergency services. >> > These will also change. =A0Are we clear that this only captures change= s >> > to those within a service hierarchy? >> > >> >> but you don't need to know the dialstring for pizza in advance: if you >> press the pizza button on your device, it can simply do the service >> discovery. >> >> > >> >>The problem arises in countries not having a single emergency >> >>dialstring, like 911, but having different dialstrings for different >> >>services and dialstrings as well as services depend on location. When >> >>travelling around, the availability of services may change, as well >> as >> >>the dialstrings. So there needs to be some kind of rule on when to >> >>update the service list. Since the service boundary tells when to do >> a >> >>findService again, I thought it would be consistent to introduce >> >>another boundary to tell the client when to update the service list >> >>(as proposed in the draft). >> > >> > In the past, we discussed this in terms of time, rather than >> movement; >> > this was because the list could also change because of additions >> (again, >> > not so much for emergency servies, but potentially for other >> services) >> > >> >> I wasn't talking about changes in time - sorry if didn't express that >> clearly. Besides, the changes in time would be addressed by the >> expires attribute. >> >> > >> >>Since I was just listening remotely to the discussion, I'd like to >> ask >> >>if I understood Ted's idea correctly: instead of a boundary >> indicating >> >>the area, the service list is valid for, the LoST Server should also >> >>return services that are NOT available at the current location. >> >>This would mean: when a client does a findService for >> >>urn:service:sos.ambulance for its current location, it would also get >> >>back a mapping for urn:service:sos.physician for a different >> location? >> > >> > No; it sounds like something got lost here. =A0I was first proposing >> that >> > this should be limited in applicability, essentially to a single >> forest or >> > service type. =A0Then I was suggesting that a server able to traverse >> that >> > forest respond with a list of relevant services but without location >> > boundary information for those not available in the area relevant >> > to the query. =A0That is, you do a query using findServicebyLocation >> for >> > urn:service:geg and get back urn:service:geg.orthozog with a >> boundary, >> > and urn:service:geg.mumblefratz. with no boundary. =A0That avoids >> > dumping the database (and the current server having to collect the >> > information about where geg.mumblefratz is available); it simply >> > lets the client know that there are other services out there which >> > are explicitly not available at the target site of the first query. >> > >> > If the client wants to use geg.mumblefratz, it needs to re-query. >> > It can requery at some specified time scale, or it can requery on >> > only when it wants to use geg.mumblefratz. >> > >> >> hm, as I understand it, the client has still the same problem: when >> does the service become available? The only information the client >> gets is that this service is available "somewhere". I'm not sure this >> is helpful? >> Moreover, considering the emergency service case, you have to know the >> dialstring right before the call. I know I'm concentrating on >> emergency services... >> >> > I was somewhat surprised, honestly, to see Henning arguing >> > for this, since he has argued against this idea in the past. =A0This >> > makes me suspect I am missing some subtle difference, >> > and I would not be surprised to find that this is so. =A0I would >> > like, however, if we did not concentrate on the emergency >> > services use case to the exclusion of other use cases; that >> > tends to skew the design in ways that will limit LoST's usefulness >> > in other realms. >> >> I'm afraid we need some kind of rule on when to update the service >> list when travelling. And this is crucial for figuring out the >> dialstings as long as there is not a single emergency dialstring all >> over the world. >> I'm not sure if the servicelistboundary makes much sense for other >> services, since as you pointed out, they may just get discovered on >> demand without any problems. >> However, also the service boundary is optional in LoST, also the >> servicelistboundary could just be optional and only be returned in >> case the server knows it or it's about emergency services. >> >> karl heinz >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regards, >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ted Har= die >> > >> >>So when moving to this other area, the client already knows which >> >>services and dialstrings are available there. >> >>I'm afraid this approach would just solve the problem in case the >> LoST >> >>Server would dump more or less it's complete database to the client. >> >>If the LoST Server would just send a couple of mappings, and others >> >>not, the client could still be lost. >> >>Besides, traffic and complexity for the client would increase. The >> >>servicelistboundary wouldn't increase complexity too much for a >> client >> >>already evaluating the service boundary, since all the necessary >> >>functionality should be already in place. On the server side, the >> >>complexity should also be manageable (the servicelistboundary could >> be >> >>pre-calculated for the area the server has data for). >> >> >> >>Please let me know if I missed something in the discussion. >> >> >> >>karl heinz >> >>_______________________________________________ >> >>Ecrit mailing list >> >>Ecrit@ietf.org >> >>https://www.ietf.org/mailman/listinfo/ecrit >> > >> > >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > From mlinsner@cisco.com Wed Jul 29 06:53:16 2009 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 D0A6C3A6FB6 for ; Wed, 29 Jul 2009 06:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.28 X-Spam-Level: X-Spam-Status: No, score=-5.28 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JecSOYWQn17g for ; Wed, 29 Jul 2009 06:53:14 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id EFEA53A6BD4 for ; Wed, 29 Jul 2009 06:53:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAFfxb0qrR7PE/2dsb2JhbACCJTCWF6JoiCeQPgWEEQ X-IronPort-AV: E=Sophos;i="4.43,289,1246838400"; d="scan'208,217";a="220721595" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 29 Jul 2009 13:53:15 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n6TDrFeR007231 for ; Wed, 29 Jul 2009 06:53:15 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6TDrEZm014043 for ; Wed, 29 Jul 2009 13:53:15 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 09:53:15 -0400 Received: from [10.43.1.100] ([10.61.80.51]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 09:53:13 -0400 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 29 Jul 2009 15:53:08 +0200 From: Marc Linsner To: "'ecrit'" Message-ID: Thread-Topic: HUM on PhoneBCP Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQ== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3331727593_1235920" X-OriginalArrivalTime: 29 Jul 2009 13:53:13.0980 (UTC) FILETIME=[EAB8F3C0:01CA1053] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1474; t=1248875595; x=1249739595; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20HUM=20on=20PhoneBCP |Sender:=20; bh=uBdSaaA11PKUC0Qigb5A3RaXA/Ax18QHlFBB5SXDgEA=; b=BliQ6xUVgLsqfrQS545Vf2WhBxA2o4t7pgTt72rztfdoB4iGiHDQiSY9iY rOjQVcWKHuZNLg8BihAcAQRNJffirR2QNeTYeUM93MPKNXpXnYAGoElCDctM BMGNoMcKoD; Authentication-Results: sj-dkim-4; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Ecrit] HUM on 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: Wed, 29 Jul 2009 13:53:16 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3331727593_1235920 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable During today=B9s meeting there was discussion as to why the chairs Publicatio= n Requested PhoneBCP version 13 when there are unresolved issues. This discussion led us to call for a hum. We are now asking the same question o= n the list. Do you agree or disagree that PhoneBCP -13 is ready to Publication Request? Please respond by close of business on Wednesday August 5th. Thanks, Marc & Hannes --B_3331727593_1235920 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable HUM on PhoneBCP During today’s meeting there was discussion as to why the chairs Pub= lication Requested PhoneBCP version 13 when there are unresolved issues. &nb= sp;This discussion led us to call for a hum.  We are now asking the sam= e question on the list.

Do you agree or disagree that PhoneBCP -13 is ready t= o Publication Request?

Please respond by close of business on Wednesday August 5th.

Thanks,

Marc & Hannes
 --B_3331727593_1235920-- From br@brianrosen.net Wed Jul 29 06:54:46 2009 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 F0E9B3A700B for ; Wed, 29 Jul 2009 06:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFJvdeVCHDms for ; Wed, 29 Jul 2009 06:54:45 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 8C4523A6358 for ; Wed, 29 Jul 2009 06:54:45 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MW9c6-00034i-Kp; Wed, 29 Jul 2009 08:54:39 -0500 From: "Brian Rosen" To: "'Brian Rosen'" , "'Karl Heinz Wolf'" , "'Ted Hardie'" References: <024101ca1051$26a6c720$73f45560$@net> In-Reply-To: <024101ca1051$26a6c720$73f45560$@net> Date: Wed, 29 Jul 2009 09:54:41 -0400 Message-ID: <025101ca1054$218e9490$64abbdb0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoQT2eYoI99lzAqQ7e4qAhc1pM8MAAAMikwAADihnA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting today 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, 29 Jul 2009 13:54:47 -0000 Well, I was thinking of either explicitly defining a subservice, much as = we have defined sos and sos.police OR perhaps defining the urn so that any token(s) after servicelistboundary be treated as a filter for which = services were composed into the servicelistboundary, with the default being all = of the services the LoST server handles. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Wednesday, July 29, 2009 9:33 AM > To: 'Karl Heinz Wolf'; 'Ted Hardie' > Cc: 'ECRIT' > Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting > today >=20 > Perhaps the service URN has some sub urns, like > urn:service:servicelistboundary.sos >=20 >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > > Of Karl Heinz Wolf > > Sent: Wednesday, July 29, 2009 9:21 AM > > To: Ted Hardie > > Cc: ECRIT > > Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting > > today > > > > Ted, > > > > thank you for your clarification. > > > > You might be correct, I probably focused too much on emergency > > services. But there it hurts the most: if you're unaware of the > > service, you don't have the dialstring and you definitely cannot > > detect the emergency call to this service. > > > > On Wed, Jul 29, 2009 at 2:27 PM, Ted Hardie > wrote: > > > At 5:01 AM -0700 7/29/09, Karl Heinz Wolf wrote: > > >>There was some discussion during the meeting today on my draft > > >>http://tools.ietf.org/html/draft-wolf-ecrit-lost- > servicelistboundary- > > 01 > > >> > > >>My main concern is how to ensure that a client never misses a > change > > >>in available services and consequently learns all location > dependent > > >>dialstrings for the current location in order to be able to detect > an > > >>emergency call based on the dialstring. > > > > > > I think this is where the draft is a bit unclear. =A0Let's start = from > > > what RFC 5222 says: > > > > > > =A0A LoST client can ask a LoST server for the list of services it > > knows > > > =A0 about for a particular area. =A0The = query > > > =A0 contains one or more elements, each from a = different > > > =A0 location profile (Section 12), and may contain the > > element. > > > =A0 As for , the server selects the first location > element > > > =A0 that has a profile the server understands and it can operate > either > > > =A0 recursively or iteratively; elements track the progress = of > > the > > > =A0 request. =A0The query indicates the services that the server = can > > > =A0 enumerate from within the forest structure of which it is a = part. > > > =A0 Because LoST does not presume a single, overarching = organization > of > > > =A0 all potential service types, there may be services available > within > > a > > > =A0 geographic area that could be described by other LoST servers > > > =A0 connected to other forest structures. =A0As an example, the > emergency > > > =A0 services forest for a region may be distinct from the forests > that > > > =A0 locate commercial services within the same region. > > > > > > =A0 If the query contains the element, the LoST server > > returns > > > =A0 only immediate child services of the queried service that are > > > =A0 available for the provided location. =A0If the = element is > > > =A0 absent, the LoST service returns all top-level services = available > > for > > > =A0 the provided location that it knows about. > > > > > > The current mechanism only works within a single forest structure. > > > This draft is not clear, at least to me, in being scoped to a > single > > > forest structure, and the discussion in the room wandered around > > > that topic (partly by referring to the services for which the > > responding > > > servers are authoritative). > > > > > right, the draft does not explicitly say this at the moment. > > Thank you for pointing this out, it helps me understanding the > > discussion better. > > > > > >>Currently the listServiceByLocation response does not give any > > >>information on the area the service list is valid for. So a client > > >>might miss a change in the available services, so it won't have = the > > >>dialstring configured and is not able to detect an emergency call. > > > > > > But there are many more available services than emergency = services. > > > These will also change. =A0Are we clear that this only captures > changes > > > to those within a service hierarchy? > > > > > > > but you don't need to know the dialstring for pizza in advance: if > you > > press the pizza button on your device, it can simply do the service > > discovery. > > > > > > > >>The problem arises in countries not having a single emergency > > >>dialstring, like 911, but having different dialstrings for > different > > >>services and dialstrings as well as services depend on location. > When > > >>travelling around, the availability of services may change, as = well > > as > > >>the dialstrings. So there needs to be some kind of rule on when to > > >>update the service list. Since the service boundary tells when to > do > > a > > >>findService again, I thought it would be consistent to introduce > > >>another boundary to tell the client when to update the service = list > > >>(as proposed in the draft). > > > > > > In the past, we discussed this in terms of time, rather than > > movement; > > > this was because the list could also change because of additions > > (again, > > > not so much for emergency servies, but potentially for other > > services) > > > > > > > I wasn't talking about changes in time - sorry if didn't express = that > > clearly. Besides, the changes in time would be addressed by the > > expires attribute. > > > > > > > >>Since I was just listening remotely to the discussion, I'd like to > > ask > > >>if I understood Ted's idea correctly: instead of a boundary > > indicating > > >>the area, the service list is valid for, the LoST Server should > also > > >>return services that are NOT available at the current location. > > >>This would mean: when a client does a findService for > > >>urn:service:sos.ambulance for its current location, it would also > get > > >>back a mapping for urn:service:sos.physician for a different > > location? > > > > > > No; it sounds like something got lost here. =A0I was first = proposing > > that > > > this should be limited in applicability, essentially to a single > > forest or > > > service type. =A0Then I was suggesting that a server able to = traverse > > that > > > forest respond with a list of relevant services but without > location > > > boundary information for those not available in the area relevant > > > to the query. =A0That is, you do a query using = findServicebyLocation > > for > > > urn:service:geg and get back urn:service:geg.orthozog with a > > boundary, > > > and urn:service:geg.mumblefratz. with no boundary. =A0That avoids > > > dumping the database (and the current server having to collect the > > > information about where geg.mumblefratz is available); it simply > > > lets the client know that there are other services out there which > > > are explicitly not available at the target site of the first = query. > > > > > > If the client wants to use geg.mumblefratz, it needs to re-query. > > > It can requery at some specified time scale, or it can requery on > > > only when it wants to use geg.mumblefratz. > > > > > > > hm, as I understand it, the client has still the same problem: when > > does the service become available? The only information the client > > gets is that this service is available "somewhere". I'm not sure = this > > is helpful? > > Moreover, considering the emergency service case, you have to know > the > > dialstring right before the call. I know I'm concentrating on > > emergency services... > > > > > I was somewhat surprised, honestly, to see Henning arguing > > > for this, since he has argued against this idea in the past. = =A0This > > > makes me suspect I am missing some subtle difference, > > > and I would not be surprised to find that this is so. =A0I would > > > like, however, if we did not concentrate on the emergency > > > services use case to the exclusion of other use cases; that > > > tends to skew the design in ways that will limit LoST's usefulness > > > in other realms. > > > > I'm afraid we need some kind of rule on when to update the service > > list when travelling. And this is crucial for figuring out the > > dialstings as long as there is not a single emergency dialstring all > > over the world. > > I'm not sure if the servicelistboundary makes much sense for other > > services, since as you pointed out, they may just get discovered on > > demand without any problems. > > However, also the service boundary is optional in LoST, also the > > servicelistboundary could just be optional and only be returned in > > case the server knows it or it's about emergency services. > > > > karl heinz > > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regards, > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ted = Hardie > > > > > >>So when moving to this other area, the client already knows which > > >>services and dialstrings are available there. > > >>I'm afraid this approach would just solve the problem in case the > > LoST > > >>Server would dump more or less it's complete database to the > client. > > >>If the LoST Server would just send a couple of mappings, and = others > > >>not, the client could still be lost. > > >>Besides, traffic and complexity for the client would increase. The > > >>servicelistboundary wouldn't increase complexity too much for a > > client > > >>already evaluating the service boundary, since all the necessary > > >>functionality should be already in place. On the server side, the > > >>complexity should also be manageable (the servicelistboundary = could > > be > > >>pre-calculated for the area the server has data for). > > >> > > >>Please let me know if I missed something in the discussion. > > >> > > >>karl heinz > > >>_______________________________________________ > > >>Ecrit mailing list > > >>Ecrit@ietf.org > > >>https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From Martin.Thomson@andrew.com Wed Jul 29 06:58:34 2009 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 99F243A70DF for ; Wed, 29 Jul 2009 06:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.034, 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 U+9Eacayp5Mp for ; Wed, 29 Jul 2009 06:58:33 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id A59FF3A70DB for ; Wed, 29 Jul 2009 06:58:33 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_29_09_21_06 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 29 Jul 2009 09:21:06 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 08:58:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1054.A92802DC" Date: Wed, 29 Jul 2009 08:58:31 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQAALEfw References: From: "Thomson, Martin" To: "Marc Linsner" , "ecrit" X-OriginalArrivalTime: 29 Jul 2009 13:58:33.0922 (UTC) FILETIME=[A96C3A20:01CA1054] Subject: Re: [Ecrit] HUM on 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: Wed, 29 Jul 2009 13:58:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1054.A92802DC Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGRvY3VtZW50IGlzIHJlYWR5Lg0KDQogDQoNCkZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyYyBMaW5z bmVyDQpTZW50OiBXZWRuZXNkYXksIDI5IEp1bHkgMjAwOSAzOjUzIFBNDQpUbzogJ2Vjcml0Jw0K U3ViamVjdDogW0Vjcml0XSBIVU0gb24gUGhvbmVCQ1ANCg0KIA0KDQpEdXJpbmcgdG9kYXnigJlz IG1lZXRpbmcgdGhlcmUgd2FzIGRpc2N1c3Npb24gYXMgdG8gd2h5IHRoZSBjaGFpcnMgUHVibGlj YXRpb24gUmVxdWVzdGVkIFBob25lQkNQIHZlcnNpb24gMTMgd2hlbiB0aGVyZSBhcmUgdW5yZXNv bHZlZCBpc3N1ZXMuICBUaGlzIGRpc2N1c3Npb24gbGVkIHVzIHRvIGNhbGwgZm9yIGEgaHVtLiAg V2UgYXJlIG5vdyBhc2tpbmcgdGhlIHNhbWUgcXVlc3Rpb24gb24gdGhlIGxpc3QuDQoNCkRvIHlv dSBhZ3JlZSBvciBkaXNhZ3JlZSB0aGF0IFBob25lQkNQIC0xMyBpcyByZWFkeSB0byBQdWJsaWNh dGlvbiBSZXF1ZXN0Pw0KDQpQbGVhc2UgcmVzcG9uZCBieSBjbG9zZSBvZiBidXNpbmVzcyBvbiBX ZWRuZXNkYXkgQXVndXN0IDV0aC4NCg0KVGhhbmtzLA0KDQpNYXJjICYgSGFubmVzDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0 aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQs IHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91 IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1t ZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBv Zg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpbbWYyXQ0K ------_=_NextPart_001_01CA1054.A92802DC Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDov L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KDQo8bWV0YSBuYW1lPUdlbmVy YXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8dGl0 bGU+SFVNIG9uIFBob25lQkNQPC90aXRsZT4NCjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmlu aXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglw YW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQog LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMyNDQwNjE7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCg0KPGJvZHkgbGFuZz1FTi1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2IGNs YXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMyNDQw NjEnPlRoZSBkb2N1bWVudCBpcyByZWFkeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPg0KDQo8ZGl2Pg0KDQo8ZGl2IHN0 eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSc+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KIlRhaG9tYSIsInNhbnMt c2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IGVjcml0LWJvdW5j ZXNAaWV0Zi5vcmcNClttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxm IE9mIDwvYj5NYXJjIExpbnNuZXI8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCAyOSBKdWx5 IDIwMDkgMzo1MyBQTTxicj4NCjxiPlRvOjwvYj4gJ2Vjcml0Jzxicj4NCjxiPlN1YmplY3Q6PC9i PiBbRWNyaXRdIEhVTSBvbiBQaG9uZUJDUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+ DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5EdXJpbmcNCnRvZGF54oCZcyBtZWV0aW5nIHRo ZXJlIHdhcyBkaXNjdXNzaW9uIGFzIHRvIHdoeSB0aGUgY2hhaXJzIFB1YmxpY2F0aW9uIFJlcXVl c3RlZA0KUGhvbmVCQ1AgdmVyc2lvbiAxMyB3aGVuIHRoZXJlIGFyZSB1bnJlc29sdmVkIGlzc3Vl cy4gJm5ic3A7VGhpcyBkaXNjdXNzaW9uIGxlZA0KdXMgdG8gY2FsbCBmb3IgYSBodW0uICZuYnNw O1dlIGFyZSBub3cgYXNraW5nIHRoZSBzYW1lIHF1ZXN0aW9uIG9uIHRoZSBsaXN0Ljxicj4NCjxi cj4NCjxzcGFuIHN0eWxlPSdjb2xvcjojMTIxMjEyJz5EbyB5b3UgYWdyZWUgb3IgZGlzYWdyZWUg dGhhdCBQaG9uZUJDUCAtMTMgaXMgcmVhZHkNCnRvIFB1YmxpY2F0aW9uIFJlcXVlc3Q/PGJyPg0K PGJyPg0KUGxlYXNlIHJlc3BvbmQgYnkgY2xvc2Ugb2YgYnVzaW5lc3Mgb24gV2VkbmVzZGF5IEF1 Z3VzdCA1dGguPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCjxicj4NCk1hcmMgJmFtcDsgSGFubmVz PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8YnI+ PGJyPjx0YWJsZSBiZ2NvbG9yPXdoaXRlIHN0eWxlPSJjb2xvcjpibGFjayI+PHRyPjx0ZD48YnI+ LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KVGhpcyZuYnNwO21l c3NhZ2UmbmJzcDtpcyZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO2Rlc2lnbmF0ZWQmbmJzcDtyZWNp cGllbnQmbmJzcDtvbmx5Jm5ic3A7YW5kJm5ic3A7bWF5PGJyPg0KY29udGFpbiZuYnNwO3ByaXZp bGVnZWQsJm5ic3A7cHJvcHJpZXRhcnksJm5ic3A7b3ImbmJzcDtvdGhlcndpc2UmbmJzcDtwcml2 YXRlJm5ic3A7aW5mb3JtYXRpb24uJm5ic3A7Jm5ic3A7PGJyPg0KSWYmbmJzcDt5b3UmbmJzcDto YXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDtpdCZuYnNwO2luJm5ic3A7ZXJyb3IsJm5ic3A7cGxlYXNl Jm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7c2VuZGVyPGJyPg0KaW1tZWRpYXRlbHkmbmJzcDth bmQmbmJzcDtkZWxldGUmbmJzcDt0aGUmbmJzcDtvcmlnaW5hbC4mbmJzcDsmbmJzcDtBbnkmbmJz cDt1bmF1dGhvcml6ZWQmbmJzcDt1c2UmbmJzcDtvZjxicj4NCnRoaXMmbmJzcDtlbWFpbCZuYnNw O2lzJm5ic3A7cHJvaGliaXRlZC48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQpbbWYyXTwvdGQ+PC90cj48L3RhYmxlPjwvYm9keT4NCg0KPC9odG1sPg0K ------_=_NextPart_001_01CA1054.A92802DC-- From br@brianrosen.net Wed Jul 29 07:01:23 2009 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 7F6E13A70C5 for ; Wed, 29 Jul 2009 07:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.030, 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 M9JAa188Ijws for ; Wed, 29 Jul 2009 07:01:20 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 6FDA53A70E5 for ; Wed, 29 Jul 2009 07:01:20 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MW9iU-0003La-Fm; Wed, 29 Jul 2009 09:01:14 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , "'ecrit'" References: In-Reply-To: Date: Wed, 29 Jul 2009 10:01:17 -0400 Message-ID: <026601ca1055$0d86c0c0$28944240$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0267_01CA1033.867520C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQAASC1g Content-Language: en-us 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] HUM on 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: Wed, 29 Jul 2009 14:01:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0267_01CA1033.867520C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Agree From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Wednesday, July 29, 2009 9:53 AM To: 'ecrit' Subject: [Ecrit] HUM on PhoneBCP During today's meeting there was discussion as to why the chairs Publication Requested PhoneBCP version 13 when there are unresolved issues. This discussion led us to call for a hum. We are now asking the same question on the list. Do you agree or disagree that PhoneBCP -13 is ready to Publication Request? Please respond by close of business on Wednesday August 5th. Thanks, Marc & Hannes ------=_NextPart_000_0267_01CA1033.867520C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HUM on PhoneBCP

Agree

 

From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of = Marc Linsner
Sent: Wednesday, July 29, 2009 9:53 AM
To: 'ecrit'
Subject: [Ecrit] HUM on PhoneBCP

 

During today’s meeting there was discussion as to why the chairs = Publication Requested PhoneBCP version 13 when there are unresolved issues.  This = discussion led us to call for a hum.  We are now asking the same question on the = list.

Do you agree or disagree that PhoneBCP -13 = is ready to Publication Request?

Please respond by close of business on Wednesday August 5th.

Thanks,

Marc & Hannes

------=_NextPart_000_0267_01CA1033.867520C0-- From rbarnes@bbn.com Wed Jul 29 07:12:40 2009 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 718533A70E0 for ; Wed, 29 Jul 2009 07:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 XEhoa4iiV3w9 for ; Wed, 29 Jul 2009 07:12:39 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 965E13A706F for ; Wed, 29 Jul 2009 07:12:39 -0700 (PDT) Received: from [128.89.254.19] (helo=dhcp-14e6.meeting.ietf.org) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1MW9tW-0006fV-CO; Wed, 29 Jul 2009 10:12:39 -0400 Message-ID: <4A7058D5.9090704@bbn.com> Date: Wed, 29 Jul 2009 16:12:37 +0200 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Brian Rosen References: <026601ca1055$0d86c0c0$28944240$@net> In-Reply-To: <026601ca1055$0d86c0c0$28944240$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'ecrit' Subject: Re: [Ecrit] HUM on 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: Wed, 29 Jul 2009 14:12:40 -0000 +1 Brian Rosen wrote: > Agree > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Marc Linsner > Sent: Wednesday, July 29, 2009 9:53 AM > To: 'ecrit' > Subject: [Ecrit] HUM on PhoneBCP > > > > During today's meeting there was discussion as to why the chairs Publication > Requested PhoneBCP version 13 when there are unresolved issues. This > discussion led us to call for a hum. We are now asking the same question on > the list. > > Do you agree or disagree that PhoneBCP -13 is ready to Publication Request? > > Please respond by close of business on Wednesday August 5th. > > Thanks, > > Marc & Hannes > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From MILANPA@nortel.com Wed Jul 29 07:16:04 2009 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 E43E83A6A72 for ; Wed, 29 Jul 2009 07:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmqnA0gMj9BE for ; Wed, 29 Jul 2009 07:16:04 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 600123A6B46 for ; Wed, 29 Jul 2009 07:16:03 -0700 (PDT) Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6TEFu110179; Wed, 29 Jul 2009 14:15:56 GMT 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: Wed, 29 Jul 2009 15:15:48 +0100 Message-ID: <0913B6CD18F370498CD65864CF254E900A70EEC9@zharhxm1.corp.nortel.com> In-Reply-To: <4A7058D5.9090704@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoQVqa9Sh39LTWQT8+igh8KzN5/DAAAEGuA References: <026601ca1055$0d86c0c0$28944240$@net> <4A7058D5.9090704@bbn.com> From: "Milan Patel" To: "Richard Barnes" , "Brian Rosen" Cc: ecrit Subject: Re: [Ecrit] HUM on 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: Wed, 29 Jul 2009 14:16:05 -0000 Humming in agreement Regards, Milan -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Richard Barnes Sent: 29 July 2009 15:13 To: Brian Rosen Cc: 'ecrit' Subject: Re: [Ecrit] HUM on PhoneBCP +1 Brian Rosen wrote: > Agree >=20 > =20 >=20 > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Marc Linsner > Sent: Wednesday, July 29, 2009 9:53 AM > To: 'ecrit' > Subject: [Ecrit] HUM on PhoneBCP >=20 > =20 >=20 > During today's meeting there was discussion as to why the chairs Publication > Requested PhoneBCP version 13 when there are unresolved issues. This > discussion led us to call for a hum. We are now asking the same question on > the list. >=20 > Do you agree or disagree that PhoneBCP -13 is ready to Publication Request? >=20 > Please respond by close of business on Wednesday August 5th. >=20 > Thanks, >=20 > Marc & Hannes >=20 >=20 >=20 >=20 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From hardie@qualcomm.com Wed Jul 29 07:42:49 2009 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 957073A6EA3 for ; Wed, 29 Jul 2009 07:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzwP2mKoDT0o for ; Wed, 29 Jul 2009 07:42:48 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 4CF703A6E5A for ; Wed, 29 Jul 2009 07:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1248878570; x=1280414570; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20|References:=20|Date:=20Wed,=2029=20Jul=202009=2016:42:41=20+0200 |To:=20Marc=20Linsner=20,=20"'ecrit'" =20|From:=20Ted=20Hardie=20|Subject:=20Re:=20[Ecrit]=20HUM=20on=20PhoneBCP |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5691"=3B=20 a=3D"21400394"; bh=tOzejpfg0BTe7jQp/ZwUfKIT9ln2tRlLFE27PawHsxo=; b=xo580cqPruW3e77d3IJsHQNGrX21ivhGjsFlyOr37N1HGd+0hzVuWqrB cel1GZqBixPgK74Kf23b2LEVOg7vwiVmWvAXTS/xvKmRQOFlPoEFdJxE5 phKeZn08yAfGJQ1pizXR0vkvMv0Ylk0FnmokRZGSmf3nOJSGUXdR78Eah w=; X-IronPort-AV: E=McAfee;i="5300,2777,5691"; a="21400394" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jul 2009 07:42:49 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6TEgnjO015360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Jul 2009 07:42:49 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6TEgkB2029043 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Jul 2009 07:42:49 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 29 Jul 2009 07:42:48 -0700 Received: from [130.129.80.242] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 29 Jul 2009 07:42:47 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: References: Date: Wed, 29 Jul 2009 16:42:41 +0200 To: Marc Linsner , "'ecrit'" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Subject: Re: [Ecrit] HUM on 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: Wed, 29 Jul 2009 14:42:50 -0000 At 6:53 AM -0700 7/29/09, Marc Linsner wrote: >During today's meeting there was discussion as to why the chairs Publication Requested PhoneBCP version 13 when there are unresolved issues. This discussion led us to call for a hum. We are now asking the same question on the list. > >Do you agree or disagree that PhoneBCP -13 is ready to Publication Request? > >Please respond by close of business on Wednesday August 5th. > >Thanks, > >Marc & Hannes I disagree. Ted >Content-Type: text/plain; name="ATT00001.txt" >Content-Description: ATT00001.txt >Content-Disposition: attachment; filename="ATT00001.txt"; size=194; > creation-date="Wed, 29 Jul 2009 06:54:03 GMT"; > modification-date="Wed, 29 Jul 2009 06:54:03 GMT" > >Attachment converted: Macintosh HD:ATT00001 7461.txt (TEXT/ttxt) (005CACE1) From ngwilcox@gmail.com Wed Jul 29 07:49:39 2009 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 3385C3A6830 for ; Wed, 29 Jul 2009 07:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4CvFxv5o5DN for ; Wed, 29 Jul 2009 07:49:38 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 1FC1C3A67F4 for ; Wed, 29 Jul 2009 07:49:20 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so457014qwd.31 for ; Wed, 29 Jul 2009 07:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1e6XihSoWEPP/gRW3MUPdfIOP6tUdpGl6jFDkBxEIF0=; b=bv/m2YlJlxH3fe9PCVv6uc9DuDLi/V7zHggLaVOSOLicPVhUV6tQTQsyUGbiCRL5+f QbZRGFLUSkP5cdWjZPKQUtKlDdfpbpOC9sNPx628j6RUNpugX7unapUud5PxmamEce9A PvgLpn7y9b9FAuIzMqu2dyva3hQDQ0m5GuVSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=a/h3QcVyUnHahlUgD02jqG5+6JOUszUBKPdG5/shnndNXQtG8i7hnWPwgorM8SgZ6M i9QSNBNl1AFL7wLhEGFqCSi4z0Rvo6CXbGWhhgMleleoj+YLVuEU611F2zAVzbQLomxd iGSNbyXIR2Dz9y+OGYAZCcH+onOik4aCFr0IE= MIME-Version: 1.0 Received: by 10.231.14.9 with SMTP id e9mr2825261iba.45.1248878959726; Wed, 29 Jul 2009 07:49:19 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Jul 2009 10:49:19 -0400 Message-ID: <181f29c0907290749q662bdfc3u7e80e42d9dd0f252@mail.gmail.com> From: Nate Wilcox To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ecrit Subject: Re: [Ecrit] HUM on 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: Wed, 29 Jul 2009 14:49:39 -0000 It's ready On Wed, Jul 29, 2009 at 10:42 AM, Ted Hardie wrote: > At 6:53 AM -0700 7/29/09, Marc Linsner wrote: >>During today's meeting there was discussion as to why the chairs Publicat= ion Requested PhoneBCP version 13 when there are unresolved issues. =A0This= discussion led us to call for a hum. =A0We are now asking the same questio= n on the list. >> >>Do you agree or disagree that PhoneBCP -13 is ready to Publication Reques= t? >> >>Please respond by close of business on Wednesday August 5th. >> >>Thanks, >> >>Marc & Hannes > > I disagree. > > Ted > > >>Content-Type: text/plain; name=3D"ATT00001.txt" >>Content-Description: ATT00001.txt >>Content-Disposition: attachment; filename=3D"ATT00001.txt"; size=3D194; >> =A0 =A0 =A0 creation-date=3D"Wed, 29 Jul 2009 06:54:03 GMT"; >> =A0 =A0 =A0 modification-date=3D"Wed, 29 Jul 2009 06:54:03 GMT" >> >>Attachment converted: Macintosh HD:ATT00001 7461.txt (TEXT/ttxt) (005CACE= 1) > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From bernard_aboba@hotmail.com Wed Jul 29 08:00:19 2009 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 6D4653A6EA5 for ; Wed, 29 Jul 2009 08:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[AWL=1.122, 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 vZ22rXN6pdnN for ; Wed, 29 Jul 2009 08:00:18 -0700 (PDT) Received: from blu0-omc4-s29.blu0.hotmail.com (blu0-omc4-s29.blu0.hotmail.com [65.55.111.168]) by core3.amsl.com (Postfix) with ESMTP id 66D523A6DFD for ; Wed, 29 Jul 2009 08:00:18 -0700 (PDT) Received: from BLU137-W35 ([65.55.111.136]) by blu0-omc4-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 08:00:20 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_3d8dc9ab-0fbf-422c-be1d-12287beee38e_" X-Originating-IP: [130.129.22.186] From: Bernard Aboba To: Date: Wed, 29 Jul 2009 08:00:20 -0700 Importance: Normal In-Reply-To: <0913B6CD18F370498CD65864CF254E900A70EEC9@zharhxm1.corp.nortel.com> References: <026601ca1055$0d86c0c0$28944240$@net> <4A7058D5.9090704@bbn.com> <0913B6CD18F370498CD65864CF254E900A70EEC9@zharhxm1.corp.nortel.com> MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jul 2009 15:00:20.0110 (UTC) FILETIME=[4A7BA2E0:01CA105D] Cc: ecrit@ietf.org Subject: Re: [Ecrit] HUM on 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: Wed, 29 Jul 2009 15:00:19 -0000 --_3d8dc9ab-0fbf-422c-be1d-12287beee38e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 > Date: Wed=2C 29 Jul 2009 15:15:48 +0100 > From: milanpa@nortel.com > To: rbarnes@bbn.com=3B br@brianrosen.net > CC: ecrit@ietf.org > Subject: Re: [Ecrit] HUM on PhoneBCP >=20 > Humming in agreement >=20 > Regards=2C > Milan >=20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Richard Barnes > Sent: 29 July 2009 15:13 > To: Brian Rosen > Cc: 'ecrit' > Subject: Re: [Ecrit] HUM on PhoneBCP >=20 > +1 >=20 > Brian Rosen wrote: > > Agree > >=20 > >=20 > >=20 > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Marc Linsner > > Sent: Wednesday=2C July 29=2C 2009 9:53 AM > > To: 'ecrit' > > Subject: [Ecrit] HUM on PhoneBCP > >=20 > >=20 > >=20 > > During today's meeting there was discussion as to why the chairs > Publication > > Requested PhoneBCP version 13 when there are unresolved issues. This > > discussion led us to call for a hum. We are now asking the same > question on > > the list. > >=20 > > Do you agree or disagree that PhoneBCP -13 is ready to Publication > Request? > >=20 > > Please respond by close of business on Wednesday August 5th. > >=20 > > Thanks=2C > >=20 > > Marc & Hannes > >=20 > >=20 > >=20 > >=20 > > > ------------------------------------------------------------------------ > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --_3d8dc9ab-0fbf-422c-be1d-12287beee38e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1

>=3B Date: Wed=2C 29 Jul 2009 15:15:48 +0100
>=3B From: mi= lanpa@nortel.com
>=3B To: rbarnes@bbn.com=3B br@brianrosen.net
>= =3B CC: ecrit@ietf.org
>=3B Subject: Re: [Ecrit] HUM on PhoneBCP
&g= t=3B
>=3B Humming in agreement
>=3B
>=3B Regards=2C
>= =3B Milan
>=3B
>=3B
>=3B -----Original Message-----
>= =3B From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf<= BR>>=3B Of Richard Barnes
>=3B Sent: 29 July 2009 15:13
>=3B To= : Brian Rosen
>=3B Cc: 'ecrit'
>=3B Subject: Re: [Ecrit] HUM on P= honeBCP
>=3B
>=3B +1
>=3B
>=3B Brian Rosen wrote:
= >=3B >=3B Agree
>=3B >=3B
>=3B >=3B
>=3B >=3B >=3B >=3B From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf
>=3B Of
>=3B >=3B Marc Linsner
>=3B >=3B Sen= t: Wednesday=2C July 29=2C 2009 9:53 AM
>=3B >=3B To: 'ecrit'
>= =3B >=3B Subject: [Ecrit] HUM on PhoneBCP
>=3B >=3B
>=3B >= =3B
>=3B >=3B
>=3B >=3B During today's meeting there was di= scussion as to why the chairs
>=3B Publication
>=3B >=3B Reques= ted PhoneBCP version 13 when there are unresolved issues. This
>=3B &g= t=3B discussion led us to call for a hum. We are now asking the same
>= =3B question on
>=3B >=3B the list.
>=3B >=3B
>=3B >= =3B Do you agree or disagree that PhoneBCP -13 is ready to Publication
&= gt=3B Request?
>=3B >=3B
>=3B >=3B Please respond by close o= f business on Wednesday August 5th.
>=3B >=3B
>=3B >=3B Than= ks=2C
>=3B >=3B
>=3B >=3B Marc &=3B Hannes
>=3B >= =3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B=
>=3B ----------------------------------------------------------------= --------
>=3B >=3B
>=3B >=3B _______________________________= ________________
>=3B >=3B Ecrit mailing list
>=3B >=3B Ecrit= @ietf.org
>=3B >=3B https://www.ietf.org/mailman/listinfo/ecrit
&= gt=3B _______________________________________________
>=3B Ecrit maili= ng list
>=3B Ecrit@ietf.org
>=3B https://www.ietf.org/mailman/lis= tinfo/ecrit
>=3B _______________________________________________
&g= t=3B Ecrit mailing list
>=3B Ecrit@ietf.org
>=3B https://www.ietf= .org/mailman/listinfo/ecrit
= --_3d8dc9ab-0fbf-422c-be1d-12287beee38e_-- From gunnar.hellstrom@omnitor.se Wed Jul 29 08:12:15 2009 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 7AE373A6D91 for ; Wed, 29 Jul 2009 08:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 Ybv3hlWjobZD for ; Wed, 29 Jul 2009 08:12:12 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by core3.amsl.com (Postfix) with ESMTP id 1B3693A6AA1 for ; Wed, 29 Jul 2009 08:12:11 -0700 (PDT) Received: (qmail 27303 invoked from network); 29 Jul 2009 15:12:16 -0000 Received: from s34.loopia.se (HELO s42.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 29 Jul 2009 15:12:16 -0000 Received: (qmail 62042 invoked from network); 29 Jul 2009 15:12:01 -0000 Received: from dhcp-1465.meeting.ietf.org (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[130.129.20.101]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with SMTP for ; 29 Jul 2009 15:12:01 -0000 From: "Gunnar Hellstrom" To: "'Marc Linsner'" , "'ecrit'" References: Date: Wed, 29 Jul 2009 17:12:03 +0200 Message-ID: <00ae01ca105e$edb060d0$65148182@GunnarH> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AF_01CA106F.B13930D0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACuyKQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: Subject: Re: [Ecrit] HUM on 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: Wed, 29 Jul 2009 15:12:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00AF_01CA106F.B13930D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I agree. Gunnar _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Wednesday, July 29, 2009 3:53 PM To: 'ecrit' Subject: [Ecrit] HUM on PhoneBCP During today's meeting there was discussion as to why the chairs Publication Requested PhoneBCP version 13 when there are unresolved issues. This discussion led us to call for a hum. We are now asking the same question on the list. Do you agree or disagree that PhoneBCP -13 is ready to Publication Request? Please respond by close of business on Wednesday August 5th. Thanks, Marc & Hannes ------=_NextPart_000_00AF_01CA106F.B13930D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HUM on PhoneBCP
I=20 agree.
 
Gunnar

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc = Linsner
Sent:=20 Wednesday, July 29, 2009 3:53 PM
To: = 'ecrit'
Subject:=20 [Ecrit] HUM on PhoneBCP

During today’s meeting there was = discussion as to why=20 the chairs Publication Requested PhoneBCP version 13 when there are = unresolved=20 issues.  This discussion led us to call for a hum.  We are now = asking=20 the same question on the list.

Do you agree = or=20 disagree that PhoneBCP -13 is ready to Publication = Request?

Please=20 respond by close of business on Wednesday August = 5th.

Thanks,

Marc=20 & Hannes
 ------=_NextPart_000_00AF_01CA106F.B13930D0-- From James.Winterbottom@andrew.com Wed Jul 29 13:44:04 2009 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 DA99F3A6B47 for ; Wed, 29 Jul 2009 13:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, 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 yaSGjEE0gfZJ for ; Wed, 29 Jul 2009 13:44:04 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 426803A6EC6 for ; Wed, 29 Jul 2009 13:43:33 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_29_16_06_06 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 29 Jul 2009 16:06:05 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 15:43:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Jul 2009 15:43:27 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQAALEfwAA4oUms= References: From: "Winterbottom, James" To: "Thomson, Martin" , "Marc Linsner" , "ecrit" X-OriginalArrivalTime: 29 Jul 2009 20:43:33.0042 (UTC) FILETIME=[3CD3B120:01CA108D] Subject: Re: [Ecrit] HUM on 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: Wed, 29 Jul 2009 20:44:04 -0000 =0D=0A+1=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: ecrit-bounces@iet= f.org on behalf of Thomson, Martin=0D=0ASent: Wed 7/29/2009 8:58 AM=0D=0ATo= : Marc Linsner; ecrit=0D=0ASubject: Re: [Ecrit] HUM on PhoneBCP=0D=0A=20=0D= =0AThe document is ready.=0D=0A=0D=0A=20=0D=0A=0D=0AFrom: ecrit-bounces@iet= f.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner=0D=0ASent: = Wednesday, 29 July 2009 3:53 PM=0D=0ATo: 'ecrit'=0D=0ASubject: [Ecrit] HUM = on PhoneBCP=0D=0A=0D=0A=20=0D=0A=0D=0ADuring today's meeting there was disc= ussion as to why the chairs Publication Requested PhoneBCP version 13 when = there are unresolved issues. This discussion led us to call for a hum. We= are now asking the same question on the list.=0D=0A=0D=0ADo you agree or d= isagree that PhoneBCP -13 is ready to Publication Request=3F=0D=0A=0D=0APle= ase respond by close of business on Wednesday August 5th.=0D=0A=0D=0AThanks= ,=0D=0A=0D=0AMarc & Hannes=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A-------------------= ---------------------------------------------------------------------------= --=0D=0AThis message is for the designated recipient only and may=0D=0Acont= ain privileged, proprietary, or otherwise private information. =20=0D=0AIf = you have received it in error, please notify the sender=0D=0Aimmediately an= d delete the original. Any unauthorized use of=0D=0Athis email is prohibit= ed.=0D=0A------------------------------------------------------------------= ------------------------------=0D=0A[mf2]=09=0D=0A=0D=0A-------------------= ---------------------------------------------------------------------------= --=0D=0AThis message is for the designated recipient only and may=0D=0Acont= ain privileged, proprietary, or otherwise private information. =20=0D=0AIf = you have received it in error, please notify the sender=0D=0Aimmediately an= d delete the original. Any unauthorized use of=0D=0Athis email is prohibit= ed.=0D=0A------------------------------------------------------------------= ------------------------------=0D=0A[mf2]=0D=0A From jmpolk@cisco.com Wed Jul 29 16:44:39 2009 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 697BD3A63C9 for ; Wed, 29 Jul 2009 16:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.651, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jx3Qh67YseoC for ; Wed, 29 Jul 2009 16:44:38 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 7DB123A6808 for ; Wed, 29 Jul 2009 16:44:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0IAGh7cEqrR7PD/2dsb2JhbACISJAkolmIJ5AgBYQR X-IronPort-AV: E=Sophos;i="4.43,290,1246838400"; d="scan'208";a="40221745" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 29 Jul 2009 23:44:40 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6TNiesn032082; Wed, 29 Jul 2009 16:44:40 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6TNieIc021794; Wed, 29 Jul 2009 23:44:40 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 16:44:39 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.13.29]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 16:44:39 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 29 Jul 2009 17:51:05 -0500 To: "Thomson, Martin" , "Marc Linsner" , "ecrit" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: 29 Jul 2009 23:44:39.0362 (UTC) FILETIME=[89A88A20:01CA10A6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1505; t=1248911080; x=1249775080; 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]=20HUM=20on=20PhoneBCP |Sender:=20; bh=Mr1a+1uVYrrqSzzX1XIFk6V7JLMx2fOyYeCADoaHJDs=; b=bBdYJfxtbnBbBTSJEY4CwcaspKOwhTWwGZKe0SF/Pwczp5sz5W50cH6nby soQyjZLnz/GoMsT++1MdD/iYGBDSeF4QCN/smwND61dOR/d9D2EDhIpz797p UtIPP3q7j8; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Ecrit] HUM on 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: Wed, 29 Jul 2009 23:44:39 -0000 At 08:58 AM 7/29/2009, Thomson, Martin wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary=3D"----_=3D_NextPart_001_01CA1054.A92802DC" > >The document is ready. I agree > >From: ecrit-bounces@ietf.org=20 >[mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner >Sent: Wednesday, 29 July 2009 3:53 PM >To: 'ecrit' >Subject: [Ecrit] HUM on PhoneBCP > >During today=E2=80=99s meeting there was discussion as=20 >to why the chairs Publication Requested PhoneBCP=20 >version 13 when there are unresolved=20 >issues. This discussion led us to call for a=20 >hum. We are now asking the same question on the list. > >Do you agree or disagree that PhoneBCP -13 is ready to Publication Request? > >Please respond by close of business on Wednesday August 5th. > >Thanks, > >Marc & Hannes > > > >---------------------------------------------------------------------------= --------------------- >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >---------------------------------------------------------------------------= --------------------- >[mf2] >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From bsmith@indigital.net Wed Jul 29 17:01:10 2009 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 5DD513A690A for ; Wed, 29 Jul 2009 17:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7l8oIPPo1nm for ; Wed, 29 Jul 2009 17:01:09 -0700 (PDT) Received: from mail-pz0-f184.google.com (mail-pz0-f184.google.com [209.85.222.184]) by core3.amsl.com (Postfix) with ESMTP id 84A963A688B for ; Wed, 29 Jul 2009 17:01:09 -0700 (PDT) Received: by pzk14 with SMTP id 14so196263pzk.29 for ; Wed, 29 Jul 2009 17:01:09 -0700 (PDT) Received: by 10.141.13.19 with SMTP id q19mr339337rvi.31.1248912069346; Wed, 29 Jul 2009 17:01:09 -0700 (PDT) Received: from ?10.1.1.107? (static-98-108-98-36.sbndin.dsl-w.verizon.net [98.108.98.36]) by mx.google.com with ESMTPS id f42sm8580529rvb.35.2009.07.29.17.01.06 (version=SSLv3 cipher=RC4-MD5); Wed, 29 Jul 2009 17:01:07 -0700 (PDT) Message-ID: <4A70E289.5050906@indigital.net> Date: Wed, 29 Jul 2009 20:00:09 -0400 From: Byron Smith Organization: INdigital Telecom User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: 'ecrit' References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bsmith@indigital.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 00:01:10 -0000 Agree. Byron Marc Linsner wrote: > During today’s meeting there was discussion as to why the chairs > Publication Requested PhoneBCP version 13 when there are unresolved > issues. This discussion led us to call for a hum. We are now asking > the same question on the list. > > Do you agree or disagree that PhoneBCP -13 is ready to Publication > Request? > > Please respond by close of business on Wednesday August 5th. > > Thanks, > > Marc & Hannes > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From Martin.Dawson@andrew.com Wed Jul 29 17:41:49 2009 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 ADA2E3A7104 for ; Wed, 29 Jul 2009 17:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNULLwQ+c3Eq for ; Wed, 29 Jul 2009 17:41:49 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id C56EC3A7101 for ; Wed, 29 Jul 2009 17:41:48 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_29_20_04_23 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 29 Jul 2009 20:04:22 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 19:41:49 -0500 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: Wed, 29 Jul 2009 19:41:44 -0500 Message-ID: In-Reply-To: <4A70E289.5050906@indigital.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoQqNqQb3fcg+rgSimXIWi33WsOGQABaU/A References: <4A70E289.5050906@indigital.net> From: "Dawson, Martin" To: , "ecrit" X-OriginalArrivalTime: 30 Jul 2009 00:41:49.0920 (UTC) FILETIME=[866E2600:01CA10AE] Subject: Re: [Ecrit] HUM on 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: Thu, 30 Jul 2009 00:41:50 -0000 +1=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: ecrit-bounces@ietf.org = [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0AOf Byron Smith=0D=0ASent: Th= ursday, 30 July 2009 10:00 AM=0D=0ATo: 'ecrit'=0D=0ASubject: Re: [Ecrit] HU= M on PhoneBCP=0D=0A=0D=0AAgree.=0D=0A=0D=0AByron=0D=0A=0D=0AMarc Linsner wr= ote:=0D=0A> During today's meeting there was discussion as to why the chair= s=20=0D=0A> Publication Requested PhoneBCP version 13 when there are unreso= lved=20=0D=0A> issues. This discussion led us to call for a hum. We are now= asking=20=0D=0A> the same question on the list.=0D=0A>=0D=0A> Do you agree= or disagree that PhoneBCP -13 is ready to Publication=20=0D=0A> Request=3F=0D= =0A>=0D=0A> Please respond by close of business on Wednesday August 5th.=0D= =0A>=0D=0A> Thanks,=0D=0A>=0D=0A> Marc & Hannes=0D=0A>=0D=0A---------------= ---------------------------------------------------------=0D=0A>=0D=0A> ___= ____________________________________________=0D=0A> Ecrit mailing list=0D=0A= > Ecrit@ietf.org=0D=0A> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A> = =20=0D=0A=0D=0A_______________________________________________=0D=0AEcrit = mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman/listinfo= /ecrit=0D=0A=0D=0A---------------------------------------------------------= ---------------------------------------=0D=0AThis message is for the design= ated recipient only and may=0D=0Acontain privileged, proprietary, or otherw= ise private information. =20=0D=0AIf you have received it in error, please = notify the sender=0D=0Aimmediately and delete the original. Any unauthoriz= ed use of=0D=0Athis email is prohibited.=0D=0A-----------------------------= -------------------------------------------------------------------=0D=0A[m= f2]=0D=0A From khwolf1@gmail.com Wed Jul 29 23:24:08 2009 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 B8DA73A6D2E for ; Wed, 29 Jul 2009 23:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPPnIGcrmQuv for ; Wed, 29 Jul 2009 23:24:08 -0700 (PDT) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id 7F4143A6938 for ; Wed, 29 Jul 2009 23:24:00 -0700 (PDT) Received: by fxm26 with SMTP id 26so445166fxm.42 for ; Wed, 29 Jul 2009 23:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=P8QD59eqjptD+gjlB+GSaZBJ9B6njAS6o1/HbztAewY=; b=eDsgBnwc7JzYtVX5ULDZIcWtfh95f5K/UnYR54zeX/DG5ifj8Q5mIcg+twfaJRWVhC EhuG9IzaSrzzizD0g/Qk5WvoiuSduXOeS30uaG0IeIdZGeR+zjOL4hN+/MEJVFA1cx98 k2fx4a+ujXBwRo3yc0Vz8IWTMMVg3y/uh3MtE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PwI5p06wPfkDIQmI9mKveHfi8mXXu5xAyEC9coHCaMU5QoEV4ZwFYYejVqpD8KUbwZ Xo1tdBqy1zPs4pTpJHavgUHGPtsKAdVuIctc/lvc4BO6tTJdpSJ5Tg05BxuGAL5qYDxS MmjgavII7chWv7lxuLvQD6jT5ynhX5S121a5g= MIME-Version: 1.0 Received: by 10.103.212.2 with SMTP id o2mr427730muq.18.1248935038783; Wed, 29 Jul 2009 23:23:58 -0700 (PDT) In-Reply-To: References: <4A70E289.5050906@indigital.net> Date: Thu, 30 Jul 2009 08:23:58 +0200 Message-ID: From: Karl Heinz Wolf To: "Dawson, Martin" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ecrit Subject: Re: [Ecrit] HUM on 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: Thu, 30 Jul 2009 06:24:08 -0000 +1 On Thu, Jul 30, 2009 at 2:41 AM, Dawson, Martin w= rote: > +1 > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Byron Smith > Sent: Thursday, 30 July 2009 10:00 AM > To: 'ecrit' > Subject: Re: [Ecrit] HUM on PhoneBCP > > Agree. > > Byron > > Marc Linsner wrote: >> During today's meeting there was discussion as to why the chairs >> Publication Requested PhoneBCP version 13 when there are unresolved >> issues. This discussion led us to call for a hum. We are now asking >> the same question on the list. >> >> Do you agree or disagree that PhoneBCP -13 is ready to Publication >> Request? >> >> Please respond by close of business on Wednesday August 5th. >> >> Thanks, >> >> Marc & Hannes >> > ------------------------------------------------------------------------ >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------------------= ----------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. =A0Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------= ----------------------- > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From robinsg@huawei.com Wed Jul 29 23:57:50 2009 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 A6D0D3A715C for ; Wed, 29 Jul 2009 23:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIuY1sxY5F-7 for ; Wed, 29 Jul 2009 23:57:46 -0700 (PDT) Received: from customer-relay.songnetworks.se (customer-relay.songnetworks.se [195.42.210.9]) by core3.amsl.com (Postfix) with ESMTP id DFF4D3A6BE9 for ; Wed, 29 Jul 2009 23:57:45 -0700 (PDT) Received: from [10.59.1.165] (95.78.227.87.static.s-cy.siw.siwnet.net [87.227.78.95]) by customer-relay.songnetworks.se (Postfix) with ESMTP id 9D0B02429D; Thu, 30 Jul 2009 08:57:45 +0200 (CEST) Message-ID: <4A71445E.5060703@huawei.com> Date: Thu, 30 Jul 2009 08:57:34 +0200 From: Robins George User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Brian Rosen References: <024101ca1051$26a6c720$73f45560$@net> <025101ca1054$218e9490$64abbdb0$@net> In-Reply-To: <025101ca1054$218e9490$64abbdb0$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'ECRIT' Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting today 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, 30 Jul 2009 06:57:50 -0000 > Well, I was thinking of either explicitly defining a subservice, much as we > have defined sos and sos.police This looks more reasonable to me though there may have reasons to define the URN. > OR perhaps defining the urn so that any > token(s) after servicelistboundary be treated as a filter for which services > were composed into the servicelistboundary, with the default being all of > the services the LoST server handles. > > Brian > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Brian Rosen >> Sent: Wednesday, July 29, 2009 9:33 AM >> To: 'Karl Heinz Wolf'; 'Ted Hardie' >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting >> today >> >> Perhaps the service URN has some sub urns, like >> urn:service:servicelistboundary.sos >> >> >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> >> Behalf >> >>> Of Karl Heinz Wolf >>> Sent: Wednesday, July 29, 2009 9:21 AM >>> To: Ted Hardie >>> Cc: ECRIT >>> Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting >>> today >>> >>> Ted, >>> >>> thank you for your clarification. >>> >>> You might be correct, I probably focused too much on emergency >>> services. But there it hurts the most: if you're unaware of the >>> service, you don't have the dialstring and you definitely cannot >>> detect the emergency call to this service. >>> >>> On Wed, Jul 29, 2009 at 2:27 PM, Ted Hardie >>> >> wrote: >> >>>> At 5:01 AM -0700 7/29/09, Karl Heinz Wolf wrote: >>>> >>>>> There was some discussion during the meeting today on my draft >>>>> http://tools.ietf.org/html/draft-wolf-ecrit-lost- >>>>> >> servicelistboundary- >> >>> 01 >>> >>>>> My main concern is how to ensure that a client never misses a >>>>> >> change >> >>>>> in available services and consequently learns all location >>>>> >> dependent >> >>>>> dialstrings for the current location in order to be able to detect >>>>> >> an >> >>>>> emergency call based on the dialstring. >>>>> >>>> I think this is where the draft is a bit unclear. Let's start from >>>> what RFC 5222 says: >>>> >>>> A LoST client can ask a LoST server for the list of services it >>>> >>> knows >>> >>>> about for a particular area. The query >>>> contains one or more elements, each from a different >>>> location profile (Section 12), and may contain the >>>> >>> element. >>> >>>> As for, the server selects the first location >>>> >> element >> >>>> that has a profile the server understands and it can operate >>>> >> either >> >>>> recursively or iteratively; elements track the progress of >>>> >>> the >>> >>>> request. The query indicates the services that the server can >>>> enumerate from within the forest structure of which it is a part. >>>> Because LoST does not presume a single, overarching organization >>>> >> of >> >>>> all potential service types, there may be services available >>>> >> within >> >>> a >>> >>>> geographic area that could be described by other LoST servers >>>> connected to other forest structures. As an example, the >>>> >> emergency >> >>>> services forest for a region may be distinct from the forests >>>> >> that >> >>>> locate commercial services within the same region. >>>> >>>> If the query contains the element, the LoST server >>>> >>> returns >>> >>>> only immediate child services of the queried service that are >>>> available for the provided location. If the element is >>>> absent, the LoST service returns all top-level services available >>>> >>> for >>> >>>> the provided location that it knows about. >>>> >>>> The current mechanism only works within a single forest structure. >>>> This draft is not clear, at least to me, in being scoped to a >>>> >> single >> >>>> forest structure, and the discussion in the room wandered around >>>> that topic (partly by referring to the services for which the >>>> >>> responding >>> >>>> servers are authoritative). >>>> >>>> >>> right, the draft does not explicitly say this at the moment. >>> Thank you for pointing this out, it helps me understanding the >>> discussion better. >>> >>>> >>>>> Currently the listServiceByLocation response does not give any >>>>> information on the area the service list is valid for. So a client >>>>> might miss a change in the available services, so it won't have the >>>>> dialstring configured and is not able to detect an emergency call. >>>>> >>>> But there are many more available services than emergency services. >>>> These will also change. Are we clear that this only captures >>>> >> changes >> >>>> to those within a service hierarchy? >>>> >>>> >>> but you don't need to know the dialstring for pizza in advance: if >>> >> you >> >>> press the pizza button on your device, it can simply do the service >>> discovery. >>> >>> >>>> >>>>> The problem arises in countries not having a single emergency >>>>> dialstring, like 911, but having different dialstrings for >>>>> >> different >> >>>>> services and dialstrings as well as services depend on location. >>>>> >> When >> >>>>> travelling around, the availability of services may change, as well >>>>> >>> as >>> >>>>> the dialstrings. So there needs to be some kind of rule on when to >>>>> update the service list. Since the service boundary tells when to >>>>> >> do >> >>> a >>> >>>>> findService again, I thought it would be consistent to introduce >>>>> another boundary to tell the client when to update the service list >>>>> (as proposed in the draft). >>>>> >>>> In the past, we discussed this in terms of time, rather than >>>> >>> movement; >>> >>>> this was because the list could also change because of additions >>>> >>> (again, >>> >>>> not so much for emergency servies, but potentially for other >>>> >>> services) >>> >>>> >>> I wasn't talking about changes in time - sorry if didn't express that >>> clearly. Besides, the changes in time would be addressed by the >>> expires attribute. >>> >>> >>>> >>>>> Since I was just listening remotely to the discussion, I'd like to >>>>> >>> ask >>> >>>>> if I understood Ted's idea correctly: instead of a boundary >>>>> >>> indicating >>> >>>>> the area, the service list is valid for, the LoST Server should >>>>> >> also >> >>>>> return services that are NOT available at the current location. >>>>> This would mean: when a client does a findService for >>>>> urn:service:sos.ambulance for its current location, it would also >>>>> >> get >> >>>>> back a mapping for urn:service:sos.physician for a different >>>>> >>> location? >>> >>>> No; it sounds like something got lost here. I was first proposing >>>> >>> that >>> >>>> this should be limited in applicability, essentially to a single >>>> >>> forest or >>> >>>> service type. Then I was suggesting that a server able to traverse >>>> >>> that >>> >>>> forest respond with a list of relevant services but without >>>> >> location >> >>>> boundary information for those not available in the area relevant >>>> to the query. That is, you do a query using findServicebyLocation >>>> >>> for >>> >>>> urn:service:geg and get back urn:service:geg.orthozog with a >>>> >>> boundary, >>> >>>> and urn:service:geg.mumblefratz. with no boundary. That avoids >>>> dumping the database (and the current server having to collect the >>>> information about where geg.mumblefratz is available); it simply >>>> lets the client know that there are other services out there which >>>> are explicitly not available at the target site of the first query. >>>> >>>> If the client wants to use geg.mumblefratz, it needs to re-query. >>>> It can requery at some specified time scale, or it can requery on >>>> only when it wants to use geg.mumblefratz. >>>> >>>> >>> hm, as I understand it, the client has still the same problem: when >>> does the service become available? The only information the client >>> gets is that this service is available "somewhere". I'm not sure this >>> is helpful? >>> Moreover, considering the emergency service case, you have to know >>> >> the >> >>> dialstring right before the call. I know I'm concentrating on >>> emergency services... >>> >>> >>>> I was somewhat surprised, honestly, to see Henning arguing >>>> for this, since he has argued against this idea in the past. This >>>> makes me suspect I am missing some subtle difference, >>>> and I would not be surprised to find that this is so. I would >>>> like, however, if we did not concentrate on the emergency >>>> services use case to the exclusion of other use cases; that >>>> tends to skew the design in ways that will limit LoST's usefulness >>>> in other realms. >>>> >>> I'm afraid we need some kind of rule on when to update the service >>> list when travelling. And this is crucial for figuring out the >>> dialstings as long as there is not a single emergency dialstring all >>> over the world. >>> I'm not sure if the servicelistboundary makes much sense for other >>> services, since as you pointed out, they may just get discovered on >>> demand without any problems. >>> However, also the service boundary is optional in LoST, also the >>> servicelistboundary could just be optional and only be returned in >>> case the server knows it or it's about emergency services. >>> >>> karl heinz >>> >>> >>>> regards, >>>> Ted Hardie >>>> >>>> >>>>> So when moving to this other area, the client already knows which >>>>> services and dialstrings are available there. >>>>> I'm afraid this approach would just solve the problem in case the >>>>> >>> LoST >>> >>>>> Server would dump more or less it's complete database to the >>>>> >> client. >> >>>>> If the LoST Server would just send a couple of mappings, and others >>>>> not, the client could still be lost. >>>>> Besides, traffic and complexity for the client would increase. The >>>>> servicelistboundary wouldn't increase complexity too much for a >>>>> >>> client >>> >>>>> already evaluating the service boundary, since all the necessary >>>>> functionality should be already in place. On the server side, the >>>>> complexity should also be manageable (the servicelistboundary could >>>>> >>> be >>> >>>>> pre-calculated for the area the server has data for). >>>>> >>>>> Please let me know if I missed something in the discussion. >>>>> >>>>> karl heinz >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>> >>>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> _______________________________________________ >> Ecrit mailing 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 robinsg@huawei.com Thu Jul 30 00:11:01 2009 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 E3A2E28C13D for ; Thu, 30 Jul 2009 00:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rP8B3iDWNCR3 for ; Thu, 30 Jul 2009 00:10:55 -0700 (PDT) Received: from customer-relay.songnetworks.se (customer-relay.songnetworks.se [195.42.210.9]) by core3.amsl.com (Postfix) with ESMTP id EFD7B28C12E for ; Thu, 30 Jul 2009 00:10:54 -0700 (PDT) Received: from [10.59.1.165] (95.78.227.87.static.s-cy.siw.siwnet.net [87.227.78.95]) by customer-relay.songnetworks.se (Postfix) with ESMTP id 279792429D; Thu, 30 Jul 2009 09:10:56 +0200 (CEST) Message-ID: <4A714774.3070505@huawei.com> Date: Thu, 30 Jul 2009 09:10:44 +0200 From: Robins George User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: "James M. Polk" References: <4A608144.7090107@bbn.com> <4A60DF3C.2050401@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'ECRIT' Subject: Re: [Ecrit] New ID creating Geocoding URN 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, 30 Jul 2009 07:11:02 -0000 James, HELD extension would be a better choice for Geocoding and Reverse-Geocoding. More over address translation is useful in many cases other than emergency services, where LoST is not required. On 7/18/2009 1:06 AM, James M. Polk wrote: > At 03:29 PM 7/17/2009, Richard Barnes wrote: >> Hey James, >> >>>> I'm a little puzzled as to why you would want to use LoST for >>>> [reverse] geocoding ... >>> It seems to me that LoST servers will not be that overloaded (though >>> I could be underestimating), >> >> There's nothing preventing these servers from offering a different >> interface. Heck, both LoST and HELD are HTTP-based, so it'll >> probably just be another servlet / script / etc. > > fair comment - but this is a draw IMO > > >>>> For just trading civic vs. geodetic information, it would seem much >>>> more appropriate to use HELD as a baseline, as in >>>> >>>> >>> I'm not sure HELD will be in every device, which would be required >>> for/by this ID, correct? >> >> Last I read phonebcp, HELD and DHCP were required in the same places. > > true - but since devices are made by vendors, they will choose to > implement what they want to implement (and I'm not just talking about > Cisco), regardless of what a spec says. The all mighty RFP is mightier > than the RFC (regrettably) ;-) > > >> Moreover, geocoding is useful in many cases outside of emergency >> services, so devices that aren't capable of emergency calling might >> still want to do it. > > ok - to that I'd say that LoST is definitely more useful than just for > emergency calling too. The ECRIT WG reached consensus that LoST and > the service URNs are to be extended in ECRIT even if the particular > service has nothing to do with emergency calling. There was a lively > and open debate about this in Vancouver. > > I'd further say that applications that likely are intelligent enough > to know the difference between the two formats will be more > intelligent than a palette, thus making them (probably) more often > than not able to signal an emergency - even if the likely won't in > their lifetime. > > Smart phones is a good example of this. Not-so-smart phones probably > will also have LoST in them, so coding the new URN seems like a > no-brainer to me. > >> These devices > > which devices? boxes, palettes or phones? > >> won't necessarily have LoST libraries, so there's no inherent >> advantage there to using LoST. > > I believe the latter of the list above will, and will probably be the > type of devices that knows enough to do the geocoding transaction. I'm > not thinking palettes or boxes will have the choice of more than one > location format, much less know to ask for another one. > > My draft is targeted at devices that have applications that are smart > enough to know there is a difference and to ask for the more preferred > format if they only receive a format that know isn't what they prefer. > > James > > >> --Richard > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From Martin.Thomson@andrew.com Thu Jul 30 00:51:55 2009 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 CE6583A6E1D for ; Thu, 30 Jul 2009 00:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 Lxd3RiFaGDQw for ; Thu, 30 Jul 2009 00:51:54 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id BB8CD3A7144 for ; Thu, 30 Jul 2009 00:51:54 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_30_03_14_28 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 30 Jul 2009 03:14:25 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 02:51:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 30 Jul 2009 02:51:47 -0500 Message-ID: In-Reply-To: <4A714774.3070505@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] New ID creating Geocoding URN Thread-Index: AcoQ5OhVkgWQ60ezSLSib70LjTPdiAABS9uw References: <4A608144.7090107@bbn.com><4A60DF3C.2050401@bbn.com> <4A714774.3070505@huawei.com> From: "Thomson, Martin" To: "Robins George" , "James M. Polk" X-OriginalArrivalTime: 30 Jul 2009 07:51:52.0443 (UTC) FILETIME=[99EEB4B0:01CA10EA] Cc: ECRIT Subject: Re: [Ecrit] New ID creating Geocoding URN 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, 30 Jul 2009 07:51:55 -0000 SGkgUm9iaW5zLA0KDQpXZSBkaXNjdXNzZWQgdGhpcyBpbiB0aGUgbWVldGluZyBhbmQgY2FtZSB0 byB0aGUgY29uY2x1c2lvbiB0aGF0IHlvdXIgZ2VvY29kaW5nIGRyYWZ0IG1pZ2h0IGJlIGEgbW9y ZSBhcHByb3ByaWF0ZSBtZWFucyBvZiBhY3R1YWxseSBtYWtpbmcgdGhlIGdlb2NvZGluZyByZXF1 ZXN0LiAgQnJpYW4gc3VnZ2VzdGVkIHRoYXQgdGhlIHNjb3BlIG1pZ2h0IGJlIGV4dGVuZGVkIHRv IGluY2x1ZGUgYSBtb3JlIGdlbmVyYWwgIlBJREYtTE8gdHJhbnNmb3JtYXRpb24iIC0gc29tZXRo aW5nIHRoYXQgaXMgYXBwYXJlbnRseSBuZWNlc3NhcnkgaW4gdGhlICdzdGF0ZXMgZm9yIHRyYW5z bGF0aW5nIGJldHdlZW4gZW1lcmdlbmN5LXVzZWZ1bCBjaXZpYyBsb2NhdGlvbiBhbmQgcG9zdGFs LXVzZWZ1bCBjaXZpYyBsb2NhdGlvbiBmb3IgaW5zdGFuY2UuICBJJ20gY2VydGFpbmx5IGludGVy ZXN0ZWQgaW4gc2VlaW5nIHRoYXQgd29yayBwcm9ncmVzcy4NCg0KSG93ZXZlciwgdXNlIG9mIExv U1QgaW4gX2Rpc2NvdmVyaW5nXyBhIHNlcnZlciB0aGF0IGlzIGNhcGFibGUgb2YgcHJvdmlkaW5n IHRoaXMgc2VydmljZSB3YXMgc3RpbGwgYSB1c2VmdWwgdGhpbmcuDQoNCi0tTWFydGluDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBSb2JpbnMg R2VvcmdlDQo+IFNlbnQ6IFRodXJzZGF5LCAzMCBKdWx5IDIwMDkgOToxMSBBTQ0KPiBUbzogSmFt ZXMgTS4gUG9saw0KPiBDYzogJ0VDUklUJw0KPiBTdWJqZWN0OiBSZTogW0Vjcml0XSBOZXcgSUQg Y3JlYXRpbmcgR2VvY29kaW5nIFVSTg0KPiANCj4gSmFtZXMsDQo+IA0KPiBIRUxEIGV4dGVuc2lv biB3b3VsZCBiZSBhIGJldHRlciBjaG9pY2UgZm9yIEdlb2NvZGluZyBhbmQNCj4gUmV2ZXJzZS1H ZW9jb2RpbmcuIE1vcmUgb3ZlciBhZGRyZXNzIHRyYW5zbGF0aW9uIGlzIHVzZWZ1bCBpbiBtYW55 DQo+IGNhc2VzDQo+IG90aGVyIHRoYW4gZW1lcmdlbmN5IHNlcnZpY2VzLCB3aGVyZSBMb1NUIGlz IG5vdCByZXF1aXJlZC4NCj4gDQo+IA0KPiBPbiA3LzE4LzIwMDkgMTowNiBBTSwgSmFtZXMgTS4g UG9sayB3cm90ZToNCj4gPiBBdCAwMzoyOSBQTSA3LzE3LzIwMDksIFJpY2hhcmQgQmFybmVzIHdy b3RlOg0KPiA+PiBIZXkgSmFtZXMsDQo+ID4+DQo+ID4+Pj4gSSdtIGEgbGl0dGxlIHB1enpsZWQg YXMgdG8gd2h5IHlvdSB3b3VsZCB3YW50IHRvIHVzZSBMb1NUIGZvcg0KPiA+Pj4+IFtyZXZlcnNl XSBnZW9jb2RpbmcgLi4uDQo+ID4+PiBJdCBzZWVtcyB0byBtZSB0aGF0IExvU1Qgc2VydmVycyB3 aWxsIG5vdCBiZSB0aGF0IG92ZXJsb2FkZWQNCj4gKHRob3VnaA0KPiA+Pj4gSSBjb3VsZCBiZSB1 bmRlcmVzdGltYXRpbmcpLA0KPiA+Pg0KPiA+PiBUaGVyZSdzIG5vdGhpbmcgcHJldmVudGluZyB0 aGVzZSBzZXJ2ZXJzIGZyb20gb2ZmZXJpbmcgYSBkaWZmZXJlbnQNCj4gPj4gaW50ZXJmYWNlLiAg SGVjaywgYm90aCBMb1NUIGFuZCBIRUxEIGFyZSBIVFRQLWJhc2VkLCBzbyBpdCdsbA0KPiA+PiBw cm9iYWJseSBqdXN0IGJlIGFub3RoZXIgc2VydmxldCAvIHNjcmlwdCAvIGV0Yy4NCj4gPg0KPiA+ IGZhaXIgY29tbWVudCAtIGJ1dCB0aGlzIGlzIGEgZHJhdyBJTU8NCj4gPg0KPiA+DQo+ID4+Pj4g Rm9yIGp1c3QgdHJhZGluZyBjaXZpYyB2cy4gZ2VvZGV0aWMgaW5mb3JtYXRpb24sIGl0IHdvdWxk IHNlZW0NCj4gbXVjaA0KPiA+Pj4+IG1vcmUgYXBwcm9wcmlhdGUgdG8gdXNlIEhFTEQgYXMgYSBi YXNlbGluZSwgYXMgaW4NCj4gPj4+PiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Z2VvcmdlLWdlb3ByaXYtYWRkcmVzcy0NCj4gdHJhbnNsYXRpb24tMDE+DQo+ID4+Pj4NCj4gPj4+ IEknbSBub3Qgc3VyZSBIRUxEIHdpbGwgYmUgaW4gZXZlcnkgZGV2aWNlLCB3aGljaCB3b3VsZCBi ZSByZXF1aXJlZA0KPiA+Pj4gZm9yL2J5IHRoaXMgSUQsIGNvcnJlY3Q/DQo+ID4+DQo+ID4+IExh c3QgSSByZWFkIHBob25lYmNwLCBIRUxEIGFuZCBESENQIHdlcmUgcmVxdWlyZWQgaW4gdGhlIHNh bWUNCj4gcGxhY2VzLg0KPiA+DQo+ID4gdHJ1ZSAtIGJ1dCBzaW5jZSBkZXZpY2VzIGFyZSBtYWRl IGJ5IHZlbmRvcnMsIHRoZXkgd2lsbCBjaG9vc2UgdG8NCj4gPiBpbXBsZW1lbnQgd2hhdCB0aGV5 IHdhbnQgdG8gaW1wbGVtZW50IChhbmQgSSdtIG5vdCBqdXN0IHRhbGtpbmcgYWJvdXQNCj4gPiBD aXNjbyksIHJlZ2FyZGxlc3Mgb2Ygd2hhdCBhIHNwZWMgc2F5cy4gVGhlIGFsbCBtaWdodHkgUkZQ IGlzDQo+IG1pZ2h0aWVyDQo+ID4gdGhhbiB0aGUgUkZDIChyZWdyZXR0YWJseSkgICA7LSkNCj4g Pg0KPiA+DQo+ID4+IE1vcmVvdmVyLCBnZW9jb2RpbmcgaXMgdXNlZnVsIGluIG1hbnkgY2FzZXMg b3V0c2lkZSBvZiBlbWVyZ2VuY3kNCj4gPj4gc2VydmljZXMsIHNvIGRldmljZXMgdGhhdCBhcmVu J3QgY2FwYWJsZSBvZiBlbWVyZ2VuY3kgY2FsbGluZyBtaWdodA0KPiA+PiBzdGlsbCB3YW50IHRv IGRvIGl0Lg0KPiA+DQo+ID4gb2sgLSB0byB0aGF0IEknZCBzYXkgdGhhdCBMb1NUIGlzIGRlZmlu aXRlbHkgbW9yZSB1c2VmdWwgdGhhbiBqdXN0DQo+IGZvcg0KPiA+IGVtZXJnZW5jeSBjYWxsaW5n IHRvby4gIFRoZSBFQ1JJVCBXRyByZWFjaGVkIGNvbnNlbnN1cyB0aGF0IExvU1QgYW5kDQo+ID4g dGhlIHNlcnZpY2UgVVJOcyBhcmUgdG8gYmUgZXh0ZW5kZWQgaW4gRUNSSVQgZXZlbiBpZiB0aGUg cGFydGljdWxhcg0KPiA+IHNlcnZpY2UgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBlbWVyZ2VuY3kg Y2FsbGluZy4gVGhlcmUgd2FzIGEgbGl2ZWx5DQo+ID4gYW5kIG9wZW4gZGViYXRlIGFib3V0IHRo aXMgaW4gVmFuY291dmVyLg0KPiA+DQo+ID4gSSdkIGZ1cnRoZXIgc2F5IHRoYXQgYXBwbGljYXRp b25zIHRoYXQgbGlrZWx5IGFyZSBpbnRlbGxpZ2VudCBlbm91Z2gNCj4gPiB0byBrbm93IHRoZSBk aWZmZXJlbmNlIGJldHdlZW4gdGhlIHR3byBmb3JtYXRzIHdpbGwgYmUgbW9yZQ0KPiA+IGludGVs bGlnZW50IHRoYW4gYSBwYWxldHRlLCB0aHVzIG1ha2luZyB0aGVtIChwcm9iYWJseSkgbW9yZSBv ZnRlbg0KPiA+IHRoYW4gbm90IGFibGUgdG8gc2lnbmFsIGFuIGVtZXJnZW5jeSAtIGV2ZW4gaWYg dGhlIGxpa2VseSB3b24ndCBpbg0KPiA+IHRoZWlyIGxpZmV0aW1lLg0KPiA+DQo+ID4gU21hcnQg cGhvbmVzIGlzIGEgZ29vZCBleGFtcGxlIG9mIHRoaXMuIE5vdC1zby1zbWFydCBwaG9uZXMgcHJv YmFibHkNCj4gPiB3aWxsIGFsc28gaGF2ZSBMb1NUIGluIHRoZW0sIHNvIGNvZGluZyB0aGUgbmV3 IFVSTiBzZWVtcyBsaWtlIGENCj4gPiBuby1icmFpbmVyIHRvIG1lLg0KPiA+DQo+ID4+IFRoZXNl IGRldmljZXMNCj4gPg0KPiA+IHdoaWNoIGRldmljZXM/IGJveGVzLCBwYWxldHRlcyBvciBwaG9u ZXM/DQo+ID4NCj4gPj4gd29uJ3QgbmVjZXNzYXJpbHkgaGF2ZSBMb1NUIGxpYnJhcmllcywgc28g dGhlcmUncyBubyBpbmhlcmVudA0KPiA+PiBhZHZhbnRhZ2UgdGhlcmUgdG8gdXNpbmcgTG9TVC4N Cj4gPg0KPiA+IEkgYmVsaWV2ZSB0aGUgbGF0dGVyIG9mIHRoZSBsaXN0IGFib3ZlIHdpbGwsIGFu ZCB3aWxsIHByb2JhYmx5IGJlIHRoZQ0KPiA+IHR5cGUgb2YgZGV2aWNlcyB0aGF0IGtub3dzIGVu b3VnaCB0byBkbyB0aGUgZ2VvY29kaW5nIHRyYW5zYWN0aW9uLg0KPiBJJ20NCj4gPiBub3QgdGhp bmtpbmcgcGFsZXR0ZXMgb3IgYm94ZXMgd2lsbCBoYXZlIHRoZSBjaG9pY2Ugb2YgbW9yZSB0aGFu IG9uZQ0KPiA+IGxvY2F0aW9uIGZvcm1hdCwgbXVjaCBsZXNzIGtub3cgdG8gYXNrIGZvciBhbm90 aGVyIG9uZS4NCj4gPg0KPiA+IE15IGRyYWZ0IGlzIHRhcmdldGVkIGF0IGRldmljZXMgdGhhdCBo YXZlIGFwcGxpY2F0aW9ucyB0aGF0IGFyZSBzbWFydA0KPiA+IGVub3VnaCB0byBrbm93IHRoZXJl IGlzIGEgZGlmZmVyZW5jZSBhbmQgdG8gYXNrIGZvciB0aGUgbW9yZQ0KPiBwcmVmZXJyZWQNCj4g PiBmb3JtYXQgaWYgdGhleSBvbmx5IHJlY2VpdmUgYSBmb3JtYXQgdGhhdCBrbm93IGlzbid0IHdo YXQgdGhleQ0KPiBwcmVmZXIuDQo+ID4NCj4gPiBKYW1lcw0KPiA+DQo+ID4NCj4gPj4gLS1SaWNo YXJkDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+IEVjcml0IG1haWxpbmcgbGlzdA0KPiA+IEVjcml0QGlldGYub3JnDQo+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPiA+DQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBFY3JpdCBtYWls aW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9lY3JpdA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5k IG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZh dGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFs LiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0NCg== From drage@alcatel-lucent.com Thu Jul 30 01:01:05 2009 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 DAEFE28C15D for ; Thu, 30 Jul 2009 01:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.635 X-Spam-Level: X-Spam-Status: No, score=-3.635 tagged_above=-999 required=5 tests=[AWL=-1.387, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 7QxMj442SZGu for ; Thu, 30 Jul 2009 01:01:04 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 7524228C16B for ; Thu, 30 Jul 2009 01:01:04 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n6U80a49032431 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Jul 2009 10:00:36 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 30 Jul 2009 10:00:36 +0200 From: "DRAGE, Keith (Keith)" To: Marc Linsner , "'ecrit'" Date: Thu, 30 Jul 2009 10:00:32 +0200 Thread-Topic: HUM on PhoneBCP Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE2070BE6D5FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Subject: Re: [Ecrit] HUM on 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: Thu, 30 Jul 2009 08:01:05 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE2070BE6D5FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I don't agree. Some background. There was a set of comments provided by Stephen Edge on 5th February 2009. = I can find no response to that set of comments on the mailing list. The gist of that set of comments was that phonebcp claims to cover all acce= ss technologies and it identified a significant number of requirements with= in phonebcp that the author considered were not requirements on 3GPP access= es. So my position is that the document is not ready because all the valid comm= ents on the document were not addressed. There are two ways of dealing with this set of comments: - going through and modifying all the identified requirements where the = comment is upheld. - making more clear in the abstract and / or introduction that this is s= olely the view of IETF in regard to IP capable devices and that other organ= isations may specify other requirements. I would note at this point that the current abstract says: 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. Because the two sentences follow each other, it implies that other SDOs tha= t have efforts targetted at addressing these solutions are complicit in the= requirements so stated, and this is untrue. Certainly the current status o= f this document as addressed by various informal 3GPP discussions is to ens= ure that things do not fall apart in entities using the 3GPP mechanisms, ho= wever 3GPP devices do not use these requirements (no do these requirements = represent the 3GPP requires. One solution to the issue would just be to make much clearer which SDOs hav= e participated in this work and which have not and the status of that progr= ess - however that was also what people keep calling the "applicability sta= tement" was trying to do. regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of M= arc Linsner Sent: Wednesday, July 29, 2009 2:53 PM To: 'ecrit' Subject: [Ecrit] HUM on PhoneBCP During today=92s meeting there was discussion as to why the chairs Publicat= ion Requested PhoneBCP version 13 when there are unresolved issues. This d= iscussion led us to call for a hum. We are now asking the same question on= the list. Do you agree or disagree that PhoneBCP -13 is ready to Publication Request? Please respond by close of business on Wednesday August 5th. Thanks, Marc & Hannes --_000_EDC0A1AE77C57744B664A310A0B23AE2070BE6D5FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable HUM on PhoneBCP
I don't agree.
 
Some background.
 
There was a set of comments provided by Stephen Ed= ge on 5th=20 February 2009. I can find no response to that set of comments on the mailin= g=20 list.
 
The gist of that set of comments was that phonebcp= claims=20 to cover all access technologies and it identified a significant number of= =20 requirements within phonebcp that the author considered were not requiremen= ts on=20 3GPP accesses.
 
So my position is that the document is not ready b= ecause=20 all the valid comments on the document were not addressed.
 
There are two ways of dealing with this set of=20 comments:
 
-    going through and modifying al= l the=20 identified requirements where the comment is upheld.
 
-    making more clear in the abstr= act and /=20 or introduction that this is solely the view of IETF in regard to IP capabl= e=20 devices and that other organisations may specify other=20 requirements.
 
I would note at this point that the current abstra= ct=20 says:
 
   The IETF and other standards organiza= tion have=20 efforts targeted at
   standardizing various aspects of placing emergency ca= lls on=20 IP
   networks.  This memo describes best current practic= e on=20 how devices,
   networks and services should use such standard= s to=20 make emergency
   calls.
Because the two sentences follow each other, it im= plies=20 that other SDOs that have efforts targetted at addressing these solutions a= re=20 complicit in the requirements so stated, and this is untrue. Certainly the= =20 current status of this document as addressed by various informal 3GPP=20 discussions is to ensure that things do not fall apart in entities using th= e=20 3GPP mechanisms, however 3GPP devices do not use these requirements (no do = these=20 requirements represent the 3GPP requires.
 
One solution to the issue would just be to make mu= ch=20 clearer which SDOs have participated in this work and which have not and th= e=20 status of that progress - however that was also what people keep calling th= e=20 "applicability statement" was trying to do.
 
regards
 
Keith
 
 

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc=20 Linsner
Sent: Wednesday, July 29, 2009 2:53 PM
To:=20 'ecrit'
Subject: [Ecrit] HUM on PhoneBCP

During today=92s meeting there was discussion a= s to why=20 the chairs Publication Requested PhoneBCP version 13 when there are unres= olved=20 issues.  This discussion led us to call for a hum.  We are now= =20 asking the same question on the list.

Do you= agree=20 or disagree that PhoneBCP -13 is ready to Publication Request?

Ple= ase=20 respond by close of business on Wednesday August=20 5th.

Thanks,

Marc &=20 Hannes
 --_000_EDC0A1AE77C57744B664A310A0B23AE2070BE6D5FRMRSSXCHMBSC3d_-- From Martin.Thomson@andrew.com Thu Jul 30 01:06:03 2009 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 C44C828C195 for ; Thu, 30 Jul 2009 01:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 fLYen76YLQw6 for ; Thu, 30 Jul 2009 01:06:02 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 7419528C191 for ; Thu, 30 Jul 2009 01:06:02 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_30_03_28_36 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 30 Jul 2009 03:28:33 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 03:06:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA10EC.92B5ACE4" Date: Thu, 30 Jul 2009 03:05:56 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] (aside) HUM on PhoneBCP Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAACNBRHA= References: From: "Thomson, Martin" To: "DRAGE, Keith (Keith)" , "Marc Linsner" , "ecrit" X-OriginalArrivalTime: 30 Jul 2009 08:06:00.0105 (UTC) FILETIME=[932DA990:01CA10EC] Subject: Re: [Ecrit] (aside) HUM on 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: Thu, 30 Jul 2009 08:06:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA10EC.92B5ACE4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 S2VpdGgsDQoNCiANCg0KVGhpcyB3b3JraW5nIGdyb3VwIGhhcyBkaXNjdXNzZWQsIGF0IGdyZWF0 IGxlbmd0aCwgU3RlcGhlbuKAmXMgY29uY2VybnMuICBJZiBhIHNwZWNpZmljIGVtYWlsIGhhcyBu b3QgaGFkIGFueSByZXNwb25zZSwgdGhhdCBjYW5ub3QgYmUgdGFrZW4gYXMgYW4gaW5kaWNhdGlv biBvbmUgd2F5IG9yIG90aGVyLg0KDQogDQoNCllvdSBtYXkgY29uc2lkZXIgdGhpcyBodW0gaXMg b24gd2hldGhlciB5b3UgdGhpbmsgdGhvc2UgY29tbWVudHMgdmFsaWQuDQoNCiANCg0KLS1NYXJ0 aW4NCg0KIA0KDQpGcm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZWNyaXQtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERSQUdFLCBLZWl0aCAoS2VpdGgpDQpTZW50OiBU aHVyc2RheSwgMzAgSnVseSAyMDA5IDEwOjAxIEFNDQpUbzogTWFyYyBMaW5zbmVyOyAnZWNyaXQn DQpTdWJqZWN0OiBSZTogW0Vjcml0XSBIVU0gb24gUGhvbmVCQ1ANCg0KIA0KDQpJIGRvbid0IGFn cmVlLg0KDQogDQoNClNvbWUgYmFja2dyb3VuZC4NCg0KIA0KDQpUaGVyZSB3YXMgYSBzZXQgb2Yg Y29tbWVudHMgcHJvdmlkZWQgYnkgU3RlcGhlbiBFZGdlIG9uIDV0aCBGZWJydWFyeSAyMDA5LiBJ IGNhbiBmaW5kIG5vIHJlc3BvbnNlIHRvIHRoYXQgc2V0IG9mIGNvbW1lbnRzIG9uIHRoZSBtYWls aW5nIGxpc3QuDQoNCiANCg0KVGhlIGdpc3Qgb2YgdGhhdCBzZXQgb2YgY29tbWVudHMgd2FzIHRo YXQgcGhvbmViY3AgY2xhaW1zIHRvIGNvdmVyIGFsbCBhY2Nlc3MgdGVjaG5vbG9naWVzIGFuZCBp dCBpZGVudGlmaWVkIGEgc2lnbmlmaWNhbnQgbnVtYmVyIG9mIHJlcXVpcmVtZW50cyB3aXRoaW4g cGhvbmViY3AgdGhhdCB0aGUgYXV0aG9yIGNvbnNpZGVyZWQgd2VyZSBub3QgcmVxdWlyZW1lbnRz IG9uIDNHUFAgYWNjZXNzZXMuDQoNCiANCg0KU28gbXkgcG9zaXRpb24gaXMgdGhhdCB0aGUgZG9j dW1lbnQgaXMgbm90IHJlYWR5IGJlY2F1c2UgYWxsIHRoZSB2YWxpZCBjb21tZW50cyBvbiB0aGUg ZG9jdW1lbnQgd2VyZSBub3QgYWRkcmVzc2VkLg0KDQogDQoNClRoZXJlIGFyZSB0d28gd2F5cyBv ZiBkZWFsaW5nIHdpdGggdGhpcyBzZXQgb2YgY29tbWVudHM6DQoNCiANCg0KLSAgICBnb2luZyB0 aHJvdWdoIGFuZCBtb2RpZnlpbmcgYWxsIHRoZSBpZGVudGlmaWVkIHJlcXVpcmVtZW50cyB3aGVy ZSB0aGUgY29tbWVudCBpcyB1cGhlbGQuDQoNCiANCg0KLSAgICBtYWtpbmcgbW9yZSBjbGVhciBp biB0aGUgYWJzdHJhY3QgYW5kIC8gb3IgaW50cm9kdWN0aW9uIHRoYXQgdGhpcyBpcyBzb2xlbHkg dGhlIHZpZXcgb2YgSUVURiBpbiByZWdhcmQgdG8gSVAgY2FwYWJsZSBkZXZpY2VzIGFuZCB0aGF0 IG90aGVyIG9yZ2FuaXNhdGlvbnMgbWF5IHNwZWNpZnkgb3RoZXIgcmVxdWlyZW1lbnRzLg0KDQog DQoNCkkgd291bGQgbm90ZSBhdCB0aGlzIHBvaW50IHRoYXQgdGhlIGN1cnJlbnQgYWJzdHJhY3Qg c2F5czoNCg0KIA0KDQogICBUaGUgSUVURiBhbmQgb3RoZXIgc3RhbmRhcmRzIG9yZ2FuaXphdGlv biBoYXZlIGVmZm9ydHMgdGFyZ2V0ZWQgYXQNCg0KICAgc3RhbmRhcmRpemluZyB2YXJpb3VzIGFz cGVjdHMgb2YgcGxhY2luZyBlbWVyZ2VuY3kgY2FsbHMgb24gSVANCiAgIG5ldHdvcmtzLiAgVGhp cyBtZW1vIGRlc2NyaWJlcyBiZXN0IGN1cnJlbnQgcHJhY3RpY2Ugb24gaG93IGRldmljZXMsDQog ICBuZXR3b3JrcyBhbmQgc2VydmljZXMgc2hvdWxkIHVzZSBzdWNoIHN0YW5kYXJkcyB0byBtYWtl IGVtZXJnZW5jeQ0KICAgY2FsbHMuDQoNCkJlY2F1c2UgdGhlIHR3byBzZW50ZW5jZXMgZm9sbG93 IGVhY2ggb3RoZXIsIGl0IGltcGxpZXMgdGhhdCBvdGhlciBTRE9zIHRoYXQgaGF2ZSBlZmZvcnRz IHRhcmdldHRlZCBhdCBhZGRyZXNzaW5nIHRoZXNlIHNvbHV0aW9ucyBhcmUgY29tcGxpY2l0IGlu IHRoZSByZXF1aXJlbWVudHMgc28gc3RhdGVkLCBhbmQgdGhpcyBpcyB1bnRydWUuIENlcnRhaW5s eSB0aGUgY3VycmVudCBzdGF0dXMgb2YgdGhpcyBkb2N1bWVudCBhcyBhZGRyZXNzZWQgYnkgdmFy aW91cyBpbmZvcm1hbCAzR1BQIGRpc2N1c3Npb25zIGlzIHRvIGVuc3VyZSB0aGF0IHRoaW5ncyBk byBub3QgZmFsbCBhcGFydCBpbiBlbnRpdGllcyB1c2luZyB0aGUgM0dQUCBtZWNoYW5pc21zLCBo b3dldmVyIDNHUFAgZGV2aWNlcyBkbyBub3QgdXNlIHRoZXNlIHJlcXVpcmVtZW50cyAobm8gZG8g dGhlc2UgcmVxdWlyZW1lbnRzIHJlcHJlc2VudCB0aGUgM0dQUCByZXF1aXJlcy4NCg0KIA0KDQpP bmUgc29sdXRpb24gdG8gdGhlIGlzc3VlIHdvdWxkIGp1c3QgYmUgdG8gbWFrZSBtdWNoIGNsZWFy ZXIgd2hpY2ggU0RPcyBoYXZlIHBhcnRpY2lwYXRlZCBpbiB0aGlzIHdvcmsgYW5kIHdoaWNoIGhh dmUgbm90IGFuZCB0aGUgc3RhdHVzIG9mIHRoYXQgcHJvZ3Jlc3MgLSBob3dldmVyIHRoYXQgd2Fz IGFsc28gd2hhdCBwZW9wbGUga2VlcCBjYWxsaW5nIHRoZSAiYXBwbGljYWJpbGl0eSBzdGF0ZW1l bnQiIHdhcyB0cnlpbmcgdG8gZG8uDQoNCiANCg0KcmVnYXJkcw0KDQogDQoNCktlaXRoDQoNCiAN Cg0KIA0KDQoJIA0KDQoJDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCglG cm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIE1hcmMgTGluc25lcg0KCVNlbnQ6IFdlZG5lc2RheSwgSnVseSAyOSwg MjAwOSAyOjUzIFBNDQoJVG86ICdlY3JpdCcNCglTdWJqZWN0OiBbRWNyaXRdIEhVTSBvbiBQaG9u ZUJDUA0KDQoJRHVyaW5nIHRvZGF54oCZcyBtZWV0aW5nIHRoZXJlIHdhcyBkaXNjdXNzaW9uIGFz IHRvIHdoeSB0aGUgY2hhaXJzIFB1YmxpY2F0aW9uIFJlcXVlc3RlZCBQaG9uZUJDUCB2ZXJzaW9u IDEzIHdoZW4gdGhlcmUgYXJlIHVucmVzb2x2ZWQgaXNzdWVzLiAgVGhpcyBkaXNjdXNzaW9uIGxl ZCB1cyB0byBjYWxsIGZvciBhIGh1bS4gIFdlIGFyZSBub3cgYXNraW5nIHRoZSBzYW1lIHF1ZXN0 aW9uIG9uIHRoZSBsaXN0Lg0KCQ0KCURvIHlvdSBhZ3JlZSBvciBkaXNhZ3JlZSB0aGF0IFBob25l QkNQIC0xMyBpcyByZWFkeSB0byBQdWJsaWNhdGlvbiBSZXF1ZXN0Pw0KCQ0KCVBsZWFzZSByZXNw b25kIGJ5IGNsb3NlIG9mIGJ1c2luZXNzIG9uIFdlZG5lc2RheSBBdWd1c3QgNXRoLg0KCQ0KCVRo YW5rcywNCgkNCglNYXJjICYgSGFubmVzDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQg b25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndp c2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUg b3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJp dGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ0K ------_=_NextPart_001_01CA10EC.92B5ACE4 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDov L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KDQo8bWV0YSBuYW1lPUdlbmVy YXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0t W2lmICFtc29dPg0KPHN0eWxlPg0Kdlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0K b1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNk ZWZhdWx0I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0 eWxlPg0KPCFbZW5kaWZdLS0+DQo8dGl0bGU+SFVNIG9uIFBob25lQkNQPC90aXRsZT4NCjxzdHls ZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToy IDExIDYgNCAzIDUgNCA0IDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMyNDQwNjE7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rp b24xO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1FTi1BVSBsaW5rPWJsdWUg dmxpbms9cHVycGxlPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCmNvbG9yOiMyNDQwNjEnPktlaXRoLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6 IzI0NDA2MSc+VGhpcyB3b3JraW5nIGdyb3VwIGhhcyBkaXNjdXNzZWQsIGF0IGdyZWF0IGxlbmd0 aCwgU3RlcGhlbuKAmXMNCmNvbmNlcm5zLsKgIElmIGEgc3BlY2lmaWMgZW1haWwgaGFzIG5vdCBo YWQgYW55IHJlc3BvbnNlLCB0aGF0IGNhbm5vdCBiZSB0YWtlbg0KYXMgYW4gaW5kaWNhdGlvbiBv bmUgd2F5IG9yIG90aGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+WW91IG1heSBj b25zaWRlciB0aGlzIGh1bSBpcyBvbiB3aGV0aGVyIHlvdSB0aGluayB0aG9zZSBjb21tZW50cw0K dmFsaWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCmNvbG9yOiMyNDQwNjEnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz4tLU1hcnRpbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYx Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+ DQoNCjxkaXY+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6DQoiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiJz4gZWNyaXQtYm91bmNlc0BpZXRmLm9yZw0KW21haWx0bzplY3JpdC1ib3VuY2VzQGll dGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkRSQUdFLCBLZWl0aCAoS2VpdGgpPGJyPg0KPGI+ U2VudDo8L2I+IFRodXJzZGF5LCAzMCBKdWx5IDIwMDkgMTA6MDEgQU08YnI+DQo8Yj5Ubzo8L2I+ IE1hcmMgTGluc25lcjsgJ2Vjcml0Jzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0Vjcml0XSBI VU0gb24gUGhvbmVCQ1A8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7DQpjb2xvcjpibHVlJz5JIGRvbid0IGFncmVlLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQpjb2xvcjpibHVlJz5Tb21lIGJhY2tncm91bmQuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286 cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOmJsdWUnPlRoZXJlIHdh cyBhIHNldCBvZiBjb21tZW50cyBwcm92aWRlZCBieSBTdGVwaGVuIEVkZ2Ugb24gNXRoIEZlYnJ1 YXJ5DQoyMDA5LiBJIGNhbiBmaW5kIG5vIHJlc3BvbnNlIHRvIHRoYXQgc2V0IG9mIGNvbW1lbnRz IG9uIHRoZSBtYWlsaW5nIGxpc3QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm IjsNCmNvbG9yOmJsdWUnPlRoZSBnaXN0IG9mIHRoYXQgc2V0IG9mIGNvbW1lbnRzIHdhcyB0aGF0 IHBob25lYmNwIGNsYWltcyB0byBjb3Zlcg0KYWxsIGFjY2VzcyB0ZWNobm9sb2dpZXMgYW5kIGl0 IGlkZW50aWZpZWQgYSBzaWduaWZpY2FudCBudW1iZXIgb2YgcmVxdWlyZW1lbnRzDQp3aXRoaW4g cGhvbmViY3AgdGhhdCB0aGUgYXV0aG9yIGNvbnNpZGVyZWQgd2VyZSBub3QgcmVxdWlyZW1lbnRz IG9uIDNHUFANCmFjY2Vzc2VzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 DQpjb2xvcjpibHVlJz5TbyBteSBwb3NpdGlvbiBpcyB0aGF0IHRoZSBkb2N1bWVudCBpcyBub3Qg cmVhZHkgYmVjYXVzZSBhbGwgdGhlDQp2YWxpZCBjb21tZW50cyBvbiB0aGUgZG9jdW1lbnQgd2Vy ZSBub3QgYWRkcmVzc2VkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQpj b2xvcjpibHVlJz5UaGVyZSBhcmUgdHdvIHdheXMgb2YgZGVhbGluZyB3aXRoIHRoaXMgc2V0IG9m IGNvbW1lbnRzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQpjb2xvcjpi bHVlJz4tJm5ic3A7Jm5ic3A7Jm5ic3A7IGdvaW5nIHRocm91Z2ggYW5kIG1vZGlmeWluZyBhbGwg dGhlIGlkZW50aWZpZWQNCnJlcXVpcmVtZW50cyB3aGVyZSB0aGUgY29tbWVudCBpcyB1cGhlbGQu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48 L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOmJsdWUnPi0mbmJz cDsmbmJzcDsmbmJzcDsgbWFraW5nIG1vcmUgY2xlYXIgaW4gdGhlIGFic3RyYWN0IGFuZCAvIG9y DQppbnRyb2R1Y3Rpb24gdGhhdCB0aGlzIGlzIHNvbGVseSB0aGUgdmlldyBvZiBJRVRGIGluIHJl Z2FyZCB0byBJUCBjYXBhYmxlDQpkZXZpY2VzIGFuZCB0aGF0IG90aGVyIG9yZ2FuaXNhdGlvbnMg bWF5IHNwZWNpZnkgb3RoZXIgcmVxdWlyZW1lbnRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7DQpjb2xvcjpibHVlJz5JIHdvdWxkIG5vdGUgYXQgdGhpcyBwb2ludCB0aGF0 IHRoZSBjdXJyZW50IGFic3RyYWN0IHNheXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjsNCmNvbG9yOmJsdWUnPiZuYnNwOyZuYnNwOyBUaGUgSUVURiBhbmQgb3RoZXIgc3Rh bmRhcmRzIG9yZ2FuaXphdGlvbiBoYXZlIGVmZm9ydHMNCnRhcmdldGVkIGF0PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQpjb2xvcjpi bHVlJz4mbmJzcDsmbmJzcDsgc3RhbmRhcmRpemluZyB2YXJpb3VzIGFzcGVjdHMgb2YgcGxhY2lu ZyBlbWVyZ2VuY3kNCmNhbGxzIG9uIElQPGJyPg0KJm5ic3A7Jm5ic3A7IG5ldHdvcmtzLiZuYnNw OyBUaGlzIG1lbW8gZGVzY3JpYmVzIGJlc3QgY3VycmVudCBwcmFjdGljZSBvbiBob3cNCmRldmlj ZXMsPGJyPg0KJm5ic3A7Jm5ic3A7IG5ldHdvcmtzIGFuZCBzZXJ2aWNlcyBzaG91bGQgdXNlIHN1 Y2ggc3RhbmRhcmRzIHRvIG1ha2UgZW1lcmdlbmN5PGJyPg0KJm5ic3A7Jm5ic3A7IGNhbGxzLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm IjsNCmNvbG9yOmJsdWUnPkJlY2F1c2UgdGhlIHR3byBzZW50ZW5jZXMgZm9sbG93IGVhY2ggb3Ro ZXIsIGl0IGltcGxpZXMgdGhhdCBvdGhlcg0KU0RPcyB0aGF0IGhhdmUgZWZmb3J0cyB0YXJnZXR0 ZWQgYXQgYWRkcmVzc2luZyB0aGVzZSBzb2x1dGlvbnMgYXJlIGNvbXBsaWNpdCBpbg0KdGhlIHJl cXVpcmVtZW50cyBzbyBzdGF0ZWQsIGFuZCB0aGlzIGlzIHVudHJ1ZS4gQ2VydGFpbmx5IHRoZSBj dXJyZW50IHN0YXR1cyBvZg0KdGhpcyBkb2N1bWVudCBhcyBhZGRyZXNzZWQgYnkgdmFyaW91cyBp bmZvcm1hbCAzR1BQIGRpc2N1c3Npb25zIGlzIHRvIGVuc3VyZQ0KdGhhdCB0aGluZ3MgZG8gbm90 IGZhbGwgYXBhcnQgaW4gZW50aXRpZXMgdXNpbmcgdGhlIDNHUFAgbWVjaGFuaXNtcywgaG93ZXZl cg0KM0dQUCBkZXZpY2VzIGRvIG5vdCB1c2UgdGhlc2UgcmVxdWlyZW1lbnRzIChubyBkbyB0aGVz ZSByZXF1aXJlbWVudHMgcmVwcmVzZW50DQp0aGUgM0dQUCByZXF1aXJlcy48L3NwYW4+PG86cD48 L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KY29sb3I6Ymx1ZSc+T25lIHNvbHV0aW9uIHRvIHRo ZSBpc3N1ZSB3b3VsZCBqdXN0IGJlIHRvIG1ha2UgbXVjaCBjbGVhcmVyIHdoaWNoDQpTRE9zIGhh dmUgcGFydGljaXBhdGVkIGluIHRoaXMgd29yayBhbmQgd2hpY2ggaGF2ZSBub3QgYW5kIHRoZSBz dGF0dXMgb2YgdGhhdA0KcHJvZ3Jlc3MgLSBob3dldmVyIHRoYXQgd2FzIGFsc28gd2hhdCBwZW9w bGUga2VlcCBjYWxsaW5nIHRoZQ0KJnF1b3Q7YXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQmcXVvdDsg d2FzIHRyeWluZyB0byBkby48L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0K Y29sb3I6Ymx1ZSc+cmVnYXJkczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 DQpjb2xvcjpibHVlJz5LZWl0aDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7 PG86cD48L286cD48L3A+DQoNCjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7DQptYXJnaW4t bGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0 b206NS4wcHQnPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoN CjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50 ZXInPjxzcGFuIGxhbmc9RU4tVVM+DQoNCjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNl bnRlcj4NCg0KPC9zcGFuPjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdp bi1ib3R0b206MTIuMHB0Jz48Yj48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48 c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiInPg0KZWNyaXQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmVjcml0 LWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+TWFyYw0KTGluc25lcjxicj4N CjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bHkgMjksIDIwMDkgMjo1MyBQTTxicj4NCjxiPlRv OjwvYj4gJ2Vjcml0Jzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbRWNyaXRdIEhVTSBvbiBQaG9uZUJD UDwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiInPkR1cmluZw0KdG9kYXnigJlzIG1lZXRpbmcgdGhlcmUgd2Fz IGRpc2N1c3Npb24gYXMgdG8gd2h5IHRoZSBjaGFpcnMgUHVibGljYXRpb24gUmVxdWVzdGVkDQpQ aG9uZUJDUCB2ZXJzaW9uIDEzIHdoZW4gdGhlcmUgYXJlIHVucmVzb2x2ZWQgaXNzdWVzLiAmbmJz cDtUaGlzIGRpc2N1c3Npb24gbGVkDQp1cyB0byBjYWxsIGZvciBhIGh1bS4gJm5ic3A7V2UgYXJl IG5vdyBhc2tpbmcgdGhlIHNhbWUgcXVlc3Rpb24gb24gdGhlIGxpc3QuPGJyPg0KPGJyPg0KPHNw YW4gc3R5bGU9J2NvbG9yOiMxMjEyMTInPkRvIHlvdSBhZ3JlZSBvciBkaXNhZ3JlZSB0aGF0IFBo b25lQkNQIC0xMyBpcyByZWFkeQ0KdG8gUHVibGljYXRpb24gUmVxdWVzdD88YnI+DQo8YnI+DQpQ bGVhc2UgcmVzcG9uZCBieSBjbG9zZSBvZiBidXNpbmVzcyBvbiBXZWRuZXNkYXkgQXVndXN0IDV0 aC48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KPGJyPg0KTWFyYyAmYW1wOyBIYW5uZXM8bzpwPjwv bzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KDQo8L2Jsb2NrcXVvdGU+DQoNCjwvZGl2Pg0KDQo8L2Rp dj4NCg0KPGJyPjxicj48dGFibGUgYmdjb2xvcj13aGl0ZSBzdHlsZT0iY29sb3I6YmxhY2siPjx0 cj48dGQ+PGJyPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClRo aXMmbmJzcDttZXNzYWdlJm5ic3A7aXMmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDtkZXNpZ25hdGVk Jm5ic3A7cmVjaXBpZW50Jm5ic3A7b25seSZuYnNwO2FuZCZuYnNwO21heTxicj4NCmNvbnRhaW4m bmJzcDtwcml2aWxlZ2VkLCZuYnNwO3Byb3ByaWV0YXJ5LCZuYnNwO29yJm5ic3A7b3RoZXJ3aXNl Jm5ic3A7cHJpdmF0ZSZuYnNwO2luZm9ybWF0aW9uLiZuYnNwOyZuYnNwOzxicj4NCklmJm5ic3A7 eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7aXQmbmJzcDtpbiZuYnNwO2Vycm9yLCZu YnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO3NlbmRlcjxicj4NCmltbWVkaWF0 ZWx5Jm5ic3A7YW5kJm5ic3A7ZGVsZXRlJm5ic3A7dGhlJm5ic3A7b3JpZ2luYWwuJm5ic3A7Jm5i c3A7QW55Jm5ic3A7dW5hdXRob3JpemVkJm5ic3A7dXNlJm5ic3A7b2Y8YnI+DQp0aGlzJm5ic3A7 ZW1haWwmbmJzcDtpcyZuYnNwO3Byb2hpYml0ZWQuPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KW21mMl08L3RkPjwvdHI+PC90YWJsZT48L2JvZHk+DQoN CjwvaHRtbD4NCg== ------_=_NextPart_001_01CA10EC.92B5ACE4-- From drage@alcatel-lucent.com Thu Jul 30 01:31:03 2009 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 D0F243A7172 for ; Thu, 30 Jul 2009 01:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.52 X-Spam-Level: X-Spam-Status: No, score=-5.52 tagged_above=-999 required=5 tests=[AWL=0.728, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 uRm5V7wh+I8A for ; Thu, 30 Jul 2009 01:31:02 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id EF3C53A6C2F for ; Thu, 30 Jul 2009 01:31:01 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n6U8UvbA018209 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Jul 2009 10:30:57 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 30 Jul 2009 10:30:57 +0200 From: "DRAGE, Keith (Keith)" To: "Thomson, Martin" , Marc Linsner , ecrit Date: Thu, 30 Jul 2009 10:30:56 +0200 Thread-Topic: [Ecrit] (aside) HUM on PhoneBCP Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAACNBRHAAACMDMA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE2070BE6ECFRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Subject: Re: [Ecrit] (aside) HUM on 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: Thu, 30 Jul 2009 08:31:03 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE2070BE6ECFRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgZGlzY3Vzc2VkIFN0ZXBoZW5zIGNvbmNlcm5zIG9uIGZyYW1ld29yay4NCg0KSSB3ZW50IGJh Y2sgdGhyb3VnaCBib3RoIG15IG93biBhcmNoaXZlIGFuZCB0aGUgd2ViIGFyY2hpdmUgYW5kIGZv dW5kIG5vdGhpbmcgYWRkcmVzc2luZyBwaG9uZSBiY3AgY29tbWVudHMgZGlyZWN0bHkuLg0KDQpL ZWl0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogVGhvbXNvbiwg TWFydGluIFttYWlsdG86TWFydGluLlRob21zb25AYW5kcmV3LmNvbV0NClNlbnQ6IFRodXJzZGF5 LCBKdWx5IDMwLCAyMDA5IDk6MDYgQU0NClRvOiBEUkFHRSwgS2VpdGggKEtlaXRoKTsgTWFyYyBM aW5zbmVyOyBlY3JpdA0KU3ViamVjdDogUkU6IFtFY3JpdF0gKGFzaWRlKSBIVU0gb24gUGhvbmVC Q1ANCg0KS2VpdGgsDQoNClRoaXMgd29ya2luZyBncm91cCBoYXMgZGlzY3Vzc2VkLCBhdCBncmVh dCBsZW5ndGgsIFN0ZXBoZW7igJlzIGNvbmNlcm5zLiAgSWYgYSBzcGVjaWZpYyBlbWFpbCBoYXMg bm90IGhhZCBhbnkgcmVzcG9uc2UsIHRoYXQgY2Fubm90IGJlIHRha2VuIGFzIGFuIGluZGljYXRp b24gb25lIHdheSBvciBvdGhlci4NCg0KWW91IG1heSBjb25zaWRlciB0aGlzIGh1bSBpcyBvbiB3 aGV0aGVyIHlvdSB0aGluayB0aG9zZSBjb21tZW50cyB2YWxpZC4NCg0KLS1NYXJ0aW4NCg0KRnJv bTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBEUkFHRSwgS2VpdGggKEtlaXRoKQ0KU2VudDogVGh1cnNkYXksIDMwIEp1 bHkgMjAwOSAxMDowMSBBTQ0KVG86IE1hcmMgTGluc25lcjsgJ2Vjcml0Jw0KU3ViamVjdDogUmU6 IFtFY3JpdF0gSFVNIG9uIFBob25lQkNQDQoNCkkgZG9uJ3QgYWdyZWUuDQoNClNvbWUgYmFja2dy b3VuZC4NCg0KVGhlcmUgd2FzIGEgc2V0IG9mIGNvbW1lbnRzIHByb3ZpZGVkIGJ5IFN0ZXBoZW4g RWRnZSBvbiA1dGggRmVicnVhcnkgMjAwOS4gSSBjYW4gZmluZCBubyByZXNwb25zZSB0byB0aGF0 IHNldCBvZiBjb21tZW50cyBvbiB0aGUgbWFpbGluZyBsaXN0Lg0KDQpUaGUgZ2lzdCBvZiB0aGF0 IHNldCBvZiBjb21tZW50cyB3YXMgdGhhdCBwaG9uZWJjcCBjbGFpbXMgdG8gY292ZXIgYWxsIGFj Y2VzcyB0ZWNobm9sb2dpZXMgYW5kIGl0IGlkZW50aWZpZWQgYSBzaWduaWZpY2FudCBudW1iZXIg b2YgcmVxdWlyZW1lbnRzIHdpdGhpbiBwaG9uZWJjcCB0aGF0IHRoZSBhdXRob3IgY29uc2lkZXJl ZCB3ZXJlIG5vdCByZXF1aXJlbWVudHMgb24gM0dQUCBhY2Nlc3Nlcy4NCg0KU28gbXkgcG9zaXRp b24gaXMgdGhhdCB0aGUgZG9jdW1lbnQgaXMgbm90IHJlYWR5IGJlY2F1c2UgYWxsIHRoZSB2YWxp ZCBjb21tZW50cyBvbiB0aGUgZG9jdW1lbnQgd2VyZSBub3QgYWRkcmVzc2VkLg0KDQpUaGVyZSBh cmUgdHdvIHdheXMgb2YgZGVhbGluZyB3aXRoIHRoaXMgc2V0IG9mIGNvbW1lbnRzOg0KDQotICAg IGdvaW5nIHRocm91Z2ggYW5kIG1vZGlmeWluZyBhbGwgdGhlIGlkZW50aWZpZWQgcmVxdWlyZW1l bnRzIHdoZXJlIHRoZSBjb21tZW50IGlzIHVwaGVsZC4NCg0KLSAgICBtYWtpbmcgbW9yZSBjbGVh ciBpbiB0aGUgYWJzdHJhY3QgYW5kIC8gb3IgaW50cm9kdWN0aW9uIHRoYXQgdGhpcyBpcyBzb2xl bHkgdGhlIHZpZXcgb2YgSUVURiBpbiByZWdhcmQgdG8gSVAgY2FwYWJsZSBkZXZpY2VzIGFuZCB0 aGF0IG90aGVyIG9yZ2FuaXNhdGlvbnMgbWF5IHNwZWNpZnkgb3RoZXIgcmVxdWlyZW1lbnRzLg0K DQpJIHdvdWxkIG5vdGUgYXQgdGhpcyBwb2ludCB0aGF0IHRoZSBjdXJyZW50IGFic3RyYWN0IHNh eXM6DQoNCiAgIFRoZSBJRVRGIGFuZCBvdGhlciBzdGFuZGFyZHMgb3JnYW5pemF0aW9uIGhhdmUg ZWZmb3J0cyB0YXJnZXRlZCBhdA0KICAgc3RhbmRhcmRpemluZyB2YXJpb3VzIGFzcGVjdHMgb2Yg cGxhY2luZyBlbWVyZ2VuY3kgY2FsbHMgb24gSVANCiAgIG5ldHdvcmtzLiAgVGhpcyBtZW1vIGRl c2NyaWJlcyBiZXN0IGN1cnJlbnQgcHJhY3RpY2Ugb24gaG93IGRldmljZXMsDQogICBuZXR3b3Jr cyBhbmQgc2VydmljZXMgc2hvdWxkIHVzZSBzdWNoIHN0YW5kYXJkcyB0byBtYWtlIGVtZXJnZW5j eQ0KICAgY2FsbHMuDQpCZWNhdXNlIHRoZSB0d28gc2VudGVuY2VzIGZvbGxvdyBlYWNoIG90aGVy LCBpdCBpbXBsaWVzIHRoYXQgb3RoZXIgU0RPcyB0aGF0IGhhdmUgZWZmb3J0cyB0YXJnZXR0ZWQg YXQgYWRkcmVzc2luZyB0aGVzZSBzb2x1dGlvbnMgYXJlIGNvbXBsaWNpdCBpbiB0aGUgcmVxdWly ZW1lbnRzIHNvIHN0YXRlZCwgYW5kIHRoaXMgaXMgdW50cnVlLiBDZXJ0YWlubHkgdGhlIGN1cnJl bnQgc3RhdHVzIG9mIHRoaXMgZG9jdW1lbnQgYXMgYWRkcmVzc2VkIGJ5IHZhcmlvdXMgaW5mb3Jt YWwgM0dQUCBkaXNjdXNzaW9ucyBpcyB0byBlbnN1cmUgdGhhdCB0aGluZ3MgZG8gbm90IGZhbGwg YXBhcnQgaW4gZW50aXRpZXMgdXNpbmcgdGhlIDNHUFAgbWVjaGFuaXNtcywgaG93ZXZlciAzR1BQ IGRldmljZXMgZG8gbm90IHVzZSB0aGVzZSByZXF1aXJlbWVudHMgKG5vIGRvIHRoZXNlIHJlcXVp cmVtZW50cyByZXByZXNlbnQgdGhlIDNHUFAgcmVxdWlyZXMuDQoNCk9uZSBzb2x1dGlvbiB0byB0 aGUgaXNzdWUgd291bGQganVzdCBiZSB0byBtYWtlIG11Y2ggY2xlYXJlciB3aGljaCBTRE9zIGhh dmUgcGFydGljaXBhdGVkIGluIHRoaXMgd29yayBhbmQgd2hpY2ggaGF2ZSBub3QgYW5kIHRoZSBz dGF0dXMgb2YgdGhhdCBwcm9ncmVzcyAtIGhvd2V2ZXIgdGhhdCB3YXMgYWxzbyB3aGF0IHBlb3Bs ZSBrZWVwIGNhbGxpbmcgdGhlICJhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCIgd2FzIHRyeWluZyB0 byBkby4NCg0KcmVnYXJkcw0KDQpLZWl0aA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyYyBMaW5zbmVyDQpTZW50OiBXZWRuZXNkYXks IEp1bHkgMjksIDIwMDkgMjo1MyBQTQ0KVG86ICdlY3JpdCcNClN1YmplY3Q6IFtFY3JpdF0gSFVN IG9uIFBob25lQkNQDQpEdXJpbmcgdG9kYXnigJlzIG1lZXRpbmcgdGhlcmUgd2FzIGRpc2N1c3Np b24gYXMgdG8gd2h5IHRoZSBjaGFpcnMgUHVibGljYXRpb24gUmVxdWVzdGVkIFBob25lQkNQIHZl cnNpb24gMTMgd2hlbiB0aGVyZSBhcmUgdW5yZXNvbHZlZCBpc3N1ZXMuICBUaGlzIGRpc2N1c3Np b24gbGVkIHVzIHRvIGNhbGwgZm9yIGEgaHVtLiAgV2UgYXJlIG5vdyBhc2tpbmcgdGhlIHNhbWUg cXVlc3Rpb24gb24gdGhlIGxpc3QuDQoNCkRvIHlvdSBhZ3JlZSBvciBkaXNhZ3JlZSB0aGF0IFBo b25lQkNQIC0xMyBpcyByZWFkeSB0byBQdWJsaWNhdGlvbiBSZXF1ZXN0Pw0KDQpQbGVhc2UgcmVz cG9uZCBieSBjbG9zZSBvZiBidXNpbmVzcyBvbiBXZWRuZXNkYXkgQXVndXN0IDV0aC4NCg0KVGhh bmtzLA0KDQpNYXJjICYgSGFubmVzDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50 IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3 aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBv cmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0 ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJdDQo= --_000_EDC0A1AE77C57744B664A310A0B23AE2070BE6ECFRMRSSXCHMBSC3d_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MIHhtbG5zOnYgPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm8gPSANCiJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHht bG5zOncgPSANCiJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczpt ID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIj48 SEVBRD48VElUTEU+SFVNIG9uIFBob25lQkNQPC9USVRMRT4NCjxNRVRBIGh0dHAtZXF1aXY9Q29u dGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8TUVUQSBjb250 ZW50PSJNU0hUTUwgNi4wMC4yOTAwLjM0OTIiIG5hbWU9R0VORVJBVE9SPjwhLS1baWYgIW1zb10+ DQo8U1RZTEU+dlw6KiB7DQoJQkVIQVZJT1I6IHVybCgjZGVmYXVsdCNWTUwpDQp9DQpvXDoqIHsN CglCRUhBVklPUjogdXJsKCNkZWZhdWx0I1ZNTCkNCn0NCndcOiogew0KCUJFSEFWSU9SOiB1cmwo I2RlZmF1bHQjVk1MKQ0KfQ0KLnNoYXBlIHsNCglCRUhBVklPUjogdXJsKCNkZWZhdWx0I1ZNTCkN Cn0NCjwvU1RZTEU+DQo8IVtlbmRpZl0tLT4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250LWZh bWlseTogQ2FtYnJpYSBNYXRoOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IENhbGli cmk7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogVGFob21hOw0KfQ0KQHBhZ2UgU2Vj dGlvbjEge3NpemU6IDYxMi4wcHQgNzkyLjBwdDsgbWFyZ2luOiA3Mi4wcHQgNzIuMHB0IDcyLjBw dCA3Mi4wcHQ7IH0NClAuTXNvTm9ybWFsIHsNCglGT05ULVNJWkU6IDEycHQ7IE1BUkdJTjogMGNt IDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiDQp9DQpMSS5N c29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTJwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1G QU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiINCn0NCkRJVi5Nc29Ob3JtYWwgew0KCUZP TlQtU0laRTogMTJwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiINCn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JB VElPTjogdW5kZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpTUEFOLk1zb0h5cGVy bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyBtc28tc3R5 bGUtcHJpb3JpdHk6IDk5DQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVD T1JBVElPTjogdW5kZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpTUEFOLk1zb0h5 cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09SQVRJT046IHVuZGVy bGluZTsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0KCUNP TE9SOiAjMjQ0MDYxOyBGT05ULUZBTUlMWTogIkNhbGlicmkiLCJzYW5zLXNlcmlmIjsgbXNvLXN0 eWxlLXR5cGU6IHBlcnNvbmFsLXJlcGx5DQp9DQouTXNvQ2hwRGVmYXVsdCB7DQoJRk9OVC1TSVpF OiAxMHB0OyBtc28tc3R5bGUtdHlwZTogZXhwb3J0LW9ubHkNCn0NCkRJVi5TZWN0aW9uMSB7DQoJ cGFnZTogU2VjdGlvbjENCn0NCjwvU1RZTEU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9IRUFEPg0KPEJPRFkgbGFuZz1FTi1BVSB2TGluaz1w dXJwbGUgbGluaz1ibHVlPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MzI3 NDUwNjA4LTMwMDcyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj5J dCBkaXNjdXNzZWQgU3RlcGhlbnMgY29uY2VybnMgb24gDQpmcmFtZXdvcmsuPC9GT05UPjwvU1BB Tj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTMyNzQ1MDYwOC0z MDA3MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjwv U1BBTj4mbmJzcDs8L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTMy NzQ1MDYwOC0zMDA3MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBmZiBzaXplPTI+ SSB3ZW50IGJhY2sgdGhyb3VnaCBib3RoIG15IG93biBhcmNoaXZlIGFuZCB0aGUgd2ViIGFyY2hp dmUgDQphbmQgZm91bmQgbm90aGluZyBhZGRyZXNzaW5nIHBob25lIGJjcCBjb21tZW50cyBkaXJl Y3RseS4uPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFO IGNsYXNzPTMyNzQ1MDYwOC0zMDA3MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBm ZiBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1s ZWZ0PjxTUEFOIGNsYXNzPTMyNzQ1MDYwOC0zMDA3MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KY29s b3I9IzAwMDBmZiBzaXplPTI+S2VpdGg8L0ZPTlQ+PC9TUEFOPjwvRElWPjxCUj4NCjxCTE9DS1FV T1RFIA0Kc3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVIt TEVGVDogIzAwMDBmZiAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBjbGFz cz1PdXRsb29rTWVzc2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD4NCiAg PEhSIHRhYkluZGV4PS0xPg0KICA8Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RnJvbTo8L0I+ IFRob21zb24sIE1hcnRpbiANCiAgW21haWx0bzpNYXJ0aW4uVGhvbXNvbkBhbmRyZXcuY29tXSA8 QlI+PEI+U2VudDo8L0I+IFRodXJzZGF5LCBKdWx5IDMwLCAyMDA5IA0KICA5OjA2IEFNPEJSPjxC PlRvOjwvQj4gRFJBR0UsIEtlaXRoIChLZWl0aCk7IE1hcmMgTGluc25lcjsgDQogIGVjcml0PEJS PjxCPlN1YmplY3Q6PC9CPiBSRTogW0Vjcml0XSAoYXNpZGUpIEhVTSBvbiANCiAgUGhvbmVCQ1A8 QlI+PC9GT05UPjxCUj48L0RJVj4NCiAgPERJVj48L0RJVj4NCiAgPERJViBjbGFzcz1TZWN0aW9u MT4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0 OyBDT0xPUjogIzI0NDA2MTsgRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZiciPktl aXRoLDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0K ICBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBDT0xPUjogIzI0NDA2MTsgRk9OVC1GQU1JTFk6ICdD YWxpYnJpJywnc2Fucy1zZXJpZiciPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBDT0xPUjog IzI0NDA2MTsgRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZiciPlRoaXMgDQogIHdv cmtpbmcgZ3JvdXAgaGFzIGRpc2N1c3NlZCwgYXQgZ3JlYXQgbGVuZ3RoLCBTdGVwaGVu4oCZcyBj b25jZXJucy4mbmJzcDsgSWYgYSANCiAgc3BlY2lmaWMgZW1haWwgaGFzIG5vdCBoYWQgYW55IHJl c3BvbnNlLCB0aGF0IGNhbm5vdCBiZSB0YWtlbiBhcyBhbiBpbmRpY2F0aW9uIA0KICBvbmUgd2F5 IG9yIG90aGVyLjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxT UEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBDT0xPUjogIzI0NDA2MTsgRk9OVC1GQU1J TFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZiciPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4N CiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBD T0xPUjogIzI0NDA2MTsgRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZiciPllvdSAN CiAgbWF5IGNvbnNpZGVyIHRoaXMgaHVtIGlzIG9uIHdoZXRoZXIgeW91IHRoaW5rIHRob3NlIGNv bW1lbnRzIA0KICB2YWxpZC48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05v cm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgQ09MT1I6ICMyNDQwNjE7IEZP TlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BB Tj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTog MTFwdDsgQ09MT1I6ICMyNDQwNjE7IEZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYn Ij4tLU1hcnRpbjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxT UEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBDT0xPUjogIzI0NDA2MTsgRk9OVC1GQU1J TFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZiciPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4N CiAgPERJViANCiAgc3R5bGU9IkJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctUklH SFQ6IDBjbTsgQk9SREVSLVRPUDogbWVkaXVtIG5vbmU7IFBBRERJTkctTEVGVDogNHB0OyBQQURE SU5HLUJPVFRPTTogMGNtOyBCT1JERVItTEVGVDogYmx1ZSAxLjVwdCBzb2xpZDsgUEFERElORy1U T1A6IDBjbTsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmUiPg0KICA8RElWPg0KICA8RElWIA0K ICBzdHlsZT0iQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1SSUdIVDogMGNtOyBC T1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgUEFERElORy1MRUZUOiAwY207IFBBRERJTkct Qk9UVE9NOiAwY207IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdDsg Qk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmUiPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEI+PFNQ QU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdU YWhvbWEnLCdzYW5zLXNlcmlmJyI+RnJvbTo8L1NQQU4+PC9CPjxTUEFOIA0KICBsYW5nPUVOLVVT IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJp ZiciPiANCiAgZWNyaXQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0 Zi5vcmddIDxCPk9uIEJlaGFsZiBPZiANCiAgPC9CPkRSQUdFLCBLZWl0aCAoS2VpdGgpPEJSPjxC PlNlbnQ6PC9CPiBUaHVyc2RheSwgMzAgSnVseSAyMDA5IDEwOjAxIA0KICBBTTxCUj48Qj5Ubzo8 L0I+IE1hcmMgTGluc25lcjsgJ2Vjcml0JzxCUj48Qj5TdWJqZWN0OjwvQj4gUmU6IFtFY3JpdF0g SFVNIG9uIA0KICBQaG9uZUJDUDxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj48L0RJVj4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05U LUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPkkgDQogIGRvbid0IGFncmVlLjwvU1BBTj48 bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9Q Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPlNvbWUgDQog IGJhY2tncm91bmQuPC9TUEFOPjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+ Jm5ic3A7PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiAnQXJpYWwnLCdz YW5zLXNlcmlmJyI+VGhlcmUgDQogIHdhcyBhIHNldCBvZiBjb21tZW50cyBwcm92aWRlZCBieSBT dGVwaGVuIEVkZ2Ugb24gNXRoIEZlYnJ1YXJ5IDIwMDkuIEkgY2FuIA0KICBmaW5kIG5vIHJlc3Bv bnNlIHRvIHRoYXQgc2V0IG9mIGNvbW1lbnRzIG9uIHRoZSBtYWlsaW5nIA0KICBsaXN0LjwvU1BB Tj48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+ PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPlRoZSAN CiAgZ2lzdCBvZiB0aGF0IHNldCBvZiBjb21tZW50cyB3YXMgdGhhdCBwaG9uZWJjcCBjbGFpbXMg dG8gY292ZXIgYWxsIGFjY2VzcyANCiAgdGVjaG5vbG9naWVzIGFuZCBpdCBpZGVudGlmaWVkIGEg c2lnbmlmaWNhbnQgbnVtYmVyIG9mIHJlcXVpcmVtZW50cyB3aXRoaW4gDQogIHBob25lYmNwIHRo YXQgdGhlIGF1dGhvciBjb25zaWRlcmVkIHdlcmUgbm90IHJlcXVpcmVtZW50cyBvbiAzR1BQIA0K ICBhY2Nlc3Nlcy48L1NQQU4+PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD4m bmJzcDs8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3Nh bnMtc2VyaWYnIj5TbyBteSANCiAgcG9zaXRpb24gaXMgdGhhdCB0aGUgZG9jdW1lbnQgaXMgbm90 IHJlYWR5IGJlY2F1c2UgYWxsIHRoZSB2YWxpZCBjb21tZW50cyBvbiANCiAgdGhlIGRvY3VtZW50 IHdlcmUgbm90IGFkZHJlc3NlZC48L1NQQU4+PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1z b05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6ICdB cmlhbCcsJ3NhbnMtc2VyaWYnIj5UaGVyZSANCiAgYXJlIHR3byB3YXlzIG9mIGRlYWxpbmcgd2l0 aCB0aGlzIHNldCBvZiBjb21tZW50czo8L1NQQU4+PG86cD48L286cD48L1A+DQogIDxQIGNsYXNz PU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxT UEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6 ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj4tJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBnb2luZyB0aHJv dWdoIGFuZCBtb2RpZnlpbmcgYWxsIHRoZSBpZGVudGlmaWVkIHJlcXVpcmVtZW50cyB3aGVyZSB0 aGUgY29tbWVudCANCiAgaXMgdXBoZWxkLjwvU1BBTj48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xh c3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+ PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlM WTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPi0mbmJzcDsmbmJzcDsmbmJzcDsgDQogIG1ha2luZyBt b3JlIGNsZWFyIGluIHRoZSBhYnN0cmFjdCBhbmQgLyBvciBpbnRyb2R1Y3Rpb24gdGhhdCB0aGlz IGlzIHNvbGVseSANCiAgdGhlIHZpZXcgb2YgSUVURiBpbiByZWdhcmQgdG8gSVAgY2FwYWJsZSBk ZXZpY2VzIGFuZCB0aGF0IG90aGVyIG9yZ2FuaXNhdGlvbnMgDQogIG1heSBzcGVjaWZ5IG90aGVy IHJlcXVpcmVtZW50cy48L1NQQU4+PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1h bD4mbmJzcDs8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6ICdBcmlhbCcs J3NhbnMtc2VyaWYnIj5JIA0KICB3b3VsZCBub3RlIGF0IHRoaXMgcG9pbnQgdGhhdCB0aGUgY3Vy cmVudCBhYnN0cmFjdCBzYXlzOjwvU1BBTj48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNv Tm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4g DQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogJ0Fy aWFsJywnc2Fucy1zZXJpZiciPiZuYnNwOyZuYnNwOyANCiAgVGhlIElFVEYgYW5kIG90aGVyIHN0 YW5kYXJkcyBvcmdhbml6YXRpb24gaGF2ZSBlZmZvcnRzIHRhcmdldGVkIA0KICBhdDwvU1BBTj48 bzpwPjwvbzpwPjwvUD4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6ICdBcmlhbCcs J3NhbnMtc2VyaWYnIj4mbmJzcDsmbmJzcDsgDQogIHN0YW5kYXJkaXppbmcgdmFyaW91cyBhc3Bl Y3RzIG9mIHBsYWNpbmcgZW1lcmdlbmN5IGNhbGxzIG9uIElQPEJSPiZuYnNwOyZuYnNwOyANCiAg bmV0d29ya3MuJm5ic3A7IFRoaXMgbWVtbyBkZXNjcmliZXMgYmVzdCBjdXJyZW50IHByYWN0aWNl IG9uIGhvdyANCiAgZGV2aWNlcyw8QlI+Jm5ic3A7Jm5ic3A7IG5ldHdvcmtzIGFuZCBzZXJ2aWNl cyBzaG91bGQgdXNlIHN1Y2ggc3RhbmRhcmRzIHRvIA0KICBtYWtlIGVtZXJnZW5jeTxCUj4mbmJz cDsmbmJzcDsgY2FsbHMuPC9TUEFOPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICA8UCBjbGFzcz1N c29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBG T05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPkJlY2F1c2UgDQogIHRoZSB0d28gc2Vu dGVuY2VzIGZvbGxvdyBlYWNoIG90aGVyLCBpdCBpbXBsaWVzIHRoYXQgb3RoZXIgU0RPcyB0aGF0 IGhhdmUgDQogIGVmZm9ydHMgdGFyZ2V0dGVkIGF0IGFkZHJlc3NpbmcgdGhlc2Ugc29sdXRpb25z IGFyZSBjb21wbGljaXQgaW4gdGhlIA0KICByZXF1aXJlbWVudHMgc28gc3RhdGVkLCBhbmQgdGhp cyBpcyB1bnRydWUuIENlcnRhaW5seSB0aGUgY3VycmVudCBzdGF0dXMgb2YgDQogIHRoaXMgZG9j dW1lbnQgYXMgYWRkcmVzc2VkIGJ5IHZhcmlvdXMgaW5mb3JtYWwgM0dQUCBkaXNjdXNzaW9ucyBp cyB0byBlbnN1cmUgDQogIHRoYXQgdGhpbmdzIGRvIG5vdCBmYWxsIGFwYXJ0IGluIGVudGl0aWVz IHVzaW5nIHRoZSAzR1BQIG1lY2hhbmlzbXMsIGhvd2V2ZXIgDQogIDNHUFAgZGV2aWNlcyBkbyBu b3QgdXNlIHRoZXNlIHJlcXVpcmVtZW50cyAobm8gZG8gdGhlc2UgcmVxdWlyZW1lbnRzIHJlcHJl c2VudCANCiAgdGhlIDNHUFAgcmVxdWlyZXMuPC9TUEFOPjxvOnA+PC9vOnA+PC9QPg0KICA8UCBj bGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1h bD48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFN SUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJyI+T25lIA0KICBzb2x1dGlvbiB0byB0aGUgaXNzdWUg d291bGQganVzdCBiZSB0byBtYWtlIG11Y2ggY2xlYXJlciB3aGljaCBTRE9zIGhhdmUgDQogIHBh cnRpY2lwYXRlZCBpbiB0aGlzIHdvcmsgYW5kIHdoaWNoIGhhdmUgbm90IGFuZCB0aGUgc3RhdHVz IG9mIHRoYXQgcHJvZ3Jlc3MgLSANCiAgaG93ZXZlciB0aGF0IHdhcyBhbHNvIHdoYXQgcGVvcGxl IGtlZXAgY2FsbGluZyB0aGUgImFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IiANCiAgd2FzIHRyeWlu ZyB0byBkby48L1NQQU4+PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD4mbmJz cDs8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMt c2VyaWYnIj5yZWdhcmRzPC9TUEFOPjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWw+Jm5ic3A7PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiAnQXJpYWwn LCdzYW5zLXNlcmlmJyI+S2VpdGg8L1NQQU4+PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1z b05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPiZuYnNw OzxvOnA+PC9vOnA+PC9QPg0KICA8QkxPQ0tRVU9URSANCiAgc3R5bGU9IkJPUkRFUi1SSUdIVDog bWVkaXVtIG5vbmU7IFBBRERJTkctUklHSFQ6IDBjbTsgQk9SREVSLVRPUDogbWVkaXVtIG5vbmU7 IFBBRERJTkctTEVGVDogNHB0OyBQQURESU5HLUJPVFRPTTogMGNtOyBNQVJHSU46IDVwdCAwY20g NXB0IDMuNzVwdDsgQk9SREVSLUxFRlQ6IGJsdWUgMS41cHQgc29saWQ7IFBBRERJTkctVE9QOiAw Y207IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lIj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L1A+DQogICAgPERJViBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9IlRF WFQtQUxJR046IGNlbnRlciIgYWxpZ249Y2VudGVyPjxTUEFOIA0KICAgIGxhbmc9RU4tVVM+DQog ICAgPEhSIGFsaWduPWNlbnRlciB3aWR0aD0iMTAwJSIgU0laRT0yPg0KICAgIDwvU1BBTj48L0RJ Vj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDEycHQiPjxC PjxTUEFOIGxhbmc9RU4tVVMgDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J TFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJyI+RnJvbTo8L1NQQU4+PC9CPjxTUEFOIA0KICAgIGxh bmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdz YW5zLXNlcmlmJyI+IA0KICAgIGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1i b3VuY2VzQGlldGYub3JnXSA8Qj5PbiBCZWhhbGYgT2YgDQogICAgPC9CPk1hcmMgTGluc25lcjxC Uj48Qj5TZW50OjwvQj4gV2VkbmVzZGF5LCBKdWx5IDI5LCAyMDA5IDI6NTMgDQogICAgUE08QlI+ PEI+VG86PC9CPiAnZWNyaXQnPEJSPjxCPlN1YmplY3Q6PC9CPiBbRWNyaXRdIEhVTSBvbiANCiAg ICBQaG9uZUJDUDwvU1BBTj48U1BBTiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4N CiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTFw dDsgRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZiciPkR1cmluZyB0b2RheeKAmXMg DQogICAgbWVldGluZyB0aGVyZSB3YXMgZGlzY3Vzc2lvbiBhcyB0byB3aHkgdGhlIGNoYWlycyBQ dWJsaWNhdGlvbiBSZXF1ZXN0ZWQgDQogICAgUGhvbmVCQ1AgdmVyc2lvbiAxMyB3aGVuIHRoZXJl IGFyZSB1bnJlc29sdmVkIGlzc3Vlcy4gJm5ic3A7VGhpcyBkaXNjdXNzaW9uIA0KICAgIGxlZCB1 cyB0byBjYWxsIGZvciBhIGh1bS4gJm5ic3A7V2UgYXJlIG5vdyBhc2tpbmcgdGhlIHNhbWUgcXVl c3Rpb24gb24gdGhlIA0KICAgIGxpc3QuPEJSPjxCUj48U1BBTiBzdHlsZT0iQ09MT1I6ICMxMjEy MTIiPkRvIHlvdSBhZ3JlZSBvciBkaXNhZ3JlZSB0aGF0IA0KICAgIFBob25lQkNQIC0xMyBpcyBy ZWFkeSB0byBQdWJsaWNhdGlvbiBSZXF1ZXN0PzxCUj48QlI+UGxlYXNlIHJlc3BvbmQgYnkgY2xv c2UgDQogICAgb2YgYnVzaW5lc3Mgb24gV2VkbmVzZGF5IEF1Z3VzdCA1dGguPEJSPjxCUj5UaGFu a3MsPEJSPjxCUj5NYXJjICZhbXA7IA0KICAgIEhhbm5lczxvOnA+PC9vOnA+PC9TUEFOPjwvU1BB Tj48L1A+PC9CTE9DS1FVT1RFPjwvRElWPjwvRElWPjxCUj48QlI+DQogIDxUQUJMRSBzdHlsZT0i Q09MT1I6IGJsYWNrIiBiZ0NvbG9yPXdoaXRlPg0KICAgIDxUQk9EWT4NCiAgICA8VFI+DQogICAg ICA8VEQ+PEJSPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj5UaGlz Jm5ic3A7bWVzc2FnZSZuYnNwO2lzJm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7ZGVzaWduYXRlZCZu YnNwO3JlY2lwaWVudCZuYnNwO29ubHkmbmJzcDthbmQmbmJzcDttYXk8QlI+Y29udGFpbiZuYnNw O3ByaXZpbGVnZWQsJm5ic3A7cHJvcHJpZXRhcnksJm5ic3A7b3ImbmJzcDtvdGhlcndpc2UmbmJz cDtwcml2YXRlJm5ic3A7aW5mb3JtYXRpb24uJm5ic3A7Jm5ic3A7PEJSPklmJm5ic3A7eW91Jm5i c3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7aXQmbmJzcDtpbiZuYnNwO2Vycm9yLCZuYnNwO3Bs ZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO3NlbmRlcjxCUj5pbW1lZGlhdGVseSZuYnNw O2FuZCZuYnNwO2RlbGV0ZSZuYnNwO3RoZSZuYnNwO29yaWdpbmFsLiZuYnNwOyZuYnNwO0FueSZu YnNwO3VuYXV0aG9yaXplZCZuYnNwO3VzZSZuYnNwO29mPEJSPnRoaXMmbmJzcDtlbWFpbCZuYnNw O2lzJm5ic3A7cHJvaGliaXRlZC48QlI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPEJSPlttZjJdPC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48L0JMT0NLUVVPVEU+PC9C T0RZPjwvSFRNTD4NCg== --_000_EDC0A1AE77C57744B664A310A0B23AE2070BE6ECFRMRSSXCHMBSC3d_-- From Martin.Thomson@andrew.com Thu Jul 30 01:37:30 2009 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 21EAC28C1A2 for ; Thu, 30 Jul 2009 01:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.007, 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 gicNrMPYRia7 for ; Thu, 30 Jul 2009 01:37:28 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 8EAB628C12B for ; Thu, 30 Jul 2009 01:37:28 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_30_04_00_01 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 30 Jul 2009 03:59:58 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 03:37:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA10F0.F61482BB" Date: Thu, 30 Jul 2009 03:37:21 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] (aside) HUM on PhoneBCP Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAACNBRHAAACMDMAABD7BA References: From: "Thomson, Martin" To: "DRAGE, Keith (Keith)" , "Marc Linsner" , "ecrit" X-OriginalArrivalTime: 30 Jul 2009 08:37:25.0859 (UTC) FILETIME=[F72CE330:01CA10F0] Subject: Re: [Ecrit] (aside) HUM on 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: Thu, 30 Jul 2009 08:37:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA10F0.F61482BB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2luY2UgdGhleSB3ZXJlIHRoZSBzYW1lIGNvbmNlcm5zLCBJIGhhcmRseSBzZWUgdGhlIHBvaW50 IGluIHNwbGl0dGluZyBoYWlycy4NCg0KIA0KDQpGcm9tOiBEUkFHRSwgS2VpdGggKEtlaXRoKSBb bWFpbHRvOmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbV0gDQpTZW50OiBUaHVyc2RheSwgMzAgSnVs eSAyMDA5IDEwOjMxIEFNDQpUbzogVGhvbXNvbiwgTWFydGluOyBNYXJjIExpbnNuZXI7IGVjcml0 DQpTdWJqZWN0OiBSRTogW0Vjcml0XSAoYXNpZGUpIEhVTSBvbiBQaG9uZUJDUA0KDQogDQoNCkl0 IGRpc2N1c3NlZCBTdGVwaGVucyBjb25jZXJucyBvbiBmcmFtZXdvcmsuDQoNCiANCg0KSSB3ZW50 IGJhY2sgdGhyb3VnaCBib3RoIG15IG93biBhcmNoaXZlIGFuZCB0aGUgd2ViIGFyY2hpdmUgYW5k IGZvdW5kIG5vdGhpbmcgYWRkcmVzc2luZyBwaG9uZSBiY3AgY29tbWVudHMgZGlyZWN0bHkuLg0K DQogDQoNCktlaXRoDQoNCgkgDQoNCgkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNCg0KCUZyb206IFRob21zb24sIE1hcnRpbiBbbWFpbHRvOk1hcnRpbi5UaG9tc29uQGFuZHJl dy5jb21dIA0KCVNlbnQ6IFRodXJzZGF5LCBKdWx5IDMwLCAyMDA5IDk6MDYgQU0NCglUbzogRFJB R0UsIEtlaXRoIChLZWl0aCk7IE1hcmMgTGluc25lcjsgZWNyaXQNCglTdWJqZWN0OiBSRTogW0Vj cml0XSAoYXNpZGUpIEhVTSBvbiBQaG9uZUJDUA0KDQoJS2VpdGgsDQoNCgkgDQoNCglUaGlzIHdv cmtpbmcgZ3JvdXAgaGFzIGRpc2N1c3NlZCwgYXQgZ3JlYXQgbGVuZ3RoLCBTdGVwaGVu4oCZcyBj b25jZXJucy4gIElmIGEgc3BlY2lmaWMgZW1haWwgaGFzIG5vdCBoYWQgYW55IHJlc3BvbnNlLCB0 aGF0IGNhbm5vdCBiZSB0YWtlbiBhcyBhbiBpbmRpY2F0aW9uIG9uZSB3YXkgb3Igb3RoZXIuDQoN CgkgDQoNCglZb3UgbWF5IGNvbnNpZGVyIHRoaXMgaHVtIGlzIG9uIHdoZXRoZXIgeW91IHRoaW5r IHRob3NlIGNvbW1lbnRzIHZhbGlkLg0KDQoJIA0KDQoJLS1NYXJ0aW4NCg0KCSANCg0KCUZyb206 IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgRFJBR0UsIEtlaXRoIChLZWl0aCkNCglTZW50OiBUaHVyc2RheSwgMzAgSnVs eSAyMDA5IDEwOjAxIEFNDQoJVG86IE1hcmMgTGluc25lcjsgJ2Vjcml0Jw0KCVN1YmplY3Q6IFJl OiBbRWNyaXRdIEhVTSBvbiBQaG9uZUJDUA0KDQoJIA0KDQoJSSBkb24ndCBhZ3JlZS4NCg0KCSAN Cg0KCVNvbWUgYmFja2dyb3VuZC4NCg0KCSANCg0KCVRoZXJlIHdhcyBhIHNldCBvZiBjb21tZW50 cyBwcm92aWRlZCBieSBTdGVwaGVuIEVkZ2Ugb24gNXRoIEZlYnJ1YXJ5IDIwMDkuIEkgY2FuIGZp bmQgbm8gcmVzcG9uc2UgdG8gdGhhdCBzZXQgb2YgY29tbWVudHMgb24gdGhlIG1haWxpbmcgbGlz dC4NCg0KCSANCg0KCVRoZSBnaXN0IG9mIHRoYXQgc2V0IG9mIGNvbW1lbnRzIHdhcyB0aGF0IHBo b25lYmNwIGNsYWltcyB0byBjb3ZlciBhbGwgYWNjZXNzIHRlY2hub2xvZ2llcyBhbmQgaXQgaWRl bnRpZmllZCBhIHNpZ25pZmljYW50IG51bWJlciBvZiByZXF1aXJlbWVudHMgd2l0aGluIHBob25l YmNwIHRoYXQgdGhlIGF1dGhvciBjb25zaWRlcmVkIHdlcmUgbm90IHJlcXVpcmVtZW50cyBvbiAz R1BQIGFjY2Vzc2VzLg0KDQoJIA0KDQoJU28gbXkgcG9zaXRpb24gaXMgdGhhdCB0aGUgZG9jdW1l bnQgaXMgbm90IHJlYWR5IGJlY2F1c2UgYWxsIHRoZSB2YWxpZCBjb21tZW50cyBvbiB0aGUgZG9j dW1lbnQgd2VyZSBub3QgYWRkcmVzc2VkLg0KDQoJIA0KDQoJVGhlcmUgYXJlIHR3byB3YXlzIG9m IGRlYWxpbmcgd2l0aCB0aGlzIHNldCBvZiBjb21tZW50czoNCg0KCSANCg0KCS0gICAgZ29pbmcg dGhyb3VnaCBhbmQgbW9kaWZ5aW5nIGFsbCB0aGUgaWRlbnRpZmllZCByZXF1aXJlbWVudHMgd2hl cmUgdGhlIGNvbW1lbnQgaXMgdXBoZWxkLg0KDQoJIA0KDQoJLSAgICBtYWtpbmcgbW9yZSBjbGVh ciBpbiB0aGUgYWJzdHJhY3QgYW5kIC8gb3IgaW50cm9kdWN0aW9uIHRoYXQgdGhpcyBpcyBzb2xl bHkgdGhlIHZpZXcgb2YgSUVURiBpbiByZWdhcmQgdG8gSVAgY2FwYWJsZSBkZXZpY2VzIGFuZCB0 aGF0IG90aGVyIG9yZ2FuaXNhdGlvbnMgbWF5IHNwZWNpZnkgb3RoZXIgcmVxdWlyZW1lbnRzLg0K DQoJIA0KDQoJSSB3b3VsZCBub3RlIGF0IHRoaXMgcG9pbnQgdGhhdCB0aGUgY3VycmVudCBhYnN0 cmFjdCBzYXlzOg0KDQoJIA0KDQoJICAgVGhlIElFVEYgYW5kIG90aGVyIHN0YW5kYXJkcyBvcmdh bml6YXRpb24gaGF2ZSBlZmZvcnRzIHRhcmdldGVkIGF0DQoNCgkgICBzdGFuZGFyZGl6aW5nIHZh cmlvdXMgYXNwZWN0cyBvZiBwbGFjaW5nIGVtZXJnZW5jeSBjYWxscyBvbiBJUA0KCSAgIG5ldHdv cmtzLiAgVGhpcyBtZW1vIGRlc2NyaWJlcyBiZXN0IGN1cnJlbnQgcHJhY3RpY2Ugb24gaG93IGRl dmljZXMsDQoJICAgbmV0d29ya3MgYW5kIHNlcnZpY2VzIHNob3VsZCB1c2Ugc3VjaCBzdGFuZGFy ZHMgdG8gbWFrZSBlbWVyZ2VuY3kNCgkgICBjYWxscy4NCg0KCUJlY2F1c2UgdGhlIHR3byBzZW50 ZW5jZXMgZm9sbG93IGVhY2ggb3RoZXIsIGl0IGltcGxpZXMgdGhhdCBvdGhlciBTRE9zIHRoYXQg aGF2ZSBlZmZvcnRzIHRhcmdldHRlZCBhdCBhZGRyZXNzaW5nIHRoZXNlIHNvbHV0aW9ucyBhcmUg Y29tcGxpY2l0IGluIHRoZSByZXF1aXJlbWVudHMgc28gc3RhdGVkLCBhbmQgdGhpcyBpcyB1bnRy dWUuIENlcnRhaW5seSB0aGUgY3VycmVudCBzdGF0dXMgb2YgdGhpcyBkb2N1bWVudCBhcyBhZGRy ZXNzZWQgYnkgdmFyaW91cyBpbmZvcm1hbCAzR1BQIGRpc2N1c3Npb25zIGlzIHRvIGVuc3VyZSB0 aGF0IHRoaW5ncyBkbyBub3QgZmFsbCBhcGFydCBpbiBlbnRpdGllcyB1c2luZyB0aGUgM0dQUCBt ZWNoYW5pc21zLCBob3dldmVyIDNHUFAgZGV2aWNlcyBkbyBub3QgdXNlIHRoZXNlIHJlcXVpcmVt ZW50cyAobm8gZG8gdGhlc2UgcmVxdWlyZW1lbnRzIHJlcHJlc2VudCB0aGUgM0dQUCByZXF1aXJl cy4NCg0KCSANCg0KCU9uZSBzb2x1dGlvbiB0byB0aGUgaXNzdWUgd291bGQganVzdCBiZSB0byBt YWtlIG11Y2ggY2xlYXJlciB3aGljaCBTRE9zIGhhdmUgcGFydGljaXBhdGVkIGluIHRoaXMgd29y ayBhbmQgd2hpY2ggaGF2ZSBub3QgYW5kIHRoZSBzdGF0dXMgb2YgdGhhdCBwcm9ncmVzcyAtIGhv d2V2ZXIgdGhhdCB3YXMgYWxzbyB3aGF0IHBlb3BsZSBrZWVwIGNhbGxpbmcgdGhlICJhcHBsaWNh YmlsaXR5IHN0YXRlbWVudCIgd2FzIHRyeWluZyB0byBkby4NCg0KCSANCg0KCXJlZ2FyZHMNCg0K CSANCg0KCUtlaXRoDQoNCgkgDQoNCgkgDQoNCgkJIA0KDQoJCQ0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KDQoJCUZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyYyBMaW5zbmVyDQoJCVNl bnQ6IFdlZG5lc2RheSwgSnVseSAyOSwgMjAwOSAyOjUzIFBNDQoJCVRvOiAnZWNyaXQnDQoJCVN1 YmplY3Q6IFtFY3JpdF0gSFVNIG9uIFBob25lQkNQDQoNCgkJRHVyaW5nIHRvZGF54oCZcyBtZWV0 aW5nIHRoZXJlIHdhcyBkaXNjdXNzaW9uIGFzIHRvIHdoeSB0aGUgY2hhaXJzIFB1YmxpY2F0aW9u IFJlcXVlc3RlZCBQaG9uZUJDUCB2ZXJzaW9uIDEzIHdoZW4gdGhlcmUgYXJlIHVucmVzb2x2ZWQg aXNzdWVzLiAgVGhpcyBkaXNjdXNzaW9uIGxlZCB1cyB0byBjYWxsIGZvciBhIGh1bS4gIFdlIGFy ZSBub3cgYXNraW5nIHRoZSBzYW1lIHF1ZXN0aW9uIG9uIHRoZSBsaXN0Lg0KCQkNCgkJRG8geW91 IGFncmVlIG9yIGRpc2FncmVlIHRoYXQgUGhvbmVCQ1AgLTEzIGlzIHJlYWR5IHRvIFB1YmxpY2F0 aW9uIFJlcXVlc3Q/DQoJCQ0KCQlQbGVhc2UgcmVzcG9uZCBieSBjbG9zZSBvZiBidXNpbmVzcyBv biBXZWRuZXNkYXkgQXVndXN0IDV0aC4NCgkJDQoJCVRoYW5rcywNCgkJDQoJCU1hcmMgJiBIYW5u ZXMNCg0KCSANCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRo aXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0K Y29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5m b3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55 IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0NCg0KCSANCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBk ZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJv cHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2 ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlh dGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0 aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClttZjJdDQo= ------_=_NextPart_001_01CA10F0.F61482BB Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYg IW1zb10+DQo8c3R5bGU+DQp2XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoq IHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1 bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+ DQo8IVtlbmRpZl0tLT4NCjx0aXRsZT5IVU0gb24gUGhvbmVCQ1A8L3RpdGxlPg0KPHN0eWxlPg0K PCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzI0NDA2MTt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMyNDQwNjE7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3 Mi4wcHQgNzIuMHB0O30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9z dHlsZT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1FTi1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPg0K DQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNv bG9yOiMyNDQwNjEnPlNpbmNlIHRoZXkgd2VyZSB0aGUgc2FtZSBjb25jZXJucywgSSBoYXJkbHkg c2VlIHRoZSBwb2ludCBpbg0Kc3BsaXR0aW5nIGhhaXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+DQoNCjxkaXY+DQoN CjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQoiVGFob21h Iiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gRFJB R0UsIEtlaXRoIChLZWl0aCkNClttYWlsdG86ZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tXSA8YnI+ DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIDMwIEp1bHkgMjAwOSAxMDozMSBBTTxicj4NCjxiPlRv OjwvYj4gVGhvbXNvbiwgTWFydGluOyBNYXJjIExpbnNuZXI7IGVjcml0PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJFOiBbRWNyaXRdIChhc2lkZSkgSFVNIG9uIFBob25lQkNQPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KY29sb3I6Ymx1ZSc+ SXQgZGlzY3Vzc2VkIFN0ZXBoZW5zIGNvbmNlcm5zIG9uIGZyYW1ld29yay48L3NwYW4+PG86cD48 L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KY29sb3I6Ymx1ZSc+SSB3ZW50IGJhY2sgdGhyb3Vn aCBib3RoIG15IG93biBhcmNoaXZlIGFuZCB0aGUgd2ViIGFyY2hpdmUgYW5kDQpmb3VuZCBub3Ro aW5nIGFkZHJlc3NpbmcgcGhvbmUgYmNwIGNvbW1lbnRzIGRpcmVjdGx5Li48L3NwYW4+PG86cD48 L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KY29sb3I6Ymx1ZSc+S2VpdGg8L3NwYW4+PG86cD48 L286cD48L3A+DQoNCjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7DQptYXJnaW4tbGVmdDoz Ljc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4w cHQnPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxkaXYg Y2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxz cGFuIGxhbmc9RU4tVVM+DQoNCjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlcj4N Cg0KPC9zcGFuPjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0 b206MTIuMHB0Jz48Yj48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3Bhbg0K bGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiInPiBUaG9tc29uLA0KTWFydGluIFttYWlsdG86TWFydGluLlRob21zb25AYW5k cmV3LmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDMwLCAyMDA5IDk6MDYg QU08YnI+DQo8Yj5Ubzo8L2I+IERSQUdFLCBLZWl0aCAoS2VpdGgpOyBNYXJjIExpbnNuZXI7IGVj cml0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbRWNyaXRdIChhc2lkZSkgSFVNIG9uIFBob25l QkNQPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMyNDQwNjEnPktlaXRoLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYx Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KY29sb3I6IzI0NDA2MSc+VGhpcyB3b3JraW5nIGdyb3VwIGhhcyBkaXNjdXNzZWQsIGF0 IGdyZWF0IGxlbmd0aCwgU3RlcGhlbuKAmXMNCmNvbmNlcm5zLiZuYnNwOyBJZiBhIHNwZWNpZmlj IGVtYWlsIGhhcyBub3QgaGFkIGFueSByZXNwb25zZSwgdGhhdCBjYW5ub3QgYmUNCnRha2VuIGFz IGFuIGluZGljYXRpb24gb25lIHdheSBvciBvdGhlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMy NDQwNjEnPllvdSBtYXkgY29uc2lkZXIgdGhpcyBodW0gaXMgb24gd2hldGhlciB5b3UgdGhpbmsg dGhvc2UgY29tbWVudHMNCnZhbGlkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+LS1N YXJ0aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KY29sb3I6IzI0NDA2MSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2IHN0 eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNC4wcHQnPg0KDQo8ZGl2Pg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5Og0KIlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcNClttYWlsdG86 ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5EUkFHRSwgS2VpdGgg KEtlaXRoKTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgMzAgSnVseSAyMDA5IDEwOjAxIEFN PGJyPg0KPGI+VG86PC9iPiBNYXJjIExpbnNuZXI7ICdlY3JpdCc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtFY3JpdF0gSFVNIG9uIFBob25lQkNQPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KY29sb3I6Ymx1ZSc+SSBkb24ndCBhZ3Jl ZS48L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KY29sb3I6Ymx1ZSc+U29t ZSBiYWNrZ3JvdW5kLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQpjb2xv cjpibHVlJz5UaGVyZSB3YXMgYSBzZXQgb2YgY29tbWVudHMgcHJvdmlkZWQgYnkgU3RlcGhlbiBF ZGdlIG9uIDV0aA0KRmVicnVhcnkgMjAwOS4gSSBjYW4gZmluZCBubyByZXNwb25zZSB0byB0aGF0 IHNldCBvZiBjb21tZW50cyBvbiB0aGUgbWFpbGluZw0KbGlzdC48L3NwYW4+PG86cD48L286cD48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiOw0KY29sb3I6Ymx1ZSc+VGhlIGdpc3Qgb2YgdGhhdCBzZXQgb2Yg Y29tbWVudHMgd2FzIHRoYXQgcGhvbmViY3AgY2xhaW1zIHRvIGNvdmVyDQphbGwgYWNjZXNzIHRl Y2hub2xvZ2llcyBhbmQgaXQgaWRlbnRpZmllZCBhIHNpZ25pZmljYW50IG51bWJlciBvZiByZXF1 aXJlbWVudHMNCndpdGhpbiBwaG9uZWJjcCB0aGF0IHRoZSBhdXRob3IgY29uc2lkZXJlZCB3ZXJl IG5vdCByZXF1aXJlbWVudHMgb24gM0dQUA0KYWNjZXNzZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOmJsdWUnPlNvIG15IHBvc2l0aW9uIGlzIHRoYXQgdGhl IGRvY3VtZW50IGlzIG5vdCByZWFkeSBiZWNhdXNlIGFsbCB0aGUNCnZhbGlkIGNvbW1lbnRzIG9u IHRoZSBkb2N1bWVudCB3ZXJlIG5vdCBhZGRyZXNzZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjsNCmNvbG9yOmJsdWUnPlRoZXJlIGFyZSB0d28gd2F5cyBvZiBkZWFsaW5n IHdpdGggdGhpcyBzZXQgb2YgY29tbWVudHM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjsNCmNvbG9yOmJsdWUnPi0mbmJzcDsmbmJzcDsmbmJzcDsgZ29pbmcgdGhyb3VnaCBh bmQgbW9kaWZ5aW5nIGFsbCB0aGUgaWRlbnRpZmllZA0KcmVxdWlyZW1lbnRzIHdoZXJlIHRoZSBj b21tZW50IGlzIHVwaGVsZC48L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0K Y29sb3I6Ymx1ZSc+LSZuYnNwOyZuYnNwOyZuYnNwOyBtYWtpbmcgbW9yZSBjbGVhciBpbiB0aGUg YWJzdHJhY3QgYW5kIC8gb3INCmludHJvZHVjdGlvbiB0aGF0IHRoaXMgaXMgc29sZWx5IHRoZSB2 aWV3IG9mIElFVEYgaW4gcmVnYXJkIHRvIElQIGNhcGFibGUNCmRldmljZXMgYW5kIHRoYXQgb3Ro ZXIgb3JnYW5pc2F0aW9ucyBtYXkgc3BlY2lmeSBvdGhlciByZXF1aXJlbWVudHMuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOmJsdWUnPkkgd291bGQgbm90ZSBh dCB0aGlzIHBvaW50IHRoYXQgdGhlIGN1cnJlbnQgYWJzdHJhY3Qgc2F5czo8L3NwYW4+PG86cD48 L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KY29sb3I6Ymx1ZSc+Jm5ic3A7Jm5ic3A7IFRoZSBJ RVRGIGFuZCBvdGhlciBzdGFuZGFyZHMgb3JnYW5pemF0aW9uIGhhdmUgZWZmb3J0cw0KdGFyZ2V0 ZWQgYXQ8L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjsNCmNvbG9yOmJsdWUnPiZuYnNwOyZuYnNwOyBzdGFuZGFyZGl6aW5nIHZhcmlvdXMg YXNwZWN0cyBvZiBwbGFjaW5nIGVtZXJnZW5jeQ0KY2FsbHMgb24gSVA8YnI+DQombmJzcDsmbmJz cDsgbmV0d29ya3MuJm5ic3A7IFRoaXMgbWVtbyBkZXNjcmliZXMgYmVzdCBjdXJyZW50IHByYWN0 aWNlIG9uIGhvdw0KZGV2aWNlcyw8YnI+DQombmJzcDsmbmJzcDsgbmV0d29ya3MgYW5kIHNlcnZp Y2VzIHNob3VsZCB1c2Ugc3VjaCBzdGFuZGFyZHMgdG8gbWFrZSBlbWVyZ2VuY3k8YnI+DQombmJz cDsmbmJzcDsgY2FsbHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiOw0KY29sb3I6Ymx1ZSc+QmVjYXVzZSB0aGUgdHdvIHNlbnRlbmNl cyBmb2xsb3cgZWFjaCBvdGhlciwgaXQgaW1wbGllcyB0aGF0IG90aGVyDQpTRE9zIHRoYXQgaGF2 ZSBlZmZvcnRzIHRhcmdldHRlZCBhdCBhZGRyZXNzaW5nIHRoZXNlIHNvbHV0aW9ucyBhcmUgY29t cGxpY2l0IGluDQp0aGUgcmVxdWlyZW1lbnRzIHNvIHN0YXRlZCwgYW5kIHRoaXMgaXMgdW50cnVl LiBDZXJ0YWlubHkgdGhlIGN1cnJlbnQgc3RhdHVzIG9mDQp0aGlzIGRvY3VtZW50IGFzIGFkZHJl c3NlZCBieSB2YXJpb3VzIGluZm9ybWFsIDNHUFAgZGlzY3Vzc2lvbnMgaXMgdG8gZW5zdXJlDQp0 aGF0IHRoaW5ncyBkbyBub3QgZmFsbCBhcGFydCBpbiBlbnRpdGllcyB1c2luZyB0aGUgM0dQUCBt ZWNoYW5pc21zLCBob3dldmVyDQozR1BQIGRldmljZXMgZG8gbm90IHVzZSB0aGVzZSByZXF1aXJl bWVudHMgKG5vIGRvIHRoZXNlIHJlcXVpcmVtZW50cyByZXByZXNlbnQNCnRoZSAzR1BQIHJlcXVp cmVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQpjb2xvcjpibHVlJz5P bmUgc29sdXRpb24gdG8gdGhlIGlzc3VlIHdvdWxkIGp1c3QgYmUgdG8gbWFrZSBtdWNoIGNsZWFy ZXIgd2hpY2gNClNET3MgaGF2ZSBwYXJ0aWNpcGF0ZWQgaW4gdGhpcyB3b3JrIGFuZCB3aGljaCBo YXZlIG5vdCBhbmQgdGhlIHN0YXR1cyBvZiB0aGF0DQpwcm9ncmVzcyAtIGhvd2V2ZXIgdGhhdCB3 YXMgYWxzbyB3aGF0IHBlb3BsZSBrZWVwIGNhbGxpbmcgdGhlDQomcXVvdDthcHBsaWNhYmlsaXR5 IHN0YXRlbWVudCZxdW90OyB3YXMgdHJ5aW5nIHRvIGRvLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7DQpjb2xvcjpibHVlJz5yZWdhcmRzPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOmJsdWUnPktlaXRoPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPGJsb2NrcXVvdGUgc3R5bGU9J2Jv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBj bSA0LjBwdDsNCm1hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCc+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxl PSd0ZXh0LWFsaWduOmNlbnRlcic+PHNwYW4gbGFuZz1FTi1VUz4NCg0KPGhyIHNpemU9MiB3aWR0 aD0iMTAwJSIgYWxpZ249Y2VudGVyPg0KDQo8L3NwYW4+PC9kaXY+DQoNCjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxiPjxzcGFuIGxhbmc9RU4tVVMNCnN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuDQpsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+DQplY3JpdC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5N YXJjDQpMaW5zbmVyPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSnVseSAyOSwgMjAwOSAy OjUzIFBNPGJyPg0KPGI+VG86PC9iPiAnZWNyaXQnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFY3Jp dF0gSFVNIG9uIFBob25lQkNQPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+RHVyaW5nDQp0b2RheeKAmXMg bWVldGluZyB0aGVyZSB3YXMgZGlzY3Vzc2lvbiBhcyB0byB3aHkgdGhlIGNoYWlycyBQdWJsaWNh dGlvbiBSZXF1ZXN0ZWQNClBob25lQkNQIHZlcnNpb24gMTMgd2hlbiB0aGVyZSBhcmUgdW5yZXNv bHZlZCBpc3N1ZXMuICZuYnNwO1RoaXMgZGlzY3Vzc2lvbiBsZWQNCnVzIHRvIGNhbGwgZm9yIGEg aHVtLiAmbmJzcDtXZSBhcmUgbm93IGFza2luZyB0aGUgc2FtZSBxdWVzdGlvbiBvbiB0aGUgbGlz dC48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0nY29sb3I6IzEyMTIxMic+RG8geW91IGFncmVlIG9y IGRpc2FncmVlIHRoYXQgUGhvbmVCQ1AgLTEzIGlzIHJlYWR5DQp0byBQdWJsaWNhdGlvbiBSZXF1 ZXN0Pzxicj4NCjxicj4NClBsZWFzZSByZXNwb25kIGJ5IGNsb3NlIG9mIGJ1c2luZXNzIG9uIFdl ZG5lc2RheSBBdWd1c3QgNXRoLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQo8YnI+DQpNYXJjICZh bXA7IEhhbm5lczxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQoNCjwvYmxvY2txdW90ZT4N Cg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4w cHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8dGFibGUgY2xhc3M9TXNvTm9ybWFsVGFibGUg Ym9yZGVyPTAgY2VsbHBhZGRpbmc9MCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+DQogPHRyPg0K ICA8dGQgc3R5bGU9J3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQnPg0KICA8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48YnI+DQogIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiAgVGhpcyZuYnNwO21lc3NhZ2UmbmJz cDtpcyZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO2Rlc2lnbmF0ZWQmbmJzcDtyZWNpcGllbnQmbmJz cDtvbmx5Jm5ic3A7YW5kJm5ic3A7bWF5PGJyPg0KICBjb250YWluJm5ic3A7cHJpdmlsZWdlZCwm bmJzcDtwcm9wcmlldGFyeSwmbmJzcDtvciZuYnNwO290aGVyd2lzZSZuYnNwO3ByaXZhdGUmbmJz cDtpbmZvcm1hdGlvbi4mbmJzcDsmbmJzcDs8YnI+DQogIElmJm5ic3A7eW91Jm5ic3A7aGF2ZSZu YnNwO3JlY2VpdmVkJm5ic3A7aXQmbmJzcDtpbiZuYnNwO2Vycm9yLCZuYnNwO3BsZWFzZSZuYnNw O25vdGlmeSZuYnNwO3RoZSZuYnNwO3NlbmRlcjxicj4NCiAgaW1tZWRpYXRlbHkmbmJzcDthbmQm bmJzcDtkZWxldGUmbmJzcDt0aGUmbmJzcDtvcmlnaW5hbC4mbmJzcDsmbmJzcDtBbnkmbmJzcDt1 bmF1dGhvcml6ZWQmbmJzcDt1c2UmbmJzcDtvZjxicj4NCiAgdGhpcyZuYnNwO2VtYWlsJm5ic3A7 aXMmbmJzcDtwcm9oaWJpdGVkLjxicj4NCiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KICBbbWYyXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCiAgPC90ZD4NCiA8 L3RyPg0KPC90YWJsZT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KDQo8L2Jsb2NrcXVvdGU+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGJyPjxicj48dGFibGUg Ymdjb2xvcj13aGl0ZSBzdHlsZT0iY29sb3I6YmxhY2siPjx0cj48dGQ+PGJyPi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7 aXMmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDtkZXNpZ25hdGVkJm5ic3A7cmVjaXBpZW50Jm5ic3A7 b25seSZuYnNwO2FuZCZuYnNwO21heTxicj4NCmNvbnRhaW4mbmJzcDtwcml2aWxlZ2VkLCZuYnNw O3Byb3ByaWV0YXJ5LCZuYnNwO29yJm5ic3A7b3RoZXJ3aXNlJm5ic3A7cHJpdmF0ZSZuYnNwO2lu Zm9ybWF0aW9uLiZuYnNwOyZuYnNwOzxicj4NCklmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3Jl Y2VpdmVkJm5ic3A7aXQmbmJzcDtpbiZuYnNwO2Vycm9yLCZuYnNwO3BsZWFzZSZuYnNwO25vdGlm eSZuYnNwO3RoZSZuYnNwO3NlbmRlcjxicj4NCmltbWVkaWF0ZWx5Jm5ic3A7YW5kJm5ic3A7ZGVs ZXRlJm5ic3A7dGhlJm5ic3A7b3JpZ2luYWwuJm5ic3A7Jm5ic3A7QW55Jm5ic3A7dW5hdXRob3Jp emVkJm5ic3A7dXNlJm5ic3A7b2Y8YnI+DQp0aGlzJm5ic3A7ZW1haWwmbmJzcDtpcyZuYnNwO3By b2hpYml0ZWQuPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJy Pg0KW21mMl08L3RkPjwvdHI+PC90YWJsZT48L2JvZHk+DQoNCjwvaHRtbD4NCg== ------_=_NextPart_001_01CA10F0.F61482BB-- From Gabor.Bajko@nokia.com Thu Jul 30 01:38:17 2009 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 4564928C1D2 for ; Thu, 30 Jul 2009 01:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.033 X-Spam-Level: X-Spam-Status: No, score=-6.033 tagged_above=-999 required=5 tests=[AWL=0.565, 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 WMoyEaDLVWex for ; Thu, 30 Jul 2009 01:38:11 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 46ADC28C17D for ; Thu, 30 Jul 2009 01:38:11 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6U8bKdV026194; Thu, 30 Jul 2009 03:37:56 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 11:37:43 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 11:37:38 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 30 Jul 2009 10:37:38 +0200 From: To: , , Date: Thu, 30 Jul 2009 10:37:39 +0200 Thread-Topic: HUM on PhoneBCP Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAACRpzZA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A99B171D26E1564B92D36826128CD6613A6F8C670CNOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jul 2009 08:37:38.0989 (UTC) FILETIME=[FF005DD0:01CA10F0] X-Nokia-AV: Clean Subject: Re: [Ecrit] HUM on 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: Thu, 30 Jul 2009 08:38:17 -0000 --_000_A99B171D26E1564B92D36826128CD6613A6F8C670CNOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't agree either. My comments were also not addressed (ie ignored). - Gabor ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of e= xt DRAGE, Keith (Keith) Sent: Thursday, July 30, 2009 1:01 AM To: Marc Linsner; 'ecrit' Subject: Re: [Ecrit] HUM on PhoneBCP I don't agree. Some background. There was a set of comments provided by Stephen Edge on 5th February 2009. = I can find no response to that set of comments on the mailing list. The gist of that set of comments was that phonebcp claims to cover all acce= ss technologies and it identified a significant number of requirements with= in phonebcp that the author considered were not requirements on 3GPP access= es. So my position is that the document is not ready because all the valid comm= ents on the document were not addressed. There are two ways of dealing with this set of comments: - going through and modifying all the identified requirements where the = comment is upheld. - making more clear in the abstract and / or introduction that this is s= olely the view of IETF in regard to IP capable devices and that other organ= isations may specify other requirements. I would note at this point that the current abstract says: 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. Because the two sentences follow each other, it implies that other SDOs tha= t have efforts targetted at addressing these solutions are complicit in the= requirements so stated, and this is untrue. Certainly the current status o= f this document as addressed by various informal 3GPP discussions is to ens= ure that things do not fall apart in entities using the 3GPP mechanisms, ho= wever 3GPP devices do not use these requirements (no do these requirements = represent the 3GPP requires. One solution to the issue would just be to make much clearer which SDOs hav= e participated in this work and which have not and the status of that progr= ess - however that was also what people keep calling the "applicability sta= tement" was trying to do. regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of M= arc Linsner Sent: Wednesday, July 29, 2009 2:53 PM To: 'ecrit' Subject: [Ecrit] HUM on PhoneBCP During today's meeting there was discussion as to why the chairs Publicatio= n Requested PhoneBCP version 13 when there are unresolved issues. This dis= cussion led us to call for a hum. We are now asking the same question on t= he list. Do you agree or disagree that PhoneBCP -13 is ready to Publication Request? Please respond by close of business on Wednesday August 5th. Thanks, Marc & Hannes --_000_A99B171D26E1564B92D36826128CD6613A6F8C670CNOKEUMSG01mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HUM on PhoneBCP
I don't agree either. My comments were also not ad= dressed=20 (ie ignored).
 
- Gabor

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of ext DRAGE, Keith=20 (Keith)
Sent: Thursday, July 30, 2009 1:01 AM
To: Mar= c=20 Linsner; 'ecrit'
Subject: Re: [Ecrit] HUM on=20 PhoneBCP

I don't agree.
 
Some background.
 
There was a set of comments provided by Stephen = Edge on=20 5th February 2009. I can find no response to that set of comments on the= =20 mailing list.
 
The gist of that set of comments was that phoneb= cp claims=20 to cover all access technologies and it identified a significant number o= f=20 requirements within phonebcp that the author considered were not requirem= ents=20 on 3GPP accesses.
 
So my position is that the document is not ready= because=20 all the valid comments on the document were not addressed.<= /DIV>
 
There are two ways of dealing with this set of=20 comments:
 
-    going through and modifying = all the=20 identified requirements where the comment is upheld.
 
-    making more clear in the abs= tract and=20 / or introduction that this is solely the view of IETF in regard to IP ca= pable=20 devices and that other organisations may specify other=20 requirements.
 
I would note at this point that the current abst= ract=20 says:
 
   The IETF and other standards organi= zation=20 have efforts targeted at
   standardizing various aspects of placing emergency = calls=20 on IP
   networks.  This memo describes best current=20 practice on how devices,
   networks and services should use= such=20 standards to make emergency
   calls.
Because the two sentences follow each other, it = implies=20 that other SDOs that have efforts targetted at addressing these solutions= are=20 complicit in the requirements so stated, and this is untrue. Certainly th= e=20 current status of this document as addressed by various informal 3GPP=20 discussions is to ensure that things do not fall apart in entities using = the=20 3GPP mechanisms, however 3GPP devices do not use these requirements (no d= o=20 these requirements represent the 3GPP requires.
 
One solution to the issue would just be to make = much=20 clearer which SDOs have participated in this work and which have not and = the=20 status of that progress - however that was also what people keep calling = the=20 "applicability statement" was trying to do.
 
regards
 
Keith
 
 

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc=20 Linsner
Sent: Wednesday, July 29, 2009 2:53 PM
To:= =20 'ecrit'
Subject: [Ecrit] HUM on PhoneBCP

During today’s meeting there was discus= sion as to=20 why the chairs Publication Requested PhoneBCP version 13 when there are= =20 unresolved issues.  This discussion led us to call for a hum. &nbs= p;We=20 are now asking the same question on the list.

Do=20 you agree or disagree that PhoneBCP -13 is ready to Publication=20 Request?

Please respond by close of business on Wednesday August= =20 5th.

Thanks,

Marc &=20 Hannes
--_000_A99B171D26E1564B92D36826128CD6613A6F8C670CNOKEUMSG01mgd_-- From Martin.Dawson@andrew.com Thu Jul 30 01:42:48 2009 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 AD33A28C1E0 for ; Thu, 30 Jul 2009 01:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YI2vS0c-DnKI for ; Thu, 30 Jul 2009 01:42:42 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id C754428C1C9 for ; Thu, 30 Jul 2009 01:42:41 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_30_04_05_14 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 30 Jul 2009 04:05:09 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 03:42:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA10F1.B00244D8" Date: Thu, 30 Jul 2009 03:42:34 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAACSJnfA= References: From: "Dawson, Martin" To: "DRAGE, Keith (Keith)" , "Marc Linsner" , "ecrit" X-OriginalArrivalTime: 30 Jul 2009 08:42:36.0759 (UTC) FILETIME=[B07C7670:01CA10F1] Subject: Re: [Ecrit] HUM on 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: Thu, 30 Jul 2009 08:42:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA10F1.B00244D8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > There are two ways of dealing with this set of comments:=0D=0A=0D=0A>=20=0D= =0A=0D=0A> - going through and modifying all the identified requirements= where=0D=0Athe comment is upheld.=0D=0A=0D=0A>=20=0D=0A=0D=0A> - making= more clear in the abstract and / or introduction that this=0D=0Ais solely = the view of IETF in regard to IP capable devices and that=0D=0Aother organi= sations may specify > other requirements.=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D= =0AThere's a third way. This hum actually includes the judgement on whether=0D= =0AStephen's comments are valid. If the "hummer" considers the document is=0D= =0Aready for publication then the inference is that they judge them not to=0D= =0Abe. Works in my case.=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMarti= n=0D=0A=0D=0A=20=0D=0A=0D=0A________________________________=0D=0A=0D=0AFro= m: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0AOf= DRAGE, Keith (Keith)=0D=0ASent: Thursday, 30 July 2009 6:01 PM=0D=0ATo: Ma= rc Linsner; 'ecrit'=0D=0ASubject: Re: [Ecrit] HUM on PhoneBCP=0D=0A=0D=0A =0D= =0A=0D=0AI don't agree.=0D=0A=0D=0A=20=0D=0A=0D=0ASome background.=0D=0A=0D= =0A=20=0D=0A=0D=0AThere was a set of comments provided by Stephen Edge on 5= th February=0D=0A2009. I can find no response to that set of comments on th= e mailing=0D=0Alist.=0D=0A=0D=0A=20=0D=0A=0D=0AThe gist of that set of comm= ents was that phonebcp claims to cover all=0D=0Aaccess technologies and it = identified a significant number of=0D=0Arequirements within phonebcp that t= he author considered were not=0D=0Arequirements on 3GPP accesses.=0D=0A=0D=0A= =20=0D=0A=0D=0ASo my position is that the document is not ready because all= the valid=0D=0Acomments on the document were not addressed.=0D=0A=0D=0A =0D= =0A=0D=0AThere are two ways of dealing with this set of comments:=0D=0A=0D=0A= =20=0D=0A=0D=0A- going through and modifying all the identified requirem= ents where=0D=0Athe comment is upheld.=0D=0A=0D=0A=20=0D=0A=0D=0A- makin= g more clear in the abstract and / or introduction that this=0D=0Ais solely= the view of IETF in regard to IP capable devices and that=0D=0Aother organ= isations may specify other requirements.=0D=0A=0D=0A=20=0D=0A=0D=0AI would = note at this point that the current abstract says:=0D=0A=0D=0A=20=0D=0A=0D=0A= The IETF and other standards organization have efforts targeted at=0D=0A=0D= =0A standardizing various aspects of placing emergency calls on IP=0D=0A = networks. This memo describes best current practice on how devices,=0D=0A= networks and services should use such standards to make emergency=0D=0A = calls.=0D=0A=0D=0ABecause the two sentences follow each other, it implies= that other SDOs=0D=0Athat have efforts targetted at addressing these solut= ions are complicit=0D=0Ain the requirements so stated, and this is untrue. = Certainly the current=0D=0Astatus of this document as addressed by various = informal 3GPP=0D=0Adiscussions is to ensure that things do not fall apart i= n entities using=0D=0Athe 3GPP mechanisms, however 3GPP devices do not use = these requirements=0D=0A(no do these requirements represent the 3GPP requir= es.=0D=0A=0D=0A=20=0D=0A=0D=0AOne solution to the issue would just be to ma= ke much clearer which SDOs=0D=0Ahave participated in this work and which ha= ve not and the status of that=0D=0Aprogress - however that was also what pe= ople keep calling the=0D=0A"applicability statement" was trying to do.=0D=0A=0D= =0A=20=0D=0A=0D=0Aregards=0D=0A=0D=0A=20=0D=0A=0D=0AKeith=0D=0A=0D=0A=20=0D= =0A=0D=0A=20=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09=0D=0A________________________= ________=0D=0A=0D=0A=0D=0A=09From: ecrit-bounces@ietf.org [mailto:ecrit-bou= nces@ietf.org] On=0D=0ABehalf Of Marc Linsner=0D=0A=09Sent: Wednesday, July= 29, 2009 2:53 PM=0D=0A=09To: 'ecrit'=0D=0A=09Subject: [Ecrit] HUM on Phone= BCP=0D=0A=0D=0A=09During today's meeting there was discussion as to why the= chairs=0D=0APublication Requested PhoneBCP version 13 when there are unres= olved=0D=0Aissues. This discussion led us to call for a hum. We are now a= sking=0D=0Athe same question on the list.=0D=0A=09=0D=0A=09Do you agree or = disagree that PhoneBCP -13 is ready to=0D=0APublication Request=3F=0D=0A=09=0D= =0A=09Please respond by close of business on Wednesday August 5th.=0D=0A=09=0D= =0A=09Thanks,=0D=0A=09=0D=0A=09Marc & Hannes=0D=0A=0D=0A-------------------= ---------------------------------------------------------------------------= --=0D=0AThis message is for the designated recipient only and may=0D=0Acont= ain privileged, proprietary, or otherwise private information. =20=0D=0AIf = you have received it in error, please notify the sender=0D=0Aimmediately an= d delete the original. Any unauthorized use of=0D=0Athis email is prohibit= ed.=0D=0A------------------------------------------------------------------= ------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01CA10F1.B00244D8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =0D=0A= HUM on PhoneBCP=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A

> There are two ways of dealing with=0D=0Athis set of comments:

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

> 

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

> -    g= oing through and=0D=0Amodifying all the identified requirements where the c= omment is upheld.

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

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

= > -&= nbsp;   making more clear=0D=0Ain the abstract and / or introduct= ion that this is solely the view of IETF in=0D=0Aregard to IP capable devic= es and that other organisations may specify > other=0D=0Arequirements.

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

 

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

 =

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

Ther= e’s a third way. This hum actually=0D=0Aincludes the judgement on whe= ther Stephen’s comments are valid. If the “hummer”=0D=0Ac= onsiders the document is ready for publication then the inference is that t= hey=0D=0Ajudge them not to be. Works in my case.=0D=0A=0D=0A

&= nbsp;

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

Cheers,

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

Martin

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

<= o:p> 

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

From:=0D=0Aecr= it-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith)
=0D=0A= Sent: Thursday, 30 July 2009 6:= 01=0D=0APM
=0D=0ATo: Marc= Linsner; 'ecrit'
=0D=0ASubject: Re: [Ecrit] HUM on=0D=0APhoneBCP

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

=  

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

I don't agree.

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

 

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

Some background.

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

 

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

There was a set of comments provided by=0D=0AStephen Edge on 5th= February 2009. I can find no response to that set of=0D=0Acomments on the = mailing list.

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

=  

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

The gist of that set of comments was that=0D= =0Aphonebcp claims to cover all access technologies and it identified a=0D=0A= significant number of requirements within phonebcp that the author consider= ed=0D=0Awere not requirements on 3GPP accesses.=0D=0A=0D=0A

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

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

So my posit= ion is that the document is not=0D=0Aready because all the valid comments o= n the document were not addressed.

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

 

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

There are two ways of d= ealing with this=0D=0Aset of comments:

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

 

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

-    g= oing through and=0D=0Amodifying all the identified requirements where the c= omment is upheld.

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

 

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

-    making more clear = in=0D=0Athe abstract and / or introduction that this is solely the view of = IETF in=0D=0Aregard to IP capable devices and that other organisations may = specify other=0D=0Arequirements.

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

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

I would note at this poin= t that the=0D=0Acurrent abstract says:

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

 

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

   The IETF= and other standards=0D=0Aorganization have efforts targeted at

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

   standardizing various aspects=0D=0Ao= f placing emergency calls on IP
=0D=0A   networks.  This = memo describes best current practice on how=0D=0Adevices,
=0D=0A &n= bsp; networks and services should use such standards to make emergency
=0D= =0A   calls.

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

Because the two s= entences follow each=0D=0Aother, it implies that other SDOs that have effor= ts targetted at addressing=0D=0Athese solutions are complicit in the requir= ements so stated, and this is=0D=0Auntrue. Certainly the current status of = this document as addressed by various=0D=0Ainformal 3GPP discussions is to = ensure that things do not fall apart in=0D=0Aentities using the 3GPP mechan= isms, however 3GPP devices do not use these=0D=0Arequirements (no do these = requirements represent the 3GPP requires.

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

 

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

One solution to the i= ssue would just be to=0D=0Amake much clearer which SDOs have participated i= n this work and which have not=0D=0Aand the status of that progress - howev= er that was also what people keep=0D=0Acalling the "applicability stat= ement" was trying to do.

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

 

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

regards

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

 

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

Kei= th

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

 

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

 <= /o:p>

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

 

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

From:=0D=0Aecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf Of Marc Lin= sner
=0D=0ASent: Wednesda= y, July 29, 2009=0D=0A2:53 PM
=0D=0A= To: 'ecrit'
=0D=0ASubject= : [Ecrit] HUM on PhoneBCP<= o:p>

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

During t= oday’s meeting there was discussion as to why the=0D=0Achairs Publica= tion Requested PhoneBCP version 13 when there are unresolved=0D=0Aissues. &= nbsp;This discussion led us to call for a hum.  We are now asking=0D=0A= the same question on the list.
=0D=0A
=0D=0A<= span style=3D'color:#121212'>Do you agree or disagree that=0D=0APhoneBCP -1= 3 is ready to Publication Request=3F
=0D=0A
=0D=0APlease respond by c= lose of business on Wednesday August 5th.
=0D=0A
=0D=0AThanks,
=0D= =0A
=0D=0AMarc & Hannes

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


-----------------------------------= -------------------------------------------------------------
=0D=0AThis=  message is for the designated recipient = ;only and may
=0D=0Acontain privileged, proprietary,=  or otherwise private information.  
=0D=0A= If you have received it in error, please=  notify the sender
=0D=0Aimmediately and delete=  the original.  Any unauthorized use of<= br>=0D=0Athis email is prohibited.
=0D=0A----------------= ---------------------------------------------------------------------------= -----
=0D=0A[mf2]
=0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01CA10F1.B00244D8-- From rbarnes@bbn.com Thu Jul 30 01:48:00 2009 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 9A27A28C1F1 for ; Thu, 30 Jul 2009 01:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 CHjZPuvdZaVI for ; Thu, 30 Jul 2009 01:47:59 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 889143A6C0F for ; Thu, 30 Jul 2009 01:47:59 -0700 (PDT) Received: from [128.89.254.55] (helo=dhcp-14e6.meeting.ietf.org) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1MWRIr-0002Tp-9m; Thu, 30 Jul 2009 04:47:57 -0400 Message-ID: <4A715E3B.3060508@bbn.com> Date: Thu, 30 Jul 2009 10:47:55 +0200 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: ecrit , "Thomson, Martin" Subject: Re: [Ecrit] (aside) HUM on 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: Thu, 30 Jul 2009 08:48:00 -0000 Martin is correct. The two emails [1][2] are nearly identical, so the thread on framework clearly addresses Stephen's concerns about phonebcp. --Richard [1] [2] DRAGE, Keith (Keith) wrote: > It discussed Stephens concerns on framework. > > I went back through both my own archive and the web archive and found nothing addressing phone bcp comments directly.. > > Keith > > ________________________________ > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Thursday, July 30, 2009 9:06 AM > To: DRAGE, Keith (Keith); Marc Linsner; ecrit > Subject: RE: [Ecrit] (aside) HUM on PhoneBCP > > Keith, > > This working group has discussed, at great length, Stephen’s concerns. If a specific email has not had any response, that cannot be taken as an indication one way or other. > > You may consider this hum is on whether you think those comments valid. > > --Martin > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) > Sent: Thursday, 30 July 2009 10:01 AM > To: Marc Linsner; 'ecrit' > Subject: Re: [Ecrit] HUM on PhoneBCP > > I don't agree. > > Some background. > > There was a set of comments provided by Stephen Edge on 5th February 2009. I can find no response to that set of comments on the mailing list. > > The gist of that set of comments was that phonebcp claims to cover all access technologies and it identified a significant number of requirements within phonebcp that the author considered were not requirements on 3GPP accesses. > > So my position is that the document is not ready because all the valid comments on the document were not addressed. > > There are two ways of dealing with this set of comments: > > - going through and modifying all the identified requirements where the comment is upheld. > > - making more clear in the abstract and / or introduction that this is solely the view of IETF in regard to IP capable devices and that other organisations may specify other requirements. > > I would note at this point that the current abstract says: > > 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. > Because the two sentences follow each other, it implies that other SDOs that have efforts targetted at addressing these solutions are complicit in the requirements so stated, and this is untrue. Certainly the current status of this document as addressed by various informal 3GPP discussions is to ensure that things do not fall apart in entities using the 3GPP mechanisms, however 3GPP devices do not use these requirements (no do these requirements represent the 3GPP requires. > > One solution to the issue would just be to make much clearer which SDOs have participated in this work and which have not and the status of that progress - however that was also what people keep calling the "applicability statement" was trying to do. > > regards > > Keith > > > > ________________________________ > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner > Sent: Wednesday, July 29, 2009 2:53 PM > To: 'ecrit' > Subject: [Ecrit] HUM on PhoneBCP > During today’s meeting there was discussion as to why the chairs Publication Requested PhoneBCP version 13 when there are unresolved issues. This discussion led us to call for a hum. We are now asking the same question on the list. > > Do you agree or disagree that PhoneBCP -13 is ready to Publication Request? > > Please respond by close of business on Wednesday August 5th. > > Thanks, > > Marc & Hannes > > > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From robinsg@huawei.com Thu Jul 30 01:54:39 2009 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 4D13D3A7195 for ; Thu, 30 Jul 2009 01:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C76u6i843mkU for ; Thu, 30 Jul 2009 01:54:38 -0700 (PDT) Received: from customer-relay.songnetworks.se (customer-relay.songnetworks.se [195.42.210.9]) by core3.amsl.com (Postfix) with ESMTP id 837CC3A7199 for ; Thu, 30 Jul 2009 01:53:51 -0700 (PDT) Received: from [10.59.1.165] (95.78.227.87.static.s-cy.siw.siwnet.net [87.227.78.95]) by customer-relay.songnetworks.se (Postfix) with ESMTP id B9796242D0; Thu, 30 Jul 2009 10:53:51 +0200 (CEST) Message-ID: <4A715F94.3040406@huawei.com> Date: Thu, 30 Jul 2009 10:53:40 +0200 From: Robins George User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: "Thomson, Martin" References: <4A608144.7090107@bbn.com> <4A60DF3C.2050401@bbn.com> <4A714774.3070505@huawei.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ECRIT Subject: Re: [Ecrit] New ID creating Geocoding URN 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, 30 Jul 2009 08:54:39 -0000 Hi Martin, > Hi Robins, > > We discussed this in the meeting and came to the conclusion that your geocoding draft might be a more appropriate means of actually making the geocoding request. Brian suggested that the scope might be extended to include a more general "PIDF-LO transformation" - something that is apparently necessary in the 'states for translating between emergency-useful civic location and postal-useful civic location for instance. I'm certainly interested in seeing that work progress. > > I do understand Brian's concern to include presence information and I'll work on it to produce a revision of this draft. > However, use of LoST in _discovering_ a server that is capable of providing this service was still a useful thing. > > I agree. --Robins [Apologies for not attending the face-to-face discussion, I was in another meeting] > --Martin > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Robins George >> Sent: Thursday, 30 July 2009 9:11 AM >> To: James M. Polk >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] New ID creating Geocoding URN >> >> James, >> >> HELD extension would be a better choice for Geocoding and >> Reverse-Geocoding. More over address translation is useful in many >> cases >> other than emergency services, where LoST is not required. >> >> >> On 7/18/2009 1:06 AM, James M. Polk wrote: >> >>> At 03:29 PM 7/17/2009, Richard Barnes wrote: >>> >>>> Hey James, >>>> >>>> >>>>>> I'm a little puzzled as to why you would want to use LoST for >>>>>> [reverse] geocoding ... >>>>>> >>>>> It seems to me that LoST servers will not be that overloaded >>>>> >> (though >> >>>>> I could be underestimating), >>>>> >>>> There's nothing preventing these servers from offering a different >>>> interface. Heck, both LoST and HELD are HTTP-based, so it'll >>>> probably just be another servlet / script / etc. >>>> >>> fair comment - but this is a draw IMO >>> >>> >>> >>>>>> For just trading civic vs. geodetic information, it would seem >>>>>> >> much >> >>>>>> more appropriate to use HELD as a baseline, as in >>>>>> >>>>> >> translation-01> >> >>>>>> >>>>> I'm not sure HELD will be in every device, which would be required >>>>> for/by this ID, correct? >>>>> >>>> Last I read phonebcp, HELD and DHCP were required in the same >>>> >> places. >> >>> true - but since devices are made by vendors, they will choose to >>> implement what they want to implement (and I'm not just talking about >>> Cisco), regardless of what a spec says. The all mighty RFP is >>> >> mightier >> >>> than the RFC (regrettably) ;-) >>> >>> >>> >>>> Moreover, geocoding is useful in many cases outside of emergency >>>> services, so devices that aren't capable of emergency calling might >>>> still want to do it. >>>> >>> ok - to that I'd say that LoST is definitely more useful than just >>> >> for >> >>> emergency calling too. The ECRIT WG reached consensus that LoST and >>> the service URNs are to be extended in ECRIT even if the particular >>> service has nothing to do with emergency calling. There was a lively >>> and open debate about this in Vancouver. >>> >>> I'd further say that applications that likely are intelligent enough >>> to know the difference between the two formats will be more >>> intelligent than a palette, thus making them (probably) more often >>> than not able to signal an emergency - even if the likely won't in >>> their lifetime. >>> >>> Smart phones is a good example of this. Not-so-smart phones probably >>> will also have LoST in them, so coding the new URN seems like a >>> no-brainer to me. >>> >>> >>>> These devices >>>> >>> which devices? boxes, palettes or phones? >>> >>> >>>> won't necessarily have LoST libraries, so there's no inherent >>>> advantage there to using LoST. >>>> >>> I believe the latter of the list above will, and will probably be the >>> type of devices that knows enough to do the geocoding transaction. >>> >> I'm >> >>> not thinking palettes or boxes will have the choice of more than one >>> location format, much less know to ask for another one. >>> >>> My draft is targeted at devices that have applications that are smart >>> enough to know there is a difference and to ask for the more >>> >> preferred >> >>> format if they only receive a format that know isn't what they >>> >> prefer. >> >>> James >>> >>> >>> >>>> --Richard >>>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > ------------------------------------------------------------------------------------------------ > 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] > From br@brianrosen.net Thu Jul 30 01:56:40 2009 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 CED493A71B8 for ; Thu, 30 Jul 2009 01:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.021, 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 qhhkJA151Fig for ; Thu, 30 Jul 2009 01:56:34 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 210B63A718A for ; Thu, 30 Jul 2009 01:56:34 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MWRR7-0000X1-EF; Thu, 30 Jul 2009 03:56:30 -0500 From: "Brian Rosen" To: , , , References: In-Reply-To: Date: Thu, 30 Jul 2009 04:56:27 -0400 Message-ID: <005501ca10f3$a284a5e0$e78df1a0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0056_01CA10D2.1B754FD0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAACRpzZAAAHztgA== Content-Language: en-us 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] HUM on 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: Thu, 30 Jul 2009 08:56:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0056_01CA10D2.1B754FD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I went back and looked at your comments. There was one on the list of LCPs. That was discussed extensively, and the current statements in the document reflect the consensus of the work group. The other was a suggestion to change the document to "requirements" from BCP. I responded to you that I was not opposed if it resolved the issues. No one else spoke in favor of the change, and it was dropped. I don't think that constitutes "ignored". Brian From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Thursday, July 30, 2009 4:38 AM To: drage@alcatel-lucent.com; mlinsner@cisco.com; ecrit@ietf.org Subject: Re: [Ecrit] HUM on PhoneBCP I don't agree either. My comments were also not addressed (ie ignored). - Gabor _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of ext DRAGE, Keith (Keith) Sent: Thursday, July 30, 2009 1:01 AM To: Marc Linsner; 'ecrit' Subject: Re: [Ecrit] HUM on PhoneBCP I don't agree. Some background. There was a set of comments provided by Stephen Edge on 5th February 2009. I can find no response to that set of comments on the mailing list. The gist of that set of comments was that phonebcp claims to cover all access technologies and it identified a significant number of requirements within phonebcp that the author considered were not requirements on 3GPP accesses. So my position is that the document is not ready because all the valid comments on the document were not addressed. There are two ways of dealing with this set of comments: - going through and modifying all the identified requirements where the comment is upheld. - making more clear in the abstract and / or introduction that this is solely the view of IETF in regard to IP capable devices and that other organisations may specify other requirements. I would note at this point that the current abstract says: 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. Because the two sentences follow each other, it implies that other SDOs that have efforts targetted at addressing these solutions are complicit in the requirements so stated, and this is untrue. Certainly the current status of this document as addressed by various informal 3GPP discussions is to ensure that things do not fall apart in entities using the 3GPP mechanisms, however 3GPP devices do not use these requirements (no do these requirements represent the 3GPP requires. One solution to the issue would just be to make much clearer which SDOs have participated in this work and which have not and the status of that progress - however that was also what people keep calling the "applicability statement" was trying to do. regards Keith _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Wednesday, July 29, 2009 2:53 PM To: 'ecrit' Subject: [Ecrit] HUM on PhoneBCP During today's meeting there was discussion as to why the chairs Publication Requested PhoneBCP version 13 when there are unresolved issues. This discussion led us to call for a hum. We are now asking the same question on the list. Do you agree or disagree that PhoneBCP -13 is ready to Publication Request? Please respond by close of business on Wednesday August 5th. Thanks, Marc & Hannes ------=_NextPart_000_0056_01CA10D2.1B754FD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HUM on PhoneBCP

I went back and looked at your = comments.

 

There was one on the list of LCPs.  That was = discussed extensively, and the current statements in the document reflect the consensus of the = work group.

 

The other was a suggestion to change the document to = “requirements” from BCP.

 

I responded to you that I was not opposed if it resolved = the issues.  No one else spoke in favor of the change, and it was dropped.  I don’t think that constitutes = “ignored”.

 

Brian

 

From:= = ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of = Gabor.Bajko@nokia.com
Sent: Thursday, July 30, 2009 4:38 AM
To: drage@alcatel-lucent.com; mlinsner@cisco.com; = ecrit@ietf.org
Subject: Re: [Ecrit] HUM on PhoneBCP

 

I don't agree either. My comments were also not addressed = (ie ignored).

 

- Gabor

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of ext DRAGE, Keith = (Keith)
Sent: Thursday, July 30, 2009 1:01 AM
To: Marc Linsner; 'ecrit'
Subject: Re: [Ecrit] HUM on PhoneBCP

I don't agree.

 

Some background.

 

There was a set of comments provided by Stephen Edge on 5th February 2009. I can find no response to that set of comments on the = mailing list.

 

The gist of that set of comments was that phonebcp claims to = cover all access technologies and it identified a significant number of = requirements within phonebcp that the author considered were not requirements on 3GPP accesses.

 

So my position is that the document is not ready because all = the valid comments on the document were not addressed.

 

There are two ways of dealing with this set of = comments:

 

-    going through and modifying all the = identified requirements where the comment is upheld.

 

-    making more clear in the abstract and / = or introduction that this is solely the view of IETF in regard to IP = capable devices and that other organisations may specify other = requirements.

 

I would note at this point that the current abstract = says:

 

   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.

Because the two sentences follow each other, it implies that = other SDOs that have efforts targetted at addressing these solutions are = complicit in the requirements so stated, and this is untrue. Certainly the current = status of this document as addressed by various informal 3GPP discussions is to = ensure that things do not fall apart in entities using the 3GPP mechanisms, = however 3GPP devices do not use these requirements (no do these requirements = represent the 3GPP requires.

 

One solution to the issue would just be to make much clearer = which SDOs have participated in this work and which have not and the status of = that progress - however that was also what people keep calling the "applicability statement" was trying to = do.

 

regards

 

Keith

 

 

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner
Sent: Wednesday, July 29, 2009 2:53 PM
To: 'ecrit'
Subject: [Ecrit] HUM on PhoneBCP

During today’s meeting there was discussion as to why the chairs = Publication Requested PhoneBCP version 13 when there are unresolved issues. =  This discussion led us to call for a hum.  We are now asking the same = question on the list.

Do you agree or disagree that PhoneBCP -13 = is ready to Publication Request?

Please respond by close of business on Wednesday August 5th.

Thanks,

Marc & Hannes

------=_NextPart_000_0056_01CA10D2.1B754FD0-- From br@brianrosen.net Thu Jul 30 02:01:35 2009 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 1E29D3A6809 for ; Thu, 30 Jul 2009 02:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 vJzycNkXArHj for ; Thu, 30 Jul 2009 02:01:34 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id E94543A71BD for ; Thu, 30 Jul 2009 02:01:33 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MWRVw-0000tG-Vv; Thu, 30 Jul 2009 04:01:31 -0500 From: "Brian Rosen" To: "'Robins George'" , "'Thomson, Martin'" References: <4A608144.7090107@bbn.com> <4A60DF3C.2050401@bbn.com> <4A714774.3070505@huawei.com> <4A715F94.3040406@huawei.com> In-Reply-To: <4A715F94.3040406@huawei.com> Date: Thu, 30 Jul 2009 05:01:27 -0400 Message-ID: <006001ca10f4$5695c140$03c143c0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoQ83DbmBFv++DvT/68//a8UpQrswAAF5Sw Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] New ID creating Geocoding URN 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, 30 Jul 2009 09:01:35 -0000 What I suggested is that we need a generalized PIDF-LO to PIDF-LO transformation service. The service would take a PIDF and some set of parameters and transform the input PIDF to an output PIDF. One transformation is geocode/reverse geocode. Another might be to transform from one form of civic address to another (which was my example). I do not want to overload either LoST or HELD with this service. It doesn't have the same inputs and/or outputs. Make it a different service, defined to do the specific task at hand. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Robins George > Sent: Thursday, July 30, 2009 4:54 AM > To: Thomson, Martin > Cc: ECRIT > Subject: Re: [Ecrit] New ID creating Geocoding URN > > Hi Martin, > > > Hi Robins, > > > > We discussed this in the meeting and came to the conclusion that your > geocoding draft might be a more appropriate means of actually making > the geocoding request. Brian suggested that the scope might be > extended to include a more general "PIDF-LO transformation" - something > that is apparently necessary in the 'states for translating between > emergency-useful civic location and postal-useful civic location for > instance. I'm certainly interested in seeing that work progress. > > > > > > I do understand Brian's concern to include presence information and > I'll > work on it to produce a revision of this draft. > > However, use of LoST in _discovering_ a server that is capable of > providing this service was still a useful thing. > > > > > I agree. > > --Robins > > [Apologies for not attending the face-to-face discussion, I was in > another meeting] > > > --Martin > > > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > >> Of Robins George > >> Sent: Thursday, 30 July 2009 9:11 AM > >> To: James M. Polk > >> Cc: 'ECRIT' > >> Subject: Re: [Ecrit] New ID creating Geocoding URN > >> > >> James, > >> > >> HELD extension would be a better choice for Geocoding and > >> Reverse-Geocoding. More over address translation is useful in many > >> cases > >> other than emergency services, where LoST is not required. > >> > >> > >> On 7/18/2009 1:06 AM, James M. Polk wrote: > >> > >>> At 03:29 PM 7/17/2009, Richard Barnes wrote: > >>> > >>>> Hey James, > >>>> > >>>> > >>>>>> I'm a little puzzled as to why you would want to use LoST for > >>>>>> [reverse] geocoding ... > >>>>>> > >>>>> It seems to me that LoST servers will not be that overloaded > >>>>> > >> (though > >> > >>>>> I could be underestimating), > >>>>> > >>>> There's nothing preventing these servers from offering a different > >>>> interface. Heck, both LoST and HELD are HTTP-based, so it'll > >>>> probably just be another servlet / script / etc. > >>>> > >>> fair comment - but this is a draw IMO > >>> > >>> > >>> > >>>>>> For just trading civic vs. geodetic information, it would seem > >>>>>> > >> much > >> > >>>>>> more appropriate to use HELD as a baseline, as in > >>>>>> >>>>>> > >> translation-01> > >> > >>>>>> > >>>>> I'm not sure HELD will be in every device, which would be > required > >>>>> for/by this ID, correct? > >>>>> > >>>> Last I read phonebcp, HELD and DHCP were required in the same > >>>> > >> places. > >> > >>> true - but since devices are made by vendors, they will choose to > >>> implement what they want to implement (and I'm not just talking > about > >>> Cisco), regardless of what a spec says. The all mighty RFP is > >>> > >> mightier > >> > >>> than the RFC (regrettably) ;-) > >>> > >>> > >>> > >>>> Moreover, geocoding is useful in many cases outside of emergency > >>>> services, so devices that aren't capable of emergency calling > might > >>>> still want to do it. > >>>> > >>> ok - to that I'd say that LoST is definitely more useful than just > >>> > >> for > >> > >>> emergency calling too. The ECRIT WG reached consensus that LoST > and > >>> the service URNs are to be extended in ECRIT even if the particular > >>> service has nothing to do with emergency calling. There was a > lively > >>> and open debate about this in Vancouver. > >>> > >>> I'd further say that applications that likely are intelligent > enough > >>> to know the difference between the two formats will be more > >>> intelligent than a palette, thus making them (probably) more often > >>> than not able to signal an emergency - even if the likely won't in > >>> their lifetime. > >>> > >>> Smart phones is a good example of this. Not-so-smart phones > probably > >>> will also have LoST in them, so coding the new URN seems like a > >>> no-brainer to me. > >>> > >>> > >>>> These devices > >>>> > >>> which devices? boxes, palettes or phones? > >>> > >>> > >>>> won't necessarily have LoST libraries, so there's no inherent > >>>> advantage there to using LoST. > >>>> > >>> I believe the latter of the list above will, and will probably be > the > >>> type of devices that knows enough to do the geocoding transaction. > >>> > >> I'm > >> > >>> not thinking palettes or boxes will have the choice of more than > one > >>> location format, much less know to ask for another one. > >>> > >>> My draft is targeted at devices that have applications that are > smart > >>> enough to know there is a difference and to ask for the more > >>> > >> preferred > >> > >>> format if they only receive a format that know isn't what they > >>> > >> prefer. > >> > >>> James > >>> > >>> > >>> > >>>> --Richard > >>>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >>> > >>> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >> > > --------------------------------------------------------------------- > --------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > --------------------------------------------------------------------- > --------------------------- > > [mf2] > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hardie@qualcomm.com Thu Jul 30 02:09:48 2009 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 D21E128C218 for ; Thu, 30 Jul 2009 02:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.999 X-Spam-Level: X-Spam-Status: No, score=-104.999 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqm7DTET-km2 for ; Thu, 30 Jul 2009 02:09:47 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 37D7F28C239 for ; Thu, 30 Jul 2009 02:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1248944987; x=1280480987; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<006001ca10f4$5695c140$ 03c143c0$@net>|References:=20=0D=0A=20<4A608144.7090107@bb n.com>=0D=0A=20=0D=0A=20<4A60DF3C.2050401@bbn.com>=0D=0A =20=0D=0A=20<4A714774.3070505@huawei.com>=0D=0A=20=0D =0A=20<4A715F94.3040406@huawei.com>=20<006001ca10f4$5695c 140$03c143c0$@net>|Date:=20Thu,=2030=20Jul=202009=2011:09 :35=20+0200|To:=20Brian=20Rosen=20,=20 "'Robins=20George'"=20,=0D=0A=20=20 =20=20=20=20=20=20"'Thomson,=20Martin'"=20|From:=20Ted=20Hardie=20 |Subject:=20Re:=20[Ecrit]=20New=20ID=20creating=20Geocodi ng=20URN|CC:=20"'ECRIT'"=20|Content-Type: =20text/plain=3B=20charset=3D"us-ascii"|X-IronPort-AV:=20 E=3DMcAfee=3Bi=3D"5300,2777,5692"=3B=20a=3D"21429227"; bh=b4800wtdDPDfeICiPQyurYaV+/OxzfCmmL+OIa6qH3k=; b=gt+68k/2UJkSvqlNt/imUGguU1jw+zvhR7TuwdBrxKNAygAKU+Xy7z6w +tfHSOUcpvCRbh7nHCrfjgNt/bTFXz/gwQA4qriZCe27+BgxYonftMZNl 13E29igWP9DR/mN4pC7AzjJN71VtXhygNt1nvubV3sp6Yo/OztMRvevtG I=; X-IronPort-AV: E=McAfee;i="5300,2777,5692"; a="21429227" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jul 2009 02:09:47 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6U99klO032012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Jul 2009 02:09:46 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6U99kIe010725 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Jul 2009 02:09:46 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 30 Jul 2009 02:09:45 -0700 Received: from [130.129.16.114] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 30 Jul 2009 02:09:44 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <006001ca10f4$5695c140$03c143c0$@net> References: <4A608144.7090107@bbn.com> <4A60DF3C.2050401@bbn.com> <4A714774.3070505@huawei.com> <4A715F94.3040406@huawei.com> <006001ca10f4$5695c140$03c143c0$@net> Date: Thu, 30 Jul 2009 11:09:35 +0200 To: Brian Rosen , "'Robins George'" , "'Thomson, Martin'" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Cc: 'ECRIT' Subject: Re: [Ecrit] New ID creating Geocoding URN 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, 30 Jul 2009 09:09:48 -0000 At 2:01 AM -0700 7/30/09, Brian Rosen wrote: >What I suggested is that we need a generalized PIDF-LO to PIDF-LO >transformation service. The service would take a PIDF and some set of >parameters and transform the input PIDF to an output PIDF. One >transformation is geocode/reverse geocode. Another might be to transform >from one form of civic address to another (which was my example). > >I do not want to overload either LoST or HELD with this service. It doesn't >have the same inputs and/or outputs. Make it a different service, defined >to do the specific task at hand. > >Brian What permissions need to be granted in order to allow this transformation? Are we sure that the privacy considerations are the same, and that the rule-makers original decision on what rules to apply can be applied to a transformed PIDF-LO? Especially if the transformation is not simple geocoding? Ted > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Robins George >> Sent: Thursday, July 30, 2009 4:54 AM >> To: Thomson, Martin >> Cc: ECRIT >> Subject: Re: [Ecrit] New ID creating Geocoding URN >> >> Hi Martin, >> >> > Hi Robins, >> > >> > We discussed this in the meeting and came to the conclusion that your >> geocoding draft might be a more appropriate means of actually making >> the geocoding request. Brian suggested that the scope might be >> extended to include a more general "PIDF-LO transformation" - something >> that is apparently necessary in the 'states for translating between >> emergency-useful civic location and postal-useful civic location for >> instance. I'm certainly interested in seeing that work progress. >> > >> > >> >> I do understand Brian's concern to include presence information and >> I'll >> work on it to produce a revision of this draft. >> > However, use of LoST in _discovering_ a server that is capable of >> providing this service was still a useful thing. >> > >> > >> I agree. >> >> --Robins >> >> [Apologies for not attending the face-to-face discussion, I was in >> another meeting] >> >> > --Martin >> > >> > >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf >> >> Of Robins George >> >> Sent: Thursday, 30 July 2009 9:11 AM >> >> To: James M. Polk >> >> Cc: 'ECRIT' >> >> Subject: Re: [Ecrit] New ID creating Geocoding URN >> >> >> >> James, >> >> >> >> HELD extension would be a better choice for Geocoding and >> >> Reverse-Geocoding. More over address translation is useful in many >> >> cases >> >> other than emergency services, where LoST is not required. >> >> >> >> >> >> On 7/18/2009 1:06 AM, James M. Polk wrote: >> >> >> >>> At 03:29 PM 7/17/2009, Richard Barnes wrote: >> >>> >> >>>> Hey James, >> >>>> >> >>>> >> >>>>>> I'm a little puzzled as to why you would want to use LoST for >> >>>>>> [reverse] geocoding ... >> >>>>>> >> >>>>> It seems to me that LoST servers will not be that overloaded >> >>>>> >> >> (though >> >> >> >>>>> I could be underestimating), >> >>>>> >> >>>> There's nothing preventing these servers from offering a different >> >>>> interface. Heck, both LoST and HELD are HTTP-based, so it'll >> >>>> probably just be another servlet / script / etc. >> >>>> >> >>> fair comment - but this is a draw IMO >> >>> >> >>> >> >>> >> >>>>>> For just trading civic vs. geodetic information, it would seem >> >>>>>> >> >> much >> >> >> >>>>>> more appropriate to use HELD as a baseline, as in >> >>>>>> > >>>>>> >> >> translation-01> >> >> >> >>>>>> >> >>>>> I'm not sure HELD will be in every device, which would be >> required >> >>>>> for/by this ID, correct? >> >>>>> >> >>>> Last I read phonebcp, HELD and DHCP were required in the same >> >>>> >> >> places. >> >> >> >>> true - but since devices are made by vendors, they will choose to >> >>> implement what they want to implement (and I'm not just talking > > about >> >>> Cisco), regardless of what a spec says. The all mighty RFP is >> >>> >> >> mightier >> >> >> >>> than the RFC (regrettably) ;-) >> >>> >> >>> >> >>> >> >>>> Moreover, geocoding is useful in many cases outside of emergency >> >>>> services, so devices that aren't capable of emergency calling >> might >> >>>> still want to do it. >> >>>> >> >>> ok - to that I'd say that LoST is definitely more useful than just >> >>> >> >> for >> >> >> >>> emergency calling too. The ECRIT WG reached consensus that LoST >> and >> >>> the service URNs are to be extended in ECRIT even if the particular >> >>> service has nothing to do with emergency calling. There was a >> lively >> >>> and open debate about this in Vancouver. >> >>> >> >>> I'd further say that applications that likely are intelligent >> enough >> >>> to know the difference between the two formats will be more >> >>> intelligent than a palette, thus making them (probably) more often >> >>> than not able to signal an emergency - even if the likely won't in >> >>> their lifetime. >> >>> >> >>> Smart phones is a good example of this. Not-so-smart phones >> probably >> >>> will also have LoST in them, so coding the new URN seems like a >> >>> no-brainer to me. >> >>> >> >>> >> >>>> These devices >> >>>> >> >>> which devices? boxes, palettes or phones? >> >>> >> >>> >> >>>> won't necessarily have LoST libraries, so there's no inherent >> >>>> advantage there to using LoST. >> >>>> >> >>> I believe the latter of the list above will, and will probably be >> the >> >>> type of devices that knows enough to do the geocoding transaction. >> >>> >> >> I'm >> >> >> >>> not thinking palettes or boxes will have the choice of more than >> one >> >>> location format, much less know to ask for another one. >> >>> >> >>> My draft is targeted at devices that have applications that are >> smart >> >>> enough to know there is a difference and to ask for the more >> >>> >> >> preferred >> >> >> >>> format if they only receive a format that know isn't what they >> >>> >> >> prefer. >> >> >> >>> James >> >>> >> >>> >> >>> >> >>>> --Richard >> >>>> >> >>> _______________________________________________ >> >>> Ecrit mailing list >> >>> Ecrit@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/ecrit >> >>> >> >>> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> > --------------------------------------------------------------------- >> --------------------------- >> > This message is for the designated recipient only and may >> > contain privileged, proprietary, or otherwise private information. >> > If you have received it in error, please notify the sender >> > immediately and delete the original. Any unauthorized use of >> > this email is prohibited. >> > --------------------------------------------------------------------- >> --------------------------- >> > [mf2] >> > >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From Martin.Dawson@andrew.com Thu Jul 30 02:10:11 2009 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 415D028C200 for ; Thu, 30 Jul 2009 02:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9pAvw8qbOfP for ; Thu, 30 Jul 2009 02:10:10 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id AC8DC28C1F1 for ; Thu, 30 Jul 2009 02:10:09 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_30_04_32_42 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 30 Jul 2009 04:32:41 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 04:10:08 -0500 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, 30 Jul 2009 04:10:06 -0500 Message-ID: In-Reply-To: <006001ca10f4$5695c140$03c143c0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] New ID creating Geocoding URN Thread-Index: AcoQ83DbmBFv++DvT/68//a8UpQrswAAF5SwAABU58A= References: <4A608144.7090107@bbn.com> <4A60DF3C.2050401@bbn.com> <4A714774.3070505@huawei.com> <4A715F94.3040406@huawei.com> <006001ca10f4$5695c140$03c143c0$@net> From: "Dawson, Martin" To: "Brian Rosen" , "Robins George" , "Thomson, Martin" X-OriginalArrivalTime: 30 Jul 2009 09:10:08.0506 (UTC) FILETIME=[89010DA0:01CA10F5] Cc: ECRIT Subject: Re: [Ecrit] New ID creating Geocoding URN 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, 30 Jul 2009 09:10:11 -0000 I agree. It's a different service. I don't know if folk think that=0D=0Aove= rloading services is a quicker way to get a spec... it's not in my=0D=0Aexp= erience. And modular design, as in almost all engineering, is a=0D=0Abetter= approach to protocol specification.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A--= ---Original Message-----=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bo= unces@ietf.org] On Behalf=0D=0AOf Brian Rosen=0D=0ASent: Thursday, 30 July = 2009 7:01 PM=0D=0ATo: 'Robins George'; Thomson, Martin=0D=0ACc: 'ECRIT'=0D=0A= Subject: Re: [Ecrit] New ID creating Geocoding URN=0D=0A=0D=0AWhat I sugges= ted is that we need a generalized PIDF-LO to PIDF-LO=0D=0Atransformation se= rvice. The service would take a PIDF and some set of=0D=0Aparameters and t= ransform the input PIDF to an output PIDF. One=0D=0Atransformation is geoc= ode/reverse geocode. Another might be to=0D=0Atransform=0D=0Afrom one form= of civic address to another (which was my example). =20=0D=0A=0D=0AI do no= t want to overload either LoST or HELD with this service. It=0D=0Adoesn't=0D= =0Ahave the same inputs and/or outputs. Make it a different service,=0D=0A= defined=0D=0Ato do the specific task at hand.=0D=0A=0D=0ABrian=0D=0A=0D=0A=0D= =0A> -----Original Message-----=0D=0A> From: ecrit-bounces@ietf.org [mailto= :ecrit-bounces@ietf.org] On Behalf=0D=0A> Of Robins George=0D=0A> Sent: Thu= rsday, July 30, 2009 4:54 AM=0D=0A> To: Thomson, Martin=0D=0A> Cc: ECRIT=0D= =0A> Subject: Re: [Ecrit] New ID creating Geocoding URN=0D=0A>=20=0D=0A> Hi= Martin,=0D=0A>=20=0D=0A> > Hi Robins,=0D=0A> >=0D=0A> > We discussed this = in the meeting and came to the conclusion that=0D=0Ayour=0D=0A> geocoding d= raft might be a more appropriate means of actually making=0D=0A> the geocod= ing request. Brian suggested that the scope might be=0D=0A> extended to in= clude a more general "PIDF-LO transformation" -=0D=0Asomething=0D=0A> that = is apparently necessary in the 'states for translating between=0D=0A> emerg= ency-useful civic location and postal-useful civic location for=0D=0A> inst= ance. I'm certainly interested in seeing that work progress.=0D=0A> >=0D=0A= > >=0D=0A>=20=0D=0A> I do understand Brian's concern to include presence in= formation and=0D=0A> I'll=0D=0A> work on it to produce a revision of this d= raft.=0D=0A> > However, use of LoST in _discovering_ a server that is capab= le of=0D=0A> providing this service was still a useful thing.=0D=0A> >=0D=0A= > >=0D=0A> I agree.=0D=0A>=20=0D=0A> --Robins=0D=0A>=20=0D=0A> [Apologies f= or not attending the face-to-face discussion, I was in=0D=0A> another meeti= ng]=0D=0A>=20=0D=0A> > --Martin=0D=0A> >=0D=0A> >=0D=0A> >> -----Original M= essage-----=0D=0A> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ie= tf.org] On=0D=0A> Behalf=0D=0A> >> Of Robins George=0D=0A> >> Sent: Thursda= y, 30 July 2009 9:11 AM=0D=0A> >> To: James M. Polk=0D=0A> >> Cc: 'ECRIT'=0D= =0A> >> Subject: Re: [Ecrit] New ID creating Geocoding URN=0D=0A> >>=0D=0A>= >> James,=0D=0A> >>=0D=0A> >> HELD extension would be a better choice for = Geocoding and=0D=0A> >> Reverse-Geocoding. More over address translation is= useful in many=0D=0A> >> cases=0D=0A> >> other than emergency services, wh= ere LoST is not required.=0D=0A> >>=0D=0A> >>=0D=0A> >> On 7/18/2009 1:06 A= M, James M. Polk wrote:=0D=0A> >>=0D=0A> >>> At 03:29 PM 7/17/2009, Richard= Barnes wrote:=0D=0A> >>>=0D=0A> >>>> Hey James,=0D=0A> >>>>=0D=0A> >>>>=0D= =0A> >>>>>> I'm a little puzzled as to why you would want to use LoST for=0D= =0A> >>>>>> [reverse] geocoding ...=0D=0A> >>>>>>=0D=0A> >>>>> It seems to = me that LoST servers will not be that overloaded=0D=0A> >>>>>=0D=0A> >> (th= ough=0D=0A> >>=0D=0A> >>>>> I could be underestimating),=0D=0A> >>>>>=0D=0A= > >>>> There's nothing preventing these servers from offering a=0D=0Adiffer= ent=0D=0A> >>>> interface. Heck, both LoST and HELD are HTTP-based, so it'= ll=0D=0A> >>>> probably just be another servlet / script / etc.=0D=0A> >>>>=0D= =0A> >>> fair comment - but this is a draw IMO=0D=0A> >>>=0D=0A> >>>=0D=0A>= >>>=0D=0A> >>>>>> For just trading civic vs. geodetic information, it woul= d seem=0D=0A> >>>>>>=0D=0A> >> much=0D=0A> >>=0D=0A> >>>>>> more appropriat= e to use HELD as a baseline, as in=0D=0A> >>>>>> >>>>>>=0D=0A> >> translation-01>=0D=0A= > >>=0D=0A> >>>>>>=0D=0A> >>>>> I'm not sure HELD will be in every device, = which would be=0D=0A> required=0D=0A> >>>>> for/by this ID, correct=3F=0D=0A= > >>>>>=0D=0A> >>>> Last I read phonebcp, HELD and DHCP were required in th= e same=0D=0A> >>>>=0D=0A> >> places.=0D=0A> >>=0D=0A> >>> true - but since = devices are made by vendors, they will choose to=0D=0A> >>> implement what = they want to implement (and I'm not just talking=0D=0A> about=0D=0A> >>> Ci= sco), regardless of what a spec says. The all mighty RFP is=0D=0A> >>>=0D=0A= > >> mightier=0D=0A> >>=0D=0A> >>> than the RFC (regrettably) ;-)=0D=0A> = >>>=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>> Moreover, geocoding is useful in many= cases outside of emergency=0D=0A> >>>> services, so devices that aren't ca= pable of emergency calling=0D=0A> might=0D=0A> >>>> still want to do it.=0D= =0A> >>>>=0D=0A> >>> ok - to that I'd say that LoST is definitely more usef= ul than just=0D=0A> >>>=0D=0A> >> for=0D=0A> >>=0D=0A> >>> emergency callin= g too. The ECRIT WG reached consensus that LoST=0D=0A> and=0D=0A> >>> the = service URNs are to be extended in ECRIT even if the=0D=0Aparticular=0D=0A>= >>> service has nothing to do with emergency calling. There was a=0D=0A> l= ively=0D=0A> >>> and open debate about this in Vancouver.=0D=0A> >>>=0D=0A>= >>> I'd further say that applications that likely are intelligent=0D=0A> e= nough=0D=0A> >>> to know the difference between the two formats will be mor= e=0D=0A> >>> intelligent than a palette, thus making them (probably) more o= ften=0D=0A> >>> than not able to signal an emergency - even if the likely w= on't in=0D=0A> >>> their lifetime.=0D=0A> >>>=0D=0A> >>> Smart phones is a = good example of this. Not-so-smart phones=0D=0A> probably=0D=0A> >>> will a= lso have LoST in them, so coding the new URN seems like a=0D=0A> >>> no-bra= iner to me.=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>> These devices=0D=0A> >>>>=0D=0A= > >>> which devices=3F boxes, palettes or phones=3F=0D=0A> >>>=0D=0A> >>>=0D= =0A> >>>> won't necessarily have LoST libraries, so there's no inherent=0D=0A= > >>>> advantage there to using LoST.=0D=0A> >>>>=0D=0A> >>> I believe the = latter of the list above will, and will probably be=0D=0A> the=0D=0A> >>> t= ype of devices that knows enough to do the geocoding transaction.=0D=0A> >>= >=0D=0A> >> I'm=0D=0A> >>=0D=0A> >>> not thinking palettes or boxes will ha= ve the choice of more than=0D=0A> one=0D=0A> >>> location format, much less= know to ask for another one.=0D=0A> >>>=0D=0A> >>> My draft is targeted at= devices that have applications that are=0D=0A> smart=0D=0A> >>> enough to = know there is a difference and to ask for the more=0D=0A> >>>=0D=0A> >> pre= ferred=0D=0A> >>=0D=0A> >>> format if they only receive a format that know = isn't what they=0D=0A> >>>=0D=0A> >> prefer.=0D=0A> >>=0D=0A> >>> James=0D=0A= > >>>=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>> --Richard=0D=0A> >>>>=0D=0A> >>> __= _____________________________________________=0D=0A> >>> Ecrit mailing list=0D= =0A> >>> Ecrit@ietf.org=0D=0A> >>> https://www.ietf.org/mailman/listinfo/ec= rit=0D=0A> >>>=0D=0A> >>>=0D=0A> >> _______________________________________= ________=0D=0A> >> Ecrit mailing list=0D=0A> >> Ecrit@ietf.org=0D=0A> >> ht= tps://www.ietf.org/mailman/listinfo/ecrit=0D=0A> >>=0D=0A> >=0D=0A---------= ------------------------------------------------------------=0D=0A> -------= --------------------=0D=0A> > This message is for the designated recipient = only and may=0D=0A> > contain privileged, proprietary, or otherwise private= information.=0D=0A> > If you have received it in error, please notify the = sender=0D=0A> > immediately and delete the original. Any unauthorized use = of=0D=0A> > this email is prohibited.=0D=0A> >=0D=0A-----------------------= ----------------------------------------------=0D=0A> ---------------------= ------=0D=0A> > [mf2]=0D=0A> >=0D=0A>=20=0D=0A> ___________________________= ____________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A>= https://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A___________________= ____________________________=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D= =0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A-----------------= ---------------------------------------------------------------------------= ----=0D=0AThis message is for the designated recipient only and may=0D=0Aco= ntain privileged, proprietary, or otherwise private information. =20=0D=0AI= f you have received it in error, please notify the sender=0D=0Aimmediately = and delete the original. Any unauthorized use of=0D=0Athis email is prohib= ited.=0D=0A----------------------------------------------------------------= --------------------------------=0D=0A[mf2]=0D=0A From br@brianrosen.net Thu Jul 30 02:23:07 2009 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 2F96928C29D for ; Thu, 30 Jul 2009 02:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 Wn2I54v6dEdB for ; Thu, 30 Jul 2009 02:23:06 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id D5D3C28C29C for ; Thu, 30 Jul 2009 02:23:05 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MWRqo-0002L9-PF; Thu, 30 Jul 2009 04:23:03 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Robins George'" , "'Thomson, Martin'" References: <4A608144.7090107@bbn.com> <4A60DF3C.2050401@bbn.com> <4A714774.3070505@huawei.com> <4A715F94.3040406@huawei.com> <006001ca10f4$5695c140$03c143c0$@net> In-Reply-To: Date: Thu, 30 Jul 2009 05:23:00 -0400 Message-ID: <006701ca10f7$5885f120$0991d360$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoQ9ZU4OmXUHAesTJ6itb4AR7f35gAATHBg Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] New ID creating Geocoding URN 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, 30 Jul 2009 09:23:07 -0000 Generally, I would think that the PIDF still represents the location of a target, and its privacy considerations would be the same. I'm sanguine on whether you need explicit permission to transform, but you certainly need to respect the same restrictions on dissemination as the original. An interesting transform is "fuzz", i.e. make location less precise. That may be allowed to have a less restrictive ruleset than the original. The RM would have to do that itself of course. Brian > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Thursday, July 30, 2009 5:10 AM > To: Brian Rosen; 'Robins George'; 'Thomson, Martin' > Cc: 'ECRIT' > Subject: Re: [Ecrit] New ID creating Geocoding URN > > At 2:01 AM -0700 7/30/09, Brian Rosen wrote: > >What I suggested is that we need a generalized PIDF-LO to PIDF-LO > >transformation service. The service would take a PIDF and some set of > >parameters and transform the input PIDF to an output PIDF. One > >transformation is geocode/reverse geocode. Another might be to > transform > >from one form of civic address to another (which was my example). > > > >I do not want to overload either LoST or HELD with this service. It > doesn't > >have the same inputs and/or outputs. Make it a different service, > defined > >to do the specific task at hand. > > > >Brian > > What permissions need to be granted in order to allow this > transformation? > Are we sure that the privacy considerations are the same, and that the > rule-makers > original decision on what rules to apply can be applied to a > transformed > PIDF-LO? Especially if the transformation is not simple geocoding? > > Ted > > > > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > >> Of Robins George > >> Sent: Thursday, July 30, 2009 4:54 AM > >> To: Thomson, Martin > >> Cc: ECRIT > >> Subject: Re: [Ecrit] New ID creating Geocoding URN > >> > >> Hi Martin, > >> > >> > Hi Robins, > >> > > >> > We discussed this in the meeting and came to the conclusion that > your > >> geocoding draft might be a more appropriate means of actually making > >> the geocoding request. Brian suggested that the scope might be > >> extended to include a more general "PIDF-LO transformation" - > something > >> that is apparently necessary in the 'states for translating between > >> emergency-useful civic location and postal-useful civic location for > >> instance. I'm certainly interested in seeing that work progress. > >> > > >> > > >> > >> I do understand Brian's concern to include presence information and > >> I'll > >> work on it to produce a revision of this draft. > >> > However, use of LoST in _discovering_ a server that is capable of > >> providing this service was still a useful thing. > >> > > >> > > >> I agree. > >> > >> --Robins > >> > >> [Apologies for not attending the face-to-face discussion, I was in > >> another meeting] > >> > >> > --Martin > >> > > >> > > >> >> -----Original Message----- > >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> Behalf > >> >> Of Robins George > >> >> Sent: Thursday, 30 July 2009 9:11 AM > >> >> To: James M. Polk > >> >> Cc: 'ECRIT' > >> >> Subject: Re: [Ecrit] New ID creating Geocoding URN > >> >> > >> >> James, > >> >> > >> >> HELD extension would be a better choice for Geocoding and > >> >> Reverse-Geocoding. More over address translation is useful in > many > >> >> cases > >> >> other than emergency services, where LoST is not required. > >> >> > >> >> > >> >> On 7/18/2009 1:06 AM, James M. Polk wrote: > >> >> > >> >>> At 03:29 PM 7/17/2009, Richard Barnes wrote: > >> >>> > >> >>>> Hey James, > >> >>>> > >> >>>> > >> >>>>>> I'm a little puzzled as to why you would want to use LoST for > >> >>>>>> [reverse] geocoding ... > >> >>>>>> > >> >>>>> It seems to me that LoST servers will not be that overloaded > >> >>>>> > >> >> (though > >> >> > >> >>>>> I could be underestimating), > >> >>>>> > >> >>>> There's nothing preventing these servers from offering a > different > >> >>>> interface. Heck, both LoST and HELD are HTTP-based, so it'll > >> >>>> probably just be another servlet / script / etc. > >> >>>> > >> >>> fair comment - but this is a draw IMO > >> >>> > >> >>> > >> >>> > >> >>>>>> For just trading civic vs. geodetic information, it would > seem > >> >>>>>> > >> >> much > >> >> > >> >>>>>> more appropriate to use HELD as a baseline, as in > >> >>>>>> >> >>>>>> > >> >> translation-01> > >> >> > >> >>>>>> > >> >>>>> I'm not sure HELD will be in every device, which would be > >> required > >> >>>>> for/by this ID, correct? > >> >>>>> > >> >>>> Last I read phonebcp, HELD and DHCP were required in the same > >> >>>> > >> >> places. > >> >> > >> >>> true - but since devices are made by vendors, they will choose > to > >> >>> implement what they want to implement (and I'm not just talking > > > about > >> >>> Cisco), regardless of what a spec says. The all mighty RFP is > >> >>> > >> >> mightier > >> >> > >> >>> than the RFC (regrettably) ;-) > >> >>> > >> >>> > >> >>> > >> >>>> Moreover, geocoding is useful in many cases outside of > emergency > >> >>>> services, so devices that aren't capable of emergency calling > >> might > >> >>>> still want to do it. > >> >>>> > >> >>> ok - to that I'd say that LoST is definitely more useful than > just > >> >>> > >> >> for > >> >> > >> >>> emergency calling too. The ECRIT WG reached consensus that LoST > >> and > >> >>> the service URNs are to be extended in ECRIT even if the > particular > >> >>> service has nothing to do with emergency calling. There was a > >> lively > >> >>> and open debate about this in Vancouver. > >> >>> > >> >>> I'd further say that applications that likely are intelligent > >> enough > >> >>> to know the difference between the two formats will be more > >> >>> intelligent than a palette, thus making them (probably) more > often > >> >>> than not able to signal an emergency - even if the likely won't > in > >> >>> their lifetime. > >> >>> > >> >>> Smart phones is a good example of this. Not-so-smart phones > >> probably > >> >>> will also have LoST in them, so coding the new URN seems like a > >> >>> no-brainer to me. > >> >>> > >> >>> > >> >>>> These devices > >> >>>> > >> >>> which devices? boxes, palettes or phones? > >> >>> > >> >>> > >> >>>> won't necessarily have LoST libraries, so there's no inherent > >> >>>> advantage there to using LoST. > >> >>>> > >> >>> I believe the latter of the list above will, and will probably > be > >> the > >> >>> type of devices that knows enough to do the geocoding > transaction. > >> >>> > >> >> I'm > >> >> > >> >>> not thinking palettes or boxes will have the choice of more than > >> one > >> >>> location format, much less know to ask for another one. > >> >>> > >> >>> My draft is targeted at devices that have applications that are > >> smart > >> >>> enough to know there is a difference and to ask for the more > >> >>> > >> >> preferred > >> >> > >> >>> format if they only receive a format that know isn't what they > >> >>> > >> >> prefer. > >> >> > >> >>> James > >> >>> > >> >>> > >> >>> > >> >>>> --Richard > >> >>>> > >> >>> _______________________________________________ > >> >>> Ecrit mailing list > >> >>> Ecrit@ietf.org > >> >>> https://www.ietf.org/mailman/listinfo/ecrit > >> >>> > >> >>> > >> >> _______________________________________________ > >> >> Ecrit mailing list > >> >> Ecrit@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/ecrit > >> >> > >> > ------------------------------------------------------------------ > --- > >> --------------------------- > >> > This message is for the designated recipient only and may > >> > contain privileged, proprietary, or otherwise private information. > >> > If you have received it in error, please notify the sender > >> > immediately and delete the original. Any unauthorized use of > >> > this email is prohibited. > >> > ------------------------------------------------------------------ > --- > >> --------------------------- > >> > [mf2] > >> > > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit From randy@qualcomm.com Thu Jul 30 05:39:58 2009 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 3540428C177 for ; Thu, 30 Jul 2009 05:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.788 X-Spam-Level: X-Spam-Status: No, score=-102.788 tagged_above=-999 required=5 tests=[AWL=-1.647, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnA6qNKplXyI for ; Thu, 30 Jul 2009 05:39:57 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 4A68B3A6818 for ; Thu, 30 Jul 2009 05:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1248957599; x=1280493599; h=message-id:in-reply-to:references:x-mailer: x-message-note:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20|In-Reply-To:=20 |References:=20=0D=0A =20|X-Mailer:=20Eudora =20for=20Mac=20OS=20X|X-message-Note:=20Warning:=20Outloo k=20in=20use.=20=20Upgrade=20to=20Eudora:=20|Date:=20Thu,=2030=20Jul=202009=2005:39:34=20-0 700|To:=20"DRAGE,=20Keith=20(Keith)"=20,=0D=0A=20=20=20=20=20=20=20=20Marc=20Linsner=0D =0A=09,=20"'ecrit'"=20|From:=20Randall=20Gellens=20 |Subject:=20Re:=20[Ecrit]=20HUM=20on=20PhoneBCP |MIME-Version:=201.0|Content-Type:=20text/html=3B=20chars et=3D"us-ascii"|X-Random-Sig-Tag:=201.0b28|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5300,2777,5692"=3B=20a=3D"21449114"; bh=8Mg3tJeKyBLNrRVp95RTALDSSjHmpT9mxgUuBMN5ys4=; b=Qpe+dtOa3C6ftI12TlNBQRaK0eiqxG9JP6IvpXR7CV0U6d5zxCRum2YF kJixoDUByq7CPGdFNVIwdbDdhLQlQ7M7G9TPaxZp67g8fFEb1xK26OCNU K6Ib9DTs8yAE9s9BBQ6TB0YtrQlGBeZD8ZAh1WpXYmghw8pdMOlQa0MdE 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5692"; a="21449114" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jul 2009 05:39:44 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6UCdhKX005234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Jul 2009 05:39:43 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6UCdhmP010534 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Jul 2009 05:39:43 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 30 Jul 2009 05:39:43 -0700 Received: from dhcp-121a.meeting.ietf.org (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 30 Jul 2009 05:39:42 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 30 Jul 2009 05:39:34 -0700 To: "DRAGE, Keith (Keith)" , Marc Linsner , "'ecrit'" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Random-Sig-Tag: 1.0b28 Subject: Re: [Ecrit] HUM on 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: Thu, 30 Jul 2009 12:39:58 -0000 Re: [Ecrit] HUM on PhoneBCP
+1.  The document is not ready.

Further, there is a liaison from 3GPP SA2 that says that they intend to send further liaison on this document.  We should wait at least a little while for this liaison.

At 10:00 AM +0200 7/30/09, Keith (Keith) DRAGE wrote:

I don't agree.
 
Some background.
 
There was a set of comments provided by Stephen Edge on 5th February 2009. I can find no response to that set of comments on the mailing list.
 
The gist of that set of comments was that phonebcp claims to cover all access technologies and it identified a significant number of requirements within phonebcp that the author considered were not requirements on 3GPP accesses.
 
So my position is that the document is not ready because all the valid comments on the document were not addressed.
 
There are two ways of dealing with this set of comments:
 
-    going through and modifying all the identified requirements where the comment is upheld.
 
-    making more clear in the abstract and / or introduction that this is solely the view of IETF in regard to IP capable devices and that other organisations may specify other requirements.
 
I would note at this point that the current abstract says:
 
   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.
Because the two sentences follow each other, it implies that other SDOs that have efforts targetted at addressing these solutions are complicit in the requirements so stated, and this is untrue. Certainly the current status of this document as addressed by various informal 3GPP discussions is to ensure that things do not fall apart in entities using the 3GPP mechanisms, however 3GPP devices do not use these requirements (no do these requirements represent the 3GPP requires.
 
One solution to the issue would just be to make much clearer which SDOs have participated in this work and which have not and the status of that progress - however that was also what people keep calling the "applicability statement" was trying to do.
 
regards
 
Keith
 
 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner
Sent: Wednesday, July 29, 2009 2:53 PM
To: 'ecrit'
Subject: [Ecrit] HUM on PhoneBCP
During today's meeting there was discussion as to why the chairs Publication Requested PhoneBCP version 13 when there are unresolved issues.  This discussion led us to call for a hum.  We are now asking the same question on the list.

Do you agree or disagree that PhoneBCP -13 is ready to Publication Request?

Please respond by close of business on Wednesday August 5th.

Thanks,
Marc & Hannes

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I worry that the person who thought up Muzak may be thinking up
something else.
 --Lily Tomlin
From drage@alcatel-lucent.com Thu Jul 30 08:21:15 2009 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 C045C28C18D for ; Thu, 30 Jul 2009 08:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=-1.328, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Rx+lCE47V-W1 for ; Thu, 30 Jul 2009 08:21:14 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id EE39D28C210 for ; Thu, 30 Jul 2009 08:21:13 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n6UFL95r011517 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Jul 2009 17:21:09 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 30 Jul 2009 17:21:09 +0200 From: "DRAGE, Keith (Keith)" To: "Dawson, Martin" , Marc Linsner , ecrit Date: Thu, 30 Jul 2009 17:21:08 +0200 Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAACSJnfAACH+vcA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE2070BE7F7FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Subject: Re: [Ecrit] HUM on 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: Thu, 30 Jul 2009 15:21:15 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE2070BE7F7FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Do not confuse things. This hum does not include that consideration at all. This hum merely answers the question: "Do you agree or disagree that PhoneBCP -13 is ready to Publication Request= ?" I included detail in my response as the reason I was answering no. We are n= ot at the point of considering that detail. regards Keith ________________________________ From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] Sent: Thursday, July 30, 2009 9:43 AM To: DRAGE, Keith (Keith); Marc Linsner; ecrit Subject: RE: [Ecrit] HUM on PhoneBCP > There are two ways of dealing with this set of comments: > > - going through and modifying all the identified requirements where th= e comment is upheld. > > - making more clear in the abstract and / or introduction that this is= solely the view of IETF in regard to IP capable devices and that other org= anisations may specify > other requirements. There=92s a third way. This hum actually includes the judgement on whether = Stephen=92s comments are valid. If the =93hummer=94 considers the document = is ready for publication then the inference is that they judge them not to = be. Works in my case. Cheers, Martin ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of D= RAGE, Keith (Keith) Sent: Thursday, 30 July 2009 6:01 PM To: Marc Linsner; 'ecrit' Subject: Re: [Ecrit] HUM on PhoneBCP I don't agree. Some background. There was a set of comments provided by Stephen Edge on 5th February 2009. = I can find no response to that set of comments on the mailing list. The gist of that set of comments was that phonebcp claims to cover all acce= ss technologies and it identified a significant number of requirements with= in phonebcp that the author considered were not requirements on 3GPP access= es. So my position is that the document is not ready because all the valid comm= ents on the document were not addressed. There are two ways of dealing with this set of comments: - going through and modifying all the identified requirements where the = comment is upheld. - making more clear in the abstract and / or introduction that this is s= olely the view of IETF in regard to IP capable devices and that other organ= isations may specify other requirements. I would note at this point that the current abstract says: 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. Because the two sentences follow each other, it implies that other SDOs tha= t have efforts targetted at addressing these solutions are complicit in the= requirements so stated, and this is untrue. Certainly the current status o= f this document as addressed by various informal 3GPP discussions is to ens= ure that things do not fall apart in entities using the 3GPP mechanisms, ho= wever 3GPP devices do not use these requirements (no do these requirements = represent the 3GPP requires. One solution to the issue would just be to make much clearer which SDOs hav= e participated in this work and which have not and the status of that progr= ess - however that was also what people keep calling the "applicability sta= tement" was trying to do. regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of M= arc Linsner Sent: Wednesday, July 29, 2009 2:53 PM To: 'ecrit' Subject: [Ecrit] HUM on PhoneBCP During today=92s meeting there was discussion as to why the chairs Publicat= ion Requested PhoneBCP version 13 when there are unresolved issues. This d= iscussion led us to call for a hum. We are now asking the same question on= the list. Do you agree or disagree that PhoneBCP -13 is ready to Publication Request? Please respond by close of business on Wednesday August 5th. Thanks, Marc & Hannes ---------------------------------------------------------------------------= --------------------- 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] --_000_EDC0A1AE77C57744B664A310A0B23AE2070BE7F7FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable HUM on PhoneBCP</TITLE= > <META http-equiv=3DContent-Type content=3D"text/html; charset=3DWindows-125= 2"> <META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: Batang; } @font-face { font-family: Tahoma; } @font-face { font-family: Calibri; } @font-face { font-family: @Batang; } @page Section1 {size: 595.3pt 841.9pt; margin: 72.0pt 90.0pt 72.0pt 90.0pt;= } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } SPAN.EmailStyle17 { COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } </STYLE> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></HEAD> <BODY lang=3DEN-AU vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><SPAN class=3D598544212-30072009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>Do not confuse things.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D598544212-30072009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D598544212-30072009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>This hum does not include that consideration at=20 all.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D598544212-30072009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D598544212-30072009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>This hum merely answers the question:</FONT></SPAN= ></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D598544212-30072009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV><SPAN class=3D598544212-= 30072009> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2></F= ONT><BR><SPAN=20 style=3D"COLOR: #121212"><FONT face=3DArial><FONT color=3D#0000ff><FONT siz= e=3D2><SPAN=20 class=3D598544212-30072009>"</SPAN>Do you agree or disagree that PhoneBCP -= 13 is=20 ready to Publication Request?<SPAN=20 class=3D598544212-30072009>"</SPAN><BR></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN style=3D"COLOR: #121212"><SPAN=20 class=3D598544212-30072009><FONT face=3DArial color=3D#0000ff size=3D2>I in= cluded detail=20 in my response as the reason I was answering no. We are not at the point of= =20 considering that detail.</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN style=3D"COLOR: #121212"><SPAN=20 class=3D598544212-30072009><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN style=3D"COLOR: #121212"><SPAN=20 class=3D598544212-30072009><FONT face=3DArial color=3D#0000ff=20 size=3D2>regards</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN style=3D"COLOR: #121212"><SPAN=20 class=3D598544212-30072009><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN style=3D"COLOR: #121212"><SPAN=20 class=3D598544212-30072009><FONT face=3DArial color=3D#0000ff=20 size=3D2>Keith</FONT></SPAN></DIV></SPAN></SPAN><BR> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli= d; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Dawson, Martin=20 [mailto:Martin.Dawson@andrew.com] <BR><B>Sent:</B> Thursday, July 30, 200= 9=20 9:43 AM<BR><B>To:</B> DRAGE, Keith (Keith); Marc Linsner;=20 ecrit<BR><B>Subject:</B> RE: [Ecrit] HUM on PhoneBCP<BR></FONT><BR></DIV> <DIV></DIV> <DIV class=3DSection1> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">> There are= two=20 ways of dealing with this set of comments:</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">></SPAN></F= ONT> <o:p></o:p></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">>=20 -    going through and modifying all the identified=20 requirements where the comment is upheld.</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">></SPAN></F= ONT> <o:p></o:p></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">>=20 -    making more clear in the abstract and / or introducti= on=20 that this is solely the view of IETF in regard to IP capable devices and = that=20 other organisations may specify > other=20 requirements.</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o= :p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o= :p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">There=92s a th= ird way.=20 This hum actually includes the judgement on whether Stephen=92s comments = are=20 valid. If the =93hummer=94 considers the document is ready for publicatio= n then=20 the inference is that they judge them not to be. Works in my=20 case.<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o= :p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Cheers,<o:p></= o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Martin<o:p></o= :p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o= :p></SPAN></FONT></P> <DIV> <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT= =20 face=3D"Times New Roman" size=3D3><SPAN lang=3DEN-US style=3D"FONT-SIZE: = 12pt"> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</= SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] <B><SPAN style=3D"FONT-WEIGHT: bold">On B= ehalf=20 Of </SPAN></B>DRAGE, Keith (Keith)<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Thursday, 30 July 2009 6:01= =20 PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Marc Linsner;=20 'ecrit'<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> Re: [= Ecrit]=20 HUM on PhoneBCP</SPAN></FONT><SPAN lang=3DEN-US><o:p></o:p></SPAN></P></D= IV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I don't=20 agree.</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Some=20 background.</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">There was a se= t of=20 comments provided by Stephen Edge on 5th February 2009. I can find no res= ponse=20 to that set of comments on the mailing list.</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">The gist of th= at set=20 of comments was that phonebcp claims to cover all access technologies and= it=20 identified a significant number of requirements within phonebcp that the= =20 author considered were not requirements on 3GPP=20 accesses.</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">So my position= is=20 that the document is not ready because all the valid comments on the docu= ment=20 were not addressed.</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">There are two = ways of=20 dealing with this set of comments:</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-  &= nbsp;=20 going through and modifying all the identified requirements where the com= ment=20 is upheld.</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-  &= nbsp;=20 making more clear in the abstract and / or introduction that this is sole= ly=20 the view of IETF in regard to IP capable devices and that other organisat= ions=20 may specify other requirements.</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I would note a= t this=20 point that the current abstract says:</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">   T= he IETF=20 and other standards organization have efforts targeted=20 at</SPAN></FONT><o:p></o:p></P> <DIV> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">  =20 standardizing various aspects of placing emergency calls on IP<BR> &= nbsp;=20 networks.  This memo describes best current practice on how=20 devices,<BR>   networks and services should use such standards = to=20 make emergency<BR>   calls.</SPAN></FONT><o:p></o:p></P></DIV> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Because the tw= o=20 sentences follow each other, it implies that other SDOs that have efforts= =20 targetted at addressing these solutions are complicit in the requirements= so=20 stated, and this is untrue. Certainly the current status of this document= as=20 addressed by various informal 3GPP discussions is to ensure that things d= o not=20 fall apart in entities using the 3GPP mechanisms, however 3GPP devices do= not=20 use these requirements (no do these requirements represent the 3GPP=20 requires.</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">One solution t= o the=20 issue would just be to make much clearer which SDOs have participated in = this=20 work and which have not and the status of that progress - however that wa= s=20 also what people keep calling the "applicability statement" was trying to= =20 do.</SPAN></FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">regards</SPAN>= </FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Keith</SPAN></= FONT><o:p></o:p></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P> <BLOCKQUOTE=20 style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: mediu= m none; PADDING-LEFT: 3pt; PADDING-BOTTOM: 0cm; MARGIN: 5pt 0cm 5pt 2.7pt; = BORDER-LEFT: blue 1pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none"> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FON= T=20 face=3D"Times New Roman" size=3D3><SPAN lang=3DEN-US style=3D"FONT-SIZE= : 12pt"> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><FONT face=3DTaho= ma=20 size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:= </SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> ecrit-bounces@ietf.org= =20 [mailto:ecrit-bounces@ietf.org] <B><SPAN style=3D"FONT-WEIGHT: bold">On= Behalf=20 Of </SPAN></B>Marc Linsner<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Wednesday, July 29, 2009 2= :53=20 PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> 'ecrit'<BR><B= ><SPAN=20 style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> [Ecrit] HUM on=20 PhoneBCP</SPAN></FONT><SPAN lang=3DEN-US><o:p></o:p></SPAN></P> <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN=20 style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri">During today=92s meetin= g there=20 was discussion as to why the chairs Publication Requested PhoneBCP vers= ion=20 13 when there are unresolved issues.  This discussion led us to ca= ll=20 for a hum.  We are now asking the same question on the=20 list.<BR><BR><FONT color=3D#121212><SPAN style=3D"COLOR: #121212">Do yo= u agree=20 or disagree that PhoneBCP -13 is ready to Publication Request?<BR><BR>P= lease=20 respond by close of business on Wednesday August=20 5th.<BR><BR>Thanks,<BR><BR>Marc &=20 Hannes<o:p></o:p></SPAN></FONT></SPAN></FONT></P></BLOCKQUOTE></DIV><BR= ><BR> <TABLE style=3D"COLOR: black" bgColor=3Dwhite> <TBODY> <TR> <TD><BR>-------------------------------------------------------------= -----------------------------------<BR>This message is for&n= bsp;the designated recipient only and may<BR>conta= in privileged, proprietary, or otherwise private&n= bsp;information.  <BR>If you have received it=  in error, please notify the sender<BR>immedi= ately and delete the original.  Any unau= thorized use of<BR>this email is prohibited.<BR>--= ---------------------------------------------------------------------------= -------------------<BR>[mf2]</TD></TR></TBODY></TABLE></BLOCKQUOTE></BODY><= /HTML> --_000_EDC0A1AE77C57744B664A310A0B23AE2070BE7F7FRMRSSXCHMBSC3d_-- From john.elwell@siemens-enterprise.com Thu Jul 30 10:02:20 2009 Return-Path: <john.elwell@siemens-enterprise.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56F203A6BC1 for <ecrit@core3.amsl.com>; Thu, 30 Jul 2009 10:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 AdJ4ovFsbBmh for <ecrit@core3.amsl.com>; Thu, 30 Jul 2009 10:02:19 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id BB3243A6AAC for <ecrit@ietf.org>; Thu, 30 Jul 2009 10:02:14 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KNL00MAOTZRBM@siemenscomms.co.uk> for ecrit@ietf.org; Thu, 30 Jul 2009 18:02:15 +0100 (BST) Date: Thu, 30 Jul 2009 18:02:25 +0100 From: "Elwell, John" <john.elwell@siemens-enterprise.com> In-reply-to: <EDC0A1AE77C57744B664A310A0B23AE2070BE6D5@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>, Marc Linsner <mlinsner@cisco.com>, ecrit <ecrit@ietf.org> Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8A= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <C69620E4.191F3%mlinsner@cisco.com> <EDC0A1AE77C57744B664A310A0B23AE2070BE6D5@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Jul 2009 17:02:20 -0000 =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of DRAGE, Keith (Keith) > Sent: 30 July 2009 09:01 > To: Marc Linsner; 'ecrit' > Subject: Re: [Ecrit] HUM on PhoneBCP >=20 > I don't agree. > =20 > Some background. > =20 > There was a set of comments provided by Stephen Edge on 5th=20 > February 2009. I can find no response to that set of comments=20 > on the mailing list. > =20 > The gist of that set of comments was that phonebcp claims to=20 > cover all access technologies and it identified a significant=20 > number of requirements within phonebcp that the author=20 > considered were not requirements on 3GPP accesses. > =20 > So my position is that the document is not ready because all=20 > the valid comments on the document were not addressed. > =20 > There are two ways of dealing with this set of comments: > =20 > - going through and modifying all the identified=20 > requirements where the comment is upheld. > =20 > - making more clear in the abstract and / or introduction=20 > that this is solely the view of IETF in regard to IP capable=20 > devices and that other organisations may specify other requirements. > =20 > I would note at this point that the current abstract says: > =20 > 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=20 > how devices, > networks and services should use such standards to make emergency > calls. >=20 > Because the two sentences follow each other, it implies that=20 > other SDOs that have efforts targetted at addressing these=20 > solutions are complicit in the requirements so stated, and=20 > this is untrue.=20 [JRE] I agree that this juxtaposition of statements is rather misleading, and would suggest we try to improve. In fact the only "other standards organization" responsible for "such standards" is ANSI/TIA, since LLDP-MED is the only normative reference (and I would argue that LLDP-MED is not specifically targeted at emergency calls). So perhaps we can reword the abstract to say "The IETF has efforts..." John Certainly the current status of this document=20 > as addressed by various informal 3GPP discussions is to=20 > ensure that things do not fall apart in entities using the=20 > 3GPP mechanisms, however 3GPP devices do not use these=20 > requirements (no do these requirements represent the 3GPP requires. > =20 > One solution to the issue would just be to make much clearer=20 > which SDOs have participated in this work and which have not=20 > and the status of that progress - however that was also what=20 > people keep calling the "applicability statement" was trying to do. > =20 > regards > =20 > Keith > =20 > =20 >=20 >=20 > ________________________________ >=20 > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner > Sent: Wednesday, July 29, 2009 2:53 PM > To: 'ecrit' > Subject: [Ecrit] HUM on PhoneBCP > =09 > =09 > During today's meeting there was discussion as to why=20 > the chairs Publication Requested PhoneBCP version 13 when=20 > there are unresolved issues. This discussion led us to call=20 > for a hum. We are now asking the same question on the list. > =09 > Do you agree or disagree that PhoneBCP -13 is ready to=20 > Publication Request? > =09 > Please respond by close of business on Wednesday August 5th. > =09 > Thanks, > =09 > Marc & Hannes > =09 >=20 >=20 From br@brianrosen.net Thu Jul 30 10:15:36 2009 Return-Path: <br@brianrosen.net> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F35D3A6BE0 for <ecrit@core3.amsl.com>; Thu, 30 Jul 2009 10:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 l84MaEW5sEwE for <ecrit@core3.amsl.com>; Thu, 30 Jul 2009 10:15:35 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 5AFDA3A68E8 for <ecrit@ietf.org>; Thu, 30 Jul 2009 10:15:35 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from <br@brianrosen.net>) id 1MWZDx-0005yB-VE; Thu, 30 Jul 2009 12:15:26 -0500 From: "Brian Rosen" <br@brianrosen.net> To: "'Elwell, John'" <john.elwell@siemens-enterprise.com>, "'DRAGE, Keith \(Keith\)'" <drage@alcatel-lucent.com>, "'Marc Linsner'" <mlinsner@cisco.com>, "'ecrit'" <ecrit@ietf.org> References: <C69620E4.191F3%mlinsner@cisco.com> <EDC0A1AE77C57744B664A310A0B23AE2070BE6D5@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net> Date: Thu, 30 Jul 2009 13:15:28 -0400 Message-ID: <000901ca1139$590fb490$0b2f1db0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8A== Content-Language: en-us 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] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Jul 2009 17:15:36 -0000 The IETF does work targeted to the Internet. Other SDOs do work on different kinds of networks other than the Internet. The document describes best current practice for emergency calls on the Internet. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Elwell, John > Sent: Thursday, July 30, 2009 1:02 PM > To: DRAGE, Keith (Keith); Marc Linsner; ecrit > Subject: Re: [Ecrit] HUM on PhoneBCP > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of DRAGE, Keith (Keith) > > Sent: 30 July 2009 09:01 > > To: Marc Linsner; 'ecrit' > > Subject: Re: [Ecrit] HUM on PhoneBCP > > > > I don't agree. > > > > Some background. > > > > There was a set of comments provided by Stephen Edge on 5th > > February 2009. I can find no response to that set of comments > > on the mailing list. > > > > The gist of that set of comments was that phonebcp claims to > > cover all access technologies and it identified a significant > > number of requirements within phonebcp that the author > > considered were not requirements on 3GPP accesses. > > > > So my position is that the document is not ready because all > > the valid comments on the document were not addressed. > > > > There are two ways of dealing with this set of comments: > > > > - going through and modifying all the identified > > requirements where the comment is upheld. > > > > - making more clear in the abstract and / or introduction > > that this is solely the view of IETF in regard to IP capable > > devices and that other organisations may specify other requirements. > > > > I would note at this point that the current abstract says: > > > > 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. > > > > Because the two sentences follow each other, it implies that > > other SDOs that have efforts targetted at addressing these > > solutions are complicit in the requirements so stated, and > > this is untrue. > [JRE] I agree that this juxtaposition of statements is rather > misleading, and would suggest we try to improve. In fact the only > "other > standards organization" responsible for "such standards" is ANSI/TIA, > since LLDP-MED is the only normative reference (and I would argue that > LLDP-MED is not specifically targeted at emergency calls). So perhaps > we > can reword the abstract to say "The IETF has efforts..." > > John > > > Certainly the current status of this document > > as addressed by various informal 3GPP discussions is to > > ensure that things do not fall apart in entities using the > > 3GPP mechanisms, however 3GPP devices do not use these > > requirements (no do these requirements represent the 3GPP requires. > > > > One solution to the issue would just be to make much clearer > > which SDOs have participated in this work and which have not > > and the status of that progress - however that was also what > > people keep calling the "applicability statement" was trying to do. > > > > regards > > > > Keith > > > > > > > > > > ________________________________ > > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner > > Sent: Wednesday, July 29, 2009 2:53 PM > > To: 'ecrit' > > Subject: [Ecrit] HUM on PhoneBCP > > > > > > During today's meeting there was discussion as to why > > the chairs Publication Requested PhoneBCP version 13 when > > there are unresolved issues. This discussion led us to call > > for a hum. We are now asking the same question on the list. > > > > Do you agree or disagree that PhoneBCP -13 is ready to > > Publication Request? > > > > Please respond by close of business on Wednesday August 5th. > > > > Thanks, > > > > Marc & Hannes > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From john.elwell@siemens-enterprise.com Thu Jul 30 12:25:36 2009 Return-Path: <john.elwell@siemens-enterprise.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CAA83A723B for <ecrit@core3.amsl.com>; Thu, 30 Jul 2009 12:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 uA2bdblVKPd6 for <ecrit@core3.amsl.com>; Thu, 30 Jul 2009 12:25:35 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 6DA113A71EA for <ecrit@ietf.org>; Thu, 30 Jul 2009 12:25:34 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KNM0080M0MKAW@siemenscomms.co.uk> for ecrit@ietf.org; Thu, 30 Jul 2009 20:25:32 +0100 (BST) Date: Thu, 30 Jul 2009 20:25:18 +0100 From: "Elwell, John" <john.elwell@siemens-enterprise.com> In-reply-to: <000901ca1139$590fb490$0b2f1db0$@net> To: Brian Rosen <br@brianrosen.net>, "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>, Marc Linsner <mlinsner@cisco.com>, ecrit <ecrit@ietf.org> Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00233D3F7@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAEeNJg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <C69620E4.191F3%mlinsner@cisco.com> <EDC0A1AE77C57744B664A310A0B23AE2070BE6D5@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net> <000901ca1139$590fb490$0b2f1db0$@net> Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Jul 2009 19:25:36 -0000 Brian, Agreed. But the current reference to other SDOs in the abstract is misleading. The ecrit-framework makes no such reference. It simply says "The IETF has standardized various aspects of placing emergency calls." So why include that controversial statement in the phone BCP? John > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: 30 July 2009 18:15 > To: Elwell, John; 'DRAGE, Keith (Keith)'; 'Marc Linsner'; 'ecrit' > Subject: RE: [Ecrit] HUM on PhoneBCP >=20 > The IETF does work targeted to the Internet. Other SDOs do=20 > work on different > kinds of networks other than the Internet. The document=20 > describes best > current practice for emergency calls on the Internet. >=20 > Brian >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Elwell, John > > Sent: Thursday, July 30, 2009 1:02 PM > > To: DRAGE, Keith (Keith); Marc Linsner; ecrit > > Subject: Re: [Ecrit] HUM on PhoneBCP > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > > On Behalf Of DRAGE, Keith (Keith) > > > Sent: 30 July 2009 09:01 > > > To: Marc Linsner; 'ecrit' > > > Subject: Re: [Ecrit] HUM on PhoneBCP > > > > > > I don't agree. > > > > > > Some background. > > > > > > There was a set of comments provided by Stephen Edge on 5th > > > February 2009. I can find no response to that set of comments > > > on the mailing list. > > > > > > The gist of that set of comments was that phonebcp claims to > > > cover all access technologies and it identified a significant > > > number of requirements within phonebcp that the author > > > considered were not requirements on 3GPP accesses. > > > > > > So my position is that the document is not ready because all > > > the valid comments on the document were not addressed. > > > > > > There are two ways of dealing with this set of comments: > > > > > > - going through and modifying all the identified > > > requirements where the comment is upheld. > > > > > > - making more clear in the abstract and / or introduction > > > that this is solely the view of IETF in regard to IP capable > > > devices and that other organisations may specify other=20 > requirements. > > > > > > I would note at this point that the current abstract says: > > > > > > The IETF and other standards organization have efforts=20 > 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=20 > make emergency > > > calls. > > > > > > Because the two sentences follow each other, it implies that > > > other SDOs that have efforts targetted at addressing these > > > solutions are complicit in the requirements so stated, and > > > this is untrue. > > [JRE] I agree that this juxtaposition of statements is rather > > misleading, and would suggest we try to improve. In fact the only > > "other > > standards organization" responsible for "such standards"=20 > is ANSI/TIA, > > since LLDP-MED is the only normative reference (and I would=20 > argue that > > LLDP-MED is not specifically targeted at emergency calls).=20 > So perhaps > > we > > can reword the abstract to say "The IETF has efforts..." > >=20 > > John > >=20 > >=20 > > Certainly the current status of this document > > > as addressed by various informal 3GPP discussions is to > > > ensure that things do not fall apart in entities using the > > > 3GPP mechanisms, however 3GPP devices do not use these > > > requirements (no do these requirements represent the 3GPP=20 > requires. > > > > > > One solution to the issue would just be to make much clearer > > > which SDOs have participated in this work and which have not > > > and the status of that progress - however that was also what > > > people keep calling the "applicability statement" was=20 > trying to do. > > > > > > regards > > > > > > Keith > > > > > > > > > > > > > > > ________________________________ > > > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner > > > Sent: Wednesday, July 29, 2009 2:53 PM > > > To: 'ecrit' > > > Subject: [Ecrit] HUM on PhoneBCP > > > > > > > > > During today's meeting there was discussion as to why > > > the chairs Publication Requested PhoneBCP version 13 when > > > there are unresolved issues. This discussion led us to call > > > for a hum. We are now asking the same question on the list. > > > > > > Do you agree or disagree that PhoneBCP -13 is ready to > > > Publication Request? > > > > > > Please respond by close of business on Wednesday August 5th. > > > > > > Thanks, > > > > > > Marc & Hannes > > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 From br@brianrosen.net Thu Jul 30 12:36:35 2009 Return-Path: <br@brianrosen.net> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71AAC3A6C0A for <ecrit@core3.amsl.com>; Thu, 30 Jul 2009 12:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 GRCMmJXrXUdO for <ecrit@core3.amsl.com>; Thu, 30 Jul 2009 12:36:34 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 51ED33A69F4 for <ecrit@ietf.org>; Thu, 30 Jul 2009 12:36:34 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from <br@brianrosen.net>) id 1MWbQO-0005zu-P6; Thu, 30 Jul 2009 14:36:25 -0500 From: "Brian Rosen" <br@brianrosen.net> To: "'Elwell, John'" <john.elwell@siemens-enterprise.com>, "'DRAGE, Keith \(Keith\)'" <drage@alcatel-lucent.com>, "'Marc Linsner'" <mlinsner@cisco.com>, "'ecrit'" <ecrit@ietf.org> References: <C69620E4.191F3%mlinsner@cisco.com> <EDC0A1AE77C57744B664A310A0B23AE2070BE6D5@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net> <000901ca1139$590fb490$0b2f1db0$@net> <0D5F89FAC29E2C41B98A6A762007F5D00233D3F7@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00233D3F7@GBNTHT12009MSX.gb002.siemens.net> Date: Thu, 30 Jul 2009 15:36:30 -0400 Message-ID: <003401ca114d$0c063d90$2412b8b0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAEeNJgAABt6UA= Content-Language: en-us 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] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Jul 2009 19:36:35 -0000 If it solves the problem, I don't have a problem with this edit. At the moment, we have a hum on the table. Let's let it run. If it fails, we can try things that might gain rough consensus. Unfortunately, the last time I tried to make edits to gain a wider consensus, my efforts actually backfired. Brian > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, July 30, 2009 3:25 PM > To: Brian Rosen; DRAGE, Keith (Keith); Marc Linsner; ecrit > Subject: RE: [Ecrit] HUM on PhoneBCP > > Brian, > > Agreed. But the current reference to other SDOs in the abstract is > misleading. The ecrit-framework makes no such reference. It simply says > "The IETF has standardized various aspects of placing emergency calls." > So why include that controversial statement in the phone BCP? > > John > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: 30 July 2009 18:15 > > To: Elwell, John; 'DRAGE, Keith (Keith)'; 'Marc Linsner'; 'ecrit' > > Subject: RE: [Ecrit] HUM on PhoneBCP > > > > The IETF does work targeted to the Internet. Other SDOs do > > work on different > > kinds of networks other than the Internet. The document > > describes best > > current practice for emergency calls on the Internet. > > > > Brian > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Elwell, John > > > Sent: Thursday, July 30, 2009 1:02 PM > > > To: DRAGE, Keith (Keith); Marc Linsner; ecrit > > > Subject: Re: [Ecrit] HUM on PhoneBCP > > > > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > > > On Behalf Of DRAGE, Keith (Keith) > > > > Sent: 30 July 2009 09:01 > > > > To: Marc Linsner; 'ecrit' > > > > Subject: Re: [Ecrit] HUM on PhoneBCP > > > > > > > > I don't agree. > > > > > > > > Some background. > > > > > > > > There was a set of comments provided by Stephen Edge on 5th > > > > February 2009. I can find no response to that set of comments > > > > on the mailing list. > > > > > > > > The gist of that set of comments was that phonebcp claims to > > > > cover all access technologies and it identified a significant > > > > number of requirements within phonebcp that the author > > > > considered were not requirements on 3GPP accesses. > > > > > > > > So my position is that the document is not ready because all > > > > the valid comments on the document were not addressed. > > > > > > > > There are two ways of dealing with this set of comments: > > > > > > > > - going through and modifying all the identified > > > > requirements where the comment is upheld. > > > > > > > > - making more clear in the abstract and / or introduction > > > > that this is solely the view of IETF in regard to IP capable > > > > devices and that other organisations may specify other > > requirements. > > > > > > > > I would note at this point that the current abstract says: > > > > > > > > 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. > > > > > > > > Because the two sentences follow each other, it implies that > > > > other SDOs that have efforts targetted at addressing these > > > > solutions are complicit in the requirements so stated, and > > > > this is untrue. > > > [JRE] I agree that this juxtaposition of statements is rather > > > misleading, and would suggest we try to improve. In fact the only > > > "other > > > standards organization" responsible for "such standards" > > is ANSI/TIA, > > > since LLDP-MED is the only normative reference (and I would > > argue that > > > LLDP-MED is not specifically targeted at emergency calls). > > So perhaps > > > we > > > can reword the abstract to say "The IETF has efforts..." > > > > > > John > > > > > > > > > Certainly the current status of this document > > > > as addressed by various informal 3GPP discussions is to > > > > ensure that things do not fall apart in entities using the > > > > 3GPP mechanisms, however 3GPP devices do not use these > > > > requirements (no do these requirements represent the 3GPP > > requires. > > > > > > > > One solution to the issue would just be to make much clearer > > > > which SDOs have participated in this work and which have not > > > > and the status of that progress - however that was also what > > > > people keep calling the "applicability statement" was > > trying to do. > > > > > > > > regards > > > > > > > > Keith > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner > > > > Sent: Wednesday, July 29, 2009 2:53 PM > > > > To: 'ecrit' > > > > Subject: [Ecrit] HUM on PhoneBCP > > > > > > > > > > > > During today's meeting there was discussion as to why > > > > the chairs Publication Requested PhoneBCP version 13 when > > > > there are unresolved issues. This discussion led us to call > > > > for a hum. We are now asking the same question on the list. > > > > > > > > Do you agree or disagree that PhoneBCP -13 is ready to > > > > Publication Request? > > > > > > > > Please respond by close of business on Wednesday August > 5th. > > > > > > > > Thanks, > > > > > > > > Marc & Hannes > > > > > > > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > From john.elwell@siemens-enterprise.com Thu Jul 30 12:41:16 2009 Return-Path: <john.elwell@siemens-enterprise.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8F9528C27F for <ecrit@core3.amsl.com>; Thu, 30 Jul 2009 12:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 St6mBl4Put6q for <ecrit@core3.amsl.com>; Thu, 30 Jul 2009 12:41:15 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 1B57928C234 for <ecrit@ietf.org>; Thu, 30 Jul 2009 12:41:15 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KNM0098R1CS68@siemenscomms.co.uk> for ecrit@ietf.org; Thu, 30 Jul 2009 20:41:16 +0100 (BST) Date: Thu, 30 Jul 2009 20:40:59 +0100 From: "Elwell, John" <john.elwell@siemens-enterprise.com> In-reply-to: <003401ca114d$0c063d90$2412b8b0$@net> To: Brian Rosen <br@brianrosen.net>, "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>, Marc Linsner <mlinsner@cisco.com>, ecrit <ecrit@ietf.org> Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00233D3FD@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAEeNJgAABt6UAAACt3MA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <C69620E4.191F3%mlinsner@cisco.com> <EDC0A1AE77C57744B664A310A0B23AE2070BE6D5@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net> <000901ca1139$590fb490$0b2f1db0$@net> <0D5F89FAC29E2C41B98A6A762007F5D00233D3F7@GBNTHT12009MSX.gb002.siemens.net> <003401ca114d$0c063d90$2412b8b0$@net> Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Jul 2009 19:41:16 -0000 Brian, Yes, understood. I was going to vote "yes", but seeing this particular point raised by Keith I felt the Abstract needed to be corrected. I didn't think it fair to vote "no" without making a proposal how to fix my concern. John > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: 30 July 2009 20:37 > To: Elwell, John; 'DRAGE, Keith (Keith)'; 'Marc Linsner'; 'ecrit' > Subject: RE: [Ecrit] HUM on PhoneBCP >=20 > If it solves the problem, I don't have a problem with this=20 > edit. At the > moment, we have a hum on the table. Let's let it run. If it=20 > fails, we can > try things that might gain rough consensus. >=20 > Unfortunately, the last time I tried to make edits to gain a wider > consensus, my efforts actually backfired. >=20 > Brian >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Thursday, July 30, 2009 3:25 PM > > To: Brian Rosen; DRAGE, Keith (Keith); Marc Linsner; ecrit > > Subject: RE: [Ecrit] HUM on PhoneBCP > >=20 > > Brian, > >=20 > > Agreed. But the current reference to other SDOs in the abstract is > > misleading. The ecrit-framework makes no such reference. It=20 > simply says > > "The IETF has standardized various aspects of placing=20 > emergency calls." > > So why include that controversial statement in the phone BCP? > >=20 > > John > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: 30 July 2009 18:15 > > > To: Elwell, John; 'DRAGE, Keith (Keith)'; 'Marc Linsner'; 'ecrit' > > > Subject: RE: [Ecrit] HUM on PhoneBCP > > > > > > The IETF does work targeted to the Internet. Other SDOs do > > > work on different > > > kinds of networks other than the Internet. The document > > > describes best > > > current practice for emergency calls on the Internet. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of Elwell, John > > > > Sent: Thursday, July 30, 2009 1:02 PM > > > > To: DRAGE, Keith (Keith); Marc Linsner; ecrit > > > > Subject: Re: [Ecrit] HUM on PhoneBCP > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > > > > On Behalf Of DRAGE, Keith (Keith) > > > > > Sent: 30 July 2009 09:01 > > > > > To: Marc Linsner; 'ecrit' > > > > > Subject: Re: [Ecrit] HUM on PhoneBCP > > > > > > > > > > I don't agree. > > > > > > > > > > Some background. > > > > > > > > > > There was a set of comments provided by Stephen Edge on 5th > > > > > February 2009. I can find no response to that set of comments > > > > > on the mailing list. > > > > > > > > > > The gist of that set of comments was that phonebcp claims to > > > > > cover all access technologies and it identified a significant > > > > > number of requirements within phonebcp that the author > > > > > considered were not requirements on 3GPP accesses. > > > > > > > > > > So my position is that the document is not ready because all > > > > > the valid comments on the document were not addressed. > > > > > > > > > > There are two ways of dealing with this set of comments: > > > > > > > > > > - going through and modifying all the identified > > > > > requirements where the comment is upheld. > > > > > > > > > > - making more clear in the abstract and / or introduction > > > > > that this is solely the view of IETF in regard to IP capable > > > > > devices and that other organisations may specify other > > > requirements. > > > > > > > > > > I would note at this point that the current abstract says: > > > > > > > > > > The IETF and other standards organization have efforts > > > targeted at > > > > > standardizing various aspects of placing emergency=20 > calls on IP > > > > > networks. This memo describes best current practice on > > > > > how devices, > > > > > networks and services should use such standards to > > > make emergency > > > > > calls. > > > > > > > > > > Because the two sentences follow each other, it implies that > > > > > other SDOs that have efforts targetted at addressing these > > > > > solutions are complicit in the requirements so stated, and > > > > > this is untrue. > > > > [JRE] I agree that this juxtaposition of statements is rather > > > > misleading, and would suggest we try to improve. In=20 > fact the only > > > > "other > > > > standards organization" responsible for "such standards" > > > is ANSI/TIA, > > > > since LLDP-MED is the only normative reference (and I would > > > argue that > > > > LLDP-MED is not specifically targeted at emergency calls). > > > So perhaps > > > > we > > > > can reword the abstract to say "The IETF has efforts..." > > > > > > > > John > > > > > > > > > > > > Certainly the current status of this document > > > > > as addressed by various informal 3GPP discussions is to > > > > > ensure that things do not fall apart in entities using the > > > > > 3GPP mechanisms, however 3GPP devices do not use these > > > > > requirements (no do these requirements represent the 3GPP > > > requires. > > > > > > > > > > One solution to the issue would just be to make much clearer > > > > > which SDOs have participated in this work and which have not > > > > > and the status of that progress - however that was also what > > > > > people keep calling the "applicability statement" was > > > trying to do. > > > > > > > > > > regards > > > > > > > > > > Keith > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner > > > > > Sent: Wednesday, July 29, 2009 2:53 PM > > > > > To: 'ecrit' > > > > > Subject: [Ecrit] HUM on PhoneBCP > > > > > > > > > > > > > > > During today's meeting there was discussion as to why > > > > > the chairs Publication Requested PhoneBCP version 13 when > > > > > there are unresolved issues. This discussion led us to call > > > > > for a hum. We are now asking the same question on the list. > > > > > > > > > > Do you agree or disagree that PhoneBCP -13 is ready to > > > > > Publication Request? > > > > > > > > > > Please respond by close of business on Wednesday August > > 5th. > > > > > > > > > > Thanks, > > > > > > > > > > Marc & Hannes > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > >=20 >=20 From drage@alcatel-lucent.com Thu Jul 30 13:13:00 2009 Return-Path: <drage@alcatel-lucent.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 434733A6C85 for <ecrit@core3.amsl.com>; Thu, 30 Jul 2009 13:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.481 X-Spam-Level: X-Spam-Status: No, score=-5.481 tagged_above=-999 required=5 tests=[AWL=0.768, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 63nZuKTh7DHG for <ecrit@core3.amsl.com>; Thu, 30 Jul 2009 13:12:59 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id DA9CB3A6A4E for <ecrit@ietf.org>; Thu, 30 Jul 2009 13:12:58 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n6UKCpdd010271 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Jul 2009 22:12:52 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 30 Jul 2009 22:12:51 +0200 From: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com> To: Brian Rosen <br@brianrosen.net>, "'Elwell, John'" <john.elwell@siemens-enterprise.com>, "'Marc Linsner'" <mlinsner@cisco.com>, "'ecrit'" <ecrit@ietf.org> Date: Thu, 30 Jul 2009 22:12:50 +0200 Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAA2Vmw Message-ID: <EDC0A1AE77C57744B664A310A0B23AE2070BE83A@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> References: <C69620E4.191F3%mlinsner@cisco.com> <EDC0A1AE77C57744B664A310A0B23AE2070BE6D5@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net> <000901ca1139$590fb490$0b2f1db0$@net> In-Reply-To: <000901ca1139$590fb490$0b2f1db0$@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Jul 2009 20:13:00 -0000 I don't believe you can use the word "Internet" to target a distinct scope = of phonebcp from other SDOs work in this area.=20 But I'll follow the argument through if you really want. Which well known d= efinition of internet are you using so we start from a common baseline? regards Keith > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Thursday, July 30, 2009 6:15 PM > To: 'Elwell, John'; DRAGE, Keith (Keith); 'Marc Linsner'; 'ecrit' > Subject: RE: [Ecrit] HUM on PhoneBCP >=20 > The IETF does work targeted to the Internet. Other SDOs do=20 > work on different kinds of networks other than the Internet. =20 > The document describes best current practice for emergency=20 > calls on the Internet. >=20 > Brian >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > > Of Elwell, John > > Sent: Thursday, July 30, 2009 1:02 PM > > To: DRAGE, Keith (Keith); Marc Linsner; ecrit > > Subject: Re: [Ecrit] HUM on PhoneBCP > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > > > Behalf Of DRAGE, Keith (Keith) > > > Sent: 30 July 2009 09:01 > > > To: Marc Linsner; 'ecrit' > > > Subject: Re: [Ecrit] HUM on PhoneBCP > > > > > > I don't agree. > > > > > > Some background. > > > > > > There was a set of comments provided by Stephen Edge on=20 > 5th February=20 > > > 2009. I can find no response to that set of comments on=20 > the mailing=20 > > > list. > > > > > > The gist of that set of comments was that phonebcp claims=20 > to cover=20 > > > all access technologies and it identified a significant number of=20 > > > requirements within phonebcp that the author considered were not=20 > > > requirements on 3GPP accesses. > > > > > > So my position is that the document is not ready because all the=20 > > > valid comments on the document were not addressed. > > > > > > There are two ways of dealing with this set of comments: > > > > > > - going through and modifying all the identified > > > requirements where the comment is upheld. > > > > > > - making more clear in the abstract and / or introduction > > > that this is solely the view of IETF in regard to IP=20 > capable devices=20 > > > and that other organisations may specify other requirements. > > > > > > I would note at this point that the current abstract says: > > > > > > The IETF and other standards organization have efforts=20 > targeted at > > > standardizing various aspects of placing emergency calls on IP > > > networks. This memo describes best current practice on how=20 > > > devices, > > > networks and services should use such standards to=20 > make emergency > > > calls. > > > > > > Because the two sentences follow each other, it implies=20 > that other=20 > > > SDOs that have efforts targetted at addressing these=20 > solutions are=20 > > > complicit in the requirements so stated, and this is untrue. > > [JRE] I agree that this juxtaposition of statements is rather=20 > > misleading, and would suggest we try to improve. In fact the only=20 > > "other standards organization" responsible for "such standards" is=20 > > ANSI/TIA, since LLDP-MED is the only normative reference=20 > (and I would=20 > > argue that LLDP-MED is not specifically targeted at=20 > emergency calls).=20 > > So perhaps we can reword the abstract to say "The IETF has=20 > efforts..." > >=20 > > John > >=20 > >=20 > > Certainly the current status of this document > > > as addressed by various informal 3GPP discussions is to=20 > ensure that=20 > > > things do not fall apart in entities using the 3GPP mechanisms,=20 > > > however 3GPP devices do not use these requirements (no do these=20 > > > requirements represent the 3GPP requires. > > > > > > One solution to the issue would just be to make much=20 > clearer which=20 > > > SDOs have participated in this work and which have not and the=20 > > > status of that progress - however that was also what people keep=20 > > > calling the "applicability statement" was trying to do. > > > > > > regards > > > > > > Keith > > > > > > > > > > > > > > > ________________________________ > > > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner > > > Sent: Wednesday, July 29, 2009 2:53 PM > > > To: 'ecrit' > > > Subject: [Ecrit] HUM on PhoneBCP > > > > > > > > > During today's meeting there was discussion as to why=20 > the chairs=20 > > > Publication Requested PhoneBCP version 13 when there are=20 > unresolved=20 > > > issues. This discussion led us to call for a hum. We are now=20 > > > asking the same question on the list. > > > > > > Do you agree or disagree that PhoneBCP -13 is ready to=20 > Publication=20 > > > Request? > > > > > > Please respond by close of business on Wednesday August 5th. > > > > > > Thanks, > > > > > > Marc & Hannes > > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > = From br@brianrosen.net Thu Jul 30 13:22:33 2009 Return-Path: <br@brianrosen.net> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0EA3A70EB for <ecrit@core3.amsl.com>; Thu, 30 Jul 2009 13:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 HEBXDEYe51pi for <ecrit@core3.amsl.com>; Thu, 30 Jul 2009 13:22:32 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id E35E83A7016 for <ecrit@ietf.org>; Thu, 30 Jul 2009 13:22:31 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from <br@brianrosen.net>) id 1MWc8s-00006o-4g; Thu, 30 Jul 2009 15:22:22 -0500 From: "Brian Rosen" <br@brianrosen.net> To: "'DRAGE, Keith \(Keith\)'" <drage@alcatel-lucent.com>, "'Elwell, John'" <john.elwell@siemens-enterprise.com>, "'Marc Linsner'" <mlinsner@cisco.com>, "'ecrit'" <ecrit@ietf.org> References: <C69620E4.191F3%mlinsner@cisco.com> <EDC0A1AE77C57744B664A310A0B23AE2070BE6D5@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net> <000901ca1139$590fb490$0b2f1db0$@net> <EDC0A1AE77C57744B664A310A0B23AE2070BE83A@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE2070BE83A@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> Date: Thu, 30 Jul 2009 16:22:28 -0400 Message-ID: <003501ca1153$77db50e0$6791f2a0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAA2VmwAAWkIYA= Content-Language: en-us 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] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Jul 2009 20:22:33 -0000 I specified the Internet, and not an internet. Usually we mean the public Internet. I think we have a decent definition of that. It wouldn't cover, for example, a closed network like a IMS call on a cellular 3G network. Might include, however, something like a call on an IMS network from a nomading customer on some random public access network, depends. Anyway, I said I was willing to do the edit in a effort to gain consensus. Brian > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Thursday, July 30, 2009 4:13 PM > To: Brian Rosen; 'Elwell, John'; 'Marc Linsner'; 'ecrit' > Subject: RE: [Ecrit] HUM on PhoneBCP > > I don't believe you can use the word "Internet" to target a distinct > scope of phonebcp from other SDOs work in this area. > > But I'll follow the argument through if you really want. Which well > known definition of internet are you using so we start from a common > baseline? > > regards > > Keith > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, July 30, 2009 6:15 PM > > To: 'Elwell, John'; DRAGE, Keith (Keith); 'Marc Linsner'; 'ecrit' > > Subject: RE: [Ecrit] HUM on PhoneBCP > > > > The IETF does work targeted to the Internet. Other SDOs do > > work on different kinds of networks other than the Internet. > > The document describes best current practice for emergency > > calls on the Internet. > > > > Brian > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Elwell, John > > > Sent: Thursday, July 30, 2009 1:02 PM > > > To: DRAGE, Keith (Keith); Marc Linsner; ecrit > > > Subject: Re: [Ecrit] HUM on PhoneBCP > > > > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > > > Behalf Of DRAGE, Keith (Keith) > > > > Sent: 30 July 2009 09:01 > > > > To: Marc Linsner; 'ecrit' > > > > Subject: Re: [Ecrit] HUM on PhoneBCP > > > > > > > > I don't agree. > > > > > > > > Some background. > > > > > > > > There was a set of comments provided by Stephen Edge on > > 5th February > > > > 2009. I can find no response to that set of comments on > > the mailing > > > > list. > > > > > > > > The gist of that set of comments was that phonebcp claims > > to cover > > > > all access technologies and it identified a significant number of > > > > requirements within phonebcp that the author considered were not > > > > requirements on 3GPP accesses. > > > > > > > > So my position is that the document is not ready because all the > > > > valid comments on the document were not addressed. > > > > > > > > There are two ways of dealing with this set of comments: > > > > > > > > - going through and modifying all the identified > > > > requirements where the comment is upheld. > > > > > > > > - making more clear in the abstract and / or introduction > > > > that this is solely the view of IETF in regard to IP > > capable devices > > > > and that other organisations may specify other requirements. > > > > > > > > I would note at this point that the current abstract says: > > > > > > > > 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. > > > > > > > > Because the two sentences follow each other, it implies > > that other > > > > SDOs that have efforts targetted at addressing these > > solutions are > > > > complicit in the requirements so stated, and this is untrue. > > > [JRE] I agree that this juxtaposition of statements is rather > > > misleading, and would suggest we try to improve. In fact the only > > > "other standards organization" responsible for "such standards" is > > > ANSI/TIA, since LLDP-MED is the only normative reference > > (and I would > > > argue that LLDP-MED is not specifically targeted at > > emergency calls). > > > So perhaps we can reword the abstract to say "The IETF has > > efforts..." > > > > > > John > > > > > > > > > Certainly the current status of this document > > > > as addressed by various informal 3GPP discussions is to > > ensure that > > > > things do not fall apart in entities using the 3GPP mechanisms, > > > > however 3GPP devices do not use these requirements (no do these > > > > requirements represent the 3GPP requires. > > > > > > > > One solution to the issue would just be to make much > > clearer which > > > > SDOs have participated in this work and which have not and the > > > > status of that progress - however that was also what people keep > > > > calling the "applicability statement" was trying to do. > > > > > > > > regards > > > > > > > > Keith > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner > > > > Sent: Wednesday, July 29, 2009 2:53 PM > > > > To: 'ecrit' > > > > Subject: [Ecrit] HUM on PhoneBCP > > > > > > > > > > > > During today's meeting there was discussion as to why > > the chairs > > > > Publication Requested PhoneBCP version 13 when there are > > unresolved > > > > issues. This discussion led us to call for a hum. We are now > > > > asking the same question on the list. > > > > > > > > Do you agree or disagree that PhoneBCP -13 is ready to > > Publication > > > > Request? > > > > > > > > Please respond by close of business on Wednesday August > 5th. > > > > > > > > Thanks, > > > > > > > > Marc & Hannes > > > > > > > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > = From drage@alcatel-lucent.com Fri Jul 31 04:21:01 2009 Return-Path: <drage@alcatel-lucent.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F02C3A6D64 for <ecrit@core3.amsl.com>; Fri, 31 Jul 2009 04:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.533 X-Spam-Level: X-Spam-Status: No, score=-5.533 tagged_above=-999 required=5 tests=[AWL=0.716, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 NZjo5wXct7j8 for <ecrit@core3.amsl.com>; Fri, 31 Jul 2009 04:21:00 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 95E313A6CE7 for <ecrit@ietf.org>; Fri, 31 Jul 2009 04:20:59 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n6VBKpUH009433 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Jul 2009 13:20:52 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 31 Jul 2009 13:20:51 +0200 From: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com> To: Brian Rosen <br@brianrosen.net>, "'Elwell, John'" <john.elwell@siemens-enterprise.com>, "'Marc Linsner'" <mlinsner@cisco.com>, "'ecrit'" <ecrit@ietf.org> Date: Fri, 31 Jul 2009 13:19:48 +0200 Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAA2VmwAAWkIYAAF6e5AA== Message-ID: <EDC0A1AE77C57744B664A310A0B23AE2070BE8C9@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> References: <C69620E4.191F3%mlinsner@cisco.com> <EDC0A1AE77C57744B664A310A0B23AE2070BE6D5@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net> <000901ca1139$590fb490$0b2f1db0$@net> <EDC0A1AE77C57744B664A310A0B23AE2070BE83A@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <003501ca1153$77db50e0$6791f2a0$@net> In-Reply-To: <003501ca1153$77db50e0$6791f2a0$@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 31 Jul 2009 11:21:01 -0000 Just to outline one of the issues. Take any 3GPP GPRS enabled mobile phone where you have a browser open and i= t is browsing the general internet. In your understanding that would be a d= evice on the Internet.=20 However if the user attempts to make an emergency call from that device, 3G= PP specifies that certain things should happen if the user happens to press= the keys associated with making an emergency call, and the device then rec= ognises an emergency call. It then goes on to specify how the emergency cal= l is made from such a device. That set of procedures is not the same as spe= cified in phonebcp. In this case 3GPP assumes in their specifications that the 3GPP procedures = take precedence, and indeed most people would consider that for this partic= ular device, despite it being a device attached to the Internet, those proc= edures are the best first mechanism to attempt to make an emergency call. regards Keith > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Thursday, July 30, 2009 9:22 PM > To: DRAGE, Keith (Keith); 'Elwell, John'; 'Marc Linsner'; 'ecrit' > Subject: RE: [Ecrit] HUM on PhoneBCP >=20 > I specified the Internet, and not an internet. Usually we=20 > mean the public Internet. I think we have a decent=20 > definition of that. It wouldn't cover, for example, a closed=20 > network like a IMS call on a cellular 3G network. > Might include, however, something like a call on an IMS=20 > network from a nomading customer on some random public access=20 > network, depends. >=20 > Anyway, I said I was willing to do the edit in a effort to=20 > gain consensus. >=20 > Brian >=20 > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > Sent: Thursday, July 30, 2009 4:13 PM > > To: Brian Rosen; 'Elwell, John'; 'Marc Linsner'; 'ecrit' > > Subject: RE: [Ecrit] HUM on PhoneBCP > >=20 > > I don't believe you can use the word "Internet" to target a=20 > distinct=20 > > scope of phonebcp from other SDOs work in this area. > >=20 > > But I'll follow the argument through if you really want. Which well=20 > > known definition of internet are you using so we start from=20 > a common=20 > > baseline? > >=20 > > regards > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, July 30, 2009 6:15 PM > > > To: 'Elwell, John'; DRAGE, Keith (Keith); 'Marc Linsner'; 'ecrit' > > > Subject: RE: [Ecrit] HUM on PhoneBCP > > > > > > The IETF does work targeted to the Internet. Other SDOs=20 > do work on=20 > > > different kinds of networks other than the Internet. > > > The document describes best current practice for=20 > emergency calls on=20 > > > the Internet. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of Elwell, John > > > > Sent: Thursday, July 30, 2009 1:02 PM > > > > To: DRAGE, Keith (Keith); Marc Linsner; ecrit > > > > Subject: Re: [Ecrit] HUM on PhoneBCP > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On=20 > > > > > Behalf Of DRAGE, Keith (Keith) > > > > > Sent: 30 July 2009 09:01 > > > > > To: Marc Linsner; 'ecrit' > > > > > Subject: Re: [Ecrit] HUM on PhoneBCP > > > > > > > > > > I don't agree. > > > > > > > > > > Some background. > > > > > > > > > > There was a set of comments provided by Stephen Edge on > > > 5th February > > > > > 2009. I can find no response to that set of comments on > > > the mailing > > > > > list. > > > > > > > > > > The gist of that set of comments was that phonebcp claims > > > to cover > > > > > all access technologies and it identified a=20 > significant number=20 > > > > > of requirements within phonebcp that the author=20 > considered were=20 > > > > > not requirements on 3GPP accesses. > > > > > > > > > > So my position is that the document is not ready=20 > because all the=20 > > > > > valid comments on the document were not addressed. > > > > > > > > > > There are two ways of dealing with this set of comments: > > > > > > > > > > - going through and modifying all the identified > > > > > requirements where the comment is upheld. > > > > > > > > > > - making more clear in the abstract and / or introduction > > > > > that this is solely the view of IETF in regard to IP > > > capable devices > > > > > and that other organisations may specify other requirements. > > > > > > > > > > I would note at this point that the current abstract says: > > > > > > > > > > The IETF and other standards organization have efforts > > > targeted at > > > > > standardizing various aspects of placing emergency=20 > calls on IP > > > > > networks. This memo describes best current=20 > practice on how=20 > > > > > devices, > > > > > networks and services should use such standards to > > > make emergency > > > > > calls. > > > > > > > > > > Because the two sentences follow each other, it implies > > > that other > > > > > SDOs that have efforts targetted at addressing these > > > solutions are > > > > > complicit in the requirements so stated, and this is untrue. > > > > [JRE] I agree that this juxtaposition of statements is rather=20 > > > > misleading, and would suggest we try to improve. In=20 > fact the only=20 > > > > "other standards organization" responsible for "such=20 > standards"=20 > > > > is ANSI/TIA, since LLDP-MED is the only normative reference > > > (and I would > > > > argue that LLDP-MED is not specifically targeted at > > > emergency calls). > > > > So perhaps we can reword the abstract to say "The IETF has > > > efforts..." > > > > > > > > John > > > > > > > > > > > > Certainly the current status of this document > > > > > as addressed by various informal 3GPP discussions is to > > > ensure that > > > > > things do not fall apart in entities using the 3GPP=20 > mechanisms,=20 > > > > > however 3GPP devices do not use these requirements=20 > (no do these=20 > > > > > requirements represent the 3GPP requires. > > > > > > > > > > One solution to the issue would just be to make much > > > clearer which > > > > > SDOs have participated in this work and which have=20 > not and the=20 > > > > > status of that progress - however that was also what=20 > people keep=20 > > > > > calling the "applicability statement" was trying to do. > > > > > > > > > > regards > > > > > > > > > > Keith > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner > > > > > Sent: Wednesday, July 29, 2009 2:53 PM > > > > > To: 'ecrit' > > > > > Subject: [Ecrit] HUM on PhoneBCP > > > > > > > > > > > > > > > During today's meeting there was discussion as to why > > > the chairs > > > > > Publication Requested PhoneBCP version 13 when there are > > > unresolved > > > > > issues. This discussion led us to call for a hum. =20 > We are now=20 > > > > > asking the same question on the list. > > > > > > > > > > Do you agree or disagree that PhoneBCP -13 is ready to > > > Publication > > > > > Request? > > > > > > > > > > Please respond by close of business on Wednesday August > > 5th. > > > > > > > > > > Thanks, > > > > > > > > > > Marc & Hannes > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > =3D >=20 > = From James.Winterbottom@andrew.com Fri Jul 31 04:59:44 2009 Return-Path: <James.Winterbottom@andrew.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC2D93A6B27 for <ecrit@core3.amsl.com>; Fri, 31 Jul 2009 04:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.343 X-Spam-Level: X-Spam-Status: No, score=-1.343 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPbnoCUKS+z7 for <ecrit@core3.amsl.com>; Fri, 31 Jul 2009 04:59:43 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 5778C3A691A for <ecrit@ietf.org>; Fri, 31 Jul 2009 04:59:43 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_31_07_22_19 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 31 Jul 2009 07:22:19 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 06:59:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Jul 2009 06:55:17 -0500 Message-ID: <E51D5B15BFDEFD448F90BDD17D41CFF104A34456@AHQEX1.andrew.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAA2VmwAAWkIYAAF6e5AAAJBBMs References: <C69620E4.191F3%mlinsner@cisco.com><EDC0A1AE77C57744B664A310A0B23AE2070BE6D5@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com><0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net><000901ca1139$590fb490$0b2f1db0$@net><EDC0A1AE77C57744B664A310A0B23AE2070BE83A@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com><003501ca1153$77db50e0$6791f2a0$@net> <EDC0A1AE77C57744B664A310A0B23AE2070BE8C9@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> From: "Winterbottom, James" <James.Winterbottom@andrew.com> To: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>, "Brian Rosen" <br@brianrosen.net>, "Elwell, John" <john.elwell@siemens-enterprise.com>, "Marc Linsner" <mlinsner@cisco.com>, "ecrit" <ecrit@ietf.org> X-OriginalArrivalTime: 31 Jul 2009 11:59:44.0531 (UTC) FILETIME=[64CCFE30:01CA11D6] Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 31 Jul 2009 11:59:44 -0000 And Keith, just to be sure that we are being totally on the same page.=0D=0A=0D= =0AWhen the network is not in breach of net neutrality legislation, and it = is offering an open Internet service, and the SIP application on the device= makes an emergency call through the Internet VSP not using any voice servi= ce that MAY be offerred by the 3G/4G/DSL/Cable/Fibre provider, that phone B= CP will apply.=0D=0A=0D=0AUnless you say that it will never apply, I see no= need for any form of applicability statement.=0D=0A=0D=0ARegards=0D=0AJame= s=0D=0A=0D=0APS, I believe that the hum is saying is the document ready. I = don't believe that people need to rehash old ground over and over again.=0D= =0A=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: ecrit-bounces@ietf.org= on behalf of DRAGE, Keith (Keith)=0D=0ASent: Fri 7/31/2009 6:19 AM=0D=0ATo= : Brian Rosen; 'Elwell, John'; 'Marc Linsner'; 'ecrit'=0D=0ASubject: Re: [E= crit] HUM on PhoneBCP=0D=0A=20=0D=0AJust to outline one of the issues.=0D=0A=0D= =0ATake any 3GPP GPRS enabled mobile phone where you have a browser open an= d it is browsing the general internet. In your understanding that would be = a device on the Internet.=20=0D=0A=0D=0AHowever if the user attempts to mak= e an emergency call from that device, 3GPP specifies that certain things sh= ould happen if the user happens to press the keys associated with making an= emergency call, and the device then recognises an emergency call. It then = goes on to specify how the emergency call is made from such a device. That = set of procedures is not the same as specified in phonebcp.=0D=0A=0D=0AIn t= his case 3GPP assumes in their specifications that the 3GPP procedures take= precedence, and indeed most people would consider that for this particular= device, despite it being a device attached to the Internet, those procedur= es are the best first mechanism to attempt to make an emergency call.=0D=0A=0D= =0Aregards=0D=0A=0D=0AKeith=0D=0A=0D=0A> -----Original Message-----=0D=0A> = From: Brian Rosen [mailto:br@brianrosen.net]=20=0D=0A> Sent: Thursday, July= 30, 2009 9:22 PM=0D=0A> To: DRAGE, Keith (Keith); 'Elwell, John'; 'Marc Li= nsner'; 'ecrit'=0D=0A> Subject: RE: [Ecrit] HUM on PhoneBCP=0D=0A>=20=0D=0A= > I specified the Internet, and not an internet. Usually we=20=0D=0A> mean= the public Internet. I think we have a decent=20=0D=0A> definition of tha= t. It wouldn't cover, for example, a closed=20=0D=0A> network like a IMS = call on a cellular 3G network.=0D=0A> Might include, however, something lik= e a call on an IMS=20=0D=0A> network from a nomading customer on some rando= m public access=20=0D=0A> network, depends.=0D=0A>=20=0D=0A> Anyway, I said= I was willing to do the edit in a effort to=20=0D=0A> gain consensus.=0D=0A= >=20=0D=0A> Brian=0D=0A>=20=0D=0A> > -----Original Message-----=0D=0A> > Fr= om: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=0D=0A> > Sent: T= hursday, July 30, 2009 4:13 PM=0D=0A> > To: Brian Rosen; 'Elwell, John'; 'M= arc Linsner'; 'ecrit'=0D=0A> > Subject: RE: [Ecrit] HUM on PhoneBCP=0D=0A> = >=20=0D=0A> > I don't believe you can use the word "Internet" to target a =0D= =0A> distinct=20=0D=0A> > scope of phonebcp from other SDOs work in this ar= ea.=0D=0A> >=20=0D=0A> > But I'll follow the argument through if you really= want. Which well=20=0D=0A> > known definition of internet are you using so= we start from=20=0D=0A> a common=20=0D=0A> > baseline=3F=0D=0A> >=20=0D=0A= > > regards=0D=0A> >=20=0D=0A> > Keith=0D=0A> >=20=0D=0A> > > -----Original= Message-----=0D=0A> > > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A= > > > Sent: Thursday, July 30, 2009 6:15 PM=0D=0A> > > To: 'Elwell, John'; = DRAGE, Keith (Keith); 'Marc Linsner'; 'ecrit'=0D=0A> > > Subject: RE: [Ecri= t] HUM on PhoneBCP=0D=0A> > >=0D=0A> > > The IETF does work targeted to the= Internet. Other SDOs=20=0D=0A> do work on=20=0D=0A> > > different kinds of= networks other than the Internet.=0D=0A> > > The document describes best c= urrent practice for=20=0D=0A> emergency calls on=20=0D=0A> > > the Internet= =2E=0D=0A> > >=0D=0A> > > Brian=0D=0A> > >=0D=0A> > > > -----Original Messa= ge-----=0D=0A> > > > From: ecrit-bounces@ietf.org=0D=0A> > > [mailto:ecrit-= bounces@ietf.org] On Behalf=0D=0A> > > > Of Elwell, John=0D=0A> > > > Sent:= Thursday, July 30, 2009 1:02 PM=0D=0A> > > > To: DRAGE, Keith (Keith); Mar= c Linsner; ecrit=0D=0A> > > > Subject: Re: [Ecrit] HUM on PhoneBCP=0D=0A> >= > >=0D=0A> > > >=0D=0A> > > >=0D=0A> > > > > -----Original Message-----=0D= =0A> > > > > From: ecrit-bounces@ietf.org=20=0D=0A> [mailto:ecrit-bounces@i= etf.org] On=20=0D=0A> > > > > Behalf Of DRAGE, Keith (Keith)=0D=0A> > > > >= Sent: 30 July 2009 09:01=0D=0A> > > > > To: Marc Linsner; 'ecrit'=0D=0A> >= > > > Subject: Re: [Ecrit] HUM on PhoneBCP=0D=0A> > > > >=0D=0A> > > > > I= don't agree.=0D=0A> > > > >=0D=0A> > > > > Some background.=0D=0A> > > > >=0D= =0A> > > > > There was a set of comments provided by Stephen Edge on=0D=0A>= > > 5th February=0D=0A> > > > > 2009. I can find no response to that set o= f comments on=0D=0A> > > the mailing=0D=0A> > > > > list.=0D=0A> > > > >=0D= =0A> > > > > The gist of that set of comments was that phonebcp claims=0D=0A= > > > to cover=0D=0A> > > > > all access technologies and it identified a =0D= =0A> significant number=20=0D=0A> > > > > of requirements within phonebcp t= hat the author=20=0D=0A> considered were=20=0D=0A> > > > > not requirements= on 3GPP accesses.=0D=0A> > > > >=0D=0A> > > > > So my position is that the= document is not ready=20=0D=0A> because all the=20=0D=0A> > > > > valid co= mments on the document were not addressed.=0D=0A> > > > >=0D=0A> > > > > Th= ere are two ways of dealing with this set of comments:=0D=0A> > > > >=0D=0A= > > > > > - going through and modifying all the identified=0D=0A> > > > = > requirements where the comment is upheld.=0D=0A> > > > >=0D=0A> > > > > -= making more clear in the abstract and / or introduction=0D=0A> > > > > = that this is solely the view of IETF in regard to IP=0D=0A> > > capable dev= ices=0D=0A> > > > > and that other organisations may specify other requirem= ents.=0D=0A> > > > >=0D=0A> > > > > I would note at this point that the cur= rent abstract says:=0D=0A> > > > >=0D=0A> > > > > The IETF and other sta= ndards organization have efforts=0D=0A> > > targeted at=0D=0A> > > > > s= tandardizing various aspects of placing emergency=20=0D=0A> calls on IP=0D=0A= > > > > > networks. This memo describes best current=20=0D=0A> practice= on how=20=0D=0A> > > > > devices,=0D=0A> > > > > networks and services = should use such standards to=0D=0A> > > make emergency=0D=0A> > > > > ca= lls.=0D=0A> > > > >=0D=0A> > > > > Because the two sentences follow each ot= her, it implies=0D=0A> > > that other=0D=0A> > > > > SDOs that have efforts= targetted at addressing these=0D=0A> > > solutions are=0D=0A> > > > > comp= licit in the requirements so stated, and this is untrue.=0D=0A> > > > [JRE]= I agree that this juxtaposition of statements is rather=20=0D=0A> > > > mi= sleading, and would suggest we try to improve. In=20=0D=0A> fact the only =0D= =0A> > > > "other standards organization" responsible for "such=20=0D=0A> = standards"=20=0D=0A> > > > is ANSI/TIA, since LLDP-MED is the only normativ= e reference=0D=0A> > > (and I would=0D=0A> > > > argue that LLDP-MED is not= specifically targeted at=0D=0A> > > emergency calls).=0D=0A> > > > So perh= aps we can reword the abstract to say "The IETF has=0D=0A> > > efforts..."=0D= =0A> > > >=0D=0A> > > > John=0D=0A> > > >=0D=0A> > > >=0D=0A> > > > Certain= ly the current status of this document=0D=0A> > > > > as addressed by vario= us informal 3GPP discussions is to=0D=0A> > > ensure that=0D=0A> > > > > th= ings do not fall apart in entities using the 3GPP=20=0D=0A> mechanisms,=20=0D= =0A> > > > > however 3GPP devices do not use these requirements=20=0D=0A> (= no do these=20=0D=0A> > > > > requirements represent the 3GPP requires.=0D=0A= > > > > >=0D=0A> > > > > One solution to the issue would just be to make mu= ch=0D=0A> > > clearer which=0D=0A> > > > > SDOs have participated in this w= ork and which have=20=0D=0A> not and the=20=0D=0A> > > > > status of that p= rogress - however that was also what=20=0D=0A> people keep=20=0D=0A> > > > = > calling the "applicability statement" was trying to do.=0D=0A> > > > >=0D= =0A> > > > > regards=0D=0A> > > > >=0D=0A> > > > > Keith=0D=0A> > > > >=0D=0A= > > > > >=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > > > > ____________________= ____________=0D=0A> > > > >=0D=0A> > > > > =09From: ecrit-bounces@ietf.org=0D= =0A> > > > > [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner=0D=0A= > > > > > =09Sent: Wednesday, July 29, 2009 2:53 PM=0D=0A> > > > > =09To: '= ecrit'=0D=0A> > > > > =09Subject: [Ecrit] HUM on PhoneBCP=0D=0A> > > > >=0D= =0A> > > > >=0D=0A> > > > > =09During today's meeting there was discussion = as to why=0D=0A> > > the chairs=0D=0A> > > > > Publication Requested PhoneB= CP version 13 when there are=0D=0A> > > unresolved=0D=0A> > > > > issues. = This discussion led us to call for a hum. =20=0D=0A> We are now=20=0D=0A> >= > > > asking the same question on the list.=0D=0A> > > > >=0D=0A> > > > > = =09Do you agree or disagree that PhoneBCP -13 is ready to=0D=0A> > > Public= ation=0D=0A> > > > > Request=3F=0D=0A> > > > >=0D=0A> > > > > =09Please res= pond by close of business on Wednesday August=0D=0A> > 5th.=0D=0A> > > > >=0D= =0A> > > > > =09Thanks,=0D=0A> > > > >=0D=0A> > > > > =09Marc & Hannes=0D=0A= > > > > >=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > > > ______________________= _________________________=0D=0A> > > > Ecrit mailing list=0D=0A> > > > Ecri= t@ietf.org=0D=0A> > > > https://www.ietf.org/mailman/listinfo/ecrit=0D=0A> = > >=0D=0A> > > =3D=0D=0A>=20=0D=0A>=20=0D=0A_______________________________= ________________=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://w= ww.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A=0D=0A-----------------------= -------------------------------------------------------------------------=0D= =0AThis message is for the designated recipient only and may=0D=0Acontain p= rivileged, proprietary, or otherwise private information. =20=0D=0AIf you h= ave received it in error, please notify the sender=0D=0Aimmediately and del= ete the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0A[mf2]=0D=0A From drage@alcatel-lucent.com Fri Jul 31 06:10:32 2009 Return-Path: <drage@alcatel-lucent.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4B8F28C28B for <ecrit@core3.amsl.com>; Fri, 31 Jul 2009 06:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.577 X-Spam-Level: X-Spam-Status: No, score=-5.577 tagged_above=-999 required=5 tests=[AWL=0.672, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 yLR3j88xpY3C for <ecrit@core3.amsl.com>; Fri, 31 Jul 2009 06:10:31 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id C119428C259 for <ecrit@ietf.org>; Fri, 31 Jul 2009 06:10:30 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n6VDAKrp020562 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Jul 2009 15:10:21 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 31 Jul 2009 15:10:21 +0200 From: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com> To: "Winterbottom, James" <James.Winterbottom@andrew.com>, Brian Rosen <br@brianrosen.net>, "Elwell, John" <john.elwell@siemens-enterprise.com>, Marc Linsner <mlinsner@cisco.com>, ecrit <ecrit@ietf.org> Date: Fri, 31 Jul 2009 15:10:17 +0200 Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAA2VmwAAWkIYAAF6e5AAAJBBMsAAJL8nA= Message-ID: <EDC0A1AE77C57744B664A310A0B23AE2070BE8F4@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> References: <C69620E4.191F3%mlinsner@cisco.com><EDC0A1AE77C57744B664A310A0B23AE2070BE6D5@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com><0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net><000901ca1139$590fb490$0b2f1db0$@net><EDC0A1AE77C57744B664A310A0B23AE2070BE83A@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com><003501ca1153$77db50e0$6791f2a0$@net> <EDC0A1AE77C57744B664A310A0B23AE2070BE8C9@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <E51D5B15BFDEFD448F90BDD17D41CFF104A34456@AHQEX1.andrew.com> In-Reply-To: <E51D5B15BFDEFD448F90BDD17D41CFF104A34456@AHQEX1.andrew.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 31 Jul 2009 13:10:32 -0000 The phone will never be in breach of network neutrality legislation because= : i) in my understanding network neutrality legislation does not extend to th= e user interface (and indeed many regulatory issues are exempt from network= neutrality legislation). ii) any resultant emergency call on a GPRS phone without IMS will always be= made in the CS domain, and not over the IP domain, despite it being intern= et connected. IMS only becomes a requirement for emergency calls when you g= et to EPS with an advertised emergency call capability) which is why specif= ically I did not choose that example. However your implementation that ignores the requirements of 3GPP in this i= nstance can well be in breach of other regulatory requirements, depending o= n country. And at the moment we are not talking about proposed textual solutions, I am= pointing out why the current scoping of a document that claims it suits al= l phones on the Internet that Brian is suggesting is inappropriate. regards Keith > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 > Sent: Friday, July 31, 2009 12:55 PM > To: DRAGE, Keith (Keith); Brian Rosen; Elwell, John; Marc=20 > Linsner; ecrit > Subject: RE: [Ecrit] HUM on PhoneBCP >=20 > And Keith, just to be sure that we are being totally on the same page. >=20 > When the network is not in breach of net neutrality=20 > legislation, and it is offering an open Internet service, and=20 > the SIP application on the device makes an emergency call=20 > through the Internet VSP not using any voice service that MAY=20 > be offerred by the 3G/4G/DSL/Cable/Fibre provider, that phone=20 > BCP will apply. >=20 > Unless you say that it will never apply, I see no need for=20 > any form of applicability statement. >=20 > Regards > James >=20 > PS, I believe that the hum is saying is the document ready. I=20 > don't believe that people need to rehash old ground over and=20 > over again. >=20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of DRAGE, Keith (Keith) > Sent: Fri 7/31/2009 6:19 AM > To: Brian Rosen; 'Elwell, John'; 'Marc Linsner'; 'ecrit' > Subject: Re: [Ecrit] HUM on PhoneBCP > =20 > Just to outline one of the issues. >=20 > Take any 3GPP GPRS enabled mobile phone where you have a=20 > browser open and it is browsing the general internet. In your=20 > understanding that would be a device on the Internet.=20 >=20 > However if the user attempts to make an emergency call from=20 > that device, 3GPP specifies that certain things should happen=20 > if the user happens to press the keys associated with making=20 > an emergency call, and the device then recognises an=20 > emergency call. It then goes on to specify how the emergency=20 > call is made from such a device. That set of procedures is=20 > not the same as specified in phonebcp. >=20 > In this case 3GPP assumes in their specifications that the=20 > 3GPP procedures take precedence, and indeed most people would=20 > consider that for this particular device, despite it being a=20 > device attached to the Internet, those procedures are the=20 > best first mechanism to attempt to make an emergency call. >=20 > regards >=20 > Keith >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, July 30, 2009 9:22 PM > > To: DRAGE, Keith (Keith); 'Elwell, John'; 'Marc Linsner'; 'ecrit' > > Subject: RE: [Ecrit] HUM on PhoneBCP > >=20 > > I specified the Internet, and not an internet. Usually we mean the=20 > > public Internet. I think we have a decent definition of that. It=20 > > wouldn't cover, for example, a closed network like a IMS call on a=20 > > cellular 3G network. > > Might include, however, something like a call on an IMS=20 > network from a=20 > > nomading customer on some random public access network, depends. > >=20 > > Anyway, I said I was willing to do the edit in a effort to gain=20 > > consensus. > >=20 > > Brian > >=20 > > > -----Original Message----- > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > Sent: Thursday, July 30, 2009 4:13 PM > > > To: Brian Rosen; 'Elwell, John'; 'Marc Linsner'; 'ecrit' > > > Subject: RE: [Ecrit] HUM on PhoneBCP > > >=20 > > > I don't believe you can use the word "Internet" to target a > > distinct > > > scope of phonebcp from other SDOs work in this area. > > >=20 > > > But I'll follow the argument through if you really want.=20 > Which well=20 > > > known definition of internet are you using so we start from > > a common > > > baseline? > > >=20 > > > regards > > >=20 > > > Keith > > >=20 > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Thursday, July 30, 2009 6:15 PM > > > > To: 'Elwell, John'; DRAGE, Keith (Keith); 'Marc=20 > Linsner'; 'ecrit' > > > > Subject: RE: [Ecrit] HUM on PhoneBCP > > > > > > > > The IETF does work targeted to the Internet. Other SDOs > > do work on > > > > different kinds of networks other than the Internet. > > > > The document describes best current practice for > > emergency calls on > > > > the Internet. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Elwell, John > > > > > Sent: Thursday, July 30, 2009 1:02 PM > > > > > To: DRAGE, Keith (Keith); Marc Linsner; ecrit > > > > > Subject: Re: [Ecrit] HUM on PhoneBCP > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On > > > > > > Behalf Of DRAGE, Keith (Keith) > > > > > > Sent: 30 July 2009 09:01 > > > > > > To: Marc Linsner; 'ecrit' > > > > > > Subject: Re: [Ecrit] HUM on PhoneBCP > > > > > > > > > > > > I don't agree. > > > > > > > > > > > > Some background. > > > > > > > > > > > > There was a set of comments provided by Stephen Edge on > > > > 5th February > > > > > > 2009. I can find no response to that set of comments on > > > > the mailing > > > > > > list. > > > > > > > > > > > > The gist of that set of comments was that phonebcp claims > > > > to cover > > > > > > all access technologies and it identified a > > significant number > > > > > > of requirements within phonebcp that the author > > considered were > > > > > > not requirements on 3GPP accesses. > > > > > > > > > > > > So my position is that the document is not ready > > because all the > > > > > > valid comments on the document were not addressed. > > > > > > > > > > > > There are two ways of dealing with this set of comments: > > > > > > > > > > > > - going through and modifying all the identified > > > > > > requirements where the comment is upheld. > > > > > > > > > > > > - making more clear in the abstract and / or introduction > > > > > > that this is solely the view of IETF in regard to IP > > > > capable devices > > > > > > and that other organisations may specify other requirements. > > > > > > > > > > > > I would note at this point that the current abstract says: > > > > > > > > > > > > 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. > > > > > > > > > > > > Because the two sentences follow each other, it implies > > > > that other > > > > > > SDOs that have efforts targetted at addressing these > > > > solutions are > > > > > > complicit in the requirements so stated, and this is untrue. > > > > > [JRE] I agree that this juxtaposition of statements is rather=20 > > > > > misleading, and would suggest we try to improve. In > > fact the only > > > > > "other standards organization" responsible for "such > > standards"=20 > > > > > is ANSI/TIA, since LLDP-MED is the only normative reference > > > > (and I would > > > > > argue that LLDP-MED is not specifically targeted at > > > > emergency calls). > > > > > So perhaps we can reword the abstract to say "The IETF has > > > > efforts..." > > > > > > > > > > John > > > > > > > > > > > > > > > Certainly the current status of this document > > > > > > as addressed by various informal 3GPP discussions is to > > > > ensure that > > > > > > things do not fall apart in entities using the 3GPP > > mechanisms, > > > > > > however 3GPP devices do not use these requirements > > (no do these > > > > > > requirements represent the 3GPP requires. > > > > > > > > > > > > One solution to the issue would just be to make much > > > > clearer which > > > > > > SDOs have participated in this work and which have > > not and the > > > > > > status of that progress - however that was also what > > people keep > > > > > > calling the "applicability statement" was trying to do. > > > > > > > > > > > > regards > > > > > > > > > > > > Keith > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > From: ecrit-bounces@ietf.org > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner > > > > > > Sent: Wednesday, July 29, 2009 2:53 PM > > > > > > To: 'ecrit' > > > > > > Subject: [Ecrit] HUM on PhoneBCP > > > > > > > > > > > > > > > > > > During today's meeting there was discussion as to why > > > > the chairs > > > > > > Publication Requested PhoneBCP version 13 when there are > > > > unresolved > > > > > > issues. This discussion led us to call for a hum. =20 > > We are now > > > > > > asking the same question on the list. > > > > > > > > > > > > Do you agree or disagree that PhoneBCP -13 is ready to > > > > Publication > > > > > > Request? > > > > > > > > > > > > Please respond by close of business on Wednesday August > > > 5th. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Marc & Hannes > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > =3D > >=20 > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may=20 > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender=20 > immediately and delete the original. Any unauthorized use of=20 > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 > = From Martin.Dawson@andrew.com Fri Jul 31 06:26:14 2009 Return-Path: <Martin.Dawson@andrew.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC6B83A6B13 for <ecrit@core3.amsl.com>; Fri, 31 Jul 2009 06:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyfnuDlTGwce for <ecrit@core3.amsl.com>; Fri, 31 Jul 2009 06:26:13 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 97D3A3A686D for <ecrit@ietf.org>; Fri, 31 Jul 2009 06:26:13 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_31_08_48_49 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 31 Jul 2009 08:48:49 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 08:26:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Jul 2009 08:26:13 -0500 Message-ID: <EB921991A86A974C80EAFA46AD428E1E011F682C@aopex4.andrew.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM on PhoneBCP Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAA2VmwAAWkIYAAF6e5AAAL5/jO References: <C69620E4.191F3%mlinsner@cisco.com><EDC0A1AE77C57744B664A310A0B23AE2070BE6D5@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com><0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net><000901ca1139$590fb490$0b2f1db0$@net><EDC0A1AE77C57744B664A310A0B23AE2070BE83A@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com><003501ca1153$77db50e0$6791f2a0$@net> <EDC0A1AE77C57744B664A310A0B23AE2070BE8C9@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> From: "Dawson, Martin" <Martin.Dawson@andrew.com> To: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>, "Brian Rosen" <br@brianrosen.net>, "Elwell, John" <john.elwell@siemens-enterprise.com>, "Marc Linsner" <mlinsner@cisco.com>, "ecrit" <ecrit@ietf.org> X-OriginalArrivalTime: 31 Jul 2009 13:26:15.0055 (UTC) FILETIME=[7A9819F0:01CA11E2] Subject: Re: [Ecrit] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 31 Jul 2009 13:26:15 -0000 Keith,=0D=0A=0D=0AAre you saying that a laptop connected to a Verizon Mi-Fi= router on 3G or LTE access would, for some reason, not be able to execute = the emergency call procedures according to PhoneBCP or that there's somethi= ng inherent in those networks that prevent the procedures from being suppor= ted=3F Are 3GPP networks somehow "broken" with respect to being able to be = used as broadband Internet access=3F=0D=0A=0D=0AYou might as well argue tha= t the browser you were using couldn't use HTTP because the 3GPP network is = "special".=0D=0A=0D=0ATo attempt to say it doesn't apply because some other= specification says it can be done another way is a tautology. Either that = or it demonstrates a lack of understanding of what the ECRIT proposition is= and means.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message= -----=0D=0AFrom: ecrit-bounces@ietf.org on behalf of DRAGE, Keith (Keith)=0D= =0ASent: Fri 7/31/2009 9:19 PM=0D=0ATo: Brian Rosen; 'Elwell, John'; 'Marc = Linsner'; 'ecrit'=0D=0ASubject: Re: [Ecrit] HUM on PhoneBCP=0D=0A=20=0D=0AJ= ust to outline one of the issues.=0D=0A=0D=0ATake any 3GPP GPRS enabled mob= ile phone where you have a browser open and it is browsing the general inte= rnet. In your understanding that would be a device on the Internet.=20=0D=0A=0D= =0AHowever if the user attempts to make an emergency call from that device,= 3GPP specifies that certain things should happen if the user happens to pr= ess the keys associated with making an emergency call, and the device then = recognises an emergency call. It then goes on to specify how the emergency = call is made from such a device. That set of procedures is not the same as = specified in phonebcp.=0D=0A=0D=0AIn this case 3GPP assumes in their specif= ications that the 3GPP procedures take precedence, and indeed most people w= ould consider that for this particular device, despite it being a device at= tached to the Internet, those procedures are the best first mechanism to at= tempt to make an emergency call.=0D=0A=0D=0Aregards=0D=0A=0D=0AKeith=0D=0A=0D= =0A> -----Original Message-----=0D=0A> From: Brian Rosen [mailto:br@brianro= sen.net]=20=0D=0A> Sent: Thursday, July 30, 2009 9:22 PM=0D=0A> To: DRAGE, = Keith (Keith); 'Elwell, John'; 'Marc Linsner'; 'ecrit'=0D=0A> Subject: RE: = [Ecrit] HUM on PhoneBCP=0D=0A>=20=0D=0A> I specified the Internet, and not = an internet. Usually we=20=0D=0A> mean the public Internet. I think we ha= ve a decent=20=0D=0A> definition of that. It wouldn't cover, for example, = a closed=20=0D=0A> network like a IMS call on a cellular 3G network.=0D=0A= > Might include, however, something like a call on an IMS=20=0D=0A> network= from a nomading customer on some random public access=20=0D=0A> network, d= epends.=0D=0A>=20=0D=0A> Anyway, I said I was willing to do the edit in a e= ffort to=20=0D=0A> gain consensus.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A> = > -----Original Message-----=0D=0A> > From: DRAGE, Keith (Keith) [mailto:dr= age@alcatel-lucent.com]=0D=0A> > Sent: Thursday, July 30, 2009 4:13 PM=0D=0A= > > To: Brian Rosen; 'Elwell, John'; 'Marc Linsner'; 'ecrit'=0D=0A> > Subje= ct: RE: [Ecrit] HUM on PhoneBCP=0D=0A> >=20=0D=0A> > I don't believe you ca= n use the word "Internet" to target a=20=0D=0A> distinct=20=0D=0A> > scope = of phonebcp from other SDOs work in this area.=0D=0A> >=20=0D=0A> > But I'l= l follow the argument through if you really want. Which well=20=0D=0A> > kn= own definition of internet are you using so we start from=20=0D=0A> a commo= n=20=0D=0A> > baseline=3F=0D=0A> >=20=0D=0A> > regards=0D=0A> >=20=0D=0A> >= Keith=0D=0A> >=20=0D=0A> > > -----Original Message-----=0D=0A> > > From: B= rian Rosen [mailto:br@brianrosen.net]=0D=0A> > > Sent: Thursday, July 30, 2= 009 6:15 PM=0D=0A> > > To: 'Elwell, John'; DRAGE, Keith (Keith); 'Marc Lins= ner'; 'ecrit'=0D=0A> > > Subject: RE: [Ecrit] HUM on PhoneBCP=0D=0A> > >=0D= =0A> > > The IETF does work targeted to the Internet. Other SDOs=20=0D=0A> = do work on=20=0D=0A> > > different kinds of networks other than the Interne= t.=0D=0A> > > The document describes best current practice for=20=0D=0A> em= ergency calls on=20=0D=0A> > > the Internet.=0D=0A> > >=0D=0A> > > Brian=0D= =0A> > >=0D=0A> > > > -----Original Message-----=0D=0A> > > > From: ecrit-b= ounces@ietf.org=0D=0A> > > [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0A>= > > > Of Elwell, John=0D=0A> > > > Sent: Thursday, July 30, 2009 1:02 PM=0D= =0A> > > > To: DRAGE, Keith (Keith); Marc Linsner; ecrit=0D=0A> > > > Subje= ct: Re: [Ecrit] HUM on PhoneBCP=0D=0A> > > >=0D=0A> > > >=0D=0A> > > >=0D=0A= > > > > > -----Original Message-----=0D=0A> > > > > From: ecrit-bounces@iet= f.org=20=0D=0A> [mailto:ecrit-bounces@ietf.org] On=20=0D=0A> > > > > Behalf= Of DRAGE, Keith (Keith)=0D=0A> > > > > Sent: 30 July 2009 09:01=0D=0A> > >= > > To: Marc Linsner; 'ecrit'=0D=0A> > > > > Subject: Re: [Ecrit] HUM on P= honeBCP=0D=0A> > > > >=0D=0A> > > > > I don't agree.=0D=0A> > > > >=0D=0A> = > > > > Some background.=0D=0A> > > > >=0D=0A> > > > > There was a set of c= omments provided by Stephen Edge on=0D=0A> > > 5th February=0D=0A> > > > > = 2009. I can find no response to that set of comments on=0D=0A> > > the mail= ing=0D=0A> > > > > list.=0D=0A> > > > >=0D=0A> > > > > The gist of that set= of comments was that phonebcp claims=0D=0A> > > to cover=0D=0A> > > > > al= l access technologies and it identified a=20=0D=0A> significant number=20=0D= =0A> > > > > of requirements within phonebcp that the author=20=0D=0A> cons= idered were=20=0D=0A> > > > > not requirements on 3GPP accesses.=0D=0A> > >= > >=0D=0A> > > > > So my position is that the document is not ready=20=0D=0A= > because all the=20=0D=0A> > > > > valid comments on the document were not= addressed.=0D=0A> > > > >=0D=0A> > > > > There are two ways of dealing wit= h this set of comments:=0D=0A> > > > >=0D=0A> > > > > - going through an= d modifying all the identified=0D=0A> > > > > requirements where the commen= t is upheld.=0D=0A> > > > >=0D=0A> > > > > - making more clear in the ab= stract and / or introduction=0D=0A> > > > > that this is solely the view of= IETF in regard to IP=0D=0A> > > capable devices=0D=0A> > > > > and that ot= her organisations may specify other requirements.=0D=0A> > > > >=0D=0A> > >= > > I would note at this point that the current abstract says:=0D=0A> > > = > >=0D=0A> > > > > The IETF and other standards organization have effort= s=0D=0A> > > targeted at=0D=0A> > > > > standardizing various aspects of= placing emergency=20=0D=0A> calls on IP=0D=0A> > > > > networks. This = memo describes best current=20=0D=0A> practice on how=20=0D=0A> > > > > dev= ices,=0D=0A> > > > > networks and services should use such standards to=0D= =0A> > > make emergency=0D=0A> > > > > calls.=0D=0A> > > > >=0D=0A> > > = > > Because the two sentences follow each other, it implies=0D=0A> > > that= other=0D=0A> > > > > SDOs that have efforts targetted at addressing these=0D= =0A> > > solutions are=0D=0A> > > > > complicit in the requirements so stat= ed, and this is untrue.=0D=0A> > > > [JRE] I agree that this juxtaposition = of statements is rather=20=0D=0A> > > > misleading, and would suggest we tr= y to improve. In=20=0D=0A> fact the only=20=0D=0A> > > > "other standards o= rganization" responsible for "such=20=0D=0A> standards"=20=0D=0A> > > > is= ANSI/TIA, since LLDP-MED is the only normative reference=0D=0A> > > (and I= would=0D=0A> > > > argue that LLDP-MED is not specifically targeted at=0D=0A= > > > emergency calls).=0D=0A> > > > So perhaps we can reword the abstract = to say "The IETF has=0D=0A> > > efforts..."=0D=0A> > > >=0D=0A> > > > John=0D= =0A> > > >=0D=0A> > > >=0D=0A> > > > Certainly the current status of this d= ocument=0D=0A> > > > > as addressed by various informal 3GPP discussions is= to=0D=0A> > > ensure that=0D=0A> > > > > things do not fall apart in entit= ies using the 3GPP=20=0D=0A> mechanisms,=20=0D=0A> > > > > however 3GPP dev= ices do not use these requirements=20=0D=0A> (no do these=20=0D=0A> > > > >= requirements represent the 3GPP requires.=0D=0A> > > > >=0D=0A> > > > > On= e solution to the issue would just be to make much=0D=0A> > > clearer which=0D= =0A> > > > > SDOs have participated in this work and which have=20=0D=0A> n= ot and the=20=0D=0A> > > > > status of that progress - however that was als= o what=20=0D=0A> people keep=20=0D=0A> > > > > calling the "applicability s= tatement" was trying to do.=0D=0A> > > > >=0D=0A> > > > > regards=0D=0A> > = > > >=0D=0A> > > > > Keith=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > > > >=0D=0A= > > > > >=0D=0A> > > > > ________________________________=0D=0A> > > > >=0D= =0A> > > > > =09From: ecrit-bounces@ietf.org=0D=0A> > > > > [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Marc Linsner=0D=0A> > > > > =09Sent: Wednesda= y, July 29, 2009 2:53 PM=0D=0A> > > > > =09To: 'ecrit'=0D=0A> > > > > =09Su= bject: [Ecrit] HUM on PhoneBCP=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > > > >= =09During today's meeting there was discussion as to why=0D=0A> > > the ch= airs=0D=0A> > > > > Publication Requested PhoneBCP version 13 when there ar= e=0D=0A> > > unresolved=0D=0A> > > > > issues. This discussion led us to c= all for a hum. =20=0D=0A> We are now=20=0D=0A> > > > > asking the same ques= tion on the list.=0D=0A> > > > >=0D=0A> > > > > =09Do you agree or disagree= that PhoneBCP -13 is ready to=0D=0A> > > Publication=0D=0A> > > > > Reques= t=3F=0D=0A> > > > >=0D=0A> > > > > =09Please respond by close of business o= n Wednesday August=0D=0A> > 5th.=0D=0A> > > > >=0D=0A> > > > > =09Thanks,=0D= =0A> > > > >=0D=0A> > > > > =09Marc & Hannes=0D=0A> > > > >=0D=0A> > > > >=0D= =0A> > > > >=0D=0A> > > > _______________________________________________=0D= =0A> > > > Ecrit mailing list=0D=0A> > > > Ecrit@ietf.org=0D=0A> > > > http= s://www.ietf.org/mailman/listinfo/ecrit=0D=0A> > >=0D=0A> > > =3D=0D=0A> =0D= =0A>=20=0D=0A_______________________________________________=0D=0AEcrit mai= ling list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman/listinfo/ec= rit=0D=0A=0D=0A=0D=0A------------------------------------------------------= ------------------------------------------=0D=0AThis message is for the des= ignated recipient only and may=0D=0Acontain privileged, proprietary, or oth= erwise private information. =20=0D=0AIf you have received it in error, plea= se notify the sender=0D=0Aimmediately and delete the original. Any unautho= rized use of=0D=0Athis email is prohibited.=0D=0A--------------------------= ----------------------------------------------------------------------=0D=0A= [mf2]=0D=0A From br@brianrosen.net Fri Jul 31 16:59:55 2009 Return-Path: <br@brianrosen.net> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C9553A68AE for <ecrit@core3.amsl.com>; Fri, 31 Jul 2009 16:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 YIuZR4FTCw2w for <ecrit@core3.amsl.com>; Fri, 31 Jul 2009 16:59:54 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 8EFE33A67F6 for <ecrit@ietf.org>; Fri, 31 Jul 2009 16:59:53 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from <br@brianrosen.net>) id 1MX20i-0001IQ-Ai; Fri, 31 Jul 2009 18:59:41 -0500 From: "Brian Rosen" <br@brianrosen.net> To: "'DRAGE, Keith \(Keith\)'" <drage@alcatel-lucent.com>, "'Elwell, John'" <john.elwell@siemens-enterprise.com>, "'Marc Linsner'" <mlinsner@cisco.com>, "'ecrit'" <ecrit@ietf.org> References: <C69620E4.191F3%mlinsner@cisco.com> <EDC0A1AE77C57744B664A310A0B23AE2070BE6D5@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D00233D3C6@GBNTHT12009MSX.gb002.siemens.net> <000901ca1139$590fb490$0b2f1db0$@net> <EDC0A1AE77C57744B664A310A0B23AE2070BE83A@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <003501ca1153$77db50e0$6791f2a0$@net> <EDC0A1AE77C57744B664A310A0B23AE2070BE8C9@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE2070BE8C9@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> Date: Fri, 31 Jul 2009 19:59:50 -0400 Message-ID: <01a501ca123a$fe05da40$fa118ec0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoQU+coC6NYc3WK+Uu28WbYldIEKQACzXWAADVEo8AAATxJ8AAA2VmwAAWkIYAAF6e5AAAh8Yzg Content-Language: en-us 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] HUM on PhoneBCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 31 Jul 2009 23:59:55 -0000 Haha, yes, a browser, or even an app using the raw packet service in a 3GPP GPRS device is on the Internet, although there are some subtle differences (the DNS root for example), but then, a service using that raw packet interface to make, say, an IM to an emergency service would probably have to make use of the phonebcp procedures, a fact 3GPP is studiously ignoring. I would not go so far as to say most people would prefer the 3GPP specified procedures vs the IETF phonebcp procedures, especially if they understood the tradeoffs. However, a 3GPP mobile telephone service is not an Internet service, no matter how you stretch it. Brian > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Friday, July 31, 2009 7:20 AM > To: Brian Rosen; 'Elwell, John'; 'Marc Linsner'; 'ecrit' > Subject: RE: [Ecrit] HUM on PhoneBCP > > Just to outline one of the issues. > > Take any 3GPP GPRS enabled mobile phone where you have a browser open > and it is browsing the general internet. In your understanding that > would be a device on the Internet. > > However if the user attempts to make an emergency call from that > device, 3GPP specifies that certain things should happen if the user > happens to press the keys associated with making an emergency call, and > the device then recognises an emergency call. It then goes on to > specify how the emergency call is made from such a device. That set of > procedures is not the same as specified in phonebcp. > > In this case 3GPP assumes in their specifications that the 3GPP > procedures take precedence, and indeed most people would consider that > for this particular device, despite it being a device attached to the > Internet, those procedures are the best first mechanism to attempt to > make an emergency call. > > regards > > Keith > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, July 30, 2009 9:22 PM > > To: DRAGE, Keith (Keith); 'Elwell, John'; 'Marc Linsner'; 'ecrit' > > Subject: RE: [Ecrit] HUM on PhoneBCP > > > > I specified the Internet, and not an internet. Usually we > > mean the public Internet. I think we have a decent > > definition of that. It wouldn't cover, for example, a closed > > network like a IMS call on a cellular 3G network. > > Might include, however, something like a call on an IMS > > network from a nomading customer on some random public access > > network, depends. > > > > Anyway, I said I was willing to do the edit in a effort to > > gain consensus. > > > > Brian > > > > > -----Original Message----- > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > Sent: Thursday, July 30, 2009 4:13 PM > > > To: Brian Rosen; 'Elwell, John'; 'Marc Linsner'; 'ecrit' > > > Subject: RE: [Ecrit] HUM on PhoneBCP > > > > > > I don't believe you can use the word "Internet" to target a > > distinct > > > scope of phonebcp from other SDOs work in this area. > > > > > > But I'll follow the argument through if you really want. Which well > > > known definition of internet are you using so we start from > > a common > > > baseline? > > > > > > regards > > > > > > Keith > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Thursday, July 30, 2009 6:15 PM > > > > To: 'Elwell, John'; DRAGE, Keith (Keith); 'Marc Linsner'; 'ecrit' > > > > Subject: RE: [Ecrit] HUM on PhoneBCP > > > > > > > > The IETF does work targeted to the Internet. Other SDOs > > do work on > > > > different kinds of networks other than the Internet. > > > > The document describes best current practice for > > emergency calls on > > > > the Internet. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Elwell, John > > > > > Sent: Thursday, July 30, 2009 1:02 PM > > > > > To: DRAGE, Keith (Keith); Marc Linsner; ecrit > > > > > Subject: Re: [Ecrit] HUM on PhoneBCP > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On > > > > > > Behalf Of DRAGE, Keith (Keith) > > > > > > Sent: 30 July 2009 09:01 > > > > > > To: Marc Linsner; 'ecrit' > > > > > > Subject: Re: [Ecrit] HUM on PhoneBCP > > > > > > > > > > > > I don't agree. > > > > > > > > > > > > Some background. > > > > > > > > > > > > There was a set of comments provided by Stephen Edge on > > > > 5th February > > > > > > 2009. I can find no response to that set of comments on > > > > the mailing > > > > > > list. > > > > > > > > > > > > The gist of that set of comments was that phonebcp claims > > > > to cover > > > > > > all access technologies and it identified a > > significant number > > > > > > of requirements within phonebcp that the author > > considered were > > > > > > not requirements on 3GPP accesses. > > > > > > > > > > > > So my position is that the document is not ready > > because all the > > > > > > valid comments on the document were not addressed. > > > > > > > > > > > > There are two ways of dealing with this set of comments: > > > > > > > > > > > > - going through and modifying all the identified > > > > > > requirements where the comment is upheld. > > > > > > > > > > > > - making more clear in the abstract and / or introduction > > > > > > that this is solely the view of IETF in regard to IP > > > > capable devices > > > > > > and that other organisations may specify other requirements. > > > > > > > > > > > > I would note at this point that the current abstract says: > > > > > > > > > > > > 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. > > > > > > > > > > > > Because the two sentences follow each other, it implies > > > > that other > > > > > > SDOs that have efforts targetted at addressing these > > > > solutions are > > > > > > complicit in the requirements so stated, and this is untrue. > > > > > [JRE] I agree that this juxtaposition of statements is rather > > > > > misleading, and would suggest we try to improve. In > > fact the only > > > > > "other standards organization" responsible for "such > > standards" > > > > > is ANSI/TIA, since LLDP-MED is the only normative reference > > > > (and I would > > > > > argue that LLDP-MED is not specifically targeted at > > > > emergency calls). > > > > > So perhaps we can reword the abstract to say "The IETF has > > > > efforts..." > > > > > > > > > > John > > > > > > > > > > > > > > > Certainly the current status of this document > > > > > > as addressed by various informal 3GPP discussions is to > > > > ensure that > > > > > > things do not fall apart in entities using the 3GPP > > mechanisms, > > > > > > however 3GPP devices do not use these requirements > > (no do these > > > > > > requirements represent the 3GPP requires. > > > > > > > > > > > > One solution to the issue would just be to make much > > > > clearer which > > > > > > SDOs have participated in this work and which have > > not and the > > > > > > status of that progress - however that was also what > > people keep > > > > > > calling the "applicability statement" was trying to do. > > > > > > > > > > > > regards > > > > > > > > > > > > Keith > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > From: ecrit-bounces@ietf.org > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner > > > > > > Sent: Wednesday, July 29, 2009 2:53 PM > > > > > > To: 'ecrit' > > > > > > Subject: [Ecrit] HUM on PhoneBCP > > > > > > > > > > > > > > > > > > During today's meeting there was discussion as to why > > > > the chairs > > > > > > Publication Requested PhoneBCP version 13 when there are > > > > unresolved > > > > > > issues. This discussion led us to call for a hum. > > We are now > > > > > > asking the same question on the list. > > > > > > > > > > > > Do you agree or disagree that PhoneBCP -13 is ready to > > > > Publication > > > > > > Request? > > > > > > > > > > > > Please respond by close of business on Wednesday August > > > 5th. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Marc & Hannes > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > = > > > > = From mlinsner@cisco.com Fri Jul 31 19:23:17 2009 Return-Path: <mlinsner@cisco.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBE463A6968 for <ecrit@core3.amsl.com>; Fri, 31 Jul 2009 19:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.272 X-Spam-Level: X-Spam-Status: No, score=-5.272 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvZ2s6lX+DV1 for <ecrit@core3.amsl.com>; Fri, 31 Jul 2009 19:23:16 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 990C43A6928 for <ecrit@ietf.org>; Fri, 31 Jul 2009 19:23:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAB5Ec0pAZnme/2dsb2JhbACCJi+WLKEHiCmQQgWEGA X-IronPort-AV: E=Sophos;i="4.43,305,1246838400"; d="scan'208,217";a="52522321" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 01 Aug 2009 02:23:18 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n712NIE7030880 for <ecrit@ietf.org>; Fri, 31 Jul 2009 22:23:18 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n712NI19028074 for <ecrit@ietf.org>; Sat, 1 Aug 2009 02:23:18 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 22:23:17 -0400 Received: from [172.16.24.58] ([10.86.244.24]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 22:23:17 -0400 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Fri, 31 Jul 2009 22:23:13 -0400 From: Marc Linsner <mlinsner@cisco.com> To: "'ecrit'" <ecrit@ietf.org> Message-ID: <C6991F51.1942A%mlinsner@cisco.com> Thread-Topic: PhoneBCP & Liaison from 3GPP Thread-Index: AcoSTwUNHUEG1PD1jk+HBYt7RsbzkQ== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3331923797_72373" X-OriginalArrivalTime: 01 Aug 2009 02:23:17.0408 (UTC) FILETIME=[07AE9A00:01CA124F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1127; t=1249093398; x=1249957398; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20<mlinsner@cisco.com> |Subject:=20PhoneBCP=20&=20Liaison=20from=203GPP |Sender:=20 |To:=20=22'ecrit'=22=20<ecrit@ietf.org>; bh=EQqgC2RcoUlu5FTSywmH+1s9aL1JMeCcCns+UslyDMg=; b=P5VSNuJRw6h3d3YumiQcJwgQG6MItHAcj592aFnuaLT1UtWOIZrIW2Fojb u4VQ63JDnav1YGgxcu8dzAWkBRvKdj2v40pmFSGjaOGPicowo6G4/a7ZCBcD jbW44k3/pg; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Ecrit] PhoneBCP & Liaison from 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 01 Aug 2009 02:23:17 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3331923797_72373 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Fyi.... https://datatracker.ietf.org/liaison/551/ I talked to the ADs about this and we can handle contributions from 3GPP before or during IETF last call. Nothing will change in the document without being vetted in the WG. -Marc- --B_3331923797_72373 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>PhoneBCP & Liaison from 3GPP Fyi....

https://datatracker.iet= f.org/liaison/551/

I talked to the ADs about this and we can handle contributions from 3GPP be= fore or during IETF last call.  Nothing will change in the document wit= hout being vetted in the WG.

-Marc- --B_3331923797_72373--