From shida@agnada.com Fri Dec 31 03:18:55 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0E743A68F9 for ; Fri, 31 Dec 2010 03:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myCpnLiSxxTv for ; Fri, 31 Dec 2010 03:18:54 -0800 (PST) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [69.56.148.12]) by core3.amsl.com (Postfix) with SMTP id 3BCF73A68FD for ; Fri, 31 Dec 2010 03:18:54 -0800 (PST) Received: (qmail 12061 invoked from network); 31 Dec 2010 11:20:03 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway13.websitewelcome.com with SMTP; 31 Dec 2010 11:20:03 -0000 Received: from [124.81.255.50] (port=49202 helo=[172.10.10.89]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PYd2Y-0000Ty-Ei; Fri, 31 Dec 2010 05:20:59 -0600 From: Shida Schubert Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Dec 2010 19:21:02 +0800 Message-Id: To: rai@ietf.org, ecrit@ietf.org, Henning Schulzrinne , Andrea G Forte , Marc Linsner Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - agnada.com X-Mailman-Approved-At: Mon, 03 Jan 2011 05:32:34 -0800 Subject: [Ecrit] RAI-ART review for draft-forte-lost-extensions-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 11:18:55 -0000 I am the assigned RAI-ART reviewer for = draft-forte-lost-extensions-02.txt. For background on RAI-ART, please see the FAQ at = . Please resolve these comments along with any other comments you may = receive. *** This draft is basically ready for publication, but has nits that should = be fixed before publication. *** I am sending the nits to the authors so I am sending few technical = concerns I have on the lists. ** Comments on the draft ** 0. This draft alters a definition of region for non-emergency = services, should this be=20 updating the RFC5222 in anyway? I am not sure if it should as = emergency case=20 is obviously the main user of the protocol but will this be the = case, say in 5 years?=20 1. Looking at the definition of "query" in RFC5222, the draft is not = really defining=20 a new queries but defining a filter to limit the results. I don't = feel that term =20 "queries" for this extension defined in this draft is appropriate. = I apologize for not being=20 able to come up with a proposal but "query" just didn't sound = right..=20 2. The draft clearly states that these extensions are NOT applicable to = the=20 emergency uses. If that is the case the draft should probably say = that it MUST NOT be=20 used in emergency cases somewhere in the draft, especially if it = has negative=20 implication (I couldn't think of any but..).=20 3. is used when you want to query the LoST server to find a = service=20 that serves the requesting entity's location but default behavior = of LoST as=20 defined in RFC5222 is to conduct a query based on the region so = this seems=20 tad bit odd to me. Especially because when is absent, one = is supposed=20 to conduct a search based on the distance from the user but it = should be the=20 other way around. Either say that when is absent it is = assumed true=20 or define alternative element which describes that it's for doing = a "instance within=20 X distance". ** General comments about the use of LoST for service other than = emergency ** I think this draft highlights lack of consideration during the creation = of LoST generic uses=20 beside emergency services and this raises some concerns not necessary = with this draft=20 but with the generic use of LoST in general.=20 1. When LoST server is used for generic uses, I believe the server will = be stressed a lot=20 more than when used for Emergency cases due to unique computation = required for=20 querying users's location to service region of the service or = searching for services=20 within distance X. I just hope that encouraging=20 the use of LoST for generic uses will not interfere with the = Emergency service in anyway..=20 I am assuming that in real deployment, the LoST server that handles = the initial request=20 will probably dispatch or redirect the request to appropriate = server that can handle the=20 requested service, so LoST serve that will handle the mapping of = location to PSAP will=20 not be overwhelmed by trying to figure out what pizza delivery is = close to Joe's current=20 location.=20 2. Although, I am assuming most or all of the remaining queries will = function as=20 defined in RFC5222, I think we should probably look at how the rest = of the=20 query beside will look like and behave when used for = generic uses.=20 e.g.=20 How useful is the listservice / listserviceresponse in generic uses = as is now?=20 >> Should there be an extension to query with a = filter so=20 only a sub-element will be displayed (querying the LoST = server with=20 urn:service:restaurants or urn:service:stores? =20 This has nothing to do with the draft in question.. But something we = may want to=20 think about if we are going to encourage people to implement LoST = for non-emergency services. Regards Shida=20= From iesg-secretary@ietf.org Mon Jan 10 11:55:11 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33F2D3A6B11; Mon, 10 Jan 2011 11:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 4Z0kWYruflBM; Mon, 10 Jan 2011 11:55:10 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBE8B28C0F4; Mon, 10 Jan 2011 11:55:09 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110110195509.23834.1939.idtracker@localhost> Date: Mon, 10 Jan 2011 11:55:09 -0800 Cc: ecrit chair , Internet Architecture Board , ecrit mailing list , RFC Editor Subject: [Ecrit] Document Action: 'LoST Service List Boundary Extension' to Experimental RFC (draft-ietf-ecrit-lost-servicelistboundary-05.txt) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:55:11 -0000 The IESG has approved the following document: - 'LoST Service List Boundary Extension' (draft-ietf-ecrit-lost-servicelistboundary-05.txt) as an Experimental RFC This document is the product of the Emergency Context Resolution with Internet Technologies Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-servicelistboundary/ Technical Summary LoST maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a query to the LoST server. However, the LoST server, in its response, does not provide context information, that is, it does not provide any additional information about the geographical region for which the returned list of services is considered valid within. Therefore, this document proposes a Service List Boundary that returns a local context along with the list of services returned, in order to assist the client to not miss a change in available services when moving. Working Group Summary There is consensus in the working group that this document adds useful functionality to the LoST protocol. Document Quality The document has been reviewed by key participants from the ECRIT working group and from the APP area XML-DIR. Personnel Richard Barnes is the document shepherd. Robert Sparks is the responsible AD. RFC Editor Note (Applies to -05) 1. In the abstract the document starts with LoST, Please expand to Location-to-Service Translation 2. At the end of section 3.2 - Replace the first instance of getServiceListBoundary with getServiceBoundary as follows: OLD: Note: since LoST does not define an attribute to indicate which location profile the clients understands in a request, this document also does not define one for the request. NEW: Note: since LoST does not define an attribute to indicate which location profile the clients understands in a request, this document also does not define one for the request. 3. In the second to last paragraph of section 3.2 - OLD: Therefore the 'serviceListKey' is a random token with at least 128 bits of entropy and can be assumed globally unique. NEW: Therefore the 'serviceListKey' is a random token with at least 128 bits of entropy [RFC4086] and can be assumed globally unique. 4. Add as a normative reference: [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. From andreaf@cs.columbia.edu Mon Jan 10 13:29:15 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31573A6802; Mon, 10 Jan 2011 13:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkNFspgN75Y8; Mon, 10 Jan 2011 13:29:14 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id 1B30F3A67EE; Mon, 10 Jan 2011 13:29:14 -0800 (PST) Received: from irtdesk1.cs.columbia.edu (irtdesk1.cs.columbia.edu [128.59.22.127]) (user=agf2104 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p0ALVOJj008300 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 10 Jan 2011 16:31:25 -0500 (EST) Message-ID: <4D2B7AAC.2080100@cs.columbia.edu> Date: Mon, 10 Jan 2011 16:31:24 -0500 From: Andrea G Forte User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Shida Schubert References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: rai@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] RAI-ART review for draft-forte-lost-extensions-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:29:16 -0000 Please read comments inline. Thanks, -Andrea On 12/31/10 6:26 AM, Shida Schubert wrote: > I am the assigned RAI-ART reviewer for draft-forte-lost-extensions-02.txt. > > For background on RAI-ART, please see the FAQ at. > > Please resolve these comments along with any other comments you may receive. > > *** > This draft is basically ready for publication, but has nits that should be fixed before publication. > *** > > I am sending the nits to the authors so I am sending few technical concerns I have on the lists. > > ** Comments on the draft ** > > 0. This draft alters a definition of region for non-emergency services, should this be > updating the RFC5222 in anyway? I am not sure if it should as emergency case > is obviously the main user of the protocol but will this be the case, say in 5 years? I do not have any particular position on this. > 1. Looking at the definition of "query" in RFC5222, the draft is not really defining > a new queries but defining a filter to limit the results. I don't feel that term > "queries" for this extension defined in this draft is appropriate. I apologize for not being > able to come up with a proposal but "query" just didn't sound right.. I do not agree with this. A filter as such, is applied on a number of existing results to further constrain them based on some metric. In this case, we do not have a pre-existing set of results that we are filtering, here we "ask" the server a more specific question and the server replies with the results fulfilling this specific question. In RFC 5222 it reads: "The query message carries location information and a service identifier encoded as a Uniform Resource Name (URN) (see [9]) from the LoST client to the LoST server. The LoST server uses its database to map the input values to one or more Uniform Resource Identifiers (URIs) and returns those URIs along with optional information, such as hints about the service boundary, in a response message to the LoST client." This is true also for our new queries. Can you please let me know where in RFC 5222 you see a definition of query that is in contrast with what we define in the draft? > 2. The draft clearly states that these extensions are NOT applicable to the > emergency uses. If that is the case the draft should probably say that it MUST NOT be > used in emergency cases somewhere in the draft, especially if it has negative > implication (I couldn't think of any but..). OK, we will add the MUST NOT. > 3. is used when you want to query the LoST server to find a service > that serves the requesting entity's location but default behavior of LoST as > defined in RFC5222 is to conduct a query based on the region so this seems > tad bit odd to me. Especially because when is absent, one is supposed > to conduct a search based on the distance from the user but it should be the > other way around. Either say that when is absent it is assumed true > or define alternative element which describes that it's for doing a "instance within > X distance". Yes, to have a more consistent behavior between emergency and non-emergency services, we can say that when is absent, it is assumed to be true rather than false. > ** General comments about the use of LoST for service other than emergency ** > > I think this draft highlights lack of consideration during the creation of LoST generic uses > beside emergency services and this raises some concerns not necessary with this draft > but with the generic use of LoST in general. > > 1. When LoST server is used for generic uses, I believe the server will be stressed a lot > more than when used for Emergency cases due to unique computation required for > querying users's location to service region of the service or searching for services > within distance X. I just hope that encouraging > the use of LoST for generic uses will not interfere with the Emergency service in anyway.. > I am assuming that in real deployment, the LoST server that handles the initial request > will probably dispatch or redirect the request to appropriate server that can handle the > requested service, so LoST serve that will handle the mapping of location to PSAP will > not be overwhelmed by trying to figure out what pizza delivery is close to Joe's current > location. In real deployments I do not think that LoST servers in the ESInet will be available also for non-emergency services. I think that access to the ESInet will be granted only for serving emergency queries or perhaps other government-related needs. > > > 2. Although, I am assuming most or all of the remaining queries will function as > defined in RFC5222, I think we should probably look at how the rest of the > query beside will look like and behave when used for generic uses. > > e.g. > How useful is the listservice / listserviceresponse in generic uses as is now? >>> Should there be an extension to query with a filter so > only a sub-element will be displayed (querying the LoST server with > urn:service:restaurants or urn:service:stores? > > This has nothing to do with the draft in question.. But something we may want to > think about if we are going to encourage people to implement LoST for non-emergency services. > > Regards > Shida From dmarnold@verizon.net Thu Jan 13 07:34:28 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF7D3A6BA4; Thu, 13 Jan 2011 07:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 QdIVdHGYp6-k; Thu, 13 Jan 2011 07:34:25 -0800 (PST) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by core3.amsl.com (Postfix) with ESMTP id 2E2E93A69B9; Thu, 13 Jan 2011 07:34:25 -0800 (PST) Received: from ArmstrongLaptop3786f509e ([unknown] [173.65.80.75]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LEY00IRAWP7EQK4@vms173005.mailsrvcs.net>; Thu, 13 Jan 2011 09:36:45 -0600 (CST) From: "Delaine M Arnold ENP" To: "Delaine M Arnold ENP" Date: Thu, 13 Jan 2011 10:36:42 -0500 Message-id: <004a01cbb337$ae70eac0$0b52c040$@net> MIME-version: 1.0 Content-type: multipart/alternative; boundary="----=_NextPart_000_004B_01CBB30D.C59AE2C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcuzN5dVDQm5Y51wSByKs12YIGsSZw== Content-language: en-us X-Mailman-Approved-At: Thu, 13 Jan 2011 07:37:50 -0800 Subject: [Ecrit] NENA ICE 4: Call Routing Based on LoST Hierarchy X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dmarnold@verizon.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 15:34:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_004B_01CBB30D.C59AE2C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The NG9-1-1 Industry Collaboration Events Steering Committee is pleased to announce that Jason Horning, Chair, and Bill Mertka, Vice Chair, will lead NENA's ICE 4 Planning Committee. ICE 4 will test call routing based on LoST hierarchy. For more information about how to join the ICE 4 Planning Committee and learn about NENA NG9-1-1 Industry Collaboration Events click here or contact Delaine Arnold. Thank you, Delaine --------------------------------------- Delaine M. Arnold, ENP NENA Industry Collaboration Event (ICE) Testing Coordination Manager Chair, NENA Data Technical Committee Voice: 813-960-1698 Cell: 813-928-1692 Email: dmarnold@verizon.net "Life is not measured by the breaths we take, but by the moments that take our breath away." ------=_NextPart_000_004B_01CBB30D.C59AE2C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The NG9-1-1 Industry Collaboration Events = Steering Committee is pleased to announce that Jason Horning, Chair, and = Bill Mertka, Vice Chair, will lead NENA’s ICE 4 Planning = Committee. ICE 4 will test call routing based on LoST hierarchy. = For more information about how to join the ICE 4 Planning Committee = and learn about NENA NG9-1-1 Industry Collaboration Events click here or contact Delaine = Arnold. 

 

Thank = you,

Delaine

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

Delaine M. Arnold, ENP

NENA Industry Collaboration Event (ICE) Testing Coordination Manager

Chair, NENA Data Technical Committee

Voice:  813-960-1698

Cell:     813-928-1692

Email:  dmarnold@verizon.net

 

"Life = is not measured by the breaths we take, but by the moments that = take our breath away." 

 

 

 

------=_NextPart_000_004B_01CBB30D.C59AE2C0-- From dmarnold@verizon.net Thu Jan 13 07:47:33 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8449D3A6BA8 for ; Thu, 13 Jan 2011 07:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, 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 KWqO0PJu-Pwc for ; Thu, 13 Jan 2011 07:47:29 -0800 (PST) Received: from vms173011pub.verizon.net (vms173011pub.verizon.net [206.46.173.11]) by core3.amsl.com (Postfix) with ESMTP id 535EA3A6BA7 for ; Thu, 13 Jan 2011 07:47:29 -0800 (PST) Received: from ArmstrongLaptop3786f509e ([unknown] [173.65.80.75]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LEY00BE8XB0AY30@vms173011.mailsrvcs.net> for ecrit@ietf.org; Thu, 13 Jan 2011 09:49:49 -0600 (CST) From: "Delaine M Arnold ENP" To: Date: Thu, 13 Jan 2011 10:49:47 -0500 Message-id: <009f01cbb339$81c4feb0$854efc10$@net> MIME-version: 1.0 Content-type: multipart/alternative; boundary="----=_NextPart_000_00A0_01CBB30F.98EEF6B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcuzN5dVDQm5Y51wSByKs12YIGsSZwAADFYQAABqLqA= Content-language: en-us Subject: [Ecrit] NENA ICE 4: Call Routing Based on LoST Hierarchy X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dmarnold@verizon.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 15:47:33 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00A0_01CBB30F.98EEF6B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The NG9-1-1 Industry Collaboration Events Steering Committee is pleased to announce that Jason Horning, Chair, and Bill Mertka, Vice Chair, will lead NENA's ICE 4 Planning Committee. ICE 4 will test call routing based on LoST hierarchy. For more information about how to join the ICE 4 Planning Committee and learn about NENA NG9-1-1 Industry Collaboration Events click here or contact Delaine Arnold. Thank you, Delaine --------------------------------------- Delaine M. Arnold, ENP NENA Industry Collaboration Event (ICE) Testing Coordination Manager Chair, NENA Data Technical Committee Voice: 813-960-1698 Cell: 813-928-1692 Email: dmarnold@verizon.net "Life is not measured by the breaths we take, but by the moments that take our breath away." ------=_NextPart_000_00A0_01CBB30F.98EEF6B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The NG9-1-1 Industry Collaboration Events = Steering Committee is pleased to announce that Jason Horning, Chair, and = Bill Mertka, Vice Chair, will lead NENA’s ICE 4 Planning = Committee. ICE 4 will test call routing based on LoST hierarchy. = For more information about how to join the ICE 4 Planning Committee = and learn about NENA NG9-1-1 Industry Collaboration Events click here or contact Delaine = Arnold. 

 

Thank = you,

Delaine

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

Delaine M. Arnold, ENP

NENA Industry Collaboration Event (ICE) Testing Coordination Manager

Chair, NENA Data Technical Committee

Voice:  813-960-1698

Cell:     813-928-1692

Email:  dmarnold@verizon.net

 

"Life = is not measured by the breaths we take, but by the moments that = take our breath away." 

 

 

 

------=_NextPart_000_00A0_01CBB30F.98EEF6B0-- From rbarnes@bbn.com Fri Jan 14 12:52:56 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6FE43A6C8D for ; Fri, 14 Jan 2011 12:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 aYGPntrOklxN for ; Fri, 14 Jan 2011 12:52:55 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id AA1F63A6A85 for ; Fri, 14 Jan 2011 12:52:52 -0800 (PST) Received: from [128.89.253.189] (port=62743 helo=[192.168.1.16]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Pdqg2-0008Wx-Gm for ecrit@ietf.org; Fri, 14 Jan 2011 15:55:18 -0500 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jan 2011 15:55:14 -0500 Message-Id: To: ecrit Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [Ecrit] Comment on draft-ietf-ecrit-unauthenticated-access X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 20:52:57 -0000 In Section 5, step 2, this document says that the ISP informs the = calling device about its local ESRP via DHCP. This seems incorrect, not = least because there is no DHCP option defined to carry this sort of = information. =20 It seems to me that in order to minimize the divergence from the normal = procedure, step 2 should have the network providing the client access to = location (HELD/DHCP-location) and LoST servers, then connecting to the = ESRP. --Richard= From br@brianrosen.net Fri Jan 14 13:03:37 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA043A6C91 for ; Fri, 14 Jan 2011 13:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.348 X-Spam-Level: X-Spam-Status: No, score=-103.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 im9jS4xGwDep for ; Fri, 14 Jan 2011 13:03:37 -0800 (PST) Received: from barmail2.idig.net (barmail2.idig.net [64.34.111.252]) by core3.amsl.com (Postfix) with ESMTP id EFC483A6C6C for ; Fri, 14 Jan 2011 13:03:36 -0800 (PST) X-ASG-Debug-ID: 1295039162-5e61dccd0001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail2.idig.net with ESMTP id CZWEzFL63WNHugC7; Fri, 14 Jan 2011 13:06:02 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=jwol-lt61.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PdqqP-0005TX-PJ; Fri, 14 Jan 2011 13:06:03 -0800 Mime-Version: 1.0 (Apple Message framework v1082) X-ASG-Orig-Subj: Re: [Ecrit] Comment on draft-ietf-ecrit-unauthenticated-access Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: Date: Fri, 14 Jan 2011 16:05:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <88654924-FC06-4DF0-8A88-A27BE1B6B73D@brianrosen.net> References: To: Richard L. Barnes X-Mailer: Apple Mail (2.1082) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1295039162 X-Barracuda-URL: http://64.34.111.252:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.52384 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: ecrit Subject: Re: [Ecrit] Comment on draft-ietf-ecrit-unauthenticated-access X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 21:03:37 -0000 Yes, that is wrong. I think your proposed solution is correct. Brian On Jan 14, 2011, at 3:55 PM, Richard L. Barnes wrote: > In Section 5, step 2, this document says that the ISP informs the = calling device about its local ESRP via DHCP. This seems incorrect, not = least because there is no DHCP option defined to carry this sort of = information. =20 >=20 > It seems to me that in order to minimize the divergence from the = normal procedure, step 2 should have the network providing the client = access to location (HELD/DHCP-location) and LoST servers, then = connecting to the ESRP. >=20 > --Richard > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From jmpolk@cisco.com Fri Jan 14 15:21:03 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE63D3A6C0B for ; Fri, 14 Jan 2011 15:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 QikMyIZnTj3X for ; Fri, 14 Jan 2011 15:21:02 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 524273A6452 for ; Fri, 14 Jan 2011 15:21:02 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN5pME2rRN+K/2dsb2JhbACkXXOiHZkDhU8EhGs Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 14 Jan 2011 23:23:29 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p0ENNSUW018401; Fri, 14 Jan 2011 23:23:28 GMT Message-Id: <201101142323.p0ENNSUW018401@sj-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 14 Jan 2011 17:23:27 -0600 To: Brian Rosen , "Richard L. Barnes" From: "James M. Polk" In-Reply-To: <88654924-FC06-4DF0-8A88-A27BE1B6B73D@brianrosen.net> References: <88654924-FC06-4DF0-8A88-A27BE1B6B73D@brianrosen.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ecrit Subject: Re: [Ecrit] Comment on draft-ietf-ecrit-unauthenticated-access X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 23:21:04 -0000 At 03:05 PM 1/14/2011, Brian Rosen wrote: >Yes, that is wrong. > >I think your proposed solution is correct. I agree James >Brian > >On Jan 14, 2011, at 3:55 PM, Richard L. Barnes wrote: > > > In Section 5, step 2, this document says that the ISP informs > the calling device about its local ESRP via DHCP. This seems > incorrect, not least because there is no DHCP option defined to > carry this sort of information. > > > > It seems to me that in order to minimize the divergence from the > normal procedure, step 2 should have the network providing the > client access to location (HELD/DHCP-location) and LoST servers, > then connecting to the ESRP. > > > > --Richard > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@gmx.net Sat Jan 15 01:11:34 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92DCF3A6D33 for ; Sat, 15 Jan 2011 01:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.61 X-Spam-Level: X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-0.011, 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 Oy0S7gHD-hSh for ; Sat, 15 Jan 2011 01:11:33 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 190F13A6D32 for ; Sat, 15 Jan 2011 01:11:32 -0800 (PST) Received: (qmail invoked by alias); 15 Jan 2011 09:13:59 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.7]) [88.115.222.204] by mail.gmx.net (mp070) with SMTP; 15 Jan 2011 10:13:59 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/XiCwzYrLXfLqPJfTQZYr+QwwkZ20qcbI+qxrAVJ wAuj/GacZ8928x Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Sat, 15 Jan 2011 11:13:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <230B8F3C-9839-4857-881C-86794BF9B2D9@gmx.net> References: To: Richard L. Barnes X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig , ecrit Subject: Re: [Ecrit] Comment on draft-ietf-ecrit-unauthenticated-access X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 09:11:34 -0000 Hey Richard,=20 you raise a very good point and this is definitely something we should a = discussion about.=20 There are two options for providing this functionality: 1) As you suggested to use the procedure in Phone BCP This essentially requires the following statements: " The emergency client MUST support location acquisition and the LCPs = described in Section 6.5 of [I-D.ietf-ecrit-phonebcp]. The description = in Section 6.5 and 6.6 of [I-D.ietf-ecrit-phonebcp] regarding the = interaction between the device and the LIS applies to this document. The = emergency client MUST use LoST [RFC5222] to obtain an ESRP URI. " Particularly the usage of RFC 5223 (DHCP option for discovering LoST = servers) in this discovery step.=20 2) The second variant, the DHCP-based SIP Proxy discovery mechanism is = used. This SIP proxy will take on the role of a ESRP. =20 This is what the current document says.=20 Ciao Hannes On Jan 14, 2011, at 10:55 PM, Richard L. Barnes wrote: > In Section 5, step 2, this document says that the ISP informs the = calling device about its local ESRP via DHCP. This seems incorrect, not = least because there is no DHCP option defined to carry this sort of = information. =20 >=20 > It seems to me that in order to minimize the divergence from the = normal procedure, step 2 should have the network providing the client = access to location (HELD/DHCP-location) and LoST servers, then = connecting to the ESRP. >=20 > --Richard > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From shida@ntt-at.com Sun Jan 16 16:54:01 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 878BD3A67C0 for ; Sun, 16 Jan 2011 16:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 jXE8DusZv45C for ; Sun, 16 Jan 2011 16:53:59 -0800 (PST) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.239.22]) by core3.amsl.com (Postfix) with SMTP id 636353A6BA0 for ; Sun, 16 Jan 2011 16:53:59 -0800 (PST) Received: (qmail 12083 invoked from network); 17 Jan 2011 00:55:35 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway03.websitewelcome.com with SMTP; 17 Jan 2011 00:55:35 -0000 Received: from [60.237.173.240] (port=53385 helo=[192.168.1.10]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PedOU-0005LV-13; Sun, 16 Jan 2011 18:56:27 -0600 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <4D2B7AAC.2080100@cs.columbia.edu> Date: Mon, 17 Jan 2011 09:56:27 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D2B7AAC.2080100@cs.columbia.edu> To: Andrea G Forte X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: rai@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] RAI-ART review for draft-forte-lost-extensions-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 00:54:01 -0000 Hi Andrea; My comments inline. On Jan 11, 2011, at 6:31 AM, Andrea G Forte wrote: > Please read comments inline. >=20 > Thanks, > -Andrea >=20 >=20 > On 12/31/10 6:26 AM, Shida Schubert wrote: >> I am the assigned RAI-ART reviewer for = draft-forte-lost-extensions-02.txt. >>=20 >> For background on RAI-ART, please see the FAQ = at. >>=20 >> Please resolve these comments along with any other comments you may = receive. >>=20 >> *** >> This draft is basically ready for publication, but has nits that = should be fixed before publication. >> *** >>=20 >> I am sending the nits to the authors so I am sending few technical = concerns I have on the lists. >>=20 >> ** Comments on the draft ** >>=20 >> 0. This draft alters a definition of region for non-emergency = services, should this be >> updating the RFC5222 in anyway? I am not sure if it should as = emergency case >> is obviously the main user of the protocol but will this be the = case, say in 5 years? > I do not have any particular position on this. Same here. I think we need additional feedback on this.=20 >=20 >> 1. Looking at the definition of "query" in RFC5222, the draft is not = really defining >> a new queries but defining a filter to limit the results. I don't = feel that term >> "queries" for this extension defined in this draft is = appropriate. I apologize for not being >> able to come up with a proposal but "query" just didn't sound = right.. > I do not agree with this. A filter as such, is applied on a number of = existing results to further constrain > them based on some metric. In this case, we do not have a pre-existing = set of results that we are filtering, here we > "ask" the server a more specific question and the server replies with = the results fulfilling this specific question. >=20 > In RFC 5222 it reads: > "The query message carries location information and a service > identifier encoded as a Uniform Resource Name (URN) (see [9]) from > the LoST client to the LoST server. The LoST server uses its > database to map the input values to one or more Uniform Resource > Identifiers (URIs) and returns those URIs along with optional > information, such as hints about the service boundary, in a response > message to the LoST client." >=20 > This is true also for our new queries. Can you please let me know = where in RFC 5222 you see a definition of query > that is in contrast with what we define in the draft? The definition you are referring doesn't necessary contradict with what=20= you are defining in the draft, but RFC5222 section 3 clearly=20 identifies type of queries associated to each request type. This draft definitely doesn't add any new request type, rather it=20 uses the pre-existing request type (findservice etc.) to allow=20 specific search to be conducted at LoST.=20 AFAIK It's not a new query that you are defining, but an extension=20 to an existing query which alter the semantics of the request to get=20 desirable result.=20 I don't really have a strong opinion on this, but when I was reading, = it=20 was rather confusing to say that you are defining new queries.=20 Furthermore does it make sense to have these extension elements=20 appear in other query type?=20 >=20 >> 2. The draft clearly states that these extensions are NOT applicable = to the >> emergency uses. If that is the case the draft should probably = say that it MUST NOT be >> used in emergency cases somewhere in the draft, especially if it = has negative >> implication (I couldn't think of any but..). > OK, we will add the MUST NOT. >=20 >> 3. is used when you want to query the LoST server to find a = service >> that serves the requesting entity's location but default = behavior of LoST as >> defined in RFC5222 is to conduct a query based on the region so = this seems >> tad bit odd to me. Especially because when is absent, = one is supposed >> to conduct a search based on the distance from the user but it = should be the >> other way around. Either say that when is absent it is = assumed true >> or define alternative element which describes that it's for = doing a "instance within >> X distance". > Yes, to have a more consistent behavior between emergency and = non-emergency services, > we can say that when is absent, it is assumed to be true = rather than false. >> ** General comments about the use of LoST for service other than = emergency ** >>=20 >> I think this draft highlights lack of consideration during the = creation of LoST generic uses >> beside emergency services and this raises some concerns not necessary = with this draft >> but with the generic use of LoST in general. >>=20 >> 1. When LoST server is used for generic uses, I believe the server = will be stressed a lot >> more than when used for Emergency cases due to unique computation = required for >> querying users's location to service region of the service or = searching for services >> within distance X. I just hope that encouraging >> the use of LoST for generic uses will not interfere with the = Emergency service in anyway.. >> I am assuming that in real deployment, the LoST server that = handles the initial request >> will probably dispatch or redirect the request to appropriate = server that can handle the >> requested service, so LoST serve that will handle the mapping of = location to PSAP will >> not be overwhelmed by trying to figure out what pizza delivery is = close to Joe's current >> location. > In real deployments I do not think that LoST servers in the ESInet = will be available also for non-emergency > services. I think that access to the ESInet will be granted only for = serving emergency queries or perhaps other > government-related needs. I don't think how you would do this.=20 How would the client know which LoST server is for ESInet and which one = isn't?=20 LoST is not like DNS, where you can look at the root domain and = dispatch/delegate=20 the request to appropriate server. With LoST, LoST server would have to = parse the=20 XML to see if the request is for emergency or non-emergency service.=20 However, it's an HTTP server after all and I do think scaling HTTP = server=20 is probably trivial so I will withdraw my concern on this.=20 Regards Shida >=20 >>=20 >>=20 >> 2. Although, I am assuming most or all of the remaining queries will = function as >> defined in RFC5222, I think we should probably look at how the = rest of the >> query beside will look like and behave when used = for generic uses. >>=20 >> e.g. >> How useful is the listservice / listserviceresponse in generic = uses as is now? >>>> Should there be an extension to query with a filter = so >> only a sub-element will be displayed (querying the LoST = server with >> urn:service:restaurants or urn:service:stores? >>=20 >> This has nothing to do with the draft in question.. But something = we may want to >> think about if we are going to encourage people to implement LoST = for non-emergency services. >>=20 >> Regards >> Shida >=20 From rbarnes@bbn.com Sun Jan 16 18:51:01 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45ADA28C0EF for ; Sun, 16 Jan 2011 18:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 revBLxIEZmwx for ; Sun, 16 Jan 2011 18:51:00 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 3095328C0EC for ; Sun, 16 Jan 2011 18:51:00 -0800 (PST) Received: from [128.89.253.241] (port=64486 helo=[192.168.1.16]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PefDo-0009qm-EG; Sun, 16 Jan 2011 21:53:32 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <230B8F3C-9839-4857-881C-86794BF9B2D9@gmx.net> Date: Sun, 16 Jan 2011 21:53:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <54E8554D-E0C2-4DD5-988C-403C61E529D4@bbn.com> References: <230B8F3C-9839-4857-881C-86794BF9B2D9@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1082) Cc: ecrit Subject: Re: [Ecrit] Comment on draft-ietf-ecrit-unauthenticated-access X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 02:51:01 -0000 It doesn't seem helpful to have a whole separate calling procedure at = the application layer, just because the mechanism for layer-2/3 access = is different. So I think whatever the solution is to be, it should be = consistent between this document and phonebcp. =20 There are at least a few arguments for this common method to be the = current LCP/LoST method instead of this novel DHCP-based method. 1. Long-standing consensus around phonebcp, and no clear reason to = change. =20 2. In addition to the client-side requirements, the DHCP method adds = several requirements for network operators. Given that there is already = some resistance by network operators to deploying phonebcp, this does = not seem like a decision that is likely to promote deployment. 3. Pinning the solution to SIP unnecessarily constrains the set of = protocols that the caller can use to communicate with the PSAP. This = should be up to the network operator's policy, not decided by the = technology. At best, you could put PSAP contact URIs in DHCP, but you = would need to define a new option. 4. DHCP server service areas don't necessarily align well with PSAP = service areas or LCP service areas, which can make the job of the ESRP = tricky. For example, it might be necessary for the ESRP to discover = which location server it needs to draw from. --Richard On Jan 15, 2011, at 4:13 AM, Hannes Tschofenig wrote: > Hey Richard,=20 >=20 > you raise a very good point and this is definitely something we should = a discussion about.=20 >=20 > There are two options for providing this functionality: >=20 > 1) As you suggested to use the procedure in Phone BCP >=20 > This essentially requires the following statements: > " > The emergency client MUST support location acquisition and the LCPs = described in Section 6.5 of [I-D.ietf-ecrit-phonebcp]. The description = in Section 6.5 and 6.6 of [I-D.ietf-ecrit-phonebcp] regarding the = interaction between the device and the LIS applies to this document. The = emergency client MUST use LoST [RFC5222] to obtain an ESRP URI. > " >=20 > Particularly the usage of RFC 5223 (DHCP option for discovering LoST = servers) in this discovery step.=20 >=20 > 2) The second variant, the DHCP-based SIP Proxy discovery mechanism is = used. This SIP proxy will take on the role of a ESRP. =20 > This is what the current document says.=20 >=20 > Ciao > Hannes >=20 > On Jan 14, 2011, at 10:55 PM, Richard L. Barnes wrote: >=20 >> In Section 5, step 2, this document says that the ISP informs the = calling device about its local ESRP via DHCP. This seems incorrect, not = least because there is no DHCP option defined to carry this sort of = information. =20 >>=20 >> It seems to me that in order to minimize the divergence from the = normal procedure, step 2 should have the network providing the client = access to location (HELD/DHCP-location) and LoST servers, then = connecting to the ESRP. >>=20 >> --Richard >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From br@brianrosen.net Sun Jan 16 19:22:48 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E080C28C0EF for ; Sun, 16 Jan 2011 19:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.332 X-Spam-Level: X-Spam-Status: No, score=-103.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 YC+wbtghT8CT for ; Sun, 16 Jan 2011 19:22:48 -0800 (PST) Received: from barmail3.idig.net (barmail3.idig.net [64.34.111.253]) by core3.amsl.com (Postfix) with ESMTP id E9EE428C0EC for ; Sun, 16 Jan 2011 19:22:47 -0800 (PST) X-ASG-Debug-ID: 1295126561-332c89c60001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail3.idig.net with ESMTP id rWg2vTAgMpDM5136; Sat, 15 Jan 2011 13:22:41 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [24.154.127.233] (helo=[192.168.1.100]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PeDa4-0000gD-Mv; Sat, 15 Jan 2011 13:22:41 -0800 Mime-Version: 1.0 (Apple Message framework v1082) X-ASG-Orig-Subj: Re: [Ecrit] Comment on draft-ietf-ecrit-unauthenticated-access Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <230B8F3C-9839-4857-881C-86794BF9B2D9@gmx.net> Date: Sat, 15 Jan 2011 16:22:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8CD35333-F282-43FE-B8AC-CCCCDD4E7B0B@brianrosen.net> References: <230B8F3C-9839-4857-881C-86794BF9B2D9@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1082) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1295126561 X-Barracuda-URL: http://64.34.111.253:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.52598 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: ecrit Subject: Re: [Ecrit] Comment on draft-ietf-ecrit-unauthenticated-access X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 03:22:49 -0000 The SIP proxy cannot take the role of an ESRP. =20 It could do the LoST processing on behalf of the client, but the client = would have to obtain location and pass it on. It seems unreasonable to = me to expect the client to know enough about emergency calling to add = location, and not enough to handle the LoST query. It is unreasonable = to expect that the proxy could always know location. If you want to = make that a requirement, I think you limit the applicability. Since I don't like unauthenticated access at all, it's fine with me to = limit applicability :) However the document has to say that. Brian On Jan 15, 2011, at 4:13 AM, Hannes Tschofenig wrote: > Hey Richard,=20 >=20 > you raise a very good point and this is definitely something we should = a discussion about.=20 >=20 > There are two options for providing this functionality: >=20 > 1) As you suggested to use the procedure in Phone BCP >=20 > This essentially requires the following statements: > " > The emergency client MUST support location acquisition and the LCPs = described in Section 6.5 of [I-D.ietf-ecrit-phonebcp]. The description = in Section 6.5 and 6.6 of [I-D.ietf-ecrit-phonebcp] regarding the = interaction between the device and the LIS applies to this document. The = emergency client MUST use LoST [RFC5222] to obtain an ESRP URI. > " >=20 > Particularly the usage of RFC 5223 (DHCP option for discovering LoST = servers) in this discovery step.=20 >=20 > 2) The second variant, the DHCP-based SIP Proxy discovery mechanism is = used. This SIP proxy will take on the role of a ESRP. =20 > This is what the current document says.=20 >=20 > Ciao > Hannes >=20 > On Jan 14, 2011, at 10:55 PM, Richard L. Barnes wrote: >=20 >> In Section 5, step 2, this document says that the ISP informs the = calling device about its local ESRP via DHCP. This seems incorrect, not = least because there is no DHCP option defined to carry this sort of = information. =20 >>=20 >> It seems to me that in order to minimize the divergence from the = normal procedure, step 2 should have the network providing the client = access to location (HELD/DHCP-location) and LoST servers, then = connecting to the ESRP. >>=20 >> --Richard >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From Martin.Thomson@andrew.com Sun Jan 16 21:05:34 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C8DA3A6DBF for ; Sun, 16 Jan 2011 21:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 3MoLpMHinGEC for ; Sun, 16 Jan 2011 21:05:33 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 6317C3A6DAE for ; Sun, 16 Jan 2011 21:05:33 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:11076 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S436996Ab1AQFIG (ORCPT ); Sun, 16 Jan 2011 23:08:06 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Sun, 16 Jan 2011 23:08:06 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 17 Jan 2011 13:08:03 +0800 From: "Thomson, Martin" To: "Richard L. Barnes" , Hannes Tschofenig Date: Mon, 17 Jan 2011 13:08:00 +0800 Thread-Topic: [Ecrit] Comment on draft-ietf-ecrit-unauthenticated-access Thread-Index: Acu18b4m9HSwYDsaQ8isO0+bE36PugAEb7Hg Message-ID: <8B0A9FCBB9832F43971E38010638454F03F5259685@SISPE7MB1.commscope.com> References: <230B8F3C-9839-4857-881C-86794BF9B2D9@gmx.net> <54E8554D-E0C2-4DD5-988C-403C61E529D4@bbn.com> In-Reply-To: <54E8554D-E0C2-4DD5-988C-403C61E529D4@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: ecrit Subject: Re: [Ecrit] Comment on draft-ietf-ecrit-unauthenticated-access X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 05:05:34 -0000 SSBoYXZlIHRvIGFncmVlIHdpdGggUmljaGFyZCBoZXJlLg0KDQpUaGVyZSdzIGFuIGFyZ3VtZW50 IHRvIGJlIG1hZGUgZm9yIGEgZHVtYiBlbnRlcnByaXNlIHBob25lIHRvIGRlbGVnYXRlIHRoZXNl IHNvcnRzIG9mIGZ1bmN0aW9ucyB0byBhIHByb3h5LCBidXQgdGhpcyBpcyByZWFsbHkgdGhlIG9w cG9zaXRlIHNjZW5hcmlvLiAgSSBjYW4ndCBzZWUgd2h5IHlvdSB3b3VsZCBuZWVkIGEgc2VwYXJh dGUgcHJvY2VkdXJlLg0KDQotLU1hcnRpbg0KDQpPbiAyMDExLTAxLTE3IGF0IDEzOjUzOjI4LCBS aWNoYXJkIEwuIEJhcm5lcyB3cm90ZToNCj4gSXQgZG9lc24ndCBzZWVtIGhlbHBmdWwgdG8gaGF2 ZSBhIHdob2xlIHNlcGFyYXRlIGNhbGxpbmcgcHJvY2VkdXJlIGF0DQo+IHRoZSBhcHBsaWNhdGlv biBsYXllciwganVzdCBiZWNhdXNlIHRoZSBtZWNoYW5pc20gZm9yIGxheWVyLTIvMyBhY2Nlc3MN Cj4gaXMgZGlmZmVyZW50LiAgU28gSSB0aGluayB3aGF0ZXZlciB0aGUgc29sdXRpb24gaXMgdG8g YmUsIGl0IHNob3VsZCBiZQ0KPiBjb25zaXN0ZW50IGJldHdlZW4gdGhpcyBkb2N1bWVudCBhbmQg cGhvbmViY3AuDQo+IA0KPiBUaGVyZSBhcmUgYXQgbGVhc3QgYSBmZXcgYXJndW1lbnRzIGZvciB0 aGlzIGNvbW1vbiBtZXRob2QgdG8gYmUgdGhlDQo+IGN1cnJlbnQgTENQL0xvU1QgbWV0aG9kIGlu c3RlYWQgb2YgdGhpcyBub3ZlbCBESENQLWJhc2VkIG1ldGhvZC4NCj4gDQo+IDEuIExvbmctc3Rh bmRpbmcgY29uc2Vuc3VzIGFyb3VuZCBwaG9uZWJjcCwgYW5kIG5vIGNsZWFyIHJlYXNvbiB0bw0K PiBjaGFuZ2UuDQo+IA0KPiAyLiBJbiBhZGRpdGlvbiB0byB0aGUgY2xpZW50LXNpZGUgcmVxdWly ZW1lbnRzLCB0aGUgREhDUCBtZXRob2QgYWRkcw0KPiBzZXZlcmFsIHJlcXVpcmVtZW50cyBmb3Ig bmV0d29yayBvcGVyYXRvcnMuICBHaXZlbiB0aGF0IHRoZXJlIGlzDQo+IGFscmVhZHkgc29tZSBy ZXNpc3RhbmNlIGJ5IG5ldHdvcmsgb3BlcmF0b3JzIHRvIGRlcGxveWluZyBwaG9uZWJjcCwNCj4g dGhpcyBkb2VzIG5vdCBzZWVtIGxpa2UgYSBkZWNpc2lvbiB0aGF0IGlzIGxpa2VseSB0byBwcm9t b3RlDQo+IGRlcGxveW1lbnQuDQo+IA0KPiAzLiBQaW5uaW5nIHRoZSBzb2x1dGlvbiB0byBTSVAg dW5uZWNlc3NhcmlseSBjb25zdHJhaW5zIHRoZSBzZXQgb2YNCj4gcHJvdG9jb2xzIHRoYXQgdGhl IGNhbGxlciBjYW4gdXNlIHRvIGNvbW11bmljYXRlIHdpdGggdGhlIFBTQVAuICBUaGlzDQo+IHNo b3VsZCBiZSB1cCB0byB0aGUgbmV0d29yayBvcGVyYXRvcidzIHBvbGljeSwgbm90IGRlY2lkZWQg YnkgdGhlDQo+IHRlY2hub2xvZ3kuICBBdCBiZXN0LCB5b3UgY291bGQgcHV0IFBTQVAgY29udGFj dCBVUklzIGluIERIQ1AsIGJ1dCB5b3UNCj4gd291bGQgbmVlZCB0byBkZWZpbmUgYSBuZXcgb3B0 aW9uLg0KPiANCj4gNC4gREhDUCBzZXJ2ZXIgc2VydmljZSBhcmVhcyBkb24ndCBuZWNlc3Nhcmls eSBhbGlnbiB3ZWxsIHdpdGggUFNBUA0KPiBzZXJ2aWNlIGFyZWFzIG9yIExDUCBzZXJ2aWNlIGFy ZWFzLCB3aGljaCBjYW4gbWFrZSB0aGUgam9iIG9mIHRoZSBFU1JQDQo+IHRyaWNreS4gIEZvciBl eGFtcGxlLCBpdCBtaWdodCBiZSBuZWNlc3NhcnkgZm9yIHRoZSBFU1JQIHRvIGRpc2NvdmVyDQo+ IHdoaWNoIGxvY2F0aW9uIHNlcnZlciBpdCBuZWVkcyB0byBkcmF3IGZyb20uDQo+IA0KPiAtLVJp Y2hhcmQNCj4gDQo+IA0KPiANCj4gDQo+IE9uIEphbiAxNSwgMjAxMSwgYXQgNDoxMyBBTSwgSGFu bmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+IA0KPiA+IEhleSBSaWNoYXJkLA0KPiA+DQo+ID4geW91 IHJhaXNlIGEgdmVyeSBnb29kIHBvaW50IGFuZCB0aGlzIGlzIGRlZmluaXRlbHkgc29tZXRoaW5n IHdlDQo+IHNob3VsZCBhIGRpc2N1c3Npb24gYWJvdXQuDQo+ID4NCj4gPiBUaGVyZSBhcmUgdHdv IG9wdGlvbnMgZm9yIHByb3ZpZGluZyB0aGlzIGZ1bmN0aW9uYWxpdHk6DQo+ID4NCj4gPiAxKSBB cyB5b3Ugc3VnZ2VzdGVkIHRvIHVzZSB0aGUgcHJvY2VkdXJlIGluIFBob25lIEJDUA0KPiA+DQo+ ID4gVGhpcyBlc3NlbnRpYWxseSByZXF1aXJlcyB0aGUgZm9sbG93aW5nIHN0YXRlbWVudHM6DQo+ ID4gIg0KPiA+IFRoZSBlbWVyZ2VuY3kgY2xpZW50IE1VU1Qgc3VwcG9ydCBsb2NhdGlvbiBhY3F1 aXNpdGlvbiBhbmQgdGhlIExDUHMNCj4gZGVzY3JpYmVkIGluIFNlY3Rpb24gNi41IG9mIFtJLUQu aWV0Zi1lY3JpdC1waG9uZWJjcF0uICBUaGUgZGVzY3JpcHRpb24NCj4gaW4gU2VjdGlvbiA2LjUg YW5kIDYuNiBvZiBbSS1ELmlldGYtZWNyaXQtcGhvbmViY3BdIHJlZ2FyZGluZyB0aGUNCj4gaW50 ZXJhY3Rpb24gYmV0d2VlbiB0aGUgZGV2aWNlIGFuZCB0aGUgTElTIGFwcGxpZXMgdG8gdGhpcyBk b2N1bWVudC4NCj4gVGhlIGVtZXJnZW5jeSBjbGllbnQgTVVTVCB1c2UgTG9TVCBbUkZDNTIyMl0g dG8gb2J0YWluIGFuIEVTUlAgVVJJLg0KPiA+ICINCj4gPg0KPiA+IFBhcnRpY3VsYXJseSB0aGUg dXNhZ2Ugb2YgUkZDIDUyMjMgKERIQ1Agb3B0aW9uIGZvciBkaXNjb3ZlcmluZyBMb1NUDQo+IHNl cnZlcnMpIGluIHRoaXMgZGlzY292ZXJ5IHN0ZXAuDQo+ID4NCj4gPiAyKSBUaGUgc2Vjb25kIHZh cmlhbnQsIHRoZSBESENQLWJhc2VkIFNJUCBQcm94eSBkaXNjb3ZlcnkgbWVjaGFuaXNtDQo+IGlz IHVzZWQuIFRoaXMgU0lQIHByb3h5IHdpbGwgdGFrZSBvbiB0aGUgcm9sZSBvZiBhIEVTUlAuDQo+ ID4gVGhpcyBpcyB3aGF0IHRoZSBjdXJyZW50IGRvY3VtZW50IHNheXMuDQo+ID4NCj4gPiBDaWFv DQo+ID4gSGFubmVzDQo+ID4NCj4gPiBPbiBKYW4gMTQsIDIwMTEsIGF0IDEwOjU1IFBNLCBSaWNo YXJkIEwuIEJhcm5lcyB3cm90ZToNCj4gPg0KPiA+PiBJbiAgU2VjdGlvbiA1LCBzdGVwIDIsIHRo aXMgZG9jdW1lbnQgc2F5cyB0aGF0IHRoZSBJU1AgaW5mb3JtcyB0aGUNCj4gY2FsbGluZyBkZXZp Y2UgYWJvdXQgaXRzIGxvY2FsIEVTUlAgdmlhIERIQ1AuICBUaGlzIHNlZW1zIGluY29ycmVjdCwN Cj4gbm90IGxlYXN0IGJlY2F1c2UgdGhlcmUgaXMgbm8gREhDUCBvcHRpb24gZGVmaW5lZCB0byBj YXJyeSB0aGlzIHNvcnQgb2YNCj4gaW5mb3JtYXRpb24uDQo+ID4+DQo+ID4+IEl0IHNlZW1zIHRv IG1lIHRoYXQgaW4gb3JkZXIgdG8gbWluaW1pemUgdGhlIGRpdmVyZ2VuY2UgZnJvbSB0aGUNCj4g bm9ybWFsIHByb2NlZHVyZSwgc3RlcCAyIHNob3VsZCBoYXZlIHRoZSBuZXR3b3JrIHByb3ZpZGlu ZyB0aGUgY2xpZW50DQo+IGFjY2VzcyB0byBsb2NhdGlvbiAoSEVMRC9ESENQLWxvY2F0aW9uKSBh bmQgTG9TVCBzZXJ2ZXJzLCB0aGVuDQo+IGNvbm5lY3RpbmcgdG8gdGhlIEVTUlAuDQo+ID4+DQo+ ID4+IC0tUmljaGFyZA0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gPj4gRWNyaXRAaWV0Zi5vcmcN Cj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPiA+DQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBF Y3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQoNCg== From rbarnes@bbn.com Wed Jan 19 13:56:04 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DDC93A701C for ; Wed, 19 Jan 2011 13:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.706 X-Spam-Level: X-Spam-Status: No, score=-102.706 tagged_above=-999 required=5 tests=[AWL=-0.107, 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 rJYOAzj2MCgf for ; Wed, 19 Jan 2011 13:56:02 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 6DBF03A6F0E for ; Wed, 19 Jan 2011 13:56:02 -0800 (PST) Received: from [192.1.255.181] (port=53484 helo=col-raltmann-l1.nira.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Pfg39-0002Rp-Fc for ecrit@ietf.org; Wed, 19 Jan 2011 16:58:43 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: "Richard L. Barnes" In-Reply-To: <7F5FAEC5-12E6-40A9-9DC1-E1883DF693BA@cs.columbia.edu> Date: Wed, 19 Jan 2011 16:58:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2853ABBA-84BA-45E0-B194-D7D88F9C7A7F@bbn.com> References: <7F5FAEC5-12E6-40A9-9DC1-E1883DF693BA@cs.columbia.edu> To: ecrit X-Mailer: Apple Mail (2.1082) Subject: Re: [Ecrit] Updated FCC NOI link X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 21:56:04 -0000 Update: This NOI appeared in the Federal Register on 12 Jan 2011. =20 The comment deadline is 28 Feb 2011. --Richard On Dec 22, 2010, at 8:34 AM, Henning Schulzrinne wrote: > Some have reported problems with the link I posted yesterday; the link = below seems to work >=20 > = http://www.fcc.gov/Daily_Releases/Daily_Business/2010/db1221/FCC-10-200A1.= pdf >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Tue Jan 25 02:25:16 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 202B43A6827; Tue, 25 Jan 2011 02:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.100, 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 q9FW0ZCW7MUe; Tue, 25 Jan 2011 02:25:13 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 68FFE3A6B80; Tue, 25 Jan 2011 02:25:13 -0800 (PST) Received: from [128.89.255.108] (port=55956 helo=[192.168.1.16]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Phg89-000NQq-Du; Tue, 25 Jan 2011 05:28:10 -0500 From: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=Apple-Mail-7--183496333 Date: Tue, 25 Jan 2011 05:28:03 -0500 References: <006b01cbbc71$5eb4e1b0$1c1ea510$@org> To: ecrit , geopriv@ietf.org, 802-23 Emergency Services Message-Id: <897B042D-F8A2-4A12-9DCA-A588516C6D6B@bbn.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [Ecrit] ESW8 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 10:25:16 -0000 --Apple-Mail-7--183496333 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > Dear all, > =20 > We are delighted to invite you to the 8th Emergency Services Workshop = (ESW8). The ESW8, an international emergency service standards = coordination group conference, will be held in Budapest on 13-15 April = 2011. > =20 > This year, the event is hosted by EENA, the European Emergency Number = Association, and it is integrated in the programme of the EU Emergency = Services Workshop that gathers emergency services, public authorities = and industry representatives. This 3-day conference aims at fostering = sharing of best practices between the relevant stakeholders. > =20 > The ESW8 is indicated as =93Next Generation Emergency Services (ESW8)=94= in the programme of the event. Participants are however welcome to = attend the entire 3-day event. As usual, special attention will be paid = to Next Generation, IP-based emergency calling, including: > =A7 An introduction to Next-Generation emergency services intended to = provide a basic understanding of IP-based emergency calling to public = safety representatives > =A7 A session on testing and deployment elements with a focus on some = relevant projects and initiatives > =A7 A discussion on standards aiming at coordinating between = different specific efforts and standards development organisations = (SDOs) > =20 > The Workshop will welcome around 200 participants, including around = 100 emergency services and public authorities=92 representatives. > =20 > Since the number of attendees is limited, we invite you to register to = the event as soon as possible. > =20 > More information, programme and registration: > http://www.emergency-services-coordination.info/esw8.html > =20 > Kind regards, > =20 > =20 > Gary MACHADO > Executive Director > European Emergency Number Association - EENA112 > Avenue Louise 262 > 1050 Brussels > Belgium > Tel: +32 (0)2 53 49 789 > www.eena.org > Privileged / confidential information may be contained in this mail = and is intended only for the use of the addressee. If you are not the = addressee, or person responsible for delivering to the person addressed, = you may not copy or deliver this to anyone else. If you receive this = mail by mistake, please notify us immediately by telephone. Thank you. > =20 > =20 --Apple-Mail-7--183496333 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Dear = all,
We are delighted to invite you to = the 8th Emergency Services Workshop = (ESW8). The ESW8, an international emergency service standards = coordination group conference, will be held in Budapest on 13-15 April = 2011.
 
 EU Emergency Services = Workshop that = gathers emergency services, public authorities and industry = representatives. This 3-day conference aims at fostering sharing of best = practices between the relevant stakeholders.
The ESW8 is indicated as =93Next Generation = Emergency Services (ESW8)=94 in the programme of the = event. Participants are however welcome to attend the entire 3-day = event. As usual, special attention will be paid to Next Generation, = IP-based emergency calling, including:
=A7  An = introduction to Next-Generation emergency services intended to provide a = basic understanding of IP-based emergency calling to public safety = representatives
=A7 A session = on testing and deployment elements with a focus on some relevant = projects and initiatives
=A7 A = discussion on standards aiming at coordinating between different = specific efforts and standards development organisations = (SDOs)
 
The = Workshop will welcome around 200 participants, including around 100 = emergency services and public authorities=92 = representatives.
 
More information, programme and = registration:
European Emergency = Number Association - EENA112
Avenue Louise 262
1050 = Brussels
Belgium
Tel: +32 (0)2 53 49 789
www.eena.orgPrivileged / = confidential information may be contained in this mail and is intended = only for the use of the addressee. If you are not the addressee, or = person responsible for delivering to the person addressed, you may not = copy or deliver this to anyone else. If you receive this mail by = mistake, please notify us immediately by telephone. Thank = you.