From ecrit-bounces@ietf.org Tue Apr 1 13:32:42 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0312728C407; Tue, 1 Apr 2008 13:32:42 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 730233A6E41 for ; Tue, 1 Apr 2008 13:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.922 X-Spam-Level: X-Spam-Status: No, score=-0.922 tagged_above=-999 required=5 tests=[AWL=0.281, 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 Kt3J5bUamAGx for ; Tue, 1 Apr 2008 13:32:40 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id A243628C337 for ; Tue, 1 Apr 2008 13:32:40 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_04_01_15_45_51 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 01 Apr 2008 15:45:50 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Apr 2008 15:32:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 15:32:38 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: Multiple Location Thread-Index: AciSoBSicmd+wT1mQom8/iePcnSz0wABYVlrACJtvEAAD6FFRAAMWCawAACTyqAAFIlhkAAQyFnF References: <47EFF025.9000705@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA080ECEF5@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA083C6764@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA083C6796@crexc41p> From: "Winterbottom, James" To: "Stark, Barbara" , "Hannes Tschofenig" , X-OriginalArrivalTime: 01 Apr 2008 20:32:39.0182 (UTC) FILETIME=[872992E0:01C89437] Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Barbara, I will chop a bunch of stuff out now <----Snip ------> My statement on LLDP-MED and DHCP was that the location sent by those protocols does not arrive at the end device in PIDF-LO format. I was mentioning that the PIDF rules on prioritizing received PIDF locations state that they apply to received PIDF locations. LLDP-MED and DHCP locations are not received by the end device as PIDF locations. Therefore the rules do not apply. They are also not received "together". Therefore, the rules do not apply. If recommendations are needed for handling multiple locations at an end device (and I believe they are), then I am saying that the PIDF rules are necessary (for multiple PIDF received together) but insufficient (for multiple locations gotten in a variety of ways), and that the PIDF document is the wrong place for comprehensive recommendations that take into account a variety of permutations of how devices get location. Barbara [AJW] PIDF-LO profile does say that if you get locations form different sources and you want to construct them into a PIDF-LO, what you need to do to do that, and that you need to put the location you consider best in first, that way the recipient can have a consistent way of interpreting what the originator was trying to tell them. PIDF-LO profile doesn't say how you determined which of these locations from different sources is best, and I don't think it can. Is it this latter piece of information you are seeking? Cheers James ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 2 05:14:55 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E74C3A6EAB; Wed, 2 Apr 2008 05:14:55 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56A873A6EAB for ; Wed, 2 Apr 2008 05:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.18 X-Spam-Level: X-Spam-Status: No, score=-102.18 tagged_above=-999 required=5 tests=[AWL=0.419, 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 GkKyK5lQfCcK for ; Wed, 2 Apr 2008 05:14:52 -0700 (PDT) Received: from aismt06p.bellsouth.com (aismt06p.bellsouth.com [139.76.165.211]) by core3.amsl.com (Postfix) with ESMTP id 4DECE3A6E03 for ; Wed, 2 Apr 2008 05:14:52 -0700 (PDT) Received: from ([139.76.131.87]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.44171647; Wed, 02 Apr 2008 08:14:26 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 2 Apr 2008 08:14:26 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 2 Apr 2008 08:14:26 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 08:14:25 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA083C6A1A@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: Multiple Location thread-index: AciSoBSicmd+wT1mQom8/iePcnSz0wABYVlrACJtvEAAD6FFRAAMWCawAACTyqAAFIlhkAAQyFnFACDQbaA= References: <47EFF025.9000705@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA080ECEF5@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA083C6764@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA083C6796@crexc41p> From: "Stark, Barbara" To: "Winterbottom, James" , "Hannes Tschofenig" , X-OriginalArrivalTime: 02 Apr 2008 12:14:26.0461 (UTC) FILETIME=[182014D0:01C894BB] Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --- snip ----------- PIDF-LO profile doesn't say how you determined which of these locations from different sources is best, and I don't think it can. Is it this latter piece of information you are seeking? --- end snip ------- Yes. But in the form of a default recommendation that can be used in the absence of any "real" knowledge. Barbara ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 2 09:50:31 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FDFF28C3B3; Wed, 2 Apr 2008 09:50:31 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69A143A6A09 for ; Wed, 2 Apr 2008 09:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, J_CHICKENPOX_31=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 ievC77KGraL9 for ; Wed, 2 Apr 2008 09:50:24 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1F62028C48C for ; Wed, 2 Apr 2008 09:50:19 -0700 (PDT) Received: (qmail invoked by alias); 02 Apr 2008 16:50:20 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp015) with SMTP; 02 Apr 2008 18:50:20 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+FiDkgm/qF/NxYLe3Zy7VUT9GDUNyujqjxCYqUuN 4LACPM7QbodCBn Message-ID: <47F3B94A.7020108@gmx.net> Date: Wed, 02 Apr 2008 19:50:18 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org, GEOPRIV X-Y-GMX-Trusted: 0 Subject: [Ecrit] [Fwd: [secdir] [New-work] OMA New Work - 1 Work Item Approved - Condition Based URI Seleciton] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org FYI, you might be interested in this work. Ciao Hannes -------- Original Message -------- Subject: [secdir] [New-work] OMA New Work - 1 Work Item Approved - Condition Based URI Seleciton Date: Wed, 2 Apr 2008 16:39:23 +0200 From: Victoria Gray To: Dear All, OMA would like to inform all the organisations subscribed to the IETF new-work list of the approval of 1 new work item: 1 Condition Based URIs Selection WI: http://www.openmobilealliance.org/ftp/Public_documents/TP/Permanent_documents/OMA-WID_0163-CBUS-V1_0-20080401-A.zip This work item is intended to provide OMA with an architectural solution for a condition/rule based URIs selection functionality based on information that may change dynamically. Such information is available e.g. from databases within the scope of Presence SIMPLE, XML Document Management, Location in SIP/IP Core and Mobile Location Service enablers. Typical examples of information that has this kind of behaviour are registration state and geographical location. The functionality can also be used to make selections based on personal information that changes less often or never, for example persons hobbies. The outcome of an evaluation of the conditions/rules will be a list of URI:s that match the conditions/rules. Depending on the condition/rules provided as input the content of the URI-List will vary as output. This work item has been allocated to the OMA PAG (Presence & Availability WG) for specification development. Best regards, Victoria Gray on behalf of OMA. *Victoria Gray* FORApolis / DSO Tel +33 (0)4 92 94 49 23 Fax +33 (0)4 92 38 49 23 GSM +33 (0)6 73 99 62 90 victoria.gray@forapolis.com MSN: *victoria.gray@forapolis.com* Yahoo!: *bluevicci* Skype: *victoria-gray* Google: *vics.gray@gmail.com * _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 2 12:43:02 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B9FE3A6A17; Wed, 2 Apr 2008 12:43:02 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D65FA3A6A81 for ; Wed, 2 Apr 2008 12:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 3zTnIatjnk2E for ; Wed, 2 Apr 2008 12:43:00 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id E76723A695C for ; Wed, 2 Apr 2008 12:42:59 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Wed, 2 Apr 2008 12:43:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 12:42:58 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575097BA424@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <47E0DD97.6090603@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Transition Support Issue Thread-Index: AciJpCaxN/1PsN+JQPalSqGTcAoOSALVTEXw References: <47E023F9.8040900@gmx.net><045701c88938$e0bdd410$640fa8c0@cis.neustar.com><047201c8893c$2c336d30$640fa8c0@cis.neustar.com> <47E0DD97.6090603@gmx.net> From: "Roger Marshall" To: , "Ted Hardie" Subject: [Ecrit] LoST Transition Support Issue X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Late comment to http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-09.txt I am requesting a simple text change to support adaptability of LoST during transition stage between non-IP PSAPs and IP-based PSAPs. Scenario: If an IP-originated emergency call uses the LoST service to provide routing instructions for routing the call to a region appropriate PSAP, yet that particular PSAP doesn't yet support IP, there needs to be a way within the LoST protocol to be able to still complete the call. One simple way is to redirect to another kind of server which can provide supplemental routing instructions to a non-IP PSAP (e.g., for North American, the NENA i2 VPC). Currently, the LoST draft would support this special kind of redirect, given single wording change: Proposal: Change text in the paragraph below, From: "LoST application unique string (see Section 4)" To: "application unique string (see Section 4)" 13.3. Redirects A LoST server can respond indicating that the querier should redirect the query to another server, using the element. The element includes a 'target' attribute indicating the LoST application unique string (see Section 4) that the client SHOULD be contacting next, as well as the 'source' attribute indicating the server that generated the redirect response and a 'message' attribute explaining the reason for the redirect response. -roger marshall. CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 2 13:38:35 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A2883A6C5D; Wed, 2 Apr 2008 13:38:35 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4703E3A6A0A for ; Wed, 2 Apr 2008 13:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.966 X-Spam-Level: X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[AWL=0.237, 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 9o83yqq+QDhg for ; Wed, 2 Apr 2008 13:38:33 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 60BF73A6B82 for ; Wed, 2 Apr 2008 13:38:33 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_04_02_15_51_47 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, 02 Apr 2008 15:51:47 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 15:37:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 15:37:58 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Transition Support Issue Thread-Index: AciJpCaxN/1PsN+JQPalSqGTcAoOSALVTEXwAAHUpY4= References: <47E023F9.8040900@gmx.net><045701c88938$e0bdd410$640fa8c0@cis.neustar.com><047201c8893c$2c336d30$640fa8c0@cis.neustar.com><47E0DD97.6090603@gmx.net> <8C837214C95C864C9F34F3635C2A6575097BA424@SEA-EXCHVS-2.telecomsys.com> From: "Winterbottom, James" To: "Roger Marshall" , , "Ted Hardie" X-OriginalArrivalTime: 02 Apr 2008 20:37:58.0640 (UTC) FILETIME=[6FFCBF00:01C89501] Subject: Re: [Ecrit] LoST Transition Support Issue X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Roger, My only concern with this, is that in i2 an end-point doesn't talk directly to a VPC, it talks to a VSP Call-Server that has several ways that it can talk with a VPC. Your proposed text change implies, at least to me, that the end-point would direct the request to the VPC, I am not sure that I would be in favour of that model in the i2 space. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Roger Marshall Sent: Wed 4/2/2008 2:42 PM To: ecrit@ietf.org; Ted Hardie Subject: [Ecrit] LoST Transition Support Issue Late comment to http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-09.txt I am requesting a simple text change to support adaptability of LoST during transition stage between non-IP PSAPs and IP-based PSAPs. Scenario: If an IP-originated emergency call uses the LoST service to provide routing instructions for routing the call to a region appropriate PSAP, yet that particular PSAP doesn't yet support IP, there needs to be a way within the LoST protocol to be able to still complete the call. One simple way is to redirect to another kind of server which can provide supplemental routing instructions to a non-IP PSAP (e.g., for North American, the NENA i2 VPC). Currently, the LoST draft would support this special kind of redirect, given single wording change: Proposal: Change text in the paragraph below, From: "LoST application unique string (see Section 4)" To: "application unique string (see Section 4)" 13.3. Redirects A LoST server can respond indicating that the querier should redirect the query to another server, using the element. The element includes a 'target' attribute indicating the LoST application unique string (see Section 4) that the client SHOULD be contacting next, as well as the 'source' attribute indicating the server that generated the redirect response and a 'message' attribute explaining the reason for the redirect response. -roger marshall. 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 ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 2 14:12:31 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D584A3A69F2; Wed, 2 Apr 2008 14:12:31 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFB613A69D6 for ; Wed, 2 Apr 2008 14:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.794 X-Spam-Level: X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[AWL=0.805, 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 s01FFnQqU-VL for ; Wed, 2 Apr 2008 14:12:29 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id D42933A69B6 for ; Wed, 2 Apr 2008 14:12:29 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JhAFq-0003k4-GD; Wed, 02 Apr 2008 16:12:22 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Roger Marshall'" , , "'Ted Hardie'" References: <47E023F9.8040900@gmx.net><045701c88938$e0bdd410$640fa8c0@cis.neustar.com><047201c8893c$2c336d30$640fa8c0@cis.neustar.com><47E0DD97.6090603@gmx.net><8C837214C95C864C9F34F3635C2A6575097BA424@SEA-EXCHVS-2.telecomsys.com> Date: Wed, 2 Apr 2008 17:12:25 -0400 Message-ID: <04b801c89506$41c374d0$6901a8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciJpCaxN/1PsN+JQPalSqGTcAoOSALVTEXwAAHUpY4AAQhzkA== In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] LoST Transition Support Issue X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I don't think this works at all. First of all, the LoST server either is run by the VPC, or it's run by something like the 9-1-1 Authority. The latter is where we are headed with i3. If the 9-1-1 Authority runs it, then it can't refer the query to the VPC, because it doesn't know which VPC. We'll have to decide (in NENA) what we do in the cases where there is no URI yet for a particular PSAP. One possibility is to return some fixed, non-globally resolvable URI. The carrier could provide its own resolution of that URI to its VPC. That could just be a default LoST return, rather than a redirect. If the VPC runs it, it can put some appropriate URI in the LoST return to get the right thing to happen. However, let's just say that somehow we do want to do a . It still has to be a LoST server, because that's what the client is going to do with it. If you want to send the call to some URI, that has to be the output of a LoST server and not a redirect. So, I think the wording is correct as written. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Wednesday, April 02, 2008 4:38 PM To: Roger Marshall; ecrit@ietf.org; Ted Hardie Subject: Re: [Ecrit] LoST Transition Support Issue Hi Roger, My only concern with this, is that in i2 an end-point doesn't talk directly to a VPC, it talks to a VSP Call-Server that has several ways that it can talk with a VPC. Your proposed text change implies, at least to me, that the end-point would direct the request to the VPC, I am not sure that I would be in favour of that model in the i2 space. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Roger Marshall Sent: Wed 4/2/2008 2:42 PM To: ecrit@ietf.org; Ted Hardie Subject: [Ecrit] LoST Transition Support Issue Late comment to http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-09.txt I am requesting a simple text change to support adaptability of LoST during transition stage between non-IP PSAPs and IP-based PSAPs. Scenario: If an IP-originated emergency call uses the LoST service to provide routing instructions for routing the call to a region appropriate PSAP, yet that particular PSAP doesn't yet support IP, there needs to be a way within the LoST protocol to be able to still complete the call. One simple way is to redirect to another kind of server which can provide supplemental routing instructions to a non-IP PSAP (e.g., for North American, the NENA i2 VPC). Currently, the LoST draft would support this special kind of redirect, given single wording change: Proposal: Change text in the paragraph below, From: "LoST application unique string (see Section 4)" To: "application unique string (see Section 4)" 13.3. Redirects A LoST server can respond indicating that the querier should redirect the query to another server, using the element. The element includes a 'target' attribute indicating the LoST application unique string (see Section 4) that the client SHOULD be contacting next, as well as the 'source' attribute indicating the server that generated the redirect response and a 'message' attribute explaining the reason for the redirect response. -roger marshall. 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 ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 2 14:24:47 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37E343A6D74; Wed, 2 Apr 2008 14:24:47 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DDCA28C0E4 for ; Wed, 2 Apr 2008 14:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.811, 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 4LWEtV8gpdnY for ; Wed, 2 Apr 2008 14:24:43 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 5B1B23A69C4 for ; Wed, 2 Apr 2008 14:24:43 -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=1207171485; x=1238707485; 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<04b801c89506$41c374d0$6 901a8c0@cis.neustar.com>|References:=0D=0A=20=20<47E023F9 .8040900@gmx.net><045701c88938$e0bdd410$640fa8c0@cis.neus tar.com=0D=0A=20><047201c8893c=0D=0A=20$2c336d30$640fa 8c0@cis.neustar.com><47E0DD97.6090603@gmx.net><8C837214C9 5C=0D=0A=20864C9F34F3635C2A6575097BA424@SEA-EXCHVS-2.tele comsys.com>=0D=0A=20=0D=0A=20<04b801c89506$41c374d0$6901 a8c0@cis.neustar.com>|Date:=20Wed,=202=20Apr=202008=2014: 24:41=20-0700|To:=20Brian=20Rosen=20, =0D=0A=20=20=20=20=20=20=20=20"'Winterbottom,=20James'" =20,=0D=0A=20=20=20=20=20 =20=20=20"'Roger=20Marshall'"=09,=0D=0A=20=20=20=20=20=20=20=20"ecrit@ietf.org"=20|From:=20Ted=20Hardie=20 |Subject:=20RE:=20[Ecrit]=20LoST=20Transition=20Support =20Issue|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,5265"=3B =20a=3D"2110040"; bh=1Uk5bpnW/+50IPM72+/8sevpIs051neWUWDT0t1n5D8=; b=T1NQY/RWbR2HvRWux6eINsNEiE9kOHER+jbJw/92YYLKIpZfI6ykWbNN l/xtLSUMhKbiU42w7SXB7ql/VhzN5uZJgEGHenBkmkG/mnVzdlHjBEOys fk/wo9bHJ/NSKqekwKh5CC4xlwQl2Htlt886/YjhlZkSt2p4TO+aBV3mc 4=; X-IronPort-AV: E=McAfee;i="5100,188,5265"; a="2110040" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Apr 2008 14:24:43 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m32LOhsw026504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Apr 2008 14:24:43 -0700 Received: from [129.46.226.27] (carbuncle.qualcomm.com [129.46.226.27]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m32LOfwA017879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Apr 2008 14:24:42 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <04b801c89506$41c374d0$6901a8c0@cis.neustar.com> References: <47E023F9.8040900@gmx.net><045701c88938$e0bdd410$640fa8c0@cis.neustar.com ><047201c8893c $2c336d30$640fa8c0@cis.neustar.com><47E0DD97.6090603@gmx.net><8C837214C95C 864C9F34F3635C2A6575097BA424@SEA-EXCHVS-2.telecomsys.com> <04b801c89506$41c374d0$6901a8c0@cis.neustar.com> Date: Wed, 2 Apr 2008 14:24:41 -0700 To: Brian Rosen , "'Winterbottom, James'" , "'Roger Marshall'" , "ecrit@ietf.org" From: Ted Hardie Subject: Re: [Ecrit] LoST Transition Support Issue X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 2:12 PM -0700 4/2/08, Brian Rosen wrote: >I don't think this works at all. Well, I can't top that for a comment, but I also have some serious issues with the proposal. If adopted, I don't see how it limits what application unique strings are returned; since a sane processing engine wouldn't bother dereferencing an application unique string for a protocol it wasn't going to be able to use at the end of the day, that's not great. At a minimum, you would need to define what protocol was going to be used once the were complete. Given that, it does seem simpler to return a URI in the LoST response that tells the end system how to contact that PSAP via whatever system it needs to use. If it's not going to understand that kind of response, it's not going to understand a pointer to a second system which is going to give it that response once it gets there. regards, Ted >First of all, the LoST server either is run by the VPC, or it's run by >something like the 9-1-1 Authority. The latter is where we are headed with >i3. > >If the 9-1-1 Authority runs it, then it can't refer the query to the VPC, >because it doesn't know which VPC. We'll have to decide (in NENA) what we >do in the cases where there is no URI yet for a particular PSAP. One >possibility is to return some fixed, non-globally resolvable URI. The >carrier could provide its own resolution of that URI to its VPC. That could >just be a default LoST return, rather than a redirect. > >If the VPC runs it, it can put some appropriate URI in the LoST return to >get the right thing to happen. > >However, let's just say that somehow we do want to do a . It >still has to be a LoST server, because that's what the client is going to do >with it. If you want to send the call to some URI, that has to be the >output of a LoST server and not a redirect. So, I think the wording is >correct as written. > >Brian > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >Winterbottom, James >Sent: Wednesday, April 02, 2008 4:38 PM >To: Roger Marshall; ecrit@ietf.org; Ted Hardie >Subject: Re: [Ecrit] LoST Transition Support Issue > >Hi Roger, > >My only concern with this, is that in i2 an end-point doesn't talk directly >to a VPC, it talks to a VSP Call-Server that has several ways that it can >talk with a VPC. Your proposed text change implies, at least to me, that the >end-point would direct the request to the VPC, I am not sure that I would be >in favour of that model in the i2 space. > >Cheers >James > > > >-----Original Message----- >From: ecrit-bounces@ietf.org on behalf of Roger Marshall >Sent: Wed 4/2/2008 2:42 PM >To: ecrit@ietf.org; Ted Hardie >Subject: [Ecrit] LoST Transition Support Issue > >Late comment to >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-09.txt > >I am requesting a simple text change to support adaptability of LoST >during transition stage between non-IP PSAPs and IP-based PSAPs. > >Scenario: >If an IP-originated emergency call uses the LoST service to provide >routing instructions for routing the call to a region appropriate PSAP, >yet that particular PSAP doesn't yet support IP, there needs to be a way >within the LoST protocol to be able to still complete the call. One >simple way is to redirect to another kind of server which can provide >supplemental routing instructions to a non-IP PSAP (e.g., for North >American, the NENA i2 VPC). Currently, the LoST draft would support >this special kind of redirect, given single wording change: > >Proposal: Change text in the paragraph below, >From: "LoST application unique string (see Section 4)" >To: "application unique string (see Section 4)" > >13.3. Redirects > > A LoST server can respond indicating that the querier should redirect > the query to another server, using the element. The > element includes a 'target' attribute indicating the LoST application > unique string (see Section 4) that the client SHOULD be contacting > next, as well as the 'source' attribute indicating the server that > generated the redirect response and a 'message' attribute explaining > the reason for the redirect response. > >-roger marshall. > > >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 > > >---------------------------------------------------------------------------- >-------------------- >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >---------------------------------------------------------------------------- >-------------------- >[mf2] > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 2 15:14:01 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 040513A6961; Wed, 2 Apr 2008 15:14:01 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23B5028C118 for ; Wed, 2 Apr 2008 15:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=0.225, 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 4YSaFh7ccDyh for ; Wed, 2 Apr 2008 15:13:59 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id EDBE63A6865 for ; Wed, 2 Apr 2008 15:13:58 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_04_02_17_27_04 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, 02 Apr 2008 17:27:04 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 17:13:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 17:13:49 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Transition Support Issue Thread-Index: AciVB/lpkpHQ2eEzSyK/Ep/oBVnVAAABozwg References: <47E023F9.8040900@gmx.net><045701c88938$e0bdd410$640fa8c0@cis.neustar.com ><047201c8893c $2c336d30$640fa8c0@cis.neustar.com><47E0DD97.6090603@gmx.net><8C837214C95C 864C9F34F3635C2A6575097BA424@SEA-EXCHVS-2.telecomsys.com> <04b801c89506$41c374d0$6901a8c0@cis.neustar.com> From: "Winterbottom, James" To: "Ted Hardie" , "Brian Rosen" , "Roger Marshall" , X-OriginalArrivalTime: 02 Apr 2008 22:13:51.0941 (UTC) FILETIME=[D538CF50:01C8950E] Subject: Re: [Ecrit] LoST Transition Support Issue X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Indeed, you could just as well have the LoST server return an ESRD (or similar) encoded as a tel uri, and doesn't the problem then kind of go away? Getting location to the PSAP of course then become the challenge, but that is a different problem. Cheers James > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Thursday, 3 April 2008 8:25 AM > To: Brian Rosen; Winterbottom, James; 'Roger Marshall'; ecrit@ietf.org > Subject: RE: [Ecrit] LoST Transition Support Issue > > At 2:12 PM -0700 4/2/08, Brian Rosen wrote: > >I don't think this works at all. > > Well, I can't top that for a comment, but I also have some serious issues > with the proposal. If adopted, I don't see how it limits what application > unique strings are returned; since a sane processing engine wouldn't > bother dereferencing an application unique string for a protocol > it wasn't going to be able to use at the end of the day, that's not great. > At a minimum, you would need to define what protocol was going to > be used once the were complete. Given that, it does > seem simpler to return a URI in the LoST response that tells > the end system how to contact that PSAP via whatever system > it needs to use. If it's not going to understand that kind of response, > it's not going to understand a pointer to a second system which is > going to give it that response once it gets there. > > regards, > Ted > > > > > >First of all, the LoST server either is run by the VPC, or it's run by > >something like the 9-1-1 Authority. The latter is where we are headed > with > >i3. > > > >If the 9-1-1 Authority runs it, then it can't refer the query to the VPC, > >because it doesn't know which VPC. We'll have to decide (in NENA) what > we > >do in the cases where there is no URI yet for a particular PSAP. One > >possibility is to return some fixed, non-globally resolvable URI. The > >carrier could provide its own resolution of that URI to its VPC. That > could > >just be a default LoST return, rather than a redirect. > > > >If the VPC runs it, it can put some appropriate URI in the LoST return to > >get the right thing to happen. > > > >However, let's just say that somehow we do want to do a . It > >still has to be a LoST server, because that's what the client is going to > do > >with it. If you want to send the call to some URI, that has to be the > >output of a LoST server and not a redirect. So, I think the wording is > >correct as written. > > > >Brian > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > >Winterbottom, James > >Sent: Wednesday, April 02, 2008 4:38 PM > >To: Roger Marshall; ecrit@ietf.org; Ted Hardie > >Subject: Re: [Ecrit] LoST Transition Support Issue > > > >Hi Roger, > > > >My only concern with this, is that in i2 an end-point doesn't talk > directly > >to a VPC, it talks to a VSP Call-Server that has several ways that it can > >talk with a VPC. Your proposed text change implies, at least to me, that > the > >end-point would direct the request to the VPC, I am not sure that I would > be > >in favour of that model in the i2 space. > > > >Cheers > >James > > > > > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org on behalf of Roger Marshall > >Sent: Wed 4/2/2008 2:42 PM > >To: ecrit@ietf.org; Ted Hardie > >Subject: [Ecrit] LoST Transition Support Issue > > > >Late comment to > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-09.txt > > > >I am requesting a simple text change to support adaptability of LoST > >during transition stage between non-IP PSAPs and IP-based PSAPs. > > > >Scenario: > >If an IP-originated emergency call uses the LoST service to provide > >routing instructions for routing the call to a region appropriate PSAP, > >yet that particular PSAP doesn't yet support IP, there needs to be a way > >within the LoST protocol to be able to still complete the call. One > >simple way is to redirect to another kind of server which can provide > >supplemental routing instructions to a non-IP PSAP (e.g., for North > >American, the NENA i2 VPC). Currently, the LoST draft would support > >this special kind of redirect, given single wording change: > > > >Proposal: Change text in the paragraph below, > >From: "LoST application unique string (see Section 4)" > >To: "application unique string (see Section 4)" > > > >13.3. Redirects > > > > A LoST server can respond indicating that the querier should redirect > > the query to another server, using the element. The > > element includes a 'target' attribute indicating the LoST application > > unique string (see Section 4) that the client SHOULD be contacting > > next, as well as the 'source' attribute indicating the server that > > generated the redirect response and a 'message' attribute explaining > > the reason for the redirect response. > > > >-roger marshall. > > > > > >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 > > > > > >----------------------------------------------------------------------- -- > --- > >-------------------- > >This message is for the designated recipient only and may > >contain privileged, proprietary, or otherwise private information. > >If you have received it in error, please notify the sender > >immediately and delete the original. Any unauthorized use of > >this email is prohibited. > >----------------------------------------------------------------------- -- > --- > >-------------------- > >[mf2] > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 2 16:36:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92D0F3A6B78; Wed, 2 Apr 2008 16:36:25 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8FF628C400 for ; Wed, 2 Apr 2008 16:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 XB4R0H5nPXua for ; Wed, 2 Apr 2008 16:36:20 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id CD28428C50F for ; Wed, 2 Apr 2008 16:35:18 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Wed, 2 Apr 2008 16:35:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 16:35:18 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750982EC99@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: Default Location Thread-Index: AciSoBsXzeiyM5C1TbiPfHV2vt2oAQAA98TkACKpIhAAEOXLgAACPnMAAASTsQAAYuLwsA== References: <47EFF030.5030802@gmx.net> <00e701c8932f$0ee90f80$6901a8c0@cis.neustar.com> <8C837214C95C864C9F34F3635C2A6575097B99E0@SEA-EXCHVS-2.telecomsys.com> <019001c8937c$81e73460$6901a8c0@cis.neustar.com> From: "Roger Marshall" To: "Winterbottom, James" , "Brian Rosen" , "Hannes Tschofenig" , Subject: Re: [Ecrit] Phone BCP: Default Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Agree with you James. There is with this a nagging 'tell me more' aspect to this. The way is being specified here is more like . It still doesn't tell you whether the last resort was TDOA, SA-GPS, Wiremap Provisioned, Cellsector-id, or 'manually-input', etc. Wouldn't it be nice to know? When the search & rescue team comes up wanting, the PSAP will want to know. -roger. > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Monday, March 31, 2008 5:23 PM > To: Brian Rosen; Roger Marshall; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] Phone BCP: Default Location > > Let's agree to disagree on this. > I see method as a means of describing how the location of the > Target was determined. What is being described by a value of > default is that the location bears no perceivable > relationship to the Target, but is being provided because we > want the call to be answered. This is a measure of the > quality of the location information, and this requires a > separate indicator. > > If everybody disagrees me on this then I will let it drop, > but I think it is a slippery path to follow. > > Cheers > James > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, 1 April 2008 9:14 AM > > To: 'Roger Marshall'; Winterbottom, James; 'Hannes Tschofenig'; > > ecrit@ietf.org > > Subject: RE: [Ecrit] Phone BCP: Default Location > > > > Well, maybe. I don't want to limit default to manually provisioned, > but > > it's probably the most common way you get it. > > > > The point is that every element that handles an emergency > call has to > be > > prepared to supply a default value. The closer the element > is to the > > endpoint, the more likely it is to have a good default > value. In your > > list, in most cases, it's . > > > > DHCP is an LCP, not a method. In most cases, a civic location is a > > wiremap and a geo is measured by GPS or triangulated by > APs. It isn't > > always > so, > > but that's probably good enough. > > > > Default is a method. You got it some basic way (usually > configured). > We > > used an example of a CMTS area for a cable system. If the > LIS failed > to > > determine a location, or a proxy server needed to add > location, using > some > > location in the CMTS service area may be a decent default location. > The > > "some location" is configured. > > > > When you have a default location, you don't have some other method. > If > > you > > did, you would use it, and you wouldn't need a default. > > > > Brian > > > > -----Original Message----- > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > Sent: Monday, March 31, 2008 5:18 PM > > To: Brian Rosen; Winterbottom, James; Hannes Tschofenig; > ecrit@ietf.org > > Subject: RE: [Ecrit] Phone BCP: Default Location > > > > ...Brian Rosen wrote on Monday, March 31, 2008 5:59 AM, > > > > > It was determined by some element who failed to get it by > some other > > > method, > > > > I'm not sure I get it. Are you saying "default", in the sense of > > "manually provisioned" only? > > > > Locations in their most basic form are either 1. (e.g., > > wiremap), 2. (e.g., agps), or 3. > (e.g., geocoded) > > > > Configuration mechanisms have been talked about, such as > using a DHCP > > server for location acquisition. I just want to make sure > folks don't > > think that the answer as to what to put in the PIDF-LO's method > element > > would be something like . If so, then any info relating to > the > > 3 methods above is gone. If not, then we need another value in > PIDF-LO, > > something like: > > > > dhcp > > > > Mostly though, the method value doesn't tell me anything > about > > the how the location should be characterized. > > > > -roger. > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > > Behalf Of Brian Rosen > > > Sent: Monday, March 31, 2008 5:59 AM > > > To: 'Winterbottom, James'; 'Hannes Tschofenig'; ecrit@ietf.org > > > Subject: Re: [Ecrit] Phone BCP: Default Location > > > > > > No, it represents the best available location of the user. > > > > > > It was determined by some element who failed to get it by > some other > > > method, and is using a default value which was predefined for that > > > purpose. The > > > best available location is the default value, and the > method used to > > > determine it was the 'default' method. > > > > > > I think it's appropriate as defined. > > > > > > Brian > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > > Behalf Of Winterbottom, James > > > Sent: Sunday, March 30, 2008 4:34 PM > > > To: Hannes Tschofenig; ecrit@ietf.org > > > Subject: Re: [Ecrit] Phone BCP: Default Location > > > > > > Actually this is a misuse of the method token. > > > The method token says how location was determined for > inclusion in > > > the PIDF-LO. > > > The intent I read from this requirement is that the method is > > > attempting to say that the location doesn't represent > where the end > > > point is at all, but is what they have registered as a default > > > location. > > > > > > I think you need a new element in the PIDF-LO to represent this. > > > Something like: > > > yes > > > > > > or > > > > > > default > > > > > > Then it could have a value of "current" or "recent" or > other kind of > > > subjective things too. > > > > > > Cheers > > > James > > > > > > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > > > Sent: Sun 3/30/2008 2:55 PM > > > To: ecrit@ietf.org > > > Subject: [Ecrit] Phone BCP: Default Location > > > > > > " > > > AN-23/SP-22 Default locations MUST be marked with > method=Default > > > and > > > the proxy MUST be identfied in provided-by element of the > PIDF-LO. > > > " > > > > > > Someone should register the token "default". To my > knowledge it is > > > not registered. > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > -------------------------------------------------------------- > > > -------------- > > > -------------------- > > > This message is for the designated recipient only and may contain > > > privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized > use of this > > > email is prohibited. > > > -------------------------------------------------------------- > > > -------------- > > > -------------------- > > > [mf2] > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > message may > be > > privileged and/or confidential. If you are not the intended > recipient, > or > > responsible for delivering this message to the intended > recipient, any > > review, forwarding, dissemination, distribution or copying of this > > communication or any attachment(s) is strictly prohibited. > If you have > > received this message in error, please notify the sender > immediately, > and > > delete it and all attachments from your computer and network. > > > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 2 17:03:52 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90AE53A6EE6; Wed, 2 Apr 2008 17:03:52 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 438903A6EE3 for ; Wed, 2 Apr 2008 17:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[AWL=0.214, 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 eAccorV6MuHq for ; Wed, 2 Apr 2008 17:03:48 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 96A993A68CB for ; Wed, 2 Apr 2008 17:03:43 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_04_02_19_16_54 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, 02 Apr 2008 19:16:54 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 19:03:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 19:03:37 -0500 Message-ID: In-Reply-To: <8C837214C95C864C9F34F3635C2A65750982EC99@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: Default Location Thread-Index: AciSoBsXzeiyM5C1TbiPfHV2vt2oAQAA98TkACKpIhAAEOXLgAACPnMAAASTsQAAYuLwsAABKvyA References: <47EFF030.5030802@gmx.net> <00e701c8932f$0ee90f80$6901a8c0@cis.neustar.com> <8C837214C95C864C9F34F3635C2A6575097B99E0@SEA-EXCHVS-2.telecomsys.com> <019001c8937c$81e73460$6901a8c0@cis.neustar.com> <8C837214C95C864C9F34F3635C2A65750982EC99@SEA-EXCHVS-2.telecomsys.com> From: "Winterbottom, James" To: "Roger Marshall" , "Brian Rosen" , "Hannes Tschofenig" , X-OriginalArrivalTime: 03 Apr 2008 00:03:40.0952 (UTC) FILETIME=[2C941980:01C8951E] Subject: Re: [Ecrit] Phone BCP: Default Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If it is the proxy in this case that is essentially getting the PSAP URI, either because it simply knows it, or because it has picked some arbitrary location and talked to LoST, I think I am prepared to say that NO location should be provided with the call. That way the network and call-taker can't help but treat the call in a more "special" way. > -----Original Message----- > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > Sent: Thursday, 3 April 2008 10:35 AM > To: Winterbottom, James; Brian Rosen; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] Phone BCP: Default Location > > Agree with you James. There is with this a nagging 'tell me more' aspect > to this. > > The way is being specified here is more like > . It still doesn't tell you whether the last > resort was TDOA, SA-GPS, Wiremap Provisioned, Cellsector-id, or > 'manually-input', etc. Wouldn't it be nice to know? When the search & > rescue team comes up wanting, the PSAP will want to know. > > -roger. > > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Monday, March 31, 2008 5:23 PM > > To: Brian Rosen; Roger Marshall; Hannes Tschofenig; ecrit@ietf.org > > Subject: RE: [Ecrit] Phone BCP: Default Location > > > > Let's agree to disagree on this. > > I see method as a means of describing how the location of the > > Target was determined. What is being described by a value of > > default is that the location bears no perceivable > > relationship to the Target, but is being provided because we > > want the call to be answered. This is a measure of the > > quality of the location information, and this requires a > > separate indicator. > > > > If everybody disagrees me on this then I will let it drop, > > but I think it is a slippery path to follow. > > > > Cheers > > James > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, 1 April 2008 9:14 AM > > > To: 'Roger Marshall'; Winterbottom, James; 'Hannes Tschofenig'; > > > ecrit@ietf.org > > > Subject: RE: [Ecrit] Phone BCP: Default Location > > > > > > Well, maybe. I don't want to limit default to manually provisioned, > > but > > > it's probably the most common way you get it. > > > > > > The point is that every element that handles an emergency > > call has to > > be > > > prepared to supply a default value. The closer the element > > is to the > > > endpoint, the more likely it is to have a good default > > value. In your > > > list, in most cases, it's . > > > > > > DHCP is an LCP, not a method. In most cases, a civic location is a > > > wiremap and a geo is measured by GPS or triangulated by > > APs. It isn't > > > always > > so, > > > but that's probably good enough. > > > > > > Default is a method. You got it some basic way (usually > > configured). > > We > > > used an example of a CMTS area for a cable system. If the > > LIS failed > > to > > > determine a location, or a proxy server needed to add > > location, using > > some > > > location in the CMTS service area may be a decent default location. > > The > > > "some location" is configured. > > > > > > When you have a default location, you don't have some other method. > > If > > > you > > > did, you would use it, and you wouldn't need a default. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > > Sent: Monday, March 31, 2008 5:18 PM > > > To: Brian Rosen; Winterbottom, James; Hannes Tschofenig; > > ecrit@ietf.org > > > Subject: RE: [Ecrit] Phone BCP: Default Location > > > > > > ...Brian Rosen wrote on Monday, March 31, 2008 5:59 AM, > > > > > > > It was determined by some element who failed to get it by > > some other > > > > method, > > > > > > I'm not sure I get it. Are you saying "default", in the sense of > > > "manually provisioned" only? > > > > > > Locations in their most basic form are either 1. (e.g., > > > wiremap), 2. (e.g., agps), or 3. > > (e.g., geocoded) > > > > > > Configuration mechanisms have been talked about, such as > > using a DHCP > > > server for location acquisition. I just want to make sure > > folks don't > > > think that the answer as to what to put in the PIDF-LO's method > > element > > > would be something like . If so, then any info relating to > > the > > > 3 methods above is gone. If not, then we need another value in > > PIDF-LO, > > > something like: > > > > > > dhcp > > > > > > Mostly though, the method value doesn't tell me anything > > about > > > the how the location should be characterized. > > > > > > -roger. > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > > > Behalf Of Brian Rosen > > > > Sent: Monday, March 31, 2008 5:59 AM > > > > To: 'Winterbottom, James'; 'Hannes Tschofenig'; ecrit@ietf.org > > > > Subject: Re: [Ecrit] Phone BCP: Default Location > > > > > > > > No, it represents the best available location of the user. > > > > > > > > It was determined by some element who failed to get it by > > some other > > > > method, and is using a default value which was predefined for that > > > > purpose. The > > > > best available location is the default value, and the > > method used to > > > > determine it was the 'default' method. > > > > > > > > I think it's appropriate as defined. > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > > > Behalf Of Winterbottom, James > > > > Sent: Sunday, March 30, 2008 4:34 PM > > > > To: Hannes Tschofenig; ecrit@ietf.org > > > > Subject: Re: [Ecrit] Phone BCP: Default Location > > > > > > > > Actually this is a misuse of the method token. > > > > The method token says how location was determined for > > inclusion in > > > > the PIDF-LO. > > > > The intent I read from this requirement is that the method is > > > > attempting to say that the location doesn't represent > > where the end > > > > point is at all, but is what they have registered as a default > > > > location. > > > > > > > > I think you need a new element in the PIDF-LO to represent this. > > > > Something like: > > > > yes > > > > > > > > or > > > > > > > > default > > > > > > > > Then it could have a value of "current" or "recent" or > > other kind of > > > > subjective things too. > > > > > > > > Cheers > > > > James > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > > > > Sent: Sun 3/30/2008 2:55 PM > > > > To: ecrit@ietf.org > > > > Subject: [Ecrit] Phone BCP: Default Location > > > > > > > > " > > > > AN-23/SP-22 Default locations MUST be marked with > > method=Default > > > > and > > > > the proxy MUST be identfied in provided-by element of the > > PIDF-LO. > > > > " > > > > > > > > Someone should register the token "default". To my > > knowledge it is > > > > not registered. > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > -------------------------------------------------------------- > > > > -------------- > > > > -------------------- > > > > This message is for the designated recipient only and may contain > > > > privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized > > use of this > > > > email is prohibited. > > > > -------------------------------------------------------------- > > > > -------------- > > > > -------------------- > > > > [mf2] > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > message may > > be > > > privileged and/or confidential. If you are not the intended > > recipient, > > or > > > responsible for delivering this message to the intended > > recipient, any > > > review, forwarding, dissemination, distribution or copying of this > > > communication or any attachment(s) is strictly prohibited. > > If you have > > > received this message in error, please notify the sender > > immediately, > > and > > > delete it and all attachments from your computer and network. > > > > > > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] > > > > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 2 20:32:23 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008C53A6AB2; Wed, 2 Apr 2008 20:32:23 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2018B28C492 for ; Wed, 2 Apr 2008 20:32:21 -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 5ytgEwv9R86Y for ; Wed, 2 Apr 2008 20:32:20 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id D52A23A6818 for ; Wed, 2 Apr 2008 20:32:19 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_04_02_22_45_35 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, 02 Apr 2008 22:45:35 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 22:32:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 22:32:20 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Transition Support Issue Thread-Index: AciVB/lpkpHQ2eEzSyK/Ep/oBVnVAAABozwgAArYseA= References: <47E023F9.8040900@gmx.net><045701c88938$e0bdd410$640fa8c0@cis.neustar.com><047201c8893c$2c336d30$640fa8c0@cis.neustar.com><47E0DD97.6090603@gmx.net><8C837214C95C864C9F34F3635C2A6575097BA424@SEA-EXCHVS-2.telecomsys.com><04b801c89506$41c374d0$6901a8c0@cis.neustar.com> From: "Dawson, Martin" To: "Winterbottom, James" , "Ted Hardie" , "Brian Rosen" , "Roger Marshall" , X-OriginalArrivalTime: 03 Apr 2008 03:32:21.0873 (UTC) FILETIME=[53A10610:01C8953B] Subject: Re: [Ecrit] LoST Transition Support Issue X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If the PSAP is not "ECRIT capable" - and this involves more than just being an "IP PSAP" - then it shouldn't resolve from LoST. I think the proper transitional situation is for VSPs to try ECRIT (LoST) and if the route doesn't resolve, to fall back to a VPC request. VSPs nominate their own VPC (and ESGW and/or proxy) providers, so the LoST server can't nominate a VPC for them. Actually, for quite some time, it may make the most sense for the VSP to use i2/VPC first and make ECRIT the fallback. In my view, ideally, an ECRIT-capable emergency client will have found and used the LoST service and sent the call directly to the PSAP in an ECRIT-capable catchment area anyway. That is, the VSP should only be involved if that doesn't apply and the call does require i2-type handling. I know - that's still semi-heretical by the BCP, but I still think it's correct and would lead to a more stable long term situation. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Thursday, 3 April 2008 9:14 AM To: Ted Hardie; Brian Rosen; Roger Marshall; ecrit@ietf.org Subject: Re: [Ecrit] LoST Transition Support Issue Indeed, you could just as well have the LoST server return an ESRD (or similar) encoded as a tel uri, and doesn't the problem then kind of go away? Getting location to the PSAP of course then become the challenge, but that is a different problem. Cheers James > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Thursday, 3 April 2008 8:25 AM > To: Brian Rosen; Winterbottom, James; 'Roger Marshall'; ecrit@ietf.org > Subject: RE: [Ecrit] LoST Transition Support Issue > > At 2:12 PM -0700 4/2/08, Brian Rosen wrote: > >I don't think this works at all. > > Well, I can't top that for a comment, but I also have some serious issues > with the proposal. If adopted, I don't see how it limits what application > unique strings are returned; since a sane processing engine wouldn't > bother dereferencing an application unique string for a protocol > it wasn't going to be able to use at the end of the day, that's not great. > At a minimum, you would need to define what protocol was going to > be used once the were complete. Given that, it does > seem simpler to return a URI in the LoST response that tells > the end system how to contact that PSAP via whatever system > it needs to use. If it's not going to understand that kind of response, > it's not going to understand a pointer to a second system which is > going to give it that response once it gets there. > > regards, > Ted > > > > > >First of all, the LoST server either is run by the VPC, or it's run by > >something like the 9-1-1 Authority. The latter is where we are headed > with > >i3. > > > >If the 9-1-1 Authority runs it, then it can't refer the query to the VPC, > >because it doesn't know which VPC. We'll have to decide (in NENA) what > we > >do in the cases where there is no URI yet for a particular PSAP. One > >possibility is to return some fixed, non-globally resolvable URI. The > >carrier could provide its own resolution of that URI to its VPC. That > could > >just be a default LoST return, rather than a redirect. > > > >If the VPC runs it, it can put some appropriate URI in the LoST return to > >get the right thing to happen. > > > >However, let's just say that somehow we do want to do a . It > >still has to be a LoST server, because that's what the client is going to > do > >with it. If you want to send the call to some URI, that has to be the > >output of a LoST server and not a redirect. So, I think the wording is > >correct as written. > > > >Brian > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > >Winterbottom, James > >Sent: Wednesday, April 02, 2008 4:38 PM > >To: Roger Marshall; ecrit@ietf.org; Ted Hardie > >Subject: Re: [Ecrit] LoST Transition Support Issue > > > >Hi Roger, > > > >My only concern with this, is that in i2 an end-point doesn't talk > directly > >to a VPC, it talks to a VSP Call-Server that has several ways that it can > >talk with a VPC. Your proposed text change implies, at least to me, that > the > >end-point would direct the request to the VPC, I am not sure that I would > be > >in favour of that model in the i2 space. > > > >Cheers > >James > > > > > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org on behalf of Roger Marshall > >Sent: Wed 4/2/2008 2:42 PM > >To: ecrit@ietf.org; Ted Hardie > >Subject: [Ecrit] LoST Transition Support Issue > > > >Late comment to > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-09.txt > > > >I am requesting a simple text change to support adaptability of LoST > >during transition stage between non-IP PSAPs and IP-based PSAPs. > > > >Scenario: > >If an IP-originated emergency call uses the LoST service to provide > >routing instructions for routing the call to a region appropriate PSAP, > >yet that particular PSAP doesn't yet support IP, there needs to be a way > >within the LoST protocol to be able to still complete the call. One > >simple way is to redirect to another kind of server which can provide > >supplemental routing instructions to a non-IP PSAP (e.g., for North > >American, the NENA i2 VPC). Currently, the LoST draft would support > >this special kind of redirect, given single wording change: > > > >Proposal: Change text in the paragraph below, > >From: "LoST application unique string (see Section 4)" > >To: "application unique string (see Section 4)" > > > >13.3. Redirects > > > > A LoST server can respond indicating that the querier should redirect > > the query to another server, using the element. The > > element includes a 'target' attribute indicating the LoST application > > unique string (see Section 4) that the client SHOULD be contacting > > next, as well as the 'source' attribute indicating the server that > > generated the redirect response and a 'message' attribute explaining > > the reason for the redirect response. > > > >-roger marshall. > > > > > >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 > > > > > >----------------------------------------------------------------------- -- > --- > >-------------------- > >This message is for the designated recipient only and may > >contain privileged, proprietary, or otherwise private information. > >If you have received it in error, please notify the sender > >immediately and delete the original. Any unauthorized use of > >this email is prohibited. > >----------------------------------------------------------------------- -- > --- > >-------------------- > >[mf2] > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 2 22:30:28 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47C328C10B; Wed, 2 Apr 2008 22:30:28 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C823A6898 for ; Wed, 2 Apr 2008 22:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.733 X-Spam-Level: X-Spam-Status: No, score=-4.733 tagged_above=-999 required=5 tests=[AWL=1.866, 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 SKknOzcmlqT5 for ; Wed, 2 Apr 2008 22:30:26 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 8AD2D28C372 for ; Wed, 2 Apr 2008 22:30:10 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2008 22:30:13 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m335UDpZ013098; Wed, 2 Apr 2008 22:30:13 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m335UDxM014455; Thu, 3 Apr 2008 05:30:13 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 22:30:12 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.87.199]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 22:30:12 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 03 Apr 2008 00:30:11 -0500 To: "Stark, Barbara" , "Winterbottom, James" , "Hannes Tschofenig" , From: "James M. Polk" In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA083C6A1A@crexc41p> References: <47EFF025.9000705@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA080ECEF5@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA083C6764@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA083C6796@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA083C6A1A@crexc41p> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 03 Apr 2008 05:30:12.0592 (UTC) FILETIME=[CA1B1F00:01C8954B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1904; t=1207200613; x=1208064613; 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]=20Phone=20BCP=3A=20Multiple=20L ocation |Sender:=20; bh=z5WuL81L+4BSxqJK7gzCN2pwbbfHdGC5b4V2dnMYXpE=; b=YpkcrHa/WsK4Q6a06c4eTKtQweB5YpsCGopfD9y06NIjlAbx1CBtberJU4 /jPidEFSO9z0evGTkYCfH5BdYQ3lLHgemLgmDk/CpOmABtnpG7bjBkapJ/X7 VdhAc2UfdhIR6Xy4LdFf2hx/zK4UvvVO2l704JUGUdkTjC+/Ep4Oo=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Barbara Isn't this a rulemaker decision (i.e., a policy configured in the LG/LS as to which to include or merge)? I think this should be the case. For example, AT&T (yeah, I'm picking on your company for no particular reason) might have a policy to trust any LLDP-MED LCI over DHCP LCI. In this case an AT&T device constructs the PIDF-LO from LLDP-MED if it used that LCP. Conversely, Sprint might have a policy stating that if there is a local GPS chip measuring location for the device, construct the PIDF-LO from that LI over anything else received. I think this is domain specific, based on the policy of the significant rulemaker (which should have some say so from the user, but maybe not in this case - because Joe Citizen doesn't know the difference or preference of the underlying network)... (the other) James At 07:14 AM 4/2/2008, Stark, Barbara wrote: >--- snip ----------- >PIDF-LO profile doesn't say how you determined which of these locations >from different sources is best, and I don't think it can. >Is it this latter piece of information you are seeking? >--- end snip ------- > >Yes. But in the form of a default recommendation that can be used in the >absence of any "real" knowledge. >Barbara > >***** > >The information transmitted is intended only for the person or >entity to which it is addressed and may contain confidential, >proprietary, and/or privileged material. Any review, retransmission, >dissemination or other use of, or taking of any action in reliance >upon this information by persons or entities other than the intended >recipient is prohibited. If you received this in error, please >contact the sender and delete the material from all computers. GA623 > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 3 04:52:32 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9C5628C64B; Thu, 3 Apr 2008 04:52:32 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C79228C64B for ; Thu, 3 Apr 2008 04:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.207 X-Spam-Level: X-Spam-Status: No, score=-102.207 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ZVmS94JVrc7v for ; Thu, 3 Apr 2008 04:52:31 -0700 (PDT) Received: from aismt07p.bellsouth.com (aismt07p.bellsouth.com [139.76.165.213]) by core3.amsl.com (Postfix) with ESMTP id CDE9128C62F for ; Thu, 3 Apr 2008 04:52:30 -0700 (PDT) Received: from ([139.76.131.31]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.198832336; Thu, 03 Apr 2008 07:52:14 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 3 Apr 2008 07:52:13 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 3 Apr 2008 07:52:14 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 07:52:13 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA04F17A5B@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: Multiple Location thread-index: AciVS9mfdccGG43vTfOpSEbEpCCTtQANU4Ti From: "Stark, Barbara" To: , , , X-OriginalArrivalTime: 03 Apr 2008 11:52:14.0082 (UTC) FILETIME=[2860EE20:01C89581] Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0134246543==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0134246543== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89581.27FA1842" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89581.27FA1842 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey Other James, I agree that there needs to be intelligence all over the place to try to = get the best location to a device in the first place.=20 In this thread, I'm really just focussing on stating that I've created = recommended behavior for generic end devices, just in case they do get = multiple locations. It could happen, and they need to have logic to = handle it. In my experience, a lack of recommendations for handling = things that shouldn't happen means that it'll happen more than we like, = and everyone will handle it differently, creating unpredictability.=20 It's no big deal. I'm not even asking for it in phonebcp. I'm just = mentioning that I've written such recommendations, and if others think = phonebcp should have them, I'll be happy to provide them. I think this = thread started when Hannes mentioned we didn't have such rules and asked = if they might be needed.=20 Barbara ----- Original Message ----- From: James M. Polk To: Stark, Barbara; Winterbottom, James ; = Hannes Tschofenig ; ecrit@ietf.org = Sent: Thu Apr 03 01:30:11 2008 Subject: Re: [Ecrit] Phone BCP: Multiple Location Barbara Isn't this a rulemaker decision (i.e., a policy configured in the=20 LG/LS as to which to include or merge)? I think this should be the case. For example, AT&T (yeah, I'm picking on your company for no=20 particular reason) might have a policy to trust any LLDP-MED LCI over=20 DHCP LCI. In this case an AT&T device constructs the PIDF-LO from=20 LLDP-MED if it used that LCP. Conversely, Sprint might have a policy stating that if there is a=20 local GPS chip measuring location for the device, construct the=20 PIDF-LO from that LI over anything else received. I think this is domain specific, based on the policy of the=20 significant rulemaker (which should have some say so from the user,=20 but maybe not in this case - because Joe Citizen doesn't know the=20 difference or preference of the underlying network)... (the other) James At 07:14 AM 4/2/2008, Stark, Barbara wrote: >--- snip ----------- >PIDF-LO profile doesn't say how you determined which of these locations >from different sources is best, and I don't think it can. >Is it this latter piece of information you are seeking? >--- end snip ------- > >Yes. But in the form of a default recommendation that can be used in = the >absence of any "real" knowledge. >Barbara > >***** > >The information transmitted is intended only for the person or=20 >entity to which it is addressed and may contain confidential,=20 >proprietary, and/or privileged material. Any review, retransmission,=20 >dissemination or other use of, or taking of any action in reliance=20 >upon this information by persons or entities other than the intended=20 >recipient is prohibited. If you received this in error, please=20 >contact the sender and delete the material from all computers. GA623 > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA625 ------_=_NextPart_001_01C89581.27FA1842 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] Phone BCP: Multiple Location

Hey Other James,
I agree that there needs to be intelligence all over the place to try to = get the best location to a device in the first place.
In this thread, I'm really just focussing on stating that I've created = recommended behavior for generic end devices, just in case they do get = multiple locations. It could happen, and they need to have logic to = handle it. In my experience, a lack of recommendations for handling = things that shouldn't happen means that it'll happen more than we like, = and everyone will handle it differently, creating unpredictability.
It's no big deal. I'm not even asking for it in phonebcp. I'm just = mentioning that I've written such recommendations, and if others think = phonebcp should have them, I'll be happy to provide them. I think this = thread started when Hannes mentioned we didn't have such rules and asked = if they might be needed.
Barbara

----- Original Message -----
From: James M. Polk <jmpolk@cisco.com>
To: Stark, Barbara; Winterbottom, James = <James.Winterbottom@andrew.com>; Hannes Tschofenig = <Hannes.Tschofenig@gmx.net>; ecrit@ietf.org = <ecrit@ietf.org>
Sent: Thu Apr 03 01:30:11 2008
Subject: Re: [Ecrit] Phone BCP: Multiple Location

Barbara

Isn't this a rulemaker decision (i.e., a policy configured in the
LG/LS as to which to include or merge)?

I think this should be the case.

For example, AT&T (yeah, I'm picking on your company for no
particular reason) might have a policy to trust any LLDP-MED LCI = over
DHCP LCI.  In this case an AT&T device constructs the PIDF-LO = from
LLDP-MED if it used that LCP.

Conversely, Sprint might have a policy stating that if there is a
local GPS chip measuring location for the device, construct the
PIDF-LO from that LI over anything else received.

I think this is domain specific, based on the policy of the
significant rulemaker (which should have some say so from the user,
but maybe not in this case - because Joe Citizen doesn't know the
difference or preference of the underlying network)...

(the other) James

At 07:14 AM 4/2/2008, Stark, Barbara wrote:

>--- snip -----------
>PIDF-LO profile doesn't say how you determined which of these = locations
>from different sources is best, and I don't think it can.
>Is it this latter piece of information you are seeking?
>--- end snip -------
>
>Yes. But in the form of a default recommendation that can be used in = the
>absence of any "real" knowledge.
>Barbara
>
>*****
>
>The information transmitted is intended only for the person or
>entity to which it is addressed and may contain confidential,
>proprietary, and/or privileged material. Any review, = retransmission,
>dissemination or other use of, or taking of any action in = reliance
>upon this information by persons or entities other than the = intended
>recipient is prohibited. If you received this in error, please
>contact the sender and delete the material from all computers. = GA623
>
>
>_______________________________________________
>Ecrit mailing list
>Ecrit@ietf.org
>https://www.ietf.org= /mailman/listinfo/ecrit

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. GA625

 ------_=_NextPart_001_01C89581.27FA1842-- --===============0134246543== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============0134246543==-- From ecrit-bounces@ietf.org Thu Apr 3 05:38:00 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A96A28C13F; Thu, 3 Apr 2008 05:38:00 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF963A69C9; Thu, 3 Apr 2008 05:37:59 -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 BCpDPxaZJR3B; Thu, 3 Apr 2008 05:37:58 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C46B83A6846; Thu, 3 Apr 2008 05:37:58 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Apr 2008 05:38:02 -0700 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 m33Cc2Rf032153; Thu, 3 Apr 2008 05:38:02 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.13.8/8.13.8) with SMTP id m33Cc1Nn009766; Thu, 3 Apr 2008 12:38:02 GMT Message-Id: <7E6ACFE7-BF6B-4AF8-9F36-9A70010502B9@cisco.com> From: Cullen Jennings To: ECRIT , GEOPRIV Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 05:37:43 -0700 References: <7582BC68E4994F4ABF0BD4723975C3FA080ECE71@crexc41p> X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=717; t=1207226282; x=1208090282; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Fwd=3A=20Liaison=20from=20DSL=20Forum=20to=20ec rit=20and=20geopriv |Sender:=20; bh=FQzyGvCSw5NT9OR9eGAMpMd+V3Ja/2YeuiXp21RSEFA=; b=suzVaMiZWKNtTPCxAHJnEjD8UambLq+/wwCMzY0JipaDkKJRJ4xxh612p5 ATaWMsnZnIudksyIAj6YtKBZufi2QXW982HMrhwD2W2fOuWevvttaSeQpwJW y6Ziv8bbuS; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Ecrit] Fwd: Liaison from DSL Forum to ecrit and geopriv X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Jon and I receive the following email with three files attached. I have removed the attachments form the email and put them and a PDF version of them at the following URL. http://idisk.mac.com/cullenfluffyjennings-Public?view=web Cullen Begin forwarded message: > From: "Stark, Barbara" > Date: March 28, 2008 12:53:23 PM PDT > To: , > Subject: Liaison from DSL Forum to ecrit and geopriv > > Jon, Cullen, > Attached is a liaison from the DSL Forum to ecrit and geopriv WGs > regarding IP device requirements for emergency services. If you could > pass it along to those groups, I'd appreciate it. > > Thanks, > Barbara > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 3 13:25:32 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D721C3A6BCE; Thu, 3 Apr 2008 13:25:32 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A9E53A6822 for ; Thu, 3 Apr 2008 13:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 pvD6GNkA5LtE for ; Thu, 3 Apr 2008 13:25:29 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id AAA7C3A6D0C for ; Thu, 3 Apr 2008 13:25:06 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Thu, 3 Apr 2008 13:25:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 13:25:05 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750982F0A1@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: Multiple Location Thread-Index: AciSoBSicmd+wT1mQom8/iePcnSz0wABYVlrACJtvEAAD6FFRAAMWCawAACTyqAAiXueIA== References: <47EFF025.9000705@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA080ECEF5@crexc41p><7582BC68E4994F4ABF0BD4723975C3FA083C6764@crexc41p> From: "Roger Marshall" To: "Winterbottom, James" , "Stark, Barbara" , "Hannes Tschofenig" , Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org [snip] > On Behalf Of Winterbottom, James > Sent: Monday, March 31, 2008 7:46 PM ... > I think the correct answer is that it should only try 3 > methods if the first 2 failed. That is, it tries one method, > if that doesn't work, it tries the next one. [/endsnip] I agree with you James, this seems practicle... but phonebcp recommends an opposite approach (along with your suggested approach). ED-22/INT-15 Endpoints SHOULD try all LCPs supported by the device in any order or in parallel. The first one that succeeds in supplying location can be used. I think it would be cleaner if Phonebcp recommended serial queries only - therefore avoiding most of the worry around choosing among different locations gotten from parallel requests. -roger. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Winterbottom, James > Sent: Monday, March 31, 2008 7:46 PM > To: Stark, Barbara; Hannes Tschofenig; ecrit@ietf.org > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > Hi Barbara, > > Having re-read your email I think I misunderstood what you > were saying. > I think what you are saying is that if a device engages all > three LCPs and gets a different location for each of them, > what does it do? > > I think the correct answer is that it should only try 3 > methods if the first 2 failed. That is, it tries one method, > if that doesn't work, it tries the next one. > > In the HELD routing/dispatch example I hope that we can say > always use dispatch since the dispatch location kind of needs > to fall into the catchment of the routing area to make any sense. > > I think we should avoid trying to get as many different > locations as we can. > > As for DHCP and LLDP-MED I am not sure that I understand your > last sentence in the first paragraph. I am not aware that we > considering sending a literal location in any form other than > a PIDF-LO with the sos message. > > Cheers > James > > > > -----Original Message----- > > From: Stark, Barbara [mailto:bs7652@att.com] > > Sent: Tuesday, 1 April 2008 1:30 PM > > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > Key words are "Where multiple PIDF documents can be sent or > received > > together". When a device has a configured location, a location from > > LLDP-MED, one from DHCP, and one or two (routing and dispatch) from > > HELD, I think that the quoted language has no relevance on the order > in > > which these are then included in an "sos" message. These different > > locations were not received together. LLDP-MED and DHCP > locations are > > not received as PIDF documents. > > > > This language does apply to the PSAP when it receives all of these > > locations. They arrive together, and all in PIDF format. > > Barbara > > > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Monday, March 31, 2008 4:29 PM > > To: Stark, Barbara; Hannes Tschofenig; ecrit@ietf.org > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > Nope. > > > > This is from PIDF-LO Profile > > > > " Rule #9: Where multiple PIDF documents can be sent or received > > together, say in a multi-part MIME body, and current location > > information is required by the recipient, then document > selection > > SHOULD be based on document order, with the first document > > considered first." > > > > Cheers > > James > > > > > > > > -----Original Message----- > > From: Stark, Barbara [mailto:bs7652@att.com] > > Sent: Mon 3/31/2008 8:05 AM > > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > It's my understanding that PIDF-LO only describes multiple location > > precedence within a single message. It doesn't describe how to > > prioritize multiple locations received from various > sources, received > > in multiple messages (or statically configured) at various times. > > > > I did include that sort of logic in my latest DSLF draft. > If there is > a > > desire to have some of this in phonebcp, I'm fine with that. > > Barbara > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Winterbottom, James > > Sent: Sunday, March 30, 2008 4:36 PM > > To: Hannes Tschofenig; ecrit@ietf.org > > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > > > PIDF-LO profile describes how to choose the correct location for > exactly > > this purpose. > > That is the application form which the original requirements were > drawn. > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > > Sent: Sun 3/30/2008 2:55 PM > > To: ecrit@ietf.org > > Subject: [Ecrit] Phone BCP: Multiple Location > > > > " > > ED-39 If a UA has more than one location available to it, it MUST > > choose one location to route the call towards the PSAP. > > > > SP-16 If a proxy inserts location on behalf of an > endpoint, and it > > has multiple locations available for the endpoint it MUST choose > one > > location to use to route the call towards the PSAP. > > " > > > > I could imagine that someone might ask how to make a decision. > > So, how does the decision making look like? > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > -------------------------------------------------------------- > ---------- > > ------------------------ > > This message is for the designated recipient only and may contain > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > immediately > > and delete the original. Any unauthorized use of this email is > > prohibited. > > > -------------------------------------------------------------- > ---------- > > ------------------------ > > [mf2] > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > -------------------------------------------------------------- > ---------- > > ------------------------ > > This message is for the designated recipient only and may contain > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > immediately > > and delete the original. Any unauthorized use of this email is > > prohibited. > > > -------------------------------------------------------------- > ---------- > > ------------------------ > > [mf2] > > > > > > ***** > > > > The information transmitted is intended only for the person > or entity > to > > which it is addressed and may contain confidential, proprietary, > and/or > > privileged material. Any review, retransmission, dissemination or > other > > use of, or taking of any action in reliance upon this > information by > > persons or entities other than the intended recipient is prohibited. > If > > you received this in error, please contact the sender and > delete the > > material from all computers. GA622 > > > > > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 3 13:37:50 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3F603A6C7F; Thu, 3 Apr 2008 13:37:50 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3943A6C7C for ; Thu, 3 Apr 2008 13:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezdatnVfsTna for ; Thu, 3 Apr 2008 13:37:48 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 5B5343A6925 for ; Thu, 3 Apr 2008 13:37:48 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 03 Apr 2008 13:37:52 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m33KbqNC012299; Thu, 3 Apr 2008 13:37:52 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m33Kbkre000835; Thu, 3 Apr 2008 20:37:52 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 16:37:51 -0400 Received: from mlinsnerwxp02 ([10.82.170.67]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 16:37:51 -0400 From: "Marc Linsner" To: "'Roger Marshall'" , "'Winterbottom, James'" , Date: Thu, 3 Apr 2008 16:37:50 -0400 Message-ID: <00bf01c895ca$95a378b0$300d0d0a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <8C837214C95C864C9F34F3635C2A65750982F0A1@SEA-EXCHVS-2.telecomsys.com> Thread-Index: AciSoBSicmd+wT1mQom8/iePcnSz0wABYVlrACJtvEAAD6FFRAAMWCawAACTyqAAiXueIAAAipQA X-OriginalArrivalTime: 03 Apr 2008 20:37:51.0417 (UTC) FILETIME=[96185A90:01C895CA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9790; t=1207255072; x=1208119072; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20Phone=20BCP=3A=20Multiple=20L ocation |Sender:=20; bh=EKI1F0JfoqKCnVgcgpkUyiaUHSXCP1I9BsHTzIK24Q4=; b=OCy5qLbIGAwqd2DaVsoZ4swq+ljnX8sum/GNLFC6oU3Khs1T/i0yzsy/RZ KMPUaUZchEazkVhfkwhKediwgANQ1CWng9ZbbqOQykr+psyA1fdRMzwzuBsU byYCTEaPtt9LakB7vCj55LuG/j7DTmAaTby3fji8weND8iAzfCbdM=; Authentication-Results: sj-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Roger, James, You are simply moving the problem. You are stating you don't want to tax the target by making it chose between multiple locations, but you are asking the target to chose between multiple LCP mechanisms. I don't see any difference in the algorithm between choosing between multiple locations or choosing between multiple LCPs. Am I missing something? -Marc- > > [snip] > > On Behalf Of Winterbottom, James > > Sent: Monday, March 31, 2008 7:46 PM > ... > > I think the correct answer is that it should only try 3 > methods if the > > first 2 failed. That is, it tries one method, if that > doesn't work, it > > tries the next one. > [/endsnip] > > I agree with you James, this seems practicle... but phonebcp > recommends an opposite approach (along with your suggested approach). > > ED-22/INT-15 Endpoints SHOULD try all LCPs supported by > the device in > any order or in parallel. The first one that succeeds in supplying > location can be used. > > I think it would be cleaner if Phonebcp recommended serial > queries only > - therefore avoiding most of the worry around choosing among > different locations gotten from parallel requests. > > -roger. > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Winterbottom, James > > Sent: Monday, March 31, 2008 7:46 PM > > To: Stark, Barbara; Hannes Tschofenig; ecrit@ietf.org > > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > > > Hi Barbara, > > > > Having re-read your email I think I misunderstood what you were > > saying. > > I think what you are saying is that if a device engages all > three LCPs > > and gets a different location for each of them, what does it do? > > > > I think the correct answer is that it should only try 3 > methods if the > > first 2 failed. That is, it tries one method, if that > doesn't work, it > > tries the next one. > > > > In the HELD routing/dispatch example I hope that we can say > always use > > dispatch since the dispatch location kind of needs to fall into the > > catchment of the routing area to make any sense. > > > > I think we should avoid trying to get as many different > locations as > > we can. > > > > As for DHCP and LLDP-MED I am not sure that I understand your last > > sentence in the first paragraph. I am not aware that we considering > > sending a literal location in any form other than a PIDF-LO > with the > > sos message. > > > > Cheers > > James > > > > > > > -----Original Message----- > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > Sent: Tuesday, 1 April 2008 1:30 PM > > > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > Key words are "Where multiple PIDF documents can be sent or > > received > > > together". When a device has a configured location, a > location from > > > LLDP-MED, one from DHCP, and one or two (routing and > dispatch) from > > > HELD, I think that the quoted language has no relevance > on the order > > in > > > which these are then included in an "sos" message. These > different > > > locations were not received together. LLDP-MED and DHCP > > locations are > > > not received as PIDF documents. > > > > > > This language does apply to the PSAP when it receives all > of these > > > locations. They arrive together, and all in PIDF format. > > > Barbara > > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Monday, March 31, 2008 4:29 PM > > > To: Stark, Barbara; Hannes Tschofenig; ecrit@ietf.org > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > Nope. > > > > > > This is from PIDF-LO Profile > > > > > > " Rule #9: Where multiple PIDF documents can be sent or received > > > together, say in a multi-part MIME body, and > current location > > > information is required by the recipient, then document > > selection > > > SHOULD be based on document order, with the first document > > > considered first." > > > > > > Cheers > > > James > > > > > > > > > > > > -----Original Message----- > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > Sent: Mon 3/31/2008 8:05 AM > > > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > It's my understanding that PIDF-LO only describes > multiple location > > > precedence within a single message. It doesn't describe how to > > > prioritize multiple locations received from various > > sources, received > > > in multiple messages (or statically configured) at various times. > > > > > > I did include that sort of logic in my latest DSLF draft. > > If there is > > a > > > desire to have some of this in phonebcp, I'm fine with that. > > > Barbara > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Winterbottom, James > > > Sent: Sunday, March 30, 2008 4:36 PM > > > To: Hannes Tschofenig; ecrit@ietf.org > > > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > > > > > PIDF-LO profile describes how to choose the correct location for > > exactly > > > this purpose. > > > That is the application form which the original requirements were > > drawn. > > > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > > > Sent: Sun 3/30/2008 2:55 PM > > > To: ecrit@ietf.org > > > Subject: [Ecrit] Phone BCP: Multiple Location > > > > > > " > > > ED-39 If a UA has more than one location available to > it, it MUST > > > choose one location to route the call towards the PSAP. > > > > > > SP-16 If a proxy inserts location on behalf of an > > endpoint, and it > > > has multiple locations available for the endpoint it > MUST choose > > one > > > location to use to route the call towards the PSAP. > > > " > > > > > > I could imagine that someone might ask how to make a decision. > > > So, how does the decision making look like? > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > > ------------------------ > > > This message is for the designated recipient only and may contain > > > privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > immediately > > > and delete the original. Any unauthorized use of this email is > > > prohibited. > > > > > -------------------------------------------------------------- > > ---------- > > > ------------------------ > > > [mf2] > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > > ------------------------ > > > This message is for the designated recipient only and may contain > > > privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > immediately > > > and delete the original. Any unauthorized use of this email is > > > prohibited. > > > > > -------------------------------------------------------------- > > ---------- > > > ------------------------ > > > [mf2] > > > > > > > > > ***** > > > > > > The information transmitted is intended only for the person > > or entity > > to > > > which it is addressed and may contain confidential, proprietary, > > and/or > > > privileged material. Any review, retransmission, dissemination or > > other > > > use of, or taking of any action in reliance upon this > > information by > > > persons or entities other than the intended recipient is > prohibited. > > If > > > you received this in error, please contact the sender and > > delete the > > > material from all computers. GA622 > > > > > > > > > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may contain > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > immediately > > and delete the original. Any unauthorized use of this email is > > prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > CONFIDENTIALITY NOTICE: The information contained in this > message may be privileged and/or confidential. If you are not > the intended recipient, or responsible for delivering this > message to the intended recipient, any review, forwarding, > dissemination, distribution or copying of this communication > or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender > immediately, and delete it and all attachments from your > computer and network. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 4 12:34:12 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8506028C52A; Fri, 4 Apr 2008 12:34:12 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEBD328C527 for ; Fri, 4 Apr 2008 12:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.078, 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 CsGv85umCOHM for ; Fri, 4 Apr 2008 12:34:10 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id 2C1313A69A1 for ; Fri, 4 Apr 2008 12:34:10 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Fri, 4 Apr 2008 12:34:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 12:34:15 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750982F52A@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <00bf01c895ca$95a378b0$300d0d0a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: Multiple Location Thread-Index: AciSoBSicmd+wT1mQom8/iePcnSz0wABYVlrACJtvEAAD6FFRAAMWCawAACTyqAAiXueIAAAipQAADAhwqA= References: <8C837214C95C864C9F34F3635C2A65750982F0A1@SEA-EXCHVS-2.telecomsys.com> <00bf01c895ca$95a378b0$300d0d0a@cisco.com> From: "Roger Marshall" To: "Marc Linsner" , "Winterbottom, James" , Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org My objection is to a written *recommendation* that directs the client to act serially OR act in parallel - as opposed to what, (guessing, since not stated) recommending an ordered list of configuration protocol candidates? Better to recommend one thing to do, allow another. -roger. > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Thursday, April 03, 2008 1:38 PM > To: Roger Marshall; 'Winterbottom, James'; ecrit@ietf.org > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > Roger, James, > > You are simply moving the problem. You are stating you don't > want to tax the target by making it chose between multiple > locations, but you are asking > the target to chose between multiple LCP mechanisms. I don't see any > difference in the algorithm between choosing between multiple > locations or choosing between multiple LCPs. > > Am I missing something? > > -Marc- > > > > > [snip] > > > On Behalf Of Winterbottom, James > > > Sent: Monday, March 31, 2008 7:46 PM > > ... > > > I think the correct answer is that it should only try 3 > > methods if the > > > first 2 failed. That is, it tries one method, if that > > doesn't work, it > > > tries the next one. > > [/endsnip] > > > > I agree with you James, this seems practicle... but phonebcp > > recommends an opposite approach (along with your suggested > approach). > > > > ED-22/INT-15 Endpoints SHOULD try all LCPs supported by > the device > > in > > any order or in parallel. The first one that succeeds > in supplying > > location can be used. > > > > I think it would be cleaner if Phonebcp recommended serial queries > > only > > - therefore avoiding most of the worry around choosing > among different > > locations gotten from parallel requests. > > > > -roger. > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Winterbottom, James > > > Sent: Monday, March 31, 2008 7:46 PM > > > To: Stark, Barbara; Hannes Tschofenig; ecrit@ietf.org > > > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > > > > > Hi Barbara, > > > > > > Having re-read your email I think I misunderstood what you were > > > saying. > > > I think what you are saying is that if a device engages all > > three LCPs > > > and gets a different location for each of them, what does it do? > > > > > > I think the correct answer is that it should only try 3 > > methods if the > > > first 2 failed. That is, it tries one method, if that > > doesn't work, it > > > tries the next one. > > > > > > In the HELD routing/dispatch example I hope that we can say > > always use > > > dispatch since the dispatch location kind of needs to > fall into the > > > catchment of the routing area to make any sense. > > > > > > I think we should avoid trying to get as many different > > locations as > > > we can. > > > > > > As for DHCP and LLDP-MED I am not sure that I understand > your last > > > sentence in the first paragraph. I am not aware that we > considering > > > sending a literal location in any form other than a PIDF-LO > > with the > > > sos message. > > > > > > Cheers > > > James > > > > > > > > > > -----Original Message----- > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > Sent: Tuesday, 1 April 2008 1:30 PM > > > > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > > > Key words are "Where multiple PIDF documents can be sent or > > > received > > > > together". When a device has a configured location, a > > location from > > > > LLDP-MED, one from DHCP, and one or two (routing and > > dispatch) from > > > > HELD, I think that the quoted language has no relevance > > on the order > > > in > > > > which these are then included in an "sos" message. These > > different > > > > locations were not received together. LLDP-MED and DHCP > > > locations are > > > > not received as PIDF documents. > > > > > > > > This language does apply to the PSAP when it receives all > > of these > > > > locations. They arrive together, and all in PIDF format. > > > > Barbara > > > > > > > > -----Original Message----- > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > Sent: Monday, March 31, 2008 4:29 PM > > > > To: Stark, Barbara; Hannes Tschofenig; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > > > Nope. > > > > > > > > This is from PIDF-LO Profile > > > > > > > > " Rule #9: Where multiple PIDF documents can be sent > or received > > > > together, say in a multi-part MIME body, and > > current location > > > > information is required by the recipient, then document > > > selection > > > > SHOULD be based on document order, with the first > document > > > > considered first." > > > > > > > > Cheers > > > > James > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > Sent: Mon 3/31/2008 8:05 AM > > > > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > > > It's my understanding that PIDF-LO only describes > > multiple location > > > > precedence within a single message. It doesn't describe how to > > > > prioritize multiple locations received from various > > > sources, received > > > > in multiple messages (or statically configured) at > various times. > > > > > > > > I did include that sort of logic in my latest DSLF draft. > > > If there is > > > a > > > > desire to have some of this in phonebcp, I'm fine with that. > > > > Barbara > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of Winterbottom, James > > > > Sent: Sunday, March 30, 2008 4:36 PM > > > > To: Hannes Tschofenig; ecrit@ietf.org > > > > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > > > > > > > PIDF-LO profile describes how to choose the correct location for > > > exactly > > > > this purpose. > > > > That is the application form which the original > requirements were > > > drawn. > > > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > > > > Sent: Sun 3/30/2008 2:55 PM > > > > To: ecrit@ietf.org > > > > Subject: [Ecrit] Phone BCP: Multiple Location > > > > > > > > " > > > > ED-39 If a UA has more than one location available to > > it, it MUST > > > > choose one location to route the call towards the PSAP. > > > > > > > > SP-16 If a proxy inserts location on behalf of an > > > endpoint, and it > > > > has multiple locations available for the endpoint it > > MUST choose > > > one > > > > location to use to route the call towards the PSAP. > > > > " > > > > > > > > I could imagine that someone might ask how to make a decision. > > > > So, how does the decision making look like? > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > ---------- > > > > ------------------------ > > > > This message is for the designated recipient only and > may contain > > > > privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > immediately > > > > and delete the original. Any unauthorized use of this email is > > > > prohibited. > > > > > > > -------------------------------------------------------------- > > > ---------- > > > > ------------------------ > > > > [mf2] > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > ---------- > > > > ------------------------ > > > > This message is for the designated recipient only and > may contain > > > > privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > immediately > > > > and delete the original. Any unauthorized use of this email is > > > > prohibited. > > > > > > > -------------------------------------------------------------- > > > ---------- > > > > ------------------------ > > > > [mf2] > > > > > > > > > > > > ***** > > > > > > > > The information transmitted is intended only for the person > > > or entity > > > to > > > > which it is addressed and may contain confidential, proprietary, > > > and/or > > > > privileged material. Any review, retransmission, > dissemination or > > > other > > > > use of, or taking of any action in reliance upon this > > > information by > > > > persons or entities other than the intended recipient is > > prohibited. > > > If > > > > you received this in error, please contact the sender and > > > delete the > > > > material from all computers. GA622 > > > > > > > > > > > > > > -------------------------------------------------------------- > > > ---------------------------------- > > > This message is for the designated recipient only and may contain > > > privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > immediately > > > and delete the original. Any unauthorized use of this email is > > > prohibited. > > > -------------------------------------------------------------- > > > ---------------------------------- > > > [mf2] > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > message may > > be privileged and/or confidential. If you are not the intended > > recipient, or responsible for delivering this message to > the intended > > recipient, any review, forwarding, dissemination, distribution or > > copying of this communication or any attachment(s) is strictly > > prohibited. If you have received this message in error, > please notify > > the sender immediately, and delete it and all attachments from your > > computer and network. > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 4 13:07:02 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CE083A6FD5; Fri, 4 Apr 2008 13:07:02 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 869CA3A6D4E for ; Fri, 4 Apr 2008 13:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.785, 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 j5vwrxFmowyw for ; Fri, 4 Apr 2008 13:06:44 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 40A7428C4E4 for ; Fri, 4 Apr 2008 13:05:18 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JhsA2-0001Za-7I; Fri, 04 Apr 2008 15:05:18 -0500 From: "Brian Rosen" To: "'Stark, Barbara'" , "'Hannes Tschofenig'" , References: <47EF9E65.1090402@gmx.net> <006101c89294$b45036b0$9744f444@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA080ECF11@crexc41p> Date: Fri, 4 Apr 2008 16:05:20 -0400 Message-ID: <01d601c8968f$37ba38e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA080ECF11@crexc41p> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AciSb0jFlOgz5NA4RaqbA9nfmYGMvgAJC8bwACZT2rAA2EUNYA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] ECRIT Framework: Dial Strings X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If you are currently located in the U.S., I believe it is a regulation that 9-1-1 work from a telephone. Not 9-9-9, but 9-1-1. If you are in the U.K., I suspect that it is required that 9-9-9 work. The regulation is of course, antiquated, and doesn't really speak to current technology capabilities. If you are a customer of a U.S. carrier, but you have roamed to the U.K., there is no requirement that 9-1-1 work, but there is a requirement that 9-9-9 work. That is in current regs. That is more or less a by-product of how roaming is implemented in mobile telephone networks, but the reality is that local is required. I wouldn't presume to speak for any U.S. government agency, but I've had some discussions on the subject, and I think they don't care what happens when a customer of a U.S. carrier is located in the U.K., but they do care what happens when a customer of a U.K. carrier is located in the U.S. They want 9-1-1 to work. I know that's how NENA feels. Brian -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Monday, March 31, 2008 9:29 AM To: Brian Rosen; Hannes Tschofenig; ecrit@ietf.org Subject: RE: [Ecrit] ECRIT Framework: Dial Strings I'm not aware of any country that requires that companies operating in foreign countries recognize "local" dial strings, when their customers are traveling into the "local" country. Likewise, I'm not aware of any country that has emergency dialing legislation regarding devices that visitors bring into the country or that residents bring in from foreign countries. I think the "legal requirements" argument is empty. But I don't see that requiring end devices to request local dial strings is a bad thing. I also think that there's a strong likelihood that "home" governments will require "home" service providers and "home" devices to support "home" dial strings, no matter where the device may go. Since the BCP doesn't preclude this, and sufficiently describes how this can be done, I'm ok with the phonebcp language. So, I'm fine with the requirements as they are. But I still think that this "legal" argument is backwards and incorrect. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Sunday, March 30, 2008 2:35 PM To: 'Hannes Tschofenig'; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Framework: Dial Strings No current systems recognize the home dial string unless they happen to be the same, or there is some fixed strings always recognized. There are legal requirements for the local one, and there are none for the home one. Unless you have some good reason, I think there is no requirement to support the home dial string. I'm not even sure it's a good idea. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 10:06 AM To: ecrit@ietf.org Subject: [Ecrit] ECRIT Framework: Dial Strings You write: " Therefore, the visited dial string must work while having the home dial string work is optional. " I don't understand this reasoning on why the home dial string is optional. From an implementation point of view you have to implement the home emergency dial strings since in most cases devices will be used "at home". Why isn't the ability to understand the home dial string mandatory? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 4 13:13:06 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F8C03A6E13; Fri, 4 Apr 2008 13:13:06 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65BA43A6FA9 for ; Fri, 4 Apr 2008 13:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 TPkqEN5aABpR for ; Fri, 4 Apr 2008 13:13:03 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id 0AC203A6C65 for ; Fri, 4 Apr 2008 13:13:02 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Fri, 4 Apr 2008 13:13:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 13:13:08 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750982F583@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Transition Support Issue Thread-Index: AciVB/zGjHp+d4rjTxaxiiulJ1iGPwBhjDAg References: <47E023F9.8040900@gmx.net><045701c88938$e0bdd410$640fa8c0@cis.neustar.com ><047201c8893c $2c336d30$640fa8c0@cis.neustar.com><47E0DD97.6090603@gmx.net><8C837214C95C 864C9F34F3635C2A6575097BA424@SEA-EXCHVS-2.telecomsys.com> <04b801c89506$41c374d0$6901a8c0@cis.neustar.com> From: "Roger Marshall" To: "Ted Hardie" , "Brian Rosen" , "Winterbottom, James" , Subject: Re: [Ecrit] LoST Transition Support Issue X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yep, I agree what you're saying makes sense. Without some sort of alternate protocol sub-type identifier, it just wouldn't work anyway. It would be nice to understand, maybe from some bcp point of view, the different use cases for iterative mode, beside "We have temporarily failed over.", as is given by (-09 section 13.3) example, since it wasn't my impression that this is the primary technique of resolving to another LoST server (via DNS). Please correct me if not so. Also, section 14., paragraph 3, last sentence, the phrase "specific service" threw me a little. It must therefore be meant as "specific LoST service". "Where an HTTP-layer redirect will be general, a LoST server redirect as described in 13.3 might be specific to a specific service or be the result of other processing by the LoST server." Thanks. -roger marshall. > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Wednesday, April 02, 2008 2:25 PM > To: Brian Rosen; 'Winterbottom, James'; Roger Marshall; ecrit@ietf.org > Subject: RE: [Ecrit] LoST Transition Support Issue > > At 2:12 PM -0700 4/2/08, Brian Rosen wrote: > >I don't think this works at all. > > Well, I can't top that for a comment, but I also have some > serious issues with the proposal. If adopted, I don't see > how it limits what application unique strings are returned; > since a sane processing engine wouldn't bother dereferencing > an application unique string for a protocol it wasn't going > to be able to use at the end of the day, that's not great. > At a minimum, you would need to define what protocol was > going to be used once the were complete. Given > that, it does seem simpler to return a URI in the LoST > response that tells the end system how to contact that PSAP > via whatever system it needs to use. If it's not going to > understand that kind of response, it's not going to > understand a pointer to a second system which is going to > give it that response once it gets there. > > regards, > Ted > > > > > >First of all, the LoST server either is run by the VPC, or > it's run by > >something like the 9-1-1 Authority. The latter is where we > are headed > >with i3. > > > >If the 9-1-1 Authority runs it, then it can't refer the query to the > >VPC, because it doesn't know which VPC. We'll have to > decide (in NENA) > >what we do in the cases where there is no URI yet for a particular > >PSAP. One possibility is to return some fixed, non-globally > resolvable > >URI. The carrier could provide its own resolution of that > URI to its > >VPC. That could just be a default LoST return, rather than > a redirect. > > > >If the VPC runs it, it can put some appropriate URI in the > LoST return > >to get the right thing to happen. > > > >However, let's just say that somehow we do want to do a > . It > >still has to be a LoST server, because that's what the > client is going > >to do with it. If you want to send the call to some URI, > that has to > >be the output of a LoST server and not a redirect. So, I think the > >wording is correct as written. > > > >Brian > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf > >Of Winterbottom, James > >Sent: Wednesday, April 02, 2008 4:38 PM > >To: Roger Marshall; ecrit@ietf.org; Ted Hardie > >Subject: Re: [Ecrit] LoST Transition Support Issue > > > >Hi Roger, > > > >My only concern with this, is that in i2 an end-point doesn't talk > >directly to a VPC, it talks to a VSP Call-Server that has > several ways > >that it can talk with a VPC. Your proposed text change implies, at > >least to me, that the end-point would direct the request to > the VPC, I > >am not sure that I would be in favour of that model in the i2 space. > > > >Cheers > >James > > > > > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org on behalf of Roger Marshall > >Sent: Wed 4/2/2008 2:42 PM > >To: ecrit@ietf.org; Ted Hardie > >Subject: [Ecrit] LoST Transition Support Issue > > > >Late comment to > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-09.txt > > > >I am requesting a simple text change to support adaptability of LoST > >during transition stage between non-IP PSAPs and IP-based PSAPs. > > > >Scenario: > >If an IP-originated emergency call uses the LoST service to provide > >routing instructions for routing the call to a region > appropriate PSAP, > >yet that particular PSAP doesn't yet support IP, there needs to be a > >way within the LoST protocol to be able to still complete the call. > >One simple way is to redirect to another kind of server which can > >provide supplemental routing instructions to a non-IP PSAP > (e.g., for > >North American, the NENA i2 VPC). Currently, the LoST draft would > >support this special kind of redirect, given single wording change: > > > >Proposal: Change text in the paragraph below, > >From: "LoST application unique string (see Section 4)" > >To: "application unique string (see Section 4)" > > > >13.3. Redirects > > > > A LoST server can respond indicating that the querier > should redirect > > the query to another server, using the element. The > > element includes a 'target' attribute indicating the LoST > application > > unique string (see Section 4) that the client SHOULD be contacting > > next, as well as the 'source' attribute indicating the server that > > generated the redirect response and a 'message' attribute > explaining > > the reason for the redirect response. > > > >-roger marshall. > > > > > >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 > > > > > >------------------------------------------------------------- > ---------- > >----- > >-------------------- > >This message is for the designated recipient only and may contain > >privileged, proprietary, or otherwise private information. > >If you have received it in error, please notify the sender > immediately > >and delete the original. Any unauthorized use of this email is > >prohibited. > >------------------------------------------------------------- > ---------- > >----- > >-------------------- > >[mf2] > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 4 13:16:51 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC8493A6988; Fri, 4 Apr 2008 13:16:51 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E82103A68BA for ; Fri, 4 Apr 2008 13:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guXhLC4DrMFv for ; Fri, 4 Apr 2008 13:16:49 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id EA10B3A69C2 for ; Fri, 4 Apr 2008 13:16:48 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Fri, 4 Apr 2008 13:16:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 13:16:54 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750982F58F@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Transition Support Issue Thread-Index: AciVB/lpkpHQ2eEzSyK/Ep/oBVnVAAABozwgAGCMB+A= References: <47E023F9.8040900@gmx.net><045701c88938$e0bdd410$640fa8c0@cis.neustar.com ><047201c8893c $2c336d30$640fa8c0@cis.neustar.com><47E0DD97.6090603@gmx.net><8C837214C95C 864C9F34F3635C2A6575097BA424@SEA-EXCHVS-2.telecomsys.com> <04b801c89506$41c374d0$6901a8c0@cis.neustar.com> From: "Roger Marshall" To: "Winterbottom, James" , "Ted Hardie" , "Brian Rosen" , Subject: Re: [Ecrit] LoST Transition Support Issue X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org It's certainly another approach - looks like the right one. Thanks. -roger marshall. > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Wednesday, April 02, 2008 3:14 PM > To: Ted Hardie; Brian Rosen; Roger Marshall; ecrit@ietf.org > Subject: RE: [Ecrit] LoST Transition Support Issue > > Indeed, you could just as well have the LoST server return an ESRD (or > similar) encoded as a tel uri, and doesn't the problem then > kind of go away? Getting location to the PSAP of course then > become the challenge, but that is a different problem. > > Cheers > James > > > -----Original Message----- > > From: Ted Hardie [mailto:hardie@qualcomm.com] > > Sent: Thursday, 3 April 2008 8:25 AM > > To: Brian Rosen; Winterbottom, James; 'Roger Marshall'; > ecrit@ietf.org > > Subject: RE: [Ecrit] LoST Transition Support Issue > > > > At 2:12 PM -0700 4/2/08, Brian Rosen wrote: > > >I don't think this works at all. > > > > Well, I can't top that for a comment, but I also have some serious > issues > > with the proposal. If adopted, I don't see how it limits what > application > > unique strings are returned; since a sane processing engine > wouldn't > > bother dereferencing an application unique string for a protocol it > > wasn't going to be able to use at the end of the day, that's not > great. > > At a minimum, you would need to define what protocol was > going to be > > used once the were complete. Given that, it does seem > > simpler to return a URI in the LoST response that tells the > end system > > how to contact that PSAP via whatever system it needs to > use. If it's > > not going to understand that kind of > response, > > it's not going to understand a pointer to a second system which is > > going to give it that response once it gets there. > > > > regards, > > Ted > > > > > > > > > > >First of all, the LoST server either is run by the VPC, or it's run > by > > >something like the 9-1-1 Authority. The latter is where we are > headed > > with > > >i3. > > > > > >If the 9-1-1 Authority runs it, then it can't refer the > query to the > VPC, > > >because it doesn't know which VPC. We'll have to decide (in NENA) > what > > we > > >do in the cases where there is no URI yet for a particular > PSAP. One > > >possibility is to return some fixed, non-globally resolvable URI. > The > > >carrier could provide its own resolution of that URI to its VPC. > That > > could > > >just be a default LoST return, rather than a redirect. > > > > > >If the VPC runs it, it can put some appropriate URI in the LoST > return to > > >get the right thing to happen. > > > > > >However, let's just say that somehow we do want to do a . > It > > >still has to be a LoST server, because that's what the client is > going to > > do > > >with it. If you want to send the call to some URI, that has to be > the > > >output of a LoST server and not a redirect. So, I think > the wording > is > > >correct as written. > > > > > >Brian > > > > > >-----Original Message----- > > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of > > >Winterbottom, James > > >Sent: Wednesday, April 02, 2008 4:38 PM > > >To: Roger Marshall; ecrit@ietf.org; Ted Hardie > > >Subject: Re: [Ecrit] LoST Transition Support Issue > > > > > >Hi Roger, > > > > > >My only concern with this, is that in i2 an end-point doesn't talk > > directly > > >to a VPC, it talks to a VSP Call-Server that has several > ways that it > can > > >talk with a VPC. Your proposed text change implies, at least to me, > that > > the > > >end-point would direct the request to the VPC, I am not sure that I > would > > be > > >in favour of that model in the i2 space. > > > > > >Cheers > > >James > > > > > > > > > > > >-----Original Message----- > > >From: ecrit-bounces@ietf.org on behalf of Roger Marshall > > >Sent: Wed 4/2/2008 2:42 PM > > >To: ecrit@ietf.org; Ted Hardie > > >Subject: [Ecrit] LoST Transition Support Issue > > > > > >Late comment to > > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-09.txt > > > > > >I am requesting a simple text change to support > adaptability of LoST > > >during transition stage between non-IP PSAPs and IP-based PSAPs. > > > > > >Scenario: > > >If an IP-originated emergency call uses the LoST service > to provide > > >routing instructions for routing the call to a region appropriate > PSAP, > > >yet that particular PSAP doesn't yet support IP, there > needs to be a > way > > >within the LoST protocol to be able to still complete the > call. One > > >simple way is to redirect to another kind of server which > can provide > > >supplemental routing instructions to a non-IP PSAP (e.g., > for North > > >American, the NENA i2 VPC). Currently, the LoST draft > would support > > >this special kind of redirect, given single wording change: > > > > > >Proposal: Change text in the paragraph below, > > >From: "LoST application unique string (see Section 4)" > > >To: "application unique string (see Section 4)" > > > > > >13.3. Redirects > > > > > > A LoST server can respond indicating that the querier should > redirect > > > the query to another server, using the element. The > > > element includes a 'target' attribute indicating the LoST > application > > > unique string (see Section 4) that the client SHOULD be > contacting > > > next, as well as the 'source' attribute indicating the > server that > > > generated the redirect response and a 'message' attribute > explaining > > > the reason for the redirect response. > > > > > >-roger marshall. > > > > > > > > >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 > > > > > > > > > >------------------------------------------------------------- > ---------- > -- > > --- > > >-------------------- > > >This message is for the designated recipient only and may contain > > >privileged, proprietary, or otherwise private information. > > >If you have received it in error, please notify the sender > > >immediately and delete the original. Any unauthorized use of this > > >email is prohibited. > > > >------------------------------------------------------------- > ---------- > -- > > --- > > >-------------------- > > >[mf2] > > > > > >_______________________________________________ > > >Ecrit mailing list > > >Ecrit@ietf.org > > >https://www.ietf.org/mailman/listinfo/ecrit > > > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 4 13:23:28 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A35983A6884; Fri, 4 Apr 2008 13:23:28 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB3C33A6884 for ; Fri, 4 Apr 2008 13:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYJDnSOJdeEG for ; Fri, 4 Apr 2008 13:23:25 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id 7DD7E3A6840 for ; Fri, 4 Apr 2008 13:23:25 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Fri, 4 Apr 2008 13:23:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 13:23:30 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750982F59D@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Transition Support Issue Thread-Index: AciVB/lpkpHQ2eEzSyK/Ep/oBVnVAAABozwgAArYseAAVci1UA== References: <47E023F9.8040900@gmx.net><045701c88938$e0bdd410$640fa8c0@cis.neustar.com><047201c8893c$2c336d30$640fa8c0@cis.neustar.com><47E0DD97.6090603@gmx.net><8C837214C95C864C9F34F3635C2A6575097BA424@SEA-EXCHVS-2.telecomsys.com><04b801c89506$41c374d0$6901a8c0@cis.neustar.com> From: "Roger Marshall" To: "Dawson, Martin" , "Winterbottom, James" , "Ted Hardie" , "Brian Rosen" , Subject: Re: [Ecrit] LoST Transition Support Issue X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Martin: Agree that this is another viable approach, though admittedly not popular here. The LoST-based architecture is an IETF 'pure-play'. I look forward to more transition discussion, since getting there will take some time. Thanks. -roger marshall. > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Wednesday, April 02, 2008 8:32 PM > To: Winterbottom, James; Ted Hardie; Brian Rosen; Roger > Marshall; ecrit@ietf.org > Subject: RE: [Ecrit] LoST Transition Support Issue > > If the PSAP is not "ECRIT capable" - and this involves more > than just being an "IP PSAP" - then it shouldn't resolve from LoST. > > I think the proper transitional situation is for VSPs to try ECRIT > (LoST) and if the route doesn't resolve, to fall back to a > VPC request. > VSPs nominate their own VPC (and ESGW and/or proxy) > providers, so the LoST server can't nominate a VPC for them. > Actually, for quite some time, it may make the most sense for > the VSP to use i2/VPC first and make ECRIT the fallback. > > In my view, ideally, an ECRIT-capable emergency client will > have found and used the LoST service and sent the call > directly to the PSAP in an ECRIT-capable catchment area > anyway. That is, the VSP should only be involved if that > doesn't apply and the call does require i2-type handling. I > know - that's still semi-heretical by the BCP, but I still > think it's correct and would lead to a more stable long term > situation. > > Cheers, > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Winterbottom, James > Sent: Thursday, 3 April 2008 9:14 AM > To: Ted Hardie; Brian Rosen; Roger Marshall; ecrit@ietf.org > Subject: Re: [Ecrit] LoST Transition Support Issue > > Indeed, you could just as well have the LoST server return an ESRD (or > similar) encoded as a tel uri, and doesn't the problem then > kind of go away? Getting location to the PSAP of course then > become the challenge, but that is a different problem. > > Cheers > James > > > -----Original Message----- > > From: Ted Hardie [mailto:hardie@qualcomm.com] > > Sent: Thursday, 3 April 2008 8:25 AM > > To: Brian Rosen; Winterbottom, James; 'Roger Marshall'; > ecrit@ietf.org > > Subject: RE: [Ecrit] LoST Transition Support Issue > > > > At 2:12 PM -0700 4/2/08, Brian Rosen wrote: > > >I don't think this works at all. > > > > Well, I can't top that for a comment, but I also have some serious > issues > > with the proposal. If adopted, I don't see how it limits what > application > > unique strings are returned; since a sane processing engine > wouldn't > > bother dereferencing an application unique string for a protocol it > > wasn't going to be able to use at the end of the day, that's not > great. > > At a minimum, you would need to define what protocol was > going to be > > used once the were complete. Given that, it does seem > > simpler to return a URI in the LoST response that tells the > end system > > how to contact that PSAP via whatever system it needs to > use. If it's > > not going to understand that kind of > response, > > it's not going to understand a pointer to a second system which is > > going to give it that response once it gets there. > > > > regards, > > Ted > > > > > > > > > > >First of all, the LoST server either is run by the VPC, or it's run > by > > >something like the 9-1-1 Authority. The latter is where we are > headed > > with > > >i3. > > > > > >If the 9-1-1 Authority runs it, then it can't refer the > query to the > VPC, > > >because it doesn't know which VPC. We'll have to decide (in NENA) > what > > we > > >do in the cases where there is no URI yet for a particular > PSAP. One > > >possibility is to return some fixed, non-globally resolvable URI. > The > > >carrier could provide its own resolution of that URI to its VPC. > That > > could > > >just be a default LoST return, rather than a redirect. > > > > > >If the VPC runs it, it can put some appropriate URI in the LoST > return to > > >get the right thing to happen. > > > > > >However, let's just say that somehow we do want to do a . > It > > >still has to be a LoST server, because that's what the client is > going to > > do > > >with it. If you want to send the call to some URI, that has to be > the > > >output of a LoST server and not a redirect. So, I think > the wording > is > > >correct as written. > > > > > >Brian > > > > > >-----Original Message----- > > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of > > >Winterbottom, James > > >Sent: Wednesday, April 02, 2008 4:38 PM > > >To: Roger Marshall; ecrit@ietf.org; Ted Hardie > > >Subject: Re: [Ecrit] LoST Transition Support Issue > > > > > >Hi Roger, > > > > > >My only concern with this, is that in i2 an end-point doesn't talk > > directly > > >to a VPC, it talks to a VSP Call-Server that has several > ways that it > can > > >talk with a VPC. Your proposed text change implies, at least to me, > that > > the > > >end-point would direct the request to the VPC, I am not sure that I > would > > be > > >in favour of that model in the i2 space. > > > > > >Cheers > > >James > > > > > > > > > > > >-----Original Message----- > > >From: ecrit-bounces@ietf.org on behalf of Roger Marshall > > >Sent: Wed 4/2/2008 2:42 PM > > >To: ecrit@ietf.org; Ted Hardie > > >Subject: [Ecrit] LoST Transition Support Issue > > > > > >Late comment to > > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-09.txt > > > > > >I am requesting a simple text change to support > adaptability of LoST > > >during transition stage between non-IP PSAPs and IP-based PSAPs. > > > > > >Scenario: > > >If an IP-originated emergency call uses the LoST service > to provide > > >routing instructions for routing the call to a region appropriate > PSAP, > > >yet that particular PSAP doesn't yet support IP, there > needs to be a > way > > >within the LoST protocol to be able to still complete the > call. One > > >simple way is to redirect to another kind of server which > can provide > > >supplemental routing instructions to a non-IP PSAP (e.g., > for North > > >American, the NENA i2 VPC). Currently, the LoST draft > would support > > >this special kind of redirect, given single wording change: > > > > > >Proposal: Change text in the paragraph below, > > >From: "LoST application unique string (see Section 4)" > > >To: "application unique string (see Section 4)" > > > > > >13.3. Redirects > > > > > > A LoST server can respond indicating that the querier should > redirect > > > the query to another server, using the element. The > > > element includes a 'target' attribute indicating the LoST > application > > > unique string (see Section 4) that the client SHOULD be > contacting > > > next, as well as the 'source' attribute indicating the > server that > > > generated the redirect response and a 'message' attribute > explaining > > > the reason for the redirect response. > > > > > >-roger marshall. > > > > > > > > >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 > > > > > > > > > >------------------------------------------------------------- > ---------- > -- > > --- > > >-------------------- > > >This message is for the designated recipient only and may contain > > >privileged, proprietary, or otherwise private information. > > >If you have received it in error, please notify the sender > > >immediately and delete the original. Any unauthorized use of this > > >email is prohibited. > > > >------------------------------------------------------------- > ---------- > -- > > --- > > >-------------------- > > >[mf2] > > > > > >_______________________________________________ > > >Ecrit mailing list > > >Ecrit@ietf.org > > >https://www.ietf.org/mailman/listinfo/ecrit > > > > -------------------------------------------------------------- > ---------- > ------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------- > ------------------------ > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 4 13:37:46 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453923A6884; Fri, 4 Apr 2008 13:37:46 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D143A6896 for ; Fri, 4 Apr 2008 13:37:45 -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 ZIuUDrcrXq-a for ; Fri, 4 Apr 2008 13:37:44 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0D67D3A676A for ; Fri, 4 Apr 2008 13:37:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,606,1199692800"; d="scan'208";a="19983313" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 04 Apr 2008 13:37:50 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m34KboL9016371; Fri, 4 Apr 2008 13:37:50 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m34Kbo9O023270; Fri, 4 Apr 2008 20:37:50 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 16:37:50 -0400 Received: from mlinsnerwxp02 ([10.82.232.186]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 16:37:49 -0400 From: "Marc Linsner" To: "'Roger Marshall'" , References: <8C837214C95C864C9F34F3635C2A65750982F0A1@SEA-EXCHVS-2.telecomsys.com> <00bf01c895ca$95a378b0$300d0d0a@cisco.com> <8C837214C95C864C9F34F3635C2A65750982F52A@SEA-EXCHVS-2.telecomsys.com> Date: Fri, 4 Apr 2008 16:37:51 -0400 Message-ID: <008e01c89693$c0d62e00$300d0d0a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8C837214C95C864C9F34F3635C2A65750982F52A@SEA-EXCHVS-2.telecomsys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciSoBSicmd+wT1mQom8/iePcnSz0wABYVlrACJtvEAAD6FFRAAMWCawAACTyqAAiXueIAAAipQAADAhwqAAAhC7MA== X-OriginalArrivalTime: 04 Apr 2008 20:37:49.0626 (UTC) FILETIME=[BF70D1A0:01C89693] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12045; t=1207341470; x=1208205470; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20Phone=20BCP=3A=20Multiple=20L ocation |Sender:=20; bh=rhUSV4RPWYJsVTw75EUWm54cLAYQ67XY+ZrTA68T82g=; b=BP3cMFNtDKSziI3tMBotdlwCoNFcER8gB1TSjUtN/F7ytnh0zs/0QaPb2r b/1OBcAtCz02ZAkFLxJR0j7bv2BdyxgrfnT8gmALYs76YF3TxYlHC/Vl92wH DT3yiczqUT; Authentication-Results: sj-dkim-3; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Roger, How would you evaluate which LCP to try first? I assume that you would recommend the host stop trying if any resemblance of LCI was returned? I agree that receiving multiple LCIs is a problem, but I don't see how you can predetermine which LCP is going to return the 'best' information. I think you must try them all, if you get multiples, they have to be evaluated, even if that means presenting them to the user. -Marc- > > My objection is to a written *recommendation* that directs > the client to act serially OR act in parallel - as opposed to > what, (guessing, since not stated) recommending an ordered > list of configuration protocol candidates? > > Better to recommend one thing to do, allow another. > > -roger. > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Thursday, April 03, 2008 1:38 PM > > To: Roger Marshall; 'Winterbottom, James'; ecrit@ietf.org > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > Roger, James, > > > > You are simply moving the problem. You are stating you > don't want to > > tax the target by making it chose between multiple > locations, but you > > are asking > > the target to chose between multiple LCP mechanisms. I > don't see any > > difference in the algorithm between choosing between multiple > > locations or choosing between multiple LCPs. > > > > Am I missing something? > > > > -Marc- > > > > > > > > [snip] > > > > On Behalf Of Winterbottom, James > > > > Sent: Monday, March 31, 2008 7:46 PM > > > ... > > > > I think the correct answer is that it should only try 3 > > > methods if the > > > > first 2 failed. That is, it tries one method, if that > > > doesn't work, it > > > > tries the next one. > > > [/endsnip] > > > > > > I agree with you James, this seems practicle... but phonebcp > > > recommends an opposite approach (along with your suggested > > approach). > > > > > > ED-22/INT-15 Endpoints SHOULD try all LCPs supported by > > the device > > > in > > > any order or in parallel. The first one that succeeds > > in supplying > > > location can be used. > > > > > > I think it would be cleaner if Phonebcp recommended > serial queries > > > only > > > - therefore avoiding most of the worry around choosing > > among different > > > locations gotten from parallel requests. > > > > > > -roger. > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of Winterbottom, James > > > > Sent: Monday, March 31, 2008 7:46 PM > > > > To: Stark, Barbara; Hannes Tschofenig; ecrit@ietf.org > > > > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > > > > > > > Hi Barbara, > > > > > > > > Having re-read your email I think I misunderstood what you were > > > > saying. > > > > I think what you are saying is that if a device engages all > > > three LCPs > > > > and gets a different location for each of them, what does it do? > > > > > > > > I think the correct answer is that it should only try 3 > > > methods if the > > > > first 2 failed. That is, it tries one method, if that > > > doesn't work, it > > > > tries the next one. > > > > > > > > In the HELD routing/dispatch example I hope that we can say > > > always use > > > > dispatch since the dispatch location kind of needs to > > fall into the > > > > catchment of the routing area to make any sense. > > > > > > > > I think we should avoid trying to get as many different > > > locations as > > > > we can. > > > > > > > > As for DHCP and LLDP-MED I am not sure that I understand > > your last > > > > sentence in the first paragraph. I am not aware that we > > considering > > > > sending a literal location in any form other than a PIDF-LO > > > with the > > > > sos message. > > > > > > > > Cheers > > > > James > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > Sent: Tuesday, 1 April 2008 1:30 PM > > > > > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > > > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > Key words are "Where multiple PIDF documents can be sent or > > > > received > > > > > together". When a device has a configured location, a > > > location from > > > > > LLDP-MED, one from DHCP, and one or two (routing and > > > dispatch) from > > > > > HELD, I think that the quoted language has no relevance > > > on the order > > > > in > > > > > which these are then included in an "sos" message. These > > > different > > > > > locations were not received together. LLDP-MED and DHCP > > > > locations are > > > > > not received as PIDF documents. > > > > > > > > > > This language does apply to the PSAP when it receives all > > > of these > > > > > locations. They arrive together, and all in PIDF format. > > > > > Barbara > > > > > > > > > > -----Original Message----- > > > > > From: Winterbottom, James > [mailto:James.Winterbottom@andrew.com] > > > > > Sent: Monday, March 31, 2008 4:29 PM > > > > > To: Stark, Barbara; Hannes Tschofenig; ecrit@ietf.org > > > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > Nope. > > > > > > > > > > This is from PIDF-LO Profile > > > > > > > > > > " Rule #9: Where multiple PIDF documents can be sent > > or received > > > > > together, say in a multi-part MIME body, and > > > current location > > > > > information is required by the recipient, then document > > > > selection > > > > > SHOULD be based on document order, with the first > > document > > > > > considered first." > > > > > > > > > > Cheers > > > > > James > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > Sent: Mon 3/31/2008 8:05 AM > > > > > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > > > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > It's my understanding that PIDF-LO only describes > > > multiple location > > > > > precedence within a single message. It doesn't > describe how to > > > > > prioritize multiple locations received from various > > > > sources, received > > > > > in multiple messages (or statically configured) at > > various times. > > > > > > > > > > I did include that sort of logic in my latest DSLF draft. > > > > If there is > > > > a > > > > > desire to have some of this in phonebcp, I'm fine with that. > > > > > Barbara > > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Winterbottom, James > > > > > Sent: Sunday, March 30, 2008 4:36 PM > > > > > To: Hannes Tschofenig; ecrit@ietf.org > > > > > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > PIDF-LO profile describes how to choose the correct > location for > > > > exactly > > > > > this purpose. > > > > > That is the application form which the original > > requirements were > > > > drawn. > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > > > > > Sent: Sun 3/30/2008 2:55 PM > > > > > To: ecrit@ietf.org > > > > > Subject: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > " > > > > > ED-39 If a UA has more than one location available to > > > it, it MUST > > > > > choose one location to route the call towards the PSAP. > > > > > > > > > > SP-16 If a proxy inserts location on behalf of an > > > > endpoint, and it > > > > > has multiple locations available for the endpoint it > > > MUST choose > > > > one > > > > > location to use to route the call towards the PSAP. > > > > > " > > > > > > > > > > I could imagine that someone might ask how to make a decision. > > > > > So, how does the decision making look like? > > > > > > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > ---------- > > > > > ------------------------ > > > > > This message is for the designated recipient only and > > may contain > > > > > privileged, proprietary, or otherwise private information. > > > > > If you have received it in error, please notify the sender > > > > immediately > > > > > and delete the original. Any unauthorized use of > this email is > > > > > prohibited. > > > > > > > > > -------------------------------------------------------------- > > > > ---------- > > > > > ------------------------ > > > > > [mf2] > > > > > > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > ---------- > > > > > ------------------------ > > > > > This message is for the designated recipient only and > > may contain > > > > > privileged, proprietary, or otherwise private information. > > > > > If you have received it in error, please notify the sender > > > > immediately > > > > > and delete the original. Any unauthorized use of > this email is > > > > > prohibited. > > > > > > > > > -------------------------------------------------------------- > > > > ---------- > > > > > ------------------------ > > > > > [mf2] > > > > > > > > > > > > > > > ***** > > > > > > > > > > The information transmitted is intended only for the person > > > > or entity > > > > to > > > > > which it is addressed and may contain confidential, > proprietary, > > > > and/or > > > > > privileged material. Any review, retransmission, > > dissemination or > > > > other > > > > > use of, or taking of any action in reliance upon this > > > > information by > > > > > persons or entities other than the intended recipient is > > > prohibited. > > > > If > > > > > you received this in error, please contact the sender and > > > > delete the > > > > > material from all computers. GA622 > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > ---------------------------------- > > > > This message is for the designated recipient only and > may contain > > > > privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > immediately > > > > and delete the original. Any unauthorized use of this email is > > > > prohibited. > > > > -------------------------------------------------------------- > > > > ---------------------------------- > > > > [mf2] > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > message may > > > be privileged and/or confidential. If you are not the intended > > > recipient, or responsible for delivering this message to > > the intended > > > recipient, any review, forwarding, dissemination, distribution or > > > copying of this communication or any attachment(s) is strictly > > > prohibited. If you have received this message in error, > > please notify > > > the sender immediately, and delete it and all attachments > from your > > > computer and network. > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 4 14:24:28 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BEF23A6FED; Fri, 4 Apr 2008 14:24:28 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAF193A6FEC for ; Fri, 4 Apr 2008 14:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 8NSNaqvRgDJE for ; Fri, 4 Apr 2008 14:24:26 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id D74013A7000 for ; Fri, 4 Apr 2008 14:21:13 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Fri, 4 Apr 2008 14:21:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 14:21:18 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750982F622@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <008e01c89693$c0d62e00$300d0d0a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: Multiple Location Thread-Index: AciSoBSicmd+wT1mQom8/iePcnSz0wABYVlrACJtvEAAD6FFRAAMWCawAACTyqAAiXueIAAAipQAADAhwqAAAhC7MAAAZgSQ References: <8C837214C95C864C9F34F3635C2A65750982F0A1@SEA-EXCHVS-2.telecomsys.com> <00bf01c895ca$95a378b0$300d0d0a@cisco.com> <8C837214C95C864C9F34F3635C2A65750982F52A@SEA-EXCHVS-2.telecomsys.com> <008e01c89693$c0d62e00$300d0d0a@cisco.com> From: "Roger Marshall" To: "Marc Linsner" , Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Marc: I would imagine that some service providers would have more confidence (no pun intended) in one method vs. another, but acknowledge would be a problem on a level playing field. I didn't see any 'best practice' as to, 1. how a device picks one of three potential locations, or 2. picks from 3 potentially different SIP URIs returned by LoST based on multiple locations input I guess we could dream something up - somebody will have to... We could, -- pick civic based on uncertainty (whoops, civic doesn't have uncertainty) -- pick between '125 River Rd.', '125 River Rd. E' and '125 River Rd. W' (any of the 3 may be valid, could even be on different sides of the river) -- two civics and a geo (e.g., from agps) - does the majority win out, or precise locations trump all others? -- manually provisioned (given) civic vs. CellSectorID civic? -- three geo's with increasing uncertainty - do you pick the one w/the smallest or largest uncertainty value (safer to err on the side of conservativeness)? To differentiate multiple LoST responses, we could go with, choose best 2 out of 3, what happens if all 3 are not the same? Lots of scenarios exist. More important than, 'where do we move the problem', I think that there needs to be some discussion on best practices for 'how to choose'. -roger marshall. > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Friday, April 04, 2008 1:38 PM > To: Roger Marshall; ecrit@ietf.org > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > Roger, > > How would you evaluate which LCP to try first? I assume that > you would recommend the host stop trying if any resemblance > of LCI was returned? > > I agree that receiving multiple LCIs is a problem, but I > don't see how you can predetermine which LCP is going to > return the 'best' information. I think you must try them > all, if you get multiples, they have to be evaluated, even if > that means presenting them to the user. > > -Marc- > > > > > > > My objection is to a written *recommendation* that directs > the client > > to act serially OR act in parallel - as opposed to what, (guessing, > > since not stated) recommending an ordered list of configuration > > protocol candidates? > > > > Better to recommend one thing to do, allow another. > > > > -roger. > > > > > -----Original Message----- > > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > > Sent: Thursday, April 03, 2008 1:38 PM > > > To: Roger Marshall; 'Winterbottom, James'; ecrit@ietf.org > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > Roger, James, > > > > > > You are simply moving the problem. You are stating you > > don't want to > > > tax the target by making it chose between multiple > > locations, but you > > > are asking > > > the target to chose between multiple LCP mechanisms. I > > don't see any > > > difference in the algorithm between choosing between multiple > > > locations or choosing between multiple LCPs. > > > > > > Am I missing something? > > > > > > -Marc- > > > > > > > > > > > [snip] > > > > > On Behalf Of Winterbottom, James > > > > > Sent: Monday, March 31, 2008 7:46 PM > > > > ... > > > > > I think the correct answer is that it should only try 3 > > > > methods if the > > > > > first 2 failed. That is, it tries one method, if that > > > > doesn't work, it > > > > > tries the next one. > > > > [/endsnip] > > > > > > > > I agree with you James, this seems practicle... but phonebcp > > > > recommends an opposite approach (along with your suggested > > > approach). > > > > > > > > ED-22/INT-15 Endpoints SHOULD try all LCPs supported by > > > the device > > > > in > > > > any order or in parallel. The first one that succeeds > > > in supplying > > > > location can be used. > > > > > > > > I think it would be cleaner if Phonebcp recommended > > serial queries > > > > only > > > > - therefore avoiding most of the worry around choosing > > > among different > > > > locations gotten from parallel requests. > > > > > > > > -roger. > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Winterbottom, James > > > > > Sent: Monday, March 31, 2008 7:46 PM > > > > > To: Stark, Barbara; Hannes Tschofenig; ecrit@ietf.org > > > > > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > Hi Barbara, > > > > > > > > > > Having re-read your email I think I misunderstood > what you were > > > > > saying. > > > > > I think what you are saying is that if a device engages all > > > > three LCPs > > > > > and gets a different location for each of them, what > does it do? > > > > > > > > > > I think the correct answer is that it should only try 3 > > > > methods if the > > > > > first 2 failed. That is, it tries one method, if that > > > > doesn't work, it > > > > > tries the next one. > > > > > > > > > > In the HELD routing/dispatch example I hope that we can say > > > > always use > > > > > dispatch since the dispatch location kind of needs to > > > fall into the > > > > > catchment of the routing area to make any sense. > > > > > > > > > > I think we should avoid trying to get as many different > > > > locations as > > > > > we can. > > > > > > > > > > As for DHCP and LLDP-MED I am not sure that I understand > > > your last > > > > > sentence in the first paragraph. I am not aware that we > > > considering > > > > > sending a literal location in any form other than a PIDF-LO > > > > with the > > > > > sos message. > > > > > > > > > > Cheers > > > > > James > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > > Sent: Tuesday, 1 April 2008 1:30 PM > > > > > > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > > > Key words are "Where multiple PIDF documents can be sent or > > > > > received > > > > > > together". When a device has a configured location, a > > > > location from > > > > > > LLDP-MED, one from DHCP, and one or two (routing and > > > > dispatch) from > > > > > > HELD, I think that the quoted language has no relevance > > > > on the order > > > > > in > > > > > > which these are then included in an "sos" message. These > > > > different > > > > > > locations were not received together. LLDP-MED and DHCP > > > > > locations are > > > > > > not received as PIDF documents. > > > > > > > > > > > > This language does apply to the PSAP when it receives all > > > > of these > > > > > > locations. They arrive together, and all in PIDF format. > > > > > > Barbara > > > > > > > > > > > > -----Original Message----- > > > > > > From: Winterbottom, James > > [mailto:James.Winterbottom@andrew.com] > > > > > > Sent: Monday, March 31, 2008 4:29 PM > > > > > > To: Stark, Barbara; Hannes Tschofenig; ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > > > Nope. > > > > > > > > > > > > This is from PIDF-LO Profile > > > > > > > > > > > > " Rule #9: Where multiple PIDF documents can be sent > > > or received > > > > > > together, say in a multi-part MIME body, and > > > > current location > > > > > > information is required by the recipient, > then document > > > > > selection > > > > > > SHOULD be based on document order, with the first > > > document > > > > > > considered first." > > > > > > > > > > > > Cheers > > > > > > James > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > > Sent: Mon 3/31/2008 8:05 AM > > > > > > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > > > It's my understanding that PIDF-LO only describes > > > > multiple location > > > > > > precedence within a single message. It doesn't > > describe how to > > > > > > prioritize multiple locations received from various > > > > > sources, received > > > > > > in multiple messages (or statically configured) at > > > various times. > > > > > > > > > > > > I did include that sort of logic in my latest DSLF draft. > > > > > If there is > > > > > a > > > > > > desire to have some of this in phonebcp, I'm fine with that. > > > > > > Barbara > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > Of Winterbottom, James > > > > > > Sent: Sunday, March 30, 2008 4:36 PM > > > > > > To: Hannes Tschofenig; ecrit@ietf.org > > > > > > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > > > PIDF-LO profile describes how to choose the correct > > location for > > > > > exactly > > > > > > this purpose. > > > > > > That is the application form which the original > > > requirements were > > > > > drawn. > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > > > > > > Sent: Sun 3/30/2008 2:55 PM > > > > > > To: ecrit@ietf.org > > > > > > Subject: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > > > " > > > > > > ED-39 If a UA has more than one location available to > > > > it, it MUST > > > > > > choose one location to route the call towards the PSAP. > > > > > > > > > > > > SP-16 If a proxy inserts location on behalf of an > > > > > endpoint, and it > > > > > > has multiple locations available for the endpoint it > > > > MUST choose > > > > > one > > > > > > location to use to route the call towards the PSAP. > > > > > > " > > > > > > > > > > > > I could imagine that someone might ask how to make > a decision. > > > > > > So, how does the decision making look like? > > > > > > > > > > > > _______________________________________________ > > > > > > Ecrit mailing list > > > > > > Ecrit@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------- > > > > > > ------------------------ > > > > > > This message is for the designated recipient only and > > > may contain > > > > > > privileged, proprietary, or otherwise private information. > > > > > > If you have received it in error, please notify the sender > > > > > immediately > > > > > > and delete the original. Any unauthorized use of > > this email is > > > > > > prohibited. > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------- > > > > > > ------------------------ > > > > > > [mf2] > > > > > > > > > > > > _______________________________________________ > > > > > > Ecrit mailing list > > > > > > Ecrit@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------- > > > > > > ------------------------ > > > > > > This message is for the designated recipient only and > > > may contain > > > > > > privileged, proprietary, or otherwise private information. > > > > > > If you have received it in error, please notify the sender > > > > > immediately > > > > > > and delete the original. Any unauthorized use of > > this email is > > > > > > prohibited. > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------- > > > > > > ------------------------ > > > > > > [mf2] > > > > > > > > > > > > > > > > > > ***** > > > > > > > > > > > > The information transmitted is intended only for the person > > > > > or entity > > > > > to > > > > > > which it is addressed and may contain confidential, > > proprietary, > > > > > and/or > > > > > > privileged material. Any review, retransmission, > > > dissemination or > > > > > other > > > > > > use of, or taking of any action in reliance upon this > > > > > information by > > > > > > persons or entities other than the intended recipient is > > > > prohibited. > > > > > If > > > > > > you received this in error, please contact the sender and > > > > > delete the > > > > > > material from all computers. GA622 > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------------------------------- > > > > > This message is for the designated recipient only and > > may contain > > > > > privileged, proprietary, or otherwise private information. > > > > > If you have received it in error, please notify the sender > > > > immediately > > > > > and delete the original. Any unauthorized use of > this email is > > > > > prohibited. > > > > > -------------------------------------------------------------- > > > > > ---------------------------------- > > > > > [mf2] > > > > > > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > > message may > > > > be privileged and/or confidential. If you are not the intended > > > > recipient, or responsible for delivering this message to > > > the intended > > > > recipient, any review, forwarding, dissemination, > distribution or > > > > copying of this communication or any attachment(s) is strictly > > > > prohibited. If you have received this message in error, > > > please notify > > > > the sender immediately, and delete it and all attachments > > from your > > > > computer and network. > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 4 14:51:28 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EAAD3A6B05; Fri, 4 Apr 2008 14:51:28 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A7413A6FB4 for ; Fri, 4 Apr 2008 14:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=0.779, 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 acrFFmxTX0cD for ; Fri, 4 Apr 2008 14:51:24 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 9143E3A6FAB for ; Fri, 4 Apr 2008 14:50:09 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JhtnV-0002Sm-CD; Fri, 04 Apr 2008 16:50:09 -0500 From: "Brian Rosen" To: "'Roger Marshall'" , "'Marc Linsner'" , References: <8C837214C95C864C9F34F3635C2A65750982F0A1@SEA-EXCHVS-2.telecomsys.com><00bf01c895ca$95a378b0$300d0d0a@cisco.com><8C837214C95C864C9F34F3635C2A65750982F52A@SEA-EXCHVS-2.telecomsys.com><008e01c89693$c0d62e00$300d0d0a@cisco.com> <8C837214C95C864C9F34F3635C2A65750982F622@SEA-EXCHVS-2.telecomsys.com> Date: Fri, 4 Apr 2008 17:50:12 -0400 Message-ID: <021701c8969d$dde67900$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8C837214C95C864C9F34F3635C2A65750982F622@SEA-EXCHVS-2.telecomsys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AciSoBSicmd+wT1mQom8/iePcnSz0wABYVlrACJtvEAAD6FFRAAMWCawAACTyqAAiXueIAAAipQAADAhwqAAAhC7MAAAZgSQAAIgROA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org First of all, I thought we started by trying LCPs until we got an answer. Then I think our advice is that an LCP returns it's most precise location if I has more than one, and never converts. A LIS should never leave a user with a choice. It chooses. Then, if the endpoint has more than one anyway, it has to choose. If a proxy is inserting, and it has more than one, it has to choose. While I could imagine a complex set of rules designed to choose the best based on civic vs geo and confidence/uncertainty, I think we need a very simple tiebreaker. I think that we should work towards never being in this situation rather than trying to optimize what we do when we are in it. So, I think the best answer is, if you really have more than one, and you don't have any basis to choose, make a random choice. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Friday, April 04, 2008 5:21 PM To: Marc Linsner; ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Multiple Location Marc: I would imagine that some service providers would have more confidence (no pun intended) in one method vs. another, but acknowledge would be a problem on a level playing field. I didn't see any 'best practice' as to, 1. how a device picks one of three potential locations, or 2. picks from 3 potentially different SIP URIs returned by LoST based on multiple locations input I guess we could dream something up - somebody will have to... We could, -- pick civic based on uncertainty (whoops, civic doesn't have uncertainty) -- pick between '125 River Rd.', '125 River Rd. E' and '125 River Rd. W' (any of the 3 may be valid, could even be on different sides of the river) -- two civics and a geo (e.g., from agps) - does the majority win out, or precise locations trump all others? -- manually provisioned (given) civic vs. CellSectorID civic? -- three geo's with increasing uncertainty - do you pick the one w/the smallest or largest uncertainty value (safer to err on the side of conservativeness)? To differentiate multiple LoST responses, we could go with, choose best 2 out of 3, what happens if all 3 are not the same? Lots of scenarios exist. More important than, 'where do we move the problem', I think that there needs to be some discussion on best practices for 'how to choose'. -roger marshall. > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Friday, April 04, 2008 1:38 PM > To: Roger Marshall; ecrit@ietf.org > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > Roger, > > How would you evaluate which LCP to try first? I assume that > you would recommend the host stop trying if any resemblance > of LCI was returned? > > I agree that receiving multiple LCIs is a problem, but I > don't see how you can predetermine which LCP is going to > return the 'best' information. I think you must try them > all, if you get multiples, they have to be evaluated, even if > that means presenting them to the user. > > -Marc- > > > > > > > My objection is to a written *recommendation* that directs > the client > > to act serially OR act in parallel - as opposed to what, (guessing, > > since not stated) recommending an ordered list of configuration > > protocol candidates? > > > > Better to recommend one thing to do, allow another. > > > > -roger. > > > > > -----Original Message----- > > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > > Sent: Thursday, April 03, 2008 1:38 PM > > > To: Roger Marshall; 'Winterbottom, James'; ecrit@ietf.org > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > Roger, James, > > > > > > You are simply moving the problem. You are stating you > > don't want to > > > tax the target by making it chose between multiple > > locations, but you > > > are asking > > > the target to chose between multiple LCP mechanisms. I > > don't see any > > > difference in the algorithm between choosing between multiple > > > locations or choosing between multiple LCPs. > > > > > > Am I missing something? > > > > > > -Marc- > > > > > > > > > > > [snip] > > > > > On Behalf Of Winterbottom, James > > > > > Sent: Monday, March 31, 2008 7:46 PM > > > > ... > > > > > I think the correct answer is that it should only try 3 > > > > methods if the > > > > > first 2 failed. That is, it tries one method, if that > > > > doesn't work, it > > > > > tries the next one. > > > > [/endsnip] > > > > > > > > I agree with you James, this seems practicle... but phonebcp > > > > recommends an opposite approach (along with your suggested > > > approach). > > > > > > > > ED-22/INT-15 Endpoints SHOULD try all LCPs supported by > > > the device > > > > in > > > > any order or in parallel. The first one that succeeds > > > in supplying > > > > location can be used. > > > > > > > > I think it would be cleaner if Phonebcp recommended > > serial queries > > > > only > > > > - therefore avoiding most of the worry around choosing > > > among different > > > > locations gotten from parallel requests. > > > > > > > > -roger. > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Winterbottom, James > > > > > Sent: Monday, March 31, 2008 7:46 PM > > > > > To: Stark, Barbara; Hannes Tschofenig; ecrit@ietf.org > > > > > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > Hi Barbara, > > > > > > > > > > Having re-read your email I think I misunderstood > what you were > > > > > saying. > > > > > I think what you are saying is that if a device engages all > > > > three LCPs > > > > > and gets a different location for each of them, what > does it do? > > > > > > > > > > I think the correct answer is that it should only try 3 > > > > methods if the > > > > > first 2 failed. That is, it tries one method, if that > > > > doesn't work, it > > > > > tries the next one. > > > > > > > > > > In the HELD routing/dispatch example I hope that we can say > > > > always use > > > > > dispatch since the dispatch location kind of needs to > > > fall into the > > > > > catchment of the routing area to make any sense. > > > > > > > > > > I think we should avoid trying to get as many different > > > > locations as > > > > > we can. > > > > > > > > > > As for DHCP and LLDP-MED I am not sure that I understand > > > your last > > > > > sentence in the first paragraph. I am not aware that we > > > considering > > > > > sending a literal location in any form other than a PIDF-LO > > > > with the > > > > > sos message. > > > > > > > > > > Cheers > > > > > James > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > > Sent: Tuesday, 1 April 2008 1:30 PM > > > > > > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > > > Key words are "Where multiple PIDF documents can be sent or > > > > > received > > > > > > together". When a device has a configured location, a > > > > location from > > > > > > LLDP-MED, one from DHCP, and one or two (routing and > > > > dispatch) from > > > > > > HELD, I think that the quoted language has no relevance > > > > on the order > > > > > in > > > > > > which these are then included in an "sos" message. These > > > > different > > > > > > locations were not received together. LLDP-MED and DHCP > > > > > locations are > > > > > > not received as PIDF documents. > > > > > > > > > > > > This language does apply to the PSAP when it receives all > > > > of these > > > > > > locations. They arrive together, and all in PIDF format. > > > > > > Barbara > > > > > > > > > > > > -----Original Message----- > > > > > > From: Winterbottom, James > > [mailto:James.Winterbottom@andrew.com] > > > > > > Sent: Monday, March 31, 2008 4:29 PM > > > > > > To: Stark, Barbara; Hannes Tschofenig; ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > > > Nope. > > > > > > > > > > > > This is from PIDF-LO Profile > > > > > > > > > > > > " Rule #9: Where multiple PIDF documents can be sent > > > or received > > > > > > together, say in a multi-part MIME body, and > > > > current location > > > > > > information is required by the recipient, > then document > > > > > selection > > > > > > SHOULD be based on document order, with the first > > > document > > > > > > considered first." > > > > > > > > > > > > Cheers > > > > > > James > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > > Sent: Mon 3/31/2008 8:05 AM > > > > > > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > > > It's my understanding that PIDF-LO only describes > > > > multiple location > > > > > > precedence within a single message. It doesn't > > describe how to > > > > > > prioritize multiple locations received from various > > > > > sources, received > > > > > > in multiple messages (or statically configured) at > > > various times. > > > > > > > > > > > > I did include that sort of logic in my latest DSLF draft. > > > > > If there is > > > > > a > > > > > > desire to have some of this in phonebcp, I'm fine with that. > > > > > > Barbara > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > Of Winterbottom, James > > > > > > Sent: Sunday, March 30, 2008 4:36 PM > > > > > > To: Hannes Tschofenig; ecrit@ietf.org > > > > > > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > > > PIDF-LO profile describes how to choose the correct > > location for > > > > > exactly > > > > > > this purpose. > > > > > > That is the application form which the original > > > requirements were > > > > > drawn. > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > > > > > > Sent: Sun 3/30/2008 2:55 PM > > > > > > To: ecrit@ietf.org > > > > > > Subject: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > > > " > > > > > > ED-39 If a UA has more than one location available to > > > > it, it MUST > > > > > > choose one location to route the call towards the PSAP. > > > > > > > > > > > > SP-16 If a proxy inserts location on behalf of an > > > > > endpoint, and it > > > > > > has multiple locations available for the endpoint it > > > > MUST choose > > > > > one > > > > > > location to use to route the call towards the PSAP. > > > > > > " > > > > > > > > > > > > I could imagine that someone might ask how to make > a decision. > > > > > > So, how does the decision making look like? > > > > > > > > > > > > _______________________________________________ > > > > > > Ecrit mailing list > > > > > > Ecrit@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------- > > > > > > ------------------------ > > > > > > This message is for the designated recipient only and > > > may contain > > > > > > privileged, proprietary, or otherwise private information. > > > > > > If you have received it in error, please notify the sender > > > > > immediately > > > > > > and delete the original. Any unauthorized use of > > this email is > > > > > > prohibited. > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------- > > > > > > ------------------------ > > > > > > [mf2] > > > > > > > > > > > > _______________________________________________ > > > > > > Ecrit mailing list > > > > > > Ecrit@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------- > > > > > > ------------------------ > > > > > > This message is for the designated recipient only and > > > may contain > > > > > > privileged, proprietary, or otherwise private information. > > > > > > If you have received it in error, please notify the sender > > > > > immediately > > > > > > and delete the original. Any unauthorized use of > > this email is > > > > > > prohibited. > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------- > > > > > > ------------------------ > > > > > > [mf2] > > > > > > > > > > > > > > > > > > ***** > > > > > > > > > > > > The information transmitted is intended only for the person > > > > > or entity > > > > > to > > > > > > which it is addressed and may contain confidential, > > proprietary, > > > > > and/or > > > > > > privileged material. Any review, retransmission, > > > dissemination or > > > > > other > > > > > > use of, or taking of any action in reliance upon this > > > > > information by > > > > > > persons or entities other than the intended recipient is > > > > prohibited. > > > > > If > > > > > > you received this in error, please contact the sender and > > > > > delete the > > > > > > material from all computers. GA622 > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------------------------------- > > > > > This message is for the designated recipient only and > > may contain > > > > > privileged, proprietary, or otherwise private information. > > > > > If you have received it in error, please notify the sender > > > > immediately > > > > > and delete the original. Any unauthorized use of > this email is > > > > > prohibited. > > > > > -------------------------------------------------------------- > > > > > ---------------------------------- > > > > > [mf2] > > > > > > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > > message may > > > > be privileged and/or confidential. If you are not the intended > > > > recipient, or responsible for delivering this message to > > > the intended > > > > recipient, any review, forwarding, dissemination, > distribution or > > > > copying of this communication or any attachment(s) is strictly > > > > prohibited. If you have received this message in error, > > > please notify > > > > the sender immediately, and delete it and all attachments > > from your > > > > computer and network. > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 4 22:41:57 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB63A3A67E9; Fri, 4 Apr 2008 22:41:57 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A43E93A68D5 for ; Fri, 4 Apr 2008 22:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.994 X-Spam-Level: X-Spam-Status: No, score=-0.994 tagged_above=-999 required=5 tests=[AWL=0.209, 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 b6oflsOejk5H for ; Fri, 4 Apr 2008 22:41:55 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id F18BB3A67E9 for ; Fri, 4 Apr 2008 22:41:54 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_04_05_00_55_13 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); Sat, 05 Apr 2008 00:55:12 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 5 Apr 2008 00:41:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 5 Apr 2008 00:27:17 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP: Multiple Location Thread-Index: AciSoBSicmd+wT1mQom8/iePcnSz0wABYVlrACJtvEAAD6FFRAAMWCawAACTyqAAiXueIAAAipQAADAhwqAAAhC7MAAAZgSQAAIgROAAEE1KAA== References: <8C837214C95C864C9F34F3635C2A65750982F0A1@SEA-EXCHVS-2.telecomsys.com><00bf01c895ca$95a378b0$300d0d0a@cisco.com><8C837214C95C864C9F34F3635C2A65750982F52A@SEA-EXCHVS-2.telecomsys.com><008e01c89693$c0d62e00$300d0d0a@cisco.com><8C837214C95C864C9F34F3635C2A65750982F622@SEA-EXCHVS-2.telecomsys.com> <021701c8969d$dde67900$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Roger Marshall" , "Marc Linsner" , X-OriginalArrivalTime: 05 Apr 2008 05:41:57.0529 (UTC) FILETIME=[C31B7890:01C896DF] Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Actually, if a LIS has more than one answer it may provide more than one answer, but it MUST return the PIDF-LO based on PIDF-LO profile, so there is no ambiguity as which location to send to LoST. This problem is less of an issue for DHCP, as they specifications already say that the user must explicitly ask it, so that should take care of the multiple problem to some extent. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Brian Rosen Sent: Fri 4/4/2008 4:50 PM To: 'Roger Marshall'; 'Marc Linsner'; ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Multiple Location First of all, I thought we started by trying LCPs until we got an answer. Then I think our advice is that an LCP returns it's most precise location if I has more than one, and never converts. A LIS should never leave a user with a choice. It chooses. Then, if the endpoint has more than one anyway, it has to choose. If a proxy is inserting, and it has more than one, it has to choose. While I could imagine a complex set of rules designed to choose the best based on civic vs geo and confidence/uncertainty, I think we need a very simple tiebreaker. I think that we should work towards never being in this situation rather than trying to optimize what we do when we are in it. So, I think the best answer is, if you really have more than one, and you don't have any basis to choose, make a random choice. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Friday, April 04, 2008 5:21 PM To: Marc Linsner; ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Multiple Location Marc: I would imagine that some service providers would have more confidence (no pun intended) in one method vs. another, but acknowledge would be a problem on a level playing field. I didn't see any 'best practice' as to, 1. how a device picks one of three potential locations, or 2. picks from 3 potentially different SIP URIs returned by LoST based on multiple locations input I guess we could dream something up - somebody will have to... We could, -- pick civic based on uncertainty (whoops, civic doesn't have uncertainty) -- pick between '125 River Rd.', '125 River Rd. E' and '125 River Rd. W' (any of the 3 may be valid, could even be on different sides of the river) -- two civics and a geo (e.g., from agps) - does the majority win out, or precise locations trump all others? -- manually provisioned (given) civic vs. CellSectorID civic? -- three geo's with increasing uncertainty - do you pick the one w/the smallest or largest uncertainty value (safer to err on the side of conservativeness)? To differentiate multiple LoST responses, we could go with, choose best 2 out of 3, what happens if all 3 are not the same? Lots of scenarios exist. More important than, 'where do we move the problem', I think that there needs to be some discussion on best practices for 'how to choose'. -roger marshall. > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Friday, April 04, 2008 1:38 PM > To: Roger Marshall; ecrit@ietf.org > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > Roger, > > How would you evaluate which LCP to try first? I assume that > you would recommend the host stop trying if any resemblance > of LCI was returned? > > I agree that receiving multiple LCIs is a problem, but I > don't see how you can predetermine which LCP is going to > return the 'best' information. I think you must try them > all, if you get multiples, they have to be evaluated, even if > that means presenting them to the user. > > -Marc- > > > > > > > My objection is to a written *recommendation* that directs > the client > > to act serially OR act in parallel - as opposed to what, (guessing, > > since not stated) recommending an ordered list of configuration > > protocol candidates? > > > > Better to recommend one thing to do, allow another. > > > > -roger. > > > > > -----Original Message----- > > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > > Sent: Thursday, April 03, 2008 1:38 PM > > > To: Roger Marshall; 'Winterbottom, James'; ecrit@ietf.org > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > Roger, James, > > > > > > You are simply moving the problem. You are stating you > > don't want to > > > tax the target by making it chose between multiple > > locations, but you > > > are asking > > > the target to chose between multiple LCP mechanisms. I > > don't see any > > > difference in the algorithm between choosing between multiple > > > locations or choosing between multiple LCPs. > > > > > > Am I missing something? > > > > > > -Marc- > > > > > > > > > > > [snip] > > > > > On Behalf Of Winterbottom, James > > > > > Sent: Monday, March 31, 2008 7:46 PM > > > > ... > > > > > I think the correct answer is that it should only try 3 > > > > methods if the > > > > > first 2 failed. That is, it tries one method, if that > > > > doesn't work, it > > > > > tries the next one. > > > > [/endsnip] > > > > > > > > I agree with you James, this seems practicle... but phonebcp > > > > recommends an opposite approach (along with your suggested > > > approach). > > > > > > > > ED-22/INT-15 Endpoints SHOULD try all LCPs supported by > > > the device > > > > in > > > > any order or in parallel. The first one that succeeds > > > in supplying > > > > location can be used. > > > > > > > > I think it would be cleaner if Phonebcp recommended > > serial queries > > > > only > > > > - therefore avoiding most of the worry around choosing > > > among different > > > > locations gotten from parallel requests. > > > > > > > > -roger. > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Winterbottom, James > > > > > Sent: Monday, March 31, 2008 7:46 PM > > > > > To: Stark, Barbara; Hannes Tschofenig; ecrit@ietf.org > > > > > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > Hi Barbara, > > > > > > > > > > Having re-read your email I think I misunderstood > what you were > > > > > saying. > > > > > I think what you are saying is that if a device engages all > > > > three LCPs > > > > > and gets a different location for each of them, what > does it do? > > > > > > > > > > I think the correct answer is that it should only try 3 > > > > methods if the > > > > > first 2 failed. That is, it tries one method, if that > > > > doesn't work, it > > > > > tries the next one. > > > > > > > > > > In the HELD routing/dispatch example I hope that we can say > > > > always use > > > > > dispatch since the dispatch location kind of needs to > > > fall into the > > > > > catchment of the routing area to make any sense. > > > > > > > > > > I think we should avoid trying to get as many different > > > > locations as > > > > > we can. > > > > > > > > > > As for DHCP and LLDP-MED I am not sure that I understand > > > your last > > > > > sentence in the first paragraph. I am not aware that we > > > considering > > > > > sending a literal location in any form other than a PIDF-LO > > > > with the > > > > > sos message. > > > > > > > > > > Cheers > > > > > James > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > > Sent: Tuesday, 1 April 2008 1:30 PM > > > > > > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > > > Key words are "Where multiple PIDF documents can be sent or > > > > > received > > > > > > together". When a device has a configured location, a > > > > location from > > > > > > LLDP-MED, one from DHCP, and one or two (routing and > > > > dispatch) from > > > > > > HELD, I think that the quoted language has no relevance > > > > on the order > > > > > in > > > > > > which these are then included in an "sos" message. These > > > > different > > > > > > locations were not received together. LLDP-MED and DHCP > > > > > locations are > > > > > > not received as PIDF documents. > > > > > > > > > > > > This language does apply to the PSAP when it receives all > > > > of these > > > > > > locations. They arrive together, and all in PIDF format. > > > > > > Barbara > > > > > > > > > > > > -----Original Message----- > > > > > > From: Winterbottom, James > > [mailto:James.Winterbottom@andrew.com] > > > > > > Sent: Monday, March 31, 2008 4:29 PM > > > > > > To: Stark, Barbara; Hannes Tschofenig; ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > > > Nope. > > > > > > > > > > > > This is from PIDF-LO Profile > > > > > > > > > > > > " Rule #9: Where multiple PIDF documents can be sent > > > or received > > > > > > together, say in a multi-part MIME body, and > > > > current location > > > > > > information is required by the recipient, > then document > > > > > selection > > > > > > SHOULD be based on document order, with the first > > > document > > > > > > considered first." > > > > > > > > > > > > Cheers > > > > > > James > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > > Sent: Mon 3/31/2008 8:05 AM > > > > > > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > > > It's my understanding that PIDF-LO only describes > > > > multiple location > > > > > > precedence within a single message. It doesn't > > describe how to > > > > > > prioritize multiple locations received from various > > > > > sources, received > > > > > > in multiple messages (or statically configured) at > > > various times. > > > > > > > > > > > > I did include that sort of logic in my latest DSLF draft. > > > > > If there is > > > > > a > > > > > > desire to have some of this in phonebcp, I'm fine with that. > > > > > > Barbara > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > Of Winterbottom, James > > > > > > Sent: Sunday, March 30, 2008 4:36 PM > > > > > > To: Hannes Tschofenig; ecrit@ietf.org > > > > > > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > > > PIDF-LO profile describes how to choose the correct > > location for > > > > > exactly > > > > > > this purpose. > > > > > > That is the application form which the original > > > requirements were > > > > > drawn. > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > > > > > > Sent: Sun 3/30/2008 2:55 PM > > > > > > To: ecrit@ietf.org > > > > > > Subject: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > > > " > > > > > > ED-39 If a UA has more than one location available to > > > > it, it MUST > > > > > > choose one location to route the call towards the PSAP. > > > > > > > > > > > > SP-16 If a proxy inserts location on behalf of an > > > > > endpoint, and it > > > > > > has multiple locations available for the endpoint it > > > > MUST choose > > > > > one > > > > > > location to use to route the call towards the PSAP. > > > > > > " > > > > > > > > > > > > I could imagine that someone might ask how to make > a decision. > > > > > > So, how does the decision making look like? > > > > > > > > > > > > _______________________________________________ > > > > > > Ecrit mailing list > > > > > > Ecrit@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------- > > > > > > ------------------------ > > > > > > This message is for the designated recipient only and > > > may contain > > > > > > privileged, proprietary, or otherwise private information. > > > > > > If you have received it in error, please notify the sender > > > > > immediately > > > > > > and delete the original. Any unauthorized use of > > this email is > > > > > > prohibited. > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------- > > > > > > ------------------------ > > > > > > [mf2] > > > > > > > > > > > > _______________________________________________ > > > > > > Ecrit mailing list > > > > > > Ecrit@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------- > > > > > > ------------------------ > > > > > > This message is for the designated recipient only and > > > may contain > > > > > > privileged, proprietary, or otherwise private information. > > > > > > If you have received it in error, please notify the sender > > > > > immediately > > > > > > and delete the original. Any unauthorized use of > > this email is > > > > > > prohibited. > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------- > > > > > > ------------------------ > > > > > > [mf2] > > > > > > > > > > > > > > > > > > ***** > > > > > > > > > > > > The information transmitted is intended only for the person > > > > > or entity > > > > > to > > > > > > which it is addressed and may contain confidential, > > proprietary, > > > > > and/or > > > > > > privileged material. Any review, retransmission, > > > dissemination or > > > > > other > > > > > > use of, or taking of any action in reliance upon this > > > > > information by > > > > > > persons or entities other than the intended recipient is > > > > prohibited. > > > > > If > > > > > > you received this in error, please contact the sender and > > > > > delete the > > > > > > material from all computers. GA622 > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------------------------------- > > > > > This message is for the designated recipient only and > > may contain > > > > > privileged, proprietary, or otherwise private information. > > > > > If you have received it in error, please notify the sender > > > > immediately > > > > > and delete the original. Any unauthorized use of > this email is > > > > > prohibited. > > > > > -------------------------------------------------------------- > > > > > ---------------------------------- > > > > > [mf2] > > > > > > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > > message may > > > > be privileged and/or confidential. If you are not the intended > > > > recipient, or responsible for delivering this message to > > > the intended > > > > recipient, any review, forwarding, dissemination, > distribution or > > > > copying of this communication or any attachment(s) is strictly > > > > prohibited. If you have received this message in error, > > > please notify > > > > the sender immediately, and delete it and all attachments > > from your > > > > computer and network. > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 5 06:29:29 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46BE28C25A; Sat, 5 Apr 2008 06:29:29 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBA6D3A6D58 for ; Sat, 5 Apr 2008 06:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.772, 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 c4e5T+i1NkwX for ; Sat, 5 Apr 2008 06:29:25 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id AF3503A6D18 for ; Sat, 5 Apr 2008 06:29:25 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Ji8SX-0008UN-LP; Sat, 05 Apr 2008 08:29:30 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Roger Marshall'" , "'Marc Linsner'" , References: <8C837214C95C864C9F34F3635C2A65750982F0A1@SEA-EXCHVS-2.telecomsys.com><00bf01c895ca$95a378b0$300d0d0a@cisco.com><8C837214C95C864C9F34F3635C2A65750982F52A@SEA-EXCHVS-2.telecomsys.com><008e01c89693$c0d62e00$300d0d0a@cisco.com><8C837214C95C864C9F34F3635C2A65750982F622@SEA-EXCHVS-2.telecomsys.com> <021701c8969d$dde67900$640fa8c0@cis.neustar.com> Date: Sat, 5 Apr 2008 09:29:30 -0400 Message-ID: <02d001c89721$15a9bea0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AciSoBSicmd+wT1mQom8/iePcnSz0wABYVlrACJtvEAAD6FFRAAMWCawAACTyqAAiXueIAAAipQAADAhwqAAAhC7MAAAZgSQAAIgROAAEE1KAAAQpx5w X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Phone BCP: Multiple Location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm not arguing that a LIS may not, under any circumstances, provide more than one answer. I'm saying that for emergency services, it should not do that. In the case we're describing, the LIS is closer to the origin of the data, and has a much better idea than any downstream entity what is the most appropriate answer. It should return the best answer, within the constraints of the protocol and what the user specified. I don't see this as a really practical problem, because it's pretty hard to imagine the circumstance where it exists. If the LCP is DHCP or LLDP-MED, as you say, you only return what was asked for. In HELD, for emergency use, the client would specify the purpose, and the LIS would only have one answer. Nevertheless, we have to say what happens if you do get more than one. Order when it comes from a PIDF is fine. Random when you don't have order to assist you is also fine. Brian -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Saturday, April 05, 2008 1:27 AM To: Brian Rosen; Roger Marshall; Marc Linsner; ecrit@ietf.org Subject: RE: [Ecrit] Phone BCP: Multiple Location Actually, if a LIS has more than one answer it may provide more than one answer, but it MUST return the PIDF-LO based on PIDF-LO profile, so there is no ambiguity as which location to send to LoST. This problem is less of an issue for DHCP, as they specifications already say that the user must explicitly ask it, so that should take care of the multiple problem to some extent. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Brian Rosen Sent: Fri 4/4/2008 4:50 PM To: 'Roger Marshall'; 'Marc Linsner'; ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Multiple Location First of all, I thought we started by trying LCPs until we got an answer. Then I think our advice is that an LCP returns it's most precise location if I has more than one, and never converts. A LIS should never leave a user with a choice. It chooses. Then, if the endpoint has more than one anyway, it has to choose. If a proxy is inserting, and it has more than one, it has to choose. While I could imagine a complex set of rules designed to choose the best based on civic vs geo and confidence/uncertainty, I think we need a very simple tiebreaker. I think that we should work towards never being in this situation rather than trying to optimize what we do when we are in it. So, I think the best answer is, if you really have more than one, and you don't have any basis to choose, make a random choice. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Friday, April 04, 2008 5:21 PM To: Marc Linsner; ecrit@ietf.org Subject: Re: [Ecrit] Phone BCP: Multiple Location Marc: I would imagine that some service providers would have more confidence (no pun intended) in one method vs. another, but acknowledge would be a problem on a level playing field. I didn't see any 'best practice' as to, 1. how a device picks one of three potential locations, or 2. picks from 3 potentially different SIP URIs returned by LoST based on multiple locations input I guess we could dream something up - somebody will have to... We could, -- pick civic based on uncertainty (whoops, civic doesn't have uncertainty) -- pick between '125 River Rd.', '125 River Rd. E' and '125 River Rd. W' (any of the 3 may be valid, could even be on different sides of the river) -- two civics and a geo (e.g., from agps) - does the majority win out, or precise locations trump all others? -- manually provisioned (given) civic vs. CellSectorID civic? -- three geo's with increasing uncertainty - do you pick the one w/the smallest or largest uncertainty value (safer to err on the side of conservativeness)? To differentiate multiple LoST responses, we could go with, choose best 2 out of 3, what happens if all 3 are not the same? Lots of scenarios exist. More important than, 'where do we move the problem', I think that there needs to be some discussion on best practices for 'how to choose'. -roger marshall. > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Friday, April 04, 2008 1:38 PM > To: Roger Marshall; ecrit@ietf.org > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > Roger, > > How would you evaluate which LCP to try first? I assume that > you would recommend the host stop trying if any resemblance > of LCI was returned? > > I agree that receiving multiple LCIs is a problem, but I > don't see how you can predetermine which LCP is going to > return the 'best' information. I think you must try them > all, if you get multiples, they have to be evaluated, even if > that means presenting them to the user. > > -Marc- > > > > > > > My objection is to a written *recommendation* that directs > the client > > to act serially OR act in parallel - as opposed to what, (guessing, > > since not stated) recommending an ordered list of configuration > > protocol candidates? > > > > Better to recommend one thing to do, allow another. > > > > -roger. > > > > > -----Original Message----- > > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > > Sent: Thursday, April 03, 2008 1:38 PM > > > To: Roger Marshall; 'Winterbottom, James'; ecrit@ietf.org > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > Roger, James, > > > > > > You are simply moving the problem. You are stating you > > don't want to > > > tax the target by making it chose between multiple > > locations, but you > > > are asking > > > the target to chose between multiple LCP mechanisms. I > > don't see any > > > difference in the algorithm between choosing between multiple > > > locations or choosing between multiple LCPs. > > > > > > Am I missing something? > > > > > > -Marc- > > > > > > > > > > > [snip] > > > > > On Behalf Of Winterbottom, James > > > > > Sent: Monday, March 31, 2008 7:46 PM > > > > ... > > > > > I think the correct answer is that it should only try 3 > > > > methods if the > > > > > first 2 failed. That is, it tries one method, if that > > > > doesn't work, it > > > > > tries the next one. > > > > [/endsnip] > > > > > > > > I agree with you James, this seems practicle... but phonebcp > > > > recommends an opposite approach (along with your suggested > > > approach). > > > > > > > > ED-22/INT-15 Endpoints SHOULD try all LCPs supported by > > > the device > > > > in > > > > any order or in parallel. The first one that succeeds > > > in supplying > > > > location can be used. > > > > > > > > I think it would be cleaner if Phonebcp recommended > > serial queries > > > > only > > > > - therefore avoiding most of the worry around choosing > > > among different > > > > locations gotten from parallel requests. > > > > > > > > -roger. > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Winterbottom, James > > > > > Sent: Monday, March 31, 2008 7:46 PM > > > > > To: Stark, Barbara; Hannes Tschofenig; ecrit@ietf.org > > > > > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > Hi Barbara, > > > > > > > > > > Having re-read your email I think I misunderstood > what you were > > > > > saying. > > > > > I think what you are saying is that if a device engages all > > > > three LCPs > > > > > and gets a different location for each of them, what > does it do? > > > > > > > > > > I think the correct answer is that it should only try 3 > > > > methods if the > > > > > first 2 failed. That is, it tries one method, if that > > > > doesn't work, it > > > > > tries the next one. > > > > > > > > > > In the HELD routing/dispatch example I hope that we can say > > > > always use > > > > > dispatch since the dispatch location kind of needs to > > > fall into the > > > > > catchment of the routing area to make any sense. > > > > > > > > > > I think we should avoid trying to get as many different > > > > locations as > > > > > we can. > > > > > > > > > > As for DHCP and LLDP-MED I am not sure that I understand > > > your last > > > > > sentence in the first paragraph. I am not aware that we > > > considering > > > > > sending a literal location in any form other than a PIDF-LO > > > > with the > > > > > sos message. > > > > > > > > > > Cheers > > > > > James > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > > Sent: Tuesday, 1 April 2008 1:30 PM > > > > > > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > > > Key words are "Where multiple PIDF documents can be sent or > > > > > received > > > > > > together". When a device has a configured location, a > > > > location from > > > > > > LLDP-MED, one from DHCP, and one or two (routing and > > > > dispatch) from > > > > > > HELD, I think that the quoted language has no relevance > > > > on the order > > > > > in > > > > > > which these are then included in an "sos" message. These > > > > different > > > > > > locations were not received together. LLDP-MED and DHCP > > > > > locations are > > > > > > not received as PIDF documents. > > > > > > > > > > > > This language does apply to the PSAP when it receives all > > > > of these > > > > > > locations. They arrive together, and all in PIDF format. > > > > > > Barbara > > > > > > > > > > > > -----Original Message----- > > > > > > From: Winterbottom, James > > [mailto:James.Winterbottom@andrew.com] > > > > > > Sent: Monday, March 31, 2008 4:29 PM > > > > > > To: Stark, Barbara; Hannes Tschofenig; ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > > > Nope. > > > > > > > > > > > > This is from PIDF-LO Profile > > > > > > > > > > > > " Rule #9: Where multiple PIDF documents can be sent > > > or received > > > > > > together, say in a multi-part MIME body, and > > > > current location > > > > > > information is required by the recipient, > then document > > > > > selection > > > > > > SHOULD be based on document order, with the first > > > document > > > > > > considered first." > > > > > > > > > > > > Cheers > > > > > > James > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > > Sent: Mon 3/31/2008 8:05 AM > > > > > > To: Winterbottom, James; Hannes Tschofenig; ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > > > It's my understanding that PIDF-LO only describes > > > > multiple location > > > > > > precedence within a single message. It doesn't > > describe how to > > > > > > prioritize multiple locations received from various > > > > > sources, received > > > > > > in multiple messages (or statically configured) at > > > various times. > > > > > > > > > > > > I did include that sort of logic in my latest DSLF draft. > > > > > If there is > > > > > a > > > > > > desire to have some of this in phonebcp, I'm fine with that. > > > > > > Barbara > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > Of Winterbottom, James > > > > > > Sent: Sunday, March 30, 2008 4:36 PM > > > > > > To: Hannes Tschofenig; ecrit@ietf.org > > > > > > Subject: Re: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > > > PIDF-LO profile describes how to choose the correct > > location for > > > > > exactly > > > > > > this purpose. > > > > > > That is the application form which the original > > > requirements were > > > > > drawn. > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org on behalf of Hannes Tschofenig > > > > > > Sent: Sun 3/30/2008 2:55 PM > > > > > > To: ecrit@ietf.org > > > > > > Subject: [Ecrit] Phone BCP: Multiple Location > > > > > > > > > > > > " > > > > > > ED-39 If a UA has more than one location available to > > > > it, it MUST > > > > > > choose one location to route the call towards the PSAP. > > > > > > > > > > > > SP-16 If a proxy inserts location on behalf of an > > > > > endpoint, and it > > > > > > has multiple locations available for the endpoint it > > > > MUST choose > > > > > one > > > > > > location to use to route the call towards the PSAP. > > > > > > " > > > > > > > > > > > > I could imagine that someone might ask how to make > a decision. > > > > > > So, how does the decision making look like? > > > > > > > > > > > > _______________________________________________ > > > > > > Ecrit mailing list > > > > > > Ecrit@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------- > > > > > > ------------------------ > > > > > > This message is for the designated recipient only and > > > may contain > > > > > > privileged, proprietary, or otherwise private information. > > > > > > If you have received it in error, please notify the sender > > > > > immediately > > > > > > and delete the original. Any unauthorized use of > > this email is > > > > > > prohibited. > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------- > > > > > > ------------------------ > > > > > > [mf2] > > > > > > > > > > > > _______________________________________________ > > > > > > Ecrit mailing list > > > > > > Ecrit@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------- > > > > > > ------------------------ > > > > > > This message is for the designated recipient only and > > > may contain > > > > > > privileged, proprietary, or otherwise private information. > > > > > > If you have received it in error, please notify the sender > > > > > immediately > > > > > > and delete the original. Any unauthorized use of > > this email is > > > > > > prohibited. > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------- > > > > > > ------------------------ > > > > > > [mf2] > > > > > > > > > > > > > > > > > > ***** > > > > > > > > > > > > The information transmitted is intended only for the person > > > > > or entity > > > > > to > > > > > > which it is addressed and may contain confidential, > > proprietary, > > > > > and/or > > > > > > privileged material. Any review, retransmission, > > > dissemination or > > > > > other > > > > > > use of, or taking of any action in reliance upon this > > > > > information by > > > > > > persons or entities other than the intended recipient is > > > > prohibited. > > > > > If > > > > > > you received this in error, please contact the sender and > > > > > delete the > > > > > > material from all computers. GA622 > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------------------------------- > > > > > This message is for the designated recipient only and > > may contain > > > > > privileged, proprietary, or otherwise private information. > > > > > If you have received it in error, please notify the sender > > > > immediately > > > > > and delete the original. Any unauthorized use of > this email is > > > > > prohibited. > > > > > -------------------------------------------------------------- > > > > > ---------------------------------- > > > > > [mf2] > > > > > > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > > message may > > > > be privileged and/or confidential. If you are not the intended > > > > recipient, or responsible for delivering this message to > > > the intended > > > > recipient, any review, forwarding, dissemination, > distribution or > > > > copying of this communication or any attachment(s) is strictly > > > > prohibited. If you have received this message in error, > > > please notify > > > > the sender immediately, and delete it and all attachments > > from your > > > > computer and network. > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 7 06:35:43 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD73C28C216; Mon, 7 Apr 2008 06:35:43 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4216F3A6E7C for ; Mon, 7 Apr 2008 06:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.232 X-Spam-Level: X-Spam-Status: No, score=-102.232 tagged_above=-999 required=5 tests=[AWL=0.367, 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 mQTMVNkjbOlW for ; Mon, 7 Apr 2008 06:35:36 -0700 (PDT) Received: from aismt07p.bellsouth.com (aismt07p.bellsouth.com [139.76.165.213]) by core3.amsl.com (Postfix) with ESMTP id EB8B53A6BC1 for ; Mon, 7 Apr 2008 06:35:28 -0700 (PDT) Received: from ([139.76.131.83]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.199055519; Mon, 07 Apr 2008 09:35:11 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 7 Apr 2008 09:35:12 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 7 Apr 2008 09:35:11 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 09:35:10 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA083C720E@crexc41p> In-Reply-To: <01d601c8968f$37ba38e0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT Framework: Dial Strings thread-index: AciSb0jFlOgz5NA4RaqbA9nfmYGMvgAJC8bwACZT2rAA2EUNYACJB56A References: <47EF9E65.1090402@gmx.net> <006101c89294$b45036b0$9744f444@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA080ECF11@crexc41p> <01d601c8968f$37ba38e0$640fa8c0@cis.neustar.com> From: "Stark, Barbara" To: "Brian Rosen" , "Hannes Tschofenig" , X-OriginalArrivalTime: 07 Apr 2008 13:35:11.0729 (UTC) FILETIME=[34320E10:01C898B4] Subject: Re: [Ecrit] ECRIT Framework: Dial Strings X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org We need to distinguish between cellular environments where the access network can control what calls the end device can make, and VoIP providers that have no roaming arrangements and place the burden of getting on the Internet on the customer. I'm not aware of any regulations that require these VoIP providers to recognize "local" strings for wherever their customers may be. I'm also not aware of any current regulations on Internet Service Providers or Hotspot providers. I'm not aware of any current regulation that says my SIP phone must understand 9-9-9 to be a request for emergency services when I take it to the UK. Can you point me to such a regulation? Is the regulation on the all phone manufacturers worldwide, the ISP (who is local but doesn't currently sniff for VoIP), or the foreign VSP? Or the customer? Is there a law that says travelers may not bring SIP phones into the country that do not support 9-9-9 as an emergency string? Just who do these regulations apply to? If the regulations don't exist today, who do you expect them to apply to? Also, if they don't exist, and you have no knowledge of even proposed text for such a regulation, is the IETF trying to guide the creation of such regulations? Barbara -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, April 04, 2008 4:05 PM To: Stark, Barbara; 'Hannes Tschofenig'; ecrit@ietf.org Subject: RE: [Ecrit] ECRIT Framework: Dial Strings If you are currently located in the U.S., I believe it is a regulation that 9-1-1 work from a telephone. Not 9-9-9, but 9-1-1. If you are in the U.K., I suspect that it is required that 9-9-9 work. The regulation is of course, antiquated, and doesn't really speak to current technology capabilities. If you are a customer of a U.S. carrier, but you have roamed to the U.K., there is no requirement that 9-1-1 work, but there is a requirement that 9-9-9 work. That is in current regs. That is more or less a by-product of how roaming is implemented in mobile telephone networks, but the reality is that local is required. I wouldn't presume to speak for any U.S. government agency, but I've had some discussions on the subject, and I think they don't care what happens when a customer of a U.S. carrier is located in the U.K., but they do care what happens when a customer of a U.K. carrier is located in the U.S. They want 9-1-1 to work. I know that's how NENA feels. Brian -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Monday, March 31, 2008 9:29 AM To: Brian Rosen; Hannes Tschofenig; ecrit@ietf.org Subject: RE: [Ecrit] ECRIT Framework: Dial Strings I'm not aware of any country that requires that companies operating in foreign countries recognize "local" dial strings, when their customers are traveling into the "local" country. Likewise, I'm not aware of any country that has emergency dialing legislation regarding devices that visitors bring into the country or that residents bring in from foreign countries. I think the "legal requirements" argument is empty. But I don't see that requiring end devices to request local dial strings is a bad thing. I also think that there's a strong likelihood that "home" governments will require "home" service providers and "home" devices to support "home" dial strings, no matter where the device may go. Since the BCP doesn't preclude this, and sufficiently describes how this can be done, I'm ok with the phonebcp language. So, I'm fine with the requirements as they are. But I still think that this "legal" argument is backwards and incorrect. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Sunday, March 30, 2008 2:35 PM To: 'Hannes Tschofenig'; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Framework: Dial Strings No current systems recognize the home dial string unless they happen to be the same, or there is some fixed strings always recognized. There are legal requirements for the local one, and there are none for the home one. Unless you have some good reason, I think there is no requirement to support the home dial string. I'm not even sure it's a good idea. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 10:06 AM To: ecrit@ietf.org Subject: [Ecrit] ECRIT Framework: Dial Strings You write: " Therefore, the visited dial string must work while having the home dial string work is optional. " I don't understand this reasoning on why the home dial string is optional. From an implementation point of view you have to implement the home emergency dial strings since in most cases devices will be used "at home". Why isn't the ability to understand the home dial string mandatory? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 7 08:36:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CA433A698B; Mon, 7 Apr 2008 08:36:25 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B47963A690C for ; Mon, 7 Apr 2008 08:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.764, 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 TCi0Uil3n6-U for ; Mon, 7 Apr 2008 08:36:23 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 72B3128C3C7 for ; Mon, 7 Apr 2008 08:36:23 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JitOZ-0005MZ-3X; Mon, 07 Apr 2008 10:36:31 -0500 From: "Brian Rosen" To: "'Stark, Barbara'" , "'Hannes Tschofenig'" , References: <47EF9E65.1090402@gmx.net> <006101c89294$b45036b0$9744f444@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA080ECF11@crexc41p> <01d601c8968f$37ba38e0$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA083C720E@crexc41p> Date: Mon, 7 Apr 2008 11:36:33 -0400 Message-ID: <04e001c898c5$2a085eb0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA083C720E@crexc41p> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AciSb0jFlOgz5NA4RaqbA9nfmYGMvgAJC8bwACZT2rAA2EUNYACJB56AAAQpcvA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] ECRIT Framework: Dial Strings X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Do you think the user experience of cellular roam and VoIP nomadic should be different? As I said, current regulations are antiquated. They apply to telephone carriers, and, in the U.S., VoIP service providers. I don't think there are any emergency service obligations on ISPs or hotspot providers currently. Given that the wording of the regulations really don't adequately cover technology evolution, the intent is pretty clear. When you are in the U.S., U.S. rules apply. When you are in the U.K., U.K. rules apply. As with all Internet services, it's pretty hard for a U.S. law to apply to a service provider operating outside the U.S. even if the service is provided to a U.S. consumer while he is in the U.S. (and the same for any other country). IANAL. I'm not as familiar with U.K. law applicable to VoIP, but let's take U.S. regulations. If you were in the U.S., and you had dial in and dial out capability to the U.S. PSTN, regardless of whether your VoIP provider was a U.S. service provider, I believe you would come under the VoIP E9-1-1 regulations, and 9-1-1 has to work. I think the FCC would say that the (foreign) VoIP provider has to meet the requirements and not the ISP, or even the underlying carrier who would be providing PSTN connections and telephone numbers. And it doesn't matter where you got your phone. I don't want to see more regulation (less would be better). However, I think we have to be cognizant that the local regulator, and the rules applicable to a local provider, should apply to a roamer or a nomad, even if the reach of the regulator doesn't actually extend that far. I also think the local PSAPs want their local emergency number to work for all visitors. I don't think they care if the home dial string works, they do care if the local one works. Brian -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Monday, April 07, 2008 9:35 AM To: Brian Rosen; Hannes Tschofenig; ecrit@ietf.org Subject: RE: [Ecrit] ECRIT Framework: Dial Strings We need to distinguish between cellular environments where the access network can control what calls the end device can make, and VoIP providers that have no roaming arrangements and place the burden of getting on the Internet on the customer. I'm not aware of any regulations that require these VoIP providers to recognize "local" strings for wherever their customers may be. I'm also not aware of any current regulations on Internet Service Providers or Hotspot providers. I'm not aware of any current regulation that says my SIP phone must understand 9-9-9 to be a request for emergency services when I take it to the UK. Can you point me to such a regulation? Is the regulation on the all phone manufacturers worldwide, the ISP (who is local but doesn't currently sniff for VoIP), or the foreign VSP? Or the customer? Is there a law that says travelers may not bring SIP phones into the country that do not support 9-9-9 as an emergency string? Just who do these regulations apply to? If the regulations don't exist today, who do you expect them to apply to? Also, if they don't exist, and you have no knowledge of even proposed text for such a regulation, is the IETF trying to guide the creation of such regulations? Barbara -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, April 04, 2008 4:05 PM To: Stark, Barbara; 'Hannes Tschofenig'; ecrit@ietf.org Subject: RE: [Ecrit] ECRIT Framework: Dial Strings If you are currently located in the U.S., I believe it is a regulation that 9-1-1 work from a telephone. Not 9-9-9, but 9-1-1. If you are in the U.K., I suspect that it is required that 9-9-9 work. The regulation is of course, antiquated, and doesn't really speak to current technology capabilities. If you are a customer of a U.S. carrier, but you have roamed to the U.K., there is no requirement that 9-1-1 work, but there is a requirement that 9-9-9 work. That is in current regs. That is more or less a by-product of how roaming is implemented in mobile telephone networks, but the reality is that local is required. I wouldn't presume to speak for any U.S. government agency, but I've had some discussions on the subject, and I think they don't care what happens when a customer of a U.S. carrier is located in the U.K., but they do care what happens when a customer of a U.K. carrier is located in the U.S. They want 9-1-1 to work. I know that's how NENA feels. Brian -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Monday, March 31, 2008 9:29 AM To: Brian Rosen; Hannes Tschofenig; ecrit@ietf.org Subject: RE: [Ecrit] ECRIT Framework: Dial Strings I'm not aware of any country that requires that companies operating in foreign countries recognize "local" dial strings, when their customers are traveling into the "local" country. Likewise, I'm not aware of any country that has emergency dialing legislation regarding devices that visitors bring into the country or that residents bring in from foreign countries. I think the "legal requirements" argument is empty. But I don't see that requiring end devices to request local dial strings is a bad thing. I also think that there's a strong likelihood that "home" governments will require "home" service providers and "home" devices to support "home" dial strings, no matter where the device may go. Since the BCP doesn't preclude this, and sufficiently describes how this can be done, I'm ok with the phonebcp language. So, I'm fine with the requirements as they are. But I still think that this "legal" argument is backwards and incorrect. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Sunday, March 30, 2008 2:35 PM To: 'Hannes Tschofenig'; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Framework: Dial Strings No current systems recognize the home dial string unless they happen to be the same, or there is some fixed strings always recognized. There are legal requirements for the local one, and there are none for the home one. Unless you have some good reason, I think there is no requirement to support the home dial string. I'm not even sure it's a good idea. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 30, 2008 10:06 AM To: ecrit@ietf.org Subject: [Ecrit] ECRIT Framework: Dial Strings You write: " Therefore, the visited dial string must work while having the home dial string work is optional. " I don't understand this reasoning on why the home dial string is optional. From an implementation point of view you have to implement the home emergency dial strings since in most cases devices will be used "at home". Why isn't the ability to understand the home dial string mandatory? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 7 08:49:32 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27DE3A6CD4; Mon, 7 Apr 2008 08:49:32 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BD9D28C3EF for ; Mon, 7 Apr 2008 08:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOoAIU3hHnmF for ; Mon, 7 Apr 2008 08:49:26 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id B72B93A6BE5 for ; Mon, 7 Apr 2008 08:49:25 -0700 (PDT) Received: from [209.2.226.206] ([209.2.226.206]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m37FnWlQ005174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 7 Apr 2008 11:49:32 -0400 (EDT) Message-Id: <684AD948-0033-4DDC-A7B3-7E272DF0EE3C@cs.columbia.edu> From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <04e001c898c5$2a085eb0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 7 Apr 2008 11:49:31 -0400 References: <47EF9E65.1090402@gmx.net> <006101c89294$b45036b0$9744f444@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA080ECF11@crexc41p> <01d601c8968f$37ba38e0$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA083C720E@crexc41p> <04e001c898c5$2a085eb0$640fa8c0@cis.neustar.com> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6 Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Framework: Dial Strings X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm not sure anticipating or guessing at regulation is particularly helpful. I think we have the chance, with minimal effort, to create a system that works better, for the user, than the current system. Our job is not to satisfy regulators or lawyers, but to engineer for those that actually need emergency services. We've discussed several times in the past why having both dial strings is useful, such as the lack of familiarity of tourists with the dial string in the country visited and the "good samaritan" situation. It should also be noted that the current cellular system, having both 1-1-2 and 9-1-1 hardcoded (among others), already offers the visited/ home functionality to hundreds of millions and users/tourists, so it would seem peculiar to regress below that functionality. Henning On Apr 7, 2008, at 11:36 AM, Brian Rosen wrote: > Do you think the user experience of cellular roam and VoIP nomadic > should be > different? > > As I said, current regulations are antiquated. They apply to > telephone > carriers, and, in the U.S., VoIP service providers. I don't think > there are > any emergency service obligations on ISPs or hotspot providers > currently. > > Given that the wording of the regulations really don't adequately > cover > technology evolution, the intent is pretty clear. When you are in > the U.S., > U.S. rules apply. When you are in the U.K., U.K. rules apply. As > with all > Internet services, it's pretty hard for a U.S. law to apply to a > service > provider operating outside the U.S. even if the service is provided > to a > U.S. consumer while he is in the U.S. (and the same for any other > country). > > IANAL. I'm not as familiar with U.K. law applicable to VoIP, but > let's take > U.S. regulations. If you were in the U.S., and you had dial in and > dial out > capability to the U.S. PSTN, regardless of whether your VoIP > provider was a > U.S. service provider, I believe you would come under the VoIP E9-1-1 > regulations, and 9-1-1 has to work. I think the FCC would say that > the > (foreign) VoIP provider has to meet the requirements and not the > ISP, or > even the underlying carrier who would be providing PSTN connections > and > telephone numbers. And it doesn't matter where you got your phone. > > I don't want to see more regulation (less would be better). > However, I > think we have to be cognizant that the local regulator, and the rules > applicable to a local provider, should apply to a roamer or a nomad, > even if > the reach of the regulator doesn't actually extend that far. I also > think > the local PSAPs want their local emergency number to work for all > visitors. > I don't think they care if the home dial string works, they do care > if the > local one works. > > Brian > > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Monday, April 07, 2008 9:35 AM > To: Brian Rosen; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] ECRIT Framework: Dial Strings > > We need to distinguish between cellular environments where the access > network can control what calls the end device can make, and VoIP > providers that have no roaming arrangements and place the burden of > getting on the Internet on the customer. > > I'm not aware of any regulations that require these VoIP providers to > recognize "local" strings for wherever their customers may be. I'm > also > not aware of any current regulations on Internet Service Providers or > Hotspot providers. > > I'm not aware of any current regulation that says my SIP phone must > understand 9-9-9 to be a request for emergency services when I take it > to the UK. Can you point me to such a regulation? Is the regulation on > the all phone manufacturers worldwide, the ISP (who is local but > doesn't > currently sniff for VoIP), or the foreign VSP? Or the customer? Is > there > a law that says travelers may not bring SIP phones into the country > that > do not support 9-9-9 as an emergency string? Just who do these > regulations apply to? If the regulations don't exist today, who do you > expect them to apply to? Also, if they don't exist, and you have no > knowledge of even proposed text for such a regulation, is the IETF > trying to guide the creation of such regulations? > Barbara > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, April 04, 2008 4:05 PM > To: Stark, Barbara; 'Hannes Tschofenig'; ecrit@ietf.org > Subject: RE: [Ecrit] ECRIT Framework: Dial Strings > > If you are currently located in the U.S., I believe it is a regulation > that > 9-1-1 work from a telephone. Not 9-9-9, but 9-1-1. If you are in the > U.K., > I suspect that it is required that 9-9-9 work. The regulation is of > course, > antiquated, and doesn't really speak to current technology > capabilities. > > If you are a customer of a U.S. carrier, but you have roamed to the > U.K., > there is no requirement that 9-1-1 work, but there is a requirement > that > 9-9-9 work. That is in current regs. That is more or less a by- > product > of > how roaming is implemented in mobile telephone networks, but the > reality > is > that local is required. > > I wouldn't presume to speak for any U.S. government agency, but I've > had > some discussions on the subject, and I think they don't care what > happens > when a customer of a U.S. carrier is located in the U.K., but they do > care > what happens when a customer of a U.K. carrier is located in the U.S. > They > want 9-1-1 to work. I know that's how NENA feels. > > Brian > > > > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Monday, March 31, 2008 9:29 AM > To: Brian Rosen; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] ECRIT Framework: Dial Strings > > I'm not aware of any country that requires that companies operating in > foreign countries recognize "local" dial strings, when their customers > are traveling into the "local" country. > > Likewise, I'm not aware of any country that has emergency dialing > legislation regarding devices that visitors bring into the country or > that residents bring in from foreign countries. > > I think the "legal requirements" argument is empty. But I don't see > that > requiring end devices to request local dial strings is a bad thing. > > I also think that there's a strong likelihood that "home" governments > will require "home" service providers and "home" devices to support > "home" dial strings, no matter where the device may go. Since the BCP > doesn't preclude this, and sufficiently describes how this can be > done, > I'm ok with the phonebcp language. > > So, I'm fine with the requirements as they are. But I still think that > this "legal" argument is backwards and incorrect. > Barbara > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Sunday, March 30, 2008 2:35 PM > To: 'Hannes Tschofenig'; ecrit@ietf.org > Subject: Re: [Ecrit] ECRIT Framework: Dial Strings > > No current systems recognize the home dial string unless they happen > to > be > the same, or there is some fixed strings always recognized. There are > legal > requirements for the local one, and there are none for the home one. > > Unless you have some good reason, I think there is no requirement to > support > the home dial string. I'm not even sure it's a good idea. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > Hannes Tschofenig > Sent: Sunday, March 30, 2008 10:06 AM > To: ecrit@ietf.org > Subject: [Ecrit] ECRIT Framework: Dial Strings > > You write: > " > Therefore, the visited dial string must > work while having the home dial string work is optional. > " > > I don't understand this reasoning on why the home dial string is > optional. > From an implementation point of view you have to implement the home > emergency dial strings since in most cases devices will be used "at > home". > Why isn't the ability to understand the home dial string mandatory? > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > ***** > > The information transmitted is intended only for the person or > entity to > which it is addressed and may contain confidential, proprietary, and/ > or > privileged material. Any review, retransmission, dissemination or > other use > of, or taking of any action in reliance upon this information by > persons or > entities other than the intended recipient is prohibited. If you > received > this in error, please contact the sender and delete the material > from all > computers. GA622 > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 7 08:53:17 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F19B3A6EBD; Mon, 7 Apr 2008 08:53:17 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91DF028C413 for ; Mon, 7 Apr 2008 08:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=0.758, 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 DIlvteGf-xs2 for ; Mon, 7 Apr 2008 08:53:09 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id C66AB28C426 for ; Mon, 7 Apr 2008 08:52:55 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JiteZ-00074L-Ik; Mon, 07 Apr 2008 10:53:03 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" References: <47EF9E65.1090402@gmx.net> <006101c89294$b45036b0$9744f444@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA080ECF11@crexc41p> <01d601c8968f$37ba38e0$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA083C720E@crexc41p> <04e001c898c5$2a085eb0$640fa8c0@cis.neustar.com> <684AD948-0033-4DDC-A7B3-7E272DF0EE3C@cs.columbia.edu> Date: Mon, 7 Apr 2008 11:53:05 -0400 Message-ID: <04e401c898c7$79a2b7c0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <684AD948-0033-4DDC-A7B3-7E272DF0EE3C@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AciYxvh9TRUTffoyQCmLnDQ2e+g7YAAAFKbQ 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] ECRIT Framework: Dial Strings X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I have no problem with MUST local and SHOULD home. I think MUST local is required. I think you don't need to have MUST home. -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, April 07, 2008 11:50 AM To: Brian Rosen Cc: 'Stark, Barbara'; 'Hannes Tschofenig'; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Framework: Dial Strings I'm not sure anticipating or guessing at regulation is particularly helpful. I think we have the chance, with minimal effort, to create a system that works better, for the user, than the current system. Our job is not to satisfy regulators or lawyers, but to engineer for those that actually need emergency services. We've discussed several times in the past why having both dial strings is useful, such as the lack of familiarity of tourists with the dial string in the country visited and the "good samaritan" situation. It should also be noted that the current cellular system, having both 1-1-2 and 9-1-1 hardcoded (among others), already offers the visited/ home functionality to hundreds of millions and users/tourists, so it would seem peculiar to regress below that functionality. Henning On Apr 7, 2008, at 11:36 AM, Brian Rosen wrote: > Do you think the user experience of cellular roam and VoIP nomadic > should be > different? > > As I said, current regulations are antiquated. They apply to > telephone > carriers, and, in the U.S., VoIP service providers. I don't think > there are > any emergency service obligations on ISPs or hotspot providers > currently. > > Given that the wording of the regulations really don't adequately > cover > technology evolution, the intent is pretty clear. When you are in > the U.S., > U.S. rules apply. When you are in the U.K., U.K. rules apply. As > with all > Internet services, it's pretty hard for a U.S. law to apply to a > service > provider operating outside the U.S. even if the service is provided > to a > U.S. consumer while he is in the U.S. (and the same for any other > country). > > IANAL. I'm not as familiar with U.K. law applicable to VoIP, but > let's take > U.S. regulations. If you were in the U.S., and you had dial in and > dial out > capability to the U.S. PSTN, regardless of whether your VoIP > provider was a > U.S. service provider, I believe you would come under the VoIP E9-1-1 > regulations, and 9-1-1 has to work. I think the FCC would say that > the > (foreign) VoIP provider has to meet the requirements and not the > ISP, or > even the underlying carrier who would be providing PSTN connections > and > telephone numbers. And it doesn't matter where you got your phone. > > I don't want to see more regulation (less would be better). > However, I > think we have to be cognizant that the local regulator, and the rules > applicable to a local provider, should apply to a roamer or a nomad, > even if > the reach of the regulator doesn't actually extend that far. I also > think > the local PSAPs want their local emergency number to work for all > visitors. > I don't think they care if the home dial string works, they do care > if the > local one works. > > Brian > > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Monday, April 07, 2008 9:35 AM > To: Brian Rosen; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] ECRIT Framework: Dial Strings > > We need to distinguish between cellular environments where the access > network can control what calls the end device can make, and VoIP > providers that have no roaming arrangements and place the burden of > getting on the Internet on the customer. > > I'm not aware of any regulations that require these VoIP providers to > recognize "local" strings for wherever their customers may be. I'm > also > not aware of any current regulations on Internet Service Providers or > Hotspot providers. > > I'm not aware of any current regulation that says my SIP phone must > understand 9-9-9 to be a request for emergency services when I take it > to the UK. Can you point me to such a regulation? Is the regulation on > the all phone manufacturers worldwide, the ISP (who is local but > doesn't > currently sniff for VoIP), or the foreign VSP? Or the customer? Is > there > a law that says travelers may not bring SIP phones into the country > that > do not support 9-9-9 as an emergency string? Just who do these > regulations apply to? If the regulations don't exist today, who do you > expect them to apply to? Also, if they don't exist, and you have no > knowledge of even proposed text for such a regulation, is the IETF > trying to guide the creation of such regulations? > Barbara > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, April 04, 2008 4:05 PM > To: Stark, Barbara; 'Hannes Tschofenig'; ecrit@ietf.org > Subject: RE: [Ecrit] ECRIT Framework: Dial Strings > > If you are currently located in the U.S., I believe it is a regulation > that > 9-1-1 work from a telephone. Not 9-9-9, but 9-1-1. If you are in the > U.K., > I suspect that it is required that 9-9-9 work. The regulation is of > course, > antiquated, and doesn't really speak to current technology > capabilities. > > If you are a customer of a U.S. carrier, but you have roamed to the > U.K., > there is no requirement that 9-1-1 work, but there is a requirement > that > 9-9-9 work. That is in current regs. That is more or less a by- > product > of > how roaming is implemented in mobile telephone networks, but the > reality > is > that local is required. > > I wouldn't presume to speak for any U.S. government agency, but I've > had > some discussions on the subject, and I think they don't care what > happens > when a customer of a U.S. carrier is located in the U.K., but they do > care > what happens when a customer of a U.K. carrier is located in the U.S. > They > want 9-1-1 to work. I know that's how NENA feels. > > Brian > > > > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Monday, March 31, 2008 9:29 AM > To: Brian Rosen; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] ECRIT Framework: Dial Strings > > I'm not aware of any country that requires that companies operating in > foreign countries recognize "local" dial strings, when their customers > are traveling into the "local" country. > > Likewise, I'm not aware of any country that has emergency dialing > legislation regarding devices that visitors bring into the country or > that residents bring in from foreign countries. > > I think the "legal requirements" argument is empty. But I don't see > that > requiring end devices to request local dial strings is a bad thing. > > I also think that there's a strong likelihood that "home" governments > will require "home" service providers and "home" devices to support > "home" dial strings, no matter where the device may go. Since the BCP > doesn't preclude this, and sufficiently describes how this can be > done, > I'm ok with the phonebcp language. > > So, I'm fine with the requirements as they are. But I still think that > this "legal" argument is backwards and incorrect. > Barbara > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Sunday, March 30, 2008 2:35 PM > To: 'Hannes Tschofenig'; ecrit@ietf.org > Subject: Re: [Ecrit] ECRIT Framework: Dial Strings > > No current systems recognize the home dial string unless they happen > to > be > the same, or there is some fixed strings always recognized. There are > legal > requirements for the local one, and there are none for the home one. > > Unless you have some good reason, I think there is no requirement to > support > the home dial string. I'm not even sure it's a good idea. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > Hannes Tschofenig > Sent: Sunday, March 30, 2008 10:06 AM > To: ecrit@ietf.org > Subject: [Ecrit] ECRIT Framework: Dial Strings > > You write: > " > Therefore, the visited dial string must > work while having the home dial string work is optional. > " > > I don't understand this reasoning on why the home dial string is > optional. > From an implementation point of view you have to implement the home > emergency dial strings since in most cases devices will be used "at > home". > Why isn't the ability to understand the home dial string mandatory? > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > ***** > > The information transmitted is intended only for the person or > entity to > which it is addressed and may contain confidential, proprietary, and/ > or > privileged material. Any review, retransmission, dissemination or > other use > of, or taking of any action in reliance upon this information by > persons or > entities other than the intended recipient is prohibited. If you > received > this in error, please contact the sender and delete the material > from all > computers. GA622 > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 7 09:02:50 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADCA43A6B7F; Mon, 7 Apr 2008 09:02:50 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9D663A68DB for ; Mon, 7 Apr 2008 09:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.254 X-Spam-Level: X-Spam-Status: No, score=-102.254 tagged_above=-999 required=5 tests=[AWL=0.345, 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 z5+RsCa1xZvH for ; Mon, 7 Apr 2008 09:02:46 -0700 (PDT) Received: from aismt07p.bellsouth.com (aismt07p.bellsouth.com [139.76.165.213]) by core3.amsl.com (Postfix) with ESMTP id 4B9543A67D4 for ; Mon, 7 Apr 2008 09:02:46 -0700 (PDT) Received: from ([139.76.131.83]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.199079255; Mon, 07 Apr 2008 12:02:25 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 7 Apr 2008 12:02:25 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 7 Apr 2008 12:02:25 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 12:02:23 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA083C729D@crexc41p> In-Reply-To: <684AD948-0033-4DDC-A7B3-7E272DF0EE3C@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT Framework: Dial Strings thread-index: AciYxwt3HoCPXwNbSkCqAwy9MBTBDAAAGegA References: <47EF9E65.1090402@gmx.net> <006101c89294$b45036b0$9744f444@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA080ECF11@crexc41p> <01d601c8968f$37ba38e0$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA083C720E@crexc41p> <04e001c898c5$2a085eb0$640fa8c0@cis.neustar.com> <684AD948-0033-4DDC-A7B3-7E272DF0EE3C@cs.columbia.edu> From: "Stark, Barbara" To: "Henning Schulzrinne" , "Brian Rosen" X-OriginalArrivalTime: 07 Apr 2008 16:02:25.0539 (UTC) FILETIME=[C58E7D30:01C898C8] Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Framework: Dial Strings X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I agree. This is why I stated that I think the "legal requirements" argument is empty. It's not an appropriate justification. But I think the capabilities that have been defined are good and sufficient. Namely, - LoST provides a mechanism to supply local dial strings. - phonebcp requires devices to recognize dial strings supplied by LoST - phonebcp encourages devices to support configuration of home dial strings, and recognize such strings I'm ok with the current phonebcp statements relating to service provider support of dial string recognition. Again, I think the requirements are fine. I just wish we'd drop this "legal requirement" justification. I'd be fine with no justification. Or with "good Samaritan" and "tourist" justifications. Barbara -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, April 07, 2008 11:50 AM To: Brian Rosen Cc: Stark, Barbara; 'Hannes Tschofenig'; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Framework: Dial Strings I'm not sure anticipating or guessing at regulation is particularly helpful. I think we have the chance, with minimal effort, to create a system that works better, for the user, than the current system. Our job is not to satisfy regulators or lawyers, but to engineer for those that actually need emergency services. We've discussed several times in the past why having both dial strings is useful, such as the lack of familiarity of tourists with the dial string in the country visited and the "good samaritan" situation. It should also be noted that the current cellular system, having both 1-1-2 and 9-1-1 hardcoded (among others), already offers the visited/ home functionality to hundreds of millions and users/tourists, so it would seem peculiar to regress below that functionality. Henning On Apr 7, 2008, at 11:36 AM, Brian Rosen wrote: > Do you think the user experience of cellular roam and VoIP nomadic > should be > different? > > As I said, current regulations are antiquated. They apply to > telephone > carriers, and, in the U.S., VoIP service providers. I don't think > there are > any emergency service obligations on ISPs or hotspot providers > currently. > > Given that the wording of the regulations really don't adequately > cover > technology evolution, the intent is pretty clear. When you are in > the U.S., > U.S. rules apply. When you are in the U.K., U.K. rules apply. As > with all > Internet services, it's pretty hard for a U.S. law to apply to a > service > provider operating outside the U.S. even if the service is provided > to a > U.S. consumer while he is in the U.S. (and the same for any other > country). > > IANAL. I'm not as familiar with U.K. law applicable to VoIP, but > let's take > U.S. regulations. If you were in the U.S., and you had dial in and > dial out > capability to the U.S. PSTN, regardless of whether your VoIP > provider was a > U.S. service provider, I believe you would come under the VoIP E9-1-1 > regulations, and 9-1-1 has to work. I think the FCC would say that > the > (foreign) VoIP provider has to meet the requirements and not the > ISP, or > even the underlying carrier who would be providing PSTN connections > and > telephone numbers. And it doesn't matter where you got your phone. > > I don't want to see more regulation (less would be better). > However, I > think we have to be cognizant that the local regulator, and the rules > applicable to a local provider, should apply to a roamer or a nomad, > even if > the reach of the regulator doesn't actually extend that far. I also > think > the local PSAPs want their local emergency number to work for all > visitors. > I don't think they care if the home dial string works, they do care > if the > local one works. > > Brian > > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Monday, April 07, 2008 9:35 AM > To: Brian Rosen; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] ECRIT Framework: Dial Strings > > We need to distinguish between cellular environments where the access > network can control what calls the end device can make, and VoIP > providers that have no roaming arrangements and place the burden of > getting on the Internet on the customer. > > I'm not aware of any regulations that require these VoIP providers to > recognize "local" strings for wherever their customers may be. I'm > also > not aware of any current regulations on Internet Service Providers or > Hotspot providers. > > I'm not aware of any current regulation that says my SIP phone must > understand 9-9-9 to be a request for emergency services when I take it > to the UK. Can you point me to such a regulation? Is the regulation on > the all phone manufacturers worldwide, the ISP (who is local but > doesn't > currently sniff for VoIP), or the foreign VSP? Or the customer? Is > there > a law that says travelers may not bring SIP phones into the country > that > do not support 9-9-9 as an emergency string? Just who do these > regulations apply to? If the regulations don't exist today, who do you > expect them to apply to? Also, if they don't exist, and you have no > knowledge of even proposed text for such a regulation, is the IETF > trying to guide the creation of such regulations? > Barbara > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, April 04, 2008 4:05 PM > To: Stark, Barbara; 'Hannes Tschofenig'; ecrit@ietf.org > Subject: RE: [Ecrit] ECRIT Framework: Dial Strings > > If you are currently located in the U.S., I believe it is a regulation > that > 9-1-1 work from a telephone. Not 9-9-9, but 9-1-1. If you are in the > U.K., > I suspect that it is required that 9-9-9 work. The regulation is of > course, > antiquated, and doesn't really speak to current technology > capabilities. > > If you are a customer of a U.S. carrier, but you have roamed to the > U.K., > there is no requirement that 9-1-1 work, but there is a requirement > that > 9-9-9 work. That is in current regs. That is more or less a by- > product > of > how roaming is implemented in mobile telephone networks, but the > reality > is > that local is required. > > I wouldn't presume to speak for any U.S. government agency, but I've > had > some discussions on the subject, and I think they don't care what > happens > when a customer of a U.S. carrier is located in the U.K., but they do > care > what happens when a customer of a U.K. carrier is located in the U.S. > They > want 9-1-1 to work. I know that's how NENA feels. > > Brian > > > > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Monday, March 31, 2008 9:29 AM > To: Brian Rosen; Hannes Tschofenig; ecrit@ietf.org > Subject: RE: [Ecrit] ECRIT Framework: Dial Strings > > I'm not aware of any country that requires that companies operating in > foreign countries recognize "local" dial strings, when their customers > are traveling into the "local" country. > > Likewise, I'm not aware of any country that has emergency dialing > legislation regarding devices that visitors bring into the country or > that residents bring in from foreign countries. > > I think the "legal requirements" argument is empty. But I don't see > that > requiring end devices to request local dial strings is a bad thing. > > I also think that there's a strong likelihood that "home" governments > will require "home" service providers and "home" devices to support > "home" dial strings, no matter where the device may go. Since the BCP > doesn't preclude this, and sufficiently describes how this can be > done, > I'm ok with the phonebcp language. > > So, I'm fine with the requirements as they are. But I still think that > this "legal" argument is backwards and incorrect. > Barbara > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Sunday, March 30, 2008 2:35 PM > To: 'Hannes Tschofenig'; ecrit@ietf.org > Subject: Re: [Ecrit] ECRIT Framework: Dial Strings > > No current systems recognize the home dial string unless they happen > to > be > the same, or there is some fixed strings always recognized. There are > legal > requirements for the local one, and there are none for the home one. > > Unless you have some good reason, I think there is no requirement to > support > the home dial string. I'm not even sure it's a good idea. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > Hannes Tschofenig > Sent: Sunday, March 30, 2008 10:06 AM > To: ecrit@ietf.org > Subject: [Ecrit] ECRIT Framework: Dial Strings > > You write: > " > Therefore, the visited dial string must > work while having the home dial string work is optional. > " > > I don't understand this reasoning on why the home dial string is > optional. > From an implementation point of view you have to implement the home > emergency dial strings since in most cases devices will be used "at > home". > Why isn't the ability to understand the home dial string mandatory? > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > ***** > > The information transmitted is intended only for the person or > entity to > which it is addressed and may contain confidential, proprietary, and/ > or > privileged material. Any review, retransmission, dissemination or > other use > of, or taking of any action in reliance upon this information by > persons or > entities other than the intended recipient is prohibited. If you > received > this in error, please contact the sender and delete the material > from all > computers. GA622 > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 7 11:28:17 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E59A228C302; Mon, 7 Apr 2008 11:28:17 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC8CB28C2C9 for ; Mon, 7 Apr 2008 11:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.724 X-Spam-Level: X-Spam-Status: No, score=-3.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYoKD1FV5suy for ; Mon, 7 Apr 2008 11:28:16 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id D72FC3A6A31 for ; Mon, 7 Apr 2008 11:28:15 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m37ISOcu023894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 7 Apr 2008 14:28:24 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <04e401c898c7$79a2b7c0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 7 Apr 2008 14:28:24 -0400 References: <47EF9E65.1090402@gmx.net> <006101c89294$b45036b0$9744f444@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA080ECF11@crexc41p> <01d601c8968f$37ba38e0$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA083C720E@crexc41p> <04e001c898c5$2a085eb0$640fa8c0@cis.neustar.com> <684AD948-0033-4DDC-A7B3-7E272DF0EE3C@cs.columbia.edu> <04e401c898c7$79a2b7c0$640fa8c0@cis.neustar.com> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Cc: ECRIT Subject: Re: [Ecrit] ECRIT Framework: Dial Strings X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org SHOULD without reasons when not to do is is just weaseling out of making a decision. There's nothing difficult about declaring that phonebcp-compliant devices MUST allow configuration of a "home country". If LoST is available and that country information is reachable, it can then be used to retrieve the home dial string. Obviously, if there's no such service, we can't create one out of thin air, but MUST/SHOULD here are implementation guidelines, not "MUST work" guidelines. I'm less enamored with a user-configured home dial string (such as 911), although the likelihood of getting this wrong is relatively low. Like Barbara, I'd also prefer the user-focused motivations rather than hiding behind lawyers and regulators. Henning On Apr 7, 2008, at 11:53 AM, Brian Rosen wrote: > I have no problem with MUST local and SHOULD home. > I think MUST local is required. > I think you don't need to have MUST home. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 7 11:36:15 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AA7628C34F; Mon, 7 Apr 2008 11:36:15 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B85328C2C9 for ; Mon, 7 Apr 2008 11:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=0.752, 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 io6qN+KGavlX for ; Mon, 7 Apr 2008 11:36:10 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id BBA8728C3EF for ; Mon, 7 Apr 2008 11:35:53 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JiwCH-0004jN-6y; Mon, 07 Apr 2008 13:36:01 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" References: <47EF9E65.1090402@gmx.net> <006101c89294$b45036b0$9744f444@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA080ECF11@crexc41p> <01d601c8968f$37ba38e0$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA083C720E@crexc41p> <04e001c898c5$2a085eb0$640fa8c0@cis.neustar.com> <684AD948-0033-4DDC-A7B3-7E272DF0EE3C@cs.columbia.edu> <04e401c898c7$79a2b7c0$640fa8c0@cis.neustar.com> Date: Mon, 7 Apr 2008 14:36:04 -0400 Message-ID: <050e01c898de$3e0b51b0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AciY3Slom7Qj9CjATNyoEzo+MCAiFAAAP5sg 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] ECRIT Framework: Dial Strings X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If there are no other objections, I'll do it this way. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, April 07, 2008 2:28 PM To: Brian Rosen Cc: Barbara Stark; ECRIT Subject: Re: [Ecrit] ECRIT Framework: Dial Strings SHOULD without reasons when not to do is is just weaseling out of making a decision. There's nothing difficult about declaring that phonebcp-compliant devices MUST allow configuration of a "home country". If LoST is available and that country information is reachable, it can then be used to retrieve the home dial string. Obviously, if there's no such service, we can't create one out of thin air, but MUST/SHOULD here are implementation guidelines, not "MUST work" guidelines. I'm less enamored with a user-configured home dial string (such as 911), although the likelihood of getting this wrong is relatively low. Like Barbara, I'd also prefer the user-focused motivations rather than hiding behind lawyers and regulators. Henning On Apr 7, 2008, at 11:53 AM, Brian Rosen wrote: > I have no problem with MUST local and SHOULD home. > I think MUST local is required. > I think you don't need to have MUST home. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 8 11:32:12 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1DDA28C418; Tue, 8 Apr 2008 11:32:12 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCD1528C410 for ; Tue, 8 Apr 2008 11:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=0.736, 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 Jw9V2YE8KzJK for ; Tue, 8 Apr 2008 11:32:11 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 568FE28C33A for ; Tue, 8 Apr 2008 11:32:06 -0700 (PDT) Received: (qmail invoked by alias); 08 Apr 2008 18:32:20 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp037) with SMTP; 08 Apr 2008 20:32:20 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18gGCQSo/4gVIM3V+eDg9pN3/RgL+tDKUiqM72wws Ph9/lwYtCjY8l3 Message-ID: <47FBBA34.1050704@gmx.net> Date: Tue, 08 Apr 2008 21:32:20 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: multipart/mixed; boundary="------------030302040306000104060309" X-Y-GMX-Trusted: 0 Cc: Roger Hixson Subject: [Ecrit] NENA NG9-1-1 related Standard for review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --------------030302040306000104060309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, Roger Hixson is asking for feedback on a NENA document (see attachment). Who would be willing to review the NENA document? Please drop us a note. Ciao Hannes --------------030302040306000104060309 Content-Type: application/msword; name="Exhibit IV_NENA TECHNICAL LIAISON (EXTERNAL) FORM (2) RH1.doc" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename*0="Exhibit IV_NENA TECHNICAL LIAISON (EXTERNAL) FORM (2) RH1.do"; filename*1="c" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAWwAAAAAA AAAAEAAAWQAAAAEAAAD+////AAAAAFwAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAA2AJBAAA+BK/AAAAAAAAEAAAAAAABgAA JRIAAA4AYmpiao/qj+oAAAAAAAAAAAAAAAAAAAAAAAAJBBYALkYAAO2AAADtgAAAJQoAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAKQAAAAAABAFAAAAAAAAEAUAABAFAAAAAAAAEAUAAAAAAAAQBQAA AAAAABAFAAAAAAAAEAUAABQAAAAAAAAAAAAAACQFAAAAAAAA8CIAAAAAAADwIgAAAAAAAPAi AAAAAAAA8CIAACQAAAAUIwAApAAAACQFAAAAAAAAmy0AAN4BAADEIwAAFgAAANojAAAAAAAA 2iMAAAAAAADaIwAAAAAAANojAAAAAAAA2iMAAEQAAAAeJAAAHAAAADokAAAQAAAAGi0AAAIA AAAcLQAAAAAAABwtAAAAAAAAHC0AAAAAAAAcLQAAAAAAABwtAAAAAAAAHC0AACQAAAB5LwAA aAIAAOExAAByAAAAQC0AABUAAAAAAAAAAAAAAAAAAAAAAAAAEAUAAAAAAABKJAAAAAAAAAAA AAAAAAAAAAAAAAAAAADaIwAAAAAAANojAAAAAAAASiQAAAAAAABKJAAAAAAAAEAtAAAAAAAA AAAAAAAAAAAQBQAAAAAAABAFAAAAAAAA2iMAAAAAAAAAAAAAAAAAANojAAAAAAAAVS0AABYA AAAmJQAAAAAAACYlAAAAAAAAJiUAAAAAAABKJAAAFgAAABAFAAAAAAAA2iMAAAAAAAAQBQAA AAAAANojAAAAAAAAGi0AAAAAAAAAAAAAAAAAACYlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASiQAAAAAAAAaLQAAAAAAAAAAAAAAAAAA JiUAAAAAAAAmJQAAOgAAAJoqAAAsAAAAEAUAAAAAAAAQBQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2ioAAAAAAADaIwAA AAAAALgjAAAMAAAA8AyTWDxDyAEAAAAAAAAAAPAiAAAAAAAAYCQAAC4AAADGKgAACgAAAAAA AAAAAAAANisAAOQBAABrLQAAMAAAAJstAAAAAAAA0CoAAAoAAABTMgAAAAAAAI4kAACOAAAA UzIAABQAAADaKgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFMyAAAAAAAAAAAAAAAAAAAQBQAA AAAAANoqAABcAAAASiQAAAAAAABKJAAAAAAAACYlAAAAAAAASiQAAAAAAABKJAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASiQAAAAAAABKJAAAAAAAAEokAAAAAAAA QC0AAAAAAABALQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHCUAAAoA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEokAAAAAAAASiQAAAAAAABKJAAA AAAAAJstAAAAAAAASiQAAAAAAABKJAAAAAAAAEokAAAAAAAASiQAAAAAAAAAAAAAAAAAACQF AAAAAAAAJAUAAAQJAAAoDgAAZAoAAIwYAABkCgAAJAUAAAAAAAAkBQAAAAAAACgOAAAAAAAA jBgAAAAAAAAkBQAAAAAAACQFAAAAAAAAJAUAAAAAAAAQBQAAAAAAABAFAAAAAAAAEAUAAAAA AAAQBQAAAAAAABAFAAAAAAAAEAUAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgICAgICAgICAgIE5FTkEgVEVDSE5JQ0FMIExJQUlT T04gKEVYVEVSTkFMKSBGT1JNDQ0NVG8gQmUgQ29tcGxldGVkIGJ5IE9yaWdpbmF0b3IHB0lz c3VlOg0gDU5vdGlmaWNhdGlvbiBvZiBwZW5kaW5nIHB1YmxpY2F0aW9uIHJlZ2FyZGluZyBO RU5BIHByZS1wdWJsaXNoZWQgc3RhbmRhcmQgZG9jdW1lbnQsIJNGdW5jdGlvbmFsIGFuZCBJ bnRlcmZhY2UgU3RhbmRhcmRzIGZvciBOZXh0IEdlbmVyYXRpb24gOS0xLTEgVmVyc2lvbiAx LjAgKGkzKZQsIHdoaWNoIE5FTkEgaW50ZW5kcyB0byBvZmZpY2lhbGx5IHB1Ymxpc2ggYXMg YW4gZW1lcmdlbmN5IHNlcnZpY2VzIHJlbGV2YW50IJNzdGFnZSAylCBhcmNoaXRlY3R1cmUg c3RhbmRhcmQgZG9jdW1lbnQgZm9jdXNlZCBvbiBJUCBiYXNlZCBFbWVyZ2VuY3kgU2Vydmlj ZSBzcGVjaWZpYyBuZXR3b3Jrcy4gIE5FTkEgaXMgYmVnaW5uaW5nIHRoZSByZWxhdGVkIJNz dGFnZSAzkiBkZXNpZ24gd29yayBmb3Igbm9uLUlNUyAoSU1TIGFwcHJvYWNoIGlzIGJ5IEFU SVMpLg0HRGF0ZSBTdWJtaXR0ZWQ6DTEyLzExLzIwMDcHB0RldGFpbGVkIGluZm9ybWF0aW9u IGFib3V0IHJlcXVlc3Q6DQ1UaGUgTkVOQSBMVEQtV0cgd291bGQgbGlrZSB0byBtYWtlIHlv dSBhd2FyZSB0aGF0IG91ciBTdGFnZSAyIGRvY3VtZW50OiCTRnVuY3Rpb25hbCBhbmQgSW50 ZXJmYWNlIFNwZWNpZmljYXRpb25zIGZvciBOZXh0IEdlbmVyYXRpb24gOS0xLTEgVmVyc2lv biAxLjAgKGkzKZQsIGhhcyBub3cgY29tcGxldGVkIGEgcHVibGljIHJldmlldyBzdGFnZSBh bmQgc2hvdWxkLCBmb2xsb3dpbmcgcmVzb2x1dGlvbiBvZiBhbnkgY29tbWVudHMgcmVjZWl2 ZWQgYW5kIG90aGVyIGludGVybmFsIE5FTkEgcHJvY2Vzc2VzLCBiZSByZWxlYXNlZCBhcyBh biBvZmZpY2lhbCBORU5BIFRlY2huaWNhbCBTdGFuZGFyZC4NDVdlIHdlbGNvbWUgYW55IGNv bW1lbnQgeW91IG1heSBoYXZlIG9uIHRoaXMgZG9jdW1lbnQsIHRoYXQgc2hvdWxkIGJlIG9m IGludGVyZXN0IHRvIGFueSBvcmdhbml6YXRpb24gc3BlY2lmeWluZyB0aG9zZSBuZXR3b3Jr cyBhbmQgZnVuY3Rpb25zIHRoYXQgY291bGQgY29uY2VpdmFibHkgY2FycnkgYW5kIHByb2Nl c3MgIGVtZXJnZW5jeSBjYWxscyBhbmQgbWVzc2FnZXMuICANDVdlIGRvIGFudGljaXBhdGUg YW5vdGhlciB2ZXJzaW9uIG9mIHRoaXMgZG9jdW1lbnQgYmVpbmcgaXNzdWVkIG5leHQgeWVh ciwgc28gcmVsZXZhbnQgY29tbWVudHMgcmVjZWl2ZWQgd2lsbCBiZSBjb25zaWRlcmVkIGFz IGlucHV0IHRvIHRoZSB1cGRhdGUgcHJvY2VzcyBmb3IgdGhlIG5leHQgdmVyc2lvbi4NDVRo ZSBkb2N1bWVudCB0aXRsZWQsIJNGdW5jdGlvbmFsIGFuZCBJbnRlcmZhY2UgU3RhbmRhcmRz IGZvciBOZXh0IEdlbmVyYXRpb24gOS0xLTEgVmVyc2lvbiAxLjAgKGkzKZQsIGlzIHBvc3Rl ZCBvbiB0aGUgTkVOQSBwdWJsaWMgc2l0ZSwgdW5kZXIgdGhlIGZvbGxvd2luZyBsaW5rOg0N E0hZUEVSTElOSyBodHRwOi8vd3d3Lm5lbmEub3JnL21lZGlhL2ZpbGVzL0Z1bmNhbmRJdGZT dGRmb3JORzktMS0xUHVibGljUmV2aWV3MTAtMjYtMDcucGRmIAEUaHR0cDovL3d3dy5uZW5h Lm9yZy9tZWRpYS9maWxlcy9GdW5jYW5kSXRmU3RkZm9yTkc5LTEtMVB1YmxpY1JldmlldzEw LTI2LTA3LnBkZhUNDW9yIG1heSBiZSBsb2NhdGVkIG9uIHRoZSBORU5BIHdlYnNpdGUgYWZ0 ZXIgcHVibGljYXRpb24gdW5kZXIgVGVjaG5pY2FsIFN0YW5kYXJkcy4NBwdSZWZlciBUbzog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHNw ZWNpZnkpDV9fX19fQVRJUyAgICAgX1hfX0VTSUYgICAgIF9YX19JRUVFICAgICBfX1hfSUVU RiAgICAgX1hfX09USEVSICgzR1BQMiwgRFNMIEZvcnVtLCBUUjQ1LjIsIDNHUFAsIE9NQSwg Q2FibGUgTGFicywgVFI0NS40KQcHT3JpZ2luYXRvciBDb250YWN0IEluZm9ybWF0aW9uBwdO YW1lB0JyaWFuIFJvc2VuBwdFbWFpbAd0ZWNoZG9jcmV2aWV3QG5lbmEub3JnBwdDb21taXR0 ZWUHTkVOQSBWb0lQL1BhY2tldCBUZWNobmljYWwgQ29tbWl0dGVlLCBMVEQtV0cgICh0aGUg aTMgV0cpBwcNVG8gQmUgQ29tcGxldGVkIGJ5IFJlc3BvbmRlcgcHUmVzcG9uZGVyIENvbnRh Y3QgSW5mb3JtYXRpb24HB05hbWUHBwdFbWFpbAcHB0NvbW1pdHRlZQcHB1Jlc3BvbnNlOiAg DQ0NDQcHDVRvIGJlIENvbXBsZXRlZCBieSBUZWNobmljYWwgQ29tbWl0dGVlIExpYWlzb24H B0V4dGVybmFsIExpYWlzb24gTnVtYmVyBzIwMDcxMTIwLTAwMjAgTkdXBwdEYXRlIFRlY2hu aWNhbCBDb21taXR0ZWUgTGlhaXNvbiByZWZlcnJlZCB0byBORU5BIFRlY2huaWNhbCBEaXJl Y3RvcgcxMS8xNS8wNwcHRGF0ZSBIUSByZWZlcnJlZCB0byBFeHRlcm5hbCBPcmdhbml6YXRp b24HMTIvMTEvMDcHB1JlcXVlc3RlZCBEYXRlIHRvIEluZGljYXRlIFJlY2VpcHQgYW5kIEFj dGlvbnMgBzEvMTUvMDgHB0FjdHVhbCBDb21wbGV0aW9uIERhdGUgBwcHQ29tbWl0dGVlL1dH IFJlZmVycmVkIFRvB05FTkEgTFRELVdHBwcNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAGAAAMCAAAMwgAADQIAAA1CAAAUwgAAFQIAABdCAAAbQgAAHUI AAB7CAAAgAgAAK4JAAAKCgAACwoAAAwKAAAcCgAAHQoAAB4KAAAgCgAAIQoAACYKAAD27dzL tsuek4uTi5OLk3nLZ1hnSWcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA HRZo/y/bAENKFwBPSgIAUUoCAFwIgV5KAwBhShcAHRZobj1DAENKFwBPSgIAUUoCAFwIgV5K AwBhShcAIxVoTiJdABZoTiJdAENKFwBPSgIAUUoCAFwIgV5KAwBhShcAIxVoTiJdABZoekJQ AENKFwBPSgMAUUoDAFwIgV5KAwBhShcADhZobj1DAE9KAgBRSgIAABQVaE4iXQAWaE4iXQBP SgIAUUoCAAAuFWhOIl0AFmh6QlAANQiBQ0oXAE9KAwBRSgMAXAiBXkoDAGFKFwBtSAwEc0gM BAApFmh6QlAANQiBQioBQ0ocAE9KAwBRSgMAXAiBXkoDAGFKHABwaAAAAAAgFmh6QlAANQiB Q0oXAE9KAwBRSgMAXAiBXkoDAGFKFwAAIBZoekJQADUIgUNKHABPSgMAUUoDAFwIgV5KAwBh ShwAABEWaHpCUAA1CIFDShwAYUocABEWaOAQvgA1CIFDShwAYUocAAAVAAYAADMIAAA0CAAA NQgAAFMIAABUCAAAWwgAAF0IAAALCgAA+gAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADlAAAA AAAAAAAAAAAA1AAAAAAAAAAAAAAAAF0AAAAAAAAAAAAAAABPAAAAAAAAAAAAAAAATwAAAAAA AAAAAAAAAEYAAAAAAAAAAAAAAAAJEAAWJAFJZgEAAABnZE4iXQAADQAAFiQBNyQAOCQASCQA SWYBAAAAZ2R6QlAAdwAAa2QAAAAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQB AAAEAQAABAEAAAjWGgABlP90IgAG4CIAAAAAAAAAAAAAAAAAAAAACdYCAAEKdAAA4AES1goA AAD/5ubmAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAA AP8EAQAAFPYD4CIVNgEX9gMAABj2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/zTW BgABBQMAADTWBgABCgNsAGH2AwAAcNYKAAAA/+bm5gAAAAAQAAADJAEWJAE3JAA4JABIJABJ ZgEAAABhJAFnZHpCUAAJAAA3JAA4JABIJABnZHpCUAAMAAADJAE3JAA4JABIJABhJAFnZHpC UAAABA8AZ2TgEL4AAAgABgAAJRIAAP4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEBAQsKAAAMCgAAHAoAACcK AAAoCgAATAoAAE0KAACkCwAApQsAAHwMAAB9DAAALQ0AAC4NAADxAAAAAAAAAAAAAAAA8QAA AAAAAAAAAAAAAPEAAAAAAAAAAAAAAAB2AAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAA AAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAG0AAAAAAAAAAAAAAABtAAAAAAAA AAAAAAAAbQAAAAAAAAAAAAAAAG0AAAAAAAAAAAAAAAAAAAAAAAAAAAAACRAAFiQBSWYBAAAA Z2ROIl0AAHoAAGtkmwAAABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEA AAQBAAAI1jAAApT/uBp0IgAGJBsAAAAAAAAAAAAAAAAAAAAAAAa8BwAAAAAAAAAAAAAAAAAA AAAKdAAA4AET1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAU9gPgIhU2ARf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAA AP8d1ggAAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2AwAAAA0AABYkATckADgkAEgkAElm AQAAAGdkekJQAAAMJgoAACcKAABNCgAA8woAAPoKAACjCwAApAsAAKULAAAjDAAAMQwAAE4M AABbDAAAawwAAHgMAAB7DAAAfAwAANENAADSDQAA0w0AAC0OAAAuDgAALw4AAH4OAAB/DgAA gA4AAIEOAADVDgAAYQ8AAGUPAABuDwAA7dzRydHBudGx0bHRsdG50a2flYGfcZ9t3FzcS9wA IBZopCCEADUIgUNKFwBPSgMAUUoDAFwIgV5KAwBhShcAACAWaE9O2wA1CIFDShcAT0oDAFFK AwBcCIFeSgMAYUoXAAAGFmh6QlAAAB4WaE4iXQA+KgFCKgJPSgIAUUoCAF5KAgBwaAAA/wAA JwIIgQNqLQEAAAYIARVowUVEABZoTiJdAE9KAgBRSgIAVQgBXkoCABIWaE4iXQBPSgIAUUoC AF5KAgAAGwNqAAAAABZoTiJdAE9KAgBRSgIAVQgBXkoCAAYWaE4iXQAADhZo4BC+AE9KAgBR SgIAAA4WaE4iXQBPSgIAUUoCAAAOFmh6QlAAT0oCAFFKAgAADhZobj1DAE9KAgBRSgIAABQV aE4iXQAWaE4iXQBPSgIAUUoCAAAgFmh6QlAANQiBQ0oXAE9KAwBRSgMAXAiBXkoDAGFKFwAA IxVoTiJdABZoekJQAENKFwBPSgIAUUoCAFwIgV5KAwBhShcAAB0uDQAA0Q0AANINAACADgAA gQ4AANQOAADVDgAA1g4AAFMPAADMDwAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADtAAAA AAAAAAAAAAAA3wAAAAAAAAAAAAAAAN8AAAAAAAAAAAAAAADfAAAAAAAAAAAAAAAAdwAAAAAA AAAAAAAAAN8AAAAAAAAAAAAAAADfAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAGcAAGtkPgIAABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEA AAQBAAAI1hoAAZT/dCIABuAiAAAAAAAAAAAAAAAAAAAAAAp0AADgARPWMAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2A+AiFTYBF/YDAAAY9gMA ABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAAAN AAAWJAE3JAA4JABIJABJZgEAAABnZHpCUAAJAAAWJAFJZgEAAABnZHpCUAAJEAAWJAFJZgEA AABnZE4iXQAACW4PAAByDwAAew8AAH8PAACIDwAAjA8AAJEPAADLDwAA8g8AAP0PAAD+DwAA BRAAABsQAAAcEAAAJxAAACwQAABNEAAAVBAAAGAQAABhEAAAYxAAAH8QAADNEAAA/BAAABUR AAAmEQAAbREAAHURAAChEQAAqREAALkRAADv3u/e797N3rup3pqp3ruLu4up3nbedt5l3lTe VN4AAAAAAAAAAAAAAAAAACAWaE9O2wA1CIFDShcAT0oDAFFKAwBcCIFeSgMAYUoXAAAgFmhz bRoANQiBQ0oXAE9KAwBRSgMAXAiBXkoDAGFKFwAAKRZoekJQADUIgUIqAUNKHABPSgMAUUoD AFwIgV5KAwBhShwAcGgAAAAAHRZopCCEAENKFwBPSgMAUUoDAFwIgV5KAwBhShcAHRZo/SyG AENKFwBPSgMAUUoDAFwIgV5KAwBhShcAIxVoTiJdABZoekJQAENKFwBPSgMAUUoDAFwIgV5K AwBhShcAIxVoTiJdABZoTiJdAENKFwBPSgMAUUoDAFwIgV5KAwBhShcAIBZo/SyGADUIgUNK FwBPSgMAUUoDAFwIgV5KAwBhShcAACAWaHpCUAA1CIFDShcAT0oDAFFKAwBcCIFeSgMAYUoX AAAgFmikIIQANQiBQ0oXAE9KAwBRSgMAXAiBXkoDAGFKFwAezA8AAM0PAADsDwAA7Q8AAJcA AAAAAAAAAAAAAACJAAAAAAAAAAAAAAAAIQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGcAAGtk NgMAABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1hoAAZT/ dCIABuAiAAAAAAAAAAAAAAAAAAAAAAp0AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2A+AiFTYBF/YDAAAY9gMAABrWBAAAAP8b1gQA AAD/HNYEAAAA/x3WBAAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAAANAAAWJAE3JAA4JABI JABJZgEAAABnZHpCUAAAZwAAa2S6AgAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEA AAQBAAAEAQAABAEAAAjWGgABlP90IgAG4CIAAAAAAAAAAAAAAAAAAAAACnQAAOABE9YwAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYD4CIVNgEX 9gMAABj2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/zTWBgABBQMAADTWBgABCgNs AGH2AwAAAAPtDwAA8g8AAP4PAAD/DwAABRAAABwQAADuAAAAAAAAAAAAAAAA4AAAAAAAAAAA AAAAAGUAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHoAAGtk sgMAABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1jAAApT/ CAd0IgAGdAcAAAAAAAAAAAAAAAAAAAAAAAZsGwAAAAAAAAAAAAAAAAAAAAAKdAAA4AET1jAA AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPgIhU2 ARf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA /zTWBgABBQMAADTWBgABCgNsAGH2AwAAAA0AABYkATckADgkAEgkAElmAQAAAGdkekJQAAAQ AAADJAIWJAE3JAA4JABIJABJZgEAAABhJAJnZHpCUAAABRwQAAAdEAAAJxAAAGEQAACEAAAA AAAAAAAAAAAAcwAAAAAAAAAAAAAAAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAADQAAFiQBNyQAOCQASCQASWYBAAAAZ2R6QlAAABAAAAMk AhYkATckADgkAEgkAElmAQAAAGEkAmdkekJQAAB6AABrZEQEAAAWJAEXJAFJZgEAAAAClmwA BdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNYwAAKU/wgHdCIABnQHAAAAAAAAAAAAAAAA AAAAAAAGbBsAAAAAAAAAAAAAAAAAAAAACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYD4CIVNgEX9gMAABj2AwAAGtYIAAAA/wAA AP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh 9gMAAAADYRAAAGIQAABjEAAAgBAAAIQAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAAZgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAMk ARYkATckADgkAEgkAElmAQAAAGEkAWdkekJQAA0AAA+E0AI3JAA4JABIJABehNACZ2R6QlAA AHoAAGtk1gQAABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI 1jAAApT/CAd0IgAGdAcAAAAAAAAAAAAAAAAAAAAAAAZsGwAAAAAAAAAAAAAAAAAAAAAKdAAA 4AET1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU 9gPgIhU2ARf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggA AAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2AwAAAAOAEAAAgRAAAJ8QAACIAAAAAAAAAAAA AAAAegAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA0AABYkATckADgkAEgkAElmAQAAAGdkekJQAHcAAGtkaAUAABYkARckAUlmAQAA AAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1hoAAZT/dCIABuAiAAAAAAAAAAAA AAAAAAAAAAnWAgABCnQAAOABEtYKAAAA/+bm5gAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/ BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2A+AiFTYBF/YDAAAY9gMAABrWBAAAAP8b 1gQAAAD/HNYEAAAA/x3WBAAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAHDWCgAAAP/m5uYA AAAAAp8QAACgEAAApRAAAKYQAACXAAAAAAAAAAAAAAAAhgAAAAAAAAAAAAAAAHgAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANAAAWJAE3JAA4JABIJABJZgEAAABnZHpC UAAAEAAAAyQCFiQBNyQAOCQASCQASWYBAAAAYSQCZ2R6QlAAAGcAAGtkAwYAABYkARckAUlm AQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1hoAAZT/dCIABuAiAAAAAAAA AAAAAAAAAAAAAAp0AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAABT2A+AiFTYBF/YDAAAY9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3W BAAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAAADphAAAKcQAACtEAAArhAAAIQAAAAAAAAA AAAAAABzAAAAAAAAAAAAAAAAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAANAAAWJAE3JAA4JABIJABJZgEAAABnZHpCUAAAEAAAAyQCFiQB NyQAOCQASCQASWYBAAAAYSQCZ2R6QlAAAHoAAGtkfwYAABYkARckAUlmAQAAAAKWbAAF1hgE AQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1jAAApT/zAZ0IgAGOAcAAAAAAAAAAAAAAAAAAAAA AAaoGwAAAAAAAAAAAAAAAAAAAAAKdAAA4AET1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPgIhU2ARf2AwAAGPYDAAAa1ggAAAD/AAAA/xvW CAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2AwAA AAOuEAAArxAAALkQAAC6EAAAhAAAAAAAAAAAAAAAAHMAAAAAAAAAAAAAAABlAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AABYkATckADgk AEgkAElmAQAAAGdkekJQAAAQAAADJAIWJAE3JAA4JABIJABJZgEAAABhJAJnZHpCUAAAegAA a2QRBwAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWMAAC lP/MBnQiAAY4BwAAAAAAAAAAAAAAAAAAAAAABqgbAAAAAAAAAAAAAAAAAAAAAAp0AADgARPW MAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2A+Ai FTYBF/YDAAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8A AAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAAAAA7oQAAC7EAAAxxAAAMgQAADJEAAAyhAAAMsQ AACEAAAAAAAAAAAAAAAAdgAAAAAAAAAAAAAAAHYAAAAAAAAAAAAAAAB2AAAAAAAAAAAAAAAA dgAAAAAAAAAAAAAAAHYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AABYk ATckADgkAEgkAElmAQAAAGdkekJQAAB6AABrZKMHAAAWJAEXJAFJZgEAAAAClmwABdYYBAEA AAQBAAAEAQAABAEAAAQBAAAEAQAACNYwAAKU/8wGdCIABjgHAAAAAAAAAAAAAAAAAAAAAAAG qBsAAAAAAAAAAAAAAAAAAAAACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYD4CIVNgEX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggA AAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAAAG yxAAAMwQAADNEAAA/BAAAJcAAAAAAAAAAAAAAACKAAAAAAAAAAAAAAAAeQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAyQBFiQBNyQAOCQASCQASWYBAAAAYSQB Z2R6QlAADQAAD4TQAjckADgkAEgkAF6E0AJnZHpCUAAAZwAAa2Q1CAAAFiQBFyQBSWYBAAAA ApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWGgABlP90IgAG4CIAAAAAAAAAAAAA AAAAAAAACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA AAAAAP8EAQAAFPYD4CIVNgEX9gMAABj2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA /zTWBgABBQMAADTWBgABCgNsAGH2AwAAAAP8EAAA/RAAABURAAAnEQAAiAAAAAAAAAAAAAAA AHcAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAADQAAFiQBNyQAOCQASCQASWYBAAAAZ2R6QlAAABAAAAMk AhYkATckADgkAEgkAElmAQAAAGEkAmdkekJQAHcAAGtksQgAABYkARckAUlmAQAAAAKWbAAF 1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1hoAAZT/dCIABuAiAAAAAAAAAAAAAAAAAAAA AAnWAgABCnQAAOABEtYKAAAA/+bm5gAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAA AP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2A+AiFTYBF/YDAAAY9gMAABrWBAAAAP8b1gQAAAD/ HNYEAAAA/x3WBAAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAHDWCgAAAP/m5uYAAAAAAycR AAAoEQAAbREAAHYRAACEAAAAAAAAAAAAAAAAcwAAAAAAAAAAAAAAAGUAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQAAFiQBNyQAOCQASCQA SWYBAAAAZ2R6QlAAABAAAAMkAhYkATckADgkAEgkAElmAQAAAGEkAmdkekJQAAB6AABrZEwJ AAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNYwAAKU/5wY dCIABggZAAAAAAAAAAAAAAAAAAAAAAAG2AkAAAAAAAAAAAAAAAAAAAAACnQAAOABE9YwAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYD4CIVNgEX 9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP80 1gYAAQUDAAA01gYAAQoDbABh9gMAAAADdhEAAHcRAAChEQAAqhEAAIQAAAAAAAAAAAAAAABz AAAAAAAAAAAAAAAAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAANAAAWJAE3JAA4JABIJABJZgEAAABnZHpCUAAAEAAAAyQCFiQBNyQAOCQA SCQASWYBAAAAYSQCZ2R6QlAAAHoAAGtk3gkAABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEA AAQBAAAEAQAABAEAAAQBAAAI1jAAApT/nBh0IgAGCBkAAAAAAAAAAAAAAAAAAAAAAAbYCQAA AAAAAAAAAAAAAAAAAAAKdAAA4AET1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA AAAAAP8EAQAAAAAA/wQBAAAU9gPgIhU2ARf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8A AAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2AwAAAAOqEQAA qxEAANsRAADjEQAAhAAAAAAAAAAAAAAAAHMAAAAAAAAAAAAAAABlAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AABYkATckADgkAEgkAElm AQAAAGdkekJQAAAQAAADJAIWJAE3JAA4JABIJABJZgEAAABhJAJnZHpCUAAAegAAa2RwCgAA FiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWMAAClP+cGHQi AAYIGQAAAAAAAAAAAAAAAAAAAAAABtgJAAAAAAAAAAAAAAAAAAAAAAp0AADgARPWMAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2A+AiFTYBF/YD AAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/NNYG AAEFAwAANNYGAAEKA2wAYfYDAAAAA7kRAADZEQAA2xEAANwRAADhEQAA4hEAABcSAAAcEgAA IhIAACQSAAAlEgAA797NvO/evKvepwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGFmjqF80AACAWaKQghAA1CIFDShcA T0oDAFFKAwBcCIFeSgMAYUoXAAAgFmhPTtsANQiBQ0oXAE9KAwBRSgMAXAiBXkoDAGFKFwAA IBZo/SyGADUIgUNKFwBPSgMAUUoDAFwIgV5KAwBhShcAACAWaHpCUAA1CIFDShcAT0oDAFFK AwBcCIFeSgMAYUoXAAAgFmj4IBQANQiBQ0oXAE9KAwBRSgMAXAiBXkoDAGFKFwAK4xEAAOQR AAD8EQAA/REAAIQAAAAAAAAAAAAAAABzAAAAAAAAAAAAAAAAZQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANAAAWJAE3JAA4JABIJABJZgEA AABnZHpCUAAAEAAAAyQCFiQBNyQAOCQASCQASWYBAAAAYSQCZ2R6QlAAAHoAAGtkAgsAABYk ARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1jAAApT/nBh0IgAG CBkAAAAAAAAAAAAAAAAAAAAAAAbYCQAAAAAAAAAAAAAAAAAAAAAKdAAA4AET1jAAAAD/BAEA AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPgIhU2ARf2AwAA GPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zTWBgAB BQMAADTWBgABCgNsAGH2AwAAAAP9EQAA/hEAABcSAAAjEgAAhAAAAAAAAAAAAAAAAHMAAAAA AAAAAAAAAABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA0AABYkATckADgkAEgkAElmAQAAAGdkekJQAAAQAAADJAIWJAE3JAA4JABIJABJ ZgEAAABhJAJnZHpCUAAAegAAa2SUCwAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEA AAQBAAAEAQAABAEAAAjWMAAClP+cGHQiAAYIGQAAAAAAAAAAAAAAAAAAAAAABtgJAAAAAAAA AAAAAAAAAAAAAAp0AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAABT2A+AiFTYBF/YDAAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c 1ggAAAD/AAAA/x3WCAAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAAAAAyMSAAAkEgAA JRIAAIQAAAAAAAAAAAAAAAB7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAADckADgkAEgkAGdkT07bAAB6AABrZCYMAAAWJAEX JAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNYwAAKU/5wYdCIABggZ AAAAAAAAAAAAAAAAAAAAAAAG2AkAAAAAAAAAAAAAAAAAAAAACnQAAOABE9YwAAAA/wQBAAAA AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYD4CIVNgEX9gMAABj2 AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQUD AAA01gYAAQoDbABh9gMAAAACLAAxkGgBH7DQLyCw4D0hsAgHIrAIByOQoAUkkKAFJbAAABew 0AIYsNACDJDQAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACZABYkARckAUlm AQAAAAGWAAAhdgABaAE11gUAAQPgIiN2AAHgIjpWCwAClmwACdYCAAEKdAAA4AES1goAAAD/ 5ubmAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAFPYD4CIVNgEY9gMAADXWBQABA+AicNYKAAAA/+bm5gAAAJAAFiQBFyQBSWYBAAAAAZYA ACF2AAJoATXWBQABAyQbNdYFAQIDvAcjdgABJBsjdgECvAc6VgsAApZsAAp0AADgARPWMAAA AP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2A+AiFTYB GPYDAAA11gUAAQMkGzXWBQECA7wHEQEAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIA AAADAAAA4Mnqefm6zhGMggCqAEupC6AAAABoAHQAdABwADoALwAvAHcAdwB3AC4AbgBlAG4A YQAuAG8AcgBnAC8AbQBlAGQAaQBhAC8AZgBpAGwAZQBzAC8ARgB1AG4AYwBhAG4AZABJAHQA ZgBTAHQAZABmAG8AcgBOAEcAOQAtADEALQAxAFAAdQBiAGwAaQBjAFIAZQB2AGkAZQB3ADEA MAAtADIANgAtADAANwAuAHAAZABmAAAAegAWJAEXJAFJZgEAAAABlgAAIXYAAWgBNdYFAAED 4CIjdgAB4CI6VgsAApZsAAp0AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAABT2A+AiFTYBGPYDAAA11gUAAQPgInoAFiQBFyQBSWYBAAAA AZYAACF2AAFoATXWBQABA+AiI3YAAeAiOlYLAAKWbAAKdAAA4AET1jAAAAD/BAEAAAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPgIhU2ARj2AwAANdYFAAED 4CJ6ABYkARckAUlmAQAAAAGWAAAhdgABaAE11gUAAQPgIiN2AAHgIjpWCwAClmwACnQAAOAB E9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYD 4CIVNgEY9gMAADXWBQABA+AikAAWJAEXJAFJZgEAAAABlgAAIXYAAmgBNdYFAAEDdAc11gUB AgNsGyN2AAF0ByN2AQJsGzpWCwAClmwACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYD4CIVNgEY9gMAADXWBQABA3QHNdYFAQID bBuQABYkARckAUlmAQAAAAGWAAAhdgACaAE11gUAAQN0BzXWBQECA2wbI3YAAXQHI3YBAmwb OlYLAAKWbAAKdAAA4AET1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAAAAA/wQBAAAU9gPgIhU2ARj2AwAANdYFAAEDdAc11gUBAgNsG5AAFiQBFyQBSWYBAAAA AZYAACF2AAJoATXWBQABA3QHNdYFAQIDbBsjdgABdAcjdgECbBs6VgsAApZsAAp0AADgARPW MAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2A+Ai FTYBGPYDAAA11gUAAQN0BzXWBQECA2wbmQAWJAEXJAFJZgEAAAABlgAAIXYAAWgBNdYFAAED 4CIjdgAB4CI6VgsAApZsAAnWAgABCnQAAOABEtYKAAAA/+bm5gAAABPWMAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2A+AiFTYBGPYDAAA11gUA AQPgInDWCgAAAP/m5uYAAAB6ABYkARckAUlmAQAAAAGWAAAhdgABaAE11gUAAQPgIiN2AAHg IjpWCwAClmwACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/ BAEAAAAAAP8EAQAAFPYD4CIVNgEY9gMAADXWBQABA+AikAAWJAEXJAFJZgEAAAABlgAAIXYA AmgBNdYFAAEDOAc11gUBAgOoGyN2AAE4ByN2AQKoGzpWCwAClmwACnQAAOABE9YwAAAA/wQB AAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYD4CIVNgEY9gMA ADXWBQABAzgHNdYFAQIDqBuQABYkARckAUlmAQAAAAGWAAAhdgACaAE11gUAAQM4BzXWBQEC A6gbI3YAATgHI3YBAqgbOlYLAAKWbAAKdAAA4AET1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQB AAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPgIhU2ARj2AwAANdYFAAEDOAc11gUBAgOo G5AAFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABAzgHNdYFAQIDqBsjdgABOAcjdgECqBs6 VgsAApZsAAp0AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQB AAAAAAD/BAEAABT2A+AiFTYBGPYDAAA11gUAAQM4BzXWBQECA6gbegAWJAEXJAFJZgEAAAAB lgAAIXYAAWgBNdYFAAED4CIjdgAB4CI6VgsAApZsAAp0AADgARPWMAAAAP8EAQAAAAAA/wQB AAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2A+AiFTYBGPYDAAA11gUAAQPg IpkAFiQBFyQBSWYBAAAAAZYAACF2AAFoATXWBQABA+AiI3YAAeAiOlYLAAKWbAAJ1gIAAQp0 AADgARLWCgAAAP/m5uYAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAA AP8EAQAAAAAA/wQBAAAU9gPgIhU2ARj2AwAANdYFAAED4CJw1goAAAD/5ubmAAAAkAAWJAEX JAFJZgEAAAABlgAAIXYAAmgBNdYFAAEDCBk11gUBAgPYCSN2AAEIGSN2AQLYCTpWCwAClmwA CnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAFPYD4CIVNgEY9gMAADXWBQABAwgZNdYFAQID2AmQABYkARckAUlmAQAAAAGWAAAhdgAC aAE11gUAAQMIGTXWBQECA9gJI3YAAQgZI3YBAtgJOlYLAAKWbAAKdAAA4AET1jAAAAD/BAEA AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPgIhU2ARj2AwAA NdYFAAEDCBk11gUBAgPYCZAAFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABAwgZNdYFAQID 2AkjdgABCBkjdgEC2Ak6VgsAApZsAAp0AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2A+AiFTYBGPYDAAA11gUAAQMIGTXWBQECA9gJ kAAWJAEXJAFJZgEAAAABlgAAIXYAAmgBNdYFAAEDCBk11gUBAgPYCSN2AAEIGSN2AQLYCTpW CwAClmwACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA AAAAAP8EAQAAFPYD4CIVNgEY9gMAADXWBQABAwgZNdYFAQID2AmQABYkARckAUlmAQAAAAGW AAAhdgACaAE11gUAAQMIGTXWBQECA9gJI3YAAQgZI3YBAtgJOlYLAAKWbAAKdAAA4AET1jAA AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPgIhU2 ARj2AwAANdYFAAEDCBk11gUBAgPYCZAAFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABAwgZ NdYFAQID2AkjdgABCBkjdgEC2Ak6VgsAApZsAAp0AADgARPWMAAAAP8EAQAAAAAA/wQBAAAA AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2A+AiFTYBGPYDAAA11gUAAQMIGTXW BQECA9gJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhgIUABIAAQCcAA8ABAAAAAAA AAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAAQPH/AgA4AAwAAAB6QlAA AAAGAE4AbwByAG0AYQBsAAAAAgAAABAAX0gBBG1ICQRzSAkEdEgJBAAAAAAAAAAAAAAAAAAA AAAAAEQAQUDy/6EARAAMAQAAAAAAAAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIA YQBwAGgAIABGAG8AbgB0AAAAAABSAGlA8/+zAFIADAEAAAAAAAAAAAwAVABhAGIAbABlACAA TgBvAHIAbQBhAGwAAAAcABf2AwAANNYGAAEKA2wANNYGAAEFAwAAYfYDAAACAAsAAAAoAGsA 9P/BACgAAAEAAAAAAAAAAAcATgBvACAATABpAHMAdAAAAAIAAAAAAAAANAAfQAEA8gA0AAwA AAB6QlAAAAAGAEgAZQBhAGQAZQByAAAADQAPAA3GCAAC4BDAIQECAAAAjABlQAEAAgGMAAwA AABOIl0AAAARAEgAVABNAEwAIABQAHIAZQBmAG8AcgBtAGEAdAB0AGUAZAAAADcAEAANxjIA EJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAAAAYAE9K BABQSgUAUUoEAF5KBABuSBEEdEgRBDQAVUCiABEBNAAMAAAA2S5bAAAACQBIAHkAcABlAHIA bABpAG4AawAAAAkAPioBcGgAAP8AAC4A/k+iACEBLgAMAAAA2S5bAAAACwBzAGkAZABlAGIA YQByAHQAZQB4AHQAAAAAAEgAmUABADIBSAAMBQAApCCEAAAADABCAGEAbABsAG8AbwBuACAA VABlAHgAdAAAAAIAEwAUAENKEABPSgYAUUoGAF5KBgBhShAAAAAAACUKAAAHAABGAAAIAP// //8AAAAAMwAAADQAAAA1AAAAUwAAAFQAAABbAAAAXQAAAAwCAAAcAgAAJwIAACgCAABMAgAA TQIAAIAGAADVBgAA1gYAAFMHAADMBwAAzQcAAOwHAADtBwAA8gcAAP4HAAD/BwAABQgAABwI AAAdCAAAJwgAAGEIAABiCAAAYwgAAIAIAACBCAAAnwgAAKAIAAClCAAApggAAKcIAACtCAAA rggAAK8IAAC5CAAAuggAALsIAADHCAAAyAgAAMkIAADKCAAAywgAAMwIAADNCAAA/AgAAP0I AAAVCQAAJwkAACgJAABtCQAAdgkAAHcJAAChCQAAqgkAAKsJAADbCQAA4wkAAOQJAAD8CQAA /QkAAP4JAAAXCgAAIwoAACQKAAAnCgAAmkAkIBMwAwAAAAAAAIAUewEAAAAAAAAAAAAAB5pA AAAAMAAAAAAAAACAFHsBAAAAAAAAAAAAAAeaQAAAADAAAAAAAAAAgBR7AQAAAAAAAAAAAAAH q0AAAAAwAAAAAAAAAIAUewEAAQAAAAAAAAAgB5tAAAAAMAAAAAAAAACAFHsBAAEAAAQAAAAA IAerQAAAADAAAAAAAAAAgBR7AQABAAAAAAAAAAAHq0AAAAAwAAAAAAAAAIAUewEAAQAAAAAA AAAAB6tAAAAAMAAAAAAAAACAFHsBAAEAAAAAAAAAIAerQAAAADAAAAAAAAAAgBR7AQABAAAA AAAAAAAHq0AAAAAwAAAAAAAAAIAUewEAAQAAAAAAAAAgB5tAAAAAMAAAAAAAAACAFHsBAAEA AAQAAAAAIAerQAAAADAAAAAAAAAAgBR7AQABAAAAAAAAAAAHq0AAAAAwAAAAAAAAAIAUewEA AQAAAAAAAAAAB6tAAAAAMAAAAAAAAACAFHsBAAEAAAAAAAAAAAerQAAAADAAAAAAAAAAgBR7 AQABAAAAAAAAACAHm0AAAAAwAAAAAAAAAIAUewEAAQAABAAAAAAgB6tAAAAAMAAAAAAAAACA FHsBAAEAAAAAAAAAAAerQAAAADAAAAAAAAAAgBR7AQABAAAAAAAAACAHm0AAAAAwAAAAAAAA AIAUewEAAQAABAAAAAAgB6tAAAAAMAAAAAAAAACAFHsBAAEAAAAAAAAAIAebQAAAADAAAAAA AAAAgBR7AQABAAAEAAAAACAHq0AAAAAwAAAAAAAAAIAUewEAAQAAAAAAAAAgB6tAAAAAMAAA AAAAAACAFHsBAAEAAAAAAAAAIAebQAAAADAAAAAAAAAAgBR7AQABAAAEAAAAACAHq0AAAAAw AAAAAAAAAIAUewEAAQAAAAAAAAAgB6tAAAAAMAAAAAAAAACAFHsBAAEAAAAAAAAAIAebQAAA ADAAAAAAAAAAgBR7AQABAAAEAAAAACAHq0AAAAAwAAAAAAAAAIAUewEAAQAAAAAAAAAgB6tA AAAAMAAAAAAAAACAFHsBAAEAAAAAAAAAIAebQAAAADAAAAAAAAAAgBR7AQABAAAEAAAAACAH mkAAAAAwAAAAAAAAAIAUewEAAAAAAAAAAAAAB6tAAAAAMAAAAAAAAACAFHsBAAEAAAAAAAAA IAebQAAAADAAAAAAAAAAgBR7AQABAAAEAAAAACAHq0AAAAAwAAAAAAAAAIAUewEAAQAAAAAA AAAgB5tAAAAAMAAAAAAAAACAFHsBAAEAAAQAAAAAIAerQAAAADAAAAAAAAAAgBR7AQABAAAA AAAAACAHq0AAAAAwAAAAAAAAAIAUewEAAQAAAAAAAAAgB5tAAAAAMAAAAAAAAACAFHsBAAEA AAQAAAAAIAerQAAAADAAAAAAAAAAgBR7AQABAAAAAAAAACAHq0AAAAAwAAAAAAAAAIAUewEA AQAAAAAAAAAgB5tAAAAAMAAAAAAAAACAFHsBAAEAAAQAAAAAIAerQAAAADAAAAAAAAAAgBR7 AQABAAAAAAAAACAHq0AAAAAwAAAAAAAAAIAUewEAAQAAAAAAAAAgB5tAAAAAMAAAAAAAAACA FHsBAAEAAAQAAAAAIAerQAAAADAAAAAAAAAAgBR7AQABAAAAAAAAAAAHq0AAAAAwAAAAAAAA AIAUewEAAQAAAAAAAAAAB6tAAAAAMAAAAAAAAACAFHsBAAEAAAAAAAAAAAerQAAAADAAAAAA AAAAgBR7AQABAAAAAAAAAAAHq0AAAAAwAAAAAAAAAIAUewEAAQAAAAAAAAAgB5tAAAAAMAAA AAAAAACAFHsBAAEAAAQAAAAAIAeaQAAAADAAAAAAAAAAgBR7AQAAAAAAAAAAAAAHq0AAAAAw AAAAAAAAAIAUewEAAQAAAAAAAAAgB5tAAAAAMAAAAAAAAACAFHsBAAEAAAQAAAAAIAerQAAA ADAAAAAAAAAAgBR7AQABAAAAAAAAACAHq0AAAAAwAAAAAAAAAIAUewEAAQAAAAAAAAAgB5tA AAAAMAAAAAAAAACAFHsBAAEAAAQAAAAAIAerQAAAADAAAAAAAAAAgBR7AQABAAAAAAAAACAH q0AAAAAwAAAAAAAAAIAUewEAAQAAAAAAAAAgB5tAAAAAMAAAAAAAAACAFHsBAAEAAAQAAAAA IAerQAAAADAAAAAAAAAAgBR7AQABAAAAAAAAACAHq0AAAAAwAAAAAAAAAIAUewEAAQAAAAAA AAAgB5tAAAAAMAAAAAAAAACAFHsBAAEAAAQAAAAAIAerQAAAADAAAAAAAAAAgBR7AQABAAAA AAAAACAHq0AAAAAwAAAAAAAAAIAUewEAAQAAAAAAAAAgB5tAAAAAMAAAAAAAAACAFHsBAAEA AAQAAAAAIAerQAAAADAAAAAAAAAAgBR7AQABAAAAAAAAACAHq0AAAAAwAAAAAAAAAIAUewEA AQAAAAAAAAAgB5tAAAAAMAAAAAAAAACAFHsBAAEAAAQAAAAAIAerQAAAADAAAAAAAAAAgBR7 AQABAAAAAAAAACAHq0AAAAAwAAAAAAAAAIAUewEAAQAAAAAAAAAgB5tAAAAAMAAAAAAAAACA FHsBAAEAAAQAAAAAIAcKAAAAADAAAAAAAAAAAAAAAAAGME8EAAAAAAAHAAAAADMAAAA0AAAA NQAAAFMAAABUAAAAWwAAAF0AAAALAgAADAIAABwCAAAnAgAAKAIAAEwCAABNAgAApAMAAKUD AAB8BAAAfQQAAC0FAAAuBQAA0QUAANIFAACABgAAgQYAANQGAADVBgAA1gYAAFMHAADMBwAA zQcAAOwHAADtBwAA8gcAAP4HAAD/BwAABQgAABwIAAAdCAAAJwgAAGEIAABiCAAAYwgAAIAI AACBCAAAnwgAAKAIAAClCAAApggAAKcIAACtCAAArggAAK8IAAC5CAAAuggAALsIAADHCAAA yAgAAMkIAADKCAAAywgAAMwIAADNCAAA/AgAAP0IAAAVCQAAJwkAACgJAABtCQAAdgkAAHcJ AAChCQAAqgkAAKsJAADbCQAA4wkAAOQJAAD8CQAA/QkAAP4JAAAXCgAAIwoAACQKAAAnCgAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAQAAqAAA AAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAAKwAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQ AAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAAAKkAAAAQMAAAAAAAAACAAAAAgAEA ANAAAAAAAACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA AQAA0AAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAA AIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAAAKkAAAAAMAAAAAAAAACA AAAAgAEAANAAAAAAAACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAAAAAqQAAAAAwAAAAAAAA AIAAAACAAQAA0AAAAAAAAKkAAAAQMAAAAAAAAACAAAAAgAEAANAAAAAAAACpAAAAEDAAAAAA AAAAgAAAAIABAADQAAAAAAAAqQAAABAwAAAAAAAAAIAAAACAAQAA0AAAAAAAAKkAAAAQMAAA AAAAAACAAAAAgAEAANAAAAAAAACpAAAAEDAAAAAAAAAAgAAAAIABAADQAAAAAAAAqQAAABAw AAAAAAAAAIAAAACAAQAA0AAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAAACpAAAA ADAAAAAAAAAAgAAAAIABAADQAAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAAAKkA AAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAA qQAAAAAwAAAAAAAAAIAAAACAAQAAqAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAEAAKgAAAAA IACZAAAAADAAAAAAAAAAgAAAAIABAACsAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAqAAA AAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAAKwAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAACo AAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAqAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEA AKwAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAACoAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA AQAAqAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAAKwAAAAAIACpAAAAADAAAAAAAAAAgAAA AIABAACoAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAqAAAAAAgAJkAAAAAMAAAAAAAAACA AAAAgAEAAKwAAAAAIACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAqQAAAAAwAAAAAAAA AIAAAACAAQAAqAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAAKwAAAAAIACpAAAAADAAAAAA AAAAgAAAAIABAACoAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAArAAAAAAgAKkAAAAAMAAA AAAAAACAAAAAgAEAAKgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAACoAAAAACAAmQAAAAAw AAAAAAAAAIAAAACAAQAArAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAKgAAAAAIACpAAAA ADAAAAAAAAAAgAAAAIABAACoAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAArAAAAAAgAKkA AAAAMAAAAAAAAACAAAAAgAEAAKgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAACoAAAAACAA mQAAAAAwAAAAAAAAAIAAAACAAQAArAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAA AACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAA AAAAAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAAACpAAAAADAAAAAAAAAAgAAAAIABAADQ AAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACA AQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAA AIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACA AAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAA AIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAA AAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAA AAAAAACAAAAAgAEAAKgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAACoAAAAACAAmQAAAAAw AAAAAAAAAIAAAACAAQAArAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAA ADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkA AAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAA mQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AAAAAAAAMwAAADQAAAA1AAAAUwAAAFQAAABbAAAAXQAAAAsCAAAMAgAAHAIAACcCAAAoAgAA TAIAAE0CAACkAwAApQMAAHwEAAB9BAAALQUAAC4FAADRBQAA0gUAAIAGAACBBgAA1AYAANUG AADWBgAAUwcAAMwHAADNBwAA7AcAAO0HAADyBwAA/gcAAP8HAAAFCAAAHAgAAB0IAAAnCAAA YQgAAGIIAABjCAAAgAgAAIEIAACfCAAAoAgAAKUIAACmCAAApwgAAK0IAACuCAAArwgAALkI AAC6CAAAuwgAAMcIAADICAAAyQgAAMoIAADLCAAAzAgAAM0IAAD8CAAA/QgAABUJAAAnCQAA KAkAAG0JAAB2CQAAdwkAAKEJAACqCQAAqwkAANsJAADjCQAA5AkAAPwJAAD9CQAA/gkAABcK AAAjCgAAJAoAACcKAACYAAEgDzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAHmEAAAAAwAAAAAAAA AICiswEAAAAAAAAAAACAAZhAAAAAMAAAAAAAAACAorMBAAAAAAAAAAAAgAGpQAAAADAAAAAA AAAAgKKzAQABAAAAAAAAAKABmUAAAAAwAAAAAAAAAICiswEAAQAA5AAAAAAgAalAAAAAMAAA AAAAAACAorMBAAEAAAAAAAAAgAGpQAAAADAAAAAAAAAAgKKzAQABAAAAAAAAAIABmkAAAA8w AAAAAAAAAIAAAACAAQAAAAAAAAAAB6lAAAAAMAAAAAAAAACAorMBAAEAAAAAAAAAoAGpQAAA ADAAAAAAAAAAgKKzAQABAAAAAAAAAIABq0AAAAAwAAAAAAAAAICiswEAAQAAAAAAAACgB5lA AAAAMAAAAAAAAACAorMBAAEAAOQAAAAAIAGpQAAAADAAAAAAAAAAgKKzAQABAAAAAAAAAIAB qUAAAAAwAAAAAAAAAICiswEAAQAAAAAAAACAAeqQADAOMAAAAAAAAAEAAABGAAEAAAAAAAAA gAfokAAwDjAAAAAAAAABAAAARgABAAAAAAAAAIAB6JAAMA4wAAAAAAAAAQAAAEYAAQAAAAAA AACAB5hAAAAPMAAAAAAAAACAAAAAgAEAAAAAAAAAgAeYQAAADzAAAAAAAAAAgAAAAIABAAAA AAAAAAAHmEAAAA8wAAAAAAAAAIAAAACAAQAAAAAAAAAAAZhAAAAPMAAAAAAAAACAAAAAgAEA AAAAAAAAAAGYQAAADzAAAAAAAAAAgAAAAIABAAAAAAAAAAABqUAAAAAwAAAAAAAAAICiswEA AQAAAAAAAACAAatAAAAAMAAAAAAAAACAorMBAAEAAAAAAAAAgAerQAAAADAAAAAAAAAAgKKz AQABAAAAAAAAAIAHq0AAAAAwAAAAAAAAAICiswEAAQAAAAAAAACgB5lAAAAAMAAAAAAAAACA orMBAAEAAOQAAAAAIAGpQAAAADAAAAAAAAAAgKKzAQABAAAAAAAAAIABqUAAAAAwAAAAAAAA AICiswEAAQAAAAAAAACgB5lAAAAAMAAAAAAAAACAorMBAAEAAOQAAAAAIAGpQAAAADAAAAAA AAAAgKKzAQABAAAAAAAAAKABmUAAAAAwAAAAAAAAAICiswEAAQAA5AAAAAAgAalAAAAAMAAA AAAAAACAorMBAAEAAAAAAAAAoAGpQAAAADAAAAAAAAAAgKKzAQABAAAAAAAAAKABmUAAAAAw AAAAAAAAAICiswEAAQAA5AAAAAAgAalAAAAAMAAAAAAAAACAorMBAAEAAAAAAAAAoAGpQAAA ADAAAAAAAAAAgKKzAQABAAAAAAAAAKAHmUAAAAAwAAAAAAAAAICiswEAAQAA5AAAAAAgAalA AAAAMAAAAAAAAACAorMBAAEAAAAAAAAAoAGpQAAAADAAAAAAAAAAgKKzAQABAAAAAAAAAKAH mUAAAAAwAAAAAAAAAICiswEAAQAA5AAAAAAgAZhAAAAAMAAAAAAAAACAorMBAAAAAAAAAAAA gAGpQAAAADAAAAAAAAAAgKKzAQABAAAAAAAAAKABmUAAAAAwAAAAAAAAAICiswEAAQAA5AAA AAAgAalAAAAAMAAAAAAAAACAorMBAAEAAAAAAAAAoAGZQAAAADAAAAAAAAAAgKKzAQABAADk AAAAACABqUAAAAAwAAAAAAAAAICiswEAAQAAAAAAAACgAalAAAAAMAAAAAAAAACAorMBAAEA AAAAAAAAoAGZQAAAADAAAAAAAAAAgKKzAQABAADkAAAAACABqUAAAAAwAAAAAAAAAICiswEA AQAAAAAAAACgAalAAAAAMAAAAAAAAACAorMBAAEAAAAAAAAAoAGZQAAAADAAAAAAAAAAgKKz AQABAADkAAAAACABqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACA AAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAA AIAAAACAAQAA0AAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAAACpAAAAADAAAAAA AAAAgAAAAIABAADQAAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAAAKkAAAAAMAAA AAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAACAAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAA ADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkA AAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIAGZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAA qQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKsAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAA IAeZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAA AAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIAGZAAAAADAAAAAAAAAAgAAAAIABAADU AAAAACAAqwAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgB6sAAAAAMAAAAAAAAACAAAAAgAEA ANAAAAAAIAeZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA AQAA0AAAAAAgAKsAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIAeZAAAAADAAAAAAAAAAgAAA AIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKsAAAAAMAAAAAAAAACA AAAAgAEAANAAAAAAIAeZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAmgAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAABwAGAAAmCgAAbg8AALkRAAAlEgAACgAAAA4AAAAQAAAAHwAAAAAG AAALCgAALg0AAMwPAADtDwAAHBAAAGEQAACAEAAAnxAAAKYQAACuEAAAuhAAAMsQAAD8EAAA JxEAAHYRAACqEQAA4xEAAP0RAAAjEgAAJRIAAAsAAAANAAAADwAAABEAAAASAAAAEwAAABQA AAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAIAAAACEAAAAiAAAA AAYAACUSAAAMAAAA0gUAAC4GAAB+BgAAJQoAABNYlP+VhP//AwAAAAoARQB4AGgAaQBiAGkA dABfAEkAVgAJAE8ATABFAF8ATABJAE4ASwAxAAkATwBMAEUAXwBMAEkATgBLADIAAAAAADIF AAAyBQAAJwoAAAAAAAABAAAAAgAAADIAAABBBQAAQQUAACcKAAAAAAAAxgkAAM0JAAAnCgAA BwAEAAcAAAAAAFMEAABlBAAAgQYAAIMGAACrCQAA2gkAACcKAAAHADMABwAzAAcABAAHAAAA AAAeAgAAHgIAACECAAAhAgAA+gIAAPoCAAB1CQAAdQkAAKkJAACpCQAAtAkAALQJAAC5CQAA 2QkAAOEJAADiCQAA/AkAAPwJAAAcCgAAHAoAACQKAAAkCgAAJwoAAAMABAADAAQAAwAEAAMA BAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQABwAAAAAAJwoAAAcAAgAPM1ZuIsHks/8P /w//D/8P/w//D/8P/w//DwAAYQ7mc7ZuWgf/D/8P/w//D/8P/w//D/8P/w8AAAEAAAABAAkA AAAAAAAAAAEAAAAAAAAAAA0QAAAPhAAAEYQAAF6EAABghAAAbygAh2gAAAAAiEgAAAoARQB4 AGgAaQBiAGkAdAAgAAAALgABAAAAFgQJCwAAAAAAAAAAAAAAAAAAAAANGAEAD4QAABGEAAAV xgUAATgEBl6EAABghAAAbygAh2gAAAAAiEgAAAsAUwBlAGMAdABpAG8AbgAgAAAALgABAAEA AAAEAAIAAAAAAAAAAAAAAAAAAAAAAA0YAgAPhNACEYRQ/hXGBQAB0AIGXoTQAmCEUP5vKACH aAAAAACISAAAAwAoAAIAKQABAAAAAgICAAAAAAAAAAAAAAAAAAAAAAANGAMAD4RgAxGEcP8V xgUAAWADBl6EYANghHD/bygAh2gAAAAAiEgAAAMAKAADACkAAQAAAAAAAQAAAAAAAAAAAAAA AAAAAAAADRgEAA+E8AMRhFD+FcYFAAHwAwZehPADYIRQ/m8oAIdoAAAAAIhIAAACAAQAKQAB AAAABAABAAAAAAAAAAAAAAAAAAAAAAANGAUAD4SABBGEUP4VxgUAAYAEBl6EgARghFD+bygA h2gAAAAAiEgAAAIABQApAAEAAAACAgEAAAAAAAAAAAAAAAAAAAAAAA0YBgAPhBAFEYTg/hXG BQABEAUGXoQQBWCE4P5vKACHaAAAAACISAAAAgAGACkAAQAAAAQAAQAAAAAAAAAAAAAAAAAA AAAADRgHAA+EoAURhFD+FcYFAAGgBQZehKAFYIRQ/m8oAIdoAAAAAIhIAAACAAcALgABAAAA AgIBAAAAAAAAAAAAAAAAAAAAAAANGAgAD4QwBhGEcP8VxgUAATAGBl6EMAZghHD/bygAh2gA AAAAiEgAAAIACAAuAAQAAAABAAkAAAAAAAAAAAEAAAAAAAAAAA0QAAAPhAAAEYQAAF6EAABg hAAAbygAh2gAAAAAiEgAAAoARQB4AGgAaQBiAGkAdAAgAAAALgABAAAAFgQJCwAAAAAAAAAA AAAAAAAAAAANGAEAD4QAABGEAAAVxgUAATgEBl6EAABghAAAbygAh2gAAAAAiEgAAAsAUwBl AGMAdABpAG8AbgAgAAAALgABAAEAAAAEAAIAAAAAAAAAAAAAAAAAAAAAAA0YAgAPhNACEYRQ /hXGBQAB0AIGXoTQAmCEUP5vKACHaAAAAACISAAAAwAoAAIAKQABAAAAAgICAAAAAAAAAAAA AAAAAAAAAAANGAMAD4RgAxGEcP8VxgUAAWADBl6EYANghHD/bygAh2gAAAAAiEgAAAMAKAAD ACkAAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAADRgEAA+E8AMRhFD+FcYFAAHwAwZehPADYIRQ /m8oAIdoAAAAAIhIAAACAAQAKQABAAAABAABAAAAAAAAAAAAAAAAAAAAAAANGAUAD4SABBGE UP4VxgUAAYAEBl6EgARghFD+bygAh2gAAAAAiEgAAAIABQApAAEAAAACAgEAAAAAAAAAAAAA AAAAAAAAAA0YBgAPhBAFEYTg/hXGBQABEAUGXoQQBWCE4P5vKACHaAAAAACISAAAAgAGACkA AQAAAAQAAQAAAAAAAAAAAAAAAAAAAAAADRgHAA+EoAURhFD+FcYFAAGgBQZehKAFYIRQ/m8o AIdoAAAAAIhIAAACAAcALgABAAAAAgIBAAAAAAAAAAAAAAAAAAAAAAANGAgAD4QwBhGEcP8V xgUAATAGBl6EMAZghHD/bygAh2gAAAAAiEgAAAIACAAuAAIAAABhDuZzAAAAAAAAAAAAAAAA DzNWbgAAAAAAAAAAAAAAAP////////////8CAAAAAAAAAP//AgAAAAAAAAARAAAABAAAAAgA AADlAAAAAAAAABAAAAD4IBQAc20aANROHwBuPUMAekJQAC8EWwDZLlsATiJdAKQghAD9LIYA mUSRANRDqQDgEL4A6hfNAP8v2wBPTtsAgxX2AAAAAAAzAAAANQAAAFMAAABUAAAADAIAACcC AAAoAgAA1QYAANYGAADMBwAAzQcAAOwHAADtBwAA8gcAAP4HAAD/BwAABQgAABwIAAAdCAAA JwgAAGEIAABiCAAAYwgAAIAIAACBCAAAnwgAAKAIAAClCAAApggAAKcIAACtCAAArggAAK8I AAC5CAAAuggAALsIAADLCAAAzAgAAM0IAAD8CAAA/QgAABUJAAAnCQAAKAkAAG0JAAB2CQAA dwkAAKEJAACqCQAAqwkAANsJAADjCQAA5AkAAPwJAAD9CQAA/gkAABcKAAAjCgAAJAoAACcK AAAAAAAAAAAAAAgAAAACAQAAngEAAAIBAAACAQAAngEAAAIBAACeAQAAAgEAAJ4BAAACAQAA ngEAAAIBAAACAQAAngEAAAIBAAACAQAAngEAAAIBAAACAQAAlgEAAAgAAAACAQAAngEAAAIB AACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAAAgEAAJYBAAAIAAAA AgEAAJ4BAAACAQAAAgEAAJ4BAAACAQAAAgEAAJ4BAAACAQAAAgEAAJ4BAAACAQAAAgEAAJ4B AAACAQAAAgEAAJ4BAAACAQAAAgEAAJYBAAD/QA2AAQDHCQAAxwkAAFjRKQwBAAEAxwkAAAAA AADHCQAAAAAAAAIQAAAAAAAAACUKAABwAAAQAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD/ /wEACAAAAAAAAAAAAAAA//8BAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAHAAAARxaQ AQAAAgIGAwUEBQIDBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3 ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAA AFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBId6ACAAAACACAAAAAAAAAD/AQAAAAAA AEEAcgBpAGEAbAAAAGkQkAEAEQAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABC AG8AbwBrAEEAbgB0AGkAcQB1AGEALQBCAG8AbABkAAAAVABpAG0AZQBzACAATgBlAHcAIABS AG8AbQBhAG4AAAA/NZABAAACBwMJAgIFAgQEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQwBv AHUAcgBpAGUAcgAgAE4AZQB3AAAARzWQAYAKAgIGCQQCBQgDBL8CAKD7/MdoEAAAAAAAAACf AAIAAAAAAE0AUwAgAE0AaQBuAGMAaABvAAAALf8z/yAADmYdZwAANSaQAQAAAgsGBAMFBAQC BId6AGEAAACACAAAAAAAAAD/AQEAAAAAAFQAYQBoAG8AbQBhAAAAIgAEAPGIiBgA8NAC5ARo AQAAAACMo7yGjaO8hjKEu6YDAAMAAACDAQAAoggAAAEABQAAAAQAAxASAAAAgwEAAKIIAAAB AAUAAAASAAAAAAAAACEDAPAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAgHoAW0ALQAgYEyNAAAEAAZAGQAAAAZAAAAIAoAACAKAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAA AAAACDKDcQDwEAAIAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIWAAAAAAp8P8PAQAB PwAA5AQAAP///3////9/////f////3////9/////f////396QlAAAAAAADIAAAAAAAAAAAAA AAAAAQAAAP//EgAAAAAAAAAKAEUAeABoAGkAYgBpAHQAIABJAFYAAAAAAAAAEwBUAG8AbQAg AEIAcgBlAGUAbgAtAEIAZQBsAGwAUwBvAHUAdABoAAcAUgBIAGkAeABzAG8AbgAAAAAAAAAA AAAAAAAAAAAAAAAAABQAAAAGAAAAAgAAAAAADAABAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZ MAAAAJQBAAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAAC0AAAABAAAAMAAAAAFAAAA3AAAAAYA AADoAAAABwAAAPQAAAAIAAAACAEAAAkAAAAYAQAAEgAAACQBAAAKAAAARAEAAAsAAABQAQAA DAAAAFwBAAANAAAAaAEAAA4AAAB0AQAADwAAAHwBAAAQAAAAhAEAABMAAACMAQAAAgAAAOQE AAAeAAAADAAAAEV4aGliaXQgSVYAAB4AAAAEAAAAAAAAAB4AAAAUAAAAVG9tIEJyZWVuLUJl bGxTb3V0aAAeAAAABAAAAAAAAAAeAAAABAAAAAAAAAAeAAAADAAAAE5vcm1hbC5kb3QAAB4A AAAIAAAAUkhpeHNvbgAeAAAABAAAADMAAAAeAAAAGAAAAE1pY3Jvc29mdCBPZmZpY2UgV29y ZAAAAEAAAAAA0klrAAAAAEAAAAAAdLaimijIAUAAAAAAwDwyPEPIAUAAAAAABgBWPEPIAQMA AAABAAAAAwAAAIMBAAADAAAAoggAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3V nC4bEJOXCAArLPmuQAEAAPwAAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACEAAAABgAAAIwA AAARAAAAlAAAABcAAACcAAAACwAAAKQAAAAQAAAArAAAABMAAAC0AAAAFgAAALwAAAANAAAA xAAAAAwAAADbAAAAAgAAAOQEAAAeAAAADAAAAEJlbGxTb3V0aAAAAAMAAAASAAAAAwAAAAUA AAADAAAAIAoAAAMAAAAIGQsACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAA AQAAAAsAAABFeGhpYml0IElWAAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAAAAACAB AAADAAAAAAAAACAAAAABAAAAOAAAAAIAAABAAAAAAQAAAAIAAAAMAAAAX1BJRF9ITElOS1MA AgAAAOQEAABBAAAA2AAAAAYAAAADAAAAcgBiAAMAAAAAAAAAAwAAAAAAAAADAAAABQAAAB8A AABQAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAG4AZQBuAGEALgBvAHIAZwAvAG0AZQBkAGkA YQAvAGYAaQBsAGUAcwAvAEYAdQBuAGMAYQBuAGQASQB0AGYAUwB0AGQAZgBvAHIATgBHADkA LQAxAC0AMQBQAHUAYgBsAGkAYwBSAGUAdgBpAGUAdwAxADAALQAyADYALQAwADcALgBwAGQA ZgAAAB8AAAABAAAAAADcCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIA AAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA EAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0A AAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAD+////JQAAACYAAAAnAAAAKAAAACkAAAAqAAAA KwAAAP7///8tAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgA AAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAA /v///0cAAABIAAAASQAAAEoAAABLAAAATAAAAE0AAAD+////TwAAAFAAAABRAAAAUgAAAFMA AABUAAAAVQAAAP7////9////WAAAAP7////+/////v////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAA wAAAAAAAAEYAAAAAAAAAAAAAAACwaahYPEPIAVoAAACAAAAAAAAAAEQAYQB0AGEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAAAAQ AAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAsAAAAZzIAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQIAAAAFAAAA/////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuRgAAAAAAAAUAUwB1AG0A bQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAoAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA RgAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIA bQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABOAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP////////// /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABxAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7///////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////8BAP7/AwoAAP// //8GCQIAAAAAAMAAAAAAAABGHwAAAE1pY3Jvc29mdCBPZmZpY2UgV29yZCBEb2N1bWVudAAK AAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAFIAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAA AAAARgAAAAAAAAAAAAAAAIAq5fM8Q8gBWgAAAIAAAAAAAAAARABhAHQAYQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAAABAAAAAA AAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAADgACAQEAAAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACwAAABnMgAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBAgAAAAUAAAD/////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC5GAAAAAAAAAQAAAAIAAAADAAAA BAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEA AAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAA HwAAACAAAAAhAAAAIgAAACMAAAD+////JQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAAP7/ //8tAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAA OgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAA/v///0cA AABIAAAASQAAAEoAAABLAAAATAAAAE0AAAD+//////////////////////////////////// ///////////////////////////+/////v///2UAAAD9////XgAAAF8AAABgAAAAYQAAAGIA AABjAAAAZAAAAP7////+//////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////+/wAABQECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgA Kyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuQAEAAPwAAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUA AACEAAAABgAAAIwAAAARAAAAlAAAABcAAACcAAAACwAAAKQAAAAQAAAArAAAABMAAAC0AAAA FgAAALwAAAANAAAAxAAAAAwAAADbAAAAAgAAAOQEAAAeAAAADAAAAEJlbGxTb3V0aAAAAAMA AAASAAAAAwAAAAUAAAADAAAAIAoAAAMAAAAIGQsACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAA CwAAAAAAAAAeEAAAAQAAAAsAAABFeGhpYml0IElWAAwQAAACAAAAHgAAAAYAAABUaXRsZQAD AAAAAQAAAAAAACABAAADAAAAAAAAACAAAAABAAAAOAAAAAIAAABAAAAAAQAAAAIAAAAMAAAA X1BJRF9ITElOS1MAAgAAAOQEAABBAAAA2AAAAAYAAAADAAAAcgBiAAMAAAAAAAAAAwAAAAAA AAADAAAABQAAAB8AAABQAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAG4AZQBuAGEALgBvAHIA ZwAvAG0AZQBkAGkAYQAvAGYAaQBsAGUAcwAvAEYAdQBuAGMAYQBuAGQASQB0AGYAUwB0AGQA ZgBvAHIATgBHADkALQAxAC0AMQBQAHUAYgBsAGkAYwBSAGUAdgBpAGUAdwAxADAALQAyADYA LQAwADcALgBwAGQAZgAAAB8AAAABAAAAAADcCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAACgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABGAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEA cgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAQQAAAD//////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF0AAAAAEAAAAAAAAAEAQwBvAG0A cABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAASAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAHEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --------------030302040306000104060309 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --------------030302040306000104060309-- From ecrit-bounces@ietf.org Tue Apr 8 11:54:20 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22B73A681E; Tue, 8 Apr 2008 11:54:20 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ECF03A681E for ; Tue, 8 Apr 2008 11:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkHp+8N4FZ5C for ; Tue, 8 Apr 2008 11:54:18 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 5060A3A6774 for ; Tue, 8 Apr 2008 11:54:18 -0700 (PDT) Received: from dhcp33-081-019.bbn.com ([128.33.81.19] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JjIxl-0005ZT-3s; Tue, 08 Apr 2008 14:54:33 -0400 Message-ID: <47FBBF69.7000504@bbn.com> Date: Tue, 08 Apr 2008 14:54:33 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hannes Tschofenig References: <47FBBA34.1050704@gmx.net> In-Reply-To: <47FBBA34.1050704@gmx.net> Cc: Roger Hixson , ecrit@ietf.org Subject: Re: [Ecrit] NENA NG9-1-1 related Standard for review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I will review the document. --RB Hannes Tschofenig wrote: > Folks, > > Roger Hixson is asking for feedback on a NENA document (see attachment). > Who would be willing to review the NENA document? Please drop us a note. > > Ciao > Hannes > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 15 06:27:55 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E17B03A6B9B; Tue, 15 Apr 2008 06:27:55 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29303A6830 for ; Tue, 15 Apr 2008 06:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=0.509, 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 52WlVLGgbU9v for ; Tue, 15 Apr 2008 06:27:54 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 0C9583A6768 for ; Tue, 15 Apr 2008 06:27:53 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m3FDSOOu002292 for ; Tue, 15 Apr 2008 08:28:25 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 08:28:20 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 15:28:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Apr 2008 15:28:19 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Usage of service URN by enterprises (RFC 5031) Thread-Index: Acie/JGI2XLYoKXJRk6iGKVjWmL23w== From: "DRAGE, Keith \(Keith\)" To: "ECRIT" X-OriginalArrivalTime: 15 Apr 2008 13:28:18.0340 (UTC) FILETIME=[9119E640:01C89EFC] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [Ecrit] Usage of service URN by enterprises (RFC 5031) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org RFC 5031 defines service URN as: urn:service:sos The generic 'sos' service reaches a public safety answering point (PSAP), which in turn dispatches aid appropriate to the emergency. It encompasses all of the services listed below. The definition of PSAP from RFC 5012 is as follows: Public Safety Answering Point (PSAP): A PSAP is a facility where emergency calls are received under the responsibility of a public authority. (This terminology is used by both the European Telecommunications Standards Institute (ETSI), in ETSI SR 002 180, and the National Emergency Number Association (NENA).) In the United Kingdom, PSAPs are called Operator Assistance Centres; in New Zealand, Communications Centres. Within this document, it is assumed, unless stated otherwise, that PSAPs support the receipt of emergency calls over IP, using appropriate application layer protocols, such as SIP for call signaling and RTP for media. If I have an enterprise, that provides its own emergency services, with its own emergency service routeing proxy and its own answer points, is it appropriate or inappropriate to use urn:service:sos. If it is inappropriate, is there a service urn that should be used? Otherwise it would seem that we are back to using numbers. While many enterprises will use the public network capability to respond to an emergency, there are cases where it is inappropriate, or indeed impossible for the the public network capability to provide an appropriate response for an enterprise. Regards Keith _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 15 07:26:09 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15E1328C3ED; Tue, 15 Apr 2008 07:26:09 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B4B128C166 for ; Tue, 15 Apr 2008 07:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=0.687, 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 gGQYGz0HPGt3 for ; Tue, 15 Apr 2008 07:26:06 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id C035D28C408 for ; Tue, 15 Apr 2008 07:26:00 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jlm7B-0001IX-0R; Tue, 15 Apr 2008 09:26:29 -0500 From: "Brian Rosen" To: "'DRAGE, Keith \(Keith\)'" , "'ECRIT'" References: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> Date: Tue, 15 Apr 2008 10:26:27 -0400 Message-ID: <012a01c89f04$b2f25290$6901a8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acie/JGI2XLYoKXJRk6iGKVjWmL23wABTFzg In-Reply-To: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org We may have inadvertently created a problem. The intention is to allow the enterprise to operate the PSAP, and urn:service:sos to be used to return the URI of that enterprise PSAP. This clearly occurs in specific instances. Does 5031 reference the definition in 5012? If so, we may need an erratum. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: Tuesday, April 15, 2008 9:28 AM To: ECRIT Subject: [Ecrit] Usage of service URN by enterprises (RFC 5031) RFC 5031 defines service URN as: urn:service:sos The generic 'sos' service reaches a public safety answering point (PSAP), which in turn dispatches aid appropriate to the emergency. It encompasses all of the services listed below. The definition of PSAP from RFC 5012 is as follows: Public Safety Answering Point (PSAP): A PSAP is a facility where emergency calls are received under the responsibility of a public authority. (This terminology is used by both the European Telecommunications Standards Institute (ETSI), in ETSI SR 002 180, and the National Emergency Number Association (NENA).) In the United Kingdom, PSAPs are called Operator Assistance Centres; in New Zealand, Communications Centres. Within this document, it is assumed, unless stated otherwise, that PSAPs support the receipt of emergency calls over IP, using appropriate application layer protocols, such as SIP for call signaling and RTP for media. If I have an enterprise, that provides its own emergency services, with its own emergency service routeing proxy and its own answer points, is it appropriate or inappropriate to use urn:service:sos. If it is inappropriate, is there a service urn that should be used? Otherwise it would seem that we are back to using numbers. While many enterprises will use the public network capability to respond to an emergency, there are cases where it is inappropriate, or indeed impossible for the the public network capability to provide an appropriate response for an enterprise. Regards Keith _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 15 08:01:59 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E772128C41C; Tue, 15 Apr 2008 08:01:59 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C67A3A6EFB for ; Tue, 15 Apr 2008 08:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AjGSQhrD5AD for ; Tue, 15 Apr 2008 08:01:58 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id C6BD73A6A1D for ; Tue, 15 Apr 2008 08:01:01 -0700 (PDT) Received: from col-dhcp33-244-168.bbn.com ([128.33.244.168] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Jlmf8-0005Wo-3b; Tue, 15 Apr 2008 11:01:34 -0400 Message-ID: <4804C34C.2060508@bbn.com> Date: Tue, 15 Apr 2008 11:01:32 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Brian Rosen References: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> <012a01c89f04$b2f25290$6901a8c0@cis.neustar.com> In-Reply-To: <012a01c89f04$b2f25290$6901a8c0@cis.neustar.com> Cc: 'ECRIT' Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Actually, I think this use case might introduce more problems than the one Keith pointed out. For instance, consider the case where 1) The endpoint/caller is connected to an access net with its own PSAP 2) The endpoint/caller does his own LoST routing. ISTM that for the caller to end up with the enterprise PSAP's URI within the current framework, one of a three things has to happen: 1) Forced private LoST: The caller uses a LoST resolver operated by the access network, so that the resolver can direct the caller to the enterprise PSAP. While the LoST discovery mechanism enable this to happen, there is not a requirement in framework/phonebcp for the caller to prefer the local LoST resolver (at least I haven't found one). 2) Private LoST in the public tree: If the caller is allowed to use the public LoST infrastructure, then these private arrangements must be accounted for in that infrastructure. 2a) To do this without changing LoST routing, you would have to map specific geographic areas to enterprise PSAPs, so that a standard LoST query would route to the enterprise LoST server. 2b) If we're willing to change the LoST routing, then caller could include a tag in the request (in the URN or otherwise) that indicates the network to which the requestor is connected, so that queries could be routed based on the tag. Or the LoST server could route based on the IP address of the caller. The problem is even harder when a proxy does LoST routing on behalf of an endpoint. Solutions engineering aside, do people think this is actually a problem? --Richard P.S.: Among these options, my preference is actually for option 2b. Option 1 encourages different resolvers to present different views of the LoST infrastructure. Option 2a is probably incompatible with devices that have imprecise location (given that the "enterprise regions" will usually be small). Option 2b cleanly, explicitly incorporates additional routing parameters (i.e., not location or service) into LoST. Brian Rosen wrote: > We may have inadvertently created a problem. > > The intention is to allow the enterprise to operate the PSAP, and > urn:service:sos to be used to return the URI of that enterprise PSAP. > > This clearly occurs in specific instances. > > Does 5031 reference the definition in 5012? If so, we may need an erratum. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > DRAGE, Keith (Keith) > Sent: Tuesday, April 15, 2008 9:28 AM > To: ECRIT > Subject: [Ecrit] Usage of service URN by enterprises (RFC 5031) > > RFC 5031 defines service URN as: > > urn:service:sos The generic 'sos' service reaches a public safety > answering point (PSAP), which in turn dispatches aid appropriate > to the emergency. It encompasses all of the services listed > below. > > The definition of PSAP from RFC 5012 is as follows: > > Public Safety Answering Point (PSAP): A PSAP is a facility where > emergency calls are received under the responsibility of a public > authority. (This terminology is used by both the European > Telecommunications Standards Institute (ETSI), in ETSI SR 002 180, > and the National Emergency Number Association (NENA).) In the > United Kingdom, PSAPs are called Operator Assistance Centres; in > New Zealand, Communications Centres. Within this document, it is > assumed, unless stated otherwise, that PSAPs support the receipt > of emergency calls over IP, using appropriate application layer > protocols, such as SIP for call signaling and RTP for media. > > If I have an enterprise, that provides its own emergency services, with > its own emergency service routeing proxy and its own answer points, is > it appropriate or inappropriate to use urn:service:sos. If it is > inappropriate, is there a service urn that should be used? Otherwise it > would seem that we are back to using numbers. > > While many enterprises will use the public network capability to respond > to an emergency, there are cases where it is inappropriate, or indeed > impossible for the the public network capability to provide an > appropriate response for an enterprise. > > Regards > > Keith > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 15 08:29:06 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F09253A6DD2; Tue, 15 Apr 2008 08:29:05 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4840F3A6DD2 for ; Tue, 15 Apr 2008 08:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_54=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 Q46N6HGuHFDo for ; Tue, 15 Apr 2008 08:29:04 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 0722B3A696B for ; Tue, 15 Apr 2008 08:29:03 -0700 (PDT) Received: from col-dhcp33-244-168.bbn.com ([128.33.244.168] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Jln6H-00068I-3o; Tue, 15 Apr 2008 11:29:37 -0400 Message-ID: <4804C9DE.40204@bbn.com> Date: Tue, 15 Apr 2008 11:29:34 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Karl Heinz Wolf References: <47B9A89C.2020704@bbn.com> In-Reply-To: Cc: ECRIT Subject: Re: [Ecrit] [Fwd: New Version Notification for draft-barnes-ecrit-rough-loc-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Karl Heinz, Thanks for your comments, and I apologize for the delayed response. > I read your draft and I have a question on section 4.1.: If I > understand you correctly, a client using HELD would perform a HELD > request, and would get back location by value and by reference at > once. The value is imprecise, the reference can be dereferenced to > precise location by the PSAP. Yes, that is what we intended it to mean. > What if the HELD request is with locationtype civic and exact=true ? > The LIS is not allowed to hand out a URI any more, and the client > cannot know that the value it gets is imprecise. Or would you suggest > that this type of query fails, and the client would have to request a > locationURI in a separate request, dereference the URI in the next > step to get imprecise location? That's a good point, and I think the request failing is the correct behavior. If a client cannot support location-by-reference (i.e., if it can only support civic or geo), then it is incompatible with this solution. If the client CAN use an LbyR, then it should re-query. --Richard > > > cheers > karl heinz > > > On Mon, Feb 18, 2008 at 4:47 PM, Richard Barnes wrote: >> We have posted a draft that explains how imprecise location can be used >> for emergency context resolution within the ECRIT framework. >> Specifically, we describe how a location provider can determine when a >> position is sufficiently precise for emergency call routing, and how >> emergency and non-emergency services are delivered in this context. >> >> While this document may enable a solution to the location-hiding >> problem, it can also be useful when a location provider is using >> positioning mechanisms that are capable of returning location at various >> granularities, with finer-grained location taking more time or resources >> to compute. >> >> --Richard >> >> >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-barnes-ecrit-rough-loc-00 >> Date: Mon, 18 Feb 2008 07:35:55 -0800 (PST) >> From: IETF I-D Submission Tool >> To: rbarnes@bbn.com >> CC: mlepinski@bbn.com >> >> >> A new version of I-D, draft-barnes-ecrit-rough-loc-00.txt has been >> successfuly submitted by Richard Barnes and posted to the IETF repository. >> >> Filename: draft-barnes-ecrit-rough-loc >> Revision: 00 >> Title: Using Imprecise Location for Emergency Context Resolution >> Creation_date: 2008-02-18 >> WG ID: Independent Submission >> Number_of_pages: 12 >> >> Abstract: >> Emergency calling works best when precise location is available for >> emergency call routing. However, there are situations in which a >> location provider is unable or unwilling to provide precise location, >> yet still wishes to enable subscribers to make emergency calls. This >> document describes the level of location accuracy that providers must >> provide to enable emergency call routing. In addition, we descibe >> how emergency services and non-emergency services can be invoked by >> an endpoint that does not have access to its precise location. >> >> >> >> >> The IETF Secretariat. >> >> >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> http://www.ietf.org/mailman/listinfo/ecrit >> > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 15 09:31:29 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CA863A6BF5; Tue, 15 Apr 2008 09:31:29 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB0E73A6BF5 for ; Tue, 15 Apr 2008 09:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.676, 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 pJrOEyPj+08e for ; Tue, 15 Apr 2008 09:31:22 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 5E4303A6C60 for ; Tue, 15 Apr 2008 09:31:22 -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=1208277116; x=1239813116; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-originalarrivaltime: x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<5D1A7985295922448D5550C9 4DE2918001E21FBC@DEEXC1U01.de.lucent.com>|References:=20< 5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.luc ent.com>|Date:=20Tue,=2015=20Apr=202008=2009:31:49=20-070 0|To:=20"DRAGE,=20Keith=20(Keith)"=20,=20ECRIT=20|From:=20Ted=20Hardie =20|Subject:=20Re:=20[Ecrit]=20Usage =20of=20service=20URN=20by=20enterprises=20(RFC=205031) |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-OriginalArrivalTime:=2015=20Apr=202008=2016:31:52.0187 =20(UTC)=20FILETIME=3D[35DD94B0:01C89F16]|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5100,188,5274"=3B=20a=3D"2447652"; bh=mzVqKFl4BkDGWV/wlofkwl8cTpkJdpvz/eM9+Frv4jM=; b=grDefh43ZCCuSQa+sIWhb1o8KdxYoGIT0y0IhYt6rcMrAgVSqwDf1vU3 U5QxoqnKJTNduo/CFNLflAv+jdfWCKEjyoS2+95dxGI+q1CGn1xbFu851 4zN186hpWEKEn62NUDtev4zB3z0B2mYSdz6NJfzqBep8R5+0xzn2aEMx6 s=; X-IronPort-AV: E=McAfee;i="5100,188,5274"; a="2447652" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Apr 2008 09:31:55 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m3FGVtf3013050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Apr 2008 09:31:55 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m3FGVqv4016837; Tue, 15 Apr 2008 09:31:54 -0700 (PDT) Received: from nasanexhc03.na.qualcomm.com ([172.30.33.34]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Apr 2008 09:31:52 -0700 Received: from [129.46.226.27] (129.46.226.27) by qcmail1.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.263.0; Tue, 15 Apr 2008 09:31:51 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> References: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> Date: Tue, 15 Apr 2008 09:31:49 -0700 To: "DRAGE, Keith (Keith)" , ECRIT From: Ted Hardie X-OriginalArrivalTime: 15 Apr 2008 16:31:52.0187 (UTC) FILETIME=[35DD94B0:01C89F16] Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 6:28 AM -0700 4/15/08, DRAGE, Keith (Keith) wrote: > >If I have an enterprise, that provides its own emergency services, with >its own emergency service routeing proxy and its own answer points, is >it appropriate or inappropriate to use urn:service:sos. If it is >inappropriate, is there a service urn that should be used? Otherwise it >would seem that we are back to using numbers. Hi Keith, Are these enterprise PSAPs recognized by/coordinated with the local government so that the services they provide are the same as those in the local jurisdiction? If so, then I think them re-using the urn:service:sos is fine. But if not, then I think a different urn is required. There is already a difference between dialing 911 and 9-911 in many enterprises (do I want the local security, or does someone need an ambulance?), and continuing to distinguish between the two seems required. > >While many enterprises will use the public network capability to respond >to an emergency, there are cases where it is inappropriate, or indeed >impossible for the the public network capability to provide an >appropriate response for an enterprise. The examples I can come up with where it is impossible are all basically military reservation examples. Those folks tend to find lots of places where they coordinate with local authorities, so coordinating this does not seem to be a huge additional burden. What private enterprise cases are there where it is impossible? regards, Ted >Regards > >Keith >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 15 09:47:29 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77573A6F14; Tue, 15 Apr 2008 09:47:28 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20D5D28C36B for ; Tue, 15 Apr 2008 09:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.649, 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 944tzMGadY9X for ; Tue, 15 Apr 2008 09:47:18 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 4529528C452 for ; Tue, 15 Apr 2008 09:45:31 -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=1208277965; x=1239813965; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-originalarrivaltime: x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<4804C34C.2060508@bbn.com >|References:=20<5D1A7985295922448D5550C94DE2918001E21FBC @DEEXC1U01.de.lucent.com>=0D=0A=20<012a01c89f04$b2f25290$ 6901a8c0@cis.neustar.com>=0D=0A=20<4804C34C.2060508@bbn.c om>|Date:=20Tue,=2015=20Apr=202008=2009:46:00=20-0700|To: =20Richard=20Barnes=20,=20Brian=20Rosen =20|From:=20Ted=20Hardie=20|Subject:=20Re:=20[Ecrit]=20Usage=20of=20servic e=20URN=20by=20enterprises=20(RFC=205031)|CC:=20"'ECRIT'" =20|Content-Type:=20text/plain=3B=20chars et=3D"us-ascii"|X-OriginalArrivalTime:=2015=20Apr=202008 =2016:46:03.0255=20(UTC)=20FILETIME=3D[31244070:01C89F18] |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,5274"=3B=20a =3D"2448132"; bh=Tm2sjrRmFPpGgigC2ZlPY3EbZwoZXtbQD6g8gpDeT3g=; b=XUk4WyN/oBskvOAlA2XTHZSxVgZCItL/JQJURGCXnUAuQMtNLhONUoL3 SDhzH+xxX5v8wl533IfFDkJx/VCPIlUB/RDyEYuYyoB3DPyFVGglN7+9B XMcYqSzXXn077KHSnwDBDQo9N7VrJm0MpApATMMTYW/+ESslM4gdxkB4J 4=; X-IronPort-AV: E=McAfee;i="5100,188,5274"; a="2448132" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Apr 2008 09:46:04 -0700 Received: from msgtransport06.qualcomm.com (msgtransport06.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m3FGk452014956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Apr 2008 09:46:04 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by msgtransport06.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m3FGk3EX002908; Tue, 15 Apr 2008 09:46:03 -0700 Received: from nasanexhc03.na.qualcomm.com ([172.30.33.34]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Apr 2008 09:46:03 -0700 Received: from [129.46.226.27] (129.46.226.27) by qcmail1.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.263.0; Tue, 15 Apr 2008 09:46:02 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <4804C34C.2060508@bbn.com> References: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> <012a01c89f04$b2f25290$6901a8c0@cis.neustar.com> <4804C34C.2060508@bbn.com> Date: Tue, 15 Apr 2008 09:46:00 -0700 To: Richard Barnes , Brian Rosen From: Ted Hardie X-OriginalArrivalTime: 15 Apr 2008 16:46:03.0255 (UTC) FILETIME=[31244070:01C89F18] Cc: 'ECRIT' Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 8:01 AM -0700 4/15/08, Richard Barnes wrote: >Actually, I think this use case might introduce more problems than the >one Keith pointed out. For instance, consider the case where >1) The endpoint/caller is connected to an access net with its own PSAP >2) The endpoint/caller does his own LoST routing. > >ISTM that for the caller to end up with the enterprise PSAP's URI within >the current framework, one of a three things has to happen: First, are we sure that's the goal? It seems to me that the goal is to make sure that the appropriate emergency services actually reach the caller. If I connect to example.com's access network but use a VSP infrastructure instead of the enterprise PBX, I might end up calling the "covering" PSAP of the town, county, or other jurisdiction, rather than getting the enterprise PSAP. If the covering PSAP and the enterprise are going to contact the same emergency service responders, then the difference is really only extra load on the covering PSAP. In my opinion, that's an acceptable result and appropriate to the VSP/enterprise access vs. PBX/enterprise network topology difference. If there are different emergency service responders, but the covering PSAP dispatches emergency service responders that can and do reach the emergency, then we might have lost time and used resources but basically, the right thing still happens. There's a potentially important optimization here, in other words, but no need to re-think the architecture.(1) If the covering PSAP would dispatch resources that are *not permitted* to serve the area where the call came from (and here we've shifted into corner cases like the military base call going off--base), then it seems to me there has to be a mechanism to delineate those areas *and coordinate the coverage areas*. In other words, the covering PSAP would have to have a way to forward to the "local" PSAP so that it could dispatch the permitted resources. That requires some real coordination. As I said in my response to Keith, there may well need to be a different URN for "local" non-jurisidictional emergency response (the difference between 911 and 9-911 in many enterprises in the U.S. now). But we should not, in my opinion, ever prevent someone from reach the jurisdictional response because of the presence of a local response. In the military reservation case, that means the covering area has to have a carve-out for the military reservation, but that seems to me pretty much the expected behavior. Once the carve-out is present, the standard LoST mechanisms will get you the right PSAP (or, in the worst case, you get forwarded from the initial call taker). regards, Ted (1) And that potential optimization needs to focus, at least in my opinion, on letting the access network user/device know that it can use access network resource to determine the routing to PSAPs; once the access network resources are used, the local PSAP is in the mapping database and its URIs can be returned with no architectural change. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 15 10:53:15 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1123328C44B; Tue, 15 Apr 2008 10:53:15 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A6F28C453 for ; Tue, 15 Apr 2008 10:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.683, 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 9c8HadAyFZIi for ; Tue, 15 Apr 2008 10:53:12 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id A47C528C3F9 for ; Tue, 15 Apr 2008 10:53:12 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JlpLg-0005C4-Df; Tue, 15 Apr 2008 12:53:40 -0500 From: "Brian Rosen" To: "'Richard Barnes'" References: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> <012a01c89f04$b2f25290$6901a8c0@cis.neustar.com> <4804C34C.2060508@bbn.com> Date: Tue, 15 Apr 2008 13:53:41 -0400 Message-ID: <019c01c89f21$a5de8520$6901a8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcifCZj4WHFHCp2+RoSKD/fPVASynwABEo/w In-Reply-To: <4804C34C.2060508@bbn.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm not sure what "private LoST routing" means. I'm guessing that, say, a campus provides a LoST server with different answers from the public network. This is analogous today to calling on a wireline vs a wireless phone on campus. Where I could see an issue is LoST provided by the access network and LoST provided by the calling network. Generally, I think all LoST contents should be alike. I think it's preferable for the access network to provide the pointer to the LoST service. If there is some local routing issue, it's the access network that has the best information. Brian -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com] Sent: Tuesday, April 15, 2008 11:02 AM To: Brian Rosen Cc: 'DRAGE, Keith (Keith)'; 'ECRIT' Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) Actually, I think this use case might introduce more problems than the one Keith pointed out. For instance, consider the case where 1) The endpoint/caller is connected to an access net with its own PSAP 2) The endpoint/caller does his own LoST routing. ISTM that for the caller to end up with the enterprise PSAP's URI within the current framework, one of a three things has to happen: 1) Forced private LoST: The caller uses a LoST resolver operated by the access network, so that the resolver can direct the caller to the enterprise PSAP. While the LoST discovery mechanism enable this to happen, there is not a requirement in framework/phonebcp for the caller to prefer the local LoST resolver (at least I haven't found one). 2) Private LoST in the public tree: If the caller is allowed to use the public LoST infrastructure, then these private arrangements must be accounted for in that infrastructure. 2a) To do this without changing LoST routing, you would have to map specific geographic areas to enterprise PSAPs, so that a standard LoST query would route to the enterprise LoST server. 2b) If we're willing to change the LoST routing, then caller could include a tag in the request (in the URN or otherwise) that indicates the network to which the requestor is connected, so that queries could be routed based on the tag. Or the LoST server could route based on the IP address of the caller. The problem is even harder when a proxy does LoST routing on behalf of an endpoint. Solutions engineering aside, do people think this is actually a problem? --Richard P.S.: Among these options, my preference is actually for option 2b. Option 1 encourages different resolvers to present different views of the LoST infrastructure. Option 2a is probably incompatible with devices that have imprecise location (given that the "enterprise regions" will usually be small). Option 2b cleanly, explicitly incorporates additional routing parameters (i.e., not location or service) into LoST. Brian Rosen wrote: > We may have inadvertently created a problem. > > The intention is to allow the enterprise to operate the PSAP, and > urn:service:sos to be used to return the URI of that enterprise PSAP. > > This clearly occurs in specific instances. > > Does 5031 reference the definition in 5012? If so, we may need an erratum. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > DRAGE, Keith (Keith) > Sent: Tuesday, April 15, 2008 9:28 AM > To: ECRIT > Subject: [Ecrit] Usage of service URN by enterprises (RFC 5031) > > RFC 5031 defines service URN as: > > urn:service:sos The generic 'sos' service reaches a public safety > answering point (PSAP), which in turn dispatches aid appropriate > to the emergency. It encompasses all of the services listed > below. > > The definition of PSAP from RFC 5012 is as follows: > > Public Safety Answering Point (PSAP): A PSAP is a facility where > emergency calls are received under the responsibility of a public > authority. (This terminology is used by both the European > Telecommunications Standards Institute (ETSI), in ETSI SR 002 180, > and the National Emergency Number Association (NENA).) In the > United Kingdom, PSAPs are called Operator Assistance Centres; in > New Zealand, Communications Centres. Within this document, it is > assumed, unless stated otherwise, that PSAPs support the receipt > of emergency calls over IP, using appropriate application layer > protocols, such as SIP for call signaling and RTP for media. > > If I have an enterprise, that provides its own emergency services, with > its own emergency service routeing proxy and its own answer points, is > it appropriate or inappropriate to use urn:service:sos. If it is > inappropriate, is there a service urn that should be used? Otherwise it > would seem that we are back to using numbers. > > While many enterprises will use the public network capability to respond > to an emergency, there are cases where it is inappropriate, or indeed > impossible for the the public network capability to provide an > appropriate response for an enterprise. > > Regards > > Keith > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 15 11:33:43 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F683A69CD; Tue, 15 Apr 2008 11:33:43 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E7933A69CD for ; Tue, 15 Apr 2008 11:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWFAPfSsri9D for ; Tue, 15 Apr 2008 11:33:41 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 8191A3A6CF2 for ; Tue, 15 Apr 2008 11:33:34 -0700 (PDT) Received: from col-dhcp33-244-168.bbn.com ([128.33.244.168] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Jlpyp-0004ai-4K; Tue, 15 Apr 2008 14:34:07 -0400 Message-ID: <4804F51D.6000700@bbn.com> Date: Tue, 15 Apr 2008 14:34:05 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Brian Rosen References: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> <012a01c89f04$b2f25290$6901a8c0@cis.neustar.com> <4804C34C.2060508@bbn.com> <019c01c89f21$a5de8520$6901a8c0@cis.neustar.com> In-Reply-To: <019c01c89f21$a5de8520$6901a8c0@cis.neustar.com> Cc: 'ECRIT' Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > Generally, I think all LoST contents should be alike. > I think it's preferable for the access network to provide the pointer to the > LoST service. If there is some local routing issue, it's the access network > that has the best information. Is that a requirement that should be added into phonebcp/framework? E.g., " ED-* When an endpoint has obtained a LoST server via an discovery mechanism (e.g., via the DNS [ref] or DHCP [ref]), it SHOULD prefer the discovered LoST server over LoST servers configured by other means. That is, the endpoint SHOULD send queries to this LoST server, using other LoST servers only if these queries fail. " --RB > > Brian > > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Tuesday, April 15, 2008 11:02 AM > To: Brian Rosen > Cc: 'DRAGE, Keith (Keith)'; 'ECRIT' > Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) > > Actually, I think this use case might introduce more problems than the > one Keith pointed out. For instance, consider the case where > 1) The endpoint/caller is connected to an access net with its own PSAP > 2) The endpoint/caller does his own LoST routing. > > ISTM that for the caller to end up with the enterprise PSAP's URI within > the current framework, one of a three things has to happen: > > 1) Forced private LoST: The caller uses a LoST resolver operated by the > access network, so that the resolver can direct the caller to the > enterprise PSAP. While the LoST discovery mechanism enable this to > happen, there is not a requirement in framework/phonebcp for the caller > to prefer the local LoST resolver (at least I haven't found one). > > 2) Private LoST in the public tree: If the caller is allowed to use the > public LoST infrastructure, then these private arrangements must be > accounted for in that infrastructure. > 2a) To do this without changing LoST routing, you would have to map > specific geographic areas to enterprise PSAPs, so that a standard LoST > query would route to the enterprise LoST server. > 2b) If we're willing to change the LoST routing, then caller could > include a tag in the request (in the URN or otherwise) that indicates > the network to which the requestor is connected, so that queries could > be routed based on the tag. Or the LoST server could route based on the > IP address of the caller. > > The problem is even harder when a proxy does LoST routing on behalf of > an endpoint. Solutions engineering aside, do people think this is > actually a problem? > > --Richard > > P.S.: Among these options, my preference is actually for option 2b. > Option 1 encourages different resolvers to present different views of > the LoST infrastructure. Option 2a is probably incompatible with > devices that have imprecise location (given that the "enterprise > regions" will usually be small). Option 2b cleanly, explicitly > incorporates additional routing parameters (i.e., not location or > service) into LoST. > > > > > Brian Rosen wrote: >> We may have inadvertently created a problem. >> >> The intention is to allow the enterprise to operate the PSAP, and >> urn:service:sos to be used to return the URI of that enterprise PSAP. >> >> This clearly occurs in specific instances. >> >> Does 5031 reference the definition in 5012? If so, we may need an > erratum. >> Brian >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> DRAGE, Keith (Keith) >> Sent: Tuesday, April 15, 2008 9:28 AM >> To: ECRIT >> Subject: [Ecrit] Usage of service URN by enterprises (RFC 5031) >> >> RFC 5031 defines service URN as: >> >> urn:service:sos The generic 'sos' service reaches a public safety >> answering point (PSAP), which in turn dispatches aid appropriate >> to the emergency. It encompasses all of the services listed >> below. >> >> The definition of PSAP from RFC 5012 is as follows: >> >> Public Safety Answering Point (PSAP): A PSAP is a facility where >> emergency calls are received under the responsibility of a public >> authority. (This terminology is used by both the European >> Telecommunications Standards Institute (ETSI), in ETSI SR 002 180, >> and the National Emergency Number Association (NENA).) In the >> United Kingdom, PSAPs are called Operator Assistance Centres; in >> New Zealand, Communications Centres. Within this document, it is >> assumed, unless stated otherwise, that PSAPs support the receipt >> of emergency calls over IP, using appropriate application layer >> protocols, such as SIP for call signaling and RTP for media. >> >> If I have an enterprise, that provides its own emergency services, with >> its own emergency service routeing proxy and its own answer points, is >> it appropriate or inappropriate to use urn:service:sos. If it is >> inappropriate, is there a service urn that should be used? Otherwise it >> would seem that we are back to using numbers. >> >> While many enterprises will use the public network capability to respond >> to an emergency, there are cases where it is inappropriate, or indeed >> impossible for the the public network capability to provide an >> appropriate response for an enterprise. >> >> Regards >> >> Keith >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 15 11:43:29 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CAEE3A6A1D; Tue, 15 Apr 2008 11:43:29 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22C8D3A6A1D for ; Tue, 15 Apr 2008 11:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.716, 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 sgysO3TdujZv for ; Tue, 15 Apr 2008 11:43:27 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 529FE3A69CD for ; Tue, 15 Apr 2008 11:43:25 -0700 (PDT) Received: (qmail invoked by alias); 15 Apr 2008 18:43:59 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp031) with SMTP; 15 Apr 2008 20:43:59 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19v8bNFWp1viRUfrMEnRtJHHp+XNqM5lkKfBrARCn 6m61hvliYo5F6U Message-ID: <4804F71A.2090502@gmx.net> Date: Tue, 15 Apr 2008 21:42:34 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Richard Barnes References: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> <012a01c89f04$b2f25290$6901a8c0@cis.neustar.com> <4804C34C.2060508@bbn.com> <019c01c89f21$a5de8520$6901a8c0@cis.neustar.com> <4804F51D.6000700@bbn.com> In-Reply-To: <4804F51D.6000700@bbn.com> X-Y-GMX-Trusted: 0 Cc: 'ECRIT' Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org For the emergency services use case that makes a lot of sense. Ciao Hannes Richard Barnes wrote: >> Generally, I think all LoST contents should be alike. >> I think it's preferable for the access network to provide the pointer to the >> LoST service. If there is some local routing issue, it's the access network >> that has the best information. >> > > Is that a requirement that should be added into phonebcp/framework? E.g., > > " > ED-* When an endpoint has obtained a LoST server via an discovery > mechanism (e.g., via the DNS [ref] or DHCP [ref]), it SHOULD prefer the > discovered LoST server over LoST servers configured by other means. > That is, the endpoint SHOULD send queries to this LoST server, using > other LoST servers only if these queries fail. > " > > --RB > > > >> Brian >> >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Tuesday, April 15, 2008 11:02 AM >> To: Brian Rosen >> Cc: 'DRAGE, Keith (Keith)'; 'ECRIT' >> Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) >> >> Actually, I think this use case might introduce more problems than the >> one Keith pointed out. For instance, consider the case where >> 1) The endpoint/caller is connected to an access net with its own PSAP >> 2) The endpoint/caller does his own LoST routing. >> >> ISTM that for the caller to end up with the enterprise PSAP's URI within >> the current framework, one of a three things has to happen: >> >> 1) Forced private LoST: The caller uses a LoST resolver operated by the >> access network, so that the resolver can direct the caller to the >> enterprise PSAP. While the LoST discovery mechanism enable this to >> happen, there is not a requirement in framework/phonebcp for the caller >> to prefer the local LoST resolver (at least I haven't found one). >> >> 2) Private LoST in the public tree: If the caller is allowed to use the >> public LoST infrastructure, then these private arrangements must be >> accounted for in that infrastructure. >> 2a) To do this without changing LoST routing, you would have to map >> specific geographic areas to enterprise PSAPs, so that a standard LoST >> query would route to the enterprise LoST server. >> 2b) If we're willing to change the LoST routing, then caller could >> include a tag in the request (in the URN or otherwise) that indicates >> the network to which the requestor is connected, so that queries could >> be routed based on the tag. Or the LoST server could route based on the >> IP address of the caller. >> >> The problem is even harder when a proxy does LoST routing on behalf of >> an endpoint. Solutions engineering aside, do people think this is >> actually a problem? >> >> --Richard >> >> P.S.: Among these options, my preference is actually for option 2b. >> Option 1 encourages different resolvers to present different views of >> the LoST infrastructure. Option 2a is probably incompatible with >> devices that have imprecise location (given that the "enterprise >> regions" will usually be small). Option 2b cleanly, explicitly >> incorporates additional routing parameters (i.e., not location or >> service) into LoST. >> >> >> >> >> Brian Rosen wrote: >> >>> We may have inadvertently created a problem. >>> >>> The intention is to allow the enterprise to operate the PSAP, and >>> urn:service:sos to be used to return the URI of that enterprise PSAP. >>> >>> This clearly occurs in specific instances. >>> >>> Does 5031 reference the definition in 5012? If so, we may need an >>> >> erratum. >> >>> Brian >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >>> DRAGE, Keith (Keith) >>> Sent: Tuesday, April 15, 2008 9:28 AM >>> To: ECRIT >>> Subject: [Ecrit] Usage of service URN by enterprises (RFC 5031) >>> >>> RFC 5031 defines service URN as: >>> >>> urn:service:sos The generic 'sos' service reaches a public safety >>> answering point (PSAP), which in turn dispatches aid appropriate >>> to the emergency. It encompasses all of the services listed >>> below. >>> >>> The definition of PSAP from RFC 5012 is as follows: >>> >>> Public Safety Answering Point (PSAP): A PSAP is a facility where >>> emergency calls are received under the responsibility of a public >>> authority. (This terminology is used by both the European >>> Telecommunications Standards Institute (ETSI), in ETSI SR 002 180, >>> and the National Emergency Number Association (NENA).) In the >>> United Kingdom, PSAPs are called Operator Assistance Centres; in >>> New Zealand, Communications Centres. Within this document, it is >>> assumed, unless stated otherwise, that PSAPs support the receipt >>> of emergency calls over IP, using appropriate application layer >>> protocols, such as SIP for call signaling and RTP for media. >>> >>> If I have an enterprise, that provides its own emergency services, with >>> its own emergency service routeing proxy and its own answer points, is >>> it appropriate or inappropriate to use urn:service:sos. If it is >>> inappropriate, is there a service urn that should be used? Otherwise it >>> would seem that we are back to using numbers. >>> >>> While many enterprises will use the public network capability to respond >>> to an emergency, there are cases where it is inappropriate, or indeed >>> impossible for the the public network capability to provide an >>> appropriate response for an enterprise. >>> >>> Regards >>> >>> Keith >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >>> >> >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 15 15:05:30 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26A693A6F35; Tue, 15 Apr 2008 15:05:30 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE6AF28C432 for ; Tue, 15 Apr 2008 15:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, 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 DSlJkIjz6CYr for ; Tue, 15 Apr 2008 15:05:27 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 704A03A6C25 for ; Tue, 15 Apr 2008 15:05:19 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_04_15_17_19_20 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 15 Apr 2008 17:19:19 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Apr 2008 17:05:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Apr 2008 17:05:51 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: New Version Notification fordraft-barnes-ecrit-rough-loc-00] Thread-Index: AcifDYgWJpAuQOAlT4yiJYkeZR5qxAANmqVu References: <47B9A89C.2020704@bbn.com> <4804C9DE.40204@bbn.com> From: "Winterbottom, James" To: "Richard Barnes" , "Karl Heinz Wolf" X-OriginalArrivalTime: 15 Apr 2008 22:05:40.0284 (UTC) FILETIME=[D78AA7C0:01C89F44] Cc: ECRIT Subject: Re: [Ecrit] [Fwd: New Version Notification fordraft-barnes-ecrit-rough-loc-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Richard, Just a comment below. > What if the HELD request is with locationtype civic and exact=true ? > The LIS is not allowed to hand out a URI any more, and the client > cannot know that the value it gets is imprecise. Or would you suggest > that this type of query fails, and the client would have to request a > locationURI in a separate request, dereference the URI in the next > step to get imprecise location? That's a good point, and I think the request failing is the correct behavior. If a client cannot support location-by-reference (i.e., if it can only support civic or geo), then it is incompatible with this solution. If the client CAN use an LbyR, then it should re-query. [AJW] I am assuming that in this case the end-point (I am going to use this term in place of client) has set the responseTime to a value of emergencyRouting. In which case the LIS already knows the intended application for the location information, so the LIS will return location information in the form suitable for that application, be that a literal location or a location URI. If the device is using HELD, then it had better be prepared to accept and deal with a location URI or it isn't HELD compliant. I also think that the use case is a little moot as presented, as the end-point probably doesn't have authorization to dereference the URI, oris the suggestion that the LIS provides different grades of location information depending on who is asking? Cheers James > > > cheers > karl heinz > > > On Mon, Feb 18, 2008 at 4:47 PM, Richard Barnes wrote: >> We have posted a draft that explains how imprecise location can be used >> for emergency context resolution within the ECRIT framework. >> Specifically, we describe how a location provider can determine when a >> position is sufficiently precise for emergency call routing, and how >> emergency and non-emergency services are delivered in this context. >> >> While this document may enable a solution to the location-hiding >> problem, it can also be useful when a location provider is using >> positioning mechanisms that are capable of returning location at various >> granularities, with finer-grained location taking more time or resources >> to compute. >> >> --Richard >> >> >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-barnes-ecrit-rough-loc-00 >> Date: Mon, 18 Feb 2008 07:35:55 -0800 (PST) >> From: IETF I-D Submission Tool >> To: rbarnes@bbn.com >> CC: mlepinski@bbn.com >> >> >> A new version of I-D, draft-barnes-ecrit-rough-loc-00.txt has been >> successfuly submitted by Richard Barnes and posted to the IETF repository. >> >> Filename: draft-barnes-ecrit-rough-loc >> Revision: 00 >> Title: Using Imprecise Location for Emergency Context Resolution >> Creation_date: 2008-02-18 >> WG ID: Independent Submission >> Number_of_pages: 12 >> >> Abstract: >> Emergency calling works best when precise location is available for >> emergency call routing. However, there are situations in which a >> location provider is unable or unwilling to provide precise location, >> yet still wishes to enable subscribers to make emergency calls. This >> document describes the level of location accuracy that providers must >> provide to enable emergency call routing. In addition, we descibe >> how emergency services and non-emergency services can be invoked by >> an endpoint that does not have access to its precise location. >> >> >> >> >> The IETF Secretariat. >> >> >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> http://www.ietf.org/mailman/listinfo/ecrit >> > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 15 15:39:15 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326903A695D; Tue, 15 Apr 2008 15:39:15 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18113A680E for ; Tue, 15 Apr 2008 15:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 9CiJ9qL0JJ+b for ; Tue, 15 Apr 2008 15:39:12 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 33B2A3A684F for ; Tue, 15 Apr 2008 15:39:12 -0700 (PDT) Received: from col-dhcp33-244-168.bbn.com ([128.33.244.168] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JltoY-0004dw-3f; Tue, 15 Apr 2008 18:39:46 -0400 Message-ID: <48052EB0.1060908@bbn.com> Date: Tue, 15 Apr 2008 18:39:44 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Winterbottom, James" References: <47B9A89C.2020704@bbn.com> <4804C9DE.40204@bbn.com> In-Reply-To: Cc: ECRIT Subject: Re: [Ecrit] [Fwd: New Version Notification fordraft-barnes-ecrit-rough-loc-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James, Couple of responses, both to you and myself. > That's a good point, and I think the request failing is the correct > behavior. If a client cannot support location-by-reference (i.e., if > it can only support civic or geo), then it is incompatible with this > solution. If the client CAN use an LbyR, then it should re-query. [RLB] I misspoke (mis-wrote?) here; this statement is not quite accurate. As James points out, the HELD server can still return the imprecise value, and the call will route correctly; the call just won't carry location. So when endpoints don't support LbyR, they get degraded service. As Karl Heinz points out, there's no clear indicator in this case that the location is imprecise, but presumably that can be inferred by examining the location and the region it covers. [/RLB] > [AJW] I am assuming that in this case the end-point (I am going to > use this term in place of client) has set the responseTime to a value > of emergencyRouting. In which case the LIS already knows the intended > application for the location information, so the LIS will return > location information in the form suitable for that application, be > that a literal location or a location URI. [RLB] That's true (see above). However, it's worth noting that in that case, the access controls for the location URI MUST allow the client to dereference it to obtain a coarse location. [/RLB] > If the device is using > HELD, then it had better be prepared to accept and deal with a > location URI or it isn't HELD compliant. [RLB] I don't see how this follows. Otherwise, why does HELD allow me to set geodetic civic? [/RLB] > I also think that the use > case is a little moot as presented, as the end-point probably doesn't > have authorization to dereference the URI, oris the suggestion that > the LIS provides different grades of location information depending > on who is asking? [RLB] Here's the real requirement: In order to ensure that the endpoint has access to routing-grade location, the LIS MUST provide either routing-grade LbyV (plus an optional LbyR), or an LbyR that the endpoint can dereference to a routing-grade LbyV. The choice between these two can be left to the LIS without affecting interoperability; if the client doesn't get an LbyV, then he just tries to dereference the LbyR. [/RLB] Cheers, --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 15 22:53:48 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA90228C118; Tue, 15 Apr 2008 22:53:48 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D42D228C138 for ; Tue, 15 Apr 2008 22:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.014 X-Spam-Level: X-Spam-Status: No, score=-1.014 tagged_above=-999 required=5 tests=[AWL=0.189, 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 HgqqavyPdddF for ; Tue, 15 Apr 2008 22:53:47 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 137143A6C23 for ; Tue, 15 Apr 2008 22:53:47 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_04_16_01_07_39 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 16 Apr 2008 01:07:39 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Apr 2008 00:54:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Apr 2008 00:52:04 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: New Version Notification fordraft-barnes-ecrit-rough-loc-00] Thread-Index: AcifSZtxcngjimkURXqRHiHaSJR0dAAPGPAn References: <47B9A89C.2020704@bbn.com> <4804C9DE.40204@bbn.com> <48052EB0.1060908@bbn.com> From: "Winterbottom, James" To: "Richard Barnes" X-OriginalArrivalTime: 16 Apr 2008 05:54:11.0843 (UTC) FILETIME=[4B562530:01C89F86] Cc: ECRIT Subject: Re: [Ecrit] [Fwd: New Version Notification fordraft-barnes-ecrit-rough-loc-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org One more below. [RLB] Here's the real requirement: In order to ensure that the endpoint has access to routing-grade location, the LIS MUST provide either routing-grade LbyV (plus an optional LbyR), or an LbyR that the endpoint can dereference to a routing-grade LbyV. The choice between these two can be left to the LIS without affecting interoperability; if the client doesn't get an LbyV, then he just tries to dereference the LbyR. [/RLB] [AJW]I think that this is only true if you start with the premise that the end-point must have location. A location URI and a destination URI achieves the same result without providing location to the end-point. I will however concede that this does not provide you with a coarse location solution... *8) [/AJW] ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 16 06:27:39 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2856A3A6C5C; Wed, 16 Apr 2008 06:27:39 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDADC3A6C42 for ; Wed, 16 Apr 2008 06:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 CKxf8dO7FH+h for ; Wed, 16 Apr 2008 06:27:36 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 8E3B43A6B9F for ; Wed, 16 Apr 2008 06:27:36 -0700 (PDT) Received: from col-dhcp33-244-168.bbn.com ([128.33.244.168] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Jm7gH-0003gj-3T; Wed, 16 Apr 2008 09:28:09 -0400 Message-ID: <4805FEE7.5020407@bbn.com> Date: Wed, 16 Apr 2008 09:28:07 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Winterbottom, James" References: <47B9A89C.2020704@bbn.com> <4804C9DE.40204@bbn.com> <48052EB0.1060908@bbn.com> In-Reply-To: Cc: ECRIT Subject: Re: [Ecrit] [Fwd: New Version Notification fordraft-barnes-ecrit-rough-loc-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > [RLB] Here's the real requirement: In order to ensure that the > endpoint has access to routing-grade location, the LIS MUST provide > either routing-grade LbyV (plus an optional LbyR), or an LbyR that > the endpoint can dereference to a routing-grade LbyV. The choice > between these two can be left to the LIS without affecting > interoperability; if the client doesn't get an LbyV, then he just > tries to dereference the LbyR. [/RLB] > > [AJW]I think that this is only true if you start with the premise > that the end-point must have location. A location URI and a > destination URI achieves the same result without providing location > to the end-point. I will however concede that this does not provide > you with a coarse location solution... *8) [/AJW] [RLB] Exactly. This document is describing a partcular solution, the "coarse location" solution. In the context of that solution, the LIS MUST provide coarse location to the endpoint, whether by value or by reference. [/RLB] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 16 11:53:16 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D08B3A68AB; Wed, 16 Apr 2008 11:53:16 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 258763A68AB for ; Wed, 16 Apr 2008 11:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 IdBt94oM4W52 for ; Wed, 16 Apr 2008 11:53:13 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id B6DFD3A6814 for ; Wed, 16 Apr 2008 11:53:13 -0700 (PDT) Received: from col-dhcp33-244-168.bbn.com ([128.33.244.168] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JmClQ-0000ZE-6F; Wed, 16 Apr 2008 14:53:49 -0400 Message-ID: <48064B39.3060402@bbn.com> Date: Wed, 16 Apr 2008 14:53:45 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hannes Tschofenig References: <47FBBA34.1050704@gmx.net> <47FBBF69.7000504@bbn.com> In-Reply-To: <47FBBF69.7000504@bbn.com> Cc: Roger Hixson , ecrit@ietf.org Subject: Re: [Ecrit] NENA NG9-1-1 related Standard for review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If other folks are reviewing this document, the version linked from Roger's email is broken; some of the figures got destroyed. There's a good version on the NENA web site at the following URI: --RB Richard Barnes wrote: > I will review the document. > --RB > > Hannes Tschofenig wrote: >> Folks, >> >> Roger Hixson is asking for feedback on a NENA document (see attachment). >> Who would be willing to review the NENA document? Please drop us a note. >> >> Ciao >> Hannes >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 16 18:41:13 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0635328C4C3; Wed, 16 Apr 2008 18:41:13 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 908643A6F2D for ; Wed, 16 Apr 2008 18:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.88 X-Spam-Level: X-Spam-Status: No, score=-2.88 tagged_above=-999 required=5 tests=[AWL=0.719, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P64TJa5pPuRg for ; Wed, 16 Apr 2008 18:41:10 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 759DB28C4C3 for ; Wed, 16 Apr 2008 18:40:12 -0700 (PDT) Received: from [192.168.0.57] (pool-71-250-66-107.nwrknj.east.verizon.net [71.250.66.107]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m3H1ehkr001643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Apr 2008 21:40:44 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Richard Barnes In-Reply-To: <4804F51D.6000700@bbn.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 16 Apr 2008 21:40:43 -0400 References: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> <012a01c89f04$b2f25290$6901a8c0@cis.neustar.com> <4804C34C.2060508@bbn.com> <019c01c89f21$a5de8520$6901a8c0@cis.neustar.com> <4804F51D.6000700@bbn.com> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6 Cc: 'ECRIT' Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Standard beef: A requirement with lots of SHOULD is useless. On Apr 15, 2008, at 2:34 PM, Richard Barnes wrote: >> Generally, I think all LoST contents should be alike. >> I think it's preferable for the access network to provide the >> pointer to the >> LoST service. If there is some local routing issue, it's the >> access network >> that has the best information. > > Is that a requirement that should be added into phonebcp/framework? > E.g., > > " > ED-* When an endpoint has obtained a LoST server via an discovery > mechanism (e.g., via the DNS [ref] or DHCP [ref]), it SHOULD prefer > the > discovered LoST server over LoST servers configured by other means. > That is, the endpoint SHOULD send queries to this LoST server, using > other LoST servers only if these queries fail. > " > > --RB > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 16 19:30:33 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 699A73A69F6; Wed, 16 Apr 2008 19:30:33 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 772253A6CCC for ; Wed, 16 Apr 2008 19:30:32 -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 3Fd6NDnnBEDW for ; Wed, 16 Apr 2008 19:30:31 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 9149D3A6FC8 for ; Wed, 16 Apr 2008 19:30:00 -0700 (PDT) Received: from [128.89.255.16] (helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JmJtS-0000cO-4w; Wed, 16 Apr 2008 22:30:34 -0400 Message-ID: <4806B648.80101@bbn.com> Date: Wed, 16 Apr 2008 22:30:32 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Henning Schulzrinne References: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> <012a01c89f04$b2f25290$6901a8c0@cis.neustar.com> <4804C34C.2060508@bbn.com> <019c01c89f21$a5de8520$6901a8c0@cis.neustar.com> <4804F51D.6000700@bbn.com> In-Reply-To: Cc: 'ECRIT' Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm fine with making it a MUST; I don't see any obvious problems that that would cause. On the other hand, I'm not entirely convinced that it's necessary for an endpoint to behave in that way in order for it to work interoperably. Like Brian says, "all LoST contents should be alike"; a query to any resolver (discovered or otherwise) should return the same result. In practice, that won't be true (particularly when deployment is patchy), so it's preferable to use the local resolver. The "SHOULD" in this case would be "SHOULD, unless otherwise configured" (just like with DNS servers today). So either SHOULD or MUST is ok with me. I'm feeling agreeable today... --RB Henning Schulzrinne wrote: > Standard beef: A requirement with lots of SHOULD is useless. > > On Apr 15, 2008, at 2:34 PM, Richard Barnes wrote: >>> Generally, I think all LoST contents should be alike. >>> I think it's preferable for the access network to provide the pointer >>> to the >>> LoST service. If there is some local routing issue, it's the access >>> network >>> that has the best information. >> >> Is that a requirement that should be added into phonebcp/framework? >> E.g., >> >> " >> ED-* When an endpoint has obtained a LoST server via an discovery >> mechanism (e.g., via the DNS [ref] or DHCP [ref]), it SHOULD prefer the >> discovered LoST server over LoST servers configured by other means. >> That is, the endpoint SHOULD send queries to this LoST server, using >> other LoST servers only if these queries fail. >> " >> >> --RB >> > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 17 05:31:28 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7FC23A6898; Thu, 17 Apr 2008 05:31:28 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D78793A6909 for ; Thu, 17 Apr 2008 05:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9Zfol0VRLmB for ; Thu, 17 Apr 2008 05:31:22 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by core3.amsl.com (Postfix) with ESMTP id 95E253A6867 for ; Thu, 17 Apr 2008 05:31:22 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 19so66256fkr.5 for ; Thu, 17 Apr 2008 05:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=MOBXxA2oVVgri6NkMvIgH8p192MnXov0HgeO8dhzxVs=; b=YCiMfuljTrPqMxZjBiFfjbYPY4/s6qebmi251C8DkL8ze3McDwrp/a7+VMs+olwKDwy5exBktsmnH9d8m3KUFoVgeeYlNTrbu17xCDYkV7SvLHml0/qTDg5eVCTW+iHNM217CLMd4ugHnGNIued3kBJH5fF5fZCpxHQtF/bktTI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BVZbTKFX5BYyTQAMqObRAaL9w6PypVTej3Ye5ZxkYoKAaBNzX+PDNcZvWicf2hIqqpoxhki3FkHxo0pRrIYStvcjqkFHE5IcMbxBWIQbxC+RtLl6nly9cl4hQGR7/I33Jg8Zq7dm7UJriwEOtRXTN48ZSxwc+TjJzj+EZmKF87s= Received: by 10.82.158.12 with SMTP id g12mr2199155bue.50.1208435519940; Thu, 17 Apr 2008 05:31:59 -0700 (PDT) Received: by 10.82.165.18 with HTTP; Thu, 17 Apr 2008 05:31:59 -0700 (PDT) Message-ID: Date: Thu, 17 Apr 2008 14:31:59 +0200 From: "Karl Heinz Wolf" To: "Stark, Barbara" In-Reply-To: <7E6ACFE7-BF6B-4AF8-9F36-9A70010502B9@cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <7582BC68E4994F4ABF0BD4723975C3FA080ECE71@crexc41p> <7E6ACFE7-BF6B-4AF8-9F36-9A70010502B9@cisco.com> Cc: ECRIT Subject: Re: [Ecrit] Fwd: Liaison from DSL Forum to ecrit and geopriv X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Barbara! I read your new DSL-Forum document, and I think there is something missing in flow A. If one takes the NO path from "is DHCP used for IP address config?", then there is no check for LLDP-MED success as in case for YES. One questions regarding server location 12: why should manually configured civic location not be advertised by LLDP-MED or DHCP. phonebcp says all fields of PIDF-LO must be able to be specified (ED-15). All the civic location parts have their according CAType number (which would fit in DHCP and LLDP-MED), but you cannot say method=manual in these protocols, is this the actual reason for your requirement? just a note for requirement Server location 2: it should be RFC4776 I think. Thank you for publishing your document here. -- karl heinz On Thu, Apr 3, 2008 at 2:37 PM, Cullen Jennings wrote: > > Jon and I receive the following email with three files attached. I > have removed the attachments form the email and put them and a PDF > version of them at the following URL. > > http://idisk.mac.com/cullenfluffyjennings-Public?view=web > > Cullen > > > Begin forwarded message: > > From: "Stark, Barbara" > > Date: March 28, 2008 12:53:23 PM PDT > > To: , > > Subject: Liaison from DSL Forum to ecrit and geopriv > > > > Jon, Cullen, > > Attached is a liaison from the DSL Forum to ecrit and geopriv WGs > > regarding IP device requirements for emergency services. If you could > > pass it along to those groups, I'd appreciate it. > > > > Thanks, > > Barbara > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 22 06:13:50 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C2C83A6D48; Tue, 22 Apr 2008 06:13:50 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72EC63A6D48 for ; Tue, 22 Apr 2008 06:13:49 -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 Tmc6EHbisJNm for ; Tue, 22 Apr 2008 06:13:48 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DC0473A6B8E for ; Tue, 22 Apr 2008 06:13:47 -0700 (PDT) Received: (qmail invoked by alias); 22 Apr 2008 13:13:52 -0000 Received: from adsl126.sntlabs.com (EHLO [192.168.1.96]) [205.152.56.126] by mail.gmx.net (mp021) with SMTP; 22 Apr 2008 15:13:52 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18At+AOr4EAZ0JTiCOoC3KxfzCaYboYhhvb5R57BE vuil3fEChD1MPG Message-ID: <480DE484.3050205@gmx.net> Date: Tue, 22 Apr 2008 16:13:40 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: 'ECRIT' X-Y-GMX-Trusted: 0 Subject: [Ecrit] [Fwd: [Es-coordination] Info for the Emergency Services Workshop] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org FYI -------- Original Message -------- Subject: [Es-coordination] Info for the Emergency Services Workshop Date: Tue, 22 Apr 2008 16:10:32 +0300 From: Hannes Tschofenig To: es-coordination@lists.cs.columbia.edu You can participate from remote at the workshop. Please find the conference bridge and the Webex info here: http://www.shingou.info/twiki/bin/view/EmergencyServices/BridgeDetails Information about the Jabber room can be found here: http://www.emergency-services-coordination.info/2008/ Ciao Hannes _______________________________________________ Es-coordination mailing list Es-coordination@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/es-coordination _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 23 11:13:02 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03B323A6B66; Wed, 23 Apr 2008 11:13:02 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB643A6B56 for ; Wed, 23 Apr 2008 11:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_66=0.6, 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 nSm+tz1McSX9 for ; Wed, 23 Apr 2008 11:13:00 -0700 (PDT) Received: from aismt07p.bellsouth.com (aismt07p.bellsouth.com [139.76.165.213]) by core3.amsl.com (Postfix) with ESMTP id 53B9B28C163 for ; Wed, 23 Apr 2008 11:13:00 -0700 (PDT) Received: from ([139.76.131.91]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.200325108; Wed, 23 Apr 2008 14:12:32 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 23 Apr 2008 14:12:32 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 23 Apr 2008 14:12:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Apr 2008 14:12:29 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA087DA7B6@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Fwd: Liaison from DSL Forum to ecrit and geopriv Thread-Index: AcighxPJQpowxrdBQBGGNOGOccoGsgE3N0lA References: <7582BC68E4994F4ABF0BD4723975C3FA080ECE71@crexc41p> <7E6ACFE7-BF6B-4AF8-9F36-9A70010502B9@cisco.com> From: "Stark, Barbara" To: "Karl Heinz Wolf" X-OriginalArrivalTime: 23 Apr 2008 18:12:31.0892 (UTC) FILETIME=[991D6D40:01C8A56D] Cc: ECRIT Subject: Re: [Ecrit] Fwd: Liaison from DSL Forum to ecrit and geopriv X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Karl Heinz, Thanks for reading it. I specifically removed the check for whether or not there was a response from LLDP-MED. By removing that, the device no longer has to wait for LLDP-MED to timeout before initiating the DHCP. I'm assuming there will be no LLDP in the majority of consumer scenarios. Not waiting makes things work faster. In discussions with various people, we came to the conclusion that there was really no negative consequence to not waiting for LLDP-MED to either return a response or timeout. This is also consistent with phonebcp, which expresses a preference for trying all location configuration protocols. I hadn't checked to see that all PIDF-LO fields had a corresponding CAtype. I see that you're right. Yes, DHCP is missing method. It also lacks a signing ability (if one is ever created). I'm also concerned with the ability to represent some of the ideas currently in draft-ietf-geopriv-pdif-lo-profile-11, like multiple LO in a single PIDF-LO. That particular example probably isn't relevant to this case, but I still worry that some change may be made to PIDF-LO in the future that DHCP/LLDP-MED wont be able to express. Thanks for mentioning the bad reference. Barbara -----Original Message----- From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] Sent: Thursday, April 17, 2008 8:32 AM To: Stark, Barbara Cc: ECRIT Subject: Re: [Ecrit] Fwd: Liaison from DSL Forum to ecrit and geopriv Hi Barbara! I read your new DSL-Forum document, and I think there is something missing in flow A. If one takes the NO path from "is DHCP used for IP address config?", then there is no check for LLDP-MED success as in case for YES. One questions regarding server location 12: why should manually configured civic location not be advertised by LLDP-MED or DHCP. phonebcp says all fields of PIDF-LO must be able to be specified (ED-15). All the civic location parts have their according CAType number (which would fit in DHCP and LLDP-MED), but you cannot say method=manual in these protocols, is this the actual reason for your requirement? just a note for requirement Server location 2: it should be RFC4776 I think. Thank you for publishing your document here. -- karl heinz On Thu, Apr 3, 2008 at 2:37 PM, Cullen Jennings wrote: > > Jon and I receive the following email with three files attached. I > have removed the attachments form the email and put them and a PDF > version of them at the following URL. > > http://idisk.mac.com/cullenfluffyjennings-Public?view=web > > Cullen > > > Begin forwarded message: > > From: "Stark, Barbara" > > Date: March 28, 2008 12:53:23 PM PDT > > To: , > > Subject: Liaison from DSL Forum to ecrit and geopriv > > > > Jon, Cullen, > > Attached is a liaison from the DSL Forum to ecrit and geopriv WGs > > regarding IP device requirements for emergency services. If you could > > pass it along to those groups, I'd appreciate it. > > > > Thanks, > > Barbara > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 23 13:30:29 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B45F3A6822; Wed, 23 Apr 2008 13:30:29 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBC663A67F4 for ; Wed, 23 Apr 2008 13:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ofqtXLIy+Ot for ; Wed, 23 Apr 2008 13:30:27 -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 5BB093A6822 for ; Wed, 23 Apr 2008 13:29:57 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 23 Apr 2008 13:30:03 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m3NKU3pw002126; Wed, 23 Apr 2008 13:30:03 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3NKU32r005765; Wed, 23 Apr 2008 20:30:03 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Apr 2008 13:29:59 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.88.66]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Apr 2008 13:29:58 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 23 Apr 2008 15:29:46 -0500 To: "Stark, Barbara" , "Karl Heinz Wolf" From: "James M. Polk" In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA087DA7B6@crexc41p> References: <7582BC68E4994F4ABF0BD4723975C3FA080ECE71@crexc41p> <7E6ACFE7-BF6B-4AF8-9F36-9A70010502B9@cisco.com> <7582BC68E4994F4ABF0BD4723975C3FA087DA7B6@crexc41p> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 23 Apr 2008 20:29:58.0773 (UTC) FILETIME=[CCA39A50:01C8A580] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4863; t=1208982603; x=1209846603; 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]=20Fwd=3A=20Liaison=20from=20DSL =20Forum=20to=20ecrit=20and=20geopriv |Sender:=20; bh=3xpNTMVReaeSol7wCxi+JW2J09Fu3KRs5SOcQ5G+42o=; b=YgmF8bWx9XsUcRHAbNr/tI4wdRc5f80pDTArxXCKglq/czaa6tzaJQtSnD 7wkGFyHtnXmjUOwfHj5cvpACPFT8LUkkoMaTZp0siV73ujdCqs8rqiycqWlS yxEerVYQ+O; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: ECRIT Subject: Re: [Ecrit] Fwd: Liaison from DSL Forum to ecrit and geopriv X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Barbara comments in-line At 01:12 PM 4/23/2008, Stark, Barbara wrote: >Hi Karl Heinz, >Thanks for reading it. > >I specifically removed the check for whether or not there was a response >from LLDP-MED. By removing that, the device no longer has to wait for >LLDP-MED to timeout before initiating the DHCP. I'm assuming there will >be no LLDP in the majority of consumer scenarios. however, LLDP-MED will likely be quite often in enterprise situations, and understanding the level of spillover between the two network environments (residential and enterprise -- not to mention that there really isn't a clear-cut choice for the SMB market to choose between these two, meaning they will come from either, therefore both point products) -- I'm not sure I agree with this opinion. >Not waiting makes >things work faster. but could (possibly) result in receiving location from two sources. Given the lack of guidance of what to do with more than one location source (does the UA send both?') and what the receiver does with receiving both (which *one* does it deem true (or truer) to use?). >In discussions with various people, we came to the >conclusion that there was really no negative consequence to not waiting >for LLDP-MED to either return a response or timeout. This is also >consistent with phonebcp, which expresses a preference for trying all >location configuration protocols. > >I hadn't checked to see that all PIDF-LO fields had a corresponding >CAtype. I see that you're right. Yes, DHCP is missing method. I'm not sure what you mean by DHCP=manual needs to be there. Both LLDP-MED and DHCP are in the "server-to-client" direction. Unless I'm misunderstanding what you and Karl seem to be agreeing to, you want DHCP and LLDP-MED to be able to send LCI in the "client-to-whatever" direction. This isn't the way these protocols are designed to work. >It also lacks a signing ability (if one is ever created). I'm not sure I understand this concern... >I'm also concerned with the ability to represent some of the ideas >currently in >draft-ietf-geopriv-pdif-lo-profile-11, like multiple LO in a single >PIDF-LO. Is this concern that DHCP can't send more than one LCI at the same time? I'm just trying to figure out this exchange... sorry if I've missed the point of it >That particular example probably isn't relevant to this case, >but I still worry that some change may be made to PIDF-LO in the future >that DHCP/LLDP-MED wont be able to express. > >Thanks for mentioning the bad reference. >Barbara > >-----Original Message----- >From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >Sent: Thursday, April 17, 2008 8:32 AM >To: Stark, Barbara >Cc: ECRIT >Subject: Re: [Ecrit] Fwd: Liaison from DSL Forum to ecrit and geopriv > >Hi Barbara! > >I read your new DSL-Forum document, and I think there is something >missing in flow A. >If one takes the NO path from "is DHCP used for IP address config?", >then there is no check for LLDP-MED success as in case for YES. > >One questions regarding server location 12: why should manually >configured civic location not be advertised by LLDP-MED or DHCP. >phonebcp says all fields of PIDF-LO must be able to be specified >(ED-15). All the civic location parts have their according CAType >number (which would fit in DHCP and LLDP-MED), but you cannot say >method=manual in these protocols, is this the actual reason for your >requirement? > >just a note for requirement Server location 2: it should be RFC4776 I >think. > >Thank you for publishing your document here. > >-- karl heinz > > >On Thu, Apr 3, 2008 at 2:37 PM, Cullen Jennings >wrote: > > > > Jon and I receive the following email with three files attached. I > > have removed the attachments form the email and put them and a PDF > > version of them at the following URL. > > > > http://idisk.mac.com/cullenfluffyjennings-Public?view=web > > > > Cullen > > > > > > Begin forwarded message: > > > From: "Stark, Barbara" > > > Date: March 28, 2008 12:53:23 PM PDT > > > To: , > > > Subject: Liaison from DSL Forum to ecrit and geopriv > > > > > > Jon, Cullen, > > > Attached is a liaison from the DSL Forum to ecrit and geopriv WGs > > > regarding IP device requirements for emergency services. If you >could > > > pass it along to those groups, I'd appreciate it. > > > > > > Thanks, > > > Barbara > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 24 07:56:23 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F08EC3A6B6D; Thu, 24 Apr 2008 07:56:23 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDCBF3A6B14 for ; Thu, 24 Apr 2008 07:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 BPK5k0C413a0 for ; Thu, 24 Apr 2008 07:56:19 -0700 (PDT) Received: from aismt07p.bellsouth.com (aismt07p.bellsouth.com [139.76.165.213]) by core3.amsl.com (Postfix) with ESMTP id 7B5E63A6C04 for ; Thu, 24 Apr 2008 07:55:59 -0700 (PDT) Received: from ([139.76.131.83]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.200394338; Thu, 24 Apr 2008 10:55:42 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 24 Apr 2008 10:55:42 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 24 Apr 2008 10:55:42 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Apr 2008 10:53:57 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA087DA942@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Fwd: Liaison from DSL Forum to ecrit and geopriv thread-index: AcilgOX7/ZLt0j2WTQSraNbVJlWK9wABccrg References: <7582BC68E4994F4ABF0BD4723975C3FA080ECE71@crexc41p> <7E6ACFE7-BF6B-4AF8-9F36-9A70010502B9@cisco.com> <7582BC68E4994F4ABF0BD4723975C3FA087DA7B6@crexc41p> From: "Stark, Barbara" To: "James M. Polk" ,"Karl Heinz Wolf" X-OriginalArrivalTime: 24 Apr 2008 14:55:42.0356 (UTC) FILETIME=[447EFD40:01C8A61B] Cc: ECRIT Subject: Re: [Ecrit] Fwd: Liaison from DSL Forum to ecrit and geopriv X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James, My document does have details for handling multiple locations. I don't think there's any lack of guidance there (and it is the contents of the DSL Forum document we're talking about, and not phonebcp). It says "The device MAY allow configuration of the rules for ordering multiple locations, and selecting the one to use for the LoST query and routing. The recommended default order is LLDP-MED, DHCP, HELD, GPS, and manual." I think this statement needs to be improved to make a default recommendation in case other configuration mechanisms exist. But the guidance that phonebcp does supply is that a device should try all location config protocols (LCPs), and that the device needs to be able to handle multiple locations. So, I believe that the DSL Forum document is consistent in this area, except that it doesn't recommend proceeding with HELD, if there is success at the lower layers. I'll probably change that to do HELD if the device got a LIS server URL via DHCP. But I'm not sure of the benefits of doing public IP address discovery, followed by LIS discovery through reverse DNS, followed by HELD, if the device got location already. If others feel strongly that HELD must always be attempted, then I'll consider changing that. So, do you disagree with the phonebcp recommendation to try all LCPs? If you do, how long would you recommend waiting for LLDP-MED to timeout, in case there is no LLDP server in the premises? What do you recommend to address the concerns of people who want to try to make this location config process as quick as possible? My approach was to do a step as soon as possible, without waiting for other things to complete, instead of using lots of timers and timeouts to make sure everything was purely sequential. I'm also a bit confused about your pushback to my statement that LLDP wouldn't be present in the majority of consumer scenarios. You say you disagree with that statement. Does that mean you think it will be present in the majority (over 50%) of consumer (residential) scenarios? That's interesting. Are you aware of consumer-grade equipment that does this today? I'm not, which is why I made that statement. I realize that there are a number of consumers who do use high end equipment, either because of their enterprise job, or their home-based business. But statistics that I've seen suggest that this population is very small compared to the population that uses low-end retail home routers. I currently don't see any LLDP servers in my home in the near future. Barbara -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Wednesday, April 23, 2008 4:30 PM To: Stark, Barbara; Karl Heinz Wolf Cc: ECRIT Subject: Re: [Ecrit] Fwd: Liaison from DSL Forum to ecrit and geopriv Barbara comments in-line At 01:12 PM 4/23/2008, Stark, Barbara wrote: >Hi Karl Heinz, >Thanks for reading it. > >I specifically removed the check for whether or not there was a response >from LLDP-MED. By removing that, the device no longer has to wait for >LLDP-MED to timeout before initiating the DHCP. I'm assuming there will >be no LLDP in the majority of consumer scenarios. however, LLDP-MED will likely be quite often in enterprise situations, and understanding the level of spillover between the two network environments (residential and enterprise -- not to mention that there really isn't a clear-cut choice for the SMB market to choose between these two, meaning they will come from either, therefore both point products) -- I'm not sure I agree with this opinion. >Not waiting makes >things work faster. but could (possibly) result in receiving location from two sources. Given the lack of guidance of what to do with more than one location source (does the UA send both?') and what the receiver does with receiving both (which *one* does it deem true (or truer) to use?). >In discussions with various people, we came to the >conclusion that there was really no negative consequence to not waiting >for LLDP-MED to either return a response or timeout. This is also >consistent with phonebcp, which expresses a preference for trying all >location configuration protocols. --------------- I deleted everything below this ------------------- ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 28 03:47:20 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65F363A6E6B; Mon, 28 Apr 2008 03:47:20 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C73D43A6E6A; Mon, 28 Apr 2008 03:47:14 -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 Lt15J7L9Z8Vy; Mon, 28 Apr 2008 03:47:13 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 8CAF63A6E58; Mon, 28 Apr 2008 03:47:13 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3SAkHYI001517; Mon, 28 Apr 2008 13:47:14 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Apr 2008 13:47:04 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Apr 2008 13:47:03 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Apr 2008 13:47:01 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Emergency Services work in TSVWG Thread-Index: AcipHTBlbT1rDlWOSb6xx7GeiSBnPw== From: To: X-OriginalArrivalTime: 28 Apr 2008 10:47:03.0734 (UTC) FILETIME=[31F4ED60:01C8A91D] X-Nokia-AV: Clean Cc: tsvwg@ietf.org Subject: [Ecrit] Emergency Services work in TSVWG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, In a review of draft-ietf-tsvwg-emergency-rsvp-07.txt I got the impression that the document is not only used for authority-to-authority communication but also for citizen-to-authority communication. Here is my review comment: " * I think the document needs to indicate clearly that this mechanism is supposed to be used for authority-to-authority emergency services and not for citizen-to-authority/authority-to-citizen emergency services. " As a response I received: " I would disagree. What you are asking for would be best placed in a separate applicability draft. For instance, while I mostly agree with your above assertion, I can also envision an exception in the case of Japan's 911-like service, where preferential treatment is supported in their PSTN for these types of many-to-1 call flows. Hence, more elaborate discussions on use cases and applicability is really best served in a different document. " Now, I wonder whether the ECRIT WG is aware of the desire of some folks in TSVWG to have these types of QoS mechanisms to go into citizen-to-authority emergency services architecture? We are currently finishing our architecture document and this document seems to touch that space without being explicit. Thoughts? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 28 03:48:53 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AB143A6E7C; Mon, 28 Apr 2008 03:48:53 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFAB43A6E6E; Mon, 28 Apr 2008 03:48:51 -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 l8FzKbS8h9wJ; Mon, 28 Apr 2008 03:48:51 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D13753A6E6C; Mon, 28 Apr 2008 03:48:50 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3SAmaQm003887; Mon, 28 Apr 2008 13:48:52 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Apr 2008 13:48:16 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Apr 2008 13:48:15 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Apr 2008 13:48:14 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Lack of architectures in TSVWG Thread-Index: AcipHVxb68Rypb+LRTafs0G99Sq9aA== From: To: X-OriginalArrivalTime: 28 Apr 2008 10:48:15.0702 (UTC) FILETIME=[5CDA5F60:01C8A91D] X-Nokia-AV: Clean Cc: ecrit@ietf.org Subject: [Ecrit] Lack of architectures in TSVWG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org One thing we recognized in ECRIT, on individual-to-authority emergency serv= ices, was that the work on architectures changed our view of the individual= protocol building blocks. = In our work you don't seem to have an architecture that explains how that s= tuff should work nor does it even seem to be constraint on where it should = be used. = I am clueless on how you want to accomplish interoperability or even a work= ing system. = Ciao Hannes ----- snippets from the response to my review I agree that the authorization details are out of scope for this document. = It is probably better to reference two possible approaches, rather than jus= t one. = Janet = I agree. = Janet Nguyen, An P wrote: = Fran=E7ois, = I agree with you we should focus on an RSVP extension mechanism in this do= cument. = = Regards, = An = = -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of = Francois Le Faucheur IMAP Sent: Thursday, April 10, 2008 10:40 AM To: Hannes Tschofenig Cc: tsvwg IETF list Subject: Re: [Tsvwg] draft-ietf-tsvwg-emergency-rsvp-06.txt: Comments /Que= stions = Hi Hannes, = * I think the document needs to indicate clearly that this = mechanism is supposed to be used for authority-to-authority = emergency services and not for citizen-to-authority/authority-to- = citizen emergency services. To me this is beyond the scope of this particular document (again = focusing on an RSVP extension mechanism). This would probably pertain = to some overall architecture/solution document for overall emergency = services. = Francois = Ciao Hannes = _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 28 05:19:39 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C14028C28B; Mon, 28 Apr 2008 05:19:39 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 797683A6BAF for ; Mon, 28 Apr 2008 05:19:37 -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 14Cr31kjp9ez for ; Mon, 28 Apr 2008 05:19:36 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 82A503A6E88 for ; Mon, 28 Apr 2008 05:19:36 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA05.westchester.pa.mail.comcast.net with comcast id JzFY1Z00C0bG4ec5503e00; Mon, 28 Apr 2008 12:19:23 +0000 Received: from [192.168.1.120] ([69.255.78.171]) by OMTA03.westchester.pa.mail.comcast.net with comcast id K0Ka1Z0023hlvrZ3P00000; Mon, 28 Apr 2008 12:19:34 +0000 X-Authority-Analysis: v=1.0 c=1 a=AS9Pov_854cA:10 a=l_l2uy4iHPkA:10 a=Ce2ecrBvZvm5qDiNFNUA:9 a=pL311fp83bwSUsuzIfetPIxFvs4A:4 a=zwC7bnKO5xoA:10 a=yQcR2aroB8gA:10 Message-Id: <5F8EDB43-8F83-49A0-A1BA-F841BD1C9395@g11.org.uk> From: ken carlberg To: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 28 Apr 2008 08:19:33 -0400 References: X-Mailer: Apple Mail (2.919.2) Cc: ecrit@ietf.org, tsvwg@ietf.org Subject: Re: [Ecrit] [Tsvwg] Emergency Services work in TSVWG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org whoa, slow down a bit! On Apr 28, 2008, at 6:47 AM, wrote: > Hi all, > > In a review of draft-ietf-tsvwg-emergency-rsvp-07.txt I got the > impression that the document is not only used for authority-to- > authority > communication but also for citizen-to-authority communication. > > Here is my review comment: > " > * I think the document needs to indicate clearly that this > mechanism is supposed to be used for authority-to-authority emergency > services and not for citizen-to-authority/authority-to-citizen > emergency > services. > " > > As a response I received: > > " > I would disagree. What you are asking for would be best placed in a > separate applicability draft. For instance, while I mostly agree > with > your above assertion, I can also envision an exception in the case of > Japan's 911-like service, where preferential treatment is supported in > their PSTN for these types of many-to-1 call flows. Hence, more > elaborate discussions on use cases and applicability is really best > served in a different document. > " > > Now, I wonder whether the ECRIT WG is aware of the desire of some > folks > in TSVWG to have these types of QoS mechanisms to go into > citizen-to-authority emergency services architecture? We are currently > finishing our architecture document and this document seems to touch > that space without being explicit. Please *carefully* note that in my response on the tsvwg list I said "...I can also envision..." ^ ^^ in no way did I state any desire or advocacy, one way or the other, to see the proposed extension used for citizen-to-authority emergency services. I'm agnostic in that regard, and I want the cited tsvwg draft to remain that way. And as I also stated above, its up to another document outside of the cited tsvwg draft to discuss its applicability -- in the context of this note, that would be the ECRIT architecture draft. if pressed on the matter, I would initially advocate a position that the draft-ietf-tsvwg-emergency-rsvp-07.txt MAY be used for citizen- to-authority emergency services. But I haven't followed ECRIT very closely of late, so I'll certainly defer to the consensus of others actively participating in the ECRIT architecture document. cheers, -ken _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 28 07:50:50 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D99553A6E54; Mon, 28 Apr 2008 07:50:50 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50D2C3A6866; Mon, 28 Apr 2008 07:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upPvYGbase34; Mon, 28 Apr 2008 07:50:45 -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 38C393A67AE; Mon, 28 Apr 2008 07:50:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,716,1199682000"; d="scan'208";a="6564392" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 28 Apr 2008 10:50:44 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3SEof4F023086; Mon, 28 Apr 2008 10:50:41 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3SEofe3009126; Mon, 28 Apr 2008 14:50:41 GMT Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Apr 2008 10:50:41 -0400 Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Apr 2008 07:50:40 -0700 Received: from jmpolk-wxp.cisco.com ([64.101.170.120]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Apr 2008 07:50:39 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 28 Apr 2008 09:50:38 -0500 To: , From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 28 Apr 2008 14:50:39.0613 (UTC) FILETIME=[39B312D0:01C8A93F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1632; t=1209394241; x=1210258241; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Tsvwg]=20Emergency=20Services=20work=2 0in=20TSVWG |Sender:=20 |To:=20,=20; bh=C002h8f3fF+FDHG9s2tO/NmzMqsASAzZTjExw3zKoVU=; b=fMZlnelRUmGViG0r10F/Ztq8DPS6XeHvAR58myYlLQRm5h7s3B6i8oAvPz vkd9K1d92uAC+uCJ+uom2G+Z08/S5/zy3sksSJ0N3tAw0Z/PhAUq5p5GhCV1 BRaEv9aPwS; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: tsvwg@ietf.org Subject: Re: [Ecrit] [Tsvwg] Emergency Services work in TSVWG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hannes This isn't an NG-E911/112 style communication. It is a GETS style communication (it was more like what IEPREP would deal with). Thus, ECRIT isn't chartered for this, and therefore shouldn't worry about it. James At 05:47 AM 4/28/2008, hannes.tschofenig@nsn.com wrote: >Hi all, > >In a review of draft-ietf-tsvwg-emergency-rsvp-07.txt I got the >impression that the document is not only used for authority-to-authority >communication but also for citizen-to-authority communication. > >Here is my review comment: >" > * I think the document needs to indicate clearly that this >mechanism is supposed to be used for authority-to-authority emergency >services and not for citizen-to-authority/authority-to-citizen emergency >services. >" > >As a response I received: > >" >I would disagree. What you are asking for would be best placed in a >separate applicability draft. For instance, while I mostly agree with >your above assertion, I can also envision an exception in the case of >Japan's 911-like service, where preferential treatment is supported in >their PSTN for these types of many-to-1 call flows. Hence, more >elaborate discussions on use cases and applicability is really best >served in a different document. >" > >Now, I wonder whether the ECRIT WG is aware of the desire of some folks >in TSVWG to have these types of QoS mechanisms to go into >citizen-to-authority emergency services architecture? We are currently >finishing our architecture document and this document seems to touch >that space without being explicit. > >Thoughts? > >Ciao >Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 28 17:06:02 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0762A3A6B13; Mon, 28 Apr 2008 17:06:02 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C807B3A6B13; Mon, 28 Apr 2008 17:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6F2vcG27lYOf; Mon, 28 Apr 2008 17:05:59 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 9BB9C3A67E6; Mon, 28 Apr 2008 17:05:57 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JqdLw-00044N-F5; Mon, 28 Apr 2008 19:05:52 -0500 From: "Brian Rosen" To: "'ken carlberg'" , References: <5F8EDB43-8F83-49A0-A1BA-F841BD1C9395@g11.org.uk> Date: Mon, 28 Apr 2008 20:05:48 -0400 Message-ID: <000001c8a98c$ccf31f20$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcipKioY9ZtsS/3gR/6vUqnROXxopAAAYNZw In-Reply-To: <5F8EDB43-8F83-49A0-A1BA-F841BD1C9395@g11.org.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: ecrit@ietf.org, tsvwg@ietf.org Subject: Re: [Ecrit] [Tsvwg] Emergency Services work in TSVWG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Actually, in the Emergency Standards Coordination Workshop, we discussed this in two contexts. One was citizen to authority; the other was a response call from authority to citizen (a 1-1-2/9-1-1/... call back). We need a way to signal that the network should give priority to these calls. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of ken carlberg Sent: Monday, April 28, 2008 8:20 AM To: hannes.tschofenig@nsn.com Cc: ecrit@ietf.org; tsvwg@ietf.org Subject: Re: [Ecrit] [Tsvwg] Emergency Services work in TSVWG whoa, slow down a bit! On Apr 28, 2008, at 6:47 AM, wrote: > Hi all, > > In a review of draft-ietf-tsvwg-emergency-rsvp-07.txt I got the > impression that the document is not only used for authority-to- > authority > communication but also for citizen-to-authority communication. > > Here is my review comment: > " > * I think the document needs to indicate clearly that this > mechanism is supposed to be used for authority-to-authority emergency > services and not for citizen-to-authority/authority-to-citizen > emergency > services. > " > > As a response I received: > > " > I would disagree. What you are asking for would be best placed in a > separate applicability draft. For instance, while I mostly agree > with > your above assertion, I can also envision an exception in the case of > Japan's 911-like service, where preferential treatment is supported in > their PSTN for these types of many-to-1 call flows. Hence, more > elaborate discussions on use cases and applicability is really best > served in a different document. > " > > Now, I wonder whether the ECRIT WG is aware of the desire of some > folks > in TSVWG to have these types of QoS mechanisms to go into > citizen-to-authority emergency services architecture? We are currently > finishing our architecture document and this document seems to touch > that space without being explicit. Please *carefully* note that in my response on the tsvwg list I said "...I can also envision..." ^ ^^ in no way did I state any desire or advocacy, one way or the other, to see the proposed extension used for citizen-to-authority emergency services. I'm agnostic in that regard, and I want the cited tsvwg draft to remain that way. And as I also stated above, its up to another document outside of the cited tsvwg draft to discuss its applicability -- in the context of this note, that would be the ECRIT architecture draft. if pressed on the matter, I would initially advocate a position that the draft-ietf-tsvwg-emergency-rsvp-07.txt MAY be used for citizen- to-authority emergency services. But I haven't followed ECRIT very closely of late, so I'll certainly defer to the consensus of others actively participating in the ECRIT architecture document. cheers, -ken _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 29 01:42:17 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CAB328C0EC; Tue, 29 Apr 2008 01:42:17 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D25013A69E1; Tue, 29 Apr 2008 01:42:14 -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 SuQ8yW8va75w; Tue, 29 Apr 2008 01:42:11 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 04EF33A6C80; Tue, 29 Apr 2008 01:42:10 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3T8fdj2010474; Tue, 29 Apr 2008 11:42:06 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Apr 2008 11:41:53 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Apr 2008 11:41:52 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Apr 2008 11:41:51 +0300 Message-ID: In-Reply-To: <000001c8a98c$ccf31f20$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Tsvwg] Emergency Services work in TSVWG Thread-Index: AcipKioY9ZtsS/3gR/6vUqnROXxopAAAYNZwACpH7qA= References: <5F8EDB43-8F83-49A0-A1BA-F841BD1C9395@g11.org.uk> <000001c8a98c$ccf31f20$640fa8c0@cis.neustar.com> From: To: , X-OriginalArrivalTime: 29 Apr 2008 08:41:52.0657 (UTC) FILETIME=[DF6B4810:01C8A9D4] X-Nokia-AV: Clean Cc: ecrit@ietf.org, tsvwg@ietf.org Subject: Re: [Ecrit] [Tsvwg] Emergency Services work in TSVWG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Brian, This is a different discussion. You are referring to the discussion around call marking and not QoS signaling at the network layer using RSVP. Ciao Hannes >-----Original Message----- >From: ext Brian Rosen [mailto:br@brianrosen.net] >Sent: 29 April, 2008 03:06 >To: 'ken carlberg'; Tschofenig Hannes (NSN - FI/Espoo) >Cc: ecrit@ietf.org; tsvwg@ietf.org >Subject: RE: [Ecrit] [Tsvwg] Emergency Services work in TSVWG > >Actually, in the Emergency Standards Coordination Workshop, we >discussed this in two contexts. One was citizen to authority; >the other was a response call from authority to citizen (a >1-1-2/9-1-1/... call back). We need a way to signal that the >network should give priority to these calls. > >Brian > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ken carlberg >Sent: Monday, April 28, 2008 8:20 AM >To: hannes.tschofenig@nsn.com >Cc: ecrit@ietf.org; tsvwg@ietf.org >Subject: Re: [Ecrit] [Tsvwg] Emergency Services work in TSVWG > >whoa, slow down a bit! > >On Apr 28, 2008, at 6:47 AM, wrote: >> Hi all, >> >> In a review of draft-ietf-tsvwg-emergency-rsvp-07.txt I got the >> impression that the document is not only used for authority-to- >> authority communication but also for citizen-to-authority >> communication. >> >> Here is my review comment: >> " >> * I think the document needs to indicate clearly that >this mechanism >> is supposed to be used for authority-to-authority emergency services >> and not for citizen-to-authority/authority-to-citizen >> emergency >> services. >> " >> >> As a response I received: >> >> " >> I would disagree. What you are asking for would be best placed in a >> separate applicability draft. For instance, while I mostly agree >> with >> your above assertion, I can also envision an exception in >the case of >> Japan's 911-like service, where preferential treatment is >supported in >> their PSTN for these types of many-to-1 call flows. Hence, more >> elaborate discussions on use cases and applicability is really best >> served in a different document. >> " >> >> Now, I wonder whether the ECRIT WG is aware of the desire of some >> folks in TSVWG to have these types of QoS mechanisms to go into >> citizen-to-authority emergency services architecture? We are >currently >> finishing our architecture document and this document seems to touch >> that space without being explicit. > >Please *carefully* note that in my response on the tsvwg list >I said "...I can also envision..." > >^ >^^ >in no way did I state any desire or advocacy, one way or the >other, to see the proposed extension used for >citizen-to-authority emergency services. I'm agnostic in that >regard, and I want the cited tsvwg >draft to remain that way. And as I also stated above, its up to >another document outside of the cited tsvwg draft to discuss >its applicability -- in the context of this note, that would >be the ECRIT architecture draft. > >if pressed on the matter, I would initially advocate a >position that the draft-ietf-tsvwg-emergency-rsvp-07.txt MAY >be used for citizen- to-authority emergency services. But I >haven't followed ECRIT very closely of late, so I'll certainly >defer to the consensus of others actively participating in the >ECRIT architecture document. > >cheers, > >-ken > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 29 01:46:45 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69A363A6CAB; Tue, 29 Apr 2008 01:46:45 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB073A6C3D; Tue, 29 Apr 2008 01:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWZSe8RyRSBp; Tue, 29 Apr 2008 01:46:43 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 4000828C0EC; Tue, 29 Apr 2008 01:46:28 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3T8jj7q015638; Tue, 29 Apr 2008 11:46:07 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Apr 2008 11:46:06 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Apr 2008 11:46:06 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Apr 2008 11:46:04 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] Emergency Services work in TSVWG Thread-Index: AcipP0BETv9BmKTgS9OIXm3v4c7VbgAlbBQw References: From: To: , X-OriginalArrivalTime: 29 Apr 2008 08:46:06.0280 (UTC) FILETIME=[76971480:01C8A9D5] X-Nokia-AV: Clean Cc: tsvwg@ietf.org Subject: Re: [Ecrit] [Tsvwg] Emergency Services work in TSVWG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org That's what I thought. Maybe one should be clearly stating that since I could imagine that people reading the title and the content of the draft wouldn't get that idea. I am OK with the TSVWG working on solutions that will not really get deployed because of the huge deployment problems but I definitely don't want this to impact any of the work we do in ECRIT. Ciao Hannes >-----Original Message----- >From: ext James M. Polk [mailto:jmpolk@cisco.com] >Sent: 28 April, 2008 17:51 >To: Tschofenig Hannes (NSN - FI/Espoo); ecrit@ietf.org >Cc: tsvwg@ietf.org >Subject: Re: [Tsvwg] Emergency Services work in TSVWG > >Hannes > >This isn't an NG-E911/112 style communication. It is a GETS >style communication (it was more like what IEPREP would deal >with). Thus, ECRIT isn't chartered for this, and therefore >shouldn't worry about it. > >James > >At 05:47 AM 4/28/2008, hannes.tschofenig@nsn.com wrote: >>Hi all, >> >>In a review of draft-ietf-tsvwg-emergency-rsvp-07.txt I got the >>impression that the document is not only used for >>authority-to-authority communication but also for >citizen-to-authority communication. >> >>Here is my review comment: >>" >> * I think the document needs to indicate clearly that this >>mechanism is supposed to be used for authority-to-authority emergency >>services and not for citizen-to-authority/authority-to-citizen >>emergency services. >>" >> >>As a response I received: >> >>" >>I would disagree. What you are asking for would be best placed in a >>separate applicability draft. For instance, while I mostly >agree with >>your above assertion, I can also envision an exception in the case of >>Japan's 911-like service, where preferential treatment is >supported in >>their PSTN for these types of many-to-1 call flows. Hence, more >>elaborate discussions on use cases and applicability is really best >>served in a different document. >>" >> >>Now, I wonder whether the ECRIT WG is aware of the desire of >some folks >>in TSVWG to have these types of QoS mechanisms to go into >>citizen-to-authority emergency services architecture? We are >currently >>finishing our architecture document and this document seems to touch >>that space without being explicit. >> >>Thoughts? >> >>Ciao >>Hannes > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 29 01:49:28 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40BC3A6CAA; Tue, 29 Apr 2008 01:49:28 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED1F3A6C7A; Tue, 29 Apr 2008 01:49:27 -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 OIu9j3aDIA0t; Tue, 29 Apr 2008 01:49:26 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 120603A6B03; Tue, 29 Apr 2008 01:49:25 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3T8n590010242; Tue, 29 Apr 2008 11:49:16 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Apr 2008 11:49:15 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Apr 2008 11:49:14 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Apr 2008 11:49:14 +0300 Message-ID: In-Reply-To: <5F8EDB43-8F83-49A0-A1BA-F841BD1C9395@g11.org.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] Emergency Services work in TSVWG Thread-Index: AcipKiRrWYHqgS18Q0KUb8P1oFHy7gAqzafQ References: <5F8EDB43-8F83-49A0-A1BA-F841BD1C9395@g11.org.uk> From: To: X-OriginalArrivalTime: 29 Apr 2008 08:49:14.0848 (UTC) FILETIME=[E6FC4600:01C8A9D5] X-Nokia-AV: Clean Cc: ecrit@ietf.org, tsvwg@ietf.org Subject: Re: [Ecrit] [Tsvwg] Emergency Services work in TSVWG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Ken, I would be very happy if you could state explicitly that you want to use the mechanisms in that document for authority-to-authority type of emergency services rather than for other types of emergency services. For citizien-to-authority I definitely see a lot of problems and regarding early warning (authority-to-citizen) we haven't even worked on the architecture and therefore it is very hard to tell how it would be used -- we will see in the future. Ciao Hannes >-----Original Message----- >From: ext ken carlberg [mailto:carlberg@g11.org.uk] >Sent: 28 April, 2008 15:20 >To: Tschofenig Hannes (NSN - FI/Espoo) >Cc: ecrit@ietf.org; tsvwg@ietf.org >Subject: Re: [Tsvwg] Emergency Services work in TSVWG > >whoa, slow down a bit! > >On Apr 28, 2008, at 6:47 AM, wrote: >> Hi all, >> >> In a review of draft-ietf-tsvwg-emergency-rsvp-07.txt I got the >> impression that the document is not only used for authority-to- >> authority communication but also for citizen-to-authority >> communication. >> >> Here is my review comment: >> " >> * I think the document needs to indicate clearly that >this mechanism >> is supposed to be used for authority-to-authority emergency services >> and not for citizen-to-authority/authority-to-citizen >> emergency >> services. >> " >> >> As a response I received: >> >> " >> I would disagree. What you are asking for would be best placed in a >> separate applicability draft. For instance, while I mostly agree >> with >> your above assertion, I can also envision an exception in >the case of >> Japan's 911-like service, where preferential treatment is >supported in >> their PSTN for these types of many-to-1 call flows. Hence, more >> elaborate discussions on use cases and applicability is really best >> served in a different document. >> " >> >> Now, I wonder whether the ECRIT WG is aware of the desire of some >> folks in TSVWG to have these types of QoS mechanisms to go into >> citizen-to-authority emergency services architecture? We are >currently >> finishing our architecture document and this document seems to touch >> that space without being explicit. > >Please *carefully* note that in my response on the tsvwg list >I said "...I can also envision..." > > ^ ^^ in no >way did I state any desire or advocacy, one way or the other, >to see the proposed extension used for citizen-to-authority >emergency services. I'm agnostic in that regard, and I want >the cited tsvwg >draft to remain that way. And as I also stated above, its up to >another document outside of the cited tsvwg draft to discuss >its applicability -- in the context of this note, that would >be the ECRIT architecture draft. > >if pressed on the matter, I would initially advocate a >position that the draft-ietf-tsvwg-emergency-rsvp-07.txt MAY >be used for citizen- to-authority emergency services. But I >haven't followed ECRIT very closely of late, so I'll certainly >defer to the consensus of others actively participating in the >ECRIT architecture document. > >cheers, > >-ken > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 29 04:59:24 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9630A28C176; Tue, 29 Apr 2008 04:59:24 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FACE3A6CE3 for ; Tue, 29 Apr 2008 04:59:22 -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 rbHxUHVHFIlE for ; Tue, 29 Apr 2008 04:59:17 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 37B9728C18C for ; Tue, 29 Apr 2008 04:59:16 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id KN1x1Z0050FhH24A90Dq00; Tue, 29 Apr 2008 11:59:06 +0000 Received: from [192.168.1.120] ([69.255.78.171]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id KPzF1Z0073hlvrZ8U00000; Tue, 29 Apr 2008 11:59:16 +0000 X-Authority-Analysis: v=1.0 c=1 a=HfJckuaRj20IwLXMkh8A:9 a=Xd9CGJ3VhZv12pT69l0d_thM6FcA:4 a=2uiCRmbCp6AA:10 Message-Id: <7F76FF71-3527-4890-9AE8-3B01DB685045@g11.org.uk> From: ken carlberg To: hannes.tschofenig@nsn.com Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 29 Apr 2008 07:59:15 -0400 X-Mailer: Apple Mail (2.919.2) Cc: ecrit@ietf.org Subject: [Ecrit] terminology question X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hannes, my apologies for the mundane question (and if I missed it in some document), but I just wanted to chase down a question of terminology for the sake of preciseness. within the scope of ECRIT, how are you defining civilian and authority when using the terms civilian-to-authority and authority-to-authority? for me, I gravitate to civilian = general public, and authority are people working on behalf of the government (Federal, state, local, tribal) for the common good. Examples of "authority" in the ECRIT perspective would be fireman, police, dispatchers, even militia (e.g., National Guard that gets mobilized during disasters). On the other hand, I wouldn't characterize those that work for vendors, ISPs, the PSTN as "authority". Would you agree with this perspective? -ken _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 29 06:18:32 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 425E03A6D56; Tue, 29 Apr 2008 06:18:32 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A7D13A6782 for ; Tue, 29 Apr 2008 06:18: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 P-DWzNcnnze4 for ; Tue, 29 Apr 2008 06:18:28 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 53F0D3A6D75 for ; Tue, 29 Apr 2008 06:18:26 -0700 (PDT) Received: (qmail invoked by alias); 29 Apr 2008 13:18:29 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp023) with SMTP; 29 Apr 2008 15:18:29 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18KYSB0CA4Kzb70geStpSEbAizKSSx3+Wc+Ql4OUs BKqiEn8JC6fOYe Message-ID: <48172025.4070601@gmx.net> Date: Tue, 29 Apr 2008 16:18:29 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: 'ECRIT' X-Y-GMX-Trusted: 0 Subject: [Ecrit] Early Warning Mailing List X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org We have created a new mailing list for discussions on early warning for you. https://www.ietf.org/mailman/listinfo/earlywarning Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 29 07:10:36 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 403DF3A6CFE; Tue, 29 Apr 2008 07:10:36 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261F628C16E for ; Tue, 29 Apr 2008 07:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCJ4QCR2Uvn2 for ; Tue, 29 Apr 2008 07:10:29 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 512513A69D2 for ; Tue, 29 Apr 2008 07:10:28 -0700 (PDT) Received: (qmail invoked by alias); 29 Apr 2008 14:10:31 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp052) with SMTP; 29 Apr 2008 16:10:31 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19xXqw6YmVxyrffr5VnmXQn8+iQOxk9pxU0HrpqdD s2D1p1xpFlJ4Fi Message-ID: <48172C56.9000606@gmx.net> Date: Tue, 29 Apr 2008 17:10:30 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Henning Schulzrinne References: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> <012a01c89f04$b2f25290$6901a8c0@cis.neustar.com> <4804C34C.2060508@bbn.com> <019c01c89f21$a5de8520$6901a8c0@cis.neustar.com> <4804F51D.6000700@bbn.com> In-Reply-To: X-Y-GMX-Trusted: 0 Cc: 'ECRIT' Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The problem here is again LoST usage for emergency services and LoST usage for other services. For the emergency services context I would put a MUST instead of the SHOULD. For a pizza service I would even put a MAY in there. Brian, are you happy to put an adjusted version of Richard's proposal + Henning's improvements into the document? Ciao Hannes Henning Schulzrinne wrote: > Standard beef: A requirement with lots of SHOULD is useless. > > On Apr 15, 2008, at 2:34 PM, Richard Barnes wrote: > >>> Generally, I think all LoST contents should be alike. >>> I think it's preferable for the access network to provide the >>> pointer to the >>> LoST service. If there is some local routing issue, it's the >>> access network >>> that has the best information. >>> >> Is that a requirement that should be added into phonebcp/framework? >> E.g., >> >> " >> ED-* When an endpoint has obtained a LoST server via an discovery >> mechanism (e.g., via the DNS [ref] or DHCP [ref]), it SHOULD prefer >> the >> discovered LoST server over LoST servers configured by other means. >> That is, the endpoint SHOULD send queries to this LoST server, using >> other LoST servers only if these queries fail. >> " >> >> --RB >> >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 29 07:32:17 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D230628C138; Tue, 29 Apr 2008 07:32:17 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF4F28C112 for ; Tue, 29 Apr 2008 07:32:16 -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 GcuySya63b31 for ; Tue, 29 Apr 2008 07:32:10 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 9B2F33A6CCB for ; Tue, 29 Apr 2008 07:32:10 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JqqsK-0004T3-FB; Tue, 29 Apr 2008 09:32:08 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'Henning Schulzrinne'" References: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> <012a01c89f04$b2f25290$6901a8c0@cis.neustar.com> <4804C34C.2060508@bbn.com> <019c01c89f21$a5de8520$6901a8c0@cis.neustar.com> <4804F51D.6000700@bbn.com> <48172C56.9000606@gmx.net> Date: Tue, 29 Apr 2008 10:32:09 -0400 Message-ID: <00ee01c8aa05$d0a5bbe0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciqAswLbLP87d1oTmK0DLsrc2+GyQAAsY1g In-Reply-To: <48172C56.9000606@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yes, but we need to agree on MUST/SHOULD. -phonebcp is emergency service specific, so anything we say there is for the emergency service context. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, April 29, 2008 10:11 AM To: Henning Schulzrinne Cc: 'ECRIT' Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) The problem here is again LoST usage for emergency services and LoST usage for other services. For the emergency services context I would put a MUST instead of the SHOULD. For a pizza service I would even put a MAY in there. Brian, are you happy to put an adjusted version of Richard's proposal + Henning's improvements into the document? Ciao Hannes Henning Schulzrinne wrote: > Standard beef: A requirement with lots of SHOULD is useless. > > On Apr 15, 2008, at 2:34 PM, Richard Barnes wrote: > >>> Generally, I think all LoST contents should be alike. >>> I think it's preferable for the access network to provide the >>> pointer to the >>> LoST service. If there is some local routing issue, it's the >>> access network >>> that has the best information. >>> >> Is that a requirement that should be added into phonebcp/framework? >> E.g., >> >> " >> ED-* When an endpoint has obtained a LoST server via an discovery >> mechanism (e.g., via the DNS [ref] or DHCP [ref]), it SHOULD prefer >> the >> discovered LoST server over LoST servers configured by other means. >> That is, the endpoint SHOULD send queries to this LoST server, using >> other LoST servers only if these queries fail. >> " >> >> --RB >> >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 29 07:37:31 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D07C28C28C; Tue, 29 Apr 2008 07:37:31 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3453A68D8 for ; Tue, 29 Apr 2008 07:37: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=[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 atOQ5m7jhPJe for ; Tue, 29 Apr 2008 07:37:29 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9168D28C280 for ; Tue, 29 Apr 2008 07:37:28 -0700 (PDT) Received: (qmail invoked by alias); 29 Apr 2008 14:37:30 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp035) with SMTP; 29 Apr 2008 16:37:30 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+hucVMEdKhZfzbVMygwoqaYPnEDPTonD2zDqznX8 FoJoaeaAruR8N/ Message-ID: <481732A9.6070802@gmx.net> Date: Tue, 29 Apr 2008 17:37:29 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Brian Rosen References: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> <012a01c89f04$b2f25290$6901a8c0@cis.neustar.com> <4804C34C.2060508@bbn.com> <019c01c89f21$a5de8520$6901a8c0@cis.neustar.com> <4804F51D.6000700@bbn.com> <48172C56.9000606@gmx.net> <00ee01c8aa05$d0a5bbe0$640fa8c0@cis.neustar.com> In-Reply-To: <00ee01c8aa05$d0a5bbe0$640fa8c0@cis.neustar.com> X-Y-GMX-Trusted: 0 Cc: 'ECRIT' Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org What about the following proposal: ED-* When an endpoint has obtained a LoST server via the DHCP based discovery mechanism [ref] then it MUST prefer the discovered LoST server over LoST servers configured via other mechanisms. That is, the endpoint MUST send queries to this LoST server first before contacting other LoST servers only if queries to the locally discovered LoST servers fail. Ciao Hannes Brian Rosen wrote: > Yes, but we need to agree on MUST/SHOULD. -phonebcp is emergency service > specific, so anything we say there is for the emergency service context. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Tuesday, April 29, 2008 10:11 AM > To: Henning Schulzrinne > Cc: 'ECRIT' > Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) > > The problem here is again LoST usage for emergency services and LoST > usage for other services. > For the emergency services context I would put a MUST instead of the > SHOULD. > For a pizza service I would even put a MAY in there. > > Brian, are you happy to put an adjusted version of Richard's proposal + > Henning's improvements into the document? > > Ciao > Hannes > > Henning Schulzrinne wrote: > >> Standard beef: A requirement with lots of SHOULD is useless. >> >> On Apr 15, 2008, at 2:34 PM, Richard Barnes wrote: >> >> >>>> Generally, I think all LoST contents should be alike. >>>> I think it's preferable for the access network to provide the >>>> pointer to the >>>> LoST service. If there is some local routing issue, it's the >>>> access network >>>> that has the best information. >>>> >>>> >>> Is that a requirement that should be added into phonebcp/framework? >>> E.g., >>> >>> " >>> ED-* When an endpoint has obtained a LoST server via an discovery >>> mechanism (e.g., via the DNS [ref] or DHCP [ref]), it SHOULD prefer >>> the >>> discovered LoST server over LoST servers configured by other means. >>> That is, the endpoint SHOULD send queries to this LoST server, using >>> other LoST servers only if these queries fail. >>> " >>> >>> --RB >>> >>> >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 29 07:38:36 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34DD83A6D21; Tue, 29 Apr 2008 07:38:36 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D773C3A6CFA for ; Tue, 29 Apr 2008 07:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JG+JbQLjdTJE for ; Tue, 29 Apr 2008 07:38:31 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 11F4A3A6C19 for ; Tue, 29 Apr 2008 07:38:29 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m3TEcQmr018123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 29 Apr 2008 10:38:27 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <00ee01c8aa05$d0a5bbe0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 29 Apr 2008 10:38:26 -0400 References: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> <012a01c89f04$b2f25290$6901a8c0@cis.neustar.com> <4804C34C.2060508@bbn.com> <019c01c89f21$a5de8520$6901a8c0@cis.neustar.com> <4804F51D.6000700@bbn.com> <48172C56.9000606@gmx.net> <00ee01c8aa05$d0a5bbe0$640fa8c0@cis.neustar.com> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Cc: 'ECRIT' Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Unless we can formulate some reason, in general, as to why this behavior should differ, I'd go for MUST. In really special circumstances, implementors could presumably not use DHCP (or DNS) at all. On Apr 29, 2008, at 10:32 AM, Brian Rosen wrote: > Yes, but we need to agree on MUST/SHOULD. -phonebcp is emergency > service > specific, so anything we say there is for the emergency service > context. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of > Hannes Tschofenig > Sent: Tuesday, April 29, 2008 10:11 AM > To: Henning Schulzrinne > Cc: 'ECRIT' > Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) > > The problem here is again LoST usage for emergency services and LoST > usage for other services. > For the emergency services context I would put a MUST instead of the > SHOULD. > For a pizza service I would even put a MAY in there. > > Brian, are you happy to put an adjusted version of Richard's > proposal + > Henning's improvements into the document? > > Ciao > Hannes > > Henning Schulzrinne wrote: >> Standard beef: A requirement with lots of SHOULD is useless. >> >> On Apr 15, 2008, at 2:34 PM, Richard Barnes wrote: >> >>>> Generally, I think all LoST contents should be alike. >>>> I think it's preferable for the access network to provide the >>>> pointer to the >>>> LoST service. If there is some local routing issue, it's the >>>> access network >>>> that has the best information. >>>> >>> Is that a requirement that should be added into phonebcp/framework? >>> E.g., >>> >>> " >>> ED-* When an endpoint has obtained a LoST server via an discovery >>> mechanism (e.g., via the DNS [ref] or DHCP [ref]), it SHOULD prefer >>> the >>> discovered LoST server over LoST servers configured by other means. >>> That is, the endpoint SHOULD send queries to this LoST server, using >>> other LoST servers only if these queries fail. >>> " >>> >>> --RB >>> >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 29 07:41:00 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 656B73A6C2B; Tue, 29 Apr 2008 07:41:00 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E76213A6C2B for ; Tue, 29 Apr 2008 07:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 lXNL0o952Czl for ; Tue, 29 Apr 2008 07:40:56 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id A6AFD3A6B5B for ; Tue, 29 Apr 2008 07:40:55 -0700 (PDT) Received: (qmail invoked by alias); 29 Apr 2008 14:40:58 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp002) with SMTP; 29 Apr 2008 16:40:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/LL8ZeISXLy81dVFPeK1aEvBEx6NA4kUdxNKYNuf +7yrXauAji2SIr Message-ID: <48173379.300@gmx.net> Date: Tue, 29 Apr 2008 17:40:57 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Henning Schulzrinne References: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> <012a01c89f04$b2f25290$6901a8c0@cis.neustar.com> <4804C34C.2060508@bbn.com> <019c01c89f21$a5de8520$6901a8c0@cis.neustar.com> <4804F51D.6000700@bbn.com> <48172C56.9000606@gmx.net> <00ee01c8aa05$d0a5bbe0$640fa8c0@cis.neustar.com> In-Reply-To: X-Y-GMX-Trusted: 0 Cc: 'ECRIT' Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If developers cannot use DHCP for some reason or DHCP does not return any LoST servers then one has to fallback to other mechanisms, such as manual configuration or DNS. Btw, we do not provide a way to discover local LoST servers using DNS without also using the DHCP discovery mechanism. Henning Schulzrinne wrote: > Unless we can formulate some reason, in general, as to why this > behavior should differ, I'd go for MUST. In really special > circumstances, implementors could presumably not use DHCP (or DNS) at > all. > > On Apr 29, 2008, at 10:32 AM, Brian Rosen wrote: > >> Yes, but we need to agree on MUST/SHOULD. -phonebcp is emergency >> service >> specific, so anything we say there is for the emergency service context. >> >> Brian >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf Of >> Hannes Tschofenig >> Sent: Tuesday, April 29, 2008 10:11 AM >> To: Henning Schulzrinne >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) >> >> The problem here is again LoST usage for emergency services and LoST >> usage for other services. >> For the emergency services context I would put a MUST instead of the >> SHOULD. >> For a pizza service I would even put a MAY in there. >> >> Brian, are you happy to put an adjusted version of Richard's proposal + >> Henning's improvements into the document? >> >> Ciao >> Hannes >> >> Henning Schulzrinne wrote: >>> Standard beef: A requirement with lots of SHOULD is useless. >>> >>> On Apr 15, 2008, at 2:34 PM, Richard Barnes wrote: >>> >>>>> Generally, I think all LoST contents should be alike. >>>>> I think it's preferable for the access network to provide the >>>>> pointer to the >>>>> LoST service. If there is some local routing issue, it's the >>>>> access network >>>>> that has the best information. >>>>> >>>> Is that a requirement that should be added into phonebcp/framework? >>>> E.g., >>>> >>>> " >>>> ED-* When an endpoint has obtained a LoST server via an discovery >>>> mechanism (e.g., via the DNS [ref] or DHCP [ref]), it SHOULD prefer >>>> the >>>> discovered LoST server over LoST servers configured by other means. >>>> That is, the endpoint SHOULD send queries to this LoST server, using >>>> other LoST servers only if these queries fail. >>>> " >>>> >>>> --RB >>>> >>>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 29 07:42:49 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35AB728C254; Tue, 29 Apr 2008 07:42:49 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26B7528C26D for ; Tue, 29 Apr 2008 07:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXrVPkE+r-n8 for ; Tue, 29 Apr 2008 07:42:44 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 2DE5428C254 for ; Tue, 29 Apr 2008 07:42:44 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m3TEggMH021193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 29 Apr 2008 10:42:42 -0400 (EDT) Message-Id: <169691C0-6A01-43DC-B525-D538321ED70E@cs.columbia.edu> From: Henning Schulzrinne To: Hannes Tschofenig In-Reply-To: <481732A9.6070802@gmx.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 29 Apr 2008 10:42:42 -0400 References: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> <012a01c89f04$b2f25290$6901a8c0@cis.neustar.com> <4804C34C.2060508@bbn.com> <019c01c89f21$a5de8520$6901a8c0@cis.neustar.com> <4804F51D.6000700@bbn.com> <48172C56.9000606@gmx.net> <00ee01c8aa05$d0a5bbe0$640fa8c0@cis.neustar.com> <481732A9.6070802@gmx.net> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Cc: 'ECRIT' Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Sounds ok to me. I think this can be shortened: If an endpoint has discovered a LoST server via DHCP [ref], it MUST query that LoST server first. The end point only queries other LoST servers, such as those configured manually, if that query failed. On Apr 29, 2008, at 10:37 AM, Hannes Tschofenig wrote: > What about the following proposal: > > ED-* When an endpoint has obtained a LoST server via the DHCP based > discovery mechanism [ref] then it MUST prefer the discovered LoST > server over LoST servers configured via other mechanisms. That is, > the endpoint MUST send queries to this LoST server first before > contacting other LoST servers only if queries to the locally > discovered LoST servers fail. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 29 07:42:57 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D0F528C1A9; Tue, 29 Apr 2008 07:42:57 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 861A73A6CFA; Tue, 29 Apr 2008 07:42:56 -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 KoD1wBJkKwZQ; Tue, 29 Apr 2008 07:42:51 -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 05A8C3A6B5B; Tue, 29 Apr 2008 07:42:51 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 29 Apr 2008 07:42:54 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3TEgsE0025471; Tue, 29 Apr 2008 07:42:54 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m3TEgsNr007783; Tue, 29 Apr 2008 14:42:54 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Apr 2008 07:42:54 -0700 Received: from jmpolk-wxp.cisco.com ([64.101.170.119]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Apr 2008 07:42:53 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 29 Apr 2008 09:42:53 -0500 To: , From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 29 Apr 2008 14:42:54.0044 (UTC) FILETIME=[4E9CA1C0:01C8AA07] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=526; t=1209480174; x=1210344174; 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[Tsvwg]=20Emergency=20Services=20work=2 0in=20TSVWG |Sender:=20; bh=FZt5asRFoi1odIuHjXGiS7UznLHN1S/EePNvzAd5tMw=; b=K6uhlEDAWTZU026IO9ayfP4dYk4HXbH7IHecnIoPqSjAlo9GS0myvmvlcM 79nZY0RA6TxDYxVd6ULX1mG3gIXNQi//4IA+uNKvNnhUEeyuVnkuppJvxNms W+rAmZT5XKKldn0IOeZzpuwwf6dG3T7+3GiYT0f8fN7NiNK4ZmPyE=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: tsvwg@ietf.org Subject: Re: [Ecrit] [Tsvwg] Emergency Services work in TSVWG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 03:46 AM 4/29/2008, hannes.tschofenig@nsn.com wrote: >I am OK with the TSVWG working on solutions that will not really get >deployed that's your opinion, but - at least in North America - I think this will be deployed. Are you familiar with either http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-proxy-approaches/ or http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-proxy-proto/ ? This relieves the endpoint from having to support RSVP to get RSVP deployed... this makes things easier James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 29 08:04:34 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C77BE3A6DF1; Tue, 29 Apr 2008 08:04:34 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D972828C34E; Tue, 29 Apr 2008 08:04:28 -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 TBEOLR+tBvDG; Tue, 29 Apr 2008 08:04:08 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A5B3928C0D0; Tue, 29 Apr 2008 08:02:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,723,1199692800"; d="scan'208";a="24397832" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 29 Apr 2008 08:02:59 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3TF2wNQ012832; Tue, 29 Apr 2008 08:02:58 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m3TF32Mj026142; Tue, 29 Apr 2008 15:03:02 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Apr 2008 08:02:58 -0700 Received: from jmpolk-wxp.cisco.com ([64.101.170.119]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Apr 2008 08:02:58 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 29 Apr 2008 10:03:01 -0500 To: , From: "James M. Polk" In-Reply-To: References: <5F8EDB43-8F83-49A0-A1BA-F841BD1C9395@g11.org.uk> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 29 Apr 2008 15:02:58.0406 (UTC) FILETIME=[1C77B060:01C8AA0A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3814; t=1209481379; x=1210345379; 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[Tsvwg]=20Emergency=20Services=20work=2 0in=20TSVWG |Sender:=20; bh=r94osKqHBD20xpxnbKM6Zm8hteoCGWUkk65F07GUnZk=; b=W8TOUKJo0Edt6ner5ZU5VvTob+9RVS6qQKFpntZAdSpuHBzj/53zgwxk9w OiT842GOvxQwV4/iiVgSCsW7zLjqNBy3xMyuvYrnAeIhlIomAv1zd1Rjtwzi DMC5X9Zp8r3DBgGbn8C3RlhufqsV3zPnrJtqHJSdnZhxUPuFhaMIM=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: ecrit@ietf.org, tsvwg@ietf.org Subject: Re: [Ecrit] [Tsvwg] Emergency Services work in TSVWG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 03:49 AM 4/29/2008, hannes.tschofenig@nsn.com wrote: >Hi Ken, > >I would be very happy if you could state explicitly that you want to use >the mechanisms in that document for authority-to-authority type of >emergency services rather than for other types of emergency services. The abstract starts with "An Emergency Telecommunications Service (ETS)..." which means a GETS type of service, which clearly isn't C2A based, as evidenced by the references within the opening sentence of the Intro "[RFC3689] and [RFC3690] detail requirements for an Emergency Telecommunications Service (ETS)..." >For citizien-to-authority I definitely see a lot of problems and >regarding early warning (authority-to-citizen) we haven't even worked on >the architecture and therefore it is very hard to tell how it would be >used -- we will see in the future. > >Ciao >Hannes > > >-----Original Message----- > >From: ext ken carlberg [mailto:carlberg@g11.org.uk] > >Sent: 28 April, 2008 15:20 > >To: Tschofenig Hannes (NSN - FI/Espoo) > >Cc: ecrit@ietf.org; tsvwg@ietf.org > >Subject: Re: [Tsvwg] Emergency Services work in TSVWG > > > >whoa, slow down a bit! > > > >On Apr 28, 2008, at 6:47 AM, wrote: > >> Hi all, > >> > >> In a review of draft-ietf-tsvwg-emergency-rsvp-07.txt I got the > >> impression that the document is not only used for authority-to- > >> authority communication but also for citizen-to-authority > >> communication. > >> > >> Here is my review comment: > >> " > >> * I think the document needs to indicate clearly that > >this mechanism > >> is supposed to be used for authority-to-authority emergency services > >> and not for citizen-to-authority/authority-to-citizen > >> emergency > >> services. > >> " > >> > >> As a response I received: > >> > >> " > >> I would disagree. What you are asking for would be best placed in a > >> separate applicability draft. For instance, while I mostly agree > >> with > >> your above assertion, I can also envision an exception in > >the case of > >> Japan's 911-like service, where preferential treatment is > >supported in > >> their PSTN for these types of many-to-1 call flows. Hence, more > >> elaborate discussions on use cases and applicability is really best > >> served in a different document. > >> " > >> > >> Now, I wonder whether the ECRIT WG is aware of the desire of some > >> folks in TSVWG to have these types of QoS mechanisms to go into > >> citizen-to-authority emergency services architecture? We are > >currently > >> finishing our architecture document and this document seems to touch > >> that space without being explicit. > > > >Please *carefully* note that in my response on the tsvwg list > >I said "...I can also envision..." > > > > ^ ^^ in no > >way did I state any desire or advocacy, one way or the other, > >to see the proposed extension used for citizen-to-authority > >emergency services. I'm agnostic in that regard, and I want > >the cited tsvwg > >draft to remain that way. And as I also stated above, its up to > >another document outside of the cited tsvwg draft to discuss > >its applicability -- in the context of this note, that would > >be the ECRIT architecture draft. > > > >if pressed on the matter, I would initially advocate a > >position that the draft-ietf-tsvwg-emergency-rsvp-07.txt MAY > >be used for citizen- to-authority emergency services. But I > >haven't followed ECRIT very closely of late, so I'll certainly > >defer to the consensus of others actively participating in the > >ECRIT architecture document. > > > >cheers, > > > >-ken > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 29 09:31:00 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 564573A6E0F; Tue, 29 Apr 2008 09:31:00 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76FB23A6E0F for ; Tue, 29 Apr 2008 09:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgOTHZVGKHjh for ; Tue, 29 Apr 2008 09:30:58 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 0ED0A3A697F for ; Tue, 29 Apr 2008 09:30:58 -0700 (PDT) Received: from col-dhcp33-244-159.bbn.com ([128.33.244.159] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JqsjK-0002e8-4u; Tue, 29 Apr 2008 12:30:58 -0400 Message-ID: <48174D43.2030102@bbn.com> Date: Tue, 29 Apr 2008 12:30:59 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Henning Schulzrinne References: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> <012a01c89f04$b2f25290$6901a8c0@cis.neustar.com> <4804C34C.2060508@bbn.com> <019c01c89f21$a5de8520$6901a8c0@cis.neustar.com> <4804F51D.6000700@bbn.com> <48172C56.9000606@gmx.net> <00ee01c8aa05$d0a5bbe0$640fa8c0@cis.neustar.com> <481732A9.6070802@gmx.net> <169691C0-6A01-43DC-B525-D538321ED70E@cs.columbia.edu> In-Reply-To: <169691C0-6A01-43DC-B525-D538321ED70E@cs.columbia.edu> Cc: 'ECRIT' Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I second the MUST, given that these documents are emergency-specific. (E.g., it would not be appropriate in LoST itself.) --RB Henning Schulzrinne wrote: > Sounds ok to me. I think this can be shortened: > > If an endpoint has discovered a LoST server via DHCP [ref], it MUST > query that LoST server first. The end point only queries other LoST > servers, such as those configured manually, if that query failed. > > On Apr 29, 2008, at 10:37 AM, Hannes Tschofenig wrote: > >> What about the following proposal: >> >> ED-* When an endpoint has obtained a LoST server via the DHCP based >> discovery mechanism [ref] then it MUST prefer the discovered LoST >> server over LoST servers configured via other mechanisms. That is, >> the endpoint MUST send queries to this LoST server first before >> contacting other LoST servers only if queries to the locally >> discovered LoST servers fail. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 29 11:33:55 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C7783A6B4A; Tue, 29 Apr 2008 11:33:55 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD8823A6B4A for ; Tue, 29 Apr 2008 11:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 m88LDza60M-O for ; Tue, 29 Apr 2008 11:33:53 -0700 (PDT) Received: from aismt07p.bellsouth.com (aismt07p.bellsouth.com [139.76.165.213]) by core3.amsl.com (Postfix) with ESMTP id 5A6DD3A6A17 for ; Tue, 29 Apr 2008 11:33:53 -0700 (PDT) Received: from ([139.76.131.83]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.200725580; Tue, 29 Apr 2008 14:33:22 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 29 Apr 2008 14:33:22 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 29 Apr 2008 14:33:21 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Apr 2008 14:33:20 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA089FEECD@crexc41p> In-Reply-To: <48174D43.2030102@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Usage of service URN by enterprises (RFC 5031) thread-index: AciqFrZ/tmNbAjoZQ5GSxFUm5bBK0QADkKaw References: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> <012a01c89f04$b2f25290$6901a8c0@cis.neustar.com> <4804C34C.2060508@bbn.com> <019c01c89f21$a5de8520$6901a8c0@cis.neustar.com> <4804F51D.6000700@bbn.com> <48172C56.9000606@gmx.net> <00ee01c8aa05$d0a5bbe0$640fa8c0@cis.neustar.com> <481732A9.6070802@gmx.net><169691C0-6A01-43DC-B525-D538321ED70E@cs.columbia.edu> <48174D43.2030102@bbn.com> From: "Stark, Barbara" To: "Richard Barnes" , "Henning Schulzrinne" X-OriginalArrivalTime: 29 Apr 2008 18:33:21.0654 (UTC) FILETIME=[80827960:01C8AA27] Cc: ECRIT Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I've been thinking about this wording, and I think it needs one additional clause. It needs to be clear that this only applies to queries for sos urns. Although phonebcp is supposed to only be about emergency services, the requirement, as worded, could be misconstrued to apply to all service urns. I could easily imagine that a VSP has the phones they provide to their users configured to always query the VSP LoST server for the closest something-or-other. I'd rather not use language that could be interpreted as preventing this from happening. Maybe: If an endpoint has discovered a LoST server via DHCP [ref], it MUST query that LoST server first. The end point only queries other LoST servers, such as those configured manually, if that query failed. This requirement only applies to queries relating to emergency services, and not the use of LoST for other services. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Tuesday, April 29, 2008 12:31 PM To: Henning Schulzrinne Cc: 'ECRIT' Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) I second the MUST, given that these documents are emergency-specific. (E.g., it would not be appropriate in LoST itself.) --RB Henning Schulzrinne wrote: > Sounds ok to me. I think this can be shortened: > > If an endpoint has discovered a LoST server via DHCP [ref], it MUST > query that LoST server first. The end point only queries other LoST > servers, such as those configured manually, if that query failed. > > On Apr 29, 2008, at 10:37 AM, Hannes Tschofenig wrote: > >> What about the following proposal: >> >> ED-* When an endpoint has obtained a LoST server via the DHCP based >> discovery mechanism [ref] then it MUST prefer the discovered LoST >> server over LoST servers configured via other mechanisms. That is, >> the endpoint MUST send queries to this LoST server first before >> contacting other LoST servers only if queries to the locally >> discovered LoST servers fail. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 29 12:20:36 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7CF43A6DC3; Tue, 29 Apr 2008 12:20:36 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D75E28C2DA for ; Tue, 29 Apr 2008 12:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtjznFwgH2xr for ; Tue, 29 Apr 2008 12:20:35 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 39C343A6DD4 for ; Tue, 29 Apr 2008 12:20:35 -0700 (PDT) Received: from col-dhcp33-244-159.bbn.com ([128.33.244.159] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JqvNV-0007f2-5t; Tue, 29 Apr 2008 15:20:37 -0400 Message-ID: <48177504.1010501@bbn.com> Date: Tue, 29 Apr 2008 15:20:36 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Stark, Barbara" References: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> <012a01c89f04$b2f25290$6901a8c0@cis.neustar.com> <4804C34C.2060508@bbn.com> <019c01c89f21$a5de8520$6901a8c0@cis.neustar.com> <4804F51D.6000700@bbn.com> <48172C56.9000606@gmx.net> <00ee01c8aa05$d0a5bbe0$640fa8c0@cis.neustar.com> <481732A9.6070802@gmx.net><169691C0-6A01-43DC-B525-D538321ED70E@cs.columbia.edu> <48174D43.2030102@bbn.com> <7582BC68E4994F4ABF0BD4723975C3FA089FEECD@crexc41p> In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA089FEECD@crexc41p> Cc: ECRIT Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > I could easily imagine that a VSP has the phones they provide to their > users configured to always query the VSP LoST server for the closest > something-or-other. I'd rather not use language that could be > interpreted as preventing this from happening. Just to be clear, are you including emergency services in "something-or-other"? Because I think the gist of this requirement is that when the phone is looking for emergency service, it's not okay for it to always go to the VSP. This all seems consistent with your text below. > If an endpoint has discovered a LoST server via DHCP [ref], it MUST > query that LoST server first. The end point only queries other LoST > servers, such as those configured manually, if that query failed. This > requirement only applies to queries relating to emergency services, and > not the use of LoST for other services. That text looks fine to me. --RB Stark, Barbara wrote: > I've been thinking about this wording, and I think it needs one > additional clause. It needs to be clear that this only applies to > queries for sos urns. Although phonebcp is supposed to only be about > emergency services, the requirement, as worded, could be misconstrued to > apply to all service urns. > > I could easily imagine that a VSP has the phones they provide to their > users configured to always query the VSP LoST server for the closest > something-or-other. I'd rather not use language that could be > interpreted as preventing this from happening. > > Maybe: > If an endpoint has discovered a LoST server via DHCP [ref], it MUST > query that LoST server first. The end point only queries other LoST > servers, such as those configured manually, if that query failed. This > requirement only applies to queries relating to emergency services, and > not the use of LoST for other services. > > Barbara > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Richard Barnes > Sent: Tuesday, April 29, 2008 12:31 PM > To: Henning Schulzrinne > Cc: 'ECRIT' > Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) > > I second the MUST, given that these documents are emergency-specific. > (E.g., it would not be appropriate in LoST itself.) > > --RB > > > > Henning Schulzrinne wrote: >> Sounds ok to me. I think this can be shortened: >> >> If an endpoint has discovered a LoST server via DHCP [ref], it MUST >> query that LoST server first. The end point only queries other LoST >> servers, such as those configured manually, if that query failed. >> >> On Apr 29, 2008, at 10:37 AM, Hannes Tschofenig wrote: >> >>> What about the following proposal: >>> >>> ED-* When an endpoint has obtained a LoST server via the DHCP based >>> discovery mechanism [ref] then it MUST prefer the discovered LoST >>> server over LoST servers configured via other mechanisms. That is, >>> the endpoint MUST send queries to this LoST server first before >>> contacting other LoST servers only if queries to the locally >>> discovered LoST servers fail. >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > ***** > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 29 12:23:54 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9007D3A6DE7; Tue, 29 Apr 2008 12:23:54 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB43128C11E for ; Tue, 29 Apr 2008 12:23:53 -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 6UQ0ADFNAchM for ; Tue, 29 Apr 2008 12:23:52 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 4C21B3A6DE7 for ; Tue, 29 Apr 2008 12:23:52 -0700 (PDT) Received: from col-dhcp33-244-159.bbn.com ([128.33.244.159] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JqvQh-0007ip-4H; Tue, 29 Apr 2008 15:23:55 -0400 Message-ID: <481775CA.1040101@bbn.com> Date: Tue, 29 Apr 2008 15:23:54 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hannes Tschofenig References: <47FBBA34.1050704@gmx.net> In-Reply-To: <47FBBA34.1050704@gmx.net> Cc: Roger Hixson , ecrit@ietf.org Subject: Re: [Ecrit] NENA NG9-1-1 related Standard for review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Document: Functional and Interface Standards for Next Generation 9-1-1 = Version 1.0 (i3) Reviewer: Richard L. Barnes Date: 29 April, 2008 I have reviewed Sections 1, 2, 3, 4, 5.1, 5.2, 6, 7, 8, and 9 of this = document. It is basically technically sound, in that the architecture = it describes seems to meet the functional requirements of the NG9-1-1 = system. My major reservation is that the security requirements and = properties of this system are largely undefined and highly reliant on = perimeter defenses. Specific comments follow. Major technical comments: General: It is unclear in what manner ESInets are connected to each other, i.e., = at what layer they are peered. Is it intended that they be physically = connected (physical/link layer)? That they be connected at the IP layer = (e.g., over a tunnel or VPN)? Or that they exchange messages over = public IP networks? These choices have very different security = implications, so even if a single scheme is not chosen, there should be = a discussion of trade-offs. Section 4.2.5.3 says that they are = connected at the =93IP (router) level=94, but even then, it=92s not clear = whether the routers have to be physically connected or whether they can = have an IP network in between them. General: It=92s not clear what value the SOA sections (Section 4.6 and Section 6) = add to this document, since it seems like they are simply a recitation = of the Web Services canon. If the point is simply to say that web = service and corresponding discovery systems will be offered over the = ESInet, then that=92s what should be said. Note also that several of the = services described in Section 7 are not web services, e.g., the agency = registry (Section 7.6) is an LDAP service. General: Section 9 needs to be substantially reduced or eliminated. Without a = model for what security guarantees the system is to provide and how it = is to provide them (presumably the eventual contents of Section 4.7), = the list of technologies in Section 9 is useless. Moreover, by = presenting them without context, there is a risk that entities will = claim compliance with the =93i3 security model=94 without actually providin= g = the necessary security properties. Lines 768-733 (Section 4.2.1, paragraph starting =93While other standard = bodies=85=94) This distinction between the IETF and the 3GPP[2] is unnecessary. The = suite of protocols defined by the IETF is equally well suited to = proxy-based routing as to endpoint-based routing. Indeed, the IMS = architecture is based on these protocols. What should be here is a = discussion of the separation between AIP and CSP, which leads to a = requirement for the endpoint to be delivered location in certain = circumstances. Line 1147 (Section 4.3.3, paragraph starting =93The user initiates=85=94) This paragraph says that the UE =93evaluates the SIP URI=94 to recognize an = emergency call. What does this examination entail? Suggest changing = =93SIP URI=94 or =93Service URN=94. Line 1504 (Section 4.7) This section should at least define what it means by =93Security Domain=94 = in figure 4-19, e.g., by choosing one of the eight definitions in RFC = 4949. Any commentary on what security services are available within and = between domains would be helpful, as well as on the implications of = these choices. Line 1576 (Section 5.1.1) This section essentially specifies that BCFs will act as = application-layer gateways (ALGs) for SIP traffic. Experience in the = SIP community has shown that ALGs tend to reduce the reliability of call = establishment through them, so there is a risk that the use of BCFs in = this way could add brittleness to the ESInet. Note also that if the BCF = does not act as a back-to-back user agent (B2BUA), then BCF manipulation = of firewall rules is pointless, since media traffic will likely not pass = back through this BCF. Line 2423 (Section 7.4) Why is this service associated with the ECRF, instead of a location = function (LIS/LRF/LDF), or possibly a third party service (via UDDI)? = The point of delivery for this service should be left unspecified, as it = is for most other services here. Minor technical comments: Line 515 (Paragraph starting =93Calls will be multimedia=85=94) It should be clarified that the list of media types here is not = exhaustive; i.e., other media types might be added in the future. Line 522 (Section 4.1.2 Functional architecture) Location functions (LRF/LDF/LAF) are missing from this diagram. Should = they be illustrated in the access network? Line 577 (Location Validation Function) This bullet should make it clear that the MSAG is not present in this = architecture, and that the reference to it here is only for purposes of = analogy. (This is essentially what=92s in the footnote, but this is an = important point.) Line 670 (Section 4.1.4, paragraph starting =93This example physical = architecture=85=94) It would be helpful here to have a brief statement of how an ESNet = differs from an ESInet Line 808 (Section 4.2.1.1) The reference to the Revised Civic document should be to RFC 5139. Lines 1094-1097 (Section 4.3.2) E-CSCF: I was under the impression that the E-CSCF was intended to be = part of the access network (as opposed to part of the ESInet. S-CSCF: This term has not been defined in this section. I would have thought that the ESRP would behave like an I-CSCF, in that = it is a public-facing CSCF. Line 1144 (Figure 5-3) The IP-CAN line in this figure should be deleted. It=92s confusing that = only some of the lines where location is sent are so labeled; it should = be added where not present. Lines 1352, 1356 (Section 4.5.2, paragraph starting =93The LIS is = responsible=85=94) The term =93Phase II=94 has not been defined in this document. Lines 2435, 2449 (Section 7.6, 7.7) These sections use the all-caps words =93MUST=94. Is this word intended to = be used as in RFC 2119? If not, please change to lower/mixed caps; if = so, please include a reference to RFC 2119. Line 2654 (Section 9, first paragraph) Capitalization of =93IPSEC=94 should be =93IPsec=94. Editorial comments: Line 333 (Table of acronyms): In the definitions for 3GPP and 3GPP2, there=92s a discrepancy between 3rd = and 3RD. IETF working group names (e.g., ECRIT, GEOPRIV) should be capitalized. =93IPSec=94 should be capitalized as =93IPsec=94. Line 731 (Incident Identifier) The phrase =93URI GUID=94 is incorrect. It seems to me that it should = simply be a =93GUID=94, but if it=92s a URI encoding a GUID, then the corre= ct = phrase is =93GUID URI=94. Line 808 (Section 4.2.1.1) The hyphen in =93RFC-4119=94 should be deleted. Line 815 (Section 4.2.1.2, paragraph starting =93The construction=85=94) The phrase =93user part=94 should be deleted, since this term is not define= d = for many URI types. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 29 12:28:11 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE2703A6B52; Tue, 29 Apr 2008 12:28:11 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8383A6BA1 for ; Tue, 29 Apr 2008 12:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhi7Lh8OtLjn for ; Tue, 29 Apr 2008 12:28:09 -0700 (PDT) Received: from aismt07p.bellsouth.com (aismt07p.bellsouth.com [139.76.165.213]) by core3.amsl.com (Postfix) with ESMTP id EE8363A68ED for ; Tue, 29 Apr 2008 12:28:08 -0700 (PDT) Received: from ([139.76.131.83]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.200734450; Tue, 29 Apr 2008 15:27:52 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 29 Apr 2008 15:27:52 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 29 Apr 2008 15:27:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Apr 2008 15:27:48 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA089FEF0D@crexc41p> In-Reply-To: <48177504.1010501@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Usage of service URN by enterprises (RFC 5031) Thread-Index: AciqLionnWLh73ESR8633ZjvnJ5u5gAAH1fw References: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> <012a01c89f04$b2f25290$6901a8c0@cis.neustar.com> <4804C34C.2060508@bbn.com> <019c01c89f21$a5de8520$6901a8c0@cis.neustar.com> <4804F51D.6000700@bbn.com> <48172C56.9000606@gmx.net> <00ee01c8aa05$d0a5bbe0$640fa8c0@cis.neustar.com> <481732A9.6070802@gmx.net><169691C0-6A01-43DC-B525-D538321ED70E@cs.columbia.edu> <48174D43.2030102@bbn.com> <7582BC68E4994F4ABF0BD4723975C3FA089FEECD@crexc41p> <48177504.1010501@bbn.com> From: "Stark, Barbara" To: "Richard Barnes" X-OriginalArrivalTime: 29 Apr 2008 19:27:51.0455 (UTC) FILETIME=[1D7682F0:01C8AA2F] Cc: ECRIT Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org No, I was specifically not including emergency services in "something-or-other". Barbara -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com] Sent: Tuesday, April 29, 2008 3:21 PM To: Stark, Barbara Cc: Henning Schulzrinne; ECRIT Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) > I could easily imagine that a VSP has the phones they provide to their > users configured to always query the VSP LoST server for the closest > something-or-other. I'd rather not use language that could be > interpreted as preventing this from happening. Just to be clear, are you including emergency services in "something-or-other"? Because I think the gist of this requirement is that when the phone is looking for emergency service, it's not okay for it to always go to the VSP. This all seems consistent with your text below. > If an endpoint has discovered a LoST server via DHCP [ref], it MUST > query that LoST server first. The end point only queries other LoST > servers, such as those configured manually, if that query failed. This > requirement only applies to queries relating to emergency services, and > not the use of LoST for other services. That text looks fine to me. --RB Stark, Barbara wrote: > I've been thinking about this wording, and I think it needs one > additional clause. It needs to be clear that this only applies to > queries for sos urns. Although phonebcp is supposed to only be about > emergency services, the requirement, as worded, could be misconstrued to > apply to all service urns. > > I could easily imagine that a VSP has the phones they provide to their > users configured to always query the VSP LoST server for the closest > something-or-other. I'd rather not use language that could be > interpreted as preventing this from happening. > > Maybe: > If an endpoint has discovered a LoST server via DHCP [ref], it MUST > query that LoST server first. The end point only queries other LoST > servers, such as those configured manually, if that query failed. This > requirement only applies to queries relating to emergency services, and > not the use of LoST for other services. > > Barbara > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Richard Barnes > Sent: Tuesday, April 29, 2008 12:31 PM > To: Henning Schulzrinne > Cc: 'ECRIT' > Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) > > I second the MUST, given that these documents are emergency-specific. > (E.g., it would not be appropriate in LoST itself.) > > --RB > > > > Henning Schulzrinne wrote: >> Sounds ok to me. I think this can be shortened: >> >> If an endpoint has discovered a LoST server via DHCP [ref], it MUST >> query that LoST server first. The end point only queries other LoST >> servers, such as those configured manually, if that query failed. >> >> On Apr 29, 2008, at 10:37 AM, Hannes Tschofenig wrote: >> >>> What about the following proposal: >>> >>> ED-* When an endpoint has obtained a LoST server via the DHCP based >>> discovery mechanism [ref] then it MUST prefer the discovered LoST >>> server over LoST servers configured via other mechanisms. That is, >>> the endpoint MUST send queries to this LoST server first before >>> contacting other LoST servers only if queries to the locally >>> discovered LoST servers fail. >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > ***** > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 29 13:24:49 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8503A6A7D; Tue, 29 Apr 2008 13:24:49 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB45D3A63D3 for ; Tue, 29 Apr 2008 13:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, STOX_REPLY_TYPE=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 P3URRcCXK1Wo for ; Tue, 29 Apr 2008 13:24:47 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by core3.amsl.com (Postfix) with ESMTP id DCE7B3A6AD8 for ; Tue, 29 Apr 2008 13:24:46 -0700 (PDT) Received: from s73602 ([12.164.125.206]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1JqwNb2gnm-0002LU; Tue, 29 Apr 2008 16:24:49 -0400 Message-ID: <02e301c8aa37$44407fa0$6fa7df0a@china.huawei.com> From: "Spencer Dawkins" To: "ECRIT" References: <5D1A7985295922448D5550C94DE2918001E21FBC@DEEXC1U01.de.lucent.com> <012a01c89f04$b2f25290$6901a8c0@cis.neustar.com> <4804C34C.2060508@bbn.com> <019c01c89f21$a5de8520$6901a8c0@cis.neustar.com> <4804F51D.6000700@bbn.com> <48172C56.9000606@gmx.net> <00ee01c8aa05$d0a5bbe0$640fa8c0@cis.neustar.com> <481732A9.6070802@gmx.net><169691C0-6A01-43DC-B525-D538321ED70E@cs.columbia.edu><48174D43.2030102@bbn.com><7582BC68E4994F4ABF0BD4723975C3FA089FEECD@crexc41p> <48177504.1010501@bbn.com> Date: Tue, 29 Apr 2008 16:26:06 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX18fww21ZcJxr7agnt6qknXYrVDF5fbBVpNdQh3 tXSJK6BSiowPBOHjbelKr7529TCqhbZKn5HV8yDkgEkFDVwiv6 blZ8z6DBOqvvdn06c7eBzecoFC8ZfCHvEO4toS20kw= Subject: Re: [Ecrit] Usage of service URN by enterprises (RFC 5031) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Just popping in here with an editorial suggestion... > > If an endpoint has discovered a LoST server via DHCP [ref], it MUST > > query that LoST server first. The end point only queries other LoST > > servers, such as those configured manually, if that query failed. This > > requirement only applies to queries relating to emergency services, and > > not the use of LoST for other services. > > That text looks fine to me. The text looks fine to me technically, but it seems to "hide" the point - "MUST query LoST server discovered via DHCP first for all queries relating to emergency services", if I'm understanding this thread. I'd suggest inverting as If an endpoint has discovered a LoST server via DHCP [ref], it MUST query that LoST server first, for all queries relating to emergency services. The endpoint only queries other LoST servers, such as those configured manually, if that query fails. This requirement does not apply to the use of LoST for non-emergency services. Thanks, Spencer _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 30 03:42:06 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C67283A6B7C; Wed, 30 Apr 2008 03:42:06 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CD2A3A6DB6; Wed, 30 Apr 2008 03:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vszMjRIzJFkX; Wed, 30 Apr 2008 03:42:03 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id A225528C379; Wed, 30 Apr 2008 03:41:08 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m3UAfAgo024100; Wed, 30 Apr 2008 05:41:10 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Apr 2008 05:41:09 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Apr 2008 12:41:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 12:41:06 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001E99973@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Tsvwg] Emergency Services work in TSVWG Thread-Index: AciqCnUyBr9NUhixRLyWfs+NE1NPYwAD+MTw References: <5F8EDB43-8F83-49A0-A1BA-F841BD1C9395@g11.org.uk> From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 30 Apr 2008 10:41:07.0784 (UTC) FILETIME=[B29EC480:01C8AAAE] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: ecrit@ietf.org, tsvwg@ietf.org Subject: Re: [Ecrit] [Tsvwg] Emergency Services work in TSVWG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Slightly tongue in cheek, but the point is real. Hannes, Perhaps you should also be clarifying in all the drafts produced by ECRIT that the communication is citizen to authority, as exactly the same confusion of terminology appears there. I understand the taxonomy of emergency calls is generally subdivided as follows: - citizen to authority - authority to authority - authority to citizen All of these can be referred to emergency calls. Regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of James M. Polk > Sent: Tuesday, April 29, 2008 4:03 PM > To: hannes.tschofenig@nsn.com; carlberg@g11.org.uk > Cc: ecrit@ietf.org; tsvwg@ietf.org > Subject: Re: [Ecrit] [Tsvwg] Emergency Services work in TSVWG > > At 03:49 AM 4/29/2008, hannes.tschofenig@nsn.com wrote: > >Hi Ken, > > > >I would be very happy if you could state explicitly that you want to > >use the mechanisms in that document for > authority-to-authority type of > >emergency services rather than for other types of emergency services. > > The abstract starts with > > "An Emergency Telecommunications Service (ETS)..." > which means a GETS type of service, which clearly isn't C2A > based, as evidenced by the references within the opening > sentence of the Intro > > "[RFC3689] and > [RFC3690] detail > requirements for > an Emergency Telecommunications Service (ETS)..." > > > >For citizien-to-authority I definitely see a lot of problems and > >regarding early warning (authority-to-citizen) we haven't > even worked on > >the architecture and therefore it is very hard to tell how > it would be > >used -- we will see in the future. > > > >Ciao > >Hannes > > > > >-----Original Message----- > > >From: ext ken carlberg [mailto:carlberg@g11.org.uk] > > >Sent: 28 April, 2008 15:20 > > >To: Tschofenig Hannes (NSN - FI/Espoo) > > >Cc: ecrit@ietf.org; tsvwg@ietf.org > > >Subject: Re: [Tsvwg] Emergency Services work in TSVWG > > > > > >whoa, slow down a bit! > > > > > >On Apr 28, 2008, at 6:47 AM, wrote: > > >> Hi all, > > >> > > >> In a review of draft-ietf-tsvwg-emergency-rsvp-07.txt I got the > > >> impression that the document is not only used for authority-to- > > >> authority communication but also for citizen-to-authority > > >> communication. > > >> > > >> Here is my review comment: > > >> " > > >> * I think the document needs to indicate clearly that > > >this mechanism > > >> is supposed to be used for authority-to-authority > emergency services > > >> and not for citizen-to-authority/authority-to-citizen > > >> emergency > > >> services. > > >> " > > >> > > >> As a response I received: > > >> > > >> " > > >> I would disagree. What you are asking for would be best > placed in a > > >> separate applicability draft. For instance, while I > mostly agree > > >> with > > >> your above assertion, I can also envision an exception in > > >the case of > > >> Japan's 911-like service, where preferential treatment is > > >supported in > > >> their PSTN for these types of many-to-1 call flows. Hence, more > > >> elaborate discussions on use cases and applicability is > really best > > >> served in a different document. > > >> " > > >> > > >> Now, I wonder whether the ECRIT WG is aware of the desire of some > > >> folks in TSVWG to have these types of QoS mechanisms to go into > > >> citizen-to-authority emergency services architecture? We are > > >currently > > >> finishing our architecture document and this document > seems to touch > > >> that space without being explicit. > > > > > >Please *carefully* note that in my response on the tsvwg list > > >I said "...I can also envision..." > > > > > > ^ ^^ in no > > >way did I state any desire or advocacy, one way or the other, > > >to see the proposed extension used for citizen-to-authority > > >emergency services. I'm agnostic in that regard, and I want > > >the cited tsvwg > > >draft to remain that way. And as I also stated above, its up to > > >another document outside of the cited tsvwg draft to discuss > > >its applicability -- in the context of this note, that would > > >be the ECRIT architecture draft. > > > > > >if pressed on the matter, I would initially advocate a > > >position that the draft-ietf-tsvwg-emergency-rsvp-07.txt MAY > > >be used for citizen- to-authority emergency services. But I > > >haven't followed ECRIT very closely of late, so I'll certainly > > >defer to the consensus of others actively participating in the > > >ECRIT architecture document. > > > > > >cheers, > > > > > >-ken > > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 30 12:27:08 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F93D28C181; Wed, 30 Apr 2008 12:27:08 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3587428C181 for ; Wed, 30 Apr 2008 12:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9S4iCKjmJZx9 for ; Wed, 30 Apr 2008 12:27:03 -0700 (PDT) Received: from zrtps0kn.us.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 35B9A28C1C3 for ; Wed, 30 Apr 2008 12:26:09 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kn.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3UJQ9u25242 for ; Wed, 30 Apr 2008 19:26:09 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 15:26:07 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646515C588CE@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Callbacks and phonebcp Thread-Index: Aciq+An/HeuMv5JNSLOHHzLJ4yVarQ== From: "Perry Prozeniuk" To: Subject: [Ecrit] Callbacks and phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1205073405==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1205073405== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AAF8.0A80213D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AAF8.0A80213D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As part of the NENA CPE IP Capable PSAP working group we have been looking into the SIP callback information and how the PSAP will use this. =20 In phonebcp, following references are found: =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 3. The From header MUST be present and SHOULD be the AoR of the caller. ... 6. A Contact header MUST be present which MUST be globally routable, for example a GRUU [I-D.ietf-sip-gruu], to permit an immediate call-back to the specific device which placed the emergency call. =20 And a little later: 5. Either a P-Asserted-Identity [RFC3325] or an Identity header [RFC4474], or both, MUST be included to identify the sender. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Specifically in reference to (6) above, I believe that there is a potential issue. The statement that the contact header MUST be globally routable is not sufficient. It MUST also be usable for a period of time after the call completes. =20 =20 If one looks at a situation where there is a Session Border Controller (SBC) between the SIP phone and the PSAP, the SBC may replace the contact header with a temporary address that although is globally routable is ONLY valid for the duration of the call. A GRUU would satisfy both of these conditions, however so would any other globally routable SIP URI for the originating phone that remained valid after the call completion. A GRUU would be preferred. =20 I am suggesting the the wording be strengthened somewhat to ensure that the Contact URI MUST be usable for callback for a short period of time after the call completes (e.g. a few minutes) and the a GRUU SHOULD be specified. =20 Of course if the phone is disconnected, etc then the contact may not be usable at all after the call and the other address fields (e.g. the AOR) will need to be used for callback which may or may not reach the caller directly. In most cases the phone will remain operational following the call completion and the contact information should allow the originating phone to be reached directly. =20 Perry =20 ------_=_NextPart_001_01C8AAF8.0A80213D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
As = part of the NENA=20 CPE IP Capable PSAP working group we have been looking into the SIP = callback information and how the PSAP will use this.
 
In = phonebcp,=20 following references are found:
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
   3.   The From header MUST be present = and=20 SHOULD be the AoR of the
       =20 caller.
…
   6.   A Contact header MUST be = present which=20 MUST be globally
        routable, for = example a=20 GRUU [I-D.ietf-sip-gruu], to permit an
        immediate = call-back to the=20 specific device which placed the
        emergency=20 call.
 
And a=20 little later:
   5.  Either a P-Asserted-Identity = [RFC3325] or an=20 Identity header
       [RFC4474], or both, = MUST be=20 included to identify the sender.
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Specifically in=20 reference to (6) above, I believe that there is a potential issue.  = The=20 statement that the contact header MUST be globally routable is not=20 sufficient.  It MUST also be usable for a period of time after the = call=20 completes. 
 
If one = looks at a=20 situation where there is a Session Border Controller (SBC) between the = SIP phone=20 and the PSAP, the SBC may replace the contact header with a temporary = address=20 that although is globally routable is ONLY valid for the duration of the = call.  A GRUU would satisfy both of these conditions, however so = would any=20 other globally routable SIP URI for the originating phone that remained = valid=20 after the call completion.  A GRUU would be = preferred.
 
 I am=20 suggesting the the wording be strengthened somewhat to ensure that the = Contact=20 URI MUST be usable for callback for a short period of time after the = call=20 completes (e.g. a few minutes) and the a GRUU SHOULD=20 be specified.
 
Of = course if the=20 phone is disconnected, etc then the contact may not be usable at all = after the=20 call and the other address fields (e.g. the AOR) will need to be used = for=20 callback which may or may not reach the caller directly.  In most = cases the=20 phone will remain operational following the call completion and the = contact=20 information should allow the originating phone to be reached=20 directly.
 
Perry
 
------_=_NextPart_001_01C8AAF8.0A80213D-- --===============1205073405== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1205073405==-- From ecrit-bounces@ietf.org Thu May 1 01:56:04 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49DD728C356; Thu, 1 May 2008 01:56:04 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99FB93A6B28 for ; Thu, 1 May 2008 01:56:02 -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.037, 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 ugDFdtfrr+Db for ; Thu, 1 May 2008 01:55:56 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id A1C5728C359 for ; Thu, 1 May 2008 01:55:56 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m418tl2F022010; Thu, 1 May 2008 03:55:53 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 May 2008 03:55:49 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 May 2008 10:55:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 May 2008 10:55:45 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001ED6E43@DEEXC1U01.de.lucent.com> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646515C588CE@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Callbacks and phonebcp Thread-Index: Aciq+An/HeuMv5JNSLOHHzLJ4yVarQAcNEhQ References: <9671A92C3C8B5744BC97F855F7CB646515C588CE@zcarhxm1.corp.nortel.com> From: "DRAGE, Keith \(Keith\)" To: "Perry Prozeniuk" , X-OriginalArrivalTime: 01 May 2008 08:55:46.0998 (UTC) FILETIME=[258D1D60:01C8AB69] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [Ecrit] Callbacks and phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0174741362==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0174741362== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AB69.251D4222" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AB69.251D4222 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is no point in writing a MUST unless you tell us what the period of time is. How can I assess the conformance without knowing that value. We have certainly been round that loop in 3GPP and noone has been able to specify how long after the initial call a callback must be possible. =20 Further this is a set of CPE requirements, and the CPE does not have complete control over whether the Contact header remains valid. =20 regards =20 Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Perry Prozeniuk Sent: Wednesday, April 30, 2008 8:26 PM To: ecrit@ietf.org Subject: [Ecrit] Callbacks and phonebcp =09 =09 As part of the NENA CPE IP Capable PSAP working group we have been looking into the SIP callback information and how the PSAP will use this. =20 In phonebcp, following references are found: =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 3. The From header MUST be present and SHOULD be the AoR of the caller. ... 6. A Contact header MUST be present which MUST be globally routable, for example a GRUU [I-D.ietf-sip-gruu], to permit an immediate call-back to the specific device which placed the emergency call. =20 And a little later: 5. Either a P-Asserted-Identity [RFC3325] or an Identity header [RFC4474], or both, MUST be included to identify the sender. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Specifically in reference to (6) above, I believe that there is a potential issue. The statement that the contact header MUST be globally routable is not sufficient. It MUST also be usable for a period of time after the call completes. =20 =20 If one looks at a situation where there is a Session Border Controller (SBC) between the SIP phone and the PSAP, the SBC may replace the contact header with a temporary address that although is globally routable is ONLY valid for the duration of the call. A GRUU would satisfy both of these conditions, however so would any other globally routable SIP URI for the originating phone that remained valid after the call completion. A GRUU would be preferred. =20 I am suggesting the the wording be strengthened somewhat to ensure that the Contact URI MUST be usable for callback for a short period of time after the call completes (e.g. a few minutes) and the a GRUU SHOULD be specified. =20 Of course if the phone is disconnected, etc then the contact may not be usable at all after the call and the other address fields (e.g. the AOR) will need to be used for callback which may or may not reach the caller directly. In most cases the phone will remain operational following the call completion and the contact information should allow the originating phone to be reached directly. =20 Perry =20 ------_=_NextPart_001_01C8AB69.251D4222 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There is no point in writing a MUST unless you = tell us what=20 the period of time is. How can I assess the conformance without knowing = that=20 value. We have certainly been round that loop in 3GPP and noone has been = able to=20 specify how long after the initial call a callback must be=20 possible.
 
Further this is a set of CPE requirements, and = the CPE does=20 not have complete control over whether the Contact header remains=20 valid.
 
regards
 
Keith

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Perry=20 Prozeniuk
Sent: Wednesday, April 30, 2008 8:26 = PM
To:=20 ecrit@ietf.org
Subject: [Ecrit] Callbacks and=20 phonebcp

As = part of the=20 NENA CPE IP Capable PSAP working group we have been looking into = the SIP=20 callback information and how the PSAP will use = this.
 
In = phonebcp,=20 following references are found:
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
   3.   The From header MUST be = present and=20 SHOULD be the AoR of the
       =20 caller.
…
   6.   A Contact header MUST be = present which=20 MUST be globally
        routable, for = example a=20 GRUU [I-D.ietf-sip-gruu], to permit an
        immediate = call-back to=20 the specific device which placed the
        emergency=20 call.
 
And a=20 little later:
   5.  Either a P-Asserted-Identity = [RFC3325] or an=20 Identity header
       [RFC4474], or both, = MUST be=20 included to identify the sender.
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Specifically in=20 reference to (6) above, I believe that there is a potential = issue.  The=20 statement that the contact header MUST be globally routable is not=20 sufficient.  It MUST also be usable for a period of time after = the call=20 completes. 
 
If = one looks at a=20 situation where there is a Session Border Controller (SBC) between the = SIP=20 phone and the PSAP, the SBC may replace the contact header with a = temporary=20 address that although is globally routable is ONLY valid for the = duration of=20 the call.  A GRUU would satisfy both of these conditions, however = so=20 would any other globally routable SIP URI for the originating phone = that=20 remained valid after the call completion.  A GRUU would be=20 preferred.
 
 I am=20 suggesting the the wording be strengthened somewhat to ensure that the = Contact=20 URI MUST be usable for callback for a short period of time after the = call=20 completes (e.g. a few minutes) and the a GRUU SHOULD=20 be specified.
 
Of = course if the=20 phone is disconnected, etc then the contact may not be usable at all = after the=20 call and the other address fields (e.g. the AOR) will need to be used = for=20 callback which may or may not reach the caller directly.  In most = cases=20 the phone will remain operational following the call completion and = the=20 contact information should allow the originating phone to be reached=20 directly.
 
Perry
 
------_=_NextPart_001_01C8AB69.251D4222-- --===============0174741362== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============0174741362==--