From gunnar.hellstrom@omnitor.se Mon Mar 1 02:32:18 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 C20F928C28F for ; Mon, 1 Mar 2010 02:32:18 -0800 (PST) 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=[BAYES_05=-1.11, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, MSGID_MULTIPLE_AT=1.449] 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 T7PGtkB6ADVH for ; Mon, 1 Mar 2010 02:32:17 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 57DA43A8608 for ; Mon, 1 Mar 2010 02:32:17 -0800 (PST) Received: from s24.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id C002029F593 for ; Mon, 1 Mar 2010 11:31:28 +0100 (CET) Received: (qmail 78158 invoked from network); 1 Mar 2010 10:31:24 -0000 Received: from h16n1fls34o265.telia.com (HELO AllaneCDator) (gunnar.hellstrom@omnitor.se@[213.64.232.16]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 1 Mar 2010 10:31:24 -0000 From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "'Hannes Tschofenig'" , "'ECRIT'" References: <4B8946DB.3050701@gmx.net> In-Reply-To: <4B8946DB.3050701@gmx.net> Date: Mon, 1 Mar 2010 11:31:23 +0100 Message-ID: <004f01cab92a$57b49d60$071dd820$@hellstrom@omnitor.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq3yTZAX3CskN2oSZCDl54yZnwF/ABVLnNQ Content-Language: sv Subject: Re: [Ecrit] PSAP Callback: Status? 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, 01 Mar 2010 10:32:18 -0000 A functional requirement on the callback is that if an incoming call was supported by some kind of coaching service (Text relay, sign relay, speech relay, captioned call relay, spoken language interpreter etc.), then the information provided with the incoming call must be sufficient for invoking the same coaching service again with the callback. The callback must also use the information provided with the incoming call in the right way to make the callback with the same media and invoke the right coaching service in the callback. There are at least four ways to invoke coaching services in the incoming call. 1. User initiated invocation. The user makes the combination of the emergency number and the coaching service known to be needed in the call. These two addresses are combined according to some rule in the call, so that the coaching service is invoked together with the call to the PSAP. 2. Call service initiated invocation. The user has a profile registered with the call service provider that indicates what coaching service shall be invoked in emergency calls. So, when the user calls the emergency number, the configured coaching service is invoked and connected in the call to the PSAP. 3. Coaching service initiated invocation. The user calls the coaching service and asks them to call the emergency service. ( there are many drawbacks with this method, but it is widely used. ) 4. Emergency service initiated invocation. The PSAP call taker discovers the need for invoking a coaching service in the call, and makes this invocation after the incoming call has been set up. ( it is usually a tough task to figure out what kind of coaching is needed, so in most case it is preferred that the call arrives with coaching included from the beginning). I think we need to firm up the descriptions of incoming calls to make sure that we get the correct information about media and coaching services, in parallel with describing how coached calls shall be set up when calling back. Gunnar -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Saturday, February 27, 2010 5:23 PM To: 'ECRIT' Subject: [Ecrit] PSAP Callback: Status? Hi all, as you have seen from my previous mails I have distributed questions to other organizations, namely NENA, EENA and ETSI EMTEL, to solicit feedback and clarification regarding PSAP callback requirements. So far, I have not seen a lot of feedback but I am sure we will receive something (after some time). Since the submission deadline is ahead of us I am suggestion to reflect the discussions we had during the virtual interim meeting in the draft-schulzrinne-ecrit-psap-callback document itself. Other suggestions? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit __________ NOD32 4900 (20100227) Information __________ Detta meddelande dr genomsvkt av NOD32 Antivirus. http://www.nod32.com From br@brianrosen.net Mon Mar 1 14:14: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 E4F9128C1E9 for ; Mon, 1 Mar 2010 14:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_BASE64_BLANKS=0.041] 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 JoDLnTg0lo67 for ; Mon, 1 Mar 2010 14:14:54 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id 8D3BA28C1E7 for ; Mon, 1 Mar 2010 14:14:54 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.118]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1NmDsx-0000Hz-2d for ecrit@ietf.org; Mon, 01 Mar 2010 16:14:44 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 01 Mar 2010 17:14:44 -0500 From: Brian Rosen To: Message-ID: Thread-Topic: I-D Action:draft-rosen-ecrit-additional-data-00.txt Thread-Index: Acq5jJiVWyp9jYw8/kqMXhxCGBLFcQ== In-Reply-To: <20100301220001.8A1E928C1C2@core3.amsl.com> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3350308493_69838437" 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 Subject: [Ecrit] FW: I-D Action:draft-rosen-ecrit-additional-data-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 22:14:56 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3350308493_69838437 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit In NENA, we designed a data structure that would provide us information that a carrier or other service provider knows about a call. In the current 9-1-1 system, there is information in what is called the "ALI" (Automatic Location Identification) query response that has nothing to do with location, but instead has other information about the service provider or the subscriber. In the NENA i3 work, we defined a new data structure "Additional Data about a Call" that gave non-location information known by a device or service provider in the path of the call. Since we went to all the trouble to point out that the ACCESS NETWORK provides location, we point out that this is the CALLING NETWORK that is providing this data. There could be more than one of them, if there were more than one service provider in the path, which can happen. The URL to this structure is passed in a sip "Call-Info" header. Anyway, we want this data regardless of whether the service provider is a North American service provider, and we think the data is useful to all PSAPs. It serves one other purpose: it has a "hook" for data that is device specific. Examples are crash data for a telematics equipped vehicle, or sensor data from a health monitoring device. The Additional Data about a Call does not define such data, just provides a place for a URL to it. So, we're submitting the NENA data structure to the IETF to see if we can get agreement in ecrit to create an Internet standard that everyone can use. NENA understands that that could mean that the structure changes from what NENA designed. We look forward to your comments on the idea. Brian and Hannes ------ Forwarded Message From: Reply-To: Date: Mon, 1 Mar 2010 14:00:01 -0800 (PST) To: Subject: I-D Action:draft-rosen-ecrit-additional-data-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Additional Data related to a Call for Emergency Call Purposes Author(s) : B. Rosen, H. Tschofenig Filename : draft-rosen-ecrit-additional-data-00.txt Pages : 24 Date : 2010-03-01 When an emergency call is sent to a PSAP, the device that sends it, as well as any service provider in the path of the call may have information about the call which the PSAP may be able to use. This document describes an XML data structure that contains this kind of information in a standardized form. A URI that points to the structure can be included in the SIP signaling with the call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosen-ecrit-additional-data-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------ End of Forwarded Message --B_3350308493_69838437 Content-type: application/octet-stream; name="draft-rosen-ecrit-additional-data-00.txt" Content-disposition: attachment; filename="draft-rosen-ecrit-additional-data-00.txt" Content-transfer-encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDEwLTAzLTAxMTM1MjI5 LkktREBpZXRmLm9yZz4NDQ== --B_3350308493_69838437-- From hgs@cs.columbia.edu Mon Mar 1 14:41:39 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 7563E28C20E for ; Mon, 1 Mar 2010 14:41:39 -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 5Vku9dhzVNCn for ; Mon, 1 Mar 2010 14:41:38 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id 5B0A828C20C for ; Mon, 1 Mar 2010 14:41:38 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o21MfZQB000128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 1 Mar 2010 17:41:36 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: Date: Mon, 1 Mar 2010 17:41:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <78F1D59C-9AF0-4830-AFFE-DEC414CDEB41@cs.columbia.edu> References: To: Brian Rosen X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: ecrit@ietf.org Subject: Re: [Ecrit] FW: I-D Action:draft-rosen-ecrit-additional-data-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 22:41:39 -0000 One general concern of mine is that we seem to be heading towards (at = least) three different enterprise registrations: - the SIP Forum needs to register providers to identify configurations = and seems to be about to establish a registry; - the IETF has enterprise numbers; - NENA has an (unregistered?) URN for its registry. I suspect that in many cases, the company URL or domain name would be = better than nothing. Given the likelihood of international calls as we no longer need = traditional roaming, it would be nice to be clear how this might work = outside the US. Should all non-US carriers register with NENA? Can they? = Would an IETF enterprise ID, given that it's free and easy to get, be = sufficient? It might be useful to define at least some indication of roles. For = example, a single call may well have a telematics data provider, a SIP = provider and maybe a third-party data provider (e.g., Google Health). = The document seemed fuzzy on who all would be identified and how the = call taker could tell who is doing what. Henning On Mar 1, 2010, at 5:14 PM, Brian Rosen wrote: > In NENA, we designed a data structure that would provide us = information that > a carrier or other service provider knows about a call. In the = current > 9-1-1 system, there is information in what is called the "ALI" = (Automatic > Location Identification) query response that has nothing to do with > location, but instead has other information about the service provider = or > the subscriber. >=20 > In the NENA i3 work, we defined a new data structure "Additional Data = about > a Call" that gave non-location information known by a device or = service > provider in the path of the call. Since we went to all the trouble to = point > out that the ACCESS NETWORK provides location, we point out that this = is the > CALLING NETWORK that is providing this data. There could be more than = one > of them, if there were more than one service provider in the path, = which can > happen. The URL to this structure is passed in a sip "Call-Info" = header. >=20 > Anyway, we want this data regardless of whether the service provider = is a > North American service provider, and we think the data is useful to = all > PSAPs. =20 >=20 > It serves one other purpose: it has a "hook" for data that is device > specific. Examples are crash data for a telematics equipped vehicle, = or > sensor data from a health monitoring device. The Additional Data = about a > Call does not define such data, just provides a place for a URL to it. >=20 > So, we're submitting the NENA data structure to the IETF to see if we = can > get agreement in ecrit to create an Internet standard that everyone = can use. > NENA understands that that could mean that the structure changes from = what > NENA designed. >=20 > We look forward to your comments on the idea. >=20 > Brian and Hannes >=20 > ------ Forwarded Message > From: > Reply-To: > Date: Mon, 1 Mar 2010 14:00:01 -0800 (PST) > To: > Subject: I-D Action:draft-rosen-ecrit-additional-data-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > Title : Additional Data related to a Call for Emergency Call > Purposes > Author(s) : B. Rosen, H. Tschofenig > Filename : draft-rosen-ecrit-additional-data-00.txt > Pages : 24 > Date : 2010-03-01 >=20 > When an emergency call is sent to a PSAP, the device that sends it, > as well as any service provider in the path of the call may have > information about the call which the PSAP may be able to use. This > document describes an XML data structure that contains this kind of > information in a standardized form. A URI that points to the > structure can be included in the SIP signaling with the call. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-rosen-ecrit-additional-data-00.t= xt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > ------ End of Forwarded Message >=20 > = ________________________________= _______________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Mon Mar 1 14:50:31 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 68D2128C1CE for ; Mon, 1 Mar 2010 14:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.020, 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 UWaGV6fnLbnN for ; Mon, 1 Mar 2010 14:50:30 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id E798228C150 for ; Mon, 1 Mar 2010 14:50:29 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.118]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1NmERO-0002qm-Uq; Mon, 01 Mar 2010 16:50:19 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 01 Mar 2010 17:50:24 -0500 From: Brian Rosen To: Henning Schulzrinne Message-ID: Thread-Topic: [Ecrit] FW: I-D Action:draft-rosen-ecrit-additional-data-00.txt Thread-Index: Acq5kZQfDAJYaoVvoEmeNHkVrtRzwQ== In-Reply-To: <78F1D59C-9AF0-4830-AFFE-DEC414CDEB41@cs.columbia.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 Cc: ecrit@ietf.org Subject: Re: [Ecrit] FW: I-D Action:draft-rosen-ecrit-additional-data-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 22:50:32 -0000 I think we would agree that a URL would be better than nothing. The NENA ID exists, and maintaining it makes sense. There may be similar registries in other countries. There is more than a unique ID in a NENA registry: there is other data that NENA keeps that PSAPs can get at, although the proposed data structure duplicates some of that. So I guess we would say: if a national registry exists, use it. If it doesn't, use a URL. The service provider role is pretty wrapped up in the "service delivered by provider to user". I doubt we would object to having another element that would be a more precise role definition of the provider. Brian On 3/1/10 5:41 PM, "Henning Schulzrinne" wrote: > One general concern of mine is that we seem to be heading towards (at least) > three different enterprise registrations: > > - the SIP Forum needs to register providers to identify configurations and > seems to be about to establish a registry; > > - the IETF has enterprise numbers; > > - NENA has an (unregistered?) URN for its registry. > > I suspect that in many cases, the company URL or domain name would be better > than nothing. > > Given the likelihood of international calls as we no longer need traditional > roaming, it would be nice to be clear how this might work outside the US. > Should all non-US carriers register with NENA? Can they? Would an IETF > enterprise ID, given that it's free and easy to get, be sufficient? > > It might be useful to define at least some indication of roles. For example, a > single call may well have a telematics data provider, a SIP provider and maybe > a third-party data provider (e.g., Google Health). The document seemed fuzzy > on who all would be identified and how the call taker could tell who is doing > what. > > Henning > > On Mar 1, 2010, at 5:14 PM, Brian Rosen wrote: > >> In NENA, we designed a data structure that would provide us information that >> a carrier or other service provider knows about a call. In the current >> 9-1-1 system, there is information in what is called the "ALI" (Automatic >> Location Identification) query response that has nothing to do with >> location, but instead has other information about the service provider or >> the subscriber. >> >> In the NENA i3 work, we defined a new data structure "Additional Data about >> a Call" that gave non-location information known by a device or service >> provider in the path of the call. Since we went to all the trouble to point >> out that the ACCESS NETWORK provides location, we point out that this is the >> CALLING NETWORK that is providing this data. There could be more than one >> of them, if there were more than one service provider in the path, which can >> happen. The URL to this structure is passed in a sip "Call-Info" header. >> >> Anyway, we want this data regardless of whether the service provider is a >> North American service provider, and we think the data is useful to all >> PSAPs. >> >> It serves one other purpose: it has a "hook" for data that is device >> specific. Examples are crash data for a telematics equipped vehicle, or >> sensor data from a health monitoring device. The Additional Data about a >> Call does not define such data, just provides a place for a URL to it. >> >> So, we're submitting the NENA data structure to the IETF to see if we can >> get agreement in ecrit to create an Internet standard that everyone can use. >> NENA understands that that could mean that the structure changes from what >> NENA designed. >> >> We look forward to your comments on the idea. >> >> Brian and Hannes >> >> ------ Forwarded Message >> From: >> Reply-To: >> Date: Mon, 1 Mar 2010 14:00:01 -0800 (PST) >> To: >> Subject: I-D Action:draft-rosen-ecrit-additional-data-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Additional Data related to a Call for Emergency Call >> Purposes >> Author(s) : B. Rosen, H. Tschofenig >> Filename : draft-rosen-ecrit-additional-data-00.txt >> Pages : 24 >> Date : 2010-03-01 >> >> When an emergency call is sent to a PSAP, the device that sends it, >> as well as any service provider in the path of the call may have >> information about the call which the PSAP may be able to use. This >> document describes an XML data structure that contains this kind of >> information in a standardized form. A URI that points to the >> structure can be included in the SIP signaling with the call. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-rosen-ecrit-additional-data-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> ------ End of Forwarded Message >> >> ___________________________________ >> ____________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > From hgs@cs.columbia.edu Mon Mar 1 15:00:22 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 EC4B93A89BB for ; Mon, 1 Mar 2010 15:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.999, 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 7Br08ktrhy8E for ; Mon, 1 Mar 2010 15:00:21 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 49CAE3A8BD5 for ; Mon, 1 Mar 2010 15:00:05 -0800 (PST) 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.3/8.14.3) with ESMTP id o21N03dw026342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 1 Mar 2010 18:00:03 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-19--733089156 From: Henning Schulzrinne In-Reply-To: Date: Mon, 1 Mar 2010 18:00:03 -0500 Message-Id: <283E9B5E-B86B-4E44-97B0-45BC5A013ED3@cs.columbia.edu> References: To: Brian Rosen X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: ecrit@ietf.org Subject: Re: [Ecrit] FW: I-D Action:draft-rosen-ecrit-additional-data-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 23:00:22 -0000 --Apple-Mail-19--733089156 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 1, 2010, at 5:50 PM, Brian Rosen wrote: >=20 > So I guess we would say: if a national registry exists, use it. > If it doesn't, use a URL. My main concern is the ability to access data. If I visit Korea, using = Vonage as my US-based service provider, will the PSAP be able to resolve = a NENA URN and how? (This may not be a problem for the US-Korea example, = given the large number of travelers, but may be harder for the = Estonia-New Zealand-type case.) I think duplicating as much as possible of the NENA-registered = information is a good thing. Indeed, I'd argue that all (public) = information should be accessible in machine-parseable form (i.e., XML, = not just a web page), so that one doesn't need two access protocols and = can more readily render tags and other information in appropriate (e.g., = translated) form. >=20 > The service provider role is pretty wrapped up in the "service = delivered by > provider to user". I doubt we would object to having another element = that > would be a more precise role definition of the provider. >=20 > Brian --Apple-Mail-19--733089156 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

So I guess we = would say: if a national registry exists, use it.
If it doesn't, use = a URL.

My main concern is the = ability to access data. If I visit Korea, using Vonage as my US-based = service provider, will the PSAP be able to resolve a NENA URN and how? = (This may not be a problem for the US-Korea example, given the large = number of travelers, but may be harder for the Estonia-New Zealand-type = case.)

I think duplicating as much as possible = of the NENA-registered information is a good thing. Indeed, I'd argue = that all (public) information should be accessible in machine-parseable = form (i.e.,  XML, not just a web page), so that one doesn't need = two access protocols and can more readily render tags and other = information in appropriate (e.g., translated) form.


The service provider role is pretty wrapped up in = the "service delivered by
provider to user".  I doubt we would = object to having another element that
would be a more precise role = definition of the = provider.

Brian

= --Apple-Mail-19--733089156-- From br@brianrosen.net Mon Mar 1 15:03:01 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFD883A89BB for ; Mon, 1 Mar 2010 15:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.010, 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 iasu9+sAuESV for ; Mon, 1 Mar 2010 15:03:01 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id DE6533A8863 for ; Mon, 1 Mar 2010 15:03:00 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.118]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1NmEdW-0003nQ-2v for ecrit@ietf.org; Mon, 01 Mar 2010 17:02:50 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 01 Mar 2010 18:02:56 -0500 From: Brian Rosen To: Message-ID: Thread-Topic: New Version Notification for draft-rosen-ecrit-completed-location-00 Thread-Index: Acq5k1RaCw2FK1jIIUqWdM2dYjzxJw== In-Reply-To: <20100301170348.9D8303A8BA0@core3.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 Subject: [Ecrit] FW: New Version Notification for draft-rosen-ecrit-completed-location-00 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, 01 Mar 2010 23:03:01 -0000 In NENA, we really want to be able to send a complete PIDF-LO (every element we have) back to a LoST requester to sends us a PIDF that is valid (meaning, it's complete enough to dispatch responders), but doesn't have all the fields that the LoST server does. A good example is when you send a postal address. We have the actual municipal address. We would like to return that (the A3 element). Another example is when you send "North Main", without a "Street" suffix. If there are no other North Mains, then it's unique, and therefore valid, but we would like to get that "Street" suffix back. Currently, you can't get a PIDF back on a LoST response. This document adds an attribute for (requestCompletedLocation) that requests that a PIDF be sent in the response. It adds a PIDF in a element. Brian ------ Forwarded Message From: IETF I-D Submission Tool Date: Mon, 1 Mar 2010 09:03:48 -0800 (PST) To: Brian Rosen Cc: Henning Schulzrinne Subject: New Version Notification for draft-rosen-ecrit-completed-location-00 A new version of I-D, draft-rosen-ecrit-completed-location-00.txt has been successfuly submitted by Brian Rosen and posted to the IETF repository. Filename: draft-rosen-ecrit-completed-location Revision: 00 Title: Completing the Request Location Creation_date: 2010-03-01 WG ID: Independent Submission Number_of_pages: 14 Abstract: This document defines an extension to LoST (RFC5222) that allows a request to specify that a PIDF be returned in the response if the location was valid, but there were some missing elements. For example, an civic location that did not include a postal code, but was otherwise a complete, and unambiguous location, would receive a complete PIDF in the response that included the postal code. The IETF Secretariat. ------ End of Forwarded Message From jmpolk@cisco.com Mon Mar 1 16:20:54 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 AA20B3A8A15 for ; Mon, 1 Mar 2010 16:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m87boKmRPs16 for ; Mon, 1 Mar 2010 16:20:53 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A924F3A8880 for ; Mon, 1 Mar 2010 16:20:44 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADPpi0urRN+K/2dsb2JhbACbBnOlL5gChHsEgxc X-IronPort-AV: E=Sophos;i="4.49,563,1262563200"; d="scan'208";a="94240143" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 02 Mar 2010 00:20:45 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o220Kiwq009053; Tue, 2 Mar 2010 00:20:45 GMT Message-Id: <201003020020.o220Kiwq009053@sj-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 01 Mar 2010 18:20:44 -0600 To: Brian Rosen , From: "James M. Polk" In-Reply-To: References: <20100301170348.9D8303A8BA0@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Ecrit] FW: New Version Notification for draft-rosen-ecrit-completed-location-00 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, 02 Mar 2010 00:20:54 -0000 well - I guess including a PIDF-LO in a LoST response isn't such a foreign idea anymore... (re: draft-polk-ecrit-lost-transformations-urn-00 in Stockholm - where several spoke at the mic that this wasn't the purpose of LoST (to return a PIDF-LO), but only a URI for that service). If a LoST response can include a corrected LO, then it certainly can include a transformed LO (from one location format to another), as the transformations ID proposes. Comment about draft-rosen-ecrit-completed-location-00 specifically - what do you have in mind to ensure a location isn't inadvertently completed when it shouldn't have been? For example, 2 adjacent cities, both with a "North Main", but where one is "st" the other is "Ave". If somehow the wrong info is sent back to an endpoint, this could be included in subsequent transmissions of location - and not using LoST anymore. This may be a too small a corner case, but this would make one error a lot worse (by adding more bad information in what will be used by other applications). If this is too small a concern to really worry about, I guess this could be addressed in the Security Considerations section - and be done with it. I think this ID has value - as long as it doesn't compound errors by making them worse. James At 05:02 PM 3/1/2010, Brian Rosen wrote: >In NENA, we really want to be able to send a complete PIDF-LO (every element >we have) back to a LoST requester to sends us a PIDF that is valid (meaning, >it's complete enough to dispatch responders), but doesn't have all the >fields that the LoST server does. > >A good example is when you send a postal address. We have the actual >municipal address. We would like to return that (the A3 element). > >Another example is when you send "North Main", without a "Street" suffix. >If there are no other North Mains, then it's unique, and therefore valid, >but we would like to get that "Street" suffix back. > >Currently, you can't get a PIDF back on a LoST response. This document adds >an attribute for (requestCompletedLocation) that requests that >a PIDF be sent in the response. It adds a PIDF in a > element. > >Brian >------ Forwarded Message >From: IETF I-D Submission Tool >Date: Mon, 1 Mar 2010 09:03:48 -0800 (PST) >To: Brian Rosen >Cc: Henning Schulzrinne >Subject: New Version Notification for >draft-rosen-ecrit-completed-location-00 > > >A new version of I-D, draft-rosen-ecrit-completed-location-00.txt has been >successfuly submitted by Brian Rosen and posted to the IETF repository. > >Filename: draft-rosen-ecrit-completed-location >Revision: 00 >Title: Completing the Request Location >Creation_date: 2010-03-01 >WG ID: Independent Submission >Number_of_pages: 14 > >Abstract: >This document defines an extension to LoST (RFC5222) that allows a >request to specify that a PIDF be returned in the response if the >location was valid, but there were some missing elements. For >example, an civic location that did not include a postal code, but >was otherwise a complete, and unambiguous location, would receive a >complete PIDF in the response that included the postal code. > > > >The IETF Secretariat. > > > >------ End of Forwarded Message > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Mon Mar 1 16:29:03 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 E299428C627 for ; Mon, 1 Mar 2010 16:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.007, 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 MBxqrSUCXwXO for ; Mon, 1 Mar 2010 16:29:03 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id 06D683A89C2 for ; Mon, 1 Mar 2010 16:29:02 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.118]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1NmFyk-00025r-Tp; Mon, 01 Mar 2010 18:28:51 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 01 Mar 2010 19:28:53 -0500 From: Brian Rosen To: James Polk , Message-ID: Thread-Topic: [Ecrit] FW: New Version Notification for draft-rosen-ecrit-completed-location-00 Thread-Index: Acq5n1YpQh0OXkmyG0uDMm5KttfTIw== In-Reply-To: <201003020020.o220Kiwq009053@sj-core-4.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 Subject: Re: [Ecrit] FW: New Version Notification for draft-rosen-ecrit-completed-location-00 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, 02 Mar 2010 00:29:04 -0000 There is a difference between returning some fields that the input neglected, and transforming the output: we're getting the mapping, and everything else in the same transaction, and we want that. I think the other effort on geocoding is likely a better approach than using LoST. You can always make a mistake and not know that you have made a mistake. If you meant 100 North Main, Anytown, but sent 100 North Main, Thistown, and there is a 100 North Main in both, it validates, and no one knows a mistake is made. In our case, you have to have a valid location, but no one is expecting EVERY field to be supplied to determine that: if you give us enough fields that we have exactly ONE place on our map where you could be, then we declare it valid. That is true with or without this extension. Brian On 3/1/10 7:20 PM, "James Polk" wrote: > well - I guess including a PIDF-LO in a LoST response isn't such a > foreign idea anymore... (re: > draft-polk-ecrit-lost-transformations-urn-00 in Stockholm - where > several spoke at the mic that this wasn't the purpose of LoST (to > return a PIDF-LO), but only a URI for that service). > > If a LoST response can include a corrected LO, then it certainly can > include a transformed LO (from one location format to another), as > the transformations ID proposes. > > Comment about draft-rosen-ecrit-completed-location-00 specifically - > what do you have in mind to ensure a location isn't inadvertently > completed when it shouldn't have been? > > For example, 2 adjacent cities, both with a "North Main", but where > one is "st" the other is "Ave". If somehow the wrong info is sent > back to an endpoint, this could be included in subsequent > transmissions of location - and not using LoST anymore. > > This may be a too small a corner case, but this would make one error > a lot worse (by adding more bad information in what will be used by > other applications). > > If this is too small a concern to really worry about, I guess this > could be addressed in the Security Considerations section - and be > done with it. > > I think this ID has value - as long as it doesn't compound errors by > making them worse. > > James > > At 05:02 PM 3/1/2010, Brian Rosen wrote: >> In NENA, we really want to be able to send a complete PIDF-LO (every element >> we have) back to a LoST requester to sends us a PIDF that is valid (meaning, >> it's complete enough to dispatch responders), but doesn't have all the >> fields that the LoST server does. >> >> A good example is when you send a postal address. We have the actual >> municipal address. We would like to return that (the A3 element). >> >> Another example is when you send "North Main", without a "Street" suffix. >> If there are no other North Mains, then it's unique, and therefore valid, >> but we would like to get that "Street" suffix back. >> >> Currently, you can't get a PIDF back on a LoST response. This document adds >> an attribute for (requestCompletedLocation) that requests that >> a PIDF be sent in the response. It adds a PIDF in a >> element. >> >> Brian >> ------ Forwarded Message >> From: IETF I-D Submission Tool >> Date: Mon, 1 Mar 2010 09:03:48 -0800 (PST) >> To: Brian Rosen >> Cc: Henning Schulzrinne >> Subject: New Version Notification for >> draft-rosen-ecrit-completed-location-00 >> >> >> A new version of I-D, draft-rosen-ecrit-completed-location-00.txt has been >> successfuly submitted by Brian Rosen and posted to the IETF repository. >> >> Filename: draft-rosen-ecrit-completed-location >> Revision: 00 >> Title: Completing the Request Location >> Creation_date: 2010-03-01 >> WG ID: Independent Submission >> Number_of_pages: 14 >> >> Abstract: >> This document defines an extension to LoST (RFC5222) that allows a >> request to specify that a PIDF be returned in the response if the >> location was valid, but there were some missing elements. For >> example, an civic location that did not include a postal code, but >> was otherwise a complete, and unambiguous location, would receive a >> complete PIDF in the response that included the postal code. >> >> >> >> The IETF Secretariat. >> >> >> >> ------ End of Forwarded Message >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > From Martin.Thomson@andrew.com Mon Mar 1 17:00:32 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 735B628C1DD for ; Mon, 1 Mar 2010 17:00:32 -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 WoE0Q4knXGLx for ; Mon, 1 Mar 2010 17:00:31 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 7C8ED28C678 for ; Mon, 1 Mar 2010 17:00:30 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:11477 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S13203405Ab0CBBAb (ORCPT ); Mon, 1 Mar 2010 19:00:31 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 1 Mar 2010 19:00:30 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 2 Mar 2010 09:00:28 +0800 From: "Thomson, Martin" To: Brian Rosen , "ecrit@ietf.org" Date: Tue, 2 Mar 2010 09:01:43 +0800 Thread-Topic: [Ecrit] FW: New Version Notification for draft-rosen-ecrit-completed-location-00 Thread-Index: Acq5k1RaCw2FK1jIIUqWdM2dYjzxJwAEH//g Message-ID: <8B0A9FCBB9832F43971E38010638454F03DEF1EBFE@SISPE7MB1.commscope.com> References: <20100301170348.9D8303A8BA0@core3.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Ecrit] FW: New Version Notification for draft-rosen-ecrit-completed-location-00 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, 02 Mar 2010 01:00:32 -0000 SSB0aGluayB0aGF0IHRoZXJlIGlzIGEgbWlzdGFrZSBoZXJlIGluIHRhbGtpbmcgYWJvdXQgUElE Ri1MTy4gIFNpbmNlIHRoZSBMb1NUIHNlcnZlciB3b250IGJlIGdpdmVuIGFueSBpZGVudGlmaWNh dGlvbiBpbmZvcm1hdGlvbiwgYW55IFBJREYtTE8gaXQgY3JlYXRlcyB3b3VsZCBub3QgaW5jbHVk ZSBhbnkgdXNlZnVsIGlkZW50aXR5Lg0KDQpJdCBzZWVtcyB0aGF0IGFsbCB5b3UgbmVlZCB0byBp bmNsdWRlIGluIHRoZSByZXNwb25zZSBpcyB0aGUgY29ycmVjdGVkIF9sb2NhdGlvbiBpbmZvcm1h dGlvbl8uDQoNCi0tTWFydGluDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZg0KPiBPZiBCcmlhbiBSb3Nlbg0KPiBTZW50OiBUdWVzZGF5LCAyIE1hcmNoIDIw MTAgMTA6MDMgQU0NCj4gVG86IGVjcml0QGlldGYub3JnDQo+IFN1YmplY3Q6IFtFY3JpdF0gRlc6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcm9zZW4tZWNyaXQtDQo+IGNvbXBs ZXRlZC1sb2NhdGlvbi0wMA0KPiANCj4gSW4gTkVOQSwgd2UgcmVhbGx5IHdhbnQgdG8gYmUgYWJs ZSB0byBzZW5kIGEgY29tcGxldGUgUElERi1MTyAoZXZlcnkNCj4gZWxlbWVudA0KPiB3ZSBoYXZl KSBiYWNrIHRvIGEgTG9TVCByZXF1ZXN0ZXIgdG8gc2VuZHMgdXMgYSBQSURGIHRoYXQgaXMgdmFs aWQNCj4gKG1lYW5pbmcsDQo+IGl0J3MgY29tcGxldGUgZW5vdWdoIHRvIGRpc3BhdGNoIHJlc3Bv bmRlcnMpLCBidXQgZG9lc24ndCBoYXZlIGFsbCB0aGUNCj4gZmllbGRzIHRoYXQgdGhlIExvU1Qg c2VydmVyIGRvZXMuDQo+IA0KPiBBIGdvb2QgZXhhbXBsZSBpcyB3aGVuIHlvdSBzZW5kIGEgcG9z dGFsIGFkZHJlc3MuICBXZSBoYXZlIHRoZSBhY3R1YWwNCj4gbXVuaWNpcGFsIGFkZHJlc3MuICBX ZSB3b3VsZCBsaWtlIHRvIHJldHVybiB0aGF0ICh0aGUgQTMgZWxlbWVudCkuDQo+IA0KPiBBbm90 aGVyIGV4YW1wbGUgaXMgd2hlbiB5b3Ugc2VuZCAiTm9ydGggTWFpbiIsIHdpdGhvdXQgYSAiU3Ry ZWV0Ig0KPiBzdWZmaXguDQo+IElmIHRoZXJlIGFyZSBubyBvdGhlciBOb3J0aCBNYWlucywgdGhl biBpdCdzIHVuaXF1ZSwgYW5kIHRoZXJlZm9yZQ0KPiB2YWxpZCwNCj4gYnV0IHdlIHdvdWxkIGxp a2UgdG8gZ2V0IHRoYXQgIlN0cmVldCIgc3VmZml4IGJhY2suDQo+IA0KPiBDdXJyZW50bHksIHlv dSBjYW4ndCBnZXQgYSBQSURGIGJhY2sgb24gYSBMb1NUIHJlc3BvbnNlLiAgVGhpcyBkb2N1bWVu dA0KPiBhZGRzDQo+IGFuIGF0dHJpYnV0ZSBmb3IgPGZpbmRTZXJ2aWNlPiAocmVxdWVzdENvbXBs ZXRlZExvY2F0aW9uKSB0aGF0IHJlcXVlc3RzDQo+IHRoYXQNCj4gYSBQSURGIGJlIHNlbnQgaW4g dGhlIHJlc3BvbnNlLiAgSXQgYWRkcyBhIFBJREYgaW4gYQ0KPiA8cmVzcG9uc2VDb21wbGV0ZWRM b2NhdGlvbj4gZWxlbWVudC4NCj4gDQo+IEJyaWFuDQo+IC0tLS0tLSBGb3J3YXJkZWQgTWVzc2Fn ZQ0KPiBGcm9tOiBJRVRGIEktRCBTdWJtaXNzaW9uIFRvb2wgPGlkc3VibWlzc2lvbkBpZXRmLm9y Zz4NCj4gRGF0ZTogTW9uLCAgMSBNYXIgMjAxMCAwOTowMzo0OCAtMDgwMCAoUFNUKQ0KPiBUbzog QnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0Pg0KPiBDYzogSGVubmluZyBTY2h1bHpyaW5u ZSA8aGdzQGNzLmNvbHVtYmlhLmVkdT4NCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvcg0KPiBkcmFmdC1yb3Nlbi1lY3JpdC1jb21wbGV0ZWQtbG9jYXRpb24tMDANCj4gDQo+ IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcm9zZW4tZWNyaXQtY29tcGxldGVkLWxv Y2F0aW9uLTAwLnR4dCBoYXMNCj4gYmVlbg0KPiBzdWNjZXNzZnVseSBzdWJtaXR0ZWQgYnkgQnJp YW4gUm9zZW4gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KPiANCj4gRmlsZW5h bWU6ICBkcmFmdC1yb3Nlbi1lY3JpdC1jb21wbGV0ZWQtbG9jYXRpb24NCj4gUmV2aXNpb246ICAw MA0KPiBUaXRsZTogICBDb21wbGV0aW5nIHRoZSBSZXF1ZXN0IExvY2F0aW9uDQo+IENyZWF0aW9u X2RhdGU6ICAyMDEwLTAzLTAxDQo+IFdHIElEOiAgIEluZGVwZW5kZW50IFN1Ym1pc3Npb24NCj4g TnVtYmVyX29mX3BhZ2VzOiAxNA0KPiANCj4gQWJzdHJhY3Q6DQo+IFRoaXMgZG9jdW1lbnQgZGVm aW5lcyBhbiBleHRlbnNpb24gdG8gTG9TVCAoUkZDNTIyMikgdGhhdCBhbGxvd3MgYQ0KPiByZXF1 ZXN0IHRvIHNwZWNpZnkgdGhhdCBhIFBJREYgYmUgcmV0dXJuZWQgaW4gdGhlIHJlc3BvbnNlIGlm IHRoZQ0KPiBsb2NhdGlvbiB3YXMgdmFsaWQsIGJ1dCB0aGVyZSB3ZXJlIHNvbWUgbWlzc2luZyBl bGVtZW50cy4gIEZvcg0KPiBleGFtcGxlLCBhbiBjaXZpYyBsb2NhdGlvbiB0aGF0IGRpZCBub3Qg aW5jbHVkZSBhIHBvc3RhbCBjb2RlLCBidXQNCj4gd2FzIG90aGVyd2lzZSBhIGNvbXBsZXRlLCBh bmQgdW5hbWJpZ3VvdXMgbG9jYXRpb24sIHdvdWxkIHJlY2VpdmUgYQ0KPiBjb21wbGV0ZSBQSURG IGluIHRoZSByZXNwb25zZSB0aGF0IGluY2x1ZGVkIHRoZSBwb3N0YWwgY29kZS4NCj4gDQo+IA0K PiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQuDQo+IA0KPiANCj4gDQo+IC0tLS0tLSBFbmQgb2Yg Rm9yd2FyZGVkIE1lc3NhZ2UNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0K From jmpolk@cisco.com Mon Mar 1 17:09:30 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 AFE7028C6AB for ; Mon, 1 Mar 2010 17:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGETfA1x1xKg for ; Mon, 1 Mar 2010 17:09:29 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C594228C6B0 for ; Mon, 1 Mar 2010 17:09:29 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL/zi0urRN+K/2dsb2JhbACbBnOlFJgGgk+CLASDFw X-IronPort-AV: E=Sophos;i="4.49,563,1262563200"; d="scan'208";a="158875835" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 02 Mar 2010 01:09:30 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o2219U7R021657; Tue, 2 Mar 2010 01:09:30 GMT Message-Id: <201003020109.o2219U7R021657@sj-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 01 Mar 2010 19:09:29 -0600 To: "Thomson, Martin" , Brian Rosen , "ecrit@ietf.org" From: "James M. Polk" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03DEF1EBFE@SISPE7MB1.comms cope.com> References: <20100301170348.9D8303A8BA0@core3.amsl.com> <8B0A9FCBB9832F43971E38010638454F03DEF1EBFE@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Ecrit] FW: New Version Notification for draft-rosen-ecrit-completed-location-00 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, 02 Mar 2010 01:09:30 -0000 At 07:01 PM 3/1/2010, Thomson, Martin wrote: >I think that there is a mistake here in talking about >PIDF-LO. Since the LoST server wont be given any identification >information, any PIDF-LO it creates would not include any useful identity. won't the LoST server have the identity from the PIDF-LO that was in the LoST request (i.e., to be copied from request to response)? >It seems that all you need to include in the response is the >corrected _location information_. Are we trying to save a few bytes here? What's the harm in including a complete 1 packet PIDF-LO response? James >--Martin > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Brian Rosen > > Sent: Tuesday, 2 March 2010 10:03 AM > > To: ecrit@ietf.org > > Subject: [Ecrit] FW: New Version Notification for draft-rosen-ecrit- > > completed-location-00 > > > > In NENA, we really want to be able to send a complete PIDF-LO (every > > element > > we have) back to a LoST requester to sends us a PIDF that is valid > > (meaning, > > it's complete enough to dispatch responders), but doesn't have all the > > fields that the LoST server does. > > > > A good example is when you send a postal address. We have the actual > > municipal address. We would like to return that (the A3 element). > > > > Another example is when you send "North Main", without a "Street" > > suffix. > > If there are no other North Mains, then it's unique, and therefore > > valid, > > but we would like to get that "Street" suffix back. > > > > Currently, you can't get a PIDF back on a LoST response. This document > > adds > > an attribute for (requestCompletedLocation) that requests > > that > > a PIDF be sent in the response. It adds a PIDF in a > > element. > > > > Brian > > ------ Forwarded Message > > From: IETF I-D Submission Tool > > Date: Mon, 1 Mar 2010 09:03:48 -0800 (PST) > > To: Brian Rosen > > Cc: Henning Schulzrinne > > Subject: New Version Notification for > > draft-rosen-ecrit-completed-location-00 > > > > > > A new version of I-D, draft-rosen-ecrit-completed-location-00.txt has > > been > > successfuly submitted by Brian Rosen and posted to the IETF repository. > > > > Filename: draft-rosen-ecrit-completed-location > > Revision: 00 > > Title: Completing the Request Location > > Creation_date: 2010-03-01 > > WG ID: Independent Submission > > Number_of_pages: 14 > > > > Abstract: > > This document defines an extension to LoST (RFC5222) that allows a > > request to specify that a PIDF be returned in the response if the > > location was valid, but there were some missing elements. For > > example, an civic location that did not include a postal code, but > > was otherwise a complete, and unambiguous location, would receive a > > complete PIDF in the response that included the postal code. > > > > > > > > The IETF Secretariat. > > > > > > > > ------ End of Forwarded Message > > > > > > _______________________________________________ > > 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 James.Winterbottom@andrew.com Mon Mar 1 18:26:03 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 8BCD328C1DE for ; Mon, 1 Mar 2010 18:26:03 -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 LKnzeKZ6w7xj for ; Mon, 1 Mar 2010 18:26:02 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 78F0B3A8C01 for ; Mon, 1 Mar 2010 18:26:02 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:22380 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S143381Ab0CBC0D convert rfc822-to-8bit (ORCPT ); Mon, 1 Mar 2010 20:26:03 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 1 Mar 2010 20:26:02 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 2 Mar 2010 10:26:00 +0800 From: "Winterbottom, James" To: "James M. Polk" , "Thomson, Martin" , Brian Rosen , "ecrit@ietf.org" Date: Tue, 2 Mar 2010 10:25:59 +0800 Thread-Topic: [Ecrit] FW: New Version Notification for draft-rosen-ecrit-completed-location-00 Thread-Index: Acq5qb7tRrc3N6dMSxiNYqdC7B4dzgABZevA Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120DBF555F3@SISPE7MB1.commscope.com> References: <20100301170348.9D8303A8BA0@core3.amsl.com> <8B0A9FCBB9832F43971E38010638454F03DEF1EBFE@SISPE7MB1.commscope.com> <201003020109.o2219U7R021657@sj-core-4.cisco.com> In-Reply-To: <201003020109.o2219U7R021657@sj-core-4.cisco.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="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [Ecrit] FW: New Version Notification for draft-rosen-ecrit-completed-location-00 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, 02 Mar 2010 02:26:03 -0000 Unless I am seriously mistaken a LoST server doesn't get a PIDF-LO today, it gets a location. There was considerable objection to including a PIDF-LO in the original LoST query protocol on the grounds that it included identity information EVEN if the identity was an unlinked pseudonym. These were similar grounds as to why a location URI was not deemed an acceptable input to a LoST server. I would like to understand why these issues are suddenly a non-argument. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > James M. Polk > Sent: Tuesday, 2 March 2010 12:09 PM > To: Thomson, Martin; Brian Rosen; ecrit@ietf.org > Subject: Re: [Ecrit] FW: New Version Notification for draft-rosen-ecrit- > completed-location-00 > > At 07:01 PM 3/1/2010, Thomson, Martin wrote: > >I think that there is a mistake here in talking about > >PIDF-LO. Since the LoST server wont be given any identification > >information, any PIDF-LO it creates would not include any useful > identity. > > won't the LoST server have the identity from the PIDF-LO that was in > the LoST request (i.e., to be copied from request to response)? > > > >It seems that all you need to include in the response is the > >corrected _location information_. > > Are we trying to save a few bytes here? What's the harm in including > a complete 1 packet PIDF-LO response? > > James > > > >--Martin > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Brian Rosen > > > Sent: Tuesday, 2 March 2010 10:03 AM > > > To: ecrit@ietf.org > > > Subject: [Ecrit] FW: New Version Notification for draft-rosen-ecrit- > > > completed-location-00 > > > > > > In NENA, we really want to be able to send a complete PIDF-LO (every > > > element > > > we have) back to a LoST requester to sends us a PIDF that is valid > > > (meaning, > > > it's complete enough to dispatch responders), but doesn't have all the > > > fields that the LoST server does. > > > > > > A good example is when you send a postal address. We have the actual > > > municipal address. We would like to return that (the A3 element). > > > > > > Another example is when you send "North Main", without a "Street" > > > suffix. > > > If there are no other North Mains, then it's unique, and therefore > > > valid, > > > but we would like to get that "Street" suffix back. > > > > > > Currently, you can't get a PIDF back on a LoST response. This > document > > > adds > > > an attribute for (requestCompletedLocation) that > requests > > > that > > > a PIDF be sent in the response. It adds a PIDF in a > > > element. > > > > > > Brian > > > ------ Forwarded Message > > > From: IETF I-D Submission Tool > > > Date: Mon, 1 Mar 2010 09:03:48 -0800 (PST) > > > To: Brian Rosen > > > Cc: Henning Schulzrinne > > > Subject: New Version Notification for > > > draft-rosen-ecrit-completed-location-00 > > > > > > > > > A new version of I-D, draft-rosen-ecrit-completed-location-00.txt has > > > been > > > successfuly submitted by Brian Rosen and posted to the IETF > repository. > > > > > > Filename: draft-rosen-ecrit-completed-location > > > Revision: 00 > > > Title: Completing the Request Location > > > Creation_date: 2010-03-01 > > > WG ID: Independent Submission > > > Number_of_pages: 14 > > > > > > Abstract: > > > This document defines an extension to LoST (RFC5222) that allows a > > > request to specify that a PIDF be returned in the response if the > > > location was valid, but there were some missing elements. For > > > example, an civic location that did not include a postal code, but > > > was otherwise a complete, and unambiguous location, would receive a > > > complete PIDF in the response that included the postal code. > > > > > > > > > > > > The IETF Secretariat. > > > > > > > > > > > > ------ End of Forwarded Message > > > > > > > > > _______________________________________________ > > > 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 jmpolk@cisco.com Mon Mar 1 18:38:41 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ED7128C231 for ; Mon, 1 Mar 2010 18:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2E-a2-iRYdGH for ; Mon, 1 Mar 2010 18:38:39 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 2FD993A8A24 for ; Mon, 1 Mar 2010 18:38:38 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABMJjEurRN+K/2dsb2JhbACbBXOlE5gMgk+CLASDFw X-IronPort-AV: E=Sophos;i="4.49,564,1262563200"; d="scan'208";a="158907155" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 02 Mar 2010 02:38:32 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o222cWbG014593; Tue, 2 Mar 2010 02:38:32 GMT Message-Id: <201003020238.o222cWbG014593@sj-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 01 Mar 2010 20:38:32 -0600 To: "Winterbottom, James" , "Thomson, Martin" , Brian Rosen , "ecrit@ietf.org" From: "James M. Polk" In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120DBF555F3@SISPE7MB1.com mscope.com> References: <20100301170348.9D8303A8BA0@core3.amsl.com> <8B0A9FCBB9832F43971E38010638454F03DEF1EBFE@SISPE7MB1.commscope.com> <201003020109.o2219U7R021657@sj-core-4.cisco.com> <5A55A45AE77F5941B18E5457ECAC81880120DBF555F3@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Ecrit] FW:draft-rosen-ecrit-completed-location-00 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, 02 Mar 2010 02:38:41 -0000 you're right I fixated on the idea of location -- and didn't pull my head above what I was buried with enough to think more about this before replying. I apologize James At 08:25 PM 3/1/2010, Winterbottom, James wrote: >Unless I am seriously mistaken a LoST server doesn't get a PIDF-LO >today, it gets a location. There was considerable objection to >including a PIDF-LO in the original LoST query protocol on the >grounds that it included identity information EVEN if the identity >was an unlinked pseudonym. These were similar grounds as to why a >location URI was not deemed an acceptable input to a LoST server. > >I would like to understand why these issues are suddenly a non-argument. > >Cheers >James > > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > > James M. Polk > > Sent: Tuesday, 2 March 2010 12:09 PM > > To: Thomson, Martin; Brian Rosen; ecrit@ietf.org > > Subject: Re: [Ecrit] FW: New Version Notification for draft-rosen-ecrit- > > completed-location-00 > > > > At 07:01 PM 3/1/2010, Thomson, Martin wrote: > > >I think that there is a mistake here in talking about > > >PIDF-LO. Since the LoST server wont be given any identification > > >information, any PIDF-LO it creates would not include any useful > > identity. > > > > won't the LoST server have the identity from the PIDF-LO that was in > > the LoST request (i.e., to be copied from request to response)? > > > > > > >It seems that all you need to include in the response is the > > >corrected _location information_. > > > > Are we trying to save a few bytes here? What's the harm in including > > a complete 1 packet PIDF-LO response? > > > > James > > > > > > >--Martin > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of Brian Rosen > > > > Sent: Tuesday, 2 March 2010 10:03 AM > > > > To: ecrit@ietf.org > > > > Subject: [Ecrit] FW: New Version Notification for draft-rosen-ecrit- > > > > completed-location-00 > > > > > > > > In NENA, we really want to be able to send a complete PIDF-LO (every > > > > element > > > > we have) back to a LoST requester to sends us a PIDF that is valid > > > > (meaning, > > > > it's complete enough to dispatch responders), but doesn't have all the > > > > fields that the LoST server does. > > > > > > > > A good example is when you send a postal address. We have the actual > > > > municipal address. We would like to return that (the A3 element). > > > > > > > > Another example is when you send "North Main", without a "Street" > > > > suffix. > > > > If there are no other North Mains, then it's unique, and therefore > > > > valid, > > > > but we would like to get that "Street" suffix back. > > > > > > > > Currently, you can't get a PIDF back on a LoST response. This > > document > > > > adds > > > > an attribute for (requestCompletedLocation) that > > requests > > > > that > > > > a PIDF be sent in the response. It adds a PIDF in a > > > > element. > > > > > > > > Brian > > > > ------ Forwarded Message > > > > From: IETF I-D Submission Tool > > > > Date: Mon, 1 Mar 2010 09:03:48 -0800 (PST) > > > > To: Brian Rosen > > > > Cc: Henning Schulzrinne > > > > Subject: New Version Notification for > > > > draft-rosen-ecrit-completed-location-00 > > > > > > > > > > > > A new version of I-D, draft-rosen-ecrit-completed-location-00.txt has > > > > been > > > > successfuly submitted by Brian Rosen and posted to the IETF > > repository. > > > > > > > > Filename: draft-rosen-ecrit-completed-location > > > > Revision: 00 > > > > Title: Completing the Request Location > > > > Creation_date: 2010-03-01 > > > > WG ID: Independent Submission > > > > Number_of_pages: 14 > > > > > > > > Abstract: > > > > This document defines an extension to LoST (RFC5222) that allows a > > > > request to specify that a PIDF be returned in the response if the > > > > location was valid, but there were some missing elements. For > > > > example, an civic location that did not include a postal code, but > > > > was otherwise a complete, and unambiguous location, would receive a > > > > complete PIDF in the response that included the postal code. > > > > > > > > > > > > > > > > The IETF Secretariat. > > > > > > > > > > > > > > > > ------ End of Forwarded Message > > > > > > > > > > > > _______________________________________________ > > > > 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 br@brianrosen.net Tue Mar 2 05:10:37 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 78AF83A8963 for ; Tue, 2 Mar 2010 05:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.005, 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 18GSRDf3wVuM for ; Tue, 2 Mar 2010 05:10:34 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id 077313A893C for ; Tue, 2 Mar 2010 05:10:33 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.118]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1NmRrl-0005TP-N9; Tue, 02 Mar 2010 07:10:26 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 02 Mar 2010 08:10:10 -0500 From: Brian Rosen To: James Winterbottom , James Polk , "Thomson, Martin" , "ecrit@ietf.org" Message-ID: Thread-Topic: [Ecrit] FW: New Version Notification for draft-rosen-ecrit-completed-location-00 Thread-Index: Acq5qb7tRrc3N6dMSxiNYqdC7B4dzgABZevAABaWS5k= In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120DBF555F3@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 Subject: Re: [Ecrit] FW: New Version Notification for draft-rosen-ecrit-completed-location-00 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, 02 Mar 2010 13:10:37 -0000 You are correct. I will edit the text accordingly. Brian On 3/1/10 9:25 PM, "James Winterbottom" wrote: > Unless I am seriously mistaken a LoST server doesn't get a PIDF-LO today, it > gets a location. There was considerable objection to including a PIDF-LO in > the original LoST query protocol on the grounds that it included identity > information EVEN if the identity was an unlinked pseudonym. These were similar > grounds as to why a location URI was not deemed an acceptable input to a LoST > server. > > I would like to understand why these issues are suddenly a non-argument. > > Cheers > James > > > > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> James M. Polk >> Sent: Tuesday, 2 March 2010 12:09 PM >> To: Thomson, Martin; Brian Rosen; ecrit@ietf.org >> Subject: Re: [Ecrit] FW: New Version Notification for draft-rosen-ecrit- >> completed-location-00 >> >> At 07:01 PM 3/1/2010, Thomson, Martin wrote: >>> I think that there is a mistake here in talking about >>> PIDF-LO. Since the LoST server wont be given any identification >>> information, any PIDF-LO it creates would not include any useful >> identity. >> >> won't the LoST server have the identity from the PIDF-LO that was in >> the LoST request (i.e., to be copied from request to response)? >> >> >>> It seems that all you need to include in the response is the >>> corrected _location information_. >> >> Are we trying to save a few bytes here? What's the harm in including >> a complete 1 packet PIDF-LO response? >> >> James >> >> >>> --Martin >>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>>> Of Brian Rosen >>>> Sent: Tuesday, 2 March 2010 10:03 AM >>>> To: ecrit@ietf.org >>>> Subject: [Ecrit] FW: New Version Notification for draft-rosen-ecrit- >>>> completed-location-00 >>>> >>>> In NENA, we really want to be able to send a complete PIDF-LO (every >>>> element >>>> we have) back to a LoST requester to sends us a PIDF that is valid >>>> (meaning, >>>> it's complete enough to dispatch responders), but doesn't have all the >>>> fields that the LoST server does. >>>> >>>> A good example is when you send a postal address. We have the actual >>>> municipal address. We would like to return that (the A3 element). >>>> >>>> Another example is when you send "North Main", without a "Street" >>>> suffix. >>>> If there are no other North Mains, then it's unique, and therefore >>>> valid, >>>> but we would like to get that "Street" suffix back. >>>> >>>> Currently, you can't get a PIDF back on a LoST response. This >> document >>>> adds >>>> an attribute for (requestCompletedLocation) that >> requests >>>> that >>>> a PIDF be sent in the response. It adds a PIDF in a >>>> element. >>>> >>>> Brian >>>> ------ Forwarded Message >>>> From: IETF I-D Submission Tool >>>> Date: Mon, 1 Mar 2010 09:03:48 -0800 (PST) >>>> To: Brian Rosen >>>> Cc: Henning Schulzrinne >>>> Subject: New Version Notification for >>>> draft-rosen-ecrit-completed-location-00 >>>> >>>> >>>> A new version of I-D, draft-rosen-ecrit-completed-location-00.txt has >>>> been >>>> successfuly submitted by Brian Rosen and posted to the IETF >> repository. >>>> >>>> Filename: draft-rosen-ecrit-completed-location >>>> Revision: 00 >>>> Title: Completing the Request Location >>>> Creation_date: 2010-03-01 >>>> WG ID: Independent Submission >>>> Number_of_pages: 14 >>>> >>>> Abstract: >>>> This document defines an extension to LoST (RFC5222) that allows a >>>> request to specify that a PIDF be returned in the response if the >>>> location was valid, but there were some missing elements. For >>>> example, an civic location that did not include a postal code, but >>>> was otherwise a complete, and unambiguous location, would receive a >>>> complete PIDF in the response that included the postal code. >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>>> >>>> ------ End of Forwarded Message >>>> >>>> >>>> _______________________________________________ >>>> 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 hannes.tschofenig@nsn.com Tue Mar 2 05:16:36 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5473A8940 for ; Tue, 2 Mar 2010 05:16:36 -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 RDJ3I2EJIRwn for ; Tue, 2 Mar 2010 05:16:35 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id D0CA53A8926 for ; Tue, 2 Mar 2010 05:16:34 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o22DGX7l004207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 2 Mar 2010 14:16:33 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o22DGXGi030268 for ; Tue, 2 Mar 2010 14:16:33 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 14:16:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Mar 2010 15:15:56 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502424029@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECRIT Agenda (version 1) Thread-Index: Acq6Cn4choM+BTeiQWSpPxYsyv7nvQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 02 Mar 2010 13:16:33.0313 (UTC) FILETIME=[943FD110:01CABA0A] Subject: [Ecrit] ECRIT Agenda (version 1) 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, 02 Mar 2010 13:16:36 -0000 ECRIT Meeting Agenda =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MONDAY, March 22, 2010 0900-1130 Morning Session I=20 Room: Palos Verdes * Agenda Bashing and Status Update (Marc, Hannes, Roger) * PSAP Callback (TBD) http://trac.tools.ietf.org/wg/ecrit/trac/wiki http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback Intention: Discuss potential feedback from emergency services groups on the requirements for this work. * Unauthenticated emergency services (Dirk) http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access Intention: Determine next steps. The group wants to work on it but there are still lots of open issues and re-chartering is required to add it to the milestone list.=20 * Transformations ID (James P.)=20 http://tools.ietf.org/id/draft-polk-ecrit-lost-transformations-urn Intention: TBD. * ECRIT Direct (James W.) http://tools.ietf.org/id/draft-winterbottom-ecrit-direct Intention: TBD.=20 * Additional Data (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-additional-data Intention: Initial document version. Presentation of the history and the origin of the work. Determine interest. * Data Only Emergency Calls (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-data-only-ea Intention: TBD. --=20 Have not gotten requests for the following items: * Service URN Update and Service Classification http://tools.ietf.org/id/draft-forte-ecrit-service-classification http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy =20 * Completing the Request Location http://tools.ietf.org/id/draft-rosen-ecrit-completed-location-00.txt * Emergency Text Messaging using SIP MESSAGE http://tools.ietf.org/id/draft-kim-ecrit-text-00.txt * ECRIT RPH http://tools.ietf.org/html/draft-ietf-ecrit-local-emergency-rph-namespac e From hannes.tschofenig@nsn.com Tue Mar 2 06:13:13 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E0093A8A37 for ; Tue, 2 Mar 2010 06:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5d1LSQrmNCM for ; Tue, 2 Mar 2010 06:13:12 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 925FF3A8965 for ; Tue, 2 Mar 2010 06:13:11 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o22ED9iS024142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 2 Mar 2010 15:13:10 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o22ED9OA030941 for ; Tue, 2 Mar 2010 15:13:09 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 15:13:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Mar 2010 16:12:31 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45024240C7@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECRIT Agenda Version 2 Thread-Index: Acq6EmYUR3tglNeRQ9S7oW5NfqxUxQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 02 Mar 2010 14:13:08.0338 (UTC) FILETIME=[7BD78520:01CABA12] Subject: [Ecrit] ECRIT Agenda Version 2 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, 02 Mar 2010 14:13:13 -0000 ECRIT Meeting Agenda (Version 2) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D MONDAY, March 22, 2010 0900-1130 Morning Session I=20 Room: Palos Verdes * Agenda Bashing and Status Update (Marc, Hannes, Roger) * PSAP Callback (TBD) http://trac.tools.ietf.org/wg/ecrit/trac/wiki http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback Intention: Discuss potential feedback from emergency services groups on the requirements for this work. * Unauthenticated emergency services (Dirk) http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access Intention: Determine next steps. The group wants to work on it but there are still lots of open issues and re-chartering is required to add it to the milestone list.=20 * Transformations ID (James P.) http://tools.ietf.org/id/draft-polk-ecrit-lost-transformations-urn Intention: TBD. * ECRIT Direct (James W.) http://tools.ietf.org/id/draft-winterbottom-ecrit-direct Intention: TBD.=20 * Additional Data (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-additional-data Intention: Initial document version. Presentation of the history and the origin of the work. Determine interest. * Data Only Emergency Calls (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-data-only-ea Intention: TBD. * Completing the Request Location (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-completed-location-00.txt Intention: Discussion whether the group should work on this document.=20 The document is making a normative change to RFC 5222. * Service URN Update and Service Classification (Henning) http://tools.ietf.org/id/draft-forte-ecrit-service-classification http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy =20 Intention: Documents are a bit stuck although group agreed to work on it.=20 Henning will present a way forward.=20 * Emergency Text Messaging using SIP MESSAGE (Henning) http://tools.ietf.org/id/draft-kim-ecrit-text-00.txt Intention: Discussion about what the group should do in this area. From Hannes.Tschofenig@gmx.net Wed Mar 3 11:11:56 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 687D23A8C5C for ; Wed, 3 Mar 2010 11:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 WL8rKutWfHmj for ; Wed, 3 Mar 2010 11:11:55 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0E72F3A8C07 for ; Wed, 3 Mar 2010 11:11:53 -0800 (PST) Received: (qmail invoked by alias); 03 Mar 2010 19:11:49 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.255.4]) [88.115.222.204] by mail.gmx.net (mp068) with SMTP; 03 Mar 2010 20:11:49 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Q8MdjmKqQfISMOhDwF/PSSLMkvGhCh37s8ftiA0 jXCtxJ/i265qS+ Message-ID: <4B8EB446.2080808@gmx.net> Date: Wed, 03 Mar 2010 21:11:02 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: 'ECRIT' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58999999999999997 Subject: [Ecrit] PSAP Callback -- Questions I distributed 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, 03 Mar 2010 19:11:56 -0000 I thought I had forwarded my mail to the ECRIT list but obviously I failed todo so. Here is the text I sent to NENA, EENA, and ETSI EMTEL. My hope is to have some initial feedback for discussion at the next IETF meeting. I got some responses already. So, things are looking good and I am sending out messages to individual people from emergency services organizations as well. Ciao Hannes ------------------- Hi all, To progress the work on PSAP callback in the IETF ECRIT group we are soliciting feedback from this group. A little bit of background first: When you make an IP-based emergency call to an IP-based PSAP then the PSAP will get two pieces of identity information about the emergency caller: * Contact-URI: Information that uniquely identifies the device the call came from. * Address of Record: Long-term contact information Imagine that the communication between the PSAP and the emergency caller gets interrupted prematurely and the PSAP wants to call back to the emergency caller, for example to obtain more information about the incident. The idea of the ongoing PSAP callback work is to allow the emergency call to override any call forwarding Procedures configured by the emergency caller's phone, do not disturb functionality, etc. so that the call indeed reaches the emergency caller. This includes the ability to disable network based services, such as network based call forwarding, in addition to functionality configured at the phone itself. 1st question: What functionality is available in today's CS networks? 2nd question: Is this useful functionality to have for IP-based emergency services? 3rd question: Do you envision a time-restriction on this capability? Example: only within one hour callbacks from the PSAP are treated differently to normal calls. 4th question: Would you expect the call to reach primarily the device that initiated the emergency call? 5th question: In some cases the device that was used to originally initiate the call does not respond anymore to a callback (e.g. imagine a fixed line phone that was used to report a fire in a house and is out of order soon afterwards). Since the initial emergency call provided a second contact mechanism (namely the address of record) it could be used by the call taker as well. Should this communication also experience the same type of override privilege as the initially transmitted callback to the emergency caller's device? Thank you for your time. Your feedback is very valuable to us. Ciao Hannes From gunnar.hellstrom@omnitor.se Wed Mar 3 11:44:21 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 C0EEA28C485 for ; Wed, 3 Mar 2010 11:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.244 X-Spam-Level: X-Spam-Status: No, score=0.244 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, MSGID_MULTIPLE_AT=1.449] 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 fVR4dYjn8-Be for ; Wed, 3 Mar 2010 11:44:20 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 4B0BA28C48E for ; Wed, 3 Mar 2010 11:44:20 -0800 (PST) Received: from s19.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id F34B32BAE4E for ; Wed, 3 Mar 2010 20:43:23 +0100 (CET) Received: (qmail 91466 invoked from network); 3 Mar 2010 19:43:16 -0000 Received: from h16n1fls34o265.telia.com (HELO AllaneCDator) (gunnar.hellstrom@omnitor.se@[213.64.232.16]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 3 Mar 2010 19:43:16 -0000 From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "'Hannes Tschofenig'" , "'ECRIT'" References: <4B8EB446.2080808@gmx.net> In-Reply-To: <4B8EB446.2080808@gmx.net> Date: Wed, 3 Mar 2010 20:43:18 +0100 Message-ID: <00c501cabb09$c695db50$53c191f0$@hellstrom@omnitor.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq7BWb04R0zsHNNQba8aaHnSl9OQwAAnuCw Content-Language: sv Subject: Re: [Ecrit] PSAP Callback -- Questions I distributed 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, 03 Mar 2010 19:44:21 -0000 Hannes, You say: "The idea of the ongoing PSAP callback work is to allow the emergency call to override any call forwarding Procedures configured by the emergency caller's phone, do not disturb functionality, etc. so that the call indeed reaches the emergency caller. This includes the ability to disable network based services, such as network based call forwarding, in addition to functionality configured at the phone itself." I have warned a number of times that this functionality sound contra productive against the mechanisms in use or planned for automatic relay service invocation. There may be very important network based call forwarding, or phone configured call forwarding functions involved in making the call reach both the user and a suitable coaching service (e.g. relay service ). If these functions are put out of operation when the PSAP calls back, you will end up with a call taker and a user with a connected call, but without a chance to understand each other. I think we need to create a coaching service invocation draft in parallel with the callback drafting, and verify that the callback requirements you talk about do not destroy the opportunities to get coaching services invoked in callback calls. Gunnar -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Wednesday, March 03, 2010 8:11 PM To: 'ECRIT' Subject: [Ecrit] PSAP Callback -- Questions I distributed I thought I had forwarded my mail to the ECRIT list but obviously I failed todo so. Here is the text I sent to NENA, EENA, and ETSI EMTEL. My hope is to have some initial feedback for discussion at the next IETF meeting. I got some responses already. So, things are looking good and I am sending out messages to individual people from emergency services organizations as well. Ciao Hannes ------------------- Hi all, To progress the work on PSAP callback in the IETF ECRIT group we are soliciting feedback from this group. A little bit of background first: When you make an IP-based emergency call to an IP-based PSAP then the PSAP will get two pieces of identity information about the emergency caller: * Contact-URI: Information that uniquely identifies the device the call came from. * Address of Record: Long-term contact information Imagine that the communication between the PSAP and the emergency caller gets interrupted prematurely and the PSAP wants to call back to the emergency caller, for example to obtain more information about the incident. The idea of the ongoing PSAP callback work is to allow the emergency call to override any call forwarding Procedures configured by the emergency caller's phone, do not disturb functionality, etc. so that the call indeed reaches the emergency caller. This includes the ability to disable network based services, such as network based call forwarding, in addition to functionality configured at the phone itself. 1st question: What functionality is available in today's CS networks? 2nd question: Is this useful functionality to have for IP-based emergency services? 3rd question: Do you envision a time-restriction on this capability? Example: only within one hour callbacks from the PSAP are treated differently to normal calls. 4th question: Would you expect the call to reach primarily the device that initiated the emergency call? 5th question: In some cases the device that was used to originally initiate the call does not respond anymore to a callback (e.g. imagine a fixed line phone that was used to report a fire in a house and is out of order soon afterwards). Since the initial emergency call provided a second contact mechanism (namely the address of record) it could be used by the call taker as well. Should this communication also experience the same type of override privilege as the initially transmitted callback to the emergency caller's device? Thank you for your time. Your feedback is very valuable to us. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit __________ NOD32 4913 (20100303) Information __________ Detta meddelande dr genomsvkt av NOD32 Antivirus. http://www.nod32.com From br@brianrosen.net Wed Mar 3 11:55:11 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 9614128C4B3 for ; Wed, 3 Mar 2010 11:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQ0jBr7DdbcR for ; Wed, 3 Mar 2010 11:55:09 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id F3F0C28C4A0 for ; Wed, 3 Mar 2010 11:55:06 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.118]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nmuem-0003qs-2W; Wed, 03 Mar 2010 13:54:56 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 03 Mar 2010 14:54:53 -0500 From: Brian Rosen To: Gunnar =?ISO-8859-1?B?SGVsbHN0cvZt?= , 'Hannes Tschofenig' , 'ECRIT' Message-ID: Thread-Topic: [Ecrit] PSAP Callback -- Questions I distributed Thread-Index: Acq7BWb04R0zsHNNQba8aaHnSl9OQwAAnuCwAADgYn8= In-Reply-To: <00c501cabb09$c695db50$53c191f0$@hellstrom@omnitor.se> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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 Subject: Re: [Ecrit] PSAP Callback -- Questions I distributed 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, 03 Mar 2010 19:55:11 -0000 In the U.S., this works, except in a very small percentage of cases where call forwarding is a permanent feature, and there is often no actual servic= e behind it (that is, no wire, no service, no device). You would call forwar= d in all circumstances. We implement the coaching (relay) service with normal PSTN routing, and not call forwarding. Brian On 3/3/10 2:43 PM, "Gunnar Hellstr=F6m" wrote: > Hannes, > You say: > "The idea of the ongoing PSAP callback work is to allow the emergency cal= l > to override any call forwarding Procedures configured by the emergency > caller's phone, do not disturb functionality, etc. so that the call indee= d > reaches the emergency caller. This includes the ability to disable networ= k > based services, such as network based call forwarding, in addition to > functionality configured at the phone itself." >=20 > I have warned a number of times that this functionality sound contra > productive against the mechanisms in use or planned for automatic relay > service invocation. There may be very important network based call > forwarding, or phone configured call forwarding functions involved in mak= ing > the call reach both the user and a suitable coaching service (e.g. relay > service ). If these functions are put out of operation when the PSAP call= s > back, you will end up with a call taker and a user with a connected call, > but without a chance to understand each other. >=20 > I think we need to create a coaching service invocation draft in parallel > with the callback drafting, and verify that the callback requirements you > talk about do not destroy the opportunities to get coaching services invo= ked > in callback calls. >=20 > Gunnar=20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Wednesday, March 03, 2010 8:11 PM > To: 'ECRIT' > Subject: [Ecrit] PSAP Callback -- Questions I distributed >=20 > I thought I had forwarded my mail to the ECRIT list but obviously I > failed todo so. Here is the text I sent to NENA, EENA, and ETSI EMTEL. > My hope is to have some initial feedback for discussion at the next IETF > meeting. I got some responses already. So, things are looking good and I > am sending out messages to individual people from emergency services > organizations as well. >=20 > Ciao > Hannes >=20 > ------------------- >=20 > Hi all, >=20 > To progress the work on PSAP callback in the IETF ECRIT group we are > soliciting feedback from this group. >=20 > A little bit of background first: When you make an IP-based emergency > call to an IP-based PSAP then the PSAP will get two pieces of identity > information about the emergency caller: >=20 > * Contact-URI: Information that uniquely identifies the device the > call came from. > * Address of Record: Long-term contact information >=20 > Imagine that the communication between the PSAP and the emergency caller > gets interrupted prematurely and the PSAP wants to call back to the > emergency caller, for example to obtain more information about the > incident. >=20 > The idea of the ongoing PSAP callback work is to allow the emergency > call to override any call forwarding Procedures configured by the > emergency caller's phone, do not disturb functionality, etc. so that the > call indeed reaches the emergency caller. This includes the ability to > disable network based services, such as network based call forwarding, > in addition to functionality configured at the phone itself. >=20 > 1st question: What functionality is available in today's CS networks? >=20 > 2nd question: Is this useful functionality to have for IP-based > emergency services? >=20 > 3rd question: Do you envision a time-restriction on this capability? > Example: only within one hour callbacks from the PSAP are treated > differently to normal calls. >=20 > 4th question: Would you expect the call to reach primarily the device > that initiated the emergency call? > =20 > 5th question: In some cases the device that was used to originally > initiate the call does not respond anymore to a callback (e.g. imagine a > fixed line phone that was used to report a fire in a house and is out of > order soon afterwards). Since the initial emergency call provided a > second contact mechanism (namely the address of record) it could be used > by the call taker as well. Should this communication also experience the > same type of override privilege as the initially transmitted callback to > the emergency caller's device? >=20 > Thank you for your time. Your feedback is very valuable to us. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > __________ NOD32 4913 (20100303) Information __________ >=20 > Detta meddelande dr genomsvkt av NOD32 Antivirus. > http://www.nod32.com >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From gunnar.hellstrom@omnitor.se Thu Mar 4 02:44:48 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 E3A7A3A8888 for ; Thu, 4 Mar 2010 02:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, MSGID_MULTIPLE_AT=1.449] 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 29nuaYt1ztZg for ; Thu, 4 Mar 2010 02:44:47 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 35F583A879A for ; Thu, 4 Mar 2010 02:44:47 -0800 (PST) Received: from s19.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 223432E4B64 for ; Thu, 4 Mar 2010 11:44:51 +0100 (CET) Received: (qmail 62135 invoked from network); 4 Mar 2010 10:44:47 -0000 Received: from dd577d029.access.telenet.be (HELO AllaneCDator) (gunnar.hellstrom@omnitor.se@[213.119.208.41]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 4 Mar 2010 10:44:47 -0000 From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "'Brian Rosen'" , "'Hannes Tschofenig'" , "'ECRIT'" References: <00c501cabb09$c695db50$53c191f0$@hellstrom@omnitor.se> In-Reply-To: Date: Thu, 4 Mar 2010 11:44:52 +0100 Message-ID: <021e01cabb87$b925ed10$2b71c730$@hellstrom@omnitor.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq7BWb04R0zsHNNQba8aaHnSl9OQwAAnuCwAADgYn8AAJiz0A== Content-Language: sv Subject: Re: [Ecrit] PSAP Callback -- Questions I distributed X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 10:44:49 -0000 The mechanism for callback including coaching services must still work, = even when the PSAP calls back with multimedia, and when "normal PSTN routing" = is not involved. We need to verify both that the information provided with the incoming = call is sufficient for the call back. Hannes says: "> * Contact-URI: Information that uniquely identifies the device the > call came from. > * Address of Record: Long-term contact information " Can these contain URI-lists, if that is selected to be the way a = coaching service and the calling user are supposed to be connected? Or are they single addresses resolved to multi-party calls by network elements. Do we need to add also a record of offered media or agreed media during = the incoming call, and use the same set for the callback?=20 Or will the PSAP always make the callback out with full Total = Conversation media offer (video, real-time text and audio) and accept to have the = call in the agreed subset of media? Gunnar -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, March 03, 2010 8:55 PM To: Gunnar Hellstr=F6m; 'Hannes Tschofenig'; 'ECRIT' Subject: Re: [Ecrit] PSAP Callback -- Questions I distributed In the U.S., this works, except in a very small percentage of cases = where call forwarding is a permanent feature, and there is often no actual = service behind it (that is, no wire, no service, no device). You would call = forward in all circumstances. We implement the coaching (relay) service with normal PSTN routing, and = not call forwarding. Brian On 3/3/10 2:43 PM, "Gunnar Hellstr=F6m" = wrote: > Hannes, > You say: > "The idea of the ongoing PSAP callback work is to allow the emergency = call > to override any call forwarding Procedures configured by the emergency > caller's phone, do not disturb functionality, etc. so that the call = indeed > reaches the emergency caller. This includes the ability to disable = network > based services, such as network based call forwarding, in addition to > functionality configured at the phone itself." >=20 > I have warned a number of times that this functionality sound contra > productive against the mechanisms in use or planned for automatic = relay > service invocation. There may be very important network based call > forwarding, or phone configured call forwarding functions involved in making > the call reach both the user and a suitable coaching service (e.g. = relay > service ). If these functions are put out of operation when the PSAP = calls > back, you will end up with a call taker and a user with a connected = call, > but without a chance to understand each other. >=20 > I think we need to create a coaching service invocation draft in = parallel > with the callback drafting, and verify that the callback requirements = you > talk about do not destroy the opportunities to get coaching services invoked > in callback calls. >=20 > Gunnar=20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of > Hannes Tschofenig > Sent: Wednesday, March 03, 2010 8:11 PM > To: 'ECRIT' > Subject: [Ecrit] PSAP Callback -- Questions I distributed >=20 > I thought I had forwarded my mail to the ECRIT list but obviously I > failed todo so. Here is the text I sent to NENA, EENA, and ETSI EMTEL. > My hope is to have some initial feedback for discussion at the next = IETF > meeting. I got some responses already. So, things are looking good and = I > am sending out messages to individual people from emergency services > organizations as well. >=20 > Ciao > Hannes >=20 > ------------------- >=20 > Hi all, >=20 > To progress the work on PSAP callback in the IETF ECRIT group we are > soliciting feedback from this group. >=20 > A little bit of background first: When you make an IP-based emergency > call to an IP-based PSAP then the PSAP will get two pieces of identity > information about the emergency caller: >=20 > * Contact-URI: Information that uniquely identifies the device the > call came from. > * Address of Record: Long-term contact information >=20 > Imagine that the communication between the PSAP and the emergency = caller > gets interrupted prematurely and the PSAP wants to call back to the > emergency caller, for example to obtain more information about the > incident. >=20 > The idea of the ongoing PSAP callback work is to allow the emergency > call to override any call forwarding Procedures configured by the > emergency caller's phone, do not disturb functionality, etc. so that = the > call indeed reaches the emergency caller. This includes the ability to > disable network based services, such as network based call forwarding, > in addition to functionality configured at the phone itself. >=20 > 1st question: What functionality is available in today's CS networks? >=20 > 2nd question: Is this useful functionality to have for IP-based > emergency services? >=20 > 3rd question: Do you envision a time-restriction on this capability? > Example: only within one hour callbacks from the PSAP are treated > differently to normal calls. >=20 > 4th question: Would you expect the call to reach primarily the device > that initiated the emergency call? > =20 > 5th question: In some cases the device that was used to originally > initiate the call does not respond anymore to a callback (e.g. imagine = a > fixed line phone that was used to report a fire in a house and is out = of > order soon afterwards). Since the initial emergency call provided a > second contact mechanism (namely the address of record) it could be = used > by the call taker as well. Should this communication also experience = the > same type of override privilege as the initially transmitted callback = to > the emergency caller's device? >=20 > Thank you for your time. Your feedback is very valuable to us. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > __________ NOD32 4913 (20100303) Information __________ >=20 > Detta meddelande dr genomsvkt av NOD32 Antivirus. > http://www.nod32.com >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit __________ NOD32 4913 (20100303) Information __________ Detta meddelande =E4r genoms=F6kt av NOD32 Antivirus. http://www.nod32.com From Hannes.Tschofenig@gmx.net Fri Mar 5 01:33:10 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 CAEF03A71D3 for ; Fri, 5 Mar 2010 01:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 UR-49lzq+k-P for ; Fri, 5 Mar 2010 01:33:10 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7E84C3A8F39 for ; Fri, 5 Mar 2010 01:33:09 -0800 (PST) Received: (qmail invoked by alias); 05 Mar 2010 09:33:10 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.255.4]) [88.115.222.204] by mail.gmx.net (mp006) with SMTP; 05 Mar 2010 10:33:10 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+G0PIXLUKG6EsIQWT6+5BPrJwZ7VkNDwdzg7upAf cWda4kigYUoDl6 Message-ID: <4B90CFB2.2070504@gmx.net> Date: Fri, 05 Mar 2010 11:32:34 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: 'ECRIT' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55000000000000004 Subject: [Ecrit] ECRIT Agenda Version 3 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, 05 Mar 2010 09:33:10 -0000 ECRIT Meeting Agenda (Version 3) ================================ MONDAY, March 22, 2010 0900-1130 Morning Session I Room: Palos Verdes * Agenda Bashing and Status Update (Marc, Hannes, Roger) * PSAP Callback (TBD) http://trac.tools.ietf.org/wg/ecrit/trac/wiki http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback Intention: Discuss potential feedback from emergency services groups on the requirements for this work. * Unauthenticated emergency services (Dirk) http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access Intention: Determine next steps. The group wants to work on it but there are still lots of open issues and re-chartering is required to add it to the milestone list. * Transformations ID (James P.) http://tools.ietf.org/id/draft-polk-ecrit-lost-transformations-urn Intention: TBD. * ECRIT Direct (James W.) http://tools.ietf.org/id/draft-winterbottom-ecrit-direct Intention: TBD. * Additional Data (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-additional-data Intention: Initial document version. Presentation of the history and the origin of the work. Determine interest. * Data Only Emergency Calls (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-data-only-ea Intention: TBD. * Completing the Request Location (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-completed-location-00.txt Intention: Discussion whether the group should work on this document. The document is making a normative change to RFC 5222. * Service URN Update and Service Classification (Henning) http://tools.ietf.org/id/draft-forte-ecrit-service-classification http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy Intention: Documents are a bit stuck although group agreed to work on it. Henning will present a way forward. * Emergency Text Messaging using SIP MESSAGE (Henning) http://tools.ietf.org/id/draft-kim-ecrit-text-00.txt Intention: Discussion about what the group should do in this area. * Describing Boundaries for Civic Addresse http://tools.ietf.org/id/draft-thomson-ecrit-civic-boundary-00.txt Intention: Discussion whether the group should work on this doc. From Hannes.Tschofenig@gmx.net Sat Mar 6 07:34:02 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 218C13A8D26 for ; Sat, 6 Mar 2010 07:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpAVdIcwrI7T for ; Sat, 6 Mar 2010 07:34:01 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C1B5A3A8C78 for ; Sat, 6 Mar 2010 07:33:59 -0800 (PST) Received: (qmail invoked by alias); 06 Mar 2010 15:34:02 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.255.4]) [88.115.222.204] by mail.gmx.net (mp036) with SMTP; 06 Mar 2010 16:34:02 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19rx18kUV5rNwL4A3F7R3v77TYHuqud9tnJQ0/7ub ARhVXBG0xSlxq4 Message-ID: <4B9275C7.7070109@gmx.net> Date: Sat, 06 Mar 2010 17:33:27 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: karlheinz.wolf@nic.at Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.62 Cc: 'ECRIT' Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-lost-sync-08.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: Sat, 06 Mar 2010 15:34:02 -0000 Thanks for your comment below. I updated the draft accordingly. Ciao Hannes --- Hannes, I just noticed the following misleading sentence in lost-sync, Section 3.3: In this example a request is made for a specific mapping (with source="authoritative.bar.example" and sourceId="7e3f40b098c711dbb6060800200c9a66") that is more recent than "2006-11-01T01:00:00Z". Since a getMappingsRequest with does not only request updates of the existing mappings but also missing ones, I would suggest to make that explicit in the explanation of the example: In this example a request is made for a specific mapping (with source="authoritative.bar.example" and sourceId="7e3f40b098c711dbb6060800200c9a66") that is more recent than "2006-11-01T01:00:00Z" as well as any missing mapping. Would this make the example clearer? Karl heinz From Hannes.Tschofenig@gmx.net Sat Mar 6 12:41:41 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D92D28C1F9 for ; Sat, 6 Mar 2010 12:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 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 eN-wiQ0WE+40 for ; Sat, 6 Mar 2010 12:41:40 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id A67E928C0F0 for ; Sat, 6 Mar 2010 12:41:39 -0800 (PST) Received: (qmail invoked by alias); 06 Mar 2010 20:41:41 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.255.4]) [88.115.222.204] by mail.gmx.net (mp031) with SMTP; 06 Mar 2010 21:41:41 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/BFeoDaC3BIa/+kW/Y3wrFowhTvTRL3ALrICURLd nBvobHJ7GHey25 Message-ID: <4B92BDE1.3000508@gmx.net> Date: Sat, 06 Mar 2010 22:41:05 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexander Mayrhofer Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.56999999999999995 Cc: 'ECRIT' Subject: [Ecrit] re - LoST-Synchronization & Loop prevention? 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, 06 Mar 2010 20:41:41 -0000 Hi Alex, thanks a lot for your feedback. We should definitely capture it in the document. The security aspect of came up in the context of LoST when the synchronization mechanisms was still meant to go into what is now RFC 5222. http://tools.ietf.org/html/rfc5582#section-10 captures some of the aspects. Mentioning the loop aspect is a very good idea. I have updated the draft. Ciao Hannes ------- Hello, I've just thought about something that i haven't seen discussed in any of the documents yet. Assume that there are 3 forest guides, which have the following "sync relations". A -------- B \ / \ / \ / \ / C Assuming that "A" gets updated, it would then send Sync messages to B (and probably C). B in turn would probably redistribute the message received from A over to C (because from the perspective of B, it compromises new information to be distributed) - B wouldn't know that C has already received the information from A directly. I understand that "source", "sourceid" and "last updated" could be used to identify whether a message has already been seen. However, my guts feeling tells me that there could be situations in which a FG rewrites information that it has received, and essentially creates messages that cannot be correlated with the original message (or, simple implementation problems...) I understand it looks like NNTP - I'm just curious if loop prevention has been considered, and discussed in detail ... "injecting" a loop into the global network of FGs could be a very effective DoS attack... Alex ------------------------------------------------------------------------ From root@core3.amsl.com Sat Mar 6 12:45:02 2010 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 09F4828C202; Sat, 6 Mar 2010 12:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100306204502.09F4828C202@core3.amsl.com> Date: Sat, 6 Mar 2010 12:45:02 -0800 (PST) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-sync-09.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: Sat, 06 Mar 2010 20:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements Author(s) : H. Schulzrinne, H. Tschofenig Filename : draft-ietf-ecrit-lost-sync-09.txt Pages : 28 Date : 2010-03-06 The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The main data structure, the element, used for encapsulating information about service boundaries is defined in the LoST protocol specification and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative elements between two entities. Exchanging cached elements, i.e. non-authoritative elements, is possible but not envisioned. In any case, this document can also be used without the LoST protocol even though the format of the element is re-used from the LoST specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-lost-sync-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-06123940.I-D@ietf.org> --NextPart-- From Hannes.Tschofenig@gmx.net Sat Mar 6 12:45:29 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 18C6828C217 for ; Sat, 6 Mar 2010 12:45:29 -0800 (PST) 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 TmUwp78nz9bx for ; Sat, 6 Mar 2010 12:45:28 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B509328C20C for ; Sat, 6 Mar 2010 12:45:24 -0800 (PST) Received: (qmail invoked by alias); 06 Mar 2010 20:45:27 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.255.4]) [88.115.222.204] by mail.gmx.net (mp020) with SMTP; 06 Mar 2010 21:45:27 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/BRPgUMsXBkEKYgct7zauIZ/k6+PEWGhCaq9OQ1M hf7lnxELjjE6AE Message-ID: <4B92BEC3.2020707@gmx.net> Date: Sat, 06 Mar 2010 22:44:51 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: 'ECRIT' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.68000000000000005 Subject: [Ecrit] LoST Sync Update 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, 06 Mar 2010 20:45:29 -0000 I have re-submitted a version of the LoST sync document. The update reflects the comments from Karl Heinz and Alex. As you have seen, I have solicited feedback from the XML / Relax NG experts regarding the schema. I hope to get a response soon. I would also like to get some feedback from comments I filed against the NENA i3 stage 3 specification. The NENA spec hints to a different synchronization mechanisms (as Brian mentioned already many times) but I failed to understand how it works. I would like to see what the similarity and the differences are. Since the i3 spec is supposed to be completed very soon I assume clarifications regarding the synchronization aspects will have to get discussed as well. Ciao Hannes From br@brianrosen.net Sat Mar 6 13:34:00 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 1B97728C1A3 for ; Sat, 6 Mar 2010 13:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=-0.092, 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 XOtwvbHBu1OT for ; Sat, 6 Mar 2010 13:33:59 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id 3881828C173 for ; Sat, 6 Mar 2010 13:33:59 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.118]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1No1d9-0004ei-87; Sat, 06 Mar 2010 15:33:51 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Sat, 06 Mar 2010 16:33:50 -0500 From: Brian Rosen To: Hannes Tschofenig , 'ECRIT' Message-ID: Thread-Topic: [Ecrit] LoST Sync Update Thread-Index: Acq9dLXzhHr7JbdAME2P4lHCjcnJmg== In-Reply-To: <4B92BEC3.2020707@gmx.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 Subject: Re: [Ecrit] LoST Sync Update 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, 06 Mar 2010 21:34:00 -0000 In the NENA i3 scheme, the interface to the LoST server is a set of GIS layers, and specifically, there are sets of polygons that define service boundaries. Each of these boundaries has attributes for the service URN URI, etc that are returned in the LosT response when the query location is found within the boundary. For a civic address on the query, in theory, the LoST server does a geocode and then point-in-polygon, but an implementation can compute a table to do lookups for civics. The provisioning interface is a layer replication mechanism that uses two parts: 1. A Web Feature Service (an OGC standard that does insert/delete/modify operations) 2. An RSS feed of WFS commands We have a "master GIS" that contains the layers that the LoST server needs. These include polygons for the political boundaries, plus either (or both) centerlines or road geometry, address points or parcel/subparcel polygons, etc. There is a feature layer or attribute on a feature for each of the CAtypes. As normal GIS maintenance is performed on the master (adding streets, changing boundaries, etc.), the WFS commands that replicate that change are sent as an RSS feed to the LoST server, which replicates the edits on its database, maintaining synchrony with the master. We allow the LoST server to have an OUTPUT layer replication service, which is used on an aggregating LoST server. For example, each county in a state could have a LoST server, and the state could have a LoST server which is the aggregate of the individual counties. There is a gap/overlap reporting mechanism for this. One of the primary goals for this mechanism is to enable the boundaries to be changed on the GIS system by a normal edit function, and post the cache TTL, routes changes happen immediately. We use this in disaster scenarios when our other mechanisms to reroute calls don't work for the actual situation on the ground. Brian On 3/6/10 3:44 PM, "Hannes Tschofenig" wrote: > I have re-submitted a version of the LoST sync document. > The update reflects the comments from Karl Heinz and Alex. > > As you have seen, I have solicited feedback from the XML / Relax NG > experts regarding the schema. I hope to get a response soon. > > I would also like to get some feedback from comments I filed against the > NENA i3 stage 3 specification. The NENA spec hints to a different > synchronization mechanisms (as Brian mentioned already many times) but I > failed to understand how it works. I would like to see what the > similarity and the differences are. Since the i3 spec is supposed to be > completed very soon I assume clarifications regarding the > synchronization aspects will have to get discussed as well. > > Ciao > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hgs@cs.columbia.edu Sat Mar 6 14:13:24 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 5AA2B3A8BD2 for ; Sat, 6 Mar 2010 14:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 Mey83DZRVe2r for ; Sat, 6 Mar 2010 14:13:17 -0800 (PST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 37EC03A7984 for ; Sat, 6 Mar 2010 14:13:17 -0800 (PST) Received: from new-host-3.home (pool-173-54-225-147.nwrknj.fios.verizon.net [173.54.225.147]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o26MDGV3012127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 6 Mar 2010 17:13:17 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: Date: Sat, 6 Mar 2010 17:13:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1E5344DA-AB31-447A-8613-1DA1FE28FC80@cs.columbia.edu> References: To: Brian Rosen X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: 'ECRIT' Subject: Re: [Ecrit] LoST Sync Update 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, 06 Mar 2010 22:13:25 -0000 An RSS (I hope you're at least following IETF standards and using = ATOM...) feed is, as far as I understand, one long set of XML records. = This isn't a problem for a newsfeed on Slashdot, since the system = presumably exports only a day's worth of stories, but it's unclear to me = how this would work for updates that could span years. Would each server = get the full list of operations going back to the dawn of time and then = has to sort out which ones it has already performed? If not, what = happens when a new server joins? (RSS is also a "pull" format, i.e., = involves polling, which isn't ideal, but probably won't matter much for = the small number of RSS clients hanging of a GIS database.) Henning On Mar 6, 2010, at 4:33 PM, Brian Rosen wrote: > In the NENA i3 scheme, the interface to the LoST server is a set of = GIS > layers, and specifically, there are sets of polygons that define = service > boundaries. Each of these boundaries has attributes for the service = URN > URI, etc that are returned in the LosT response when the query = location is > found within the boundary. >=20 > For a civic address on the query, in theory, the LoST server does a = geocode > and then point-in-polygon, but an implementation can compute a table = to do > lookups for civics. >=20 > The provisioning interface is a layer replication mechanism that uses = two > parts: > 1. A Web Feature Service (an OGC standard that does = insert/delete/modify > operations) > 2. An RSS feed of WFS commands >=20 > We have a "master GIS" that contains the layers that the LoST server = needs. > These include polygons for the political boundaries, plus either (or = both) > centerlines or road geometry, address points or parcel/subparcel = polygons, > etc. There is a feature layer or attribute on a feature for each of = the > CAtypes. >=20 > As normal GIS maintenance is performed on the master (adding streets, > changing boundaries, etc.), the WFS commands that replicate that = change are > sent as an RSS feed to the LoST server, which replicates the edits on = its > database, maintaining synchrony with the master. >=20 > We allow the LoST server to have an OUTPUT layer replication service, = which > is used on an aggregating LoST server. For example, each county in a = state > could have a LoST server, and the state could have a LoST server which = is > the aggregate of the individual counties. There is a gap/overlap = reporting > mechanism for this. >=20 > One of the primary goals for this mechanism is to enable the = boundaries to > be changed on the GIS system by a normal edit function, and post the = cache > TTL, routes changes happen immediately. We use this in disaster = scenarios > when our other mechanisms to reroute calls don't work for the actual > situation on the ground. >=20 > Brian >=20 >=20 > On 3/6/10 3:44 PM, "Hannes Tschofenig" = wrote: >=20 >> I have re-submitted a version of the LoST sync document. >> The update reflects the comments from Karl Heinz and Alex. >>=20 >> As you have seen, I have solicited feedback from the XML / Relax NG >> experts regarding the schema. I hope to get a response soon. >>=20 >> I would also like to get some feedback from comments I filed against = the >> NENA i3 stage 3 specification. The NENA spec hints to a different >> synchronization mechanisms (as Brian mentioned already many times) = but I >> failed to understand how it works. I would like to see what the >> similarity and the differences are. Since the i3 spec is supposed to = be >> completed very soon I assume clarifications regarding the >> synchronization aspects will have to get discussed as well. >>=20 >> Ciao >> Hannes >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From gunnar.hellstrom@omnitor.se Sat Mar 6 14:15:17 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 9F3B93A8E3C for ; Sat, 6 Mar 2010 14:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.128 X-Spam-Level: X-Spam-Status: No, score=-0.128 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, MSGID_MULTIPLE_AT=1.449] 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 yU5NWsPUA7oT for ; Sat, 6 Mar 2010 14:15:16 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id A5A173A7984 for ; Sat, 6 Mar 2010 14:15:16 -0800 (PST) Received: from s128.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 059412E627A for ; Sat, 6 Mar 2010 23:14:51 +0100 (CET) Received: (qmail 35463 invoked from network); 6 Mar 2010 22:14:41 -0000 Received: from h16n1fls34o265.telia.com (HELO AllaneCDator) (gunnar.hellstrom@omnitor.se@[213.64.232.16]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 6 Mar 2010 22:14:41 -0000 From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "Ecrit@Ietf. Org" , "Brian Rosen" References: <20100306100001.874933A77D0@core3.amsl.com> In-Reply-To: <20100306100001.874933A77D0@core3.amsl.com> Date: Sat, 6 Mar 2010 23:14:51 +0100 Message-ID: <00ea01cabd7a$71a99780$54fcc680$@hellstrom@omnitor.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq9E96XIjCGUc7pQaCiz2ocft9J1gAZKlgA Content-Language: sv Subject: Re: [Ecrit] I-D Action:draft-rosen-ecrit-ecall-03.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: Sat, 06 Mar 2010 22:15:17 -0000 Hi, In chapter 3 of this draft, there is a sentence about media saying: "Media: Real-time text and video may be supported in devices some time in the future." If this draft makes its way to be a published RFC, the expression "some time in the future" will postpone the introduction of these media forever. That is not wanted. I suggest that you delete "some time in the future". The "may" carries sufficient uncertainty to delay its introduction if it is not found feasible from the outset to provide more media than audio. The resulting sentence is proposed to be: "Media: Real-time text and video may be supported in devices." /Gunnar -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Saturday, March 06, 2010 11:00 AM To: i-d-announce@ietf.org Subject: I-D Action:draft-rosen-ecrit-ecall-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Best Current Practice for IP-based In-Vehicle Emergency Calls Author(s) : B. Rosen, et al. Filename : draft-rosen-ecrit-ecall-03.txt Pages : 17 Date : 2010-03-06 This document describes how to use a subset of the IETF-based emergency call framework for accomplishing emergency calling support in vehicles. Simplifications are possible due to the nature of the functionality that is going to be provided in vehicles with the usage of GPS. Additionally, further profiling needs to be done regarding the encoding of location information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosen-ecrit-ecall-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From br@brianrosen.net Sat Mar 6 16:47:03 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 DA8AA28C21E for ; Sat, 6 Mar 2010 16:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 52FWNJWZfiJT for ; Sat, 6 Mar 2010 16:47:02 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id DB8D528C21D for ; Sat, 6 Mar 2010 16:47:02 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.118]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1No4du-0006Em-BL; Sat, 06 Mar 2010 18:46:50 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Sat, 06 Mar 2010 19:46:56 -0500 From: Brian Rosen To: Henning Schulzrinne Message-ID: Thread-Topic: [Ecrit] LoST Sync Update Thread-Index: Acq9j6+/tjfBu7kbu06QW6YVwl4oLQ== In-Reply-To: <1E5344DA-AB31-447A-8613-1DA1FE28FC80@cs.columbia.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 Cc: 'ECRIT' Subject: Re: [Ecrit] LoST Sync Update 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: Sun, 07 Mar 2010 00:47:04 -0000 Yes, it's ATOM. I'm not an ATOM expert, but there is some kind of record ID and some way to filter updates. We will "checkpoint" from time to time: get a fresh copy of the entire layer, and start implementing updates from that point. Brian On 3/6/10 5:13 PM, "Henning Schulzrinne" wrote: > An RSS (I hope you're at least following IETF standards and using ATOM...) > feed is, as far as I understand, one long set of XML records. This isn't a > problem for a newsfeed on Slashdot, since the system presumably exports only a > day's worth of stories, but it's unclear to me how this would work for updates > that could span years. Would each server get the full list of operations going > back to the dawn of time and then has to sort out which ones it has already > performed? If not, what happens when a new server joins? (RSS is also a "pull" > format, i.e., involves polling, which isn't ideal, but probably won't matter > much for the small number of RSS clients hanging of a GIS database.) > > Henning > > On Mar 6, 2010, at 4:33 PM, Brian Rosen wrote: > >> In the NENA i3 scheme, the interface to the LoST server is a set of GIS >> layers, and specifically, there are sets of polygons that define service >> boundaries. Each of these boundaries has attributes for the service URN >> URI, etc that are returned in the LosT response when the query location is >> found within the boundary. >> >> For a civic address on the query, in theory, the LoST server does a geocode >> and then point-in-polygon, but an implementation can compute a table to do >> lookups for civics. >> >> The provisioning interface is a layer replication mechanism that uses two >> parts: >> 1. A Web Feature Service (an OGC standard that does insert/delete/modify >> operations) >> 2. An RSS feed of WFS commands >> >> We have a "master GIS" that contains the layers that the LoST server needs. >> These include polygons for the political boundaries, plus either (or both) >> centerlines or road geometry, address points or parcel/subparcel polygons, >> etc. There is a feature layer or attribute on a feature for each of the >> CAtypes. >> >> As normal GIS maintenance is performed on the master (adding streets, >> changing boundaries, etc.), the WFS commands that replicate that change are >> sent as an RSS feed to the LoST server, which replicates the edits on its >> database, maintaining synchrony with the master. >> >> We allow the LoST server to have an OUTPUT layer replication service, which >> is used on an aggregating LoST server. For example, each county in a state >> could have a LoST server, and the state could have a LoST server which is >> the aggregate of the individual counties. There is a gap/overlap reporting >> mechanism for this. >> >> One of the primary goals for this mechanism is to enable the boundaries to >> be changed on the GIS system by a normal edit function, and post the cache >> TTL, routes changes happen immediately. We use this in disaster scenarios >> when our other mechanisms to reroute calls don't work for the actual >> situation on the ground. >> >> Brian >> >> >> On 3/6/10 3:44 PM, "Hannes Tschofenig" wrote: >> >>> I have re-submitted a version of the LoST sync document. >>> The update reflects the comments from Karl Heinz and Alex. >>> >>> As you have seen, I have solicited feedback from the XML / Relax NG >>> experts regarding the schema. I hope to get a response soon. >>> >>> I would also like to get some feedback from comments I filed against the >>> NENA i3 stage 3 specification. The NENA spec hints to a different >>> synchronization mechanisms (as Brian mentioned already many times) but I >>> failed to understand how it works. I would like to see what the >>> similarity and the differences are. Since the i3 spec is supposed to be >>> completed very soon I assume clarifications regarding the >>> synchronization aspects will have to get discussed as well. >>> >>> 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 Hannes.Tschofenig@gmx.net Sat Mar 6 23:01:17 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 63B4E3A9084 for ; Sat, 6 Mar 2010 23:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kX9n2U9fg5hN for ; Sat, 6 Mar 2010 23:01:16 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 335A13A9087 for ; Sat, 6 Mar 2010 23:01:15 -0800 (PST) Received: (qmail invoked by alias); 07 Mar 2010 07:01:18 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.255.4]) [88.115.222.204] by mail.gmx.net (mp031) with SMTP; 07 Mar 2010 08:01:18 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+iuRh9tbai9RhlkbqyZ1gzDEaXqq5NCAvh5Mp8Zw bsBUGBw4cMsF+/ Message-ID: <4B934F19.5010807@gmx.net> Date: Sun, 07 Mar 2010 09:00:41 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= References: <20100306100001.874933A77D0@core3.amsl.com> <00ea01cabd7a$71a99780$54fcc680$@hellstrom@omnitor.se> In-Reply-To: <00ea01cabd7a$71a99780$54fcc680$@hellstrom@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54000000000000004 Cc: "Ecrit@Ietf. Org" Subject: Re: [Ecrit] I-D Action:draft-rosen-ecrit-ecall-03.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: Sun, 07 Mar 2010 07:01:17 -0000 Hi Gunnar, this document refers to emergency calls in vehicles. The standardization efforts I have seen in that space barely talk about voice support and I have not seen any video or real-time text being mentioned. I am specifically referring the work done in Europe (as part of the eCall effort -- hence the name of the draft). While I agree with you in general I was trying to be closer to what is being standardized in other groups. Did I miss something or do you think we should be a bit more proactive here? Ciao Hannes Gunnar Hellström wrote: > Hi, > In chapter 3 of this draft, there is a sentence about media saying: > > "Media: Real-time text and video may be supported in devices some > time in the future." > > If this draft makes its way to be a published RFC, the expression "some time > in the future" will postpone the introduction of these media forever. That > is not wanted. > > I suggest that you delete "some time in the future". The "may" carries > sufficient uncertainty to delay its introduction if it is not found feasible > from the outset to provide more media than audio. > > The resulting sentence is proposed to be: > > "Media: Real-time text and video may be supported in devices." > > > /Gunnar > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Saturday, March 06, 2010 11:00 AM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-rosen-ecrit-ecall-03.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Best Current Practice for IP-based In-Vehicle > Emergency Calls > Author(s) : B. Rosen, et al. > Filename : draft-rosen-ecrit-ecall-03.txt > Pages : 17 > Date : 2010-03-06 > > This document describes how to use a subset of the IETF-based emergency call > framework for accomplishing emergency calling support in vehicles. > Simplifications are possible due to the nature of the functionality that is > going to be provided in vehicles with the usage of GPS. Additionally, > further profiling needs to be done regarding the encoding of location > information. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-rosen-ecrit-ecall-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From Hannes.Tschofenig@gmx.net Sat Mar 6 23:45:00 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 B79533A8EF4 for ; Sat, 6 Mar 2010 23:45:00 -0800 (PST) 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 TuN3cuuBo4sj for ; Sat, 6 Mar 2010 23:44:59 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4198F3A8EF3 for ; Sat, 6 Mar 2010 23:44:58 -0800 (PST) Received: (qmail invoked by alias); 07 Mar 2010 07:45:01 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.255.4]) [88.115.222.204] by mail.gmx.net (mp006) with SMTP; 07 Mar 2010 08:45:01 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/z6fhqQDnzfQbObjC8jVsku8NsXvEnQ2tUJYgFN9 lCJ1J1KrpovFVw Message-ID: <4B93595A.5070603@gmx.net> Date: Sun, 07 Mar 2010 09:44:26 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brian Rosen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53000000000000003 Cc: 'ECRIT' Subject: Re: [Ecrit] LoST Sync Update 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: Sun, 07 Mar 2010 07:45:00 -0000 Hi Brian, Brian Rosen wrote: > In the NENA i3 scheme, the interface to the LoST server is a set of GIS > layers, and specifically, there are sets of polygons that define service > boundaries. Each of these boundaries has attributes for the service URN > URI, etc that are returned in the LosT response when the query location is > found within the boundary. > The sentence "the interface to the LoST server is a set of GIS layers" sounds nice but does not make a lot of sense to me. An interface is a protocol or an API. A GIS layer, as you describe it in the following sentences, is essentially mapping data. Mapping Data: Mapping data refers to a data structure that is defined in Section 5 of RFC 5222. > For a civic address on the query, in theory, the LoST server does a geocode > and then point-in-polygon, but an implementation can compute a table to do > lookups for civics. > > The question here should be how do you describe civic boundaries. If you have no story for it then it is a bit mood to return civic boundaries in a LoST response to the LoST client as well. > The provisioning interface is a layer replication mechanism that uses two > parts: > I hate the term "layer replication" mechanism because it is so meaningless in our concepts. We replicate mapping data because that is what LoST servers at the end need. If you replicate something else then there is the question of how this maps to the fields required for the LoST mapping data. > 1. A Web Feature Service (an OGC standard that does insert/delete/modify > operations) > 2. An RSS feed of WFS commands > > Nice. Solutions by referencing other standards that nobody understands. While I am confident that the OGC knows what they want their concept to use for I am not sure how well the story is complete for dealing with LoST servers. To me this concept sounds like being at the stage of early design work. I want to have an example of how this works. Take a look at the example we have in the LoST sync document and try to create something with these two technologies. There are two implementations of LoST Sync; the code is available. Are there implementions of what you describe for usage with LoST? > We have a "master GIS" that contains the layers that the LoST server needs. > How well does this concept map to the term defined in the LoST architecture document called "authoritative mapping server" (see Section 3 of RFC 5582)? > These include polygons for the political boundaries, plus either (or both) > centerlines or road geometry, address points or parcel/subparcel polygons, > etc. There is a feature layer or attribute on a feature for each of the > CAtypes. > Why do these things matter for LoST operation? What matters in LoST is the mapping data in a LoST server. Whether these boundaries relate to political boundaries does not matter. > As normal GIS maintenance is performed on the master (adding streets, > changing boundaries, etc.), the WFS commands that replicate that change are > sent as an RSS feed to the LoST server, which replicates the edits on its > database, maintaining synchrony with the master. > > We allow the LoST server to have an OUTPUT layer replication service, which > is used on an aggregating LoST server. For example, each county in a state > could have a LoST server, and the state could have a LoST server which is > the aggregate of the individual counties. There is a gap/overlap reporting > mechanism for this. > > Aggregating the mapping data in LoST servers all the way up to FGs is OK. That's what we also describe in the LoST Sync document. > One of the primary goals for this mechanism is to enable the boundaries to > be changed on the GIS system by a normal edit function, and post the cache > TTL, routes changes happen immediately. We use this in disaster scenarios > when our other mechanisms to reroute calls don't work for the actual > situation on the ground. > Here is another disconnect, namely the believe that changing to mapping data at a LoST server (even when replicated immediately to other LoST servers) leads to immediate route changes. No, it doesn't since we have built into LoST the caching concept to improve reliability, robustness and scalability. The downside of it is that, when used of course, changes to the mapping data are in effect only after a certain amount of time. Unless you make some further assumptions, which you did not state in your paragraph above. Ciao Hannes > Brian > > > On 3/6/10 3:44 PM, "Hannes Tschofenig" wrote: > > >> I have re-submitted a version of the LoST sync document. >> The update reflects the comments from Karl Heinz and Alex. >> >> As you have seen, I have solicited feedback from the XML / Relax NG >> experts regarding the schema. I hope to get a response soon. >> >> I would also like to get some feedback from comments I filed against the >> NENA i3 stage 3 specification. The NENA spec hints to a different >> synchronization mechanisms (as Brian mentioned already many times) but I >> failed to understand how it works. I would like to see what the >> similarity and the differences are. Since the i3 spec is supposed to be >> completed very soon I assume clarifications regarding the >> synchronization aspects will have to get discussed as well. >> >> Ciao >> Hannes >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > From br@brianrosen.net Sun Mar 7 07:53:01 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2698F28C0DF for ; Sun, 7 Mar 2010 07:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 KK4RQo-DCeOp for ; Sun, 7 Mar 2010 07:52:59 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id 9DB6A3A8AB4 for ; Sun, 7 Mar 2010 07:52:59 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.118]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1NoIml-0005cm-C7; Sun, 07 Mar 2010 09:52:55 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Sun, 07 Mar 2010 10:52:49 -0500 From: Brian Rosen To: Hannes Tschofenig Message-ID: Thread-Topic: [Ecrit] LoST Sync Update Thread-Index: Acq+DjyoewJuHNkf6EyDiJzKPuwXbQ== In-Reply-To: <4B93595A.5070603@gmx.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 Cc: 'ECRIT' Subject: Re: [Ecrit] LoST Sync Update 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: Sun, 07 Mar 2010 15:53:01 -0000 Hannes I am not sure of the point of this thread. No one has suggested that the NENA LoST provisioning idea be somehow adopted by the IETF (although I am sure we wouldn't object if it did). No one has suggested that there is anything "wrong" with lost-sync. This is a thread on the ecrit list, not the NENA i3 list. See replies in-line On 3/7/10 2:44 AM, "Hannes Tschofenig" wrote: > Hi Brian, > > > Brian Rosen wrote: >> In the NENA i3 scheme, the interface to the LoST server is a set of GIS >> layers, and specifically, there are sets of polygons that define service >> boundaries. Each of these boundaries has attributes for the service URN >> URI, etc that are returned in the LosT response when the query location is >> found within the boundary. >> > > The sentence "the interface to the LoST server is a set of GIS layers" > sounds nice but does not make a lot of sense to me. > An interface is a protocol or an API. A GIS layer, as you describe it in > the following sentences, is essentially mapping data. Yes, it is "mapping data". It is the data that drive LoST query resolution. It is represented as a set of GIS layers that are maintained on the LoST server in sync with the same layers in the master GIS system which is the authoritative source for the data. The data is the layers, the transport protocol is WFS with an ATOM feed > > Mapping Data: > Mapping data refers to a data structure that is defined in > Section 5 > of > RFC 5222. I am not even going to go look to see if the definition in there is a complete overlap in definitions. > > > > >> For a civic address on the query, in theory, the LoST server does a geocode >> and then point-in-polygon, but an implementation can compute a table to do >> lookups for civics. >> >> > The question here should be how do you describe civic boundaries. If you > have no story for it then it is a bit mood to return civic boundaries in > a LoST response to the LoST client as well. Some GIS basics, and please remember that I am not a GIS expert. A GIS system is a database. The database has records. The geodetic records are called "features". A feature is fundamentally what we often call a 'geoshape' = point, line, circle, polygon,... A feature can have attributes (=values associated with the feature, for example, a name, a record-id, or some other conventional data item) Conventionally, features are grouped into "layers" which is a set of features that have some relationship. Layers can have attributes, although we often describe a set of attributes that each feature in the layer must have. For example, consider a 'street centerline' layer. The features in this layer are lines that represent a segment of a street. Each of the lines in the layer would have attributes for (among other things) * The name of the street * The municipality it lies in * The first and last address number for each side of the street A simpler example would be a county layer, which has polygons that represent the boundary of the county, with attributes for the name of the county, a code, and perhaps the state it belongs to. Another interesting layer would be an address point layer. The features are points. The attributes are "house number", street name, etc. So, we have a layer for each of the CAtypes * A State layer with polygons for a state * A county layer with polygons for counties * A municipality layer with polygons for cites, towns * A district layer * A neighborhood layer * A street layer, which could be a street centerline layer as described above, or a set of polygons that describe the actual street geometry * An address layer, or parcel and subparcel layers that represent addressable parts of a road ... This is a map: it lets us locate a position either by a geo or a civic. To find the location of a civic, you do a common GIS operation which does successive searches to find the address point or polygon on the road in the neighborhood (if specified) in the district (if specified) in the municipality, in the county (if specified) in the state, using the geometry and/or the attributes. In most GIS systems, this would be a conventional multi-table JOIN, because there are attributes in the features that relate them to the next highest level. If the result of the search was exactly one feature, then we have a unique location for the given civic address, and we take the point (if it is an address point) or a polygon (if it is a parcel/subparcel/...) that represents it (that is, we "geocode" to go from a civic to a geo). We then do PinP on the PSAP boundary layer to determine the LoST mapping. In a bit more detail, we do PinP with the sets of polygons that have a service URN attribute matching the service urn in the LoST request, and return the URI and other information in the corresponding attributes on the selected service boundary polygon set. This makes LosT mapping either a straight PinP for a geo, or geocode followed by PinP for a civic. One important reason we do it this way is that the GIS system with all these layers already exist in most PSAPs in North America. The database was created to handle wireless calls, and is used to first display where a mobile caller is calling from, and then to determine the civic address to dispatch responders to (reverse geocode). Following the latest NENA guidance, even the current table driven routing database (the "MSAG") that the 9-1-1 system now uses is DERIVED from the GIS system. When there are changes in addressing: perhaps a new street is created, or a "un-incorporated" portion of a county boundary is annexed to a city, the change is made on the master GIS system, and a new MSAG is generated from that. Going forward, essentially ALL of the location data that drives 9-1-1 is derived directly from the GIS. For i3 that means the LoST mapping data is derived from the master GIS system. Using layer replication makes this simple, and we use the same mechanism for other services in i3. > > >> The provisioning interface is a layer replication mechanism that uses two >> parts: >> > > I hate the term "layer replication" mechanism because it is so > meaningless in our concepts. We replicate mapping data because that is > what LoST servers at the end need. If you replicate something else then > there is the question of how this maps to the fields required for the > LoST mapping data. Too bad. It describes exactly what we do. We have a set of layers in the master GIS system that represent the same layers in the LoST server used to do the LoST mapping. We replicate those layers from the master GIS to the slave LoST server, so that any edits to the master GIS quickly replicate on the LoST server. The LoST server IS a GIS system in this view. > >> 1. A Web Feature Service (an OGC standard that does insert/delete/modify >> operations) >> 2. An RSS feed of WFS commands >> >> > Nice. Solutions by referencing other standards that nobody understands. Hello? The GIS folks know what a WFS is. NENA is not restricted to IETF standards. The GIS guys don't know what an ATOM feed is, but it's a simple enough (IETF!) standard to explain to them. WFS isn't that simple, but for your purposes, it's an add/delete/edit mechanism for a GIS system that operates on features. It uses web services for transport. > > While I am confident that the OGC knows what they want their concept to > use for I am not sure how well the story is complete for dealing with > LoST servers. To me this concept sounds like being at the stage of early > design work. As is lost-sync, the difference being that the mechanism for layer sync (WFS + ATOM) has been implemented, trialed, and found to work in Canada. > > I want to have an example of how this works. Take a look at the example > we have in the LoST sync document and try to create something with these > two technologies. I explained this above. If you are still confused, ask any GIS expert how geocoding works. After that, it works the same way a geo query to LoST would work. > > There are two implementations of LoST Sync; the code is available. > Are there implementions of what you describe for usage with LoST? Yes, although not applied to a LoST server. However, the idea of geocode then PinP is not exactly stretching anything very far. > >> We have a "master GIS" that contains the layers that the LoST server needs. >> > How well does this concept map to the term defined in the LoST > architecture document called "authoritative mapping server" (see Section > 3 of RFC 5582)? The master GIS system is not a LoST server. It is the source of data the authoritative mapping server derives mappings from. It is how we provision the authoritative mapping server. We use the same protocol to provision any LoST server. > >> These include polygons for the political boundaries, plus either (or both) >> centerlines or road geometry, address points or parcel/subparcel polygons, >> etc. There is a feature layer or attribute on a feature for each of the >> CAtypes. >> > > Why do these things matter for LoST operation? What matters in LoST is > the mapping data in a LoST server. Whether these boundaries relate to > political boundaries does not matter. See above. We use the layers to geocode civic to geo. Then we use the PSAP service boundary polygons to determine mapping in geo-space. > > >> As normal GIS maintenance is performed on the master (adding streets, >> changing boundaries, etc.), the WFS commands that replicate that change are >> sent as an RSS feed to the LoST server, which replicates the edits on its >> database, maintaining synchrony with the master. >> >> We allow the LoST server to have an OUTPUT layer replication service, which >> is used on an aggregating LoST server. For example, each county in a state >> could have a LoST server, and the state could have a LoST server which is >> the aggregate of the individual counties. There is a gap/overlap reporting >> mechanism for this. >> >> > Aggregating the mapping data in LoST servers all the way up to FGs is > OK. That's what we also describe in the LoST Sync document. > >> One of the primary goals for this mechanism is to enable the boundaries to >> be changed on the GIS system by a normal edit function, and post the cache >> TTL, routes changes happen immediately. We use this in disaster scenarios >> when our other mechanisms to reroute calls don't work for the actual >> situation on the ground. >> > Here is another disconnect, namely the believe that changing to mapping > data at a LoST server (even when replicated immediately to other LoST > servers) leads to immediate route changes. No, it doesn't since we have > built into LoST the caching concept to improve reliability, robustness > and scalability. The downside of it is that, when used of course, > changes to the mapping data are in effect only after a certain amount of > time. Did you see the "post the cache TTL" phrase in what I wrote? We keep the TTLs short, for this reason. We don't think there is any problem maintaining the servers reliable or scalable with short TTLs. > > Unless you make some further assumptions, which you did not state in > your paragraph above. > > > Ciao > Hannes > >> Brian >> >> >> On 3/6/10 3:44 PM, "Hannes Tschofenig" wrote: >> >> >>> I have re-submitted a version of the LoST sync document. >>> The update reflects the comments from Karl Heinz and Alex. >>> >>> As you have seen, I have solicited feedback from the XML / Relax NG >>> experts regarding the schema. I hope to get a response soon. >>> >>> I would also like to get some feedback from comments I filed against the >>> NENA i3 stage 3 specification. The NENA spec hints to a different >>> synchronization mechanisms (as Brian mentioned already many times) but I >>> failed to understand how it works. I would like to see what the >>> similarity and the differences are. Since the i3 spec is supposed to be >>> completed very soon I assume clarifications regarding the >>> synchronization aspects will have to get discussed as well. >>> >>> Ciao >>> Hannes >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> > From keith.drage@alcatel-lucent.com Sun Mar 7 11:28:35 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD26A3A8312 for ; Sun, 7 Mar 2010 11:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.365 X-Spam-Level: X-Spam-Status: No, score=-4.365 tagged_above=-999 required=5 tests=[AWL=1.584, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 0X106akfPuUz for ; Sun, 7 Mar 2010 11:28:34 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id C0A363A9110 for ; Sun, 7 Mar 2010 11:28:33 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o27JSYjY015245 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 7 Mar 2010 20:28:34 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sun, 7 Mar 2010 20:28:10 +0100 From: "DRAGE, Keith (Keith)" To: Hannes Tschofenig , =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= Date: Sun, 7 Mar 2010 20:28:08 +0100 Thread-Topic: [Ecrit] I-D Action:draft-rosen-ecrit-ecall-03.txt Thread-Index: Acq9xAUA/N6sw1Q3TSu9XZQJ3h+SCQAZvVJw Message-ID: References: <20100306100001.874933A77D0@core3.amsl.com> <00ea01cabd7a$71a99780$54fcc680$@hellstrom@omnitor.se> <4B934F19.5010807@gmx.net> In-Reply-To: <4B934F19.5010807@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "Ecrit@Ietf. Org" Subject: Re: [Ecrit] I-D Action:draft-rosen-ecrit-ecall-03.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: Sun, 07 Mar 2010 19:28:35 -0000 Can I ask what this comment is attempting to achieve. The eCall work based on 3GPP is primarily about getting data to a specialis= t call taker able to handle the data, and defining the format of that data.= There is nothing that prevents that device making an ordinary emergency ca= ll, or indeed an emergency call requiring global text telephone. I believe = that such capabilities are envisaged. What is obviously not covered in 3GPP is the simultaneous use of that data = with an ordinary emergency call, but that is because currently the data ult= imately is sent as a modem based circuit switched call, which are not exact= ly multimedia. Switch that data to IP based media, and there is no reason w= hy you cannot mix it with any multimedia emergency call, possibly with an e= xtra service urn element to cover the requirement for a specialised call ta= ker. I would additionally raise the question of why people think IETF would be t= he better body to define this rather than 3GPP. Surely the delivery mechani= sms are intended to be cellular based rather than any other access technolo= gy - unless you really want to crash your car into Starbucks so you can mak= e use of the free WiFi. regards Keith =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Hannes Tschofenig > Sent: Sunday, March 07, 2010 7:01 AM > To: Gunnar Hellstr=F6m > Cc: Ecrit@Ietf. Org > Subject: Re: [Ecrit] I-D Action:draft-rosen-ecrit-ecall-03.txt >=20 > Hi Gunnar, >=20 > this document refers to emergency calls in vehicles. The=20 > standardization efforts I have seen in that space barely talk=20 > about voice support and I have not seen any video or=20 > real-time text being mentioned. I am specifically referring=20 > the work done in Europe (as part of the eCall effort -- hence=20 > the name of the draft). >=20 > While I agree with you in general I was trying to be closer=20 > to what is being standardized in other groups. Did I miss=20 > something or do you think we should be a bit more proactive here? >=20 > Ciao > Hannes >=20 >=20 > Gunnar Hellstr=F6m wrote: > > Hi, > > In chapter 3 of this draft, there is a sentence about media saying:=20 > > > > "Media: Real-time text and video may be supported in devices some > > time in the future." > > > > If this draft makes its way to be a published RFC, the expression=20 > > "some time in the future" will postpone the introduction of these=20 > > media forever. That is not wanted. > > > > I suggest that you delete "some time in the future". The=20 > "may" carries=20 > > sufficient uncertainty to delay its introduction if it is not found=20 > > feasible from the outset to provide more media than audio. > > > > The resulting sentence is proposed to be: > > > > "Media: Real-time text and video may be supported in devices." > > > > > > /Gunnar > > > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org=20 > > [mailto:i-d-announce-bounces@ietf.org] > > On Behalf Of Internet-Drafts@ietf.org > > Sent: Saturday, March 06, 2010 11:00 AM > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-rosen-ecrit-ecall-03.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > > > Title : Best Current Practice for IP-based In-Vehicle > > Emergency Calls > > Author(s) : B. Rosen, et al. > > Filename : draft-rosen-ecrit-ecall-03.txt > > Pages : 17 > > Date : 2010-03-06 > > > > This document describes how to use a subset of the IETF-based=20 > > emergency call framework for accomplishing emergency=20 > calling support in vehicles. > > Simplifications are possible due to the nature of the functionality=20 > > that is going to be provided in vehicles with the usage of GPS. =20 > > Additionally, further profiling needs to be done regarding the=20 > > encoding of location information. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-rosen-ecrit-ecall-03.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > =20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From gunnar.hellstrom@omnitor.se Sun Mar 7 11:28:40 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 AA99728C1D8 for ; Sun, 7 Mar 2010 11:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.252 X-Spam-Level: X-Spam-Status: No, score=-0.252 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, MSGID_MULTIPLE_AT=1.449] 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 nPbzF7ckaAkm for ; Sun, 7 Mar 2010 11:28:39 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id CAEC53A9110 for ; Sun, 7 Mar 2010 11:28:38 -0800 (PST) Received: from s24.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 84D2F33C910 for ; Sun, 7 Mar 2010 20:28:47 +0100 (CET) Received: (qmail 70269 invoked from network); 7 Mar 2010 19:28:40 -0000 Received: from h16n1fls34o265.telia.com (HELO AllaneCDator) (gunnar.hellstrom@omnitor.se@[213.64.232.16]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 7 Mar 2010 19:28:40 -0000 From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "'Hannes Tschofenig'" References: <20100306100001.874933A77D0@core3.amsl.com> <00ea01cabd7a$71a99780$54fcc680$@hellstrom@omnitor.se> <4B934F19.5010807@gmx.net> In-Reply-To: <4B934F19.5010807@gmx.net> Date: Sun, 7 Mar 2010 20:28:40 +0100 Message-ID: <01c301cabe2c$64918fa0$2db4aee0$@hellstrom@omnitor.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq9w/y9q827DD26T/if1ZUyafQJqgAWEEsQ Content-Language: sv Cc: "'Ecrit@Ietf. Org'" Subject: Re: [Ecrit] I-D Action:draft-rosen-ecrit-ecall-03.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: Sun, 07 Mar 2010 19:28:40 -0000 Hannes, I want to split the question about the sentence about support of = real-time text and video in two: One about wording in a standard, and one about = the applicability of real-time text and video in the eCall environment. 1. Wording. The current wording is: "Media: Real-time text and video may be supported in devices some time = in the future." I expect a standard to be valid at the moment I read it. If this draft becomes approved and published, the sentence will postpone all future efforts to introduce support of real-time text and video to some unknown moment when a new standard for the same purpose is approved without the words about future support. It is against the purpose of a standard to = talk about what may be done in the future. The correct way to describe future features is to just say that a feature MAY be supported, and let = external forces decide when the feature is made commonly implemented. Therefore, please delete "some time in the future". 2. About applicability and feasibility of real-time text and video in = eCall, and being more proactive. I get sad every time I see a feature standardized or implemented only = for audio. There are so many cases when severe problems of understanding = appear in a voice conversation that takes minutes to overcome, that would have = been solved in seconds by having a real-time text channel or a video channel available in the call. Such problems appear between people with = different languages, different dialects, in noisy environments, with bad = connections, or because they have items to exchange that requires exactness in = spelling. Such situations appear easily when travelling by car.=20 And of course, from the accessibility side, it is even more easy to find examples of situations where real-time text or video or both is = essential for the communication.=20 There are plenty of strong and binding policy statements requiring all communication products and services to be made accessible for people = with disabilities. Including real-time text and video in an interoperable way everywhere where audio is supported is one good step to meet these requirements, and it is also a good step towards better mainstream use = of the services.=20 One such collection of binding accessibility requirements is the UN convention on rights of people with disabilities. Article 9 is about accessibility. http://www.un.org/disabilities/default.asp?id=3D269 Article 11 is about emergency situations http://www.un.org/disabilities/default.asp?id=3D271 =20 However, it would be fruitless to just include accessibility features in = a standard without talking with the ones who proposed the standard. So, for now, I suggest that the MAY is still left there, while you = discuss with the projects working on eCall about the feasibility of other media. Gunnar=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Sunday, March 07, 2010 8:01 AM To: Gunnar Hellstr=F6m Cc: Ecrit@Ietf. Org; Brian Rosen Subject: Re: [Ecrit] I-D Action:draft-rosen-ecrit-ecall-03.txt Hi Gunnar, this document refers to emergency calls in vehicles. The standardization = efforts I have seen in that space barely talk about voice support and I=20 have not seen any video or real-time text being mentioned. I am=20 specifically referring the work done in Europe (as part of the eCall=20 effort -- hence the name of the draft). While I agree with you in general I was trying to be closer to what is=20 being standardized in other groups. Did I miss something or do you think = we should be a bit more proactive here? Ciao Hannes Gunnar Hellstr=F6m wrote: > Hi, > In chapter 3 of this draft, there is a sentence about media saying:=20 > > "Media: Real-time text and video may be supported in devices some > time in the future." > > If this draft makes its way to be a published RFC, the expression = "some time > in the future" will postpone the introduction of these media forever. = That > is not wanted. > > I suggest that you delete "some time in the future". The "may" carries > sufficient uncertainty to delay its introduction if it is not found feasible > from the outset to provide more media than audio. > > The resulting sentence is proposed to be: > > "Media: Real-time text and video may be supported in devices." > > > /Gunnar =20 > > -----Original Message----- > From: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Saturday, March 06, 2010 11:00 AM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-rosen-ecrit-ecall-03.txt=20 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Best Current Practice for IP-based In-Vehicle > Emergency Calls > Author(s) : B. Rosen, et al. > Filename : draft-rosen-ecrit-ecall-03.txt > Pages : 17 > Date : 2010-03-06 > > This document describes how to use a subset of the IETF-based = emergency call > framework for accomplishing emergency calling support in vehicles. > Simplifications are possible due to the nature of the functionality = that is > going to be provided in vehicles with the usage of GPS. Additionally, > further profiling needs to be done regarding the encoding of location > information. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-rosen-ecrit-ecall-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > =20 __________ NOD32 4921 (20100306) Information __________ Detta meddelande =E4r genoms=F6kt av NOD32 Antivirus. http://www.nod32.com From James.Winterbottom@andrew.com Sun Mar 7 12:31:58 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 EC9023A9190 for ; Sun, 7 Mar 2010 12:31:58 -0800 (PST) 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, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoB9bNz6r7DV for ; Sun, 7 Mar 2010 12:31:58 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id C702E3A9195 for ; Sun, 7 Mar 2010 12:31:57 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:56493 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S13849121Ab0CGUcA convert rfc822-to-8bit (ORCPT ); Sun, 7 Mar 2010 14:32:00 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 7 Mar 2010 14:31:59 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 8 Mar 2010 04:31:57 +0800 From: "Winterbottom, James" To: "DRAGE, Keith (Keith)" , Hannes Tschofenig , =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= Date: Mon, 8 Mar 2010 04:29:40 +0800 Thread-Topic: [Ecrit] I-D Action:draft-rosen-ecrit-ecall-03.txt Thread-Index: Acq9xAUA/N6sw1Q3TSu9XZQJ3h+SCQAZvVJwAAJ72RU= Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120DBE53141@SISPE7MB1.commscope.com> References: <20100306100001.874933A77D0@core3.amsl.com> <00ea01cabd7a$71a99780$54fcc680$@hellstrom@omnitor.se> <4B934F19.5010807@gmx.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: "Ecrit@Ietf. Org" Subject: Re: [Ecrit] I-D Action:draft-rosen-ecrit-ecall-03.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: Sun, 07 Mar 2010 20:31:59 -0000 Hi Keith, There is also the growing prevalence of MiFi in vehicles, where device connected to the MiFi point doesn't know about the 3G/4G backhaul. In this circumstance depending on 3GPP procedures is perhaps not quite so wise. Cheers James ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) [keith.drage@alcatel-lucent.com] Sent: Sunday, March 07, 2010 1:28 PM To: Hannes Tschofenig; Gunnar Hellström Cc: Ecrit@Ietf. Org Subject: Re: [Ecrit] I-D Action:draft-rosen-ecrit-ecall-03.txt Can I ask what this comment is attempting to achieve. The eCall work based on 3GPP is primarily about getting data to a specialist call taker able to handle the data, and defining the format of that data. There is nothing that prevents that device making an ordinary emergency call, or indeed an emergency call requiring global text telephone. I believe that such capabilities are envisaged. What is obviously not covered in 3GPP is the simultaneous use of that data with an ordinary emergency call, but that is because currently the data ultimately is sent as a modem based circuit switched call, which are not exactly multimedia. Switch that data to IP based media, and there is no reason why you cannot mix it with any multimedia emergency call, possibly with an extra service urn element to cover the requirement for a specialised call taker. I would additionally raise the question of why people think IETF would be the better body to define this rather than 3GPP. Surely the delivery mechanisms are intended to be cellular based rather than any other access technology - unless you really want to crash your car into Starbucks so you can make use of the free WiFi. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Hannes Tschofenig > Sent: Sunday, March 07, 2010 7:01 AM > To: Gunnar Hellström > Cc: Ecrit@Ietf. Org > Subject: Re: [Ecrit] I-D Action:draft-rosen-ecrit-ecall-03.txt > > Hi Gunnar, > > this document refers to emergency calls in vehicles. The > standardization efforts I have seen in that space barely talk > about voice support and I have not seen any video or > real-time text being mentioned. I am specifically referring > the work done in Europe (as part of the eCall effort -- hence > the name of the draft). > > While I agree with you in general I was trying to be closer > to what is being standardized in other groups. Did I miss > something or do you think we should be a bit more proactive here? > > Ciao > Hannes > > > Gunnar Hellström wrote: > > Hi, > > In chapter 3 of this draft, there is a sentence about media saying: > > > > "Media: Real-time text and video may be supported in devices some > > time in the future." > > > > If this draft makes its way to be a published RFC, the expression > > "some time in the future" will postpone the introduction of these > > media forever. That is not wanted. > > > > I suggest that you delete "some time in the future". The > "may" carries > > sufficient uncertainty to delay its introduction if it is not found > > feasible from the outset to provide more media than audio. > > > > The resulting sentence is proposed to be: > > > > "Media: Real-time text and video may be supported in devices." > > > > > > /Gunnar > > > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org] > > On Behalf Of Internet-Drafts@ietf.org > > Sent: Saturday, March 06, 2010 11:00 AM > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-rosen-ecrit-ecall-03.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : Best Current Practice for IP-based In-Vehicle > > Emergency Calls > > Author(s) : B. Rosen, et al. > > Filename : draft-rosen-ecrit-ecall-03.txt > > Pages : 17 > > Date : 2010-03-06 > > > > This document describes how to use a subset of the IETF-based > > emergency call framework for accomplishing emergency > calling support in vehicles. > > Simplifications are possible due to the nature of the functionality > > that is going to be provided in vehicles with the usage of GPS. > > Additionally, further profiling needs to be done regarding the > > encoding of location information. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-rosen-ecrit-ecall-03.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From root@core3.amsl.com Sun Mar 7 18:15:02 2010 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1F14D3A6825; Sun, 7 Mar 2010 18:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100308021502.1F14D3A6825@core3.amsl.com> Date: Sun, 7 Mar 2010 18:15:02 -0800 (PST) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-local-emergency-rph-namespace-04.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, 08 Mar 2010 02:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : IANA Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications Author(s) : J. Polk Filename : draft-ietf-ecrit-local-emergency-rph-namespace-04.txt Pages : 8 Date : 2010-03-07 This document creates the new Session Initiation Protocol (SIP) Resource Priority header field namespace "esnet" for local emergency usage to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations, and places this namespace in the IANA registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-namespace-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-local-emergency-rph-namespace-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-07180233.I-D@ietf.org> --NextPart-- From Martin.Thomson@andrew.com Sun Mar 7 20:48:34 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 385B63A68C4 for ; Sun, 7 Mar 2010 20:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.725 X-Spam-Level: X-Spam-Status: No, score=-0.725 tagged_above=-999 required=5 tests=[AWL=-1.718, BAYES_00=-2.599, FRT_PENIS1=3.592] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJSs5WWYpQZ7 for ; Sun, 7 Mar 2010 20:48:33 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 3BA883A68A2 for ; Sun, 7 Mar 2010 20:48:33 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:37528 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S174129Ab0CHEsh (ORCPT ); Sun, 7 Mar 2010 22:48:37 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 7 Mar 2010 22:48:36 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 8 Mar 2010 12:48:34 +0800 From: "Thomson, Martin" To: "Winterbottom, James" , Avery Penniston Date: Mon, 8 Mar 2010 12:49:49 +0800 Thread-Topic: [Ecrit] Last Call: draft-ietf-ecrit-specifying-holes (SpecifyingHoles in LoST Service Boundaries) to Proposed Standard Thread-Index: Acq1hjIu+BUi4yaGS2KFMd9pqd0ujwAtN6KwAANiSIgCDFLfUA== Message-ID: <8B0A9FCBB9832F43971E38010638454F03DF0980E7@SISPE7MB1.commscope.com> References: <20100224191601.0C0103A84D3@core3.amsl.com>, <909A20ADCD98AD4FB9984A87063A560503C77BE0@exchange.geo-comm.local> <5A55A45AE77F5941B18E5457ECAC81880120DBE53120@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120DBE53120@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Last Call: draft-ietf-ecrit-specifying-holes (SpecifyingHoles in LoST Service Boundaries) to Proposed Standard X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 04:48:34 -0000 SSd2ZSB1cGRhdGVkIHRoZSBkcmFmdCB0byAtMDIgdG8gY29ycmVjdCB0aGVzZSBpc3N1ZXMuDQoN CjxodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWVjcml0LXNw ZWNpZnlpbmctaG9sZXMtMDIudHh0Pg0KDQoxKSBBcyB3ZWxsIGFzIGNoYW5naW5nIHRoZSBvcmRl cmluZywgSSd2ZSBhZGRlZCBub3RlcyB0byBtYWtlIHRoaXMgYmVoYXZpb3VyIGNsZWFyZXIuICBJ dCdzIG5vdCBhbHdheXMgY2xlYXIganVzdCBmcm9tIGxvb2tpbmcuDQoNCjIpIEkndmUgbm90ZWQg dGhhdCBtb3N0IGdlb3NwYXRpYWwgc29mdHdhcmUgc3VwcG9ydHMgaW50ZXJpb3IgZXhjbHVzaW9u cywgYnV0IHJlaXRlcmF0ZWQgdGhlIHJlcXVpcmVtZW50cyBmb3IgcHJvY2Vzc2luZyBwb2x5Z29u cyB3aXRoIHRoZW0uDQoNCkNoZWVycywNCk1hcnRpbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IFdpbnRlcmJvdHRvbSwgSmFtZXMNCj4gU2VudDogRnJpZGF5LCAyNiBG ZWJydWFyeSAyMDEwIDU6MzAgQU0NCj4gVG86IEF2ZXJ5IFBlbm5pc3RvbjsgVGhvbXNvbiwgTWFy dGluDQo+IENjOiBlY3JpdEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW0Vjcml0XSBMYXN0IENh bGw6IGRyYWZ0LWlldGYtZWNyaXQtc3BlY2lmeWluZy1ob2xlcw0KPiAoU3BlY2lmeWluZ0hvbGVz IGluIExvU1QgU2VydmljZSBCb3VuZGFyaWVzKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiANCj4g SGkgQXZlcnksDQo+IA0KPiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuDQo+IElmIHdlIGhhdmUg YSBjb3VudGVyY2xvY2t3aXNlIHJpbmcgdGhlbiB5b3UgYXJlIHJpZ2h0LCB0aGlzIGlzIHdyb25n LiBJDQo+IHdpbGwgdGFrZSBhIGxvb2suDQo+IA0KPiBJdCBoYXMgYmVlbiBzbyBsb25nIHNpbmNl IHRoaXMgZHJhZnQgbGVmdCB0aGUgV0cgdGhhdCBJIHdpbGwgbmVlZCB0byBnbw0KPiBhbmQgbG9v ayBhdCBzZXBhcmF0ZSB0YWJsZSBjb21tZW50LiBJIGRvIHJlY2FsbCB0aGF0IHdoZW4gd2Ugd3Jv dGUgdGhlDQo+IGRyYWZ0IHdlIHdlcmUgYXNrZWQgdG8gcHJvdmlkZSBzb21lIGd1aWRhbmNlIGFz IHRvIGhvdyB0aGUgcHJlc2VuY2Ugb3INCj4gaG9sZXMgbWlnaHQgYmUgY2hlY2tlZCBmb3IuDQo+ IA0KPiBDaGVlcnMNCj4gSmFtZXMNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gRnJvbTogQXZlcnkgUGVubmlzdG9uIFthcGVubmlzdG9uQGdlby1jb21t LmNvbV0NCj4gU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI1LCAyMDEwIDExOjE5IEFNDQo+IFRv OiBXaW50ZXJib3R0b20sIEphbWVzOyBUaG9tc29uLCBNYXJ0aW4NCj4gQ2M6IGVjcml0QGlldGYu b3JnDQo+IFN1YmplY3Q6IFJFOiBbRWNyaXRdIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi1lY3JpdC1z cGVjaWZ5aW5nLWhvbGVzDQo+IChTcGVjaWZ5aW5nSG9sZXMgaW4gTG9TVCBTZXJ2aWNlIEJvdW5k YXJpZXMpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+IA0KPiBIZWxsbywNCj4gDQo+IEkgaGFkIGEg Y291cGxlIG9mIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtZWNyaXQtc3BlY2lmeWluZy1ob2xlczoN Cj4gDQo+IDEuKSBJbiBmaWd1cmUgNiBhbmQgOCB0aGUgPGdtbDppbnRlcmlvcj4gcmluZyBoYXMg aXRzIHBvaW50cyBzcGVjaWZpZWQNCj4gaW4gYSBjb3VudGVyY2xvY2t3aXNlIG9yZGVyLCBidXQg SSB0aGluayB0aGUgaW50ZXJpb3IgcmluZydzIHBvaW50cw0KPiBzaG91bGQgYmUgb3JkZXJlZCBj bG9ja3dpc2UuICBJIGJlbGlldmUgaXQgaXMgY29tbW9uIHByYWN0aWNlIChhbmQNCj4gcGVyaGFw cyBldmVuIG1hbmRhdGVkKSB0aGF0IHRoZSBpbnRlcmlvciByaW5nJ3MgcG9pbnQgb3JpZW50YXRp b24NCj4gc2hvdWxkDQo+IGJlIG9wcG9zaXRlIG9yaWVudGF0aW9uIG9mIHRoZSBwb2x5Z29uJ3Mg ZXh0ZXJpb3IgcmluZyBwb2ludA0KPiBvcmllbnRhdGlvbi4gIFNpbmNlIEdNTCAzLjEuMS4gYW5k IHRoZSBbZ2Vvc2hhcGVdIGRvY3VtZW50IHJlZmVyZW5jZWQNCj4gaW4NCj4gdGhlIGRyYWZ0IGJv dGggZGVmaW5lIGEgc3VyZmFjZSdzIHVwd2FyZCBub3JtYWwgYXMgY291bnRlcmNsb2Nrd2lzZQ0K PiB0aGlzDQo+IHdvdWxkIG1ha2UgdGhlIGludGVyaW9yIHJpbmcncyBvcmllbnRhdGlvbiBjbG9j a3dpc2UuDQo+IA0KPiAyLikgVGhlIGxhc3QgcGFyYWdyYXBoIG9uIHBhZ2UgMTIgdGFsa3MgYWJv dXQgc3RvcmluZyBob2xlcyBhcyBwb2x5Z29ucw0KPiBpbiBhIHNlcGFyYXRlIHRhYmxlLiAgSSB0 aGluayB0aGlzIHN0YXRlbWVudCBtYXkgYmUgZ29pbmcgYSBiaXQgZmFyIGluDQo+IHNwZWNpZnlp bmcgdGVjaG5vbG9neSBzcGVjaWZpYyBkZXRhaWxzLiAgSW4gZ2VuZXJhbCwgc3BhdGlhbGx5IGVu YWJsZWQNCj4gZGF0YWJhc2VzIHN1cHBvcnQgdGhlIG5vdGlvbiBvZiBpbnRlcmlvciByaW5ncyBh bmQgY2FuIHF1aWNrbHkNCj4gY2FsY3VsYXRlDQo+IHBvbHlnb24gaW50ZXJzZWN0aW9ucywgZXZl biBiZXR3ZWVuIHBvbHlnb25zIHRoYXQgY29udGFpbiBob2xlcywNCj4gd2l0aG91dA0KPiB0aGUg bmVlZCBmb3IgYSBzZWNvbmRhcnkgY2hlY2sgYWdhaW5zdCBhbiBleGNlcHRpb24gdGFibGUgZm9y IGhvbGUNCj4gcG9seWdvbnMuDQo+IA0KPiBBdmVyeQ0KPiBhcGVubmlzdG9uQGdlby1jb21tLmNv bQ0KPiANCj4gDQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZy b206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3Jn XSBPbg0KPiBCZWhhbGYNCj4gPiBPZiBUaGUgSUVTRw0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgRmVi cnVhcnkgMjQsIDIwMTAgMToxNiBQTQ0KPiA+IFRvOiBJRVRGLUFubm91bmNlDQo+ID4gQ2M6IGVj cml0QGlldGYub3JnDQo+ID4gU3ViamVjdDogW0Vjcml0XSBMYXN0IENhbGw6IGRyYWZ0LWlldGYt ZWNyaXQtc3BlY2lmeWluZy1ob2xlcw0KPiA+IChTcGVjaWZ5aW5nSG9sZXMgaW4gTG9TVCBTZXJ2 aWNlIEJvdW5kYXJpZXMpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4NCj4gPiBUaGUgSUVTRyBo YXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20gdGhlIEVtZXJnZW5jeSBDb250ZXh0IFJlc29sdXRp b24NCj4gPiB3aXRoIEludGVybmV0IFRlY2hub2xvZ2llcyBXRyAoZWNyaXQpIHRvIGNvbnNpZGVy IHRoZSBmb2xsb3dpbmcNCj4gPiBkb2N1bWVudDoNCj4gPg0KPiA+IC0gJ1NwZWNpZnlpbmcgSG9s ZXMgaW4gTG9TVCBTZXJ2aWNlIEJvdW5kYXJpZXMgJw0KPiA+ICAgIDxkcmFmdC1pZXRmLWVjcml0 LXNwZWNpZnlpbmctaG9sZXMtMDEudHh0PiBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4NCj4g PiBUaGUgSUVTRyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtz LCBhbmQgc29saWNpdHMNCj4gPiBmaW5hbCBjb21tZW50cyBvbiB0aGlzIGFjdGlvbi4gIFBsZWFz ZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRzIHRvDQo+IHRoZQ0KPiA+IGlldGZAaWV0Zi5vcmcg bWFpbGluZyBsaXN0cyBieSAyMDEwLTAzLTEwLiBFeGNlcHRpb25hbGx5LA0KPiA+IGNvbW1lbnRz IG1heSBiZSBzZW50IHRvIGllc2dAaWV0Zi5vcmcgaW5zdGVhZC4gSW4gZWl0aGVyIGNhc2UsIHBs ZWFzZQ0KPiA+IHJldGFpbiB0aGUgYmVnaW5uaW5nIG9mIHRoZSBTdWJqZWN0IGxpbmUgdG8gYWxs b3cgYXV0b21hdGVkIHNvcnRpbmcuDQo+ID4NCj4gPiBUaGUgZmlsZSBjYW4gYmUgb2J0YWluZWQg dmlhDQo+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1l Y3JpdC1zcGVjaWZ5aW5nLQ0KPiBob2xlcy0NCj4gPiAwMS50eHQNCj4gPg0KPiA+DQo+ID4gSUVT RyBkaXNjdXNzaW9uIGNhbiBiZSB0cmFja2VkIHZpYQ0KPiA+DQo+IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvcHVibGljL3BpZHRyYWNrZXIuY2dpP2NvbW1hbmQ9dmlld19pZCZkVGFnDQo+ ID4gPTE3MzMxJnJmY19mbGFnPTANCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gRWNyaXQgbWFpbGluZyBsaXN0DQo+ID4gRWNyaXRA aWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0 DQo= From root@core3.amsl.com Sun Mar 7 21:00:02 2010 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 438F23A68B4; Sun, 7 Mar 2010 21:00:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100308050002.438F23A68B4@core3.amsl.com> Date: Sun, 7 Mar 2010 21:00:02 -0800 (PST) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-specifying-holes-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, 08 Mar 2010 05:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Specifying Holes in LoST Service Boundaries Author(s) : J. Winterbottom, M. Thomson Filename : draft-ietf-ecrit-specifying-holes-02.txt Pages : 17 Date : 2010-03-07 This document describes how holes can be specified in geodetic service boundaries. One means of implementing a search solution in a service database, such as one might provide with a LoST server, is described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-specifying-holes-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-specifying-holes-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-07204544.I-D@ietf.org> --NextPart-- From arnoud.vanwijk@realtimetext.org Mon Mar 8 03:28:54 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 4D9503A6959 for ; Mon, 8 Mar 2010 03:28:54 -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 eE96LxUbAuBB for ; Mon, 8 Mar 2010 03:28:52 -0800 (PST) Received: from mx-in01.nouzelle.com (mx-in01.nouzelle.com [87.119.194.132]) by core3.amsl.com (Postfix) with ESMTP id EDA233A68C1 for ; Mon, 8 Mar 2010 03:28:51 -0800 (PST) Received: from internal02.nouzelle.com (internal02.nouzelle.local [172.29.32.13]) by mx-in01.nouzelle.com (Postfix) with ESMTP id A7F2940B4A0 for ; Mon, 8 Mar 2010 12:26:30 +0100 (CET) Received: from mailscan.nouzelle.com (unknown [172.29.32.10]) by internal02.nouzelle.com (Postfix) with ESMTP id E7FB510219B23 for ; Mon, 8 Mar 2010 12:28:53 +0100 (CET) X-Virus-Scanned: by amavisd-new at nouzelle.com Received: from internal02.nouzelle.com ([172.29.32.13]) by mailscan.nouzelle.com (mailscan.nouzelle.com [172.29.32.10]) (amavisd-new, port 10026) with ESMTP id W4HgZgXzd86e for ; Mon, 8 Mar 2010 12:28:52 +0100 (CET) Received: from arnoud-van-wijks-macbook-pro.local (84-245-17-214.dsl.cambrium.nl [84.245.17.214]) by internal02.nouzelle.com (Postfix) with ESMTPA id D8D2010219B2F for ; Mon, 8 Mar 2010 12:28:51 +0100 (CET) Message-ID: <4B94DF73.7020501@realtimetext.org> Date: Mon, 08 Mar 2010 12:28:51 +0100 From: Arnoud van Wijk Organization: R3TF User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: ecrit@ietf.org References: <20100306100001.874933A77D0@core3.amsl.com> <00ea01cabd7a$71a99780$54fcc680$@hellstrom@omnitor.se> <4B934F19.5010807@gmx.net> <01c301cabe2c$64918fa0$2db4aee0$@hellstrom@omnitor.se> In-Reply-To: <01c301cabe2c$64918fa0$2db4aee0$@hellstrom@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Ecrit] I-D Action:draft-rosen-ecrit-ecall-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: arnoud.vanwijk@realtimetext.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 11:28:54 -0000 I want to jump in here. I agree here with Gunnar. What we see here is that still so many people still have everything voice centric. Not realizing how essential and important it is to allow real-time text and video to be added to the call. This does sadden me a lot. We all as IETF and any other relevant standard organization should consider voice, video and real-time text the "real-time trinity". Always make it possible, always implement it and always consider it part of the normal standardization process. If there are limitations, it should never be the standard documents raising the barriers. > 1. Wording. > The current wording is: > "Media: Real-time text and video may be supported in devices some time in > the future." > I expect a standard to be valid at the moment I read it. If this draft > becomes approved and published, the sentence will postpone all future > efforts to introduce support of real-time text and video to some unknown > moment when a new standard for the same purpose is approved without the > words about future support. It is against the purpose of a standard to talk > about what may be done in the future. The correct way to describe future > features is to just say that a feature MAY be supported, and let external > forces decide when the feature is made commonly implemented. > > Therefore, please delete "some time in the future". > Agree > 2. About applicability and feasibility of real-time text and video in eCall, > and being more proactive. > I get sad every time I see a feature standardized or implemented only for > audio. There are so many cases when severe problems of understanding appear > in a voice conversation that takes minutes to overcome, that would have been > solved in seconds by having a real-time text channel or a video channel > available in the call. Such problems appear between people with different > languages, different dialects, in noisy environments, with bad connections, > or because they have items to exchange that requires exactness in spelling. > Such situations appear easily when travelling by car. > > And of course, from the accessibility side, it is even more easy to find > examples of situations where real-time text or video or both is essential > for the communication. > For example when you have video included in this call, the emergency agent can also see what is going on as well. Video can add essential information of the situation. > There are plenty of strong and binding policy statements requiring all > communication products and services to be made accessible for people with > disabilities. Including real-time text and video in an interoperable way > everywhere where audio is supported is one good step to meet these > requirements, and it is also a good step towards better mainstream use of > the services. > Exactly. > One such collection of binding accessibility requirements is the UN > convention on rights of people with disabilities. > > Article 9 is about accessibility. > http://www.un.org/disabilities/default.asp?id=269 > Article 11 is about emergency situations > http://www.un.org/disabilities/default.asp?id=271 > > However, it would be fruitless to just include accessibility features in a > standard without talking with the ones who proposed the standard. > So, for now, I suggest that the MAY is still left there, while you discuss > with the projects working on eCall about the feasibility of other media. > We could raise the bar and say: "Media: It is recommended to include Real-time text and video in devices." After all, in emergency situations, it is essential that communication is optimal, since lives may be in unnecessary danger due by miscommunications and insufficient information of the situation. Maybe being proactive here is a good thing. I do not want to die just because I am deaf and the only line of help is some voice line that I cannot use at all (only scream help maybe). Arnoud > Gunnar > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Sunday, March 07, 2010 8:01 AM > To: Gunnar Hellström > Cc: Ecrit@Ietf. Org; Brian Rosen > Subject: Re: [Ecrit] I-D Action:draft-rosen-ecrit-ecall-03.txt > > Hi Gunnar, > > this document refers to emergency calls in vehicles. The standardization > efforts I have seen in that space barely talk about voice support and I > have not seen any video or real-time text being mentioned. I am > specifically referring the work done in Europe (as part of the eCall > effort -- hence the name of the draft). > > While I agree with you in general I was trying to be closer to what is > being standardized in other groups. Did I miss something or do you think > we should be a bit more proactive here? > > Ciao > Hannes > > > Gunnar Hellström wrote: > >> Hi, >> In chapter 3 of this draft, there is a sentence about media saying: >> >> "Media: Real-time text and video may be supported in devices some >> time in the future." >> >> If this draft makes its way to be a published RFC, the expression "some >> > time > >> in the future" will postpone the introduction of these media forever. That >> is not wanted. >> >> I suggest that you delete "some time in the future". The "may" carries >> sufficient uncertainty to delay its introduction if it is not found >> > feasible > >> from the outset to provide more media than audio. >> >> The resulting sentence is proposed to be: >> >> "Media: Real-time text and video may be supported in devices." >> >> >> /Gunnar >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] >> On Behalf Of Internet-Drafts@ietf.org >> Sent: Saturday, March 06, 2010 11:00 AM >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-rosen-ecrit-ecall-03.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Best Current Practice for IP-based In-Vehicle >> Emergency Calls >> Author(s) : B. Rosen, et al. >> Filename : draft-rosen-ecrit-ecall-03.txt >> Pages : 17 >> Date : 2010-03-06 >> >> This document describes how to use a subset of the IETF-based emergency >> > call > >> framework for accomplishing emergency calling support in vehicles. >> Simplifications are possible due to the nature of the functionality that >> > is > >> going to be provided in vehicles with the usage of GPS. Additionally, >> further profiling needs to be done regarding the encoding of location >> information. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-rosen-ecrit-ecall-03.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> > > __________ NOD32 4921 (20100306) Information __________ > > Detta meddelande är genomsökt av NOD32 Antivirus. > http://www.nod32.com > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > From hannes.tschofenig@nsn.com Mon Mar 8 04:18:32 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 2B3D63A6996 for ; Mon, 8 Mar 2010 04:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 boYFXd8hcwun for ; Mon, 8 Mar 2010 04:18:28 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 0AD073A67BD for ; Mon, 8 Mar 2010 04:18:20 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o28CIIqN013071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Mar 2010 13:18:18 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o28CIGWJ013320 for ; Mon, 8 Mar 2010 13:18:18 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 13:18:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Mar 2010 14:17:28 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45024AD827@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vehicular Emergency Calls Thread-Index: Acq+uVHaQPCFuEzQQYqGMHj5KIc3dw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 08 Mar 2010 12:18:02.0956 (UTC) FILETIME=[666458C0:01CABEB9] Subject: [Ecrit] Vehicular Emergency Calls 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, 08 Mar 2010 12:18:33 -0000 I tried to address the recent comments on the list about the multi-media support. Please find the updated document here:=20 http://www.ietf.org/internet-drafts/draft-rosen-ecrit-ecall-04.txt Better?=20 Ciao Hannes From arnoud.vanwijk@realtimetext.org Mon Mar 8 07:26:06 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 845B23A6952 for ; Mon, 8 Mar 2010 07:26:06 -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 Tfqs0aFCGi9r for ; Mon, 8 Mar 2010 07:26:05 -0800 (PST) Received: from mx-in02.nouzelle.com (mx-in02.nouzelle.com [87.119.194.141]) by core3.amsl.com (Postfix) with ESMTP id 8B3D13A6904 for ; Mon, 8 Mar 2010 07:26:05 -0800 (PST) Received: from internal02.nouzelle.com (mail.local [172.29.32.13]) by mx-in02.nouzelle.com (Postfix) with ESMTP id 56451102139A0 for ; Mon, 8 Mar 2010 16:26:07 +0100 (CET) Received: from mailscan.nouzelle.com (unknown [172.29.32.10]) by internal02.nouzelle.com (Postfix) with ESMTP id 3A30F10219B2F for ; Mon, 8 Mar 2010 16:26:07 +0100 (CET) X-Virus-Scanned: by amavisd-new at nouzelle.com Received: from internal02.nouzelle.com ([172.29.32.13]) by mailscan.nouzelle.com (mailscan.nouzelle.com [172.29.32.10]) (amavisd-new, port 10026) with ESMTP id N4axtPtuIp07 for ; Mon, 8 Mar 2010 16:26:06 +0100 (CET) Received: from arnoud-van-wijks-macbook-pro.local (84-245-17-214.dsl.cambrium.nl [84.245.17.214]) by internal02.nouzelle.com (Postfix) with ESMTPA id B8FC610219B24 for ; Mon, 8 Mar 2010 16:26:06 +0100 (CET) Message-ID: <4B95170E.807@realtimetext.org> Date: Mon, 08 Mar 2010 16:26:06 +0100 From: Arnoud van Wijk Organization: R3TF User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: ecrit@ietf.org References: <3D3C75174CB95F42AD6BCC56E5555B45024AD827@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45024AD827@FIESEXC015.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] Vehicular Emergency Calls X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: arnoud.vanwijk@realtimetext.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 15:26:06 -0000 Hi Hannes, yes much better. Thanks :-) /Arnoud On 3/8/10 1:17 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > I tried to address the recent comments on the list about the multi-media > support. Please find the updated document here: > http://www.ietf.org/internet-drafts/draft-rosen-ecrit-ecall-04.txt > > Better? > > Ciao > Hannes > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > From gunnar.hellstrom@omnitor.se Mon Mar 8 22:13:02 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 C1B8D3A687F for ; Mon, 8 Mar 2010 22:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.314 X-Spam-Level: X-Spam-Status: No, score=-0.314 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, MSGID_MULTIPLE_AT=1.449] 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 O85OKSHrYa5U for ; Mon, 8 Mar 2010 22:12:56 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id E6A973A6868 for ; Mon, 8 Mar 2010 22:12:55 -0800 (PST) Received: from s19.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E959C290F81 for ; Tue, 9 Mar 2010 07:12:59 +0100 (CET) Received: (qmail 58814 invoked from network); 9 Mar 2010 06:12:58 -0000 Received: from h16n1fls34o265.telia.com (HELO AllaneCDator) (gunnar.hellstrom@omnitor.se@[213.64.232.16]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 9 Mar 2010 06:12:58 -0000 From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , References: <3D3C75174CB95F42AD6BCC56E5555B45024AD827@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45024AD827@FIESEXC015.nsn-intra.net> Date: Tue, 9 Mar 2010 07:13:02 +0100 Message-ID: <022901cabf4f$9320ea90$b962bfb0$@hellstrom@omnitor.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq+uVHaQPCFuEzQQYqGMHj5KIc3dwAk/G1w Content-Language: sv Subject: Re: [Ecrit] Vehicular Emergency Calls 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, 09 Mar 2010 06:13:03 -0000 Hannes, Yes, that was a good improvement in the Media paragraph. There is a similar statement in section 3, in the paragraph about "Signaling emergency calls", where it is now said: "Video and real-time text may be supported by end device in the future, although currently not envisioned. The corresponding text paragraphs are relevant from Section 9 of [2] when support is being provided." I suggest to delete the time references "in the future" and "currently". "Video and real-time text may be supported by end device. The corresponding text paragraphs are relevant from Section 9 of [2] when such support is being provided." Thanks Gunnar -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Monday, March 08, 2010 1:17 PM To: ecrit@ietf.org Subject: [Ecrit] Vehicular Emergency Calls I tried to address the recent comments on the list about the multi-media support. Please find the updated document here: http://www.ietf.org/internet-drafts/draft-rosen-ecrit-ecall-04.txt Better? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit __________ NOD32 4924 (20100308) Information __________ Detta meddelande dr genomsvkt av NOD32 Antivirus. http://www.nod32.com From hannes.tschofenig@nsn.com Wed Mar 10 01:07:08 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 4902D3A67D6 for ; Wed, 10 Mar 2010 01:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.625 X-Spam-Level: X-Spam-Status: No, score=-1.625 tagged_above=-999 required=5 tests=[AWL=-0.885, BAYES_20=-0.74] 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 q4Vr+kAKqd7e for ; Wed, 10 Mar 2010 01:07:05 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 9F3313A6765 for ; Wed, 10 Mar 2010 01:07:04 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2A9709W022461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Mar 2010 10:07:00 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2A96wwb024189; Wed, 10 Mar 2010 10:06:59 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 10:06:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Mar 2010 11:06:25 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45024DAD3E@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Sync Update Thread-Index: Acq+DjyoewJuHNkf6EyDiJzKPuwXbQCHxD3A References: <4B93595A.5070603@gmx.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Brian Rosen" , "Hannes Tschofenig" X-OriginalArrivalTime: 10 Mar 2010 09:06:58.0595 (UTC) FILETIME=[09ED2F30:01CAC031] Cc: ECRIT Subject: Re: [Ecrit] LoST Sync Update 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, 10 Mar 2010 09:07:08 -0000 Hi Brian,=20 Thanks for your detailed description. Just with the current text in NENA i3 stage 3 I was not able to capture the full picture. Your additional description at the EENA NG112 TC conference call helped me as well.=20 >From an LoST Sync document point of few I believe we need to cover both civic as well as geo boundaries. If I would like to re-use the GeoRSS mechanism my understanding is that GeoRSS only supports the encoding of GML and would not allow me to carry any civic information in there.=20 The other question that I have is whether the push mechanism is necessary with LoST Sync given that you are using GeoRSS, which utilizes a poll approach.=20 Ciao Hannes=20 >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of ext Brian Rosen >Sent: 07 March, 2010 17:53 >To: Hannes Tschofenig >Cc: 'ECRIT' >Subject: Re: [Ecrit] LoST Sync Update > >Hannes > >I am not sure of the point of this thread. No one has=20 >suggested that the NENA LoST provisioning idea be somehow=20 >adopted by the IETF (although I am sure we wouldn't object if=20 >it did). No one has suggested that there is anything "wrong"=20 >with lost-sync. This is a thread on the ecrit list, not the=20 >NENA i3 list. > >See replies in-line > > >On 3/7/10 2:44 AM, "Hannes Tschofenig"=20 > wrote: > >> Hi Brian, >>=20 >>=20 >> Brian Rosen wrote: >>> In the NENA i3 scheme, the interface to the LoST server is a set of=20 >>> GIS layers, and specifically, there are sets of polygons=20 >that define=20 >>> service boundaries. Each of these boundaries has=20 >attributes for the=20 >>> service URN URI, etc that are returned in the LosT response=20 >when the=20 >>> query location is found within the boundary. >>> =20 >>=20 >> The sentence "the interface to the LoST server is a set of=20 >GIS layers" >> sounds nice but does not make a lot of sense to me. >> An interface is a protocol or an API. A GIS layer, as you=20 >describe it=20 >> in the following sentences, is essentially mapping data. >Yes, it is "mapping data". It is the data that drive LoST=20 >query resolution. >It is represented as a set of GIS layers that are maintained=20 >on the LoST server in sync with the same layers in the master=20 >GIS system which is the authoritative source for the data. =20 >The data is the layers, the transport protocol is WFS with an ATOM feed >>=20 >> Mapping Data: >> Mapping data refers to a data structure that is defined in >> Section 5 >>=20 >> on-5> of RFC 5222. >I am not even going to go look to see if the definition in=20 >there is a complete overlap in definitions. >>=20 >>=20 >>=20 >>=20 >>> For a civic address on the query, in theory, the LoST server does a=20 >>> geocode and then point-in-polygon, but an implementation=20 >can compute=20 >>> a table to do lookups for civics. >>>=20 >>> =20 >> The question here should be how do you describe civic boundaries. If=20 >> you have no story for it then it is a bit mood to return civic=20 >> boundaries in a LoST response to the LoST client as well. >Some GIS basics, and please remember that I am not a GIS expert. > >A GIS system is a database. > >The database has records. The geodetic records are called=20 >"features". A feature is fundamentally what we often call a=20 >'geoshape' =3D point, line, circle, polygon,... A feature can=20 >have attributes (=3Dvalues associated with the feature, for=20 >example, a name, a record-id, or some other conventional data item) > >Conventionally, features are grouped into "layers" which is a=20 >set of features that have some relationship. Layers can have=20 >attributes, although we often describe a set of attributes=20 >that each feature in the layer must have. For example,=20 >consider a 'street centerline' layer. The features in this=20 >layer are lines that represent a segment of a street. Each of=20 >the lines in the layer would have attributes for (among other things) > * The name of the street > * The municipality it lies in > * The first and last address number for each side of the street > >A simpler example would be a county layer, which has polygons=20 >that represent the boundary of the county, with attributes for=20 >the name of the county, a code, and perhaps the state it belongs to. > >Another interesting layer would be an address point layer. The=20 >features are points. The attributes are "house number",=20 >street name, etc. > >So, we have a layer for each of the CAtypes > * A State layer with polygons for a state > * A county layer with polygons for counties > * A municipality layer with polygons for cites, towns > * A district layer > * A neighborhood layer > * A street layer, which could be a street centerline layer=20 >as described > above, or a set of polygons that describe the actual=20 >street geometry > * An address layer, or parcel and subparcel layers that represent > addressable parts of a road > ... > >This is a map: it lets us locate a position either by a geo or=20 >a civic. To find the location of a civic, you do a common GIS=20 >operation which does successive searches to find the address=20 >point or polygon on the road in the neighborhood (if=20 >specified) in the district (if specified) in the municipality,=20 >in the county (if specified) in the state, using the geometry=20 >and/or the attributes. In most GIS systems, this would be a=20 >conventional multi-table JOIN, because there are attributes in=20 >the features that relate them to the next highest level. > >If the result of the search was exactly one feature, then we=20 >have a unique location for the given civic address, and we=20 >take the point (if it is an address point) or a polygon (if it=20 >is a parcel/subparcel/...) that represents it (that is, we=20 >"geocode" to go from a civic to a geo). We then do PinP on=20 >the PSAP boundary layer to determine the LoST mapping. In a=20 >bit more detail, we do PinP with the sets of polygons that=20 >have a service URN attribute matching the service urn in the=20 >LoST request, and return the URI and other information in the=20 >corresponding attributes on the selected service boundary polygon set. > >This makes LosT mapping either a straight PinP for a geo, or=20 >geocode followed by PinP for a civic. > >One important reason we do it this way is that the GIS system=20 >with all these layers already exist in most PSAPs in North=20 >America. The database was created to handle wireless calls,=20 >and is used to first display where a mobile caller is calling=20 >from, and then to determine the civic address to dispatch=20 >responders to (reverse geocode). Following the latest NENA=20 >guidance, even the current table driven routing database (the=20 >"MSAG") that the 9-1-1 system now uses is DERIVED from the GIS=20 >system. When there are changes in addressing: perhaps a new=20 >street is created, or a "un-incorporated" portion of a county=20 >boundary is annexed to a city, the change is made on the=20 >master GIS system, and a new MSAG is generated from that. =20 >Going forward, essentially ALL of the location data that=20 >drives 9-1-1 is derived directly from the GIS. For i3 that=20 >means the LoST mapping data is derived from the master GIS=20 >system. Using layer replication makes this simple, and we use=20 >the same mechanism for other services in i3. > >>=20 >>=20 >>> The provisioning interface is a layer replication mechanism=20 >that uses=20 >>> two >>> parts: >>> =20 >>=20 >> I hate the term "layer replication" mechanism because it is so=20 >> meaningless in our concepts. We replicate mapping data=20 >because that is=20 >> what LoST servers at the end need. If you replicate something else=20 >> then there is the question of how this maps to the fields=20 >required for=20 >> the LoST mapping data. >Too bad. It describes exactly what we do. We have a set of=20 >layers in the master GIS system that represent the same layers=20 >in the LoST server used to do the LoST mapping. We replicate=20 >those layers from the master GIS to the slave LoST server, so=20 >that any edits to the master GIS quickly replicate on the LoST=20 >server. The LoST server IS a GIS system in this view. >>=20 >>> 1. A Web Feature Service (an OGC standard that does=20 >>> insert/delete/modify >>> operations) >>> 2. An RSS feed of WFS commands >>>=20 >>> =20 >> Nice. Solutions by referencing other standards that nobody=20 >understands. >Hello? The GIS folks know what a WFS is. NENA is not=20 >restricted to IETF standards. The GIS guys don't know what an=20 >ATOM feed is, but it's a simple enough (IETF!) standard to=20 >explain to them. WFS isn't that simple, but for your=20 >purposes, it's an add/delete/edit mechanism for a GIS system=20 >that operates on features. It uses web services for transport. > >>=20 >> While I am confident that the OGC knows what they want their concept=20 >> to use for I am not sure how well the story is complete for dealing=20 >> with LoST servers. To me this concept sounds like being at the stage=20 >> of early design work. >As is lost-sync, the difference being that the mechanism for=20 >layer sync (WFS >+ ATOM) has been implemented, trialed, and found to work in Canada. > >>=20 >> I want to have an example of how this works. Take a look at the=20 >> example we have in the LoST sync document and try to create=20 >something=20 >> with these two technologies. >I explained this above. If you are still confused, ask any=20 >GIS expert how geocoding works. After that, it works the same=20 >way a geo query to LoST would work. >>=20 >> There are two implementations of LoST Sync; the code is available. >> Are there implementions of what you describe for usage with LoST? >Yes, although not applied to a LoST server. However, the idea=20 >of geocode then PinP is not exactly stretching anything very far. > >>=20 >>> We have a "master GIS" that contains the layers that the=20 >LoST server needs. >>> =20 >> How well does this concept map to the term defined in the LoST=20 >> architecture document called "authoritative mapping server" (see=20 >> Section >> 3 of RFC 5582)? >The master GIS system is not a LoST server. It is the source=20 >of data the authoritative mapping server derives mappings=20 >from. It is how we provision the authoritative mapping=20 >server. We use the same protocol to provision any LoST server. >>=20 >>> These include polygons for the political boundaries, plus=20 >either (or=20 >>> both) centerlines or road geometry, address points or=20 >>> parcel/subparcel polygons, etc. There is a feature layer or=20 >>> attribute on a feature for each of the CAtypes. >>> =20 >>=20 >> Why do these things matter for LoST operation? What matters=20 >in LoST is=20 >> the mapping data in a LoST server. Whether these boundaries=20 >relate to=20 >> political boundaries does not matter. >See above. We use the layers to geocode civic to geo. Then=20 >we use the PSAP service boundary polygons to determine mapping=20 >in geo-space. > >>=20 >>=20 >>> As normal GIS maintenance is performed on the master=20 >(adding streets,=20 >>> changing boundaries, etc.), the WFS commands that replicate that=20 >>> change are sent as an RSS feed to the LoST server, which replicates=20 >>> the edits on its database, maintaining synchrony with the master. >>>=20 >>> We allow the LoST server to have an OUTPUT layer=20 >replication service,=20 >>> which is used on an aggregating LoST server. For example, each=20 >>> county in a state could have a LoST server, and the state=20 >could have=20 >>> a LoST server which is the aggregate of the individual counties. =20 >>> There is a gap/overlap reporting mechanism for this. >>>=20 >>> =20 >> Aggregating the mapping data in LoST servers all the way up=20 >to FGs is=20 >> OK. That's what we also describe in the LoST Sync document. >>=20 >>> One of the primary goals for this mechanism is to enable the=20 >>> boundaries to be changed on the GIS system by a normal edit=20 >function,=20 >>> and post the cache TTL, routes changes happen immediately. We use=20 >>> this in disaster scenarios when our other mechanisms to=20 >reroute calls=20 >>> don't work for the actual situation on the ground. >>> =20 >> Here is another disconnect, namely the believe that changing to=20 >> mapping data at a LoST server (even when replicated immediately to=20 >> other LoST >> servers) leads to immediate route changes. No, it doesn't since we=20 >> have built into LoST the caching concept to improve reliability,=20 >> robustness and scalability. The downside of it is that, when used of=20 >> course, changes to the mapping data are in effect only after=20 >a certain=20 >> amount of time. >Did you see the "post the cache TTL" phrase in what I wrote? > >We keep the TTLs short, for this reason. We don't think there=20 >is any problem maintaining the servers reliable or scalable=20 >with short TTLs. > >>=20 >> Unless you make some further assumptions, which you did not state in=20 >> your paragraph above. >>=20 >>=20 >> Ciao >> Hannes >>=20 >>> Brian >>>=20 >>>=20 >>> On 3/6/10 3:44 PM, "Hannes Tschofenig"=20 > wrote: >>>=20 >>> =20 >>>> I have re-submitted a version of the LoST sync document. >>>> The update reflects the comments from Karl Heinz and Alex. >>>>=20 >>>> As you have seen, I have solicited feedback from the XML /=20 >Relax NG=20 >>>> experts regarding the schema. I hope to get a response soon. >>>>=20 >>>> I would also like to get some feedback from comments I=20 >filed against=20 >>>> the NENA i3 stage 3 specification. The NENA spec hints to a=20 >>>> different synchronization mechanisms (as Brian mentioned already=20 >>>> many times) but I failed to understand how it works. I=20 >would like to=20 >>>> see what the similarity and the differences are. Since the i3 spec=20 >>>> is supposed to be completed very soon I assume clarifications=20 >>>> regarding the synchronization aspects will have to get=20 >discussed as well. >>>>=20 >>>> Ciao >>>> Hannes >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> =20 >>>=20 >>> =20 >>=20 > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > From bernard_aboba@hotmail.com Wed Mar 10 13:16:43 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 636CF3A6A1B for ; Wed, 10 Mar 2010 13:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.592 X-Spam-Level: X-Spam-Status: No, score=-0.592 tagged_above=-999 required=5 tests=[AWL=-0.594, 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 U62-D5c1SgeD for ; Wed, 10 Mar 2010 13:16:03 -0800 (PST) Received: from blu0-omc3-s4.blu0.hotmail.com (blu0-omc3-s4.blu0.hotmail.com [65.55.116.79]) by core3.amsl.com (Postfix) with ESMTP id F14EE3A68EE for ; Wed, 10 Mar 2010 13:15:59 -0800 (PST) Received: from BLU137-DS14 ([65.55.116.74]) by blu0-omc3-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 13:16:04 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Wed, 10 Mar 2010 13:16:55 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01CAC053.F4D02260" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrAlwKiygvc1D/0T02T71F+bZWFjQ== Content-Language: en-us X-OriginalArrivalTime: 10 Mar 2010 21:16:04.0831 (UTC) FILETIME=[E4B70EF0:01CAC096] Subject: [Ecrit] FCC to Hold a Colloqium on Public Safety and Homeland Security Portion of the National Broadband Plan (fwd) 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, 10 Mar 2010 21:16:46 -0000 ------=_NextPart_000_007C_01CAC053.F4D02260 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit FOR IMMEDIATE RELEASE: NEWS MEDIA CONTACT March 8, 2010 Robert Kenny: (202) 418-2668 Email: robert.kenny@fcc.gov FEDERAL COMMUNICATIONS COMMISSION TO HOLD A COLLOQUIUM ON PUBLIC SAFETY AND HOMELAND SECURITY PORTION OF THE NATIONAL BROADBAND PLAN Washington, D.C. - The Federal Communications Commission's (FCC's) Public Safety and Homeland Security Bureau (Bureau) today announced it will hold a colloquium on Friday, March 26, 2010 from 9:00 a.m.-11:00 a.m. to discuss the public safety and homeland security portion of the National Broadband Plan (Plan) that will have since been submitted to Congress on March 17, 2010. The event will be held in the Commission Meeting Room (TW-C305). As part of the colloquium, representatives from the Public Safety and Homeland Security Bureau will make presentations discussing how the Plan addresses the following issues: . Deployment of a nationwide interoperable public safety wireless broadband network; . Innovation in the development and deployment of Next Generation 911 networks and emergency alerting systems; and . Cyber security and critical infrastructure survivability. The goal of the Public Safety and Homeland Security portion of the Plan is to enable and enhance the use of broadband technologies by first responders in sending and receiving content-rich data, resulting in saved lives; diminished injuries; improved emergency care and response; and more effective prevention of acts of crime, terror and hatred. Such technologies will also guard critical infrastructure, and enable interoperable response to emergencies in coordination with other first responders located throughout the nation. Broadband technologies will ensure that all Americans are able to reach and access 9-1-1 services quickly, reliably, and that the public has the ability to send and receive critical information regardless of the mode or device used. These technologies and innovations will also advance the modes and methods by which the public receives accurate, concise, and timely alerts and warnings. The Public Safety and Homeland Security portion of the Plan will also enhance the security and resiliency of broadband infrastructure, including measures to prevent and assist in the response to cyber attacks. The colloquium will be open to the public; admittance, however, will be limited to the seating available. Those individuals who are interested in attending this event may pre-register on-line at http://www.fcc.gov/pshs/event-registration.html. Those who pre-register will be asked to provide their name, title, organization affiliation, and contact information. Individuals may also contact Deandrea Wilson at Deandrea.Wilson@fcc.gov or via phone at 202-418-0703 regarding pre-registration. The deadline for pre-registration is Wednesday, March 24, 2010. Audio/Video coverage of the meeting will be broadcast live with open captioning over the Internet from the FCC's web page at www.reboot.fcc.gov (go to "Events"). The FCC's web cast is free to the public and does not require pre-registration. Reasonable accommodations for persons with disabilities are available upon request. Please include a description of the accommodation you will need. Individuals making such requests must include their contact information should FCC staff need to contact them for more information. Requests should be made as early as possible. Please send an e-mail to fcc504@fcc.gov or call the Consumer & Governmental Affairs Bureau: 202-418-0530 (voice), 202-418-0432 (TTY). For additional information about the meeting, please contact Susan McLean at (202) 418-7868 or by email: Susan.McLean@fcc.gov. - FCC - ------=_NextPart_000_007C_01CAC053.F4D02260 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

FOR IMMEDIATE = RELEASE:       &nb= sp;           &nbs= p;            = ;         NEWS MEDIA CONTACT

 March 8, = 2010           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           Robert Kenny:  (202) 418-2668

Email: robert.kenny@fcc.gov =

 

FEDERAL COMMUNICATIONS COMMISSION TO HOLD A = COLLOQUIUM ON PUBLIC SAFETY AND HOMELAND SECURITY PORTION OF = THE

NATIONAL BROADBAND = PLAN

 

Washington, D.C. – The Federal Communications Commission’s = (FCC’s) Public Safety and Homeland Security Bureau (Bureau) today announced it = will hold a colloquium on Friday, March 26, 2010 from 9:00 a.m.-11:00 a.m. to discuss the public safety and homeland security portion of the National Broadband Plan (Plan) that will have since been submitted to Congress on = March 17, 2010.  The event will be held in the Commission Meeting Room = (TW-C305).  

 

As part of the colloquium, representatives from the Public Safety and = Homeland Security Bureau will make presentations discussing how the Plan = addresses the following issues:

 

·         Deployment of a nationwide interoperable public safety wireless broadband = network;

·         Innovation in the development and deployment of Next Generation 911 networks and emergency alerting systems; and

·         Cyber = security and critical infrastructure survivability.

 

The goal of the Public Safety and Homeland Security portion of the Plan is = to enable and enhance the use of broadband technologies by first responders = in sending and receiving content-rich data, resulting in saved lives; = diminished injuries; improved emergency care and response; and more effective = prevention of acts of crime, terror and hatred.  Such technologies will also = guard critical infrastructure, and enable interoperable response to = emergencies in coordination with other first responders located throughout the nation.  = Broadband technologies will ensure that all Americans are able to reach and access = 9-1-1 services quickly, reliably, and that the public has the ability to send = and receive critical information regardless of the mode or device used. = These technologies and innovations will also advance the modes and methods by = which the public receives accurate, concise, and timely alerts and = warnings.  The Public Safety and Homeland Security portion of the Plan will also = enhance the security and resiliency of broadband infrastructure, including measures = to prevent and assist in the response to cyber attacks. =

 

The colloquium will be open to the public; admittance, however, will be = limited to the seating available. Those individuals who are interested in attending = this event may pre-register on-line at http://www.fcc.gov/pshs/event-registration.html. Those who = pre-register will be asked to provide their name, title, organization affiliation, = and contact information.  Individuals may also contact Deandrea Wilson = at Deandrea.Wilson@fcc.gov or via phone at 202-418-0703 regarding pre-registration.  The = deadline for pre-registration is Wednesday, March 24, 2010.

 

Audio/Video coverage of the meeting will be = broadcast live with open captioning over the Internet from the FCC's web page at = www.reboot.fcc.gov (go to “Events”).  The = FCC’s web cast is free to the public and does not require = pre-registration.

 

Reasonable accommodations for persons with disabilities are available upon = request.  Please include a description of the accommodation you will need.  = Individuals making such requests must include their contact information should FCC = staff need to contact them for more information.  Requests should be made = as early as possible.  Please send an e-mail to fcc504@fcc.gov or call the Consumer & Governmental Affairs Bureau: 202-418-0530 = (voice), 202-418-0432 (TTY). 

 

For additional information about the meeting, please contact Susan = McLean = at (202) 418-7868 or by email: Susan.McLean@fcc.gov.

 

- FCC -

 

 

=

 

=
------=_NextPart_000_007C_01CAC053.F4D02260-- From Martin.Thomson@andrew.com Thu Mar 11 15:58:14 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 F17973A6922 for ; Thu, 11 Mar 2010 15:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 ymDgYUb2hqON for ; Thu, 11 Mar 2010 15:58:13 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 3219A3A68DB for ; Thu, 11 Mar 2010 15:58:13 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:21691 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S14284357Ab0CKX6S (ORCPT ); Thu, 11 Mar 2010 17:58:18 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 11 Mar 2010 17:58:18 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 12 Mar 2010 07:58:16 +0800 From: "Thomson, Martin" To: "ecrit@ietf.org" Date: Fri, 12 Mar 2010 07:59:31 +0800 Thread-Topic: Holes and security Thread-Index: AcrBduRZilxInDrTQTmT66i81X2jgw== Message-ID: <8B0A9FCBB9832F43971E38010638454F03DF0986F6@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: [Ecrit] Holes and security X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 23:58:14 -0000 VGhlIG9yaWdpbmFsIGhvbGVzIGRyYWZ0IGhhZCB0aGlzIGZvciBzZWN1cml0eSBjb25zaWRlcmF0 aW9uczoNCg0KICAgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBpbnRyb2R1Y2UgYW55IHNlY3VyaXR5 IGlzc3Vlcy4NCg0KV2hpY2ggSSBzdGlsbCBiZWxpZXZlIHRvIGJlIHRydWUuICBCdXQgY29uc2lk ZXJpbmcgdGhlIHdpZGVyIGltcGxpY2F0aW9ucywgdGhlcmUgbWlnaHQgYmUgc29tZXRoaW5nIHRv IGFkZC4gDQoNCkFyZSB0aGVyZSBhbnkgb2JqZWN0aW9ucyB0byBpbmNsdWRpbmcgdGhlIGZvbGxv d2luZyB0ZXh0Pw0KDQogICBDb25zdHJhaW5pbmcgdGhlIGZvcm0gb2YgYSBwb2x5Z29uIHJlcHJl c2VudGF0aW9uIGFzIGRlc2NyaWJlZCBpbg0KICAgdGhpcyBkb2N1bWVudCBkb2VzIG5vdCBpbnRy b2R1Y2UgbmV3IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLg0KICAgSG93ZXZlciwgdXNpbmcgcG9s eWdvbnMgdG8gZGVzY3JpYmUgTG9TVCBzZXJ2aWNlIGJvdW5kYXJpZXMgY2FuIGhhdmUNCiAgIHRo ZSBmb2xsb3dpbmcgY29uY2VybnM6DQoJDQogICBvICBQcmVjaXNlIHNlcnZpY2UgYm91bmRhcmll cyB3aXRoIGhvbGVzIGNhbiBoYXZlIGxhcmdlIG51bWJlcnMgb2YNCiAgICAgIHBvaW50cy4gIFRo aXMgcmVzdWx0cyBpbiBMb1NUIHJlc3BvbnNlcyBvZiBzaWduaWZpY2FudCBzaXplIGFuZA0KICAg ICAgY29tcGxleGl0eS4NCg0KICAgbyAgQSBMb1NUIHNlcnZlciBtaWdodCBub3Qgd2FudCB0byBy ZXZlYWwgc2VydmljZSBib3VuZGFyaWVzIHRvDQogICAgICBjbGllbnRzLg0KDQogICBCb3RoIHRo ZXNlIGNhc2VzIGNhbiBiZSBhZGRyZXNzZWQgYnkgcHJvdmlkaW5nIHNtYWxsZXIsIHNpbXBsZXIN CiAgIHNlcnZpY2UgYm91bmRhcnkgcG9seWdvbiBpbiBMb1NUIHJlc3BvbnNlcy4gIFRoaXMgc21h bGxlciBwb2x5Z29uDQogICBNVVNUIGZpdCB3aXRoaW4gdGhlIGFjdHVhbCBzZXJ2aWNlIGJvdW5k YXJ5LiAgVGhpcyBpcyBwb3NzaWJsZQ0KICAgYmVjYXVzZSBhIExvU1Qgc2VydmVyIGlzIG5vdCBy ZXF1aXJlZCB0byBwcm92aWRlIGEgcHJlY2lzZSBzZXJ2aWNlDQogICBib3VuZGFyeS4gIFRoZSBz ZXJ2aWNlIGJvdW5kYXJ5IG5lZWQgb25seSBpbmRpY2F0ZSBhbiBhcmVhIHdpdGhpbg0KICAgd2hp Y2ggdGhlIHNlcnZpY2UgbWFwcGluZyBkb2VzIG5vdCBjaGFuZ2UuDQoNCkkgZGlkbid0IGZpbmQg YW55dGhpbmcgb2YgdGhpcyBzb3J0IGluIFJGQzUyMjIsIGJ1dCBJIHRoaW5rIHRoYXQgaXQncyBh IHdvcnRod2hpbGUgYWRkaXRpb24uDQoNCi0tTWFydGluDQo= From mlinsner@cisco.com Fri Mar 12 06:27:20 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E26D13A6D11 for ; Fri, 12 Mar 2010 06:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uClNN2SECcZ for ; Fri, 12 Mar 2010 06:27:20 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id ABDB03A692D for ; Fri, 12 Mar 2010 06:08:24 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMrZmUtAZnwN/2dsb2JhbACaa3OiO4sSjUaCcIILBIMX X-IronPort-AV: E=Sophos;i="4.49,626,1262563200"; d="scan'208";a="92114814" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 Mar 2010 14:08:30 +0000 Received: from [10.116.195.116] (rtp-mlinsner-8713.cisco.com [10.116.195.116]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2CE8Tr7028597; Fri, 12 Mar 2010 14:08:29 GMT User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 12 Mar 2010 09:08:23 -0500 From: Marc Linsner To: "Thomson, Martin" , "ecrit@ietf.org" Message-ID: Thread-Topic: [Ecrit] Holes and security Thread-Index: AcrBduRZilxInDrTQTmT66i81X2jgwAdpWNQ In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03DF0986F6@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Ecrit] Holes and security 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, 12 Mar 2010 14:27:21 -0000 Martin, My first take on this pertains to the scope of IETF document 'security' sections. It seems the proposed text is creeping outside the topic of protocol security to application/implementation areas. Wouldn't this be better stated in a section of the document pertaining to 'implementation issues'? The analogy that comes to mind would lead to all IETF document security sections will end up telling users the equivalent of, 'If you send your password in the body of an email the recipient of the email will then have your password.' My take is the security section should deal with protocol security. FWIW, -Marc- On 3/11/10 6:59 PM, "Thomson, Martin" wrote: > The original holes draft had this for security considerations: > > This document does not introduce any security issues. > > Which I still believe to be true. But considering the wider implications, > there might be something to add. > > Are there any objections to including the following text? > > Constraining the form of a polygon representation as described in > this document does not introduce new security considerations. > However, using polygons to describe LoST service boundaries can have > the following concerns: > > o Precise service boundaries with holes can have large numbers of > points. This results in LoST responses of significant size and > complexity. > > o A LoST server might not want to reveal service boundaries to > clients. > > Both these cases can be addressed by providing smaller, simpler > service boundary polygon in LoST responses. This smaller polygon > MUST fit within the actual service boundary. This is possible > because a LoST server is not required to provide a precise service > boundary. The service boundary need only indicate an area within > which the service mapping does not change. > > I didn't find anything of this sort in RFC5222, but I think that it's a > worthwhile addition. > > --Martin > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From fluffy@cisco.com Fri Mar 12 15:08:58 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 1BE493A68BC for ; Fri, 12 Mar 2010 15:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.48 X-Spam-Level: X-Spam-Status: No, score=-110.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 upPPxYizM3-T for ; Fri, 12 Mar 2010 15:08:56 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 37ED93A68A4 for ; Fri, 12 Mar 2010 15:08:56 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANJYmkurR7H+/2dsb2JhbACaanOjIphbglWCJgSDFw X-IronPort-AV: E=Sophos;i="4.49,628,1262563200"; d="scan'208";a="165354126" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 12 Mar 2010 23:09:02 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2CN91U1020133; Fri, 12 Mar 2010 23:09:01 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4B90CFB2.2070504@gmx.net> Date: Fri, 12 Mar 2010 16:09:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <802E2323-8AA8-44F6-8D41-406C05820F4A@cisco.com> References: <4B90CFB2.2070504@gmx.net> To: Hannes Tschofenig , ECRIT X-Mailer: Apple Mail (2.1077) Subject: Re: [Ecrit] ECRIT Agenda Version 3 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, 12 Mar 2010 23:08:58 -0000 This is a lot of things to fit in 2.5 hours. It's possible that if I saw = how much time each had it would all look find but I'm very worried about = just starting new work and not finishing things. I want to be sure there = is no time required for any of the current WG items.=20 Cullen On Mar 5, 2010, at 2:32 AM, Hannes Tschofenig wrote: > ECRIT Meeting Agenda (Version 3) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >=20 > MONDAY, March 22, 2010 > 0900-1130 Morning Session I=20 > Room: Palos Verdes >=20 > * Agenda Bashing and Status Update (Marc, Hannes, Roger) >=20 > * PSAP Callback (TBD) > http://trac.tools.ietf.org/wg/ecrit/trac/wiki > http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback >=20 > Intention: Discuss potential feedback from emergency services groups = on > the requirements for this work. >=20 > * Unauthenticated emergency services (Dirk) > = http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access >=20 > Intention: Determine next steps. The group wants to work on it but = there > are still lots of open issues and re-chartering is required to add it = to > the milestone list.=20 > * Transformations ID (James P.) > http://tools.ietf.org/id/draft-polk-ecrit-lost-transformations-urn >=20 > Intention: TBD. >=20 > * ECRIT Direct (James W.) > http://tools.ietf.org/id/draft-winterbottom-ecrit-direct >=20 > Intention: TBD.=20 > * Additional Data (Brian) > http://tools.ietf.org/id/draft-rosen-ecrit-additional-data >=20 > Intention: Initial document version. Presentation of the history and = the > origin of the work. Determine interest. >=20 > * Data Only Emergency Calls (Brian) > http://tools.ietf.org/id/draft-rosen-ecrit-data-only-ea >=20 > Intention: TBD. >=20 > * Completing the Request Location (Brian) > http://tools.ietf.org/id/draft-rosen-ecrit-completed-location-00.txt >=20 > Intention: Discussion whether the group should work on this document. = The document is making a normative change to RFC 5222. >=20 > * Service URN Update and Service Classification (Henning) > http://tools.ietf.org/id/draft-forte-ecrit-service-classification > http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy > Intention: Documents are a bit stuck although group agreed to = work on > it. Henning will present a way forward.=20 > * Emergency Text Messaging using SIP MESSAGE (Henning) > http://tools.ietf.org/id/draft-kim-ecrit-text-00.txt >=20 > Intention: Discussion about what the group should do in this area. >=20 > * Describing Boundaries for Civic Addresse > http://tools.ietf.org/id/draft-thomson-ecrit-civic-boundary-00.txt >=20 > Intention: Discussion whether the group should work on this doc.=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From hannes.tschofenig@nsn.com Sun Mar 14 12:10:14 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 0904A3A69FB for ; Sun, 14 Mar 2010 12:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 EW2nKcq5FpM3 for ; Sun, 14 Mar 2010 12:10:13 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 6E5FE3A69FF for ; Sun, 14 Mar 2010 12:09:57 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2EJA2Mf028182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 14 Mar 2010 20:10:02 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2EJA1CQ004671 for ; Sun, 14 Mar 2010 20:10:01 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 14 Mar 2010 20:10:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 14 Mar 2010 21:10:01 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45025114BB@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda Thread-Index: AcrDU+/98+iFf5STQaOTqM3c1aAQOA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 14 Mar 2010 19:10:01.0868 (UTC) FILETIME=[F27D7CC0:01CAC3A9] Subject: [Ecrit] Agenda 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: Sun, 14 Mar 2010 19:10:14 -0000 Hi all,=20 The uploaded agenda can be found here http://www.ietf.org/proceedings/10mar/agenda/ecrit.txt As Cullen noted there is a lot of stuff on our agenda and in order to be able to deal with all the topics I would like to request two things from you:=20 * Please let us know what the intention of your presentation is and whether there are some sticking points you would like to discuss.=20 * Start working on the slides as soon as possible. We want to see them next week so that we do not run into surprises.=20 Ciao Hannes From br@brianrosen.net Sun Mar 14 12:55:12 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37ABA3A6452 for ; Sun, 14 Mar 2010 12:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 I-NRNfrMmdgw for ; Sun, 14 Mar 2010 12:55:11 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id 036BE3A6813 for ; Sun, 14 Mar 2010 12:55:10 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.17]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nqttx-00041P-Qj; Sun, 14 Mar 2010 14:55:06 -0500 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Sun, 14 Mar 2010 15:55:01 -0500 From: Brian Rosen To: Cullen Jennings , Hannes Tschofenig , ECRIT Message-ID: Thread-Topic: [Ecrit] ECRIT Agenda Version 3 Thread-Index: AcrDsDtMBaW58bL90Uio3GFEN7TAeQ== In-Reply-To: <802E2323-8AA8-44F6-8D41-406C05820F4A@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 Subject: Re: [Ecrit] ECRIT Agenda Version 3 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: Sun, 14 Mar 2010 19:55:12 -0000 I don't see any issues with -phonebcp and -framework that would need meeting time. Brian On 3/12/10 6:09 PM, "Cullen Jennings" wrote: > > This is a lot of things to fit in 2.5 hours. It's possible that if I saw how > much time each had it would all look find but I'm very worried about just > starting new work and not finishing things. I want to be sure there is no time > required for any of the current WG items. > > Cullen > > > On Mar 5, 2010, at 2:32 AM, Hannes Tschofenig wrote: > >> ECRIT Meeting Agenda (Version 3) >> ================================ >> >> MONDAY, March 22, 2010 >> 0900-1130 Morning Session I >> Room: Palos Verdes >> >> * Agenda Bashing and Status Update (Marc, Hannes, Roger) >> >> * PSAP Callback (TBD) >> http://trac.tools.ietf.org/wg/ecrit/trac/wiki >> http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback >> >> Intention: Discuss potential feedback from emergency services groups on >> the requirements for this work. >> >> * Unauthenticated emergency services (Dirk) >> http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access >> >> Intention: Determine next steps. The group wants to work on it but there >> are still lots of open issues and re-chartering is required to add it to >> the milestone list. >> * Transformations ID (James P.) >> http://tools.ietf.org/id/draft-polk-ecrit-lost-transformations-urn >> >> Intention: TBD. >> >> * ECRIT Direct (James W.) >> http://tools.ietf.org/id/draft-winterbottom-ecrit-direct >> >> Intention: TBD. >> * Additional Data (Brian) >> http://tools.ietf.org/id/draft-rosen-ecrit-additional-data >> >> Intention: Initial document version. Presentation of the history and the >> origin of the work. Determine interest. >> >> * Data Only Emergency Calls (Brian) >> http://tools.ietf.org/id/draft-rosen-ecrit-data-only-ea >> >> Intention: TBD. >> >> * Completing the Request Location (Brian) >> http://tools.ietf.org/id/draft-rosen-ecrit-completed-location-00.txt >> >> Intention: Discussion whether the group should work on this document. The >> document is making a normative change to RFC 5222. >> >> * Service URN Update and Service Classification (Henning) >> http://tools.ietf.org/id/draft-forte-ecrit-service-classification >> http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy >> Intention: Documents are a bit stuck although group agreed to work on >> it. Henning will present a way forward. >> * Emergency Text Messaging using SIP MESSAGE (Henning) >> http://tools.ietf.org/id/draft-kim-ecrit-text-00.txt >> >> Intention: Discussion about what the group should do in this area. >> >> * Describing Boundaries for Civic Addresse >> http://tools.ietf.org/id/draft-thomson-ecrit-civic-boundary-00.txt >> >> Intention: Discussion whether the group should work on this doc. >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From Martin.Thomson@andrew.com Sun Mar 14 17:40:45 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 A736A3A6897 for ; Sun, 14 Mar 2010 17:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.525 X-Spam-Level: X-Spam-Status: No, score=-1.525 tagged_above=-999 required=5 tests=[AWL=-0.785, BAYES_20=-0.74] 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 zfM1k7OjyHZ9 for ; Sun, 14 Mar 2010 17:40:44 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id AE6C23A6836 for ; Sun, 14 Mar 2010 17:40:44 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:5203 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S14494998Ab0COAkv (ORCPT ); Sun, 14 Mar 2010 19:40:51 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 14 Mar 2010 19:40:51 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 15 Mar 2010 08:40:47 +0800 From: "Thomson, Martin" To: Marc Linsner , "ecrit@ietf.org" Date: Mon, 15 Mar 2010 08:42:05 +0800 Thread-Topic: [Ecrit] Holes and security Thread-Index: AcrBduRZilxInDrTQTmT66i81X2jgwAdpWNQAHlmczA= Message-ID: <8B0A9FCBB9832F43971E38010638454F03E0A2FF17@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03DF0986F6@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Ecrit] Holes and security 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, 15 Mar 2010 00:40:45 -0000 SGkgTWFyYywNCg0KPiBXb3VsZG4ndCB0aGlzIGJlDQo+IGJldHRlciBzdGF0ZWQgaW4gYSBzZWN0 aW9uIG9mIHRoZSBkb2N1bWVudCBwZXJ0YWluaW5nIHRvDQo+ICdpbXBsZW1lbnRhdGlvbiBpc3N1 ZXMnPw0KDQpUaGF0J3MgYSBnb29kIHF1ZXN0aW9uLiAgVG8gd2hhdCBleHRlbnQgZG9lcyB0aGUg cG9zc2liaWxpdHkgb2YgcmVjZWl2aW5nIGEgbGFyZ2UgYW5kIGNvbXBsZXggcmVzcG9uc2UgY29u c3RpdHV0ZSBhIHNlY3VyaXR5IGNvbmNlcm4/ICBBcyB5b3Ugc2F5LCB5b3UgY291bGQgc2F5IHRo YXQgaXQncyBub3Qgb3VyIHByb2JsZW0gYW5kIGxldCB0aGUgaW1wbGVtZW50YXRpb24gZGVhbCB3 aXRoIGl0LiAgSG93ZXZlciwgcmVhZGluZyA1NDkxIGFuZCA1MjIyLCBhbiBMb1NUIGNsaWVudCBp bXBsZW1lbnRlciBjb3VsZCBlYXNpbHkgbWFrZSBzb21lIHZlcnkgd3JvbmcgYXNzdW1wdGlvbnMg YWJvdXQgdGhlIG5hdHVyZSBvZiBzZXJ2aWNlIGJvdW5kYXJpZXMgYW5kIHRoZWlyIHNpemUuDQoN CkkgY2FuIHNlZSBob3cgdGhhdCBtaWdodCBsZWFkIHRvIGEgc2VjdXJpdHkgcHJvYmxlbSwgYnV0 IHdpbGwgYWdyZWUgdGhhdCB0aGlzIGNvdWxkIGJlIGp1c3QgYW4gaW1wbGVtZW50YXRpb24gY29u Y2Vybi4gIE9uIHRoZSBvdGhlciBoYW5kLCB0aGUgcHJpdmFjeSBhc3BlY3QgbWlnaHQgd2FycmFu dCBpdHMgbWVudGlvbiBpbiBhIHNlY3VyaXR5IHNlY3Rpb24uDQoNCkkgZG9uJ3QgbWluZCBpZiB0 aGlzIGVuZHMgdXAgYmVpbmcgbW92ZWQgb3Igbm90IGFkZGVkIGF0IGFsbC4gIA0KDQo+IFRoZSBh bmFsb2d5IHRoYXQgY29tZXMgdG8gbWluZCB3b3VsZCBsZWFkIHRvIGFsbCBJRVRGIGRvY3VtZW50 IHNlY3VyaXR5DQo+IHNlY3Rpb25zIHdpbGwgZW5kIHVwIHRlbGxpbmcgdXNlcnMgdGhlIGVxdWl2 YWxlbnQgb2YsICdJZiB5b3Ugc2VuZCB5b3VyDQo+IHBhc3N3b3JkIGluIHRoZSBib2R5IG9mIGFu IGVtYWlsIHRoZSByZWNpcGllbnQgb2YgdGhlIGVtYWlsIHdpbGwgdGhlbg0KPiBoYXZlIHlvdXIg cGFzc3dvcmQuJw0KDQpJIGNhbiBzZWUgaG93IGluZHVjdGl2ZSByZWFzb25pbmcgY291bGQgYmUg YXBwbGllZCB0byByZWFjaCB0aGlzIGNvbmNsdXNpb24uICBJIGRvbid0IHRoaW5rIHRoYXQgaXQn cyBuZWNlc3NhcnkgdG8gZm9sbG93IGV2ZXJ5IGxvZ2ljYWwgcGF0aCB0byBpdHMgZXh0cmVtZSA6 KQ0KDQo+IE15IHRha2UgaXMgdGhlIHNlY3VyaXR5IHNlY3Rpb24gc2hvdWxkIGRlYWwgd2l0aCBw cm90b2NvbCBzZWN1cml0eS4NCg0KSSdtIG5vdCBzdXJlIHRoYXQgdGhpcyBpcyBlbnRpcmVseSBj b25zaXN0ZW50IHdpdGggcGFzdCBwcmFjdGljZS4gIFdlIHJvdXRpbmVseSBkaXNjdXNzIHdoYXQg aW1wbGVtZW50YXRpb25zIG1pZ2h0IGxpa2UgdG8gZG8uICBJbiBHRU9QUklWIHdlIHJvdXRpbmVs eSBkaXNjdXNzIHByaXZhY3kgaXNzdWVzIGluIHRoZSBjb250ZXh0IG9mIHNlY3VyaXR5Lg0KDQot LU1hcnRpbg0K From mlinsner@cisco.com Mon Mar 15 10:33:06 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 C034C3A6A2D for ; Mon, 15 Mar 2010 10:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBy3fBaZ5aUq for ; Mon, 15 Mar 2010 10:33:05 -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 357C53A6BC0 for ; Mon, 15 Mar 2010 10:31:02 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALILnktAZnwN/2dsb2JhbACacXOhf4sTjGGCcIILBA X-IronPort-AV: E=Sophos;i="4.49,644,1262563200"; d="scan'208";a="92949172" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 15 Mar 2010 17:31:09 +0000 Received: from [10.123.3.173] (rtp-vpn2-1621.cisco.com [10.82.246.87]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2FHV6Bw010643; Mon, 15 Mar 2010 17:31:08 GMT User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 15 Mar 2010 13:31:04 -0400 From: Marc Linsner To: "Thomson, Martin" , "ecrit@ietf.org" Message-ID: Thread-Topic: [Ecrit] Holes and security Thread-Index: AcrBduRZilxInDrTQTmT66i81X2jgwAdpWNQAHlmczAAJI19nw== In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E0A2FF17@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Ecrit] Holes and security 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, 15 Mar 2010 17:33:06 -0000 Martin, I'm certainly not going get worked up about these kinds of statements in the security section. ISTM a funny place to put it. -Marc- On 3/14/10 8:42 PM, "Thomson, Martin" wrote: > Hi Marc, > >> Wouldn't this be >> better stated in a section of the document pertaining to >> 'implementation issues'? > > That's a good question. To what extent does the possibility of receiving a > large and complex response constitute a security concern? As you say, you > could say that it's not our problem and let the implementation deal with it. > However, reading 5491 and 5222, an LoST client implementer could easily make > some very wrong assumptions about the nature of service boundaries and their > size. > > I can see how that might lead to a security problem, but will agree that this > could be just an implementation concern. On the other hand, the privacy > aspect might warrant its mention in a security section. > > I don't mind if this ends up being moved or not added at all. > >> The analogy that comes to mind would lead to all IETF document security >> sections will end up telling users the equivalent of, 'If you send your >> password in the body of an email the recipient of the email will then >> have your password.' > > I can see how inductive reasoning could be applied to reach this conclusion. > I don't think that it's necessary to follow every logical path to its extreme > :) > >> My take is the security section should deal with protocol security. > > I'm not sure that this is entirely consistent with past practice. We > routinely discuss what implementations might like to do. In GEOPRIV we > routinely discuss privacy issues in the context of security. > > --Martin From jmpolk@cisco.com Mon Mar 15 12:09:09 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6423A6886 for ; Mon, 15 Mar 2010 12:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPrHwnBV9HW7 for ; Mon, 15 Mar 2010 12:09:07 -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 76BFC3A67B2 for ; Mon, 15 Mar 2010 12:08:51 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACIjnkurR7H+/2dsb2JhbACac3OhXZgKgk6CLQSDGg X-IronPort-AV: E=Sophos;i="4.49,644,1262563200"; d="scan'208";a="166463534" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2010 19:08:55 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2FJ8s48022210 for ; Mon, 15 Mar 2010 19:08:55 GMT Message-Id: <201003151908.o2FJ8s48022210@sj-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 15 Mar 2010 14:08:53 -0500 To: "'ECRIT'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ecrit] Revved the Transformations URN ID 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, 15 Mar 2010 19:09:09 -0000 ECRIT re: http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-transformations-urn-01.txt This version is much more complete (only lacking the LoST examples). There only sticking point is whether LoST should be used by a client to get this information - or if a pure HTTP transaction should be used to geocode/reverse-geocode. I believe it is fairly logical for a URN to identify the service of "format transformation". I believe a client will not generally know which server to ask for this information -- without that server being a "Google Maps"-style well-known URL. With that in mind, it appears fairly obvious that LoST can be used, with a well known URN (denoting the service desired) to ask a LoST server for this information (when geocoding is involved), or be pointed to an appropriate URI that can do this transformation. This ID offers both options, with the LoST server deciding whether or not it will fulfill the transformation (when location transformation is the URN). If the LoST server wishes to return the transformed location, a single transaction is all that's needed by the client - increasing the user experience. If the LoST server can't or does not want to return the transformed location information, it returns the URI for that (URN) service, as is the case with most (all?) other LoST transactions. Comments and questions are appreciated James From br@brianrosen.net Mon Mar 15 12:29:35 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7EE03A698C for ; Mon, 15 Mar 2010 12:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=-0.015, 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 7H4wI0EHmjR6 for ; Mon, 15 Mar 2010 12:29:35 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id 2DEE23A6944 for ; Mon, 15 Mar 2010 12:29:33 -0700 (PDT) Received: from [209.173.57.233] (helo=[192.168.130.39]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1NrFyk-0008MH-Ku; Mon, 15 Mar 2010 14:29:30 -0500 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 15 Mar 2010 15:29:32 -0500 From: Brian Rosen To: James Polk , 'ECRIT' Message-ID: Thread-Topic: [Ecrit] Revved the Transformations URN ID Thread-Index: AcrEddZbWGZjImqGUEaIaJCn7aBv6Q== In-Reply-To: <201003151908.o2FJ8s48022210@sj-core-2.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 Subject: Re: [Ecrit] Revved the Transformations URN ID 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, 15 Mar 2010 19:29:36 -0000 Personally, I don't see the URN as having any real value. I think all we need is a simple web service: send in a PIDF, get one back. If you send a geo, you get a civic and vice versa. If you insist, have two services: geocode and reverse-geocode. Why would we want to be more complicated then that? Specifically, why would we want to invent a URN to tell us what transformation we want? Brian On 3/15/10 2:08 PM, "James Polk" wrote: > ECRIT > > re: > http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-transformations-urn- > 01.txt > > This version is much more complete (only lacking the LoST examples). > > There only sticking point is whether LoST should be used by a client > to get this information - or if a pure HTTP transaction should be > used to geocode/reverse-geocode. > > I believe it is fairly logical for a URN to identify the service of > "format transformation". > > I believe a client will not generally know which server to ask for > this information -- without that server being a "Google Maps"-style > well-known URL. With that in mind, it appears fairly obvious that > LoST can be used, with a well known URN (denoting the service > desired) to ask a LoST server for this information (when geocoding is > involved), or be pointed to an appropriate URI that can do this > transformation. > > This ID offers both options, with the LoST server deciding whether or > not it will fulfill the transformation (when location transformation > is the URN). If the LoST server wishes to return the transformed > location, a single transaction is all that's needed by the client - > increasing the user experience. If the LoST server can't or does not > want to return the transformed location information, it returns the > URI for that (URN) service, as is the case with most (all?) other > LoST transactions. > > Comments and questions are appreciated > > James > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From apenniston@geo-comm.com Mon Mar 15 14:49:35 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5623A69A1 for ; Mon, 15 Mar 2010 14:49: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 1PfW9ejHVXAB for ; Mon, 15 Mar 2010 14:49:34 -0700 (PDT) Received: from mail.geo-comm.com (geo-comm.com [66.173.42.242]) by core3.amsl.com (Postfix) with ESMTP id 5C1BC3A6973 for ; Mon, 15 Mar 2010 14:49:34 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Mar 2010 16:49:34 -0500 Message-ID: <909A20ADCD98AD4FB9984A87063A560503D81617@exchange.geo-comm.local> In-Reply-To: <201003151908.o2FJ8s48022210@sj-core-2.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Revved the Transformations URN ID Thread-Index: AcrEcwKZxjVAe4z2SMWNz3/PQ4QOagAFO08g References: <201003151908.o2FJ8s48022210@sj-core-2.cisco.com> From: "Avery Penniston" To: "James M. Polk" , "ECRIT" Subject: Re: [Ecrit] Revved the Transformations URN ID 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, 15 Mar 2010 21:49:35 -0000 When you ask the LoST server to transform a civic into a geo or vice versa, it seems that you are trying to make a LoST server into a geocoding/reverse-geocoding server - I'm not sure how much I like that idea, or how much advantage you get by using a LoST server to obtain the URI of such a service. I tend to agree with Brian, that it is better to separate concerns by creating a distinct web service for geocoding/reverse-geocoding. =20 Also, I believe your definitions of 'geocoding' and 'reverse geocoding' are opposite what they should be - 'geocoding' is converting civic to geodetic, and 'reverse geocoding' is converting geodetic to civic. Avery > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of James M. Polk > Sent: Monday, March 15, 2010 2:09 PM > To: 'ECRIT' > Subject: [Ecrit] Revved the Transformations URN ID >=20 > ECRIT >=20 > re: > http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost- > transformations-urn-01.txt >=20 > This version is much more complete (only lacking the LoST examples). >=20 > There only sticking point is whether LoST should be used by a client > to get this information - or if a pure HTTP transaction should be > used to geocode/reverse-geocode. >=20 > I believe it is fairly logical for a URN to identify the service of > "format transformation". >=20 > I believe a client will not generally know which server to ask for > this information -- without that server being a "Google Maps"-style > well-known URL. With that in mind, it appears fairly obvious that > LoST can be used, with a well known URN (denoting the service > desired) to ask a LoST server for this information (when geocoding is > involved), or be pointed to an appropriate URI that can do this > transformation. >=20 > This ID offers both options, with the LoST server deciding whether or > not it will fulfill the transformation (when location transformation > is the URN). If the LoST server wishes to return the transformed > location, a single transaction is all that's needed by the client - > increasing the user experience. If the LoST server can't or does not > want to return the transformed location information, it returns the > URI for that (URN) service, as is the case with most (all?) other > LoST transactions. >=20 > Comments and questions are appreciated >=20 > James >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Mon Mar 15 16:22:36 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2BE3A67D8 for ; Mon, 15 Mar 2010 16:22: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=[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 CKbdJJ0RN5Gw for ; Mon, 15 Mar 2010 16:22:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id E0A9A3A6A10 for ; Mon, 15 Mar 2010 16:21:55 -0700 (PDT) Received: from [128.89.253.157] (helo=[10.0.0.16]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NrJbl-000OpQ-M7; Mon, 15 Mar 2010 19:22:02 -0400 Message-Id: From: Richard Barnes To: Brian Rosen In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 16 Mar 2010 00:21:59 +0100 References: X-Mailer: Apple Mail (2.936) Cc: 'ECRIT' Subject: Re: [Ecrit] Revved the Transformations URN ID 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, 15 Mar 2010 23:22:36 -0000 Brian, I thought you were the one that mentioned the idea of additional transformations in ... Stockholm? IMO, there's some merit in this draft, in that you could imagine geocoding services advertising their coverage areas in LoST. (I have no idea whether anyone actually wants to do this, e.g., in the NG9-1-1 context.) This draft is significantly improved over the previous version in that it uses LoST in the more appropriate role -- discovery of geocoding services rather than the geocoding services themselves. Going forward, I would suggest that this draft merge with draft-george- geopriv-address-translation to form a solution in two steps: 1. Use LoST to discover a geocoding server (if necessary) 2. Use HELD to query for geocoded result --Richard On Mar 15, 2010, at 9:29 PM, Brian Rosen wrote: > Personally, I don't see the URN as having any real value. > > I think all we need is a simple web service: send in a PIDF, get one > back. > If you send a geo, you get a civic and vice versa. If you insist, > have two > services: geocode and reverse-geocode. > > Why would we want to be more complicated then that? Specifically, > why would > we want to invent a URN to tell us what transformation we want? > > Brian > > > On 3/15/10 2:08 PM, "James Polk" wrote: > >> ECRIT >> >> re: >> http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-transformations-urn- >> 01.txt >> >> This version is much more complete (only lacking the LoST examples). >> >> There only sticking point is whether LoST should be used by a client >> to get this information - or if a pure HTTP transaction should be >> used to geocode/reverse-geocode. >> >> I believe it is fairly logical for a URN to identify the service of >> "format transformation". >> >> I believe a client will not generally know which server to ask for >> this information -- without that server being a "Google Maps"-style >> well-known URL. With that in mind, it appears fairly obvious that >> LoST can be used, with a well known URN (denoting the service >> desired) to ask a LoST server for this information (when geocoding is >> involved), or be pointed to an appropriate URI that can do this >> transformation. >> >> This ID offers both options, with the LoST server deciding whether or >> not it will fulfill the transformation (when location transformation >> is the URN). If the LoST server wishes to return the transformed >> location, a single transaction is all that's needed by the client - >> increasing the user experience. If the LoST server can't or does not >> want to return the transformed location information, it returns the >> URI for that (URN) service, as is the case with most (all?) other >> LoST transactions. >> >> Comments and questions are appreciated >> >> James >> >> _______________________________________________ >> 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 jmpolk@cisco.com Mon Mar 15 21:36:57 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 1089C3A68BA for ; Mon, 15 Mar 2010 21:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.533 X-Spam-Level: X-Spam-Status: No, score=-10.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8VgaqNJfNHN for ; Mon, 15 Mar 2010 21:36:56 -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 04DBC3A68A9 for ; Mon, 15 Mar 2010 21:36:52 -0700 (PDT) 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: AvsEAAeonkurRN+K/2dsb2JhbACabnOgb5hLgk4HgiYEgxqLYA X-IronPort-AV: E=Sophos;i="4.49,648,1262563200"; d="scan'208";a="497180773" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 16 Mar 2010 04:37:00 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o2G4ax3e006451; Tue, 16 Mar 2010 04:36:59 GMT Message-Id: <201003160436.o2G4ax3e006451@sj-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 15 Mar 2010 23:36:58 -0500 To: Richard Barnes , Brian Rosen From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: 'ECRIT' Subject: Re: [Ecrit] Revved the Transformations URN ID 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, 16 Mar 2010 04:36:57 -0000 Richard Thanks for reviewing the doc. To affirm, it was Brian that strongly suggested that I expand this URN from "geocoding" to "transformations", with geocoding and reverse-geocoding as sub-services. Of your 2 steps, this ID specifies doing #1, if the LoST server doesn't want or cannot do the geocoding itself. I leave that as an option - which is based on Andy Newton's offering in Stockholm that the LoST server _could_ have both location formats for a particular location, and satisfy the goal in a single transaction. About step #2 below, I do talk about this in the current use of LoST (to learn the URI of the service at or near the given PIDF-LO location) - but I do not specify the use of HELD at this time, and leave it generically to "another transaction", inferring HTTP. HELD could very well be that second transaction's protocol. I was waiting for feedback before going down that path. I'm not opposed to merging this ID with the draft-george-geopriv-address-translation ID. You, as chair of both WGs (once we get to Anaheim), should likely provide the guidance as to which WG this merged ID goes into. James At 06:21 PM 3/15/2010, Richard Barnes wrote: >Brian, > >I thought you were the one that mentioned the idea of additional >transformations in ... Stockholm? > >IMO, there's some merit in this draft, in that you could imagine >geocoding services advertising their coverage areas in LoST. (I have >no idea whether anyone actually wants to do this, e.g., in the NG9-1-1 >context.) > >This draft is significantly improved over the previous version in that >it uses LoST in the more appropriate role -- discovery of geocoding >services rather than the geocoding services themselves. Going >forward, I would suggest that this draft merge with draft-george- >geopriv-address-translation to form a solution in two steps: >1. Use LoST to discover a geocoding server (if necessary) >2. Use HELD to query for geocoded result > >--Richard > > > >On Mar 15, 2010, at 9:29 PM, Brian Rosen wrote: > >>Personally, I don't see the URN as having any real value. >> >>I think all we need is a simple web service: send in a PIDF, get one >>back. >>If you send a geo, you get a civic and vice versa. If you insist, >>have two >>services: geocode and reverse-geocode. >> >>Why would we want to be more complicated then that? Specifically, >>why would >>we want to invent a URN to tell us what transformation we want? >> >>Brian >> >> >>On 3/15/10 2:08 PM, "James Polk" wrote: >> >>>ECRIT >>> >>>re: >>>http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-transformations-urn- >>>01.txt >>> >>>This version is much more complete (only lacking the LoST examples). >>> >>>There only sticking point is whether LoST should be used by a client >>>to get this information - or if a pure HTTP transaction should be >>>used to geocode/reverse-geocode. >>> >>>I believe it is fairly logical for a URN to identify the service of >>>"format transformation". >>> >>>I believe a client will not generally know which server to ask for >>>this information -- without that server being a "Google Maps"-style >>>well-known URL. With that in mind, it appears fairly obvious that >>>LoST can be used, with a well known URN (denoting the service >>>desired) to ask a LoST server for this information (when geocoding is >>>involved), or be pointed to an appropriate URI that can do this >>>transformation. >>> >>>This ID offers both options, with the LoST server deciding whether or >>>not it will fulfill the transformation (when location transformation >>>is the URN). If the LoST server wishes to return the transformed >>>location, a single transaction is all that's needed by the client - >>>increasing the user experience. If the LoST server can't or does not >>>want to return the transformed location information, it returns the >>>URI for that (URN) service, as is the case with most (all?) other >>>LoST transactions. >>> >>>Comments and questions are appreciated >>> >>>James >>> >>>_______________________________________________ >>>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 rbarnes@bbn.com Mon Mar 15 23:44:18 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 755B73A68F0 for ; Mon, 15 Mar 2010 23:44:18 -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 PmE2fZUS624S for ; Mon, 15 Mar 2010 23:44:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 7AA353A68E7 for ; Mon, 15 Mar 2010 23:44:17 -0700 (PDT) Received: from [128.89.253.210] (helo=[10.0.0.16]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NrQVs-000GpK-CT; Tue, 16 Mar 2010 02:44:24 -0400 Message-Id: From: Richard Barnes To: "James M. Polk" In-Reply-To: <201003160436.o2G4ax3e006451@sj-core-4.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 16 Mar 2010 07:44:22 +0100 References: <201003160436.o2G4ax3e006451@sj-core-4.cisco.com> X-Mailer: Apple Mail (2.936) Cc: 'ECRIT' Subject: Re: [Ecrit] Revved the Transformations URN ID 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, 16 Mar 2010 06:44:18 -0000 Yeah, I thought about suggesting that this go to GEOPRIV, but I don't think it matters much one way or another. --Richard On Mar 16, 2010, at 5:36 AM, James M. Polk wrote: > Richard > > Thanks for reviewing the doc. > > To affirm, it was Brian that strongly suggested that I expand this > URN from "geocoding" to "transformations", with geocoding and > reverse-geocoding as sub-services. > > Of your 2 steps, this ID specifies doing #1, if the LoST server > doesn't want or cannot do the geocoding itself. I leave that as an > option - which is based on Andy Newton's offering in Stockholm that > the LoST server _could_ have both location formats for a particular > location, and satisfy the goal in a single transaction. > > About step #2 below, I do talk about this in the current use of LoST > (to learn the URI of the service at or near the given PIDF-LO > location) - but I do not specify the use of HELD at this time, and > leave it generically to "another transaction", inferring HTTP. HELD > could very well be that second transaction's protocol. I was waiting > for feedback before going down that path. > > I'm not opposed to merging this ID with the draft-george-geopriv- > address-translation ID. You, as chair of both WGs (once we get to > Anaheim), should likely provide the guidance as to which WG this > merged ID goes into. > > James > > At 06:21 PM 3/15/2010, Richard Barnes wrote: >> Brian, >> >> I thought you were the one that mentioned the idea of additional >> transformations in ... Stockholm? >> >> IMO, there's some merit in this draft, in that you could imagine >> geocoding services advertising their coverage areas in LoST. (I have >> no idea whether anyone actually wants to do this, e.g., in the >> NG9-1-1 >> context.) >> >> This draft is significantly improved over the previous version in >> that >> it uses LoST in the more appropriate role -- discovery of geocoding >> services rather than the geocoding services themselves. Going >> forward, I would suggest that this draft merge with draft-george- >> geopriv-address-translation to form a solution in two steps: >> 1. Use LoST to discover a geocoding server (if necessary) >> 2. Use HELD to query for geocoded result >> >> --Richard >> >> >> >> On Mar 15, 2010, at 9:29 PM, Brian Rosen wrote: >> >>> Personally, I don't see the URN as having any real value. >>> >>> I think all we need is a simple web service: send in a PIDF, get one >>> back. >>> If you send a geo, you get a civic and vice versa. If you insist, >>> have two >>> services: geocode and reverse-geocode. >>> >>> Why would we want to be more complicated then that? Specifically, >>> why would >>> we want to invent a URN to tell us what transformation we want? >>> >>> Brian >>> >>> >>> On 3/15/10 2:08 PM, "James Polk" wrote: >>> >>>> ECRIT >>>> >>>> re: >>>> http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-transformations-urn- >>>> 01.txt >>>> >>>> This version is much more complete (only lacking the LoST >>>> examples). >>>> >>>> There only sticking point is whether LoST should be used by a >>>> client >>>> to get this information - or if a pure HTTP transaction should be >>>> used to geocode/reverse-geocode. >>>> >>>> I believe it is fairly logical for a URN to identify the service of >>>> "format transformation". >>>> >>>> I believe a client will not generally know which server to ask for >>>> this information -- without that server being a "Google Maps"-style >>>> well-known URL. With that in mind, it appears fairly obvious that >>>> LoST can be used, with a well known URN (denoting the service >>>> desired) to ask a LoST server for this information (when >>>> geocoding is >>>> involved), or be pointed to an appropriate URI that can do this >>>> transformation. >>>> >>>> This ID offers both options, with the LoST server deciding >>>> whether or >>>> not it will fulfill the transformation (when location >>>> transformation >>>> is the URN). If the LoST server wishes to return the transformed >>>> location, a single transaction is all that's needed by the client - >>>> increasing the user experience. If the LoST server can't or does >>>> not >>>> want to return the transformed location information, it returns the >>>> URI for that (URN) service, as is the case with most (all?) other >>>> LoST transactions. >>>> >>>> Comments and questions are appreciated >>>> >>>> James >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit > From robinsg@huawei.com Tue Mar 16 00:30:40 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 D2E153A6928 for ; Tue, 16 Mar 2010 00:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 uNI8MowLooAP for ; Tue, 16 Mar 2010 00:30:40 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id F36E33A6920 for ; Tue, 16 Mar 2010 00:30:39 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZD002BD66Z92@szxga02-in.huawei.com> for ecrit@ietf.org; Tue, 16 Mar 2010 15:30:35 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZD006UF66ZAB@szxga02-in.huawei.com> for ecrit@ietf.org; Tue, 16 Mar 2010 15:30:35 +0800 (CST) Received: from [10.85.202.237] by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZD0061366YT5@szxml04-in.huawei.com> for ecrit@ietf.org; Tue, 16 Mar 2010 15:30:35 +0800 (CST) Date: Tue, 16 Mar 2010 15:30:34 +0800 From: Robins George In-reply-to: <201003160436.o2G4ax3e006451@sj-core-4.cisco.com> To: "James M. Polk" Message-id: <4B9F339A.9000707@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 References: <201003160436.o2G4ax3e006451@sj-core-4.cisco.com> Cc: 'ECRIT' Subject: Re: [Ecrit] Revved the Transformations URN ID X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robinsg@huawei.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 07:30:40 -0000 > I'm not opposed to merging this ID with the > draft-george-geopriv-address-translation ID. You, as chair of both > WGs (once we get to Anaheim), should likely provide the guidance as to > which WG this merged ID goes into. > I'm happy to merge this draft with the draft-george-geopriv-address-translation. - robins From rjsparks@nostrum.com Fri Mar 12 07:57:04 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB1CC3A6CDC; Fri, 12 Mar 2010 07:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-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 TrFHdFbCiPb7; Fri, 12 Mar 2010 07:57:04 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 582AF3A6A2B; Fri, 12 Mar 2010 07:42:54 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2CFgwJw013316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Mar 2010 09:42:58 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: Date: Fri, 12 Mar 2010 09:42:58 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <204C0846-1479-4795-88F2-903A4BDD5837@cisco.com> To: siprec@ietf.org, SIPCORE , codec@ietf.org, DISPATCH list , ecrit@ietf.org, XMPP , rai@ietf.org X-Mailer: Apple Mail (2.1077) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Tue, 16 Mar 2010 08:52:43 -0700 Subject: [Ecrit] RAI WG chair changes X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rai@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 15:57:04 -0000 WIth the upcoming IESG and IAB changes, we need to make=20 a bunch of chair changes. After the end of the IETF 77 the chairs=20 for the following WGs will be: SIPREC=20 Brian Rosen John Elwell SIPCORE Adam Roach Paul Kyzivat CODEC Michael Knappe Jonathan Rosenberg Cullen Jennings DISPATCH Mary Barnes Cullen Jennings ECRIT=20 Richard Barnes Marc Linsner XMPP Joe Hildebrand Ben Campbell To help with continuity of the IETF77 meeting, we are going to add the = new chairs now,=20 and not remove any existing chairs until after the meeting.=20 We would like to express many thinks for all the work all these chairs = have done and continue to do.=20 Thanks,=20 Cullen, Gonzalo, & Robert From hannes.tschofenig@nsn.com Tue Mar 16 09:24:23 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 92E0E3A6B95 for ; Tue, 16 Mar 2010 09:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=-1.134, BAYES_40=-0.185] 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 ZToCCgWlwGk4 for ; Tue, 16 Mar 2010 09:24:22 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 4D8E93A67A1 for ; Tue, 16 Mar 2010 09:24:22 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2GGOSFZ001056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 16 Mar 2010 17:24:28 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2GGOSTL013555 for ; Tue, 16 Mar 2010 17:24:28 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 17:24:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Mar 2010 18:23:58 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450255EB9F@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RAI WG chair changes Thread-Index: AcrFIL8dbOF5VCE2QEqp19gpGhhouwAAPgLg References: <204C0846-1479-4795-88F2-903A4BDD5837@cisco.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 16 Mar 2010 16:24:28.0300 (UTC) FILETIME=[2672CCC0:01CAC525] Subject: Re: [Ecrit] RAI WG chair changes 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, 16 Mar 2010 16:24:23 -0000 Hi ECRIT members,=20 I would like to thank all of you for the good work you have done over the last few years. When Jon and I organized the BOF in 2004 (November IETF meeting) we did not anticipate that so many organizations would be working on the emergency services topic. Very soon afterwards the working group was formed and Marc and I got selected as chairs. When Marc and I realized the complex ecosystem we organized the first emergency services workshop in October 2006 (hosted by Henning at Columbia University) to coordinate the work with other organizations. More workshops followed and we managed to get a very good understanding of the players in that field.=20 Over the years we got a lot of work done in the ECRIT group and the coordination with various SDOs is still ongoing and we have developed close relationships over time.=20 I am happy that the ADs have been able to recruit Richard. Richard is based on his involvement in ECRIT in the past and his position in the GEOPRIV working group in a very good position to move the work forward.=20 Although my step to discontinue my co-chair position together with Marc was difficult for me I believe it is a good time to get others involved. With my new role as an IAB member I will have to re-schedule my activities to fulfill the new expectations.=20 Finally, I would really like to thank Marc and Roger for the fruitful work in the group and also Cullen, Robert and Jon (as ADs) for their support.=20 Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of ext Robert Sparks >Sent: 12 March, 2010 10:43 >To: siprec@ietf.org; SIPCORE; codec@ietf.org; DISPATCH list;=20 >ecrit@ietf.org; XMPP; rai@ietf.org >Subject: [Ecrit] RAI WG chair changes > >WIth the upcoming IESG and IAB changes, we need to make a=20 >bunch of chair changes. After the end of the IETF 77 the=20 >chairs for the following WGs will be: > >SIPREC >Brian Rosen >John Elwell > >SIPCORE >Adam Roach >Paul Kyzivat > >CODEC >Michael Knappe >Jonathan Rosenberg >Cullen Jennings > >DISPATCH >Mary Barnes >Cullen Jennings > >ECRIT >Richard Barnes >Marc Linsner > >XMPP >Joe Hildebrand >Ben Campbell > >To help with continuity of the IETF77 meeting, we are going to=20 >add the new chairs now, and not remove any existing chairs=20 >until after the meeting.=20 > >We would like to express many thinks for all the work all=20 >these chairs have done and continue to do.=20 > >Thanks, >Cullen, Gonzalo, & Robert > > > > > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > From hannes.tschofenig@nsn.com Tue Mar 16 09:29:56 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 22F783A6B7C for ; Tue, 16 Mar 2010 09:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5DvAdGrEOYC for ; Tue, 16 Mar 2010 09:29:54 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 340663A6BC8 for ; Tue, 16 Mar 2010 09:29:51 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2GGTll1008188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Mar 2010 17:29:47 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2GGTkd8030054; Tue, 16 Mar 2010 17:29:46 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 17:29:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAC525.E3BAA375" Date: Tue, 16 Mar 2010 18:29:16 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450255EBA6@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Ecrit] ECRIT Agenda Version 3 Thread-Index: AcrFJdI4HP6iOQKoTyiPsVP3yH77fw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: , X-OriginalArrivalTime: 16 Mar 2010 16:29:46.0373 (UTC) FILETIME=[E408E350:01CAC525] Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Agenda Version 3 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, 16 Mar 2010 16:29:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC525.E3BAA375 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --- I let the new chairs figure out how to arrange the items properly = but since I had written the mail already find my response below.=20 Let us take a look at the list of WG items we have:=20 Best Current Practice for Communications Services in support of = Emergency Calling = (107967 bytes) Framework for Emergency Calling using Internet Multimedia = (96432 bytes) --> Brian says he does not need time for the two items above.=20 Location Hiding: Problem Statement and Requirements = = (20127 bytes) --> This document does not seem to require time. At least from the IESG = review feedback I have not seen anything dramatic.=20 Specifying Holes in LoST Service Boundaries = (22007 = bytes) There were a punch of review comments but Martin did not send us a = request for a presentation. I assume that he feels comfortable = addressing the comments. Is this correct, Martin?=20 Synchronizing Location-to-Service Translation (LoST) Protocol based = Service Boundaries and Mapping Elements = (50425 bytes) The comments on the list by Alex got addressed and I shipped a new = version. I don't believe it would make sense to discuss the comment = again. IANA Registering a SIP Resource Priority Header Field Namespace for = Local Emergency Communications = (19327 bytes) Marc is responsible for this work and I have not received a request for = a presentation slot. LoST Service List Boundary Extension = = (26226 bytes) Using Imprecise Location for Emergency Context Resolution = (39455 bytes) My understanding of the two documents from above is that they are = essentially done; we are only waiting for the feedback from the APPS = directorate on the Relax NG schema.=20 Ciao Hannes Brian Rosen wrote:=20 I don't see any issues with -phonebcp and -framework that would need = meeting time.=20 =09 Brian =09 =09 On 3/12/10 6:09 PM, "Cullen Jennings" wrote: =09 This is a lot of things to fit in 2.5 hours. It's possible that if I = saw how much time each had it would all look find but I'm very worried about = just starting new work and not finishing things. I want to be sure there is = no time required for any of the current WG items. =09 Cullen =09 =09 On Mar 5, 2010, at 2:32 AM, Hannes Tschofenig wrote: =09 ECRIT Meeting Agenda (Version 3) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =09 MONDAY, March 22, 2010 0900-1130 Morning Session I Room: Palos Verdes =09 * Agenda Bashing and Status Update (Marc, Hannes, Roger) =09 * PSAP Callback (TBD) http://trac.tools.ietf.org/wg/ecrit/trac/wiki http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback =09 Intention: Discuss potential feedback from emergency services groups = on the requirements for this work. =09 * Unauthenticated emergency services (Dirk) = http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access =09 Intention: Determine next steps. The group wants to work on it but = there are still lots of open issues and re-chartering is required to add it = to the milestone list. * Transformations ID (James P.) http://tools.ietf.org/id/draft-polk-ecrit-lost-transformations-urn =09 Intention: TBD. =09 * ECRIT Direct (James W.) http://tools.ietf.org/id/draft-winterbottom-ecrit-direct =09 Intention: TBD.=20 * Additional Data (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-additional-data =09 Intention: Initial document version. Presentation of the history and = the origin of the work. Determine interest. =09 * Data Only Emergency Calls (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-data-only-ea =09 Intention: TBD. =09 * Completing the Request Location (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-completed-location-00.txt =09 Intention: Discussion whether the group should work on this document. = The document is making a normative change to RFC 5222. =09 * Service URN Update and Service Classification (Henning) http://tools.ietf.org/id/draft-forte-ecrit-service-classification http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy Intention: Documents are a bit stuck although group agreed to work on it. Henning will present a way forward. * Emergency Text Messaging using SIP MESSAGE (Henning) http://tools.ietf.org/id/draft-kim-ecrit-text-00.txt =09 Intention: Discussion about what the group should do in this area. =09 * Describing Boundaries for Civic Addresse http://tools.ietf.org/id/draft-thomson-ecrit-civic-boundary-00.txt =09 Intention: Discussion whether the group should work on this doc. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =09 =09 =09 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01CAC525.E3BAA375 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] ECRIT Agenda Version 3

--- I let the new chairs figure out how to = arrange the items properly but since I had written the mail already find = my response below.

Let us take a look at the list of WG items we = have:

Best Current Practice for = Communications Services in support of Emergency Calling = (107967 bytes)
Framework for Emergency Calling using = Internet Multimedia (96432 = bytes)

=A0--> Brian says he does not need time for the two items above.

Location Hiding: Problem = Statement and Requirements (20127 = bytes)

=A0--> This document does not seem to require time. At least from the = IESG review feedback I have not seen anything dramatic.

= Specifying Holes in LoST = Service Boundaries (22007 bytes)

There were a punch of review comments but Martin did not send us a = request for a presentation. I assume that he feels comfortable = addressing the comments. Is this correct, Martin?

Synchronizing Location-to-Service = Translation (LoST) Protocol based Service Boundaries and Mapping = Elements (50425 bytes)

The comments on the list by Alex got addressed and I shipped a new = version. I don't believe it would make sense to discuss the comment = again.

IANA Registering = a SIP Resource Priority Header Field Namespace for Local Emergency = Communications (19327 bytes)

Marc is responsible for this work and I have not received a request for = a presentation slot.

LoST Service List = Boundary Extension (26226 bytes)
Using Imprecise Location for = Emergency Context Resolution (39455 = bytes)

My understanding of the two documents from above is that they are = essentially done; we are only waiting for the feedback from the APPS = directorate on the Relax NG schema.

Ciao
Hannes

Brian Rosen wrote:

------_=_NextPart_001_01CAC525.E3BAA375-- From James.Winterbottom@andrew.com Tue Mar 16 09:37: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 D72753A6BFD for ; Tue, 16 Mar 2010 09:37:55 -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 v18MXr5pr7tY for ; Tue, 16 Mar 2010 09:37:47 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 38A953A6BCF for ; Tue, 16 Mar 2010 09:37:47 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:63707 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S187335Ab0CPQhz (ORCPT ); Tue, 16 Mar 2010 11:37:55 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 16 Mar 2010 11:37:55 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 17 Mar 2010 00:37:52 +0800 From: "Winterbottom, James" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "br@brianrosen.net" , "fluffy@cisco.com" Date: Wed, 17 Mar 2010 00:37:50 +0800 Thread-Topic: Re: [Ecrit] ECRIT Agenda Version 3 Thread-Index: AcrFJdI4HP6iOQKoTyiPsVP3yH77fwAARI5A Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120DDCE601A@SISPE7MB1.commscope.com> References: <3D3C75174CB95F42AD6BCC56E5555B450255EBA6@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450255EBA6@FIESEXC015.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC81880120DDCE601ASISPE7MB1co_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ECRIT Agenda Version 3 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, 16 Mar 2010 16:37:55 -0000 --_000_5A55A45AE77F5941B18E5457ECAC81880120DDCE601ASISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does this mean that none of the "intention" documents listed in the previou= s agendas have made the cut? Cheers James ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of T= schofenig, Hannes (NSN - FI/Espoo) Sent: Wednesday, 17 March 2010 3:29 AM To: br@brianrosen.net; fluffy@cisco.com Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Agenda Version 3 --- I let the new chairs figure out how to arrange the items properly but s= ince I had written the mail already find my response below. Let us take a look at the list of WG items we have: Best Current Practice for Communications Services in support of Emergency C= alling (107967 byt= es) Framework for Emergency Calling using Internet Multimedia (96432 bytes) --> Brian says he does not need time for the two items above. Location Hiding: Problem Statement and Requirements (20127 bytes) --> This document does not seem to require time. At least from the IESG re= view feedback I have not seen anything dramatic. Specifying Holes in LoST Service Boundaries (22007 bytes) There were a punch of review comments but Martin did not send us a request = for a presentation. I assume that he feels comfortable addressing the comme= nts. Is this correct, Martin? Synchronizing Location-to-Service Translation (LoST) Protocol based Service= Boundaries and Mapping Elements (50425 bytes) The comments on the list by Alex got addressed and I shipped a new version.= I don't believe it would make sense to discuss the comment again. IANA Registering a SIP Resource Priority Header Field Namespace for Local E= mergency Communications (19327 bytes) Marc is responsible for this work and I have not received a request for a p= resentation slot. LoST Service List Boundary Extension (26226 bytes) Using Imprecise Location for Emergency Context Resolution (39455 bytes) My understanding of the two documents from above is that they are essential= ly done; we are only waiting for the feedback from the APPS directorate on = the Relax NG schema. Ciao Hannes Brian Rosen wrote: I don't see any issues with -phonebcp and -framework that would need meetin= g time. Brian On 3/12/10 6:09 PM, "Cullen Jennings" wrote: This is a lot of things to fit in 2.5 hours. It's possible that if I saw ho= w much time each had it would all look find but I'm very worried about just starting new work and not finishing things. I want to be sure there is no t= ime required for any of the current WG items. Cullen On Mar 5, 2010, at 2:32 AM, Hannes Tschofenig wrote: ECRIT Meeting Agenda (Version 3) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D MONDAY, March 22, 2010 0900-1130 Morning Session I Room: Palos Verdes * Agenda Bashing and Status Update (Marc, Hannes, Roger) * PSAP Callback (TBD) http://trac.tools.ietf.org/wg/ecrit/trac/wiki http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback Intention: Discuss potential feedback from emergency services groups on the requirements for this work. * Unauthenticated emergency services (Dirk) http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access Intention: Determine next steps. The group wants to work on it but there are still lots of open issues and re-chartering is required to add it to the milestone list. * Transformations ID (James P.) http://tools.ietf.org/id/draft-polk-ecrit-lost-transformations-urn Intention: TBD. * ECRIT Direct (James W.) http://tools.ietf.org/id/draft-winterbottom-ecrit-direct Intention: TBD. * Additional Data (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-additional-data Intention: Initial document version. Presentation of the history and the origin of the work. Determine interest. * Data Only Emergency Calls (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-data-only-ea Intention: TBD. * Completing the Request Location (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-completed-location-00.txt Intention: Discussion whether the group should work on this document. The document is making a normative change to RFC 5222. * Service URN Update and Service Classification (Henning) http://tools.ietf.org/id/draft-forte-ecrit-service-classification http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy Intention: Documents are a bit stuck although group agreed to work on it. Henning will present a way forward. * Emergency Text Messaging using SIP MESSAGE (Henning) http://tools.ietf.org/id/draft-kim-ecrit-text-00.txt Intention: Discussion about what the group should do in this area. * Describing Boundaries for Civic Addresse http://tools.ietf.org/id/draft-thomson-ecrit-civic-boundary-00.txt Intention: Discussion whether the group should work on this doc. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_5A55A45AE77F5941B18E5457ECAC81880120DDCE601ASISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] ECRIT Agenda Version 3

Does this mean that none of the “= ;intention” documents listed in the previous agendas have made the cut?

 

Cheers

James

 

<= span style=3D'font-size:12.0pt;color:navy'> 

From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN = - FI/Espoo)
Sent: Wednesday, 17 March 20= 10 3:29 AM
To: br@brianrosen.net; fluffy@cisco.com
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] ECRIT A= genda Version 3

 

--- I let the new chairs figure out how to arrange the items properly but since= I had written the mail already find my response below.

Let us take a look at the list of WG items we have:

Best Current Practice for Communications Services in support of Emergency Calling <= font face=3DArial>(107967 bytes)
Framework for Emergency Call= ing using Internet Multimedia (96432 bytes)

 --> Brian says he does not need time for the two items above.

Location Hiding: Problem Sta= tement and Requirements (20127 bytes)

 --> This document does not seem to require time. At least from the IESG review feedback I have not seen anything dramatic.

Specifying Holes in LoST Ser= vice Boundaries (22007 bytes)

There were a punch of review comments but Martin did not send us a request = for a presentation. I assume that he feels comfortable addressing the comments.= Is this correct, Martin?

Synchronizing Location-to-Se= rvice Translation (LoST) Protocol based Service Boundaries and Mapping Elements (50425 bytes)

The comments on the list by Alex got addressed and I shipped a new version.= I don't believe it would make sense to discuss the comment again.

IANA Registering a SIP Resou= rce Priority Header Field Namespace for Local Emergency Communications (19327 bytes)

Marc is responsible for this work and I have not received a request for a presentation slot.

LoST Service List Boundary E= xtension (26226 bytes)
Using Imprecise Location for Emergency Context Resolution (39455 bytes)

My understanding of the two documents from above is that they are essential= ly done; we are only waiting for the feedback from the APPS directorate on the Relax NG schema.

Ciao
Hannes

Brian Rosen wrote:

I don't see any issues= with -phonebcp and -framework that would need meeting
time.

Brian


On 3/12/10 6:09 PM, "Cullen Jennings" <fluffy@cisco.com> wr= ote:

This is a lot of thing= s to fit in 2.5 hours. It's possible that if I saw how
much time each had it would all look find but I'm very worried about just starting new work and not finishing things. I want to be sure there is no t= ime
required for any of the current WG items.

Cullen


On Mar 5, 2010, at 2:32 AM, Hannes Tschofenig wrote:

ECRIT Meeting Agenda (Version 3)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

MONDAY, March 22, 2010
0900-1130 Morning Session I
Room: Palos Verdes

* Agenda Bashing and Status Update (Marc, Hannes, Roger)

* PSAP Callback (TBD)
http://trac.tools.ietf.org/wg/ecrit/trac/wiki
= http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callbac= k

Intention: Discuss potential feedback from emergency services groups on
the requirements for this work.

* Unauthenticated emergency services (Dirk)
http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthentica= ted-access

Intention: Determine next steps. The group wants to work on it but there
are still lots of open issues and re-chartering is required to add it to the milestone list.
* Transformations ID (James P.)
http://tools.ietf.org/id/draft-polk-ecrit-lost-transformation= s-urn

Intention: TBD.

* ECRIT Direct (James W.)
http://tools.ietf.org/id/draft-winterbottom-ecrit-direct

Intention: TBD.
* Additional Data (Brian)
http://tools.ietf.org/id/draft-rosen-ecrit-additional-data

Intention: Initial document version. Presentation of the history and the
origin of the work. Determine interest.

* Data Only Emergency Calls (Brian)
http://tools.ietf.org/id/draft-rosen-ecrit-data-only-ea

Intention: TBD.

* Completing the Request Location (Brian)
http://tools.ietf.org/id/draft-rosen-ecrit-completed-location= -00.txt

Intention: Discussion whether the group should work on this document. The
document is making a normative change to RFC 5222.

* Service URN Update and Service Classification (Henning)
= http://tools.ietf.org/id/draft-forte-ecrit-service-classifica= tion
http://tools.ietf.org/html/draft-forte-ecrit-service-urn-poli= cy
Intention: Documents are a bit stuck although group agreed to work on
it. Henning will present a way forward.
* Emergency Text Messaging using SIP MESSAGE (Henning)
http://tools.ietf.org/id/draft-kim-ecrit-text-00.txt

Intention: Discussion about what the group should do in this area.

* Describing Boundaries for Civic Addresse
http://tools.ietf.org/id/draft-thomson-ecrit-civic-boundary-0= 0.txt

Intention: Discussion whether the group should work on this doc.
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

 =

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index= .html



_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit




--_000_5A55A45AE77F5941B18E5457ECAC81880120DDCE601ASISPE7MB1co_-- From hannes.tschofenig@nsn.com Tue Mar 16 09:41:32 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 D11403A6C17 for ; Tue, 16 Mar 2010 09:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 k1Xh5PQscuts for ; Tue, 16 Mar 2010 09:41:23 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 7E4403A6A69 for ; Tue, 16 Mar 2010 09:41:22 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2GGe8NS027190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Mar 2010 17:40:08 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2GGe8IV032275; Tue, 16 Mar 2010 17:40:08 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 17:40:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAC527.56228FE9" Date: Tue, 16 Mar 2010 18:39:37 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450255EBBE@FIESEXC015.nsn-intra.net> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120DDCE601A@SISPE7MB1.commscope.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Ecrit] ECRIT Agenda Version 3 Thread-Index: AcrFJdI4HP6iOQKoTyiPsVP3yH77fwAARI5AAAAMs3A= References: <3D3C75174CB95F42AD6BCC56E5555B450255EBA6@FIESEXC015.nsn-intra.net> <5A55A45AE77F5941B18E5457ECAC81880120DDCE601A@SISPE7MB1.commscope.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Winterbottom, James" , , X-OriginalArrivalTime: 16 Mar 2010 16:40:07.0685 (UTC) FILETIME=[565D9350:01CAC527] Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Agenda Version 3 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, 16 Mar 2010 16:41:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC527.56228FE9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This mail was just in response to Cullen's note about the existing work items. So, I went through the list to explain that they are doing fine.=20 =20 The previous agenda has not changed and Marc & Richard need to figure out how to arrange the time.=20 =20 Ciao Hannes ________________________________ From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 Sent: 16 March, 2010 12:38 To: Tschofenig, Hannes (NSN - FI/Espoo); br@brianrosen.net; fluffy@cisco.com Cc: ecrit@ietf.org Subject: RE: Re: [Ecrit] ECRIT Agenda Version 3 =09 =09 Does this mean that none of the "intention" documents listed in the previous agendas have made the cut? =20 Cheers James =20 =20 =09 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Wednesday, 17 March 2010 3:29 AM To: br@brianrosen.net; fluffy@cisco.com Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Agenda Version 3 =20 --- I let the new chairs figure out how to arrange the items properly but since I had written the mail already find my response below.=20 Let us take a look at the list of WG items we have: =09 Best Current Practice for Communications Services in support of Emergency Calling (107967 bytes) Framework for Emergency Calling using Internet Multimedia (96432 bytes) =09 --> Brian says he does not need time for the two items above. =09 Location Hiding: Problem Statement and Requirements (20127 bytes) =09 --> This document does not seem to require time. At least from the IESG review feedback I have not seen anything dramatic. =09 Specifying Holes in LoST Service Boundaries (22007 bytes) =09 There were a punch of review comments but Martin did not send us a request for a presentation. I assume that he feels comfortable addressing the comments. Is this correct, Martin? =09 Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements (50425 bytes) =09 The comments on the list by Alex got addressed and I shipped a new version. I don't believe it would make sense to discuss the comment again. =09 IANA Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications (19327 bytes) =09 Marc is responsible for this work and I have not received a request for a presentation slot. =09 LoST Service List Boundary Extension (26226 bytes) Using Imprecise Location for Emergency Context Resolution (39455 bytes) =09 My understanding of the two documents from above is that they are essentially done; we are only waiting for the feedback from the APPS directorate on the Relax NG schema. =09 Ciao Hannes =09 Brian Rosen wrote:=20 I don't see any issues with -phonebcp and -framework that would need meeting time. =09 Brian =09 =09 On 3/12/10 6:09 PM, "Cullen Jennings" wrote: This is a lot of things to fit in 2.5 hours. It's possible that if I saw how much time each had it would all look find but I'm very worried about just starting new work and not finishing things. I want to be sure there is no time required for any of the current WG items. =09 Cullen =09 =09 On Mar 5, 2010, at 2:32 AM, Hannes Tschofenig wrote: ECRIT Meeting Agenda (Version 3) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =09 MONDAY, March 22, 2010 0900-1130 Morning Session I Room: Palos Verdes =09 * Agenda Bashing and Status Update (Marc, Hannes, Roger) =09 * PSAP Callback (TBD) http://trac.tools.ietf.org/wg/ecrit/trac/wiki =20 http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback =20 =09 Intention: Discuss potential feedback from emergency services groups on the requirements for this work. =09 * Unauthenticated emergency services (Dirk) =09 http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access =20 =09 Intention: Determine next steps. The group wants to work on it but there are still lots of open issues and re-chartering is required to add it to the milestone list. * Transformations ID (James P.) =09 http://tools.ietf.org/id/draft-polk-ecrit-lost-transformations-urn =20 =09 Intention: TBD. =09 * ECRIT Direct (James W.) http://tools.ietf.org/id/draft-winterbottom-ecrit-direct =20 =09 Intention: TBD. * Additional Data (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-additional-data =20 =09 Intention: Initial document version. Presentation of the history and the origin of the work. Determine interest. =09 * Data Only Emergency Calls (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-data-only-ea =20 =09 Intention: TBD. =09 * Completing the Request Location (Brian) =09 http://tools.ietf.org/id/draft-rosen-ecrit-completed-location-00.txt =20 =09 Intention: Discussion whether the group should work on this document. The document is making a normative change to RFC 5222. =09 * Service URN Update and Service Classification (Henning) =09 http://tools.ietf.org/id/draft-forte-ecrit-service-classification =20 http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy =20 Intention: Documents are a bit stuck although group agreed to work on it. Henning will present a way forward. * Emergency Text Messaging using SIP MESSAGE (Henning) http://tools.ietf.org/id/draft-kim-ecrit-text-00.txt =20 =09 Intention: Discussion about what the group should do in this area. =09 * Describing Boundaries for Civic Addresse =09 http://tools.ietf.org/id/draft-thomson-ecrit-civic-boundary-00.txt =20 =09 Intention: Discussion whether the group should work on this doc. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit =20 =20 Cullen Jennings For corporate legal information go to: =09 http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 =09 =09 =09 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit =20 =09 =09 =09 =09 ------_=_NextPart_001_01CAC527.56228FE9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] = ECRIT Agenda Version 3
This mail was just in response to Cullen's note = about the=20 existing work items. So, I went through the list to explain that they = are doing=20 fine.
 
The previous agenda has not changed and Marc = & Richard=20 need to figure out how to arrange the time.
 
Ciao
Hannes

From: ext Winterbottom, James=20 [mailto:James.Winterbottom@andrew.com]
Sent: 16 March, 2010 = 12:38
To: Tschofenig, Hannes (NSN - FI/Espoo); = br@brianrosen.net;=20 fluffy@cisco.com
Cc: ecrit@ietf.org
Subject: RE: = Re:=20 [Ecrit] ECRIT Agenda Version 3

Does this = mean that=20 none of the “intention” documents listed in the previous = agendas have made the=20 cut?

 

Cheers

James

 

 

From: ecrit-bounces@ietf.org = [mailto:ecrit-bounces@ietf.org] On Behalf=20 Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Wednesday, 17 March 2010 = 3:29=20 AM
To: = br@brianrosen.net;=20 fluffy@cisco.com
Cc:=20 ecrit@ietf.org
Subject: Re: [Ecrit] ECRIT = Agenda Version=20 3

 

--- I let the new chairs = figure=20 out how to arrange the items properly but since I had written the mail = already=20 find my response below.

Let us take a look at = the list of=20 WG items we have:

Best Current Practice = for=20 Communications Services in support of Emergency = Calling=20 (107967=20 bytes)
Framework for = Emergency Calling=20 using Internet Multimedia (96432 bytes)

 --> Brian = says he=20 does not need time for the two items above.

Location Hiding: = Problem Statement=20 and Requirements (20127 bytes)

 --> This = document=20 does not seem to require time. At least from the IESG review feedback = I have=20 not seen anything dramatic.

= Specifying Holes in = LoST Service=20 Boundaries (22007 bytes)

There were a punch = of review=20 comments but Martin did not send us a request for a presentation. I = assume=20 that he feels comfortable addressing the comments. Is this correct,=20 Martin?

Synchronizing = Location-to-Service=20 Translation (LoST) Protocol based Service Boundaries and Mapping=20 Elements (50425 bytes)

The comments on the = list by=20 Alex got addressed and I shipped a new version. I don't believe it = would make=20 sense to discuss the comment again.

IANA Registering a SIP = Resource=20 Priority Header Field Namespace for Local Emergency=20 Communications (19327 bytes)

Marc is responsible = for this=20 work and I have not received a request for a presentation=20 slot.

LoST Service List = Boundary=20 Extension (26226 bytes)
Using Imprecise = Location for=20 Emergency Context Resolution (39455 bytes)

My understanding of = the two=20 documents from above is that they are essentially done; we are only = waiting=20 for the feedback from the APPS directorate on the Relax NG=20 schema.

Ciao
Hannes

Brian = Rosen wrote:

I don't see any = issues=20 with -phonebcp and -framework that would need=20 meeting
time.

Brian


On 3/12/10 6:09 PM, "Cullen = Jennings"=20 <fluffy@cisco.com> wrote:

This is a lot of = things to=20 fit in 2.5 hours. It's possible that if I saw how
much time each = had it=20 would all look find but I'm very worried about just
starting new = work and=20 not finishing things. I want to be sure there is no time
required = for any=20 of the current WG items.

Cullen


On Mar 5, 2010, at = 2:32 AM,=20 Hannes Tschofenig=20 wrote:

ECRIT Meeting = Agenda=20 (Version = 3)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

MONDAY, March 22,=20 2010
0900-1130 Morning Session I
Room: Palos Verdes

* = Agenda=20 Bashing and Status Update (Marc, Hannes, Roger)

* PSAP Callback = (TBD)
http://trac.tools.ietf.org/wg/ecrit/trac/wiki
= <= FONT=20 face=3D"Courier New" size=3D2>http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback

Intention: = Discuss=20 potential feedback from emergency services groups on
the = requirements for=20 this work.

* Unauthenticated emergency services=20 (Dirk)
http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-ac= cess

Intention: = Determine next=20 steps. The group wants to work on it but there
are still lots of = open=20 issues and re-chartering is required to add it to
the milestone = list.
*=20 Transformations ID (James P.)
http://tools.ietf.org/id/draft-polk-ecrit-lost-transformations-urn<= /SPAN>

Intention: = TBD.

*=20 ECRIT Direct (James W.)
http://tools.ietf.org/id/draft-winterbottom-ecrit-direct

Intention: = TBD.
*=20 Additional Data (Brian)
http://tools.ietf.org/id/draft-rosen-ecrit-additional-data

Intention: = Initial=20 document version. Presentation of the history and the
origin of the = work.=20 Determine interest.

* Data Only Emergency Calls=20 (Brian)
http://tools.ietf.org/id/draft-rosen-ecrit-data-only-ea

Intention: = TBD.

*=20 Completing the Request Location (Brian)
http://tools.ietf.org/id/draft-rosen-ecrit-completed-location-00.tx= t

Intention: = Discussion=20 whether the group should work on this document. The
document is = making a=20 normative change to RFC 5222.

* Service URN Update and Service=20 Classification (Henning)
http://tools.ietf.org/id/draft-forte-ecrit-service-classification
= http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy
Intention: = Documents are a=20 bit stuck although group agreed to work on
it. Henning will present = a way=20 forward.
* Emergency Text Messaging using SIP MESSAGE=20 (Henning)
http://tools.ietf.org/id/draft-kim-ecrit-text-00.txt<= /A>

Intention: = Discussion=20 about what the group should do in this area.

* Describing = Boundaries=20 for Civic Addresse
http://tools.ietf.org/id/draft-thomson-ecrit-civic-boundary-00.txt<= /SPAN>

Intention: = Discussion=20 whether the group should work on this=20 doc.
_______________________________________________
Ecrit = mailing=20 list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit=20

 

Cullen Jennings
For=20 corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html<= /SPAN>



_______________________________________________
Ecrit=20 mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit=20




<= /BODY> ------_=_NextPart_001_01CAC527.56228FE9-- From James.Winterbottom@andrew.com Tue Mar 16 09:41:42 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECCC03A6C33 for ; Tue, 16 Mar 2010 09:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, 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 D4stn2RIqusc for ; Tue, 16 Mar 2010 09:41:32 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 073C83A6B31 for ; Tue, 16 Mar 2010 09:41:26 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:34895 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S187959Ab0CPQle (ORCPT ); Tue, 16 Mar 2010 11:41:34 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 16 Mar 2010 11:41:26 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 17 Mar 2010 00:41:24 +0800 From: "Winterbottom, James" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "br@brianrosen.net" , "fluffy@cisco.com" Date: Wed, 17 Mar 2010 00:41:19 +0800 Thread-Topic: Re: [Ecrit] ECRIT Agenda Version 3 Thread-Index: AcrFJdI4HP6iOQKoTyiPsVP3yH77fwAARI5AAAAMs3AAABlRQA== Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120DDCE601B@SISPE7MB1.commscope.com> References: <3D3C75174CB95F42AD6BCC56E5555B450255EBA6@FIESEXC015.nsn-intra.net> <5A55A45AE77F5941B18E5457ECAC81880120DDCE601A@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B450255EBBE@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450255EBBE@FIESEXC015.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_5A55A45AE77F5941B18E5457ECAC81880120DDCE601BSISPE7MB1co_"; type="multipart/alternative" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ECRIT Agenda Version 3 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, 16 Mar 2010 16:41:42 -0000 --_004_5A55A45AE77F5941B18E5457ECAC81880120DDCE601BSISPE7MB1co_ Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC81880120DDCE601BSISPE7MB1co_" --_000_5A55A45AE77F5941B18E5457ECAC81880120DDCE601BSISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cheers. Thanks Hannes [cid:image001.jpg@01CAC583.B48A7180] James Winterbottom Global Product Manager Andrew GeoLENs IP Location Product Portfolio Email: james.winterbottom@andrew.com Phone: +61-2-42-212938 Mobile: +61-448-266004 ________________________________ From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com= ] Sent: Wednesday, 17 March 2010 3:40 AM To: Winterbottom, James; br@brianrosen.net; fluffy@cisco.com Cc: ecrit@ietf.org Subject: RE: Re: [Ecrit] ECRIT Agenda Version 3 This mail was just in response to Cullen's note about the existing work ite= ms. So, I went through the list to explain that they are doing fine. The previous agenda has not changed and Marc & Richard need to figure out h= ow to arrange the time. Ciao Hannes ________________________________ From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: 16 March, 2010 12:38 To: Tschofenig, Hannes (NSN - FI/Espoo); br@brianrosen.net; fluffy@cisco.co= m Cc: ecrit@ietf.org Subject: RE: Re: [Ecrit] ECRIT Agenda Version 3 Does this mean that none of the "intention" documents listed in the previou= s agendas have made the cut? Cheers James ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of T= schofenig, Hannes (NSN - FI/Espoo) Sent: Wednesday, 17 March 2010 3:29 AM To: br@brianrosen.net; fluffy@cisco.com Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Agenda Version 3 --- I let the new chairs figure out how to arrange the items properly but s= ince I had written the mail already find my response below. Let us take a look at the list of WG items we have: Best Current Practice for Communications Services in support of Emergency C= alling (107967 byt= es) Framework for Emergency Calling using Internet Multimedia (96432 bytes) --> Brian says he does not need time for the two items above. Location Hiding: Problem Statement and Requirements (20127 bytes) --> This document does not seem to require time. At least from the IESG re= view feedback I have not seen anything dramatic. Specifying Holes in LoST Service Boundaries (22007 bytes) There were a punch of review comments but Martin did not send us a request = for a presentation. I assume that he feels comfortable addressing the comme= nts. Is this correct, Martin? Synchronizing Location-to-Service Translation (LoST) Protocol based Service= Boundaries and Mapping Elements (50425 bytes) The comments on the list by Alex got addressed and I shipped a new version.= I don't believe it would make sense to discuss the comment again. IANA Registering a SIP Resource Priority Header Field Namespace for Local E= mergency Communications (19327 bytes) Marc is responsible for this work and I have not received a request for a p= resentation slot. LoST Service List Boundary Extension (26226 bytes) Using Imprecise Location for Emergency Context Resolution (39455 bytes) My understanding of the two documents from above is that they are essential= ly done; we are only waiting for the feedback from the APPS directorate on = the Relax NG schema. Ciao Hannes Brian Rosen wrote: I don't see any issues with -phonebcp and -framework that would need meetin= g time. Brian On 3/12/10 6:09 PM, "Cullen Jennings" wrote: This is a lot of things to fit in 2.5 hours. It's possible that if I saw ho= w much time each had it would all look find but I'm very worried about just starting new work and not finishing things. I want to be sure there is no t= ime required for any of the current WG items. Cullen On Mar 5, 2010, at 2:32 AM, Hannes Tschofenig wrote: ECRIT Meeting Agenda (Version 3) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D MONDAY, March 22, 2010 0900-1130 Morning Session I Room: Palos Verdes * Agenda Bashing and Status Update (Marc, Hannes, Roger) * PSAP Callback (TBD) http://trac.tools.ietf.org/wg/ecrit/trac/wiki http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback Intention: Discuss potential feedback from emergency services groups on the requirements for this work. * Unauthenticated emergency services (Dirk) http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access Intention: Determine next steps. The group wants to work on it but there are still lots of open issues and re-chartering is required to add it to the milestone list. * Transformations ID (James P.) http://tools.ietf.org/id/draft-polk-ecrit-lost-transformations-urn Intention: TBD. * ECRIT Direct (James W.) http://tools.ietf.org/id/draft-winterbottom-ecrit-direct Intention: TBD. * Additional Data (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-additional-data Intention: Initial document version. Presentation of the history and the origin of the work. Determine interest. * Data Only Emergency Calls (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-data-only-ea Intention: TBD. * Completing the Request Location (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-completed-location-00.txt Intention: Discussion whether the group should work on this document. The document is making a normative change to RFC 5222. * Service URN Update and Service Classification (Henning) http://tools.ietf.org/id/draft-forte-ecrit-service-classification http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy Intention: Documents are a bit stuck although group agreed to work on it. Henning will present a way forward. * Emergency Text Messaging using SIP MESSAGE (Henning) http://tools.ietf.org/id/draft-kim-ecrit-text-00.txt Intention: Discussion about what the group should do in this area. * Describing Boundaries for Civic Addresse http://tools.ietf.org/id/draft-thomson-ecrit-civic-boundary-00.txt Intention: Discussion whether the group should work on this doc. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_5A55A45AE77F5941B18E5457ECAC81880120DDCE601BSISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] ECRIT Agenda Version 3

Cheers.

Thanks Hannes=

 

James Winterbottom

Global Product Manager

Andrew GeoLENs<= o:p>

IP Location Pro= duct Portfolio

Email: jam= es.winterbottom@andrew.com

Phone: +61-2-42-212938

Mobile: +61-448-266004

<= span style=3D'font-size:12.0pt;color:navy'> 

From:= Tschofenig, Hannes (NSN - FI/Espoo) [mailto:han= nes.tschofenig@nsn.com]
Sent: Wednesday, 17 March 20= 10 3:40 AM
To: Winterbottom, James; br@brianrosen.net; fluffy@cisco.com
Cc: ecrit@ietf.org
Subject: RE: Re: [Ecrit] ECR= IT Agenda Version 3

 

This mail was just in response to Cull= en's note about the existing work items. So, I went through the list to explain = that they are doing fine.

 

The previous agenda has not changed an= d Marc & Richard need to figure out how to arrange the time.

 

Ciao

Hannes

 

From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com]
Sent: 16 March, 2010 12:38 To: Tschofenig, Hannes (NSN = - FI/Espoo); br@brianrosen.net; fluffy@cisco.com
Cc: ecrit@ietf.org
Subject: RE: Re: [Ecrit] ECR= IT Agenda Version 3

Does this mean that none of the “intention” documents listed in the previous agendas have made = the cut?

 

Cheers

James

 

<= span style=3D'font-size:12.0pt;color:navy'> 

From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN = - FI/Espoo)
Sent: Wednesday, 17 March 20= 10 3:29 AM
To: br@brianrosen.net; fluffy@cisco.com
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] ECRIT A= genda Version 3

 

--- I let the new chairs figure out how to arrange the items properly but since= I had written the mail already find my response below.

Let us take a look at the list of WG items we have:

Best Current Practice for Communications Services in support of Emergency Calling <= font face=3DArial>(107967 bytes)
Framework for Emergency Call= ing using Internet Multimedia (96432 bytes)

 --> Brian says he does not need time for the two items above.

Location Hiding: Problem Sta= tement and Requirements (20127 bytes)

 --> This document does not seem to require time. At least from the IESG review feedback I have not seen anything dramatic.

Specifying Holes in LoST Ser= vice Boundaries (22007 bytes)

There were a punch of review comments but Martin did not send us a request = for a presentation. I assume that he feels comfortable addressing the comments.= Is this correct, Martin?

Synchronizing Location-to-Se= rvice Translation (LoST) Protocol based Service Boundaries and Mapping Elements (50425 bytes)

The comments on the list by Alex got addressed and I shipped a new version.= I don't believe it would make sense to discuss the comment again.

IANA Registering a SIP Resou= rce Priority Header Field Namespace for Local Emergency Communications (19327 bytes)

Marc is responsible for this work and I have not received a request for a presentation slot.

LoST Service List Boundary E= xtension (26226 bytes)
Using Imprecise Location for Emergency Context Resolution (39455 bytes)

My understanding of the two documents from above is that they are essential= ly done; we are only waiting for the feedback from the APPS directorate on the Relax NG schema.

Ciao
Hannes

Brian Rosen wrote:

I don't see any issues= with -phonebcp and -framework that would need meeting
time.

Brian


On 3/12/10 6:09 PM, "Cullen Jennings" <fluffy@cisco.com> wr= ote:

This is a lot of thing= s to fit in 2.5 hours. It's possible that if I saw how
much time each had it would all look find but I'm very worried about just starting new work and not finishing things. I want to be sure there is no t= ime
required for any of the current WG items.

Cullen


On Mar 5, 2010, at 2:32 AM, Hannes Tschofenig wrote:

ECRIT Meeting Agenda (Version 3)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

MONDAY, March 22, 2010
0900-1130 Morning Session I
Room: Palos Verdes

* Agenda Bashing and Status Update (Marc, Hannes, Roger)

* PSAP Callback (TBD)
http://trac.tools.ietf.org/wg/ecrit/trac/wiki
= http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callbac= k

Intention: Discuss potential feedback from emergency services groups on
the requirements for this work.

* Unauthenticated emergency services (Dirk)
http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthentica= ted-access

Intention: Determine next steps. The group wants to work on it but there
are still lots of open issues and re-chartering is required to add it to the milestone list.
* Transformations ID (James P.)
http://tools.ietf.org/id/draft-polk-ecrit-lost-transformation= s-urn

Intention: TBD.

* ECRIT Direct (James W.)
http://tools.ietf.org/id/draft-winterbottom-ecrit-direct

Intention: TBD.
* Additional Data (Brian)
http://tools.ietf.org/id/draft-rosen-ecrit-additional-data

Intention: Initial document version. Presentation of the history and the
origin of the work. Determine interest.

* Data Only Emergency Calls (Brian)
http://tools.ietf.org/id/draft-rosen-ecrit-data-only-ea

Intention: TBD.

* Completing the Request Location (Brian)
http://tools.ietf.org/id/draft-rosen-ecrit-completed-location= -00.txt

Intention: Discussion whether the group should work on this document. The
document is making a normative change to RFC 5222.

* Service URN Update and Service Classification (Henning)
= http://tools.ietf.org/id/draft-forte-ecrit-service-classifica= tion
http://tools.ietf.org/html/draft-forte-ecrit-service-urn-poli= cy
Intention: Documents are a bit stuck although group agreed to work on
it. Henning will present a way forward.
* Emergency Text Messaging using SIP MESSAGE (Henning)
http://tools.ietf.org/id/draft-kim-ecrit-text-00.txt

Intention: Discussion about what the group should do in this area.

* Describing Boundaries for Civic Addresse
http://tools.ietf.org/id/draft-thomson-ecrit-civic-boundary-0= 0.txt

Intention: Discussion whether the group should work on this doc.
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

 =

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index= .html



_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit



--_000_5A55A45AE77F5941B18E5457ECAC81880120DDCE601BSISPE7MB1co_-- --_004_5A55A45AE77F5941B18E5457ECAC81880120DDCE601BSISPE7MB1co_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6606; creation-date="Wed, 17 Mar 2010 00:41:21 GMT"; modification-date="Wed, 17 Mar 2010 00:41:21 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAByAUEDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2U9KT Pao57iG2haWeVI0UZLMcAVx+rfEayt2MOlxG7l6BzkJn+Z/Ck2lub0MNVru1ON/yOzdljUs7BVAy STgCmNcQpD5zTRiPGd5YAY+teL6x4g1fVpGW+uHVc/6gfKo/D/Gqjz3+oukBknuGA2xxgk4HTAFZ e1WyPchkM+VSnNI9T1Hx3odhuVbhrmQfwwjI/PpVKw+IunzRTy3qG2CsBFGuWd/XiuJ/4RHXPPhg Fi3mSruC54Rf9o9q6/RPhxa2+JtWcXMnXyU4QH39aFKo3sFbC5ZQpazcn5Mkg8Zarrd2sOiaSxi3 Yaeboo/lXaJnbzUdvBDbRCKCJIo14CoMAVLWqT6nh1qlOb/dxsvxFopMijNMwFopMj1oyPWgBaKT IpaACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAx9b8PW2vpBHeSSCKFt2xDjccY5qTT/D2k6WALSxiQ93K5b8zWnikxxSsnqae2qKHJzadjzyPw Hd6vq11falN9mglmZgi8uwzx7CsfxV41tvh9qy6R4d02zmlSMNcyT7mYMegyCO39K9Tvppraxnng t2uJY4yyRL1dscD8a8Hm+H3jjVE1PVrqxC3M75eGRgZJdxydvYAfXtTjCKdzbEY6vWSjJ6dlsd/4 j+Il3o3gbR9ctra2kudR27o33bFO3LYwc9R61z918aL8aJp09nZWT6hPJJHcxPv2x4I2lec8g/pW frfhLxbqPhLw3pKaROXsllE+WX5CX+U9eymoT8K9Ys/G9tDDYyy6StxGxuNy4CcE55zxVpKxw3kd H4k+J3iHSvEw0TTNKtLuYQxlk2OzmQruYAA9BTtO+L8194V1a9k0+GHUtORGVCWMUm5tv1HfjNc/ qnh3xxF8QL7xDpeiyGQzuYHcoQARtBwT6U2b4aeJNP8AB8yLZm61LUbhDLFE4PlRplhk5wSWPajQ LstJ8a/EEP2a4vNHsDazE8xFwzAHDY+Y4P1FafiL4r6xY+KZdJ0qysJIlCbWuWZTkqCcncAOtc7o Hw51vS/FWlz6hoTXlgSjzgsuIyRzkZ5Kn+VQar4M8W3fibUNTk8MtdpPPI4SR1CkE8HhvSnZCu7H Xat8SvEOjLoRurDTd2pIXmKlmVBvx8pDY6c96qJ8ap2v9UU2dr9lgjdrI/NulYHC7ue/XgUfEHwb ruraL4dXT9K8ya2tvLmhiIAi4BxyfwrmNT+FPiKCawhstPkmEltG1xLuXbHKxO4HnsMdPSkuUb5j 1n4eeJNX8V6I+qana21sjSlIBAGG8DqTknvx+Brra5bw/Zato13baOkCDSbaDYHAHUAc565J/ma6 moZa2CiiigYUUUUAFFFFABRRRQAUUUUAFFJRQAtFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUlFAEN3P8AZ7WSbaWKLkKo5J7AVkw3l/8A2UVut8dxHIFmdUyQp/iAH5frW2eRSYGaadiW tTFOqtbHy7dnvFUZ3SH5nz2XAAOMc/WmrrWoMdn2OLfyc7mxwcenrW5tAx049qNo9BTuuxPK+5zy axOlyzMWfzTgK2RHBjruGM49DnnNPbxDMrBfIiBYEhmLYXHY8dTjIre2gjp+lNMKM6uygsucEind dg5ZdzIg1i6vbe7aK0aN41ygYHOfQj14zTDqgsx/o9xJe7huPm54I/hGF+8c9D6Vu7fSk2D0HrSu h8r7mG+uXUUgWS3iRXfYrlmwvBOTxTR4hun27LNcvjCMW3J/vcd+1brRI+Nyg7TkZHQ0oQZJ9ad4 9hcsu5S06/a9eRWgaIxEK+T/AB9SB7Ywc+9aFRxxrHnYAMkk+5NPzUstX6i0UmaWkMKSgnFc/c6z e6lfSWGhLH+5O2e8kGUjPoo/iNAHQUZrCHhueUbrnXtSeT1ilEa/kBUU8Ov6Kpntro6rbpy8EygS 4/2WHX8aAOjoqlpmqWurWS3Vq+5DwQeqHuCOxq7QAUUlITgUAKTgE0iOrqGU5B5BqB7uHBVSXOP4 FzUVldRC1iDbk+UD5lxRcrkdr2LpOKM5ppYMpI5GOtZPhW+udQ0UXF3L5kpmkXdgDgOQOnsKCTYo rI8VXtzp3h64urSXypk27WwDjLAd6hGj66VB/wCEnl5H/PpHQBu5pCwzisyw03VLa6El3rj3cQBz EbdEyfXIqh4k1u70bU9PMERnikD+dEByVAByPccmgDpKKr2d7b39rHdWsiyxSDKsKsUAJRmmTsVg kYHBCkj8qzPC95cah4ds7u6k8yaVMu2AM8n0oA16KKKACiiigAooooAaTiqr32zVYLLZnzYnk3Z6 bSBjH4/pVvGapSWe/VYb0yACKJ49uOu4qc/pQVG19SgPE0LW2oP5JEtkX/dsceYF7g/p7VNqup3l n9ka3tYpluHEfzylSGIJHY8cVXufDcVzptxbPcbZJJpJY5VGCm48r7jsavXlgbtLVRKqfZ5ll6fe wCMe3Wkbv2SkmirrGuyaXNFH9nifMLTSFpduACAQvHJ5qzd6m8Qt4rW3865uVLJGzbQFGMlj2HIH 41V1jQU1a6huTMqSW8ZER252vkEN+mMVYu7Gadre4huEivIFKhyuVYHqCPTIBoF+6tHvrf8AQdaa lLK89vcwCC5hXeyK24Mp6EH8MVW0vXJ7xrZbqzFv9ri82Blk3hh1IPAwcc1YtLCSOSa5urhZrmZA hZV2qqjoAPxqrpeiz2jWxvLyOf7HGY4FjTaBngk5JyccUBanZ/19xNPrfkW1/L5IP2OYRY3/AHsh Tn2+9+lS3uozxXa2dnbLPOV8xgz7FRc4BJwepzjiql1ok1xPcKl3GlpdSLJNHsy24Y+6c8A7RVm9 sp3uxe2NzHDceX5b+Ym5XXORkZB4JNMLU9B0upTW8dmZrbZJczCJk352Eg8579P1pja3DFrjaZMh T5FZJT90k5+X2PH406awmuYrPzrlGltphKzhMBsAjAHbr+lNm0iG6u7uS4ZZIrmNEKdCNuec/j+l IlKn1EXWk/s6W7eI/LM0KRqcl2DbQB9TUtld30sxivbFYPl3K6Sb1+h4GDVWDQvK0gWRu3aRJzNH O3LBt24E+ppbHSJY9TOo3lxHJOVKjyVKKQe5BJyeKCmqdnY2RS03cPUfnRuHrTOcyfFF9NZaM4tj i4uHWCI+hbjP4DNW9K02HStNhsoRhY1wxH8Tdyay/FTbP7JnY/uotQjMnsOef8+tb+73H50ALQRm mSM+xvL278Hbk8Z7ZrE87xb/AM++kf8Af2T/AAoA1bbTrSzknkt4Vja4ffJt/iPrRe6ha6dB515O kMecZc4z9PWsmx1bV/7fXS9Sgsl3QGbdbuzYwcc5rPs7/SL7WrvUdVvbVWglMFrDNIBsVerYPcnv QBrQeLNGnmEQujGzHapmjZAx9iRir4BuyWb/AFIPAB+/7/Ss3UdW8P3llJbzX9hMjDbtaVT+XpWd o2tR2Gj6nD9qS6TTCfIkDZ3oRlRnv6Uikmbl/rGm6UFS6uEjZh8sajcx+ijmq2keINKvVjtY7kLN twI5VKFvoD1qHw5YRw2Y1K9eOXUbtfMllYglQeij0AFWbjTbHV9JSC52btoKSAjdG3Yg0DtozS2e XuKjAxyB0rF8E/8AIuL/ANfE3/oZqXw1fzXmkvHdtm5tZGglb+8V7/liovBH/IuL/wBfE3/oZpkh 43/5FS7/AOA/+hCtlLu22D/SIun98Vj+N/8AkVLv/gP/AKEKlXwj4eKg/wBkWvI/uUCNVLiGRtsc sbn0VgTWFrAz4u0HPrN/6Aa0bLQNJ0248+y0+GCXG3ei4OKz9Y/5G7QfrN/6BQBBd283ha8fUbGN pNMlbN1bKP8AVH++o/mK6K3uYru3juLd1kikUMrjoRUhVSCCMg9Qa5iWOTwjeNcwq0mjzvmWMc/Z WJ+8B/d9aAOkuP8Aj2l/3D/KsfwX/wAijp//AFz/AKmtV5UmsnkjdXR4yVZeQRjrWT4M/wCRQsP+ uZ/maAJ7zxPpNjcm2musyr98RozhP94gcfjWlbzxXUKzQSLJE4yrocgiuX8OX1npMcuk6mVtb0zM XaYYFxknDBuh47V0tlaW1lbiK0jWOIksFXpk80AWKKKKACiiigBKY8MchBdASKkooAg+yQf88xR9 lg/55ipqKB8z7kP2SD/nkKPskHaMfnU1FAcz7kP2SDH+rFH2SD/nmKmooDmfch+yQf8APMUfZYP+ eYqaigLsh+yQf88xR9lg/wCeYqaigOZ9yH7Lb/8APIUfZIP+eYqaloDml3IPskH/ADyWj7JB/wA8 hU1FAc0u5n6no9tqOnTWjLs8xcBh1U9j+dZ2h3scn/Er1ONYtStxtYE4EwHR19c10NUtT0ix1WNV vIQxTlHU4dD6gjkUBzPuTi1gx/qxVe9ksNOt3ubtkiiUclj1+nrWeNA1KL5LfxHeRx+jxpIfzNPt /C9mtwLq+mn1GdfutctlV+i9KB8z7lbw/aG/u7rXLmAxJcgR20TdVjHc+5qDQdO0+O+1HTLyzgku IrhpUMkYJaNzkEZ6gdK6sAAVm6nottqbxys0kFzF/q7iFtrr7Z9PagVxtzoulrA5GnWqlRnPlL2r Oay0nXtCvl0y1jj3B4lkWILuYdCPUZqZvDl1cr5eoa7eXUHeJVWPcPQkcmtO3hj06FLeJBHbIMIF HCD0/wDr0hpszPD4sNS0aFzbRCeJPKmjK8o68EGrifYbHSVuJ0ijijj3MxUcCoL/AMPwXdyb60uZ rK6YfNLbtw49x0NVbLwwlwkM2p6hcagqYZIpMLGD7qOtHUrmbjuS+FLdv7Nub6WLy2vrh51UjBCn p/j+NHgn/kXF/wCvib/0M1thgw2p93pkdKw4/CFpApWDUtUhQsW2R3RVQScngCmQO8b/APIqXf1T /wBCFbqfcX6VlyaBbz6NJpdxcXc0Mjbi8su6Trn7x+lVx4Uix/yGNY/8DD/hQI3q57WP+Rv0H6zf +gVcsdCTT7oXC6jqM5AI2T3JdfyqxcabBc6ha30hfzbQt5eDwdwwc0AXaa8aSIyOoZWGCD0IpR0p aAOSmWXwi8iDdJos+cHqbVj2/wB01a8LXMVj4ItLmdiscURZyBnAya35oYp4HhljV43XDKwyCKrW Om2+n6cthEu6BQVCvz8p7UAEkFhrFijTQxXMEqhl3rng+npWHol0NI/ti2Bmns7CZREB8zKCOVGT 2NWV8NTWwMWnazdWdsxJMKqrBc/3SeVq9aaLZ2emvYRB/LkJLuzZZ2PUk+tADjrFqofeXRkdEZWH IZsYH68/Q1fFZ0mjWkpcuHy+/J3f3uv5c49MmtBaAHUUUUAFJVW9vYtPt2uJxKY15Yxxs+0epAHS obTV7e8uY4Y0mBliaVTJEUyoIHQ4P8Qp2YnJJ2NGikqPzo/O8nePM27tuecdM0hktJSHNQWd5HeR yPGGAjleI7h3U4P8qBXLNFRvPFEUEkiqZG2pk/eOCcD8Afyp9AwoqGK4inkmWNtxhfY/HRsA4/Ii oLrUYbO5hhl3DzEdy/G1FXGSSfdgOPWiwrrcvUU0HimpNHKXEbqxjba4B+6cA4P4EfnQFySim1Eb u3E3k+egk3bNued2N2PrgE0DJ6KQ0h5XFAC0tZ0OrW8mlHU3EkNuASC4525xnAz1q+KNhJ3Foopk sscIUySKgZgo3HGSeAKAH0VHDNHPGJYnDo3RlOQaf70DFoOCKo3eq21lcpbyLO8siFwsMLSHaCBk 7QcckVbU7gGAwD60WFdEb20eCVBT12kiorKCP7JETuPyjgsSKkvbuOyt/NlVipdE+Uc5Zgo/U0ye 4isFt43VsSyiFMdiQTz7cUWZXPo1ctAADA4FLTRUEF5HPdXNugYPbMquSODlQwx+Bo1JbLNFVrW7 t7y3M9vKskYLKSOxBwR+lPtbiO6tY7iFt0UqhkbGMg0BcmopkUscylo3V1DFSQc4IOCPwNOoGLS1 VvruOxtGuJQxRWVSFHPLAD9TVhmVFLMQABkk9hQK46kqlZanbX7MsBkyBuG+NlDD1Ukcj3FSXF3H bTW8cgbNxL5aYHQ7SefyNFncLqxZpahmuoLcgTSpHuDEbjjIAyfyFPV1dA6kFSMgjuKB3H0U3Ipa AFooooAp6sjyaNexopZ2t5AqqMknaeBWHfac9zJas0MxMOmPtKFl2yfJgcd+OntXT4pMGqjKxnKC kcdax6rJqcMlwzpcGVGz5UpPlYGRnOwDrnPIq54it7ye7lWAXAR7WNd0ORg+cucEd9ufwrpcGjFP n1uL2ata5yjWzW93LBdRXf8AZMczBFj8xjnYhB4+Yrnd071QsI7y30++t44b6M3eVtVdXJz5rklj /DwVOTjiu6waNvrT9poJ0tb3ON+zTT6jGot7qVEvBKZZFdWU7ZODzggfLgjjBAp0Nrd2NjYW8BmE mqQrFOJHYtG+Ms/JyOMjjocV2GDUT2sUlylwyAyxgqjegPXFHOP2dtTEuoTb69Zm3hncDauza2zB J3PuHG4d93XjFReJrGWa7FxBDK8iWM6q6buGJTA478n/ACK6XBowfWlz2dx8iascfeW88ZuLgx3b zfbZDGgEhSQADap2n5RnOD0z1rW061a2j1iTypo2luWcbclm/dryue+c4962cHNKBQ53BU7HHWr3 Nqm4xXf2cQzQo4jl3SOwQqxU5IOQwz0z04qG40/VHVSkUxuonjMTMThW+zEE5/3sD6125B7UYNNV NbkuldWuc94aiuEuZiXYQGMAoYpV+fPJzIc5x6cVXeKZp5FKXZ1Q3LbX+fyvK3cc/d27PxzXU4NG 2lzalcmljl0sXt/h89tHbyiTyGJjwS2c+nX8KbdO1093NsvTduc6eyJIqgY4yMADnOd1dVg0Yo5w 9na1jlWjn8u5/d3h1gs+HXfsKZOMH7n3cY75qjcWUVzq9stla6gbZTEZfNEoXeJVOfm7gZyRxXcY NBGaaqWJdK6tc462hkFoo1SK9JEf+iiIScNls529DnH3uMYqSwstRjuIry4Fwbtr9Y5TuYr5fljd x027u/rXWgYowaTmNUl3Od1hFXxBbSzS3sMQtWXzLVGbLb1ODtU1WvLbUP7QubiyFx5z3GyNmLbT H9nz0PA+cdfWurxSYPoKFOwOnc4LVbdJSiafa6q0Xk5uARJkt5kZ43dXwDyOKuXVvcOy/wBjQ3It 1lUoJlfiXa/I3845GT0ziuywaCKftOgvZHFW8OoLC5BnMGE+1pHHMGYbhvILnJOM/d/wrY8Owxpd ak1vDPHbvMhi85WBYbACRu5xmt3bRg0nO5ShZnOaZp91a6VHdWsZW4/eCaBhtEw3tj6NjofzrGit tVjhto3DwypBELUeVKxT5Rn7pCg5zndXeYNBHvTVRoTpJnF2+l6qizWVt50MV1PLK8oYjymRyRjP Z/l/AGrYS6mjgvNViuVguS73EEW8mJgAEGF5xw3TuRXU4oxQ6jfQFSS6nDX+n6ldQzeXHc/JCDZ+ ZuOz98u3cO5AGee2K6bTtw0p45beVpowyyxyHJkbqcE8EHPHbntWng+tGDSc7qwRp8rucnuujEYN O+3GxAUzRyxsrxDcMohIBPy7umcYGDzVbUrW5mi26TFdC1DZiDhwwk8uQEru+YDkDnvXa4NGKanY TpXVrnF6hBcajqTXkMF08QhkEJZHUhxCw4U4IySB05NWZo5cS/aY7w3mxPsJiD4X5B1xwDuznd2r q8UYxRz+Q/Z+Zx6W19G08kou1acXSzvEGbHKbSoJ/wB4jHvW/oDSHSkEkRj2sVXO4b1zw2G+YZ9D WgFpwFS5XHGHKxaKKKk0CiiikAlFFFMTCloooASiiigBaKKKACiiigBKKKKYBRRRSBBRRRTAKWii gAooopAJRRRTEFHeiikMWiiigApKKKBhRRRTEFLRRSAKKKKAEooooAKWiigYUUUUAf/Z --_004_5A55A45AE77F5941B18E5457ECAC81880120DDCE601BSISPE7MB1co_-- From jmpolk@cisco.com Tue Mar 16 12:15:17 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 A66A73A693A for ; Tue, 16 Mar 2010 12:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFd3DmaNEgbd for ; Tue, 16 Mar 2010 12:15:15 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8D5503A69A5 for ; Tue, 16 Mar 2010 12:15:09 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,651,1262563200"; d="scan'208";a="101099696" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 16 Mar 2010 19:15:18 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2GJFGri015298; Tue, 16 Mar 2010 19:15:17 GMT Message-Id: <201003161915.o2GJFGri015298@sj-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 16 Mar 2010 14:15:15 -0500 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , , From: "James M. Polk" In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450255EBA6@FIESEXC015.nsn-in tra.net> References: <3D3C75174CB95F42AD6BCC56E5555B450255EBA6@FIESEXC015.nsn-intra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Agenda Version 3 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, 16 Mar 2010 19:15:17 -0000 At 11:29 AM 3/16/2010, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01CAC525.E3BAA375" > >--- I let the new chairs figure out how to arrange the items >properly but since I had written the mail already find my response below. > >Let us take a look at the list of WG items we have: > >Best >Current Practice for Communications Services in support of Emergency >Calling (107967 bytes) >Framework >for Emergency Calling using Internet Multimedia (96432 bytes) > > --> Brian says he does not need time for the two items above. > >Location >Hiding: Problem Statement and Requirements (20127 bytes) > > --> This document does not seem to require time. At least from the > IESG review feedback I have not seen anything dramatic. > >Specifying >Holes in LoST Service Boundaries (22007 bytes) > >There were a punch of review comments but Martin did not send us a >request for a presentation. I assume that he feels comfortable >addressing the comments. Is this correct, Martin? > >Synchronizing >Location-to-Service Translation (LoST) Protocol based Service >Boundaries and Mapping Elements (50425 bytes) > >The comments on the list by Alex got addressed and I shipped a new >version. I don't believe it would make sense to discuss the comment again. > >IANA >Registering a SIP Resource Priority Header Field Namespace for Local >Emergency Communications (19327 bytes) > >Marc is responsible for this work and I have not received a request >for a presentation slot. BTW - I have revved this doc, specifically addressing/incorporating each of the comments/suggested modifications by Keith Drage. I'll announce this in a separate message to the list. I don't believe there needs to be valuable preso time given to this ID, as I believe I have addressed every concern/comment/question that I have received - and am just waiting on it being chartered (with a milestone) to pub request the ID. In other words, I think this doc is done and ready for IESG review. James >LoST >Service List Boundary Extension (26226 bytes) >Using >Imprecise Location for Emergency Context Resolution (39455 bytes) > >My understanding of the two documents from above is that they are >essentially done; we are only waiting for the feedback from the APPS >directorate on the Relax NG schema. > >Ciao >Hannes > >Brian Rosen wrote: >I don't see any issues with -phonebcp and -framework that would need >meeting time. >Brian > >On 3/12/10 6:09 PM, "Cullen Jennings" wrote: >This is a lot of things to fit in 2.5 hours. It's possible that if I >saw how much time each had it would all look find but I'm very >worried about just starting new work and not finishing things. I >want to be sure there is no time required for any of the current WG items. >Cullen > >On Mar 5, 2010, at 2:32 AM, Hannes Tschofenig wrote: >ECRIT Meeting Agenda (Version 3) ================================ >MONDAY, March 22, 2010 0900-1130 Morning Session I Room: Palos Verdes >* Agenda Bashing and Status Update (Marc, Hannes, Roger) >* PSAP Callback (TBD) >http://trac.tools.ietf.org/wg/ecrit/trac/wiki >http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback > >Intention: Discuss potential feedback from emergency services groups >on the requirements for this work. >* Unauthenticated emergency services (Dirk) >http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access > >Intention: Determine next steps. The group wants to work on it but >there are still lots of open issues and re-chartering is required to >add it to the milestone list. * Transformations ID (James P.) >http://tools.ietf.org/id/draft-polk-ecrit-lost-transformations-urn >Intention: TBD. >* ECRIT Direct (James W.) >http://tools.ietf.org/id/draft-winterbottom-ecrit-direct > >Intention: TBD. * Additional Data (Brian) >http://tools.ietf.org/id/draft-rosen-ecrit-additional-data > >Intention: Initial document version. Presentation of the history and >the origin of the work. Determine interest. >* Data Only Emergency Calls (Brian) >http://tools.ietf.org/id/draft-rosen-ecrit-data-only-ea > >Intention: TBD. >* Completing the Request Location (Brian) >http://tools.ietf.org/id/draft-rosen-ecrit-completed-location-00.txt > >Intention: Discussion whether the group should work on this >document. The document is making a normative change to RFC 5222. >* Service URN Update and Service Classification (Henning) >http://tools.ietf.org/id/draft-forte-ecrit-service-classification >http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy >Intention: Documents are a bit stuck although group agreed to work >on it. Henning will present a way forward. * Emergency Text >Messaging using SIP MESSAGE (Henning) >http://tools.ietf.org/id/draft-kim-ecrit-text-00.txt > >Intention: Discussion about what the group should do in this area. >* Describing Boundaries for Civic Addresse >http://tools.ietf.org/id/draft-thomson-ecrit-civic-boundary-00.txt > >Intention: Discussion whether the group should work on this doc. >_______________________________________________ Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > > >Cullen Jennings For corporate legal information go to: >http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > >_______________________________________________ Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > > > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From mlinsner@cisco.com Tue Mar 16 14:36:42 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7138D3A6821 for ; Tue, 16 Mar 2010 14:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrVvfSTp6ieM for ; Tue, 16 Mar 2010 14:36:41 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8A2643A6782 for ; Tue, 16 Mar 2010 14:36:41 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKmWn0tAZnwM/2dsb2JhbACbBW0GoWuYd4JQgiYE X-IronPort-AV: E=Sophos;i="4.49,652,1262563200"; d="scan'208";a="93352665" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 16 Mar 2010 21:36:49 +0000 Received: from [10.123.3.173] (rtp-vpn3-1433.cisco.com [10.82.221.159]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2GLalpN025836; Tue, 16 Mar 2010 21:36:48 GMT User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 16 Mar 2010 17:36:47 -0400 From: Marc Linsner To: "ecrit@ietf.org" Message-ID: Thread-Topic: ECRIT Agenda Thread-Index: AcrFUMeVsYLy/30AUEC3AG66QMpj0Q== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Geoff Thompson Subject: [Ecrit] ECRIT Agenda 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, 16 Mar 2010 21:36:42 -0000 All, I tweaked the agenda with time management and added 1 new item. Geoff Thompson, co-chair of the Emergency Services Study Group (ESSG) within IEEE802 is going to introduce the ESSG work. The new agenda can be found at: http://www.ietf.org/proceedings/10mar/agenda/ecrit.txt Thanks, -Marc- From Martin.Thomson@andrew.com Tue Mar 16 15:09:20 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D73A3A67EA for ; Tue, 16 Mar 2010 15:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.179, 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 9BLY0cLetfvg for ; Tue, 16 Mar 2010 15:09:18 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 3A7D63A6782 for ; Tue, 16 Mar 2010 15:09:18 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:18892 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S173523Ab0CPWJ0 (ORCPT ); Tue, 16 Mar 2010 17:09:26 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 16 Mar 2010 17:09:25 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 17 Mar 2010 06:09:23 +0800 From: "Thomson, Martin" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "br@brianrosen.net" , "fluffy@cisco.com" Date: Wed, 17 Mar 2010 06:10:40 +0800 Thread-Topic: Re: [Ecrit] ECRIT Agenda Version 3 Thread-Index: AcrFJdI4HP6iOQKoTyiPsVP3yH77fwAL2IvA Message-ID: <8B0A9FCBB9832F43971E38010638454F03E0A3023C@SISPE7MB1.commscope.com> References: <3D3C75174CB95F42AD6BCC56E5555B450255EBA6@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450255EBA6@FIESEXC015.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8B0A9FCBB9832F43971E38010638454F03E0A3023CSISPE7MB1comm_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ECRIT Agenda Version 3 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, 16 Mar 2010 22:09:21 -0000 --_000_8B0A9FCBB9832F43971E38010638454F03E0A3023CSISPE7MB1comm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmXigJlzIG9uZSBpdGVtLCBidXQgSeKAmXZlIHBvc3RlZCB0byB0aGUgbGlzdCwgd2hpY2gg c2hvdWxkIGJlIHN1ZmZpY2llbnQuICBJZiBJIGRvbuKAmXQgZ2V0IGFueSBtb3JlIGZlZWRiYWNr LCBJ4oCZbGwgbWFrZSBubyBjaGFuZ2UgdG8gdGhlIGRvYy4gIFRoZSBJRVNHIHNob3VsZCBiZSBz YXRpc2ZpZWQuICBObyBuZWVkIHRvIHdhc3RlIHByZWNpb3VzIG1lZXRpbmcgdGltZS4NCg0KDQpT cGVjaWZ5aW5nIEhvbGVzIGluIExvU1QgU2VydmljZSBCb3VuZGFyaWVzPGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaWQvZHJhZnQtaWV0Zi1lY3JpdC1zcGVjaWZ5aW5nLWhvbGVzLTAyLnR4dD4gKDIyMDA3 IGJ5dGVzKQ0KDQpUaGVyZSB3ZXJlIGEgcHVuY2ggb2YgcmV2aWV3IGNvbW1lbnRzIGJ1dCBNYXJ0 aW4gZGlkIG5vdCBzZW5kIHVzIGEgcmVxdWVzdCBmb3IgYSBwcmVzZW50YXRpb24uIEkgYXNzdW1l IHRoYXQgaGUgZmVlbHMgY29tZm9ydGFibGUgYWRkcmVzc2luZyB0aGUgY29tbWVudHMuIElzIHRo aXMgY29ycmVjdCwgTWFydGluPw0K4oCmDQoNCk9uIDMvMTIvMTAgNjowOSBQTSwgIkN1bGxlbiBK ZW5uaW5ncyIgPGZsdWZmeUBjaXNjby5jb20+IHdyb3RlOg0KDQpUaGlzIGlzIGEgbG90IG9mIHRo aW5ncyB0byBmaXQgaW4gMi41IGhvdXJzLiBJdCdzIHBvc3NpYmxlIHRoYXQgaWYgSSBzYXcgaG93 DQptdWNoIHRpbWUgZWFjaCBoYWQgaXQgd291bGQgYWxsIGxvb2sgZmluZCBidXQgSSdtIHZlcnkg d29ycmllZCBhYm91dCBqdXN0DQpzdGFydGluZyBuZXcgd29yayBhbmQgbm90IGZpbmlzaGluZyB0 aGluZ3MuIEkgd2FudCB0byBiZSBzdXJlIHRoZXJlIGlzIG5vIHRpbWUNCnJlcXVpcmVkIGZvciBh bnkgb2YgdGhlIGN1cnJlbnQgV0cgaXRlbXMuDQoNCkN1bGxlbg0K --_000_8B0A9FCBB9832F43971E38010638454F03E0A3023CSISPE7MB1comm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9VVRGLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDov L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KDQo8bWV0YSBuYW1lPUdlbmVy YXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8dGl0 bGU+UmU6IFtFY3JpdF0gRUNSSVQgQWdlbmRhIFZlcnNpb24gMzwvdGl0bGU+DQo8c3R5bGU+DQo8 IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowbW07DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MG1tOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBtbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MjQ0MDYxO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuU2VjdGlvbjEN Cgl7cGFnZTpTZWN0aW9uMTt9DQogLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KIEBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjE4OTg0NzIzOTM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi05MTUyMzc1 OTY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEE3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MG1tO30NCnVsDQoJe21hcmdpbi1ib3R0 b206MG1tO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1FTi1BVSBsaW5rPWJs dWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMyNDQwNjEnPlRoZXJl4oCZcyBvbmUgaXRlbSwgYnV0IEni gJl2ZSBwb3N0ZWQgdG8gdGhlIGxpc3QsIHdoaWNoIHNob3VsZCBiZQ0Kc3VmZmljaWVudC7CoCBJ ZiBJIGRvbuKAmXQgZ2V0IGFueSBtb3JlIGZlZWRiYWNrLCBJ4oCZbGwgbWFrZSBubyBjaGFuZ2Ug dG8gdGhlIGRvYy7CoA0KVGhlIElFU0cgc2hvdWxkIGJlIHNhdGlzZmllZC7CoCBObyBuZWVkIHRv IHdhc3RlIHByZWNpb3VzIG1lZXRpbmcgdGltZS7CoCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MG1tIDBtbSAwbW0gNC4wcHQnPg0KDQo8cCBzdHlsZT0n bWFyZ2luLWxlZnQ6NS4yNXB0Jz48YQ0KaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFm dC1pZXRmLWVjcml0LXNwZWNpZnlpbmctaG9sZXMtMDIudHh0Ij48c3Bhbg0Kc3R5bGU9J2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5TcGVjaWZ5aW5nIEhvbGVzIGluIExvU1QgU2Vy dmljZQ0KQm91bmRhcmllczwvc3Bhbj48L2E+IDxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIic+KDIyMDA3DQpieXRlcyk8YnI+DQo8YnI+DQpUaGVyZSB3ZXJlIGEg cHVuY2ggb2YgcmV2aWV3IGNvbW1lbnRzIGJ1dCBNYXJ0aW4gZGlkIG5vdCBzZW5kIHVzIGEgcmVx dWVzdCBmb3INCmEgcHJlc2VudGF0aW9uLiBJIGFzc3VtZSB0aGF0IGhlIGZlZWxzIGNvbWZvcnRh YmxlIGFkZHJlc3NpbmcgdGhlIGNvbW1lbnRzLiBJcw0KdGhpcyBjb3JyZWN0LCBNYXJ0aW4/PGJy Pg0KPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPuKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHA+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+T24gMy8xMi8xMCA2OjA5 IFBNLA0KJnF1b3Q7Q3VsbGVuIEplbm5pbmdzJnF1b3Q7ICZsdDtmbHVmZnlAY2lzY28uY29tJmd0 OyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxwIHN0eWxlPSdtYXJnaW4tbGVmdDo3 Ny4yNXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciJz5UaGlzDQppcyBhIGxvdCBvZiB0aGluZ3MgdG8gZml0IGluIDIuNSBob3Vycy4gSXQn cyBwb3NzaWJsZSB0aGF0IGlmIEkgc2F3IGhvdzxicj4NCm11Y2ggdGltZSBlYWNoIGhhZCBpdCB3 b3VsZCBhbGwgbG9vayBmaW5kIGJ1dCBJJ20gdmVyeSB3b3JyaWVkIGFib3V0IGp1c3Q8YnI+DQpz dGFydGluZyBuZXcgd29yayBhbmQgbm90IGZpbmlzaGluZyB0aGluZ3MuIEkgd2FudCB0byBiZSBz dXJlIHRoZXJlIGlzIG5vIHRpbWU8YnI+DQpyZXF1aXJlZCBmb3IgYW55IG9mIHRoZSBjdXJyZW50 IFdHIGl0ZW1zLjxicj4NCjxicj4NCkN1bGxlbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPC9k aXY+DQoNCjwvZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== --_000_8B0A9FCBB9832F43971E38010638454F03E0A3023CSISPE7MB1comm_-- From fluffy@cisco.com Tue Mar 16 17:06:02 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 B88A73A6B29 for ; Tue, 16 Mar 2010 17:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.354 X-Spam-Level: X-Spam-Status: No, score=-110.354 tagged_above=-999 required=5 tests=[AWL=0.245, 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 xQjcPHnLm12E for ; Tue, 16 Mar 2010 17:06:01 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 80FFF3A6A45 for ; Tue, 16 Mar 2010 17:05:52 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE+5n0urR7Ht/2dsb2JhbACbBHOhXph6glCCJgSDGg X-IronPort-AV: E=Sophos;i="4.49,653,1262563200"; d="scan'208";a="246994143" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 17 Mar 2010 00:06:01 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2H05xY2008828; Wed, 17 Mar 2010 00:05:59 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450255EBBE@FIESEXC015.nsn-intra.net> Date: Tue, 16 Mar 2010 18:05:58 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <82DB1DC1-5E9C-43B4-905B-215FE66176FD@cisco.com> References: <3D3C75174CB95F42AD6BCC56E5555B450255EBA6@FIESEXC015.nsn-intra.net> <5A55A45AE77F5941B18E5457ECAC81880120DDCE601A@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B450255EBBE@FIESEXC015.nsn-intra.net> To: "Tschofenig, Hannes (NSN - FI/Espoo)" X-Mailer: Apple Mail (2.1077) Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Agenda Version 3 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, 17 Mar 2010 00:06:02 -0000 Thanks for doing this - seems good to me and I agree with Martin and = Brian on I don't see any issues with framework, phonebcp, or = draft-ietf-ecrit-specifying-holes that need agenda time. On Mar 16, 2010, at 10:39 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > This mail was just in response to Cullen's note about the existing = work items. So, I went through the list to explain that they are doing = fine. > =20 > The previous agenda has not changed and Marc & Richard need to figure = out how to arrange the time. > =20 > Ciao > Hannes >=20 > From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20= > Sent: 16 March, 2010 12:38 > To: Tschofenig, Hannes (NSN - FI/Espoo); br@brianrosen.net; = fluffy@cisco.com > Cc: ecrit@ietf.org > Subject: RE: Re: [Ecrit] ECRIT Agenda Version 3 >=20 > Does this mean that none of the =93intention=94 documents listed in = the previous agendas have made the cut? > =20 > Cheers > James > =20 > =20 > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Wednesday, 17 March 2010 3:29 AM > To: br@brianrosen.net; fluffy@cisco.com > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] ECRIT Agenda Version 3 > =20 > --- I let the new chairs figure out how to arrange the items properly = but since I had written the mail already find my response below. >=20 > Let us take a look at the list of WG items we have: >=20 > Best Current Practice for Communications Services in support of = Emergency Calling (107967 bytes) > Framework for Emergency Calling using Internet Multimedia (96432 = bytes) >=20 > --> Brian says he does not need time for the two items above. >=20 > Location Hiding: Problem Statement and Requirements (20127 bytes) >=20 > --> This document does not seem to require time. At least from the = IESG review feedback I have not seen anything dramatic. >=20 > Specifying Holes in LoST Service Boundaries (22007 bytes) >=20 > There were a punch of review comments but Martin did not send us a = request for a presentation. I assume that he feels comfortable = addressing the comments. Is this correct, Martin? >=20 > Synchronizing Location-to-Service Translation (LoST) Protocol based = Service Boundaries and Mapping Elements (50425 bytes) >=20 > The comments on the list by Alex got addressed and I shipped a new = version. I don't believe it would make sense to discuss the comment = again. >=20 > IANA Registering a SIP Resource Priority Header Field Namespace for = Local Emergency Communications (19327 bytes) >=20 > Marc is responsible for this work and I have not received a request = for a presentation slot. >=20 > LoST Service List Boundary Extension (26226 bytes) > Using Imprecise Location for Emergency Context Resolution (39455 = bytes) >=20 > My understanding of the two documents from above is that they are = essentially done; we are only waiting for the feedback from the APPS = directorate on the Relax NG schema. >=20 > Ciao > Hannes >=20 > Brian Rosen wrote: >=20 > I don't see any issues with -phonebcp and -framework that would need = meeting > time. >=20 > Brian >=20 >=20 > On 3/12/10 6:09 PM, "Cullen Jennings" wrote: >=20 > This is a lot of things to fit in 2.5 hours. It's possible that if I = saw how > much time each had it would all look find but I'm very worried about = just > starting new work and not finishing things. I want to be sure there is = no time > required for any of the current WG items. >=20 > Cullen >=20 >=20 > On Mar 5, 2010, at 2:32 AM, Hannes Tschofenig wrote: >=20 > ECRIT Meeting Agenda (Version 3) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >=20 > MONDAY, March 22, 2010 > 0900-1130 Morning Session I > Room: Palos Verdes >=20 > * Agenda Bashing and Status Update (Marc, Hannes, Roger) >=20 > * PSAP Callback (TBD) > http://trac.tools.ietf.org/wg/ecrit/trac/wiki > http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback >=20 > Intention: Discuss potential feedback from emergency services groups = on > the requirements for this work. >=20 > * Unauthenticated emergency services (Dirk) > = http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access >=20 > Intention: Determine next steps. The group wants to work on it but = there > are still lots of open issues and re-chartering is required to add it = to > the milestone list. > * Transformations ID (James P.) > http://tools.ietf.org/id/draft-polk-ecrit-lost-transformations-urn >=20 > Intention: TBD. >=20 > * ECRIT Direct (James W.) > http://tools.ietf.org/id/draft-winterbottom-ecrit-direct >=20 > Intention: TBD. > * Additional Data (Brian) > http://tools.ietf.org/id/draft-rosen-ecrit-additional-data >=20 > Intention: Initial document version. Presentation of the history and = the > origin of the work. Determine interest. >=20 > * Data Only Emergency Calls (Brian) > http://tools.ietf.org/id/draft-rosen-ecrit-data-only-ea >=20 > Intention: TBD. >=20 > * Completing the Request Location (Brian) > http://tools.ietf.org/id/draft-rosen-ecrit-completed-location-00.txt >=20 > Intention: Discussion whether the group should work on this document. = The > document is making a normative change to RFC 5222. >=20 > * Service URN Update and Service Classification (Henning) > http://tools.ietf.org/id/draft-forte-ecrit-service-classification > http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy > Intention: Documents are a bit stuck although group agreed to work on > it. Henning will present a way forward. > * Emergency Text Messaging using SIP MESSAGE (Henning) > http://tools.ietf.org/id/draft-kim-ecrit-text-00.txt >=20 > Intention: Discussion about what the group should do in this area. >=20 > * Describing Boundaries for Civic Addresse > http://tools.ietf.org/id/draft-thomson-ecrit-civic-boundary-00.txt >=20 > Intention: Discussion whether the group should work on this doc. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > =20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 >=20 >=20 >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From mlinsner@cisco.com Thu Mar 18 05:46:59 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 506CE3A69AD for ; Thu, 18 Mar 2010 05:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.734 X-Spam-Level: X-Spam-Status: No, score=-8.734 tagged_above=-999 required=5 tests=[AWL=0.735, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3OS5nlupxdv for ; Thu, 18 Mar 2010 05:46:58 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7A01A3A67F5 for ; Thu, 18 Mar 2010 05:46:58 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FABq+oUurR7H+/2dsb2JhbACbLW0GoBaYe4R5BA X-IronPort-AV: E=Sophos;i="4.51,267,1267401600"; d="scan'208";a="247246744" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 18 Mar 2010 12:46:57 +0000 Received: from [10.116.195.120] (rtp-mlinsner-8717.cisco.com [10.116.195.120]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2ICkuUd002917 for ; Thu, 18 Mar 2010 12:46:57 GMT User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 18 Mar 2010 08:46:55 -0400 From: Marc Linsner To: "ecrit@ietf.org" Message-ID: Thread-Topic: Presentations Thread-Index: AcrGmRbmVh2cv74EikW4hXC2WQmGNA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [Ecrit] Presentations X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 12:46:59 -0000 If you presenting in ECRIT, please send your preso to the Roger (RMarshall@telecomsys.com). We meet first thing Monday - 9AM! Thanks, -Marc- From brian.rosen@neustar.biz Thu Mar 18 15:16:48 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 C921F3A683A for ; Thu, 18 Mar 2010 15:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[AWL=-1.261, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 WRAyTXAToSzS for ; Thu, 18 Mar 2010 15:16:43 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id BC9623A67CC for ; Thu, 18 Mar 2010 15:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=neustar.biz; s=neustarbiz; t=1268950611; x=1584305404; q=dns/txt; h=From:Date: Subject:Message-ID:Content-Language:Content-Type: Content-Transfer-Encoding; bh=c9iNXa+GtuL+JHtWMJPNlzCqUm13QMcy5m XG4zhbnb8=; b=YXoP1+/qVDhBZmvYk5DvFDRbm59BysEFPIhUI3Ku3p08R4vHln Kewaj86ONYl+2tMM2xyFMAuKuDIwqBTeY20A== Received: from ([10.31.13.50]) by chihiron1.nc.neustar.com with ESMTP id 5202942.25690952; Thu, 18 Mar 2010 18:16:50 -0400 Received: from STNTEXCHHT02.cis.neustar.com ([10.31.13.229]) by stntexch11.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Mar 2010 18:16:50 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 18 Mar 2010 18:16:49 -0400 From: "Rosen, Brian" To: "ecrit@ietf.org" Date: Thu, 18 Mar 2010 18:16:48 -0400 Thread-Topic: GPS Text in -framework Thread-Index: AcrG6LOE/3EZRp2xok+q5q2nA3Rhxg== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: Zez7X+k6Wfx/jTqxVd60eg== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Mar 2010 22:16:50.0369 (UTC) FILETIME=[B4EE0310:01CAC6E8] Subject: [Ecrit] GPS Text in -framework X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 22:16:48 -0000 In the Gen-ART review of -framework, this comment was made: Minor issues: ... the GPS stuff seems a bit USA centric (IMHO you should show the document to a GPS (or Galileo :-) expert). I believe the GPS stuff is accurate, and a number of you are GPS expert enough to agree. Does anyone have any concerns about this? Brian From Martin.Thomson@andrew.com Thu Mar 18 16:01:33 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 219F93A6952 for ; Thu, 18 Mar 2010 16:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.546 X-Spam-Level: X-Spam-Status: No, score=-0.546 tagged_above=-999 required=5 tests=[AWL=-1.677, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 6HiUnGdAexqe for ; Thu, 18 Mar 2010 16:01:32 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 083523A6BB6 for ; Thu, 18 Mar 2010 16:01:32 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:38932 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S14933421Ab0CRXBn (ORCPT ); Thu, 18 Mar 2010 18:01:43 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 18 Mar 2010 18:01:43 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 19 Mar 2010 07:01:41 +0800 From: "Thomson, Martin" To: "Rosen, Brian" , "ecrit@ietf.org" Date: Fri, 19 Mar 2010 07:02:56 +0800 Thread-Topic: GPS Text in -framework Thread-Index: AcrG6LOE/3EZRp2xok+q5q2nA3RhxgAAY3Mw Message-ID: <8B0A9FCBB9832F43971E38010638454F03E0A3059D@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Ecrit] GPS Text in -framework X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 23:01:33 -0000 SSdsbCBhc3N1bWUgdGhhdCB0aGlzIG1haW5seSByZWZlcnMgdG8gJDYuMi4zLg0KDQpHaXZlbiB0 aGF0IEdsb25hc3MgaXMgaW4gc2VydmljZSwgdGhpcyBpcyBhIGZhaXIgY29tbWVudC4gIFRob3Vn aCB0aGUgdGV4dCBkb2VzIG1lbnRpb24gInNpbWlsYXIgc2F0ZWxsaXRlIGJhc2VkIFsuLi5dIHJl Y2VpdmVycyIgaXQgY291bGQgY2VydGFpbmx5IGJlIG1hZGUgbW9yZSBnZW5lcmljLg0KDQpJbiBv dGhlciBmb3J1bXMsIHRoZSB0ZXJtIEdsb2JhbCBOYXZpZ2F0aW9uIFNhdGVsbGl0ZSBTeXN0ZW0g KEdOU1MpIGlzIHVzZWQgaW5zdGVhZCBvZiBHUFMuICBUaGlzIGNvdmVycyBHUFMsIEdhbGlsZW8s IEdsb25hc3MsIGFuZCBDb21wYXNzIChCZWlkb3UpLCBwbHVzIGFueSBwb3RlbnRpYWwgZnV0dXJl IHN5c3RlbS4gIFRoZXJlIGFyZSBhbHNvIGEgbnVtYmVyIG9mIHJlZ2lvbmFsIHNhdGVsbGl0ZSBu YXZpZ2F0aW9uIHN5c3RlbXMgdGhhdCB1c3VhbGx5IGRvbid0IGdldCBhIGxvdCBvZiBtZW50aW9u IGluIGludGVybmF0aW9uYWwgc3RhbmRhcmRzLiAgQW5kIHlvdSB3b25kZXIgd2h5IHRoZXJlJ3Mg Y29uY2VybiBhYm91dCBzcGFjZSBqdW5rLi4uDQoNCldBQVMgaXMgZGVmaW5pdGVseSBzcGVjaWZp YyB0byBOb3J0aCBBbWVyaWNhLiAgVGhlIGRlc2NyaXB0aW9uIG9mIFdBQVMgYXMgcHJvdmlkaW5n IGVxdWl2YWxlbnQgZnVuY3Rpb24gdG8gQS1HUFMgaXMgbm90IGVudGlyZWx5IGluY29ycmVjdCwg YnV0IGNlcnRhaW5seSBtaXNsZWFkaW5nLiAgV0FBUyBwcm92aWRlcyBhY2N1cmFjeSBhdWdtZW50 YXRpb247IHRoZSBhbmFsb2d1ZSAodGhvdWdoIG5vdCBlcXVpdmFsZW50KSBpbiBhc3Npc3RlZCBH UFMgaXMgZGlmZmVyZW50aWFsIEdQUy4gIEknZCByZW1vdmUgYW55IG1lbnRpb24gb2YgV0FBUywg dW5sZXNzIHlvdSBhbHNvIGludGVuZCB0byBpbmNsdWRlIEVHTk9TIGFuZCBvdGhlciByZWdpb25h bCBhdWdtZW50YXRpb24gc3lzdGVtcy4NCg0KV2hpbGUgeW91J3JlIG1ha2luZyB0aGlzIGxlc3Mt c3BlY2lmaWMsIHRoaXMgcHJvYmFibHkgc2hvdWxkIGJlIHRha2VuIGZ1cnRoZXIuICBUaGVyZSBp cyBhbiBpbXBsaWVkIGFzc3VtcHRpb24gdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQgdGhhdCBzZWxm LWRldGVybWluZWQgbG9jYXRpb24gPT0gR1BTLiAgVGhpcyBpcyBub3QgdHJ1ZS4gIFRvIG1ha2Ug dGhpcyBzZWN0aW9uIGV2ZW4gbGVzcyBzcGVjaWZpYyB0byBhIHBhcnRpY3VsYXIgdGVjaG5vbG9n eSwgeW91IHdvdWxkIHJlZmVyIHRvIGRldmljZSBhdXRvbm9tb3VzIHBvc2l0aW9uaW5nLCB3aGlj aCBpbmNsdWRlcyBHTlNTLCBidXQgYWxzbyBpbmNsdWRlcyByZWdpb25hbCBzYXRlbGxpdGUgbmF2 aWdhdGlvbiBzeXN0ZW1zIGFzIHdlbGwgYXMgb3RoZXIgYXV0b25vbW91cyBzeXN0ZW1zLCBzdWNo IGFzIExPUkFOIG9yIHRob3NlIHRoYXQgdXNlIG90aGVyIHNpZ25hbHMgKGkuZS4gZGlnaXRhbCB0 ZWxldmlzaW9uIGJyb2FkY2FzdCkuICBJbmVydGlhbCBzeXN0ZW1zIHRoYXQgdXNlIGEgcHJldmlv dXMgbmV0d29yay1kZXRlcm1pbmVkIHNlZWQgbWlnaHQgYWxzbyBmYWxsIGludG8gdGhpcyBjYXRl Z29yeS4NCg0KKEkgYWxzbyBub3RlIHRoYXQgdGhlIHdvcmQgdHJpYW5ndWxhdGlvbiBpcyB1c2Vk IGluIHRoZSBuZXh0IHNlY3Rpb24uICBUaGlzIGNhbiBiZSB1c2VkLCBidXQgZHVlIHRvIHRoZSBu ZWVkIGZvciBzcGVjaWFsaXplZCBhbnRlbm5hZSwgaXQgaXNuJ3Qgb2Z0ZW4uICBNb3JlIG9mdGVu LCB0cmlsYXRlcmF0aW9uIC0gbW9yZSBjb3JyZWN0bHksIG11bHRpbGF0ZXJhdGlvbiAtIGlzIHVz ZWQsIGVzcGVjaWFsbHkgZm9yIHRoZSBjYXNlcyB0aGF0IGFyZSBjaXRlZCwgZXhjZXB0IEFvQS4p DQoNCi0tTWFydGluDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBl Y3JpdC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmDQo+IE9mIFJvc2VuLCBCcmlhbg0KPiBTZW50OiBGcmlkYXksIDE5IE1hcmNoIDIwMTAg OToxNyBBTQ0KPiBUbzogZWNyaXRAaWV0Zi5vcmcNCj4gU3ViamVjdDogW0Vjcml0XSBHUFMgVGV4 dCBpbiAtZnJhbWV3b3JrDQo+IA0KPiBJbiB0aGUgR2VuLUFSVCByZXZpZXcgb2YgLWZyYW1ld29y aywgdGhpcyBjb21tZW50IHdhcyBtYWRlOg0KPiBNaW5vciBpc3N1ZXM6IC4uLiB0aGUgR1BTIHN0 dWZmIHNlZW1zIGEgYml0IFVTQSBjZW50cmljIChJTUhPIHlvdQ0KPiBzaG91bGQNCj4gc2hvdyB0 aGUgZG9jdW1lbnQgdG8gYSBHUFMgKG9yIEdhbGlsZW8gOi0pIGV4cGVydCkuDQo+IA0KPiBJIGJl bGlldmUgdGhlIEdQUyBzdHVmZiBpcyBhY2N1cmF0ZSwgYW5kIGEgbnVtYmVyIG9mIHlvdSBhcmUg R1BTIGV4cGVydA0KPiBlbm91Z2ggdG8gYWdyZWUuICBEb2VzIGFueW9uZSBoYXZlIGFueSBjb25j ZXJucyBhYm91dCB0aGlzPw0KPiANCj4gQnJpYW4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEVjcml0IG1haWxpbmcgbGlzdA0KPiBFY3Jp dEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0 DQo= From hgs@cs.columbia.edu Fri Mar 19 10:14:33 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 031C73A68C0 for ; Fri, 19 Mar 2010 10:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 YtBMyop4iU8O for ; Fri, 19 Mar 2010 10:14:32 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id E7F473A6BCB for ; Fri, 19 Mar 2010 10:12:01 -0700 (PDT) Received: from [10.2.0.145] ([12.175.186.2]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o2JHCBr2007047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 19 Mar 2010 13:12:13 -0400 (EDT) References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne Date: Fri, 19 Mar 2010 13:12:11 -0400 To: "Rosen, Brian" X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] GPS Text in -framework X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 17:14:33 -0000 Brian, Are you referring to the discussion we had? So far, I've only heard you = nention no-name, unidentified experts that may or may not be talking = about today's post-SA system, with no citations, while I provided = citations that at least cast doubts on the statement provided. But maybe = I missed some clarifying email? Henning On Mar 18, 2010, at 6:16 PM, Rosen, Brian wrote: > In the Gen-ART review of -framework, this comment was made: > Minor issues: ... the GPS stuff seems a bit USA centric (IMHO you = should > show the document to a GPS (or Galileo :-) expert). >=20 > I believe the GPS stuff is accurate, and a number of you are GPS = expert > enough to agree. Does anyone have any concerns about this? >=20 > Brian >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From br@brianrosen.net Fri Mar 19 10:37:26 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 1D6873A6956 for ; Fri, 19 Mar 2010 10:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=-0.481, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 MwIx5BOybYkN for ; Fri, 19 Mar 2010 10:37:25 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id 2B3A23A68FA for ; Fri, 19 Mar 2010 10:37:25 -0700 (PDT) Received: from [209.173.57.233] (helo=[192.168.130.63]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nsg8W-0001RY-6B; Fri, 19 Mar 2010 12:37:28 -0500 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Fri, 19 Mar 2010 13:37:31 -0400 From: Brian Rosen To: Henning Schulzrinne , Brian Rosen Message-ID: Thread-Topic: [Ecrit] GPS Text in -framework Thread-Index: AcrHitn6KlNi9KNKg0SJbu8gB7p7Eg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] GPS Text in -framework X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 17:37:26 -0000 No, this was not the "accuracy" text. This is an overall comment about GPS-specific, rather than GSN general text. Martin provided some helpful comments, which I will incorporate. I think the best way forward is to remove the accuracy text. While I'm convinced the statements in the text are correct (post-SA), I don't have the time to go look up the records that underlie the latest work done on accuracy for the U.S. Regulatory effort. Your citations are open field, and I believe long duration tests that don't represent emergency calling. However, rather than fight, I think we can just delete. Brian On 3/19/10 1:12 PM, "Henning Schulzrinne" wrote: > Brian, > > Are you referring to the discussion we had? So far, I've only heard you > nention no-name, unidentified experts that may or may not be talking about > today's post-SA system, with no citations, while I provided citations that at > least cast doubts on the statement provided. But maybe I missed some > clarifying email? > > Henning > > On Mar 18, 2010, at 6:16 PM, Rosen, Brian wrote: > >> In the Gen-ART review of -framework, this comment was made: >> Minor issues: ... the GPS stuff seems a bit USA centric (IMHO you should >> show the document to a GPS (or Galileo :-) expert). >> >> I believe the GPS stuff is accurate, and a number of you are GPS expert >> enough to agree. Does anyone have any concerns about this? >> >> Brian >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From mlinsner@cisco.com Sun Mar 21 20:45:59 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BDC63A68B0 for ; Sun, 21 Mar 2010 20:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.469 X-Spam-Level: X-Spam-Status: No, score=-9.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZfS2fqQtQRf for ; Sun, 21 Mar 2010 20:45:58 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id CB06F3A6821 for ; Sun, 21 Mar 2010 20:45:58 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKWEpkurRN+J/2dsb2JhbACbOm0GohKXXIR9BIMe X-IronPort-AV: E=Sophos;i="4.51,285,1267401600"; d="scan'208";a="247507702" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 22 Mar 2010 03:46:15 +0000 Received: from [130.129.25.146] (sjc-vpn7-513.cisco.com [10.21.146.1]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o2M3kF3N025945 for ; Mon, 22 Mar 2010 03:46:15 GMT User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Sun, 21 Mar 2010 20:46:15 -0700 From: Marc Linsner To: "ecrit@ietf.org" Message-ID: Thread-Topic: [Ecrit] Presentations Thread-Index: AcrGmRbmVh2cv74EikW4hXC2WQmGNAC2SHqt In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [Ecrit] FW: Presentations 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, 22 Mar 2010 03:45:59 -0000 We're still missing some presentations! ------ Forwarded Message From: Marc Linsner Date: Thu, 18 Mar 2010 08:46:55 -0400 To: "ecrit@ietf.org" Subject: [Ecrit] Presentations If you presenting in ECRIT, please send your preso to the Roger (RMarshall@telecomsys.com). We meet first thing Monday - 9AM! Thanks, -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------ End of Forwarded Message From Hannes.Tschofenig@gmx.net Mon Mar 22 07:35:20 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3623A68D1 for ; Mon, 22 Mar 2010 07:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.575 X-Spam-Level: X-Spam-Status: No, score=0.575 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] 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 sluNpo2TqZ4q for ; Mon, 22 Mar 2010 07:35:20 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 801ED3A68D9 for ; Mon, 22 Mar 2010 07:35:02 -0700 (PDT) Received: (qmail invoked by alias); 22 Mar 2010 14:35:18 -0000 Received: from dhcp-wireless-open-abg-24-115.meeting.ietf.org (EHLO [130.129.24.115]) [130.129.24.115] by mail.gmx.net (mp015) with SMTP; 22 Mar 2010 15:35:18 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18byRosvaobuVe74tdkViKMoF6cP3PtqrOOkpy/0I y4kPmBo9ThSE4j Message-ID: <4BA7800A.4040406@gmx.net> Date: Mon, 22 Mar 2010 10:34:50 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: 'ECRIT' , GEOPRIV Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59999999999999998 Subject: [Ecrit] [Fwd: Re: [earlywarning] Informal Gathering at IETF#77] 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, 22 Mar 2010 14:35:20 -0000 Some of you might be interested in this activity. -------- Original Message -------- Subject: Re: [earlywarning] Informal Gathering at IETF#77 Date: Mon, 22 Mar 2010 10:28:53 -0400 From: Hannes Tschofenig To: earlywarning@ietf.org References: <4B921797.3070607@gmx.net> Hi all, I got a few responses to my mail and hence I would propose to meet on Wednesday from 13:00 to 15:00. I will try to find a room. We would be working on the charter text. Ciao Hannes Hannes Tschofenig wrote: > Hi all, > > the IETF#77 meeting is getting closer and I was wondering whether some > of you would like to get together to chat about the charter text. We, > for some reason, got a bit struck with the wording of the charter. > > Drop me a mail if you are interested to chat about this topic! > > Ciao > Hannes > > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From jmpolk@cisco.com Mon Mar 22 09:19:22 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 1994D28C11F; Mon, 22 Mar 2010 09:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.752 X-Spam-Level: X-Spam-Status: No, score=-9.752 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvLpRdIFBsrL; Mon, 22 Mar 2010 09:19:21 -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 5682628C103; Mon, 22 Mar 2010 09:19:21 -0700 (PDT) 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: AvsEAFI1p0urR7H+/2dsb2JhbACbJHOjWZgZgkSCOQSDHg X-IronPort-AV: E=Sophos;i="4.51,288,1267401600"; d="scan'208";a="500775132" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 22 Mar 2010 16:19:39 +0000 Received: from jmpolk-wxp01.cisco.com (sjc-vpn5-1268.cisco.com [10.21.92.244]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2MGJc2G006891; Mon, 22 Mar 2010 16:19:39 GMT Message-Id: <201003221619.o2MGJc2G006891@sj-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 22 Mar 2010 11:19:38 -0500 To: Hannes Tschofenig , "'ECRIT'" , GEOPRIV From: "James M. Polk" In-Reply-To: <4BA7800A.4040406@gmx.net> References: <4BA7800A.4040406@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Ecrit] [Geopriv] [Fwd: Re: [earlywarning] Informal Gathering at IETF#77] 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, 22 Mar 2010 16:19:22 -0000 Some might also be attending TSVAREA (Wed 1300-1500) who has a mini-BoF on RSVP's future in the IETF. I at least will be in that meeting -- as will several ADs interested in this topic. James At 09:34 AM 3/22/2010, Hannes Tschofenig wrote: >Some of you might be interested in this activity. > >-------- Original Message -------- >Subject: Re: [earlywarning] Informal Gathering at IETF#77 >Date: Mon, 22 Mar 2010 10:28:53 -0400 >From: Hannes Tschofenig >To: earlywarning@ietf.org >References: <4B921797.3070607@gmx.net> > > > >Hi all, > >I got a few responses to my mail and hence I would propose to meet >on Wednesday from 13:00 to 15:00. I will try to find a room. > >We would be working on the charter text. > >Ciao >Hannes > >Hannes Tschofenig wrote: >>Hi all, >> >>the IETF#77 meeting is getting closer and I was wondering whether >>some of you would like to get together to chat about the charter >>text. We, for some reason, got a bit struck with the wording of the charter. >> >>Drop me a mail if you are interested to chat about this topic! >> >>Ciao >>Hannes >> >>_______________________________________________ >>earlywarning mailing list >>earlywarning@ietf.org >>https://www.ietf.org/mailman/listinfo/earlywarning > > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www.ietf.org/mailman/listinfo/geopriv From Ray.Bellis@nominet.org.uk Mon Mar 22 10:20:32 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 4D7AA3A6A2A for ; Mon, 22 Mar 2010 10:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.957 X-Spam-Level: X-Spam-Status: No, score=-3.957 tagged_above=-999 required=5 tests=[AWL=-1.089, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 JXVvXkAANcGV for ; Mon, 22 Mar 2010 10:20:30 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 735C93A696E for ; Mon, 22 Mar 2010 10:20:30 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:To:Subject:MIME-Version:X-Mailer: Message-ID:From:Date:X-MIMETrack:Content-Type; b=ssAU1auSDKMpd7LssTPOsEnW8cOZXCRDrzUdGnRw1+QqIzAMmGV6cfH4 kWalyUsLSlRtiIyT44Olxy+9ocdlrn1T/4FZwvNYtxV3CAimz/4HhDfcM toK6QMKyrcM/oq9; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269278448; x=1300814448; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20ISPs=20and =20LIS=20requirements|Date:=20Mon,=2022=20Mar=202010=2009 :20:44=20-0800|Message-ID:=20|To:=20ecri t=20|MIME-Version:=201.0; bh=/zxPHzjyQ3pKT6HarbuEdl4xQjaetSJGUy3jouUmhfU=; b=uk4UO/LtNvnuxClxErn8dx33WalXUX+tSoudGE3Yfpk/wnvRdL3ur0UX B0+cVA/lVtSYeve6k4gqijjKSNm7onXBThYtuhXQbWH1A9BILsOkMDPDG CPYaJthB3ikXG7n; X-IronPort-AV: E=Sophos;i="4.51,289,1267401600"; d="scan'208";a="17256537" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 22 Mar 2010 17:20:46 +0000 To: ecrit MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Mon, 22 Mar 2010 09:20:44 -0800 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 22/03/2010 05:20:46 PM, Serialize complete at 22/03/2010 05:20:46 PM Content-Type: multipart/alternative; boundary="=_alternative 005F4886882576EE_=" Subject: [Ecrit] ISPs and LIS requirements 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, 22 Mar 2010 17:20:32 -0000 This is a multipart message in MIME format. --=_alternative 005F4886882576EE_= Content-Type: text/plain; charset="US-ASCII" To back up what James W just said at the mic: The proposed UK model for emergency service access over VoIP depends on each ISP running a LIS and that LIS permitting queries from the PSAP. It's my belief that this will be enshrined in UK law via the introduction by OFCOM of a new "General Condition of Service" which will apply to any public telecommunications provider, including pure IP access providers. Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 005F4886882576EE_= Content-Type: text/html; charset="US-ASCII" To back up what James W just said at the mic:

The proposed UK model for emergency service access over VoIP depends on each ISP running a LIS and that LIS permitting queries from the PSAP.

It's my belief that this will be enshrined in UK law via the introduction by OFCOM of a new "General Condition of Service" which will apply to any public telecommunications provider, including pure IP access providers.

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211
 --=_alternative 005F4886882576EE_=-- From dirk.kroeselberg@nsn.com Mon Mar 22 10:23:26 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 D613228C12E for ; Mon, 22 Mar 2010 10:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 DRVpRjQpqJon for ; Mon, 22 Mar 2010 10:23:25 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 3F5CC3A6A2A for ; Mon, 22 Mar 2010 10:22:59 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2MHNCMQ008372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Mar 2010 18:23:12 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2MHNC5O005960; Mon, 22 Mar 2010 18:23:12 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 18:23:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Mar 2010 18:22:08 +0100 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net> In-Reply-To: <201003221619.o2MGJc2G006891@sj-core-2.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: emergency access and EAP-TLS Thread-Index: AcrJ23u49i+U7AGbQJCsAYZdKEfaygABnvbw References: <4BA7800A.4040406@gmx.net> <201003221619.o2MGJc2G006891@sj-core-2.cisco.com> From: "Kroeselberg, Dirk (NSN - DE/Munich)" To: "Bernard Aboba" X-OriginalArrivalTime: 22 Mar 2010 17:23:11.0859 (UTC) FILETIME=[5921BC30:01CAC9E4] Cc: ECRIT Subject: [Ecrit] emergency access and EAP-TLS 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, 22 Mar 2010 17:23:27 -0000 Bernard,=20 continuing discussion from this morning's session: RFC5216 only seems to have the following statement for unauthenticated emergency access: "While the EAP server SHOULD require peer authentication, this is not mandatory, since there are circumstances in which peer authentication will not be needed (e.g., emergency services, as described in [UNAUTH]), or where the peer will authenticate via some other means." This is good and there is no reason to deviate from that. But it would not be sufficient on its own to indicate emergency. So what else is in existing RFCs that could be used (instead of the NAI options presented in the unauthenticated draft)? Thanks, Dirk From bernard_aboba@hotmail.com Mon Mar 22 10:28:36 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1607E3A69B5; Mon, 22 Mar 2010 10:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.259 X-Spam-Level: X-Spam-Status: No, score=0.259 tagged_above=-999 required=5 tests=[AWL=-0.873, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 2z9Tdf8EXulR; Mon, 22 Mar 2010 10:28:24 -0700 (PDT) Received: from blu0-omc3-s37.blu0.hotmail.com (blu0-omc3-s37.blu0.hotmail.com [65.55.116.112]) by core3.amsl.com (Postfix) with ESMTP id A12053A6945; Mon, 22 Mar 2010 10:28:23 -0700 (PDT) Received: from BLU137-DS5 ([65.55.116.74]) by blu0-omc3-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 10:28:41 -0700 X-Originating-IP: [130.129.27.170] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: , Date: Mon, 22 Mar 2010 10:29:11 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01CAC9AA.834AEF70" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrJ5S9V+44Ade6BSs+9gZS1IXfNYg== Content-Language: en-us X-OriginalArrivalTime: 22 Mar 2010 17:28:41.0088 (UTC) FILETIME=[1D5E1800:01CAC9E5] Subject: [Ecrit] Review of draft-schulzrinne-ecrit-unauthenticated-access-07.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, 22 Mar 2010 17:28:36 -0000 ------=_NextPart_000_0004_01CAC9AA.834AEF70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Looking over -07, it does not appear that the review comments on -06 were addressed. In addition, the presentation to ECRIT today referred to "no objections" to use of a decorated NAI to signal emergency usage. It's not clear to me why this is necessary (e.g. why use of an "emergency" user name wouldn't work), or whether the implications for deployment are understood, given that decoration may require specialized proxy handling and potential changes to AAA servers. By referring to use of non-existent domains (e.g. emergency.com) and a requirement for new EAP methods, and now adding a decorated NAI requirement, this draft is creating unnecessary barriers to gaining network access for the purposes of making an emergency call. I'd suggest that the document rethink the approach, and focus on enabling unauthenticated emergency access with as few changes to existing standards as possible. -----Original Message----- Joe Salowey said: "I agree with Bernard's comments on section 6 of this draft. I would like to emphasize the following: - I'm a bit concerned about using an EAP method type to indicate emergency authentication. The EAP method type should be orthogonal to whether emergency access is requested or not. Combining the two will cause and artificial linkages between the two and likely cause problems down the road. For this reason I am strongly against options 2.a and 2.c in section 6.2. - In section 6.3, I don't think that anonymous cipher suites or publically known shared keys are a good idea. In general, a server authenticated method using public key certificates can be used. If the client is in an emergency it can forgo certificate validation to get access. If it knows the trust root then it can validate it." -----Original Message----- From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, November 10, 2009 5:41 PM To: 'ECRIT' Subject: [Ecrit] Comments on Section 6 of draft-schulzrinne-ecrit-unauthenticated-access Section 6 " signaling allows an IEEE 802.1X to occur without exchanging cryptogrpahic keys" [BA] Not sure what this is saying. In IEEE 802.1X-2004, there is no encryption supported. However, EAP is still run. This can include methods that don't generate keys (e.g. EAP-MD5). But the issue here is client unauthenticated access, not key generation, right? Section 6.1 " In general, link layer emergency indications provide good integration into the actual network access procedure regarding the enabling of means to recognize and prioritize an emergency service request from an end host at a very early stage of the network attachment procedure. However, support in end hosts for such methods cannot be considered to be commonly available." [BA] I'm not sure what this is referring to. If it's referring to QoS, those mechanisms are independent of emergency indications (e.g. WFA WMM). If it's talking about higher layer emergency service prioritization, that's also independent of the lower layer. So what exactly is a host expected to do at the lower layer to distinguish an emergency call? Section 6.2 "In normal operation, EAP related information will only be recognized in the NAS. Any entity residing between end host and NAS should not be expected to understand/parse EAP messages." [BA] The EAP architecture requires the NAS to be EAP-method agnostic if it's acting as a pass-through. So even the NAS can't be depended upon to understand/parse EAP methods. But why would it need to? " 1.b) Emergency NAI: The NAI comes with a realm or username part indicating emergency (e.g. 'emergency at emergency.com'). An advantage of this method for NAA cases is that no new requirements are put on the involved signaling procedures. Only the identity used for network entry is impacted. Potential disadvantages include that different methods to indicate emergency for NAA cases and standard emergency network attachments may be required. Also, modifying the NAI itself (the username at realm part) may conflict with network selection and network entry procedures, depending on the actual access network." [BA] There are two distinct ideas being presented here. One is to define an emergency user name (e.g. "emergency"); another is to define an emergency domain (e.g. "emergency.com"). The former concept may make sense, but the latter one is dangerous since existing systems not including the emergency realm in their routing tables may just return an error. So the question is what realm should be used, if any. The problem with including any realm is that it assumes realm reachability. If reachability doesn't exist, then the host will get an error. If there is no realm, then the local realm needs to recognize the emergency username, and utilize an appropriate EAP method that allows client unauthenticated access. > " 2) Emergency EAP method An emergency indication can be given by using a dedicated EAP method that is reserved for emergency network attachment only." [BA] Why is a dedicated EAP method needed for emergency access? EMU WG has already discussed this and come up with mechanisms that would allow client unauthenticated access from any TLS-based method (e.g. server side either doesn't ask for a client cert, or accepts the client not providing one). That mechanism is supported in RFC 5216, and can also be applied to existing methods such as EAP FAST, EAP TTLSv0, PEAP, etc. In effect, the only real constraint here is that a local network advertising support for emergency calling needs to support one or more of these methods. " 2.a) Existing EAP method with new type: An existing EAP method may be used. EAP methods themselves typically do not support emergency indication. One option would be to pick a common EAP method like EAP-TLS and allocate a new method type for the same method that is exclusively reserved to emergency use. Such EAP method should be chosen in a way that the same method can support NAA cases as well as standard emergency network attachment." > Given that RFC 5216 already supports client-unauthenticated anonymous access (see Sections 2.1.4 and 2.2), why is it necessary to request allocation of a new method type? " 2.b) Existing EAP method: Same as 2a), but without assigning a new EAP method type for emergency. In this case some implicit indication must be used. For example, in cases where EAP-TLS is used in network attachment in combination with client certificates, the absence of a client certificate could be interpreted by the network as a request for emergency network attachment." > [BA] The combination of an emergency NAI *and* the absence of a client certificate would be considered a request for emergency attachment. If an NAI corresponding to an existing account is used, then normal policies will apply (which would probably require authenticated access). " 2.c) Emergency EAP method: A new EAP method could be defined that is specifically designed for emergency network entry in NAA cases. Most likely, such EAP method would not be usable for standard emergency network attachment with an existing subscription. Such dedicated emergency EAP method should be key-generating in compliance with RFC3748 IEEE 802.1ar might also be an example of this. ------=_NextPart_000_0004_01CAC9AA.834AEF70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Looking over -07, it does not appear that the = review comments on -06 were addressed.

 

In addition, the presentation to ECRIT today = referred to “no objections” to use of a decorated NAI to signal emergency usage. =

 

It’s not clear to me why this is necessary = (e.g. why use of an “emergency” user name wouldn’t work), or = whether the implications for deployment are understood, given that decoration = may require specialized proxy handling and potential changes to AAA servers. =

 

By referring to use of non-existent domains (e.g. emergency.com) and a requirement for new EAP methods, and now adding a decorated NAI requirement, this draft is creating unnecessary barriers = to gaining network access for the purposes of making an emergency = call.  I’d suggest that the document rethink the approach, and focus on enabling unauthenticated emergency access with as few changes to existing = standards as possible.

 

-----Original Message-----

 Joe Salowey said:

 

“I agree with Bernard's comments on section 6 of this =
draft.  
 
I would =
like to emphasize the =
following:
 
- I'm a bit =
concerned about using an EAP method type to =
indicate
emergency authentication.  The EAP =
method type should be orthogonal to
whether =
emergency access is requested or not.  Combining the two =
will
cause and artificial linkages between the two =
and likely cause problems
down the road.  For =
this reason I am strongly against options 2.a =
and
2.c in section =
6.2.
 
- In section 6.3, =
I don't think that anonymous cipher suites =
or
publically known shared keys are a good =
idea.  In general, a server
authenticated =
method using public key certificates can be used.  If =
the
client is in an emergency it can forgo =
certificate validation to get
access.  If it =
knows the trust root then it can validate =
it.”
 
-----Original=
 Message-----
From: ecrit-bounces at ietf.org =
[mailto:ecrit-bounces at ietf.org] On Behalf Of Bernard =
Aboba
Sent: Tuesday, November 10, 2009 5:41 =
PM
To: 'ECRIT'
Subject: =
[Ecrit] Comments on Section 6 of =
draft-schulzrinne-ecrit-unauthenticated-access
=
 
Section =
6
 
"  =
signaling allows an IEEE 802.1X to occur without =
exchanging
   cryptogrpahic =
keys"
 
[BA] Not =
sure what this is saying.  In IEEE 802.1X-2004, there is =
no
encryption supported.  However, EAP is =
still run.  This can include
methods that =
don't generate keys (e.g. EAP-MD5).  But the issue here =
is
client unauthenticated access, not key =
generation, =
right?
 
Section =
6.1
 
"  In =
general, link layer emergency indications provide good =
integration
   into the actual network =
access procedure regarding the enabling =
of
   means to recognize and prioritize =
an emergency service request from
   an =
end host at a very early stage of the network =
attachment
   procedure.  However, =
support in end hosts for such methods cannot =
be
   considered to be commonly =
available."
 
[BA] =
I'm not sure what this is referring to.  If it's referring to =
QoS,
those mechanisms are independent of emergency =
indications (e.g. WFA WMM).
If it's talking about =
higher layer emergency service =
prioritization,
that's also independent of the =
lower layer.  So what exactly is a =
host
expected to do at the lower layer to =
distinguish an emergency =
call?
 
Section =
6.2
 
"In normal =
operation, EAP related information will only be recognized =

in the NAS.  Any entity residing between end =
host and NAS should not 
be expected to =
understand/parse EAP =
messages."
 
[BA] =
The EAP architecture requires the NAS to be EAP-method agnostic =
if
it's acting as a pass-through.  So even the =
NAS can't be depended upon to
understand/parse EAP =
methods.  But why would it need =
to?
 
"   =
1.b) Emergency NAI: The NAI comes with a realm or username =
part
   indicating emergency (e.g. =
'emergency at emergency.com').  An =
advantage
   of this method for NAA cases =
is that no new requirements are put on
   =
the involved signaling procedures.  Only the identity used =
for
   network entry is impacted.  =
Potential disadvantages include that
   =
different methods to indicate emergency for NAA cases and =
standard
   emergency network attachments =
may be required.  Also, modifying =
the
   NAI itself (the username at realm =
part) may conflict with network
   =
selection and network entry procedures, depending on the =
actual
   access =
network."
 
[BA] =
There are two distinct ideas being presented here.  One is to =
define
an emergency user name (e.g. =
"emergency"); another is to define =
an
emergency domain (e.g. =
"emergency.com").  The former concept may =
make
sense, but the latter one is dangerous since =
existing systems not
including the emergency realm =
in their routing tables may just return =
an
error.  So the question is what realm =
should be used, if any.  The problem
with =
including any realm is that it assumes realm reachability.  =
If
reachability doesn't exist, then the host will =
get an error.  If there is
no realm, then the =
local realm needs to recognize the emergency =
username,
and utilize an appropriate EAP method =
that allows client =
unauthenticated
access.
> 
"   2) Emergency EAP method =

   An emergency indication can be =
given by using a dedicated EAP method
   =
that is reserved for emergency network attachment =
only."
 
[BA] Why is =
a dedicated EAP method needed for emergency access?  EMU =
WG
has already discussed this and come up with =
mechanisms that would allow
client unauthenticated =
access from any TLS-based method (e.g. server =
side
either doesn't ask for a client cert, or =
accepts the client not providing
one).  That =
mechanism is supported in RFC 5216, and can also be applied =
to
existing methods such as EAP FAST, EAP TTLSv0, =
PEAP, etc.
 
In effect, =
the only real constraint here is that a local =
network
advertising support for emergency calling =
needs to support one or more
of these =
methods.
 
"  =
 2.a) Existing EAP method with new type: An existing EAP method may =
be
   used.  EAP methods themselves =
typically do not support emergency
   =
indication.  One option would be to pick a common EAP method =
like
   EAP-TLS and allocate a new method =
type for the same method that is
   =
exclusively reserved to emergency use.  Such EAP method should =
be
   chosen in a way that the same =
method can support NAA cases as well =
as
   standard emergency network =
attachment."
> 
Gi=
ven that RFC 5216 already supports client-unauthenticated =
anonymous
access (see Sections 2.1.4 and 2.2), why =
is it necessary to request
allocation of a new =
method =
type?
 
"  =
 2.b) Existing EAP method: Same as 2a), but without assigning a =
new
   EAP method type for =
emergency.  In this case some implicit =
indication
   must be used.  For =
example, in cases where EAP-TLS is used in =
network
   attachment in combination with =
client certificates, the absence of a
   =
client certificate could be interpreted by the network as a =
request
   for emergency network =
attachment."
> 
[B=
A] The combination of an emergency NAI *and* the absence of a =
client
certificate would be considered a request =
for emergency attachment. If an
NAI corresponding =
to an existing account is used, then normal =
policies
will apply (which would probably require =
authenticated =
access).
 
" &nb=
sp; 2.c) Emergency EAP method: A new EAP method could be defined that =
is
   specifically designed for emergency =
network entry in NAA cases. Most
   =
likely, such EAP method would not be usable for standard =
emergency
   network attachment with an =
existing subscription.  Such =
dedicated
   emergency EAP method should =
be key-generating in compliance with
   =
RFC3748 <http://tools.ietf.org/html/rfc3748 to enable the regular =
air
interface security methods even in =
unauthenticated =
operation."
 
[BA] =
Since any TLS-based method can potentially support =
client-
unauthenticated access, it's not clear to =
me that there is a good case for
creating yet =
another method.
 
Section =
6.3
 
"   =
Therefore, for network attachment that is by default based on =
EAP
   authentication it is desirable =
also for NAA network attachment to use
   =
a key-generating EAP method (that provides an MSK key to =
the
   authenticator to bootstrap further =
key derivation for protecting the
   =
wireless =
link)."
 
[BA] Where =
key generation is required (e.g. WPA/WPA2 enterprise) you =
don't
really have a =
choice.
 
" &nbs=
p; 2) Null authentication: an EAP method is performed.  However, =
no
   credentials specific to either the =
server or the device or
   subscription =
are used as part of the authentication exchange.  =
An
   example for this would be an =
EAP-TLS exchange with using the
   =
TLS_DH_anon (anonymous) ciphersuite.  Alternatively, a =
publicly
   available static key for =
emergency access could be used.  In =
the
   latter case, the device would need =
to be provisioned with the
   appropriate =
emergency key for the IAP/ISP in =
advance."
 
[BA] =
WPA/WPA2 enterprise mode and PSK mode are distinct; PSK mode =
only
uses the 4-way handshake, not =
EAP.
 
"   =
3) Device authentication: This case extends the =
server-only
   authentication case.  =
If the device is configured with a =
device
   certificate and the IAP/ISP EAP =
server can rely on a trusted root
   =
allowing the EAP server to verify the device certificate, at =
least
   the device identity (e.g. the =
MAC address) can be authenticated by
   =
the IAP/ISP in NAA cases.  An example for this are WiMAX devices =
that
   are shipped with device =
certificates issued under the global =
WiMAX
   device public-key =
infrastructure.  To perform =
unauthenticated
   emergency calls, if =
allowed by the IAP/ISP, such devices perform =
EAP-
   TLS based network attachment with =
client authentication based on the
   =
device =
certificate."
> 
I=
EEE 802.1ar might also be an example of this.=
------=_NextPart_000_0004_01CAC9AA.834AEF70-- From hgs@cs.columbia.edu Mon Mar 22 10:37:15 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3E9B3A6952 for ; Mon, 22 Mar 2010 10:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 gOqyHGWmbG14 for ; Mon, 22 Mar 2010 10:37:15 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id 1B6D13A690E for ; Mon, 22 Mar 2010 10:37:15 -0700 (PDT) Received: from dhcp-wireless-open-abg-26-78.meeting.ietf.org (dhcp-wireless-open-abg-26-78.meeting.ietf.org [130.129.26.78]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o2MHbMTR027313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 22 Mar 2010 13:37:31 -0400 (EDT) From: Henning Schulzrinne Content-Type: text/plain; charset=us-ascii Message-Id: <12E8E8A5-49C0-4504-8019-C8CB644E921B@cs.columbia.edu> Date: Mon, 22 Mar 2010 13:37:21 -0400 To: ECRIT Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Subject: [Ecrit] Additional data: presence 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, 22 Mar 2010 17:37:15 -0000 We have CIPID (RFC 4482); it's obviously not quite what you're looking = for, but making it possible to use the new format as an extension of = PIDF would be useful, in my opinion. Henning= From dirk.kroeselberg@nsn.com Mon Mar 22 11:00:46 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 59B853A69F3; Mon, 22 Mar 2010 11:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 deJCr8-yNkAh; Mon, 22 Mar 2010 11:00:32 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 937D83A69A4; Mon, 22 Mar 2010 11:00:31 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2MI0j5M008621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Mar 2010 19:00:45 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2MI0jwY025617; Mon, 22 Mar 2010 19:00:45 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 19:00:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAC9E9.97BFD69E" Date: Mon, 22 Mar 2010 19:00:41 +0100 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF67025DB139@DEMUEXC030.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Review ofdraft-schulzrinne-ecrit-unauthenticated-access-07.txt Thread-Index: AcrJ5S9V+44Ade6BSs+9gZS1IXfNYgAAfAnQ References: From: "Kroeselberg, Dirk (NSN - DE/Munich)" To: "ext Bernard Aboba" , , X-OriginalArrivalTime: 22 Mar 2010 18:00:44.0411 (UTC) FILETIME=[97C1E4B0:01CAC9E9] Subject: Re: [Ecrit] [Emu] Review ofdraft-schulzrinne-ecrit-unauthenticated-access-07.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, 22 Mar 2010 18:00:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC9E9.97BFD69E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable the next update will incorporate the review comments, also those copied below. -07 does not incorporate feedback or proposals yet (e.g. 'use decoration'. Instead we took out some sections for now) because discussion is ongoing. Maybe the slides this morning were misleading, but the -07 version does not propose any specific way to indicate unauthenticated emergency to the access/ISP. So we are still in the phase of figuring out whether one of the methods is be agreable. =20 We can include the proposal to use a NAI "emergency" of course. For this, there is the question of how to indicate emergency in a non-'unauthenticated' case that uses a regular NAI. It would be good to use the same mechansims for unauthenticated and authenticated access. =20 > focus on enabling unauthenticated emergency access with as few changes to existing standards as possible. Agreed. But also my understanding from discussion up to now is that there is support for providing guidance from IETF instead of continuing to leverage proprietary methods with not providing such guidance. =20 Thanks, Dirk ________________________________ From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of ext Bernard Aboba Sent: Monday, March 22, 2010 6:29 PM To: ecrit@ietf.org; emu@ietf.org Subject: [Emu] Review ofdraft-schulzrinne-ecrit-unauthenticated-access-07.txt =09 =09 Looking over -07, it does not appear that the review comments on -06 were addressed.=20 =20 In addition, the presentation to ECRIT today referred to "no objections" to use of a decorated NAI to signal emergency usage.=20 =20 It's not clear to me why this is necessary (e.g. why use of an "emergency" user name wouldn't work), or whether the implications for deployment are understood, given that decoration may require specialized proxy handling and potential changes to AAA servers.=20 =20 By referring to use of non-existent domains (e.g. emergency.com) and a requirement for new EAP methods, and now adding a decorated NAI requirement, this draft is creating unnecessary barriers to gaining network access for the purposes of making an emergency call. I'd suggest that the document rethink the approach, and focus on enabling unauthenticated emergency access with as few changes to existing standards as possible.=20 =20 -----Original Message----- Joe Salowey said: =20 "I agree with Bernard's comments on section 6 of this draft. =20 =20 I would like to emphasize the following: =20 - I'm a bit concerned about using an EAP method type to indicate emergency authentication. The EAP method type should be orthogonal to whether emergency access is requested or not. Combining the two will cause and artificial linkages between the two and likely cause problems down the road. For this reason I am strongly against options 2.a and 2.c in section 6.2. =20 - In section 6.3, I don't think that anonymous cipher suites or publically known shared keys are a good idea. In general, a server authenticated method using public key certificates can be used. If the client is in an emergency it can forgo certificate validation to get access. If it knows the trust root then it can validate it." =20 -----Original Message----- From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, November 10, 2009 5:41 PM To: 'ECRIT' Subject: [Ecrit] Comments on Section 6 of draft-schulzrinne-ecrit-unauthenticated-access =20 Section 6 =20 " signaling allows an IEEE 802.1X to occur without exchanging cryptogrpahic keys" =20 [BA] Not sure what this is saying. In IEEE 802.1X-2004, there is no encryption supported. However, EAP is still run. This can include methods that don't generate keys (e.g. EAP-MD5). But the issue here is client unauthenticated access, not key generation, right? =20 Section 6.1 =20 " In general, link layer emergency indications provide good integration into the actual network access procedure regarding the enabling of means to recognize and prioritize an emergency service request from an end host at a very early stage of the network attachment procedure. However, support in end hosts for such methods cannot be considered to be commonly available." =20 [BA] I'm not sure what this is referring to. If it's referring to QoS, those mechanisms are independent of emergency indications (e.g. WFA WMM). If it's talking about higher layer emergency service prioritization, that's also independent of the lower layer. So what exactly is a host expected to do at the lower layer to distinguish an emergency call? =20 Section 6.2 =20 "In normal operation, EAP related information will only be recognized=20 in the NAS. Any entity residing between end host and NAS should not=20 be expected to understand/parse EAP messages." =20 [BA] The EAP architecture requires the NAS to be EAP-method agnostic if it's acting as a pass-through. So even the NAS can't be depended upon to understand/parse EAP methods. But why would it need to? =20 " 1.b) Emergency NAI: The NAI comes with a realm or username part indicating emergency (e.g. 'emergency at emergency.com'). An advantage of this method for NAA cases is that no new requirements are put on the involved signaling procedures. Only the identity used for network entry is impacted. Potential disadvantages include that different methods to indicate emergency for NAA cases and standard emergency network attachments may be required. Also, modifying the NAI itself (the username at realm part) may conflict with network selection and network entry procedures, depending on the actual access network." =20 [BA] There are two distinct ideas being presented here. One is to define an emergency user name (e.g. "emergency"); another is to define an emergency domain (e.g. "emergency.com"). The former concept may make sense, but the latter one is dangerous since existing systems not including the emergency realm in their routing tables may just return an error. So the question is what realm should be used, if any. The problem with including any realm is that it assumes realm reachability. If reachability doesn't exist, then the host will get an error. If there is no realm, then the local realm needs to recognize the emergency username, and utilize an appropriate EAP method that allows client unauthenticated access. >=20 " 2) Emergency EAP method=20 An emergency indication can be given by using a dedicated EAP method that is reserved for emergency network attachment only." =20 [BA] Why is a dedicated EAP method needed for emergency access? EMU WG has already discussed this and come up with mechanisms that would allow client unauthenticated access from any TLS-based method (e.g. server side either doesn't ask for a client cert, or accepts the client not providing one). That mechanism is supported in RFC 5216, and can also be applied to existing methods such as EAP FAST, EAP TTLSv0, PEAP, etc. =20 In effect, the only real constraint here is that a local network advertising support for emergency calling needs to support one or more of these methods. =20 " 2.a) Existing EAP method with new type: An existing EAP method may be used. EAP methods themselves typically do not support emergency indication. One option would be to pick a common EAP method like EAP-TLS and allocate a new method type for the same method that is exclusively reserved to emergency use. Such EAP method should be chosen in a way that the same method can support NAA cases as well as standard emergency network attachment." >=20 Given that RFC 5216 already supports client-unauthenticated anonymous access (see Sections 2.1.4 and 2.2), why is it necessary to request allocation of a new method type? =20 " 2.b) Existing EAP method: Same as 2a), but without assigning a new EAP method type for emergency. In this case some implicit indication must be used. For example, in cases where EAP-TLS is used in network attachment in combination with client certificates, the absence of a client certificate could be interpreted by the network as a request for emergency network attachment." >=20 [BA] The combination of an emergency NAI *and* the absence of a client certificate would be considered a request for emergency attachment. If an NAI corresponding to an existing account is used, then normal policies will apply (which would probably require authenticated access). =20 " 2.c) Emergency EAP method: A new EAP method could be defined that is specifically designed for emergency network entry in NAA cases. Most likely, such EAP method would not be usable for standard emergency network attachment with an existing subscription. Such dedicated emergency EAP method should be key-generating in compliance with RFC3748 =20 IEEE 802.1ar might also be an example of this. ------_=_NextPart_001_01CAC9E9.97BFD69E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
the=20 next update will incorporate the review comments, also those copied = below. -07=20 does not incorporate feedback or proposals yet (e.g. 'use = decoration'.=20 Instead we took out some sections for now) because discussion is = ongoing. Maybe=20 the slides this morning were misleading, but the -07 version does not = propose=20 any specific way to indicate unauthenticated emergency to the = access/ISP. So we=20 are still in the phase of figuring out whether one of the methods is be=20 agreable.
 
We can=20 include the proposal to use a NAI "emergency" of course. For this, there = is the=20 question of how to indicate emergency in a non-'unauthenticated' = case=20 that uses a regular NAI. It would be good to use the = same mechansims=20 for unauthenticated and authenticated access.
 
>=20 focus on enabling unauthenticated emergency access = with as=20 few changes to existing standards as = possible.
Agreed. But also=20 my understanding from discussion up to now is that there is = support=20 for providing guidance from IETF instead of continuing to leverage = proprietary=20 methods with not providing such guidance.
 
Thanks,
Dirk

From: emu-bounces@ietf.org=20 [mailto:emu-bounces@ietf.org] On Behalf Of ext Bernard=20 Aboba
Sent: Monday, March 22, 2010 6:29 PM
To:=20 ecrit@ietf.org; emu@ietf.org
Subject: [Emu] Review=20 = ofdraft-schulzrinne-ecrit-unauthenticated-access-07.txt

Looking over -07, it does not appear that the = review=20 comments on -06 were addressed.

 

In addition, the presentation to ECRIT today = referred to=20 “no objections” to use of a decorated NAI to signal = emergency usage.=20

 

It’s not clear to me why this is necessary = (e.g. why use of=20 an “emergency” user name wouldn’t work), or whether = the implications for=20 deployment are understood, given that decoration may require = specialized proxy=20 handling and potential changes to AAA servers.

 

By referring to use of non-existent domains (e.g. = emergency.com) and a requirement for new EAP methods, and now adding a = decorated NAI requirement, this draft is creating unnecessary barriers = to=20 gaining network access for the purposes of making an emergency = call.  I’d=20 suggest that the document rethink the approach, and focus on enabling=20 unauthenticated emergency access with as few changes to existing = standards as=20 possible.

 

-----Original =
Message-----

 Joe Salowey said:

 

“I agree with =
Bernard's comments on section 6 of this draft.  =

 
I would like to =
emphasize the =
following:
 
- I'm a bit =
concerned about using an EAP method type to =
indicate
emergency authentication.  The EAP =
method type should be orthogonal to
whether =
emergency access is requested or not.  Combining the two =
will
cause and artificial linkages between the two =
and likely cause problems
down the road.  For =
this reason I am strongly against options 2.a =
and
2.c in section =
6.2.
 
- In section 6.3, =
I don't think that anonymous cipher suites =
or
publically known shared keys are a good =
idea.  In general, a server
authenticated =
method using public key certificates can be used.  If =
the
client is in an emergency it can forgo =
certificate validation to get
access.  If it =
knows the trust root then it can validate =
it.”
 
-----Original=
 Message-----
From: ecrit-bounces at ietf.org =
[mailto:ecrit-bounces at ietf.org] On Behalf Of Bernard =
Aboba
Sent: Tuesday, November 10, 2009 5:41 =
PM
To: 'ECRIT'
Subject: =
[Ecrit] Comments on Section 6 of =
draft-schulzrinne-ecrit-unauthenticated-access
=
 
Section =
6
 
"  signaling =
allows an IEEE 802.1X to occur without =
exchanging
   cryptogrpahic =
keys"
 
[BA] Not sure =
what this is saying.  In IEEE 802.1X-2004, there is =
no
encryption supported.  However, EAP is =
still run.  This can include
methods that =
don't generate keys (e.g. EAP-MD5).  But the issue here =
is
client unauthenticated access, not key =
generation, =
right?
 
Section =
6.1
 
"  In general, =
link layer emergency indications provide good =
integration
   into the actual network =
access procedure regarding the enabling =
of
   means to recognize and prioritize =
an emergency service request from
   an =
end host at a very early stage of the network =
attachment
   procedure.  However, =
support in end hosts for such methods cannot =
be
   considered to be commonly =
available."
 
[BA] I'm =
not sure what this is referring to.  If it's referring to =
QoS,
those mechanisms are independent of emergency =
indications (e.g. WFA WMM).
If it's talking about =
higher layer emergency service =
prioritization,
that's also independent of the =
lower layer.  So what exactly is a =
host
expected to do at the lower layer to =
distinguish an emergency =
call?
 
Section =
6.2
 
"In normal =
operation, EAP related information will only be recognized =

in the NAS.  Any entity residing between end =
host and NAS should not 
be expected to =
understand/parse EAP =
messages."
 
[BA] The EAP =
architecture requires the NAS to be EAP-method agnostic =
if
it's acting as a pass-through.  So even the =
NAS can't be depended upon to
understand/parse EAP =
methods.  But why would it need =
to?
 
"   1.b) =
Emergency NAI: The NAI comes with a realm or username =
part
   indicating emergency (e.g. =
'emergency at emergency.com').  An =
advantage
   of this method for NAA cases =
is that no new requirements are put on
   =
the involved signaling procedures.  Only the identity used =
for
   network entry is impacted.  =
Potential disadvantages include that
   =
different methods to indicate emergency for NAA cases and =
standard
   emergency network attachments =
may be required.  Also, modifying =
the
   NAI itself (the username at realm =
part) may conflict with network
   =
selection and network entry procedures, depending on the =
actual
   access =
network."
 
[BA] There =
are two distinct ideas being presented here.  One is to =
define
an emergency user name (e.g. "emergency"); =
another is to define an
emergency domain (e.g. =
"emergency.com").  The former concept may =
make
sense, but the latter one is dangerous since =
existing systems not
including the emergency realm =
in their routing tables may just return =
an
error.  So the question is what realm =
should be used, if any.  The problem
with =
including any realm is that it assumes realm reachability.  =
If
reachability doesn't exist, then the host will =
get an error.  If there is
no realm, then the =
local realm needs to recognize the emergency =
username,
and utilize an appropriate EAP method =
that allows client =
unauthenticated
access.
> 
"   2) Emergency EAP method =

   An emergency indication can be =
given by using a dedicated EAP method
   =
that is reserved for emergency network attachment =
only."
 
[BA] Why is a =
dedicated EAP method needed for emergency access?  EMU =
WG
has already discussed this and come up with =
mechanisms that would allow
client unauthenticated =
access from any TLS-based method (e.g. server =
side
either doesn't ask for a client cert, or =
accepts the client not providing
one).  That =
mechanism is supported in RFC 5216, and can also be applied =
to
existing methods such as EAP FAST, EAP TTLSv0, =
PEAP, etc.
 
In effect, =
the only real constraint here is that a local =
network
advertising support for emergency calling =
needs to support one or more
of these =
methods.
 
"  =
 2.a) Existing EAP method with new type: An existing EAP method may =
be
   used.  EAP methods themselves =
typically do not support emergency
   =
indication.  One option would be to pick a common EAP method =
like
   EAP-TLS and allocate a new method =
type for the same method that is
   =
exclusively reserved to emergency use.  Such EAP method should =
be
   chosen in a way that the same =
method can support NAA cases as well =
as
   standard emergency network =
attachment."
> 
Given =
that RFC 5216 already supports client-unauthenticated =
anonymous
access (see Sections 2.1.4 and 2.2), why =
is it necessary to request
allocation of a new =
method =
type?
 
"   =
2.b) Existing EAP method: Same as 2a), but without assigning a =
new
   EAP method type for =
emergency.  In this case some implicit =
indication
   must be used.  For =
example, in cases where EAP-TLS is used in =
network
   attachment in combination with =
client certificates, the absence of a
   =
client certificate could be interpreted by the network as a =
request
   for emergency network =
attachment."
> 
[BA] =
The combination of an emergency NAI *and* the absence of a =
client
certificate would be considered a request =
for emergency attachment. If an
NAI corresponding =
to an existing account is used, then normal =
policies
will apply (which would probably require =
authenticated =
access).
 
"   =
2.c) Emergency EAP method: A new EAP method could be defined that =
is
   specifically designed for emergency =
network entry in NAA cases. Most
   =
likely, such EAP method would not be usable for standard =
emergency
   network attachment with an =
existing subscription.  Such =
dedicated
   emergency EAP method should =
be key-generating in compliance with
   =
RFC3748 <http://tools.ietf.org/html/rfc3748 to enable the regular =
air
interface security methods even in =
unauthenticated =
operation."
 
[BA] Since =
any TLS-based method can potentially support =
client-
unauthenticated access, it's not clear to =
me that there is a good case for
creating yet =
another method.
 
Section =
6.3
 
"   =
Therefore, for network attachment that is by default based on =
EAP
   authentication it is desirable =
also for NAA network attachment to use
   =
a key-generating EAP method (that provides an MSK key to =
the
   authenticator to bootstrap further =
key derivation for protecting the
   =
wireless link)."
 
[BA] =
Where key generation is required (e.g. WPA/WPA2 enterprise) you =
don't
really have a =
choice.
 
"   =
2) Null authentication: an EAP method is performed.  However, =
no
   credentials specific to either the =
server or the device or
   subscription =
are used as part of the authentication exchange.  =
An
   example for this would be an =
EAP-TLS exchange with using the
   =
TLS_DH_anon (anonymous) ciphersuite.  Alternatively, a =
publicly
   available static key for =
emergency access could be used.  In =
the
   latter case, the device would need =
to be provisioned with the
   appropriate =
emergency key for the IAP/ISP in =
advance."
 
[BA] WPA/WPA2 =
enterprise mode and PSK mode are distinct; PSK mode =
only
uses the 4-way handshake, not =
EAP.
 
"   3) =
Device authentication: This case extends the =
server-only
   authentication case.  =
If the device is configured with a =
device
   certificate and the IAP/ISP EAP =
server can rely on a trusted root
   =
allowing the EAP server to verify the device certificate, at =
least
   the device identity (e.g. the =
MAC address) can be authenticated by
   =
the IAP/ISP in NAA cases.  An example for this are WiMAX devices =
that
   are shipped with device =
certificates issued under the global =
WiMAX
   device public-key =
infrastructure.  To perform =
unauthenticated
   emergency calls, if =
allowed by the IAP/ISP, such devices perform =
EAP-
   TLS based network attachment with =
client authentication based on the
   =
device =
certificate."
> 
IEEE =
802.1ar might also be an example of this.
------_=_NextPart_001_01CAC9E9.97BFD69E-- From bernard_aboba@hotmail.com Mon Mar 22 11:02:10 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 905AE3A69C7 for ; Mon, 22 Mar 2010 11:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.273 X-Spam-Level: X-Spam-Status: No, score=0.273 tagged_above=-999 required=5 tests=[AWL=-0.858, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 jUMP2OuPvx9n for ; Mon, 22 Mar 2010 11:02:09 -0700 (PDT) Received: from blu0-omc3-s15.blu0.hotmail.com (blu0-omc3-s15.blu0.hotmail.com [65.55.116.90]) by core3.amsl.com (Postfix) with ESMTP id B842C3A69B5 for ; Mon, 22 Mar 2010 11:02:09 -0700 (PDT) Received: from BLU137-DS13 ([65.55.116.73]) by blu0-omc3-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 11:02:27 -0700 X-Originating-IP: [130.129.27.170] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Kroeselberg, Dirk \(NSN - DE/Munich\)'" References: <4BA7800A.4040406@gmx.net> <201003221619.o2MGJc2G006891@sj-core-2.cisco.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net> In-Reply-To: <8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net> Date: Mon, 22 Mar 2010 11:02:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrJ23u49i+U7AGbQJCsAYZdKEfaygABnvbwAAGMhOA= Content-Language: en-us X-OriginalArrivalTime: 22 Mar 2010 18:02:27.0509 (UTC) FILETIME=[D5356650:01CAC9E9] Cc: 'ECRIT' Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of service attacks on the emergency.com domain) 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, 22 Mar 2010 18:02:10 -0000 Dirk said: "So what else is in existing RFCs that could be used (instead of the NAI options presented in the unauthenticated draft)?" RFC 5113 Section 2.3 describes how domain-based routing typically functions in AAA networks, as well as the long-term problems with use of decorated NAIs. As noted there, NAI-routing depends on routing table entries maintained on proxy servers. While an NAI like "emergency" will be routed to the local AAA server, and "emergency@example.com" will be routed to the AAA server at example.com (assuming that this domain is reachable from the local network), the NAI "emergency@emergency.com" will result in routing to the AAA server maintained within the emergency.com domain (assuming that this domain was reachable from the local network). As noted below, emergency.com is a real domain, so this could result in a Denial of Service attack on the legitimate owner of that domain. Diverting unauthenticated emergency services calls to an existing domain that has not authorized use of its resources for that purpose is problematic to say the least. ; <<>> DiG 9.6.1-P3 <<>> @192.168.1.1 emergency.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8716 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;emergency.com. IN A ;; ANSWER SECTION: emergency.com. 3600 IN A 205.243.133.2 ;; Query time: 118 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Mon Mar 22 10:56:32 2010 ;; MSG SIZE rcvd: 47 From alexander.mayrhofer@nic.at Mon Mar 22 11:13:02 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 D3DE73A6B57 for ; Mon, 22 Mar 2010 11:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.364 X-Spam-Level: X-Spam-Status: No, score=-7.364 tagged_above=-999 required=5 tests=[AWL=-1.664, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F0HNe6enQ4n for ; Mon, 22 Mar 2010 11:13:00 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id 695583A6B4E for ; Mon, 22 Mar 2010 11:12:59 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.sbg.nic.at with XWall v3.45 ; Mon, 22 Mar 2010 19:13:15 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 22 Mar 2010 19:13:15 +0100 Message-ID: <8BC845943058D844ABFC73D2220D466508F4EE40@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "service URN classification" pointer. Thread-Index: AcrJ61cwJKMUO3XlQGqBrOxv4vnT7Q== From: "Alexander Mayrhofer" To: "Ecrit@Ietf. Org" X-XWALL-BCKS: auto Subject: [Ecrit] "service URN classification" pointer. 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, 22 Mar 2010 18:13:03 -0000 Follow-up to my comment at the mic: A lot of work within the OpenStreetMap community goes into proper classification of map features, so that similar features are rendered in similar ways on maps, and can be searched. Development of those "tag spaces" typically happens on a wiki. There are "well know" tags that are long established, and there is typically heated discussion once someone proposes something new. http://wiki.openstreetmap.org/wiki/Tag Some of the tags are, unfortunately regional - most complicated things are typically types of restaurants ("winery/heurigen"). There is a conference on OpenStreetMap ("State of the Map") - i haven't been there, but it might be helpful to discuss that problem. Alex From alexander.mayrhofer@nic.at Mon Mar 22 11:19:19 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 10AD13A67D3 for ; Mon, 22 Mar 2010 11:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20TXFOwFj+Ad for ; Mon, 22 Mar 2010 11:19:14 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id D68593A6AFF for ; Mon, 22 Mar 2010 11:19:04 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.sbg.nic.at with XWall v3.45 ; Mon, 22 Mar 2010 19:19:21 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 22 Mar 2010 19:19:21 +0100 Message-ID: <8BC845943058D844ABFC73D2220D466508F4EE41@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D466508F4EE40@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] "service URN classification" pointer. Thread-Index: AcrJ61cwJKMUO3XlQGqBrOxv4vnT7QAAK+Ww References: <8BC845943058D844ABFC73D2220D466508F4EE40@nics-mail.sbg.nic.at> From: "Alexander Mayrhofer" To: "Alexander Mayrhofer" , "Ecrit@Ietf. Org" X-XWALL-BCKS: auto Subject: Re: [Ecrit] "service URN classification" pointer. 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, 22 Mar 2010 18:19:19 -0000 [hate to reply to myself, but..] > There are "well know" tags that are long established, and there is > typically heated discussion once someone proposes something new. >=20 > http://wiki.openstreetmap.org/wiki/Tag All about the development of the Tag spaces can be found here: http://wiki.openstreetmap.org/wiki/Category:Proposals_admin Alex From mlinsner@cisco.com Mon Mar 22 14:14:11 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 CFFA83A681B for ; Mon, 22 Mar 2010 14:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.841 X-Spam-Level: X-Spam-Status: No, score=-7.841 tagged_above=-999 required=5 tests=[AWL=-1.628, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqldbN1IXJ8X for ; Mon, 22 Mar 2010 14:14:09 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 4889128C1DF for ; Mon, 22 Mar 2010 14:08:14 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsFAJB5p0urRN+J/2dsb2JhbACBQ5kHXnOkGZhTglWCKASDHg X-IronPort-AV: E=Sophos;i="4.51,289,1267401600"; d="scan'208,217";a="104040838" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 22 Mar 2010 21:08:31 +0000 Received: from [130.129.25.146] (sjc-vpn2-737.cisco.com [10.21.114.225]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o2ML8VLD012669; Mon, 22 Mar 2010 21:08:31 GMT User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 22 Mar 2010 14:04:58 -0700 From: Marc Linsner To: , ecrit Message-ID: Thread-Topic: ECRIT Direct (was: Re: [Ecrit] ISPs and LIS requirements) Thread-Index: AcrKA1Q1g8OpYGRevUanw+3rrw4wnw== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3352111711_964304" Subject: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) 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, 22 Mar 2010 21:14:11 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3352111711_964304 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Ray, Assuming this pertains to the conversation around ECRIT Direct. IMO, it=B9s unfortunate that regulators are led to the conclusion that you outline. Forcing a business/technical relationship between an access provider and public safety is only going to stifle those offering or wantin= g to offer access services, in the end harming the consumer of Internet services. But I suppose that=B9s the intention of those proposing such to th= e regulators. Regardless, the IETF should not put forth any architecture tha= t forces those relationships. I believe that using UK regulation as justification for the ECRIT Direct work will actually be detrimental to it=B9s progress within the IETF. -Marc- On 3/22/10 10:20 AM, "Ray.Bellis@nominet.org.uk" wrote: > To back up what James W just said at the mic: >=20 > The proposed UK model for emergency service access over VoIP depends on e= ach > ISP running a LIS and that LIS permitting queries from the PSAP. >=20 > It's my belief that this will be enshrined in UK law via the introduction= by > OFCOM of a new "General Condition of Service" which will apply to any pub= lic > telecommunications provider, including pure IP access providers. >=20 > Ray=20 --B_3352111711_964304 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable ECRIT Direct (was: Re: [Ecrit] ISPs and LIS requirements) Ray,

Assuming this pertains to the conversation around ECRIT Direct.

IMO, it’s unfortunate that regulators are led to the conclusion that = you outline.  Forcing a business/technical relationship between an acce= ss provider and public safety is only going to stifle those offering or want= ing to offer access services, in the end harming the consumer of Internet se= rvices.  But I suppose that’s the intention of those proposing su= ch to the regulators.  Regardless, the IETF should not put forth any ar= chitecture that forces those relationships.

I believe that using UK regulation as justification for the ECRIT Direct wo= rk will actually be detrimental to it’s progress within the IETF.

-Marc-




On 3/22/10 10:20 AM, "Ray.Bellis@n= ominet.org.uk" <Ray.Bellis@n= ominet.org.uk> wrote:

<= SPAN STYLE=3D'font-size:11pt'>To back up what James W just said at the mic:
The proposed UK model for emergency service access over VoIP depends on eac= h ISP running a LIS and that LIS permitting queries from the PSAP.

It's my belief that this will be enshrined in UK law via the introduction b= y OFCOM of a new "General Condition of Service" which will apply t= o any public telecommunications provider, including pure IP access providers= .

Ray
--B_3352111711_964304-- From James.Winterbottom@andrew.com Mon Mar 22 14:29:26 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 388BF3A69BF for ; Mon, 22 Mar 2010 14:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.06 X-Spam-Level: X-Spam-Status: No, score=-0.06 tagged_above=-999 required=5 tests=[AWL=-2.192, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, EXTRA_MPART_TYPE=1, 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 7IxkwhizENti for ; Mon, 22 Mar 2010 14:29:19 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id B7D713A6948 for ; Mon, 22 Mar 2010 14:29:16 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:22467 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S176834Ab0CVV3e (ORCPT ); Mon, 22 Mar 2010 16:29:34 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 22 Mar 2010 16:29:33 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 23 Mar 2010 05:29:31 +0800 From: "Winterbottom, James" To: Marc Linsner , "Ray.Bellis@nominet.org.uk" , ecrit Date: Tue, 23 Mar 2010 05:29:27 +0800 Thread-Topic: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) Thread-Index: AcrKA1Q1g8OpYGRevUanw+3rrw4wnwAAjCqg Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120DFB12FFC@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_5A55A45AE77F5941B18E5457ECAC81880120DFB12FFCSISPE7MB1co_"; type="multipart/alternative" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) 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, 22 Mar 2010 21:29:26 -0000 --_004_5A55A45AE77F5941B18E5457ECAC81880120DFB12FFCSISPE7MB1co_ Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC81880120DFB12FFCSISPE7MB1co_" --_000_5A55A45AE77F5941B18E5457ECAC81880120DFB12FFCSISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Marc, Requiring the access network to have a location service suitable for provid= ing routing and dispatch information for emergency services is a fundamenta= l aspect of i2, i3 and ECRIT. Furthermore, the LIS needs to provide locatio= n information that will result in a valid route to the PSAP. If civic locat= ion information is used then this must line-up with the profiles for civic = fields used in the local LoST server, so much of the relationships and requ= irements are you concerned about below are already pivotal to deployment of= the basic ECRIT solution as defined in phone BCP. What Ray is talking about from this point is that there is likely to regula= tion in the UK requiring ISPs and access providers to have a LIS, largely b= ecause this is seemed to be the best way to enable progression towards a NG= emergency solution. Experience in the cellular world, clearly show that wi= thout regulation access providers will not put this equipment in place so t= hat the services can progress. Discussions I have had with carriers has res= ulted in the same answer, without regulation they are not going to spend th= e money required to make it happen. This impacts all the solutions not just= ECRIT Direct. Cheers James [cid:image002.jpg@01CACA62.99629160] James Winterbottom Global Product Manager Andrew GeoLENs IP Location Product Portfolio Email: james.winterbottom@andrew.com Phone: +61-2-42-212938 Mobile: +61-448-266004 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of M= arc Linsner Sent: Tuesday, 23 March 2010 8:05 AM To: Ray.Bellis@nominet.org.uk; ecrit Subject: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) Ray, Assuming this pertains to the conversation around ECRIT Direct. IMO, it's unfortunate that regulators are led to the conclusion that you ou= tline. Forcing a business/technical relationship between an access provide= r and public safety is only going to stifle those offering or wanting to of= fer access services, in the end harming the consumer of Internet services. = But I suppose that's the intention of those proposing such to the regulato= rs. Regardless, the IETF should not put forth any architecture that forces= those relationships. I believe that using UK regulation as justification for the ECRIT Direct wo= rk will actually be detrimental to it's progress within the IETF. -Marc- On 3/22/10 10:20 AM, "Ray.Bellis@nominet.org.uk" wrote: To back up what James W just said at the mic: The proposed UK model for emergency service access over VoIP depends on eac= h ISP running a LIS and that LIS permitting queries from the PSAP. It's my belief that this will be enshrined in UK law via the introduction b= y OFCOM of a new "General Condition of Service" which will apply to any pub= lic telecommunications provider, including pure IP access providers. Ray --_000_5A55A45AE77F5941B18E5457ECAC81880120DFB12FFCSISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ECRIT Direct (was: Re: [Ecrit] ISPs and LIS requirements)

Hi Marc,

 

Requiring the access network to have a location service suitable for providing routing and dispatch information fo= r emergency services is a fundamental aspect of i2, i3 and ECRIT. Furthermore= , the LIS needs to provide location information that will result in a valid r= oute to the PSAP. If civic location information is used then this must line-up w= ith the profiles for civic fields used in the local LoST server, so much of the relationships and requirements are you concerned about below are already pivotal to deployment of the basic ECRIT solution as defined in phone BCP.<= o:p>

 

What Ray is talking about from this po= int is that there is likely to regulation in the UK requiring ISPs and access providers to have a LIS, largely because this is seemed to be the best way = to enable progression towards a NG emergency solution. Experience in the cellu= lar world, clearly show that without regulation access providers will not put t= his equipment in place so that the services can progress. Discussions I have ha= d with carriers has resulted in the same answer, without regulation they are = not going to spend the money required to make it happen. This impacts all the solutions not just ECRIT Direct.

 

Cheers

James

 

 

James Winterbottom

Global Product Manager

Andrew GeoLENs<= o:p>

IP Location Pro= duct Portfolio

Email: jam= es.winterbottom@andrew.com

Phone: +61-2-42-212938

Mobile: +61-448-266004

<= span style=3D'font-size:12.0pt;color:navy'> 

From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner
Sent: Tuesday, 23 March 2010= 8:05 AM
To: Ray.Bellis@nominet.org.uk; ecrit
Subject: [Ecrit] ECRIT Direc= t (was: Re: ISPs and LIS requirements)<= /o:p>

 

Ray,

Assuming this pertains to the conversation around ECRIT Direct.

IMO, it’s unfortunate that regulators are led to the conclusion that = you outline.  Forcing a business/technical relationship between an access provider and public safety is only going to stifle those offering or wantin= g to offer access services, in the end harming the consumer of Internet services= .  But I suppose that’s the intention of those proposing such to t= he regulators.  Regardless, the IETF should not put forth any architectur= e that forces those relationships.

I believe that using UK regulation as justification for the ECRIT Direct work will actually be detr= imental to it’s progress within the IETF.

-Marc-




On 3/22/10 10:20 AM, "Ray.Bellis= @nominet.org.uk" <Ray.Bellis@nominet.org.uk> wrote:

To back up what James W just said at the mic:

The proposed UK model for emergency service access over VoIP depends on each ISP running a = LIS and that LIS permitting queries from the PSAP.

It's my belief that this will be enshrined in UK law via the introduction b= y OFCOM of a new "General Condition of Service" which will apply to= any public telecommunications provider, including pure IP access providers.
Ray

--_000_5A55A45AE77F5941B18E5457ECAC81880120DFB12FFCSISPE7MB1co_-- --_004_5A55A45AE77F5941B18E5457ECAC81880120DFB12FFCSISPE7MB1co_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=6590; creation-date="Tue, 23 Mar 2010 05:29:29 GMT"; modification-date="Tue, 23 Mar 2010 05:29:29 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAByAUEDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2U9KT Pao57iG2haWeVI0UZLMcAVx+rfEayt2MOlxG7l6BzkJn+Z/Ck2lub0MNVru1ON/yOzdljUs7BVAy STgCmNcQpD5zTRiPGd5YAY+teL6x4g1fVpGW+uHVc/6gfKo/D/Gqjz3+oukBknuGA2xxgk4HTAFZ e1WyPchkM+VSnNI9T1Hx3odhuVbhrmQfwwjI/PpVKw+IunzRTy3qG2CsBFGuWd/XiuJ/4RHXPPhg Fi3mSruC54Rf9o9q6/RPhxa2+JtWcXMnXyU4QH39aFKo3sFbC5ZQpazcn5Mkg8Zarrd2sOiaSxi3 Yaeboo/lXaJnbzUdvBDbRCKCJIo14CoMAVLWqT6nh1qlOb/dxsvxFopMijNMwFopMj1oyPWgBaKT IpaACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAx9b8PW2vpBHeSSCKFt2xDjccY5qTT/D2k6WALSxiQ93K5b8zWnikxxSsnqae2qKHJzadjzyPw Hd6vq11falN9mglmZgi8uwzx7CsfxV41tvh9qy6R4d02zmlSMNcyT7mYMegyCO39K9Tvppraxnng t2uJY4yyRL1dscD8a8Hm+H3jjVE1PVrqxC3M75eGRlMku45O3sAPr2pxhFO5tiMdXrJRk9Oy2O/8 R/ES70bwNo+uW1tbSXOo7d0b7tinblsYOeo9a5+6+NF+NE06ezsrJ9QnkkjuYn37Y8EbSvOeQf0r P1vwl4t1Hwl4b0lNInL2SyifLL8hL/KevZTUJ+FesWfje2hhsZZdJW4jY3G5cBOCc854q0lY4byO j8SfE7xDpXiYaJpmlWl3MIYyybHZzIV3MAAegp2nfF+a+8K6teyafDDqWnIjKhLGKTc236jvxmuf 1Tw744i+IF94h0vRZDIZ3MDuUIAI2g4J9KbN8NPEmn+D5kWzN1qWo3CGWKJwfKjTLDJzgkse1GgX ZaT41+IIfs1xeaPYG1mJ5iLhmAOGx8xwfqK0/EXxX1ix8Uy6TpVlYSRKE2tcsynJUE5O4Ada53QP hzrel+KtLn1DQmvLAlHnBZcRkjnIzyVP8qg1XwZ4tu/E2oanJ4Za7SeeRwkjqFIJ4PDelOyFdnXa t8SvEOjLoRurDTd2pIXmKlmVBvx8pDY6c96qJ8ap2v8AVFNna/ZYI3ayPzbpWBwu7nv14FHxB8G6 7q2i+HV0/SvMmtrby5oYiAIuAccn8K5jU/hT4igmsIbLT5JhJbRtcS7l2xysTuB57DHT0pLlG+Y9 Z+HniTV/FeiPqmp2ttbI0pSAQBhvA6k5J78fga62uW8P2WraNd22jpAg0m2g2BwB1AHOeuSf5mup qGWtgooooGFFFFABRRRQAUUUUAFFFFABRSUUALRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFJRQBDdz/Z7WSbaWKLkKo5J7AVkw3l//ZRW63x3EcgWZ1TJCn+IAfl+tbZ5FJgZpp2Ja1MU 6q1sfLt2e8VRndIfmfPZcAA4xz9aautagx2fY4t/JzubHBx6etbm0DHTj2o2j0FO67E8r7nPJrE6 XLMxZ/NOArZEcGOu4Yzj0Oec09vEMysF8iIFgSGYthcdjx1OMit7aCOn6U0wozq7KCy5wSKd12Dl l3MiDWLq9t7torRo3jXKBgc59CPXjNMOqCzH+j3El7uG4+bngj+EYX7xz0PpW7t9KTYPQetK6Hyv uYb65dRSBZLeJFd9iuWbC8E5PFNHiG6fbss1y+MIxbcn+9x37VutEj43KDtORkdDShBkn1p3j2Fy y7lLTr9r15FaBojEQr5P8fUge2MHPvWhUccax52ADJJPuTT81LLV+otFJmlpDCkoJxXP3Os3upX0 lhoSx/uTtnvJBlIz6KP4jQB0FGawh4bnlG6517Unk9YpRGv5AVFPDr+iqZ7a6Oq26cvBMoEuP9lh 1/GgDo6KpaZqlrq1kt1avuQ8EHqh7gjsau0AFFJSE4FACk4BNIjq6hlOQeQage7hwVUlzj+Bc1FZ XUQtYg25PlA+ZcUXK5Ha9i6TijOaaWDKSORjrWT4VvrnUNFFxdy+ZKZpF3YA4DkDp7Cgk2KKyPFV 7c6d4euLq0l8qZNu1sA4ywHeoRo+ulQf+Enl5H/PpHQBu5pCwzisyw03VLa6El3rj3cQBzEbdEyf XIqh4k1u70bU9PMERnikD+dEByVAByPccmgDpKKr2d7b39rHdWsiyxSDKsKsUAJRmmTsVgkYHBCk j8qzPC95cah4ds7u6k8yaVMu2AM8n0oA16KKKACiiigAooooAaTiqr32zVYLLZnzYnk3Z6bSBjH4 /pVvGapSWe/VYb0yACKJ49uOu4qc/pQVG19SgPE0LW2oP5JEtkX/AHbHHmBe4P6e1Tarqd5Z/ZGt 7WKZbhxH88pUhiCR2PHFV7nw3Fc6bcWz3G2SSaSWOVRgpuPK+47Gr15YG7S1USqn2eZZen3sAjHt 1pG79kpJoq6xrsmlzRR/Z4nzC00haXbgAgELxyeas3epvELeK1t/OublSyRs20BRjJY9hyB+NVdY 0FNWuobkzKklvGREdudr5BDfpjFWLuxmna3uIbhIryBSocrlWB6gj0yAaBfurR763/QdaalLK89v cwCC5hXeyK24Mp6EH8MVW0vXJ7xrZbqzFv8Aa4vNgZZN4YdSDwMHHNWLSwkjkmubq4Wa5mQIWVdq qo6AD8aq6Xos9o1sby8jn+xxmOBY02gZ4JOScnHFAWp2f9fcTT635Ftfy+SD9jmEWN/3shTn2+9+ lS3uozxXa2dnbLPOV8xgz7FRc4BJwepzjiql1ok1xPcKl3GlpdSLJNHsy24Y+6c8A7RVm9sp3uxe 2NzHDceX5b+Ym5XXORkZB4JNMLU9B0upTW8dmZrbZJczCJk352Eg8579P1pja3DFrjaZMhT5FZJT 90k5+X2PH406awmuYrPzrlGltphKzhMBsAjAHbr+lNm0iG6u7uS4ZZIrmNEKdCNuec/j+lIlKn1E XWk/s6W7eI/LM0KRqcl2DbQB9TUtld30sxivbFYPl3K6Sb1+h4GDVWDQvK0gWRu3aRJzNHO3LBt2 4E+ppbHSJY9TOo3lxHJOVKjyVKKQe5BJyeKCmqdnY2RS03cPUfnRuHrTOcyfFF9NZaM4tji4uHWC I+hbjP4DNW9K02HStNhsoRhY1wxH8Tdyay/FTbP7JnY/uotQjMnsOef8+tb+73H50ALQRmmSM+xv L278Hbk8Z7ZrE87xb/z76R/39k/woA1bbTrSzknkt4Vja4ffJt/iPrRe6ha6dB515OkMecZc4z9P Wsmx1bV/7fXS9Sgsl3QGbdbuzYwcc5rPs7/SL7WrvUdVvbVWglMFrDNIBsVerYPcnvQBrQeLNGnm EQujGzHapmjZAx9iRir4BuyWb/Ug8AH7/v8ASs3UdW8P3llJbzX9hMjDbtaVT+XpWdo2tR2Gj6nD 9qS6TTCfIkDZ3oRlRnv6Uikmbl/rGm6UFS6uEjZh8sajcx+ijmq2keINKvVjtY7kLNtwI5VKFvoD 1qHw5YRw2Y1K9eOXUbtfMllYglQeij0AFWbjTbHV9JSC52btoKSAjdG3Yg0DtozS2eXuKjAxyB0r F8E/8i4v/XxN/wChmpfDV/NeaS8d22bm1kaCVv7xXv8AliovBH/IuL/18Tf+hmmSHjf/AJFS7/4D /wChCtlLu22D/SIun98Vj+N/+RUu/wDgP/oQqVfCPh4qD/ZFryP7lAjVS4hkbbHLG59FYE1hawM+ LtBz6zf+gGtGy0DSdNuPPstPhglxt3ouDis/WP8AkbtB+s3/AKBQBBd283ha8fUbGNpNMlbN1bKP 9Uf76j+Yrore5iu7eO4t3WSKRQyuOhFSFVIIIyD1BrmJY5PCN41zCrSaPO+ZYxz9lYn7wH931oA6 S4/49pf9w/yrH8F/8ijp/wD1z/qa1XlSayeSN1dHjJVl5BGOtZPgz/kULD/rmf5mgCe88T6TY3Jt prrMq/fEaM4T/eIHH41pW88V1Cs0EiyROMq6HIIrl/Dl9Z6THLpOplbW9MzF2mGBcZJwwboeO1dL ZWltZW4itI1jiJLBV6ZPNAFiiiigAooooASmPDHIQXQEipKKAIPskH/PMUfZYP8AnmKmooHzPuQ/ ZIP+eQo+yQdox+dTUUBzPuQ/ZIMf6sUfZIP+eYqaigOZ9yH7JB/zzFH2WD/nmKmooC7IfskH/PMU fZYP+eYqaigOZ9yH7Lb/APPIUfZIP+eYqaloDml3IPskH/PJaPskH/PIVNRQHNLuZ+p6Pbajp01o y7PMXAYdVPY/nWdod7HJ/wASvU41i1K3G1gTgTAdHX1zXQ1S1PSLHVY1W8hDFOUdTh0PqCORQHM+ 5OLWDH+rFV72Sw063e5u2SKJRyWPX6etZ40DUovkt/Ed5HH6PGkh/M0+38L2a3Aur6afUZ1+61y2 VX6L0oHzPuVvD9ob+7utcuYDElyBHbRN1WMdz7moNB07T477UdMvLOCS4iuGlQyRglo3OQRnqB0r qwABWbqei22pvHKzSQXMX+ruIW2uvtn09qBXG3Oi6WsDkadaqVGc+Uvas5rLSde0K+XTLWOPcHiW RYgu5h0I9Rmpm8OXVyvl6hrt5dQd4lVY9w9CRya07eGPToUt4kEdsgwgUcIPT/69IabMzw+LDUtG hc20QniTypoyvKOvBBq4n2Gx0lbidIo4o49zMVHAqC/8PwXdyb60uZrK6YfNLbtw49x0NVbLwwlw kM2p6hcagqYZIpMLGD7qOtHUrmbjuS+FLdv7Nub6WLy2vrh51UjBCnp/j+NHgn/kXF/6+Jv/AEM1 thgw2p93pkdKw4/CFpApWDUtUhQsW2R3RVQScngCmQO8b/8AIqXf1T/0IVup9xfpWXJoFvPo0ml3 FxdzQyNuLyy7pOufvH6VXHhSLH/IY1j/AMDD/hQI3q57WP8Akb9B+s3/AKBVyx0JNPuhcLqOozkA jZPcl1/KrFxpsFzqFrfSF/NtC3l4PB3DBzQBdprxpIjI6hlYYIPQilHSloA5KZZfCLyIN0miz5we ptWPb/dNWvC1zFY+CLS5nYrHFEWcgZwMmt+aGKeB4ZY1eN1wysMgiq1jptvp+nLYRLugUFQr8/Ke 1ABJBYaxYo00MVzBKoZd654Pp6Vh6JdDSP7YtgZp7OwmURAfMygjlRk9jVlfDU1sDFp2s3VnbMST CqqwXP8AdJ5Wr1potnZ6a9hEH8uQku7NlnY9ST60AOOsWqh95dGR0RlYchmxgfrz9DV8VnSaNaSl y4fL78nd/e6/lzj0ya0FoAdRRRQAUlVb29i0+3a4nEpjXljHGz7R6kAdKhtNXt7y5jhjSYGWJpVM kRTKggdDg/xCnZicknY0aKSo/Oj87yd48zbu255x0zSGS0lIc1BZ3kd5HI8YYCOV4juHdTg/yoFc s0VG88URQSSKpkbamT944JwPwB/Kn0DCioYriKeSZY23GF9j8dGwDj8iKgutRhs7mGGXcPMR3L8b UVcZJJ92A49aLCuty9RTQeKak0cpcRurGNtrgH7pwDg/gR+dAXJKKbURu7cTeT56CTds2553Y3Y+ uATQMnopDSHlcUALS1nQ6tbyaUdTcSQ24BILjnbnGcDPWr4o2EncWiimSyxwhTJIqBmCjccZJ4Ao AfRUcM0c8YlicOjdGU5Bp/vQMWg4Iqjd6rbWVylvIs7yyIXCwwtIdoIGTtBxyRVtTuAYDAPrRYV0 RvbR4JUFPXaSKisoI/skRO4/KOCxIqS9u47K382VWKl0T5RzlmCj9TTJ7iKwW3jdWxLKIUx2JBPP txRZlc+jVy0AAMDgUtNFQQXkc91c26Bg9syq5I4OVDDH4GjUlss0VWtbu3vLcz28qyRgspI7EHBH 6U+1uI7q1juIW3RSqGRsYyDQFyaimRSxzKWjdXUMVJBzgg4I/A06gYtLVW+u47G0a4lDFFZVIUc8 sAP1NWGZUUsxAAGST2FArjqSqVlqdtfsywGTIG4b42UMPVSRyPcVJcXcdtNbxyBs3EvlpgdDtJ5/ I0WdwurFmlqGa6gtyBNKke4MRuOMgDJ/IU9XV0DqQVIyCO4oHcfRTciloAWiiigCnqyPJo17Giln a3kCqoySdp4FYd9pz3MlqzQzEw6Y+0oWXbJ8mBx346e1dPikwaqMrGcoKRx1rHqsmpwyXDOlwZUb PlSk+VgZGc7AOuc8irniK3vJ7uVYBcBHtY13Q5GD5y5wR325/CulwaMU+fW4vZq1rnKNbNb3csF1 Fd/2THMwRY/MY52IQePmK53dO9ULCO8t9PvreOG+jN3lbVXVyc+a5JY/w8FTk44rusGjb60/aaCd LW9zjfs00+oxqLe6lRLwSmWRXVlO2Tg84IHy4I4wQKdDa3djY2FvAZhJqkKxTiR2LRvjLPycjjI4 6HFdhg1E9rFJcpcMgMsYKo3oD1xRzj9nbUxLqE2+vWZt4Z3A2rs2tswSdz7hxuHfd14xUXiaxlmu xcQQyvIljOqum7hiUwOO/J/yK6XBowfWlz2dx8iascfeW88ZuLgx3bzfbZDGgEhSQADap2n5RnOD 0z1rW061a2j1iTypo2luWcbclm/dryue+c4962cHNKBQ53BU7HHWr3Nqm4xXf2cQzQo4jl3SOwQq xU5IOQwz0z04qG40/VHVSkUxuonjMTMThW+zEE5/3sD6125B7UYNNVNbkuldWuc94aiuEuZiXYQG MAoYpV+fPJzIc5x6cVXeKZp5FKXZ1Q3LbX+fyvK3cc/d27PxzXU4NG2lzalcmljl0sXt/h89tHby iTyGJjwS2c+nX8KbdO1093NsvTduc6eyJIqgY4yMADnOd1dVg0Yo5w9na1jlWjn8u5/d3h1gs+HX fsKZOMH7n3cY75qjcWUVzq9stla6gbZTEZfNEoXeJVOfm7gZyRxXcYNBGaaqWJdK6tc462hkFoo1 SK9JEf8AooiEnDZbOdvQ5x97jGKksLLUY7iK8uBcG7a/WOU7mK+X5Y3cdNu7v611oGKMGk5jVJdz ndYRV8QW0s0t7DELVl8y1Rmy29Tg7VNVry21D+0Lm4shcec9xsjZi20x/Z89DwPnHX1rq8UmD6Ch TsDp3OC1W3SUomn2uqtF5ObgESZLeZGeN3V8A8jirl1b3Dsv9jQ3It1lUoJlfiXa/I3845GT0ziu ywaCKftOgvZHFW8OoLC5BnMGE+1pHHMGYbhvILnJOM/d/wAK2PDsMaXWpNbwzx27zIYvOVgWGwAk bucZrd20YNJzuUoWZzmmafdWulR3VrGVuP3gmgYbRMN7Y+jY6H86xorbVY4baNw8MqQRC1HlSsU+ UZ+6QoOc53V3mDQR701UaE6SZxdvpeqos1lbedDFdTyyvKGI8pkckYz2f5fwBq2Eupo4LzVYrlYL ku9xBFvJiYABBheccN07kV1OKMUOo30BUkupw1/p+pXUM3lx3PyQg2fmbjs/fLt3DuQBnntium07 cNKeOW3laaMMsschyZG6nBPBBzx257Vp4PrRg0nO6sEafK7nJ7roxGDTvtxsQFM0csbK8Q3DKISA T8u7pnGBg81W1K1uZotukxXQtQ2Yg4cMJPLkBK7vmA5A5712uDRimp2E6V1a5xeoQXGo6k15DBdP EIZBCWR1IcQsOFOCMkgdOTVmaOXEv2mO8N5sT7CYg+F+QdccA7s53dq6vFGMUc/kP2fmceltfRtP JKLtWnF0s7xBmxym0qCf94jHvW/oDSHSkEkRj2sVXO4b1zw2G+YZ9DWgFpwFS5XHGHKxaKKKk0Ci iikAlFFFMTCloooASiiigBaKKKACiiigBKKKKYBRRRSBBRRRTAKWiigAooopAJRRRTEFHeiikMWi iigApKKKBhRRRTEFLRRSAKKKKAEooooAKWiigYUUUUAf/9k= --_004_5A55A45AE77F5941B18E5457ECAC81880120DFB12FFCSISPE7MB1co_-- From mlinsner@cisco.com Mon Mar 22 15:46:43 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 CCA233A6BA2 for ; Mon, 22 Mar 2010 15:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.103 X-Spam-Level: X-Spam-Status: No, score=-7.103 tagged_above=-999 required=5 tests=[AWL=-1.631, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2udJ2IOKidE for ; Mon, 22 Mar 2010 15:46:37 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 9C31F3A6B79 for ; Mon, 22 Mar 2010 15:46:36 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image.jpg : 6590 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwFAMqPp0urR7Ht/2dsb2JhbACBQ5c7gUxec6RDmFgCglOCKASDHg X-IronPort-AV: E=Sophos;i="4.51,290,1267401600"; d="jpg'145?scan'145,208,217,145";a="104076675" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 22 Mar 2010 22:46:54 +0000 Received: from [130.129.25.146] (sjc-vpn5-744.cisco.com [10.21.90.232]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2MMksWG020775; Mon, 22 Mar 2010 22:46:54 GMT User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 22 Mar 2010 15:46:53 -0700 From: Marc Linsner To: "Winterbottom, James" , ecrit Message-ID: Thread-Topic: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) Thread-Index: AcrKA1Q1g8OpYGRevUanw+3rrw4wnwAAjCqgAAMDCrA= In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120DFB12FFC@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: multipart/related; boundary="B_3352117614_1209465" Subject: Re: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) 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, 22 Mar 2010 22:46:43 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3352117614_1209465 Content-type: multipart/alternative; boundary="B_3352117614_1243158" --B_3352117614_1243158 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable James, >From Ray=B9s message: =B3and that LIS permitting queries from the PSAP. =B3 I am obviously against forcing the access provider to establish a business/technical relationship with the PSAP. This goes well beyond requiring the access provider to supply location to it=B9s customer. -Marc- On 3/22/10 2:29 PM, "Winterbottom, James" wrote: > Hi Marc, > =20 > Requiring the access network to have a location service suitable for prov= iding > routing and dispatch information for emergency services is a fundamental > aspect of i2, i3 and ECRIT. Furthermore, the LIS needs to provide locatio= n > information that will result in a valid route to the PSAP. If civic locat= ion > information is used then this must line-up with the profiles for civic fi= elds > used in the local LoST server, so much of the relationships and requireme= nts > are you concerned about below are already pivotal to deployment of the ba= sic > ECRIT solution as defined in phone BCP. > =20 > What Ray is talking about from this point is that there is likely to > regulation in the UK requiring ISPs and access providers to have a LIS, > largely because this is seemed to be the best way to enable progression > towards a NG emergency solution. Experience in the cellular world, clearl= y > show that without regulation access providers will not put this equipment= in > place so that the services can progress. Discussions I have had with carr= iers > has resulted in the same answer, without regulation they are not going to > spend the money required to make it happen. This impacts all the solution= s not > just ECRIT Direct. > =20 > Cheers > James > =20 > =20 > =20 > James Winterbottom Global Product Manager Andrew GeoLENs IP Location > Product Portfolio Email: james.winterbottom@andrew.com Phone: +61-2-42-21= 2938 > Mobile: +61-448-266004 > =20 >=20 >=20 > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of= Marc > Linsner > Sent: Tuesday, 23 March 2010 8:05 AM > To: Ray.Bellis@nominet.org.uk; ecrit > Subject: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) > =20 > Ray, >=20 > Assuming this pertains to the conversation around ECRIT Direct. >=20 > IMO, it=B9s unfortunate that regulators are led to the conclusion that you > outline. Forcing a business/technical relationship between an access pro= vider > and public safety is only going to stifle those offering or wanting to of= fer > access services, in the end harming the consumer of Internet services. B= ut I > suppose that=B9s the intention of those proposing such to the regulators. > Regardless, the IETF should not put forth any architecture that forces th= ose > relationships. >=20 > I believe that using UK regulation as justification for the ECRIT Direct = work > will actually be detrimental to it=B9s progress within the IETF. >=20 > -Marc- >=20 >=20 >=20 >=20 > On 3/22/10 10:20 AM, "Ray.Bellis@nominet.org.uk" > wrote: > To back up what James W just said at the mic: >=20 > The proposed UK model for emergency service access over VoIP depends on e= ach > ISP running a LIS and that LIS permitting queries from the PSAP. >=20 > It's my belief that this will be enshrined in UK law via the introduction= by > OFCOM of a new "General Condition of Service" which will apply to any pub= lic > telecommunications provider, including pure IP access providers. >=20 > Ray=20 >=20 --B_3352117614_1243158 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Ecrit] ECRIT Direct (was: Re:  ISPs and LIS requirements)<= /TITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '>James,<BR> <BR> >From Ray’s message:<BR> <BR> “and that LIS permitting queries from the PSAP. “<BR> <BR> I am obviously against forcing the access provider to establish a business/= technical relationship with the PSAP.  This goes well beyond requiring = the access provider to supply location to it’s customer.<BR> <BR> -Marc-<BR> <BR> On 3/22/10 2:29 PM, "Winterbottom, James" <<a href=3D"James.Wint= erbottom@andrew.com">James.Winterbottom@andrew.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><FONT FACE=3D"= Arial"><SPAN STYLE=3D'font-size:10pt'>Hi Marc,<BR>  <BR> Requiring the access network to have a location service suitable for provid= ing routing and dispatch information for emergency services is a fundamental= aspect of i2, i3 and ECRIT. Furthermore, the LIS needs to provide location = information that will result in a valid route to the PSAP. If civic location= information is used then this must line-up with the profiles for civic fiel= ds used in the local LoST server, so much of the relationships and requireme= nts are you concerned about below are already pivotal to deployment of the b= asic ECRIT solution as defined in phone BCP.<BR>  <BR> What Ray is talking about from this point is that there is likely to regula= tion in the UK requiring ISPs and access providers to have a LIS, largely be= cause this is seemed to be the best way to enable progression towards a NG e= mergency solution. Experience in the cellular world, clearly show that witho= ut regulation access providers will not put this equipment in place so that = the services can progress. Discussions I have had with carriers has resulted= in the same answer, without regulation they are not going to spend the mone= y required to make it happen. This impacts all the solutions not just ECRIT = Direct.<BR>  <BR> Cheers<BR> James<BR>  <BR>  <BR> </SPAN></FONT></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:11pt'> <BR>   </SPAN></FONT><FONT COLOR=3D"#000080"><FONT FACE=3D"Times New Roman= "><SPAN STYLE=3D'font-size:12pt'><IMG src=3D"cid:3352117613_1235969" ></SPAN></F= ONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font= -size:11pt'>   </SPAN><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><SPAN S= TYLE=3D'font-size:10pt'><B>James Winterbottom</B></SPAN></FONT></FONT><SPAN ST= YLE=3D'font-size:11pt'> </SPAN><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><SPAN STYL= E=3D'font-size:10pt'>Global Product Manager</SPAN></FONT></FONT><SPAN STYLE=3D'f= ont-size:11pt'> </SPAN><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><SPAN STYLE=3D'fon= t-size:10pt'>Andrew GeoLENs</SPAN></FONT></FONT><SPAN STYLE=3D'font-size:11pt'= > </SPAN><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>I= P Location Product Portfolio</SPAN></FONT></FONT><SPAN STYLE=3D'font-size:11pt= '> </SPAN><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>= <B>Email:</B> <a href=3D"james.winterbottom@andrew.com">james.winterbottom@and= rew.com</a></SPAN></FONT></FONT><SPAN STYLE=3D'font-size:11pt'> </SPAN><FONT C= OLOR=3D"#000080"><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><B>Phone:</B> +61= -2-42-212938</SPAN></FONT></FONT><SPAN STYLE=3D'font-size:11pt'> </SPAN><FONT = COLOR=3D"#000080"><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><B>Mobile:</B> += 61-448-266004</SPAN></FONT></FONT><SPAN STYLE=3D'font-size:11pt'>  <BR> </SPAN></FONT><FONT COLOR=3D"#000080"><FONT FACE=3D"Times New Roman"><SPAN STYL= E=3D'font-size:12pt'> <BR> </SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN = STYLE=3D'font-size:11pt'> </SPAN></FONT> <P ALIGN=3DCENTER> <FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12pt'><HR ALIGN=3DCENTER = SIZE=3D"2" WIDTH=3D"100%"></SPAN></FONT> <P> <FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE=3D'= font-size:10pt'><B>From:</B> <a href=3D"ecrit-bounces@ietf.org">ecrit-bounces@= ietf.org</a> [<a href=3D"mailto:ecrit-bounces@ietf.org">mailto:ecrit-bounces@i= etf.org</a>] <B>On Behalf Of </B>Marc Linsner<BR> <B>Sent:</B> Tuesday, 23 March 2010 8:05 AM<BR> <B>To:</B> <a href=3D"Ray.Bellis@nominet.org.uk">Ray.Bellis@nominet.org.uk</a= >; ecrit<BR> <B>Subject:</B> [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements)<B= R> </SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12= pt'> <BR> </SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'= font-size:11pt'>Ray,<BR> <BR> Assuming this pertains to the conversation around ECRIT Direct.<BR> <BR> IMO, it’s unfortunate that regulators are led to the conclusion that = you outline.  Forcing a business/technical relationship between an acce= ss provider and public safety is only going to stifle those offering or want= ing to offer access services, in the end harming the consumer of Internet se= rvices.  But I suppose that’s the intention of those proposing su= ch to the regulators.  Regardless, the IETF should not put forth any ar= chitecture that forces those relationships.<BR> <BR> I believe that using UK regulation as justification for the ECRIT Direct wo= rk will actually be detrimental to it’s progress within the IETF.<BR> <BR> -Marc-<BR> <BR> <BR> <BR> <BR> On 3/22/10 10:20 AM, "<a href=3D"Ray.Bellis@nominet.org.uk">Ray.Bellis@n= ominet.org.uk</a>" <<a href=3D"Ray.Bellis@nominet.org.uk">Ray.Bellis@n= ominet.org.uk</a>> wrote:<BR> To back up what James W just said at the mic: <BR> <BR> The proposed UK model for emergency service access over VoIP depends on eac= h ISP running a LIS and that LIS permitting queries from the PSAP. <BR> <BR> It's my belief that this will be enshrined in UK law via the introduction b= y OFCOM of a new "General Condition of Service" which will apply t= o any public telecommunications provider, including pure IP access providers= . <BR> <BR> Ray <BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --B_3352117614_1243158-- --B_3352117614_1209465 Content-Type: image/jpeg; name="image.jpg" Content-ID: <3352117613_1235969> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8l JCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIo Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAAR CAByAUEDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2U9KTPao57iG2haWeVI0UZLMcAVx+rfEa yt2MOlxG7l6BzkJn+Z/Ck2lub0MNVru1ON/yOzdljUs7BVAySTgCmNcQpD5zTRiPGd5YAY+t eL6x4g1fVpGW+uHVc/6gfKo/D/Gqjz3+oukBknuGA2xxgk4HTAFZe1WyPchkM+VSnNI9T1Hx 3odhuVbhrmQfwwjI/PpVKw+IunzRTy3qG2CsBFGuWd/XiuJ/4RHXPPhgFi3mSruC54Rf9o9q 6/RPhxa2+JtWcXMnXyU4QH39aFKo3sFbC5ZQpazcn5Mkg8Zarrd2sOiaSxi3Yaeboo/lXaJn bzUdvBDbRCKCJIo14CoMAVLWqT6nh1qlOb/dxsvxFopMijNMwFopMj1oyPWgBaKTIpaACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAx 9b8PW2vpBHeSSCKFt2xDjccY5qTT/D2k6WALSxiQ93K5b8zWnikxxSsnqae2qKHJzadjzyPw Hd6vq11falN9mglmZgi8uwzx7CsfxV41tvh9qy6R4d02zmlSMNcyT7mYMegyCO39K9Tvppra xnngt2uJY4yyRL1dscD8a8Hm+H3jjVE1PVrqxC3M75eGRlMku45O3sAPr2pxhFO5tiMdXrJR k9Oy2O/8R/ES70bwNo+uW1tbSXOo7d0b7tinblsYOeo9a5+6+NF+NE06ezsrJ9QnkkjuYn37 Y8EbSvOeQf0rP1vwl4t1Hwl4b0lNInL2SyifLL8hL/KevZTUJ+FesWfje2hhsZZdJW4jY3G5 cBOCc854q0lY4byOj8SfE7xDpXiYaJpmlWl3MIYyybHZzIV3MAAegp2nfF+a+8K6teyafDDq WnIjKhLGKTc236jvxmuf1Tw744i+IF94h0vRZDIZ3MDuUIAI2g4J9KbN8NPEmn+D5kWzN1qW o3CGWKJwfKjTLDJzgkse1GgXZaT41+IIfs1xeaPYG1mJ5iLhmAOGx8xwfqK0/EXxX1ix8Uy6 TpVlYSRKE2tcsynJUE5O4Ada53QPhzrel+KtLn1DQmvLAlHnBZcRkjnIzyVP8qg1XwZ4tu/E 2oanJ4Za7SeeRwkjqFIJ4PDelOyFdnXat8SvEOjLoRurDTd2pIXmKlmVBvx8pDY6c96qJ8ap 2v8AVFNna/ZYI3ayPzbpWBwu7nv14FHxB8G67q2i+HV0/SvMmtrby5oYiAIuAccn8K5jU/hT 4igmsIbLT5JhJbRtcS7l2xysTuB57DHT0pLlG+Y9Z+HniTV/FeiPqmp2ttbI0pSAQBhvA6k5 J78fga62uW8P2WraNd22jpAg0m2g2BwB1AHOeuSf5mupqGWtgooooGFFFFABRRRQAUUUUAFF FFABRSUUALRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFJRQBDdz/Z7WSbaWKLk Ko5J7AVkw3l//ZRW63x3EcgWZ1TJCn+IAfl+tbZ5FJgZpp2Ja1MU6q1sfLt2e8VRndIfmfPZ cAA4xz9aautagx2fY4t/JzubHBx6etbm0DHTj2o2j0FO67E8r7nPJrE6XLMxZ/NOArZEcGOu 4Yzj0Oec09vEMysF8iIFgSGYthcdjx1OMit7aCOn6U0wozq7KCy5wSKd12Dll3MiDWLq9t7t orRo3jXKBgc59CPXjNMOqCzH+j3El7uG4+bngj+EYX7xz0PpW7t9KTYPQetK6HyvuYb65dRS BZLeJFd9iuWbC8E5PFNHiG6fbss1y+MIxbcn+9x37VutEj43KDtORkdDShBkn1p3j2Fyy7lL Tr9r15FaBojEQr5P8fUge2MHPvWhUccax52ADJJPuTT81LLV+otFJmlpDCkoJxXP3Os3upX0 lhoSx/uTtnvJBlIz6KP4jQB0FGawh4bnlG6517Unk9YpRGv5AVFPDr+iqZ7a6Oq26cvBMoEu P9lh1/GgDo6KpaZqlrq1kt1avuQ8EHqh7gjsau0AFFJSE4FACk4BNIjq6hlOQeQage7hwVUl zj+Bc1FZXUQtYg25PlA+ZcUXK5Ha9i6TijOaaWDKSORjrWT4VvrnUNFFxdy+ZKZpF3YA4DkD p7Cgk2KKyPFV7c6d4euLq0l8qZNu1sA4ywHeoRo+ulQf+Enl5H/PpHQBu5pCwzisyw03VLa6 El3rj3cQBzEbdEyfXIqh4k1u70bU9PMERnikD+dEByVAByPccmgDpKKr2d7b39rHdWsiyxSD KsKsUAJRmmTsVgkYHBCkj8qzPC95cah4ds7u6k8yaVMu2AM8n0oA16KKKACiiigAooooAaTi qr32zVYLLZnzYnk3Z6bSBjH4/pVvGapSWe/VYb0yACKJ49uOu4qc/pQVG19SgPE0LW2oP5JE tkX/AHbHHmBe4P6e1Tarqd5Z/ZGt7WKZbhxH88pUhiCR2PHFV7nw3Fc6bcWz3G2SSaSWOVRg puPK+47Gr15YG7S1USqn2eZZen3sAjHt1pG79kpJoq6xrsmlzRR/Z4nzC00haXbgAgELxyea s3epvELeK1t/OublSyRs20BRjJY9hyB+NVdY0FNWuobkzKklvGREdudr5BDfpjFWLuxmna3u IbhIryBSocrlWB6gj0yAaBfurR763/QdaalLK89vcwCC5hXeyK24Mp6EH8MVW0vXJ7xrZbqz Fv8Aa4vNgZZN4YdSDwMHHNWLSwkjkmubq4Wa5mQIWVdqqo6AD8aq6Xos9o1sby8jn+xxmOBY 02gZ4JOScnHFAWp2f9fcTT635Ftfy+SD9jmEWN/3shTn2+9+lS3uozxXa2dnbLPOV8xgz7FR c4BJwepzjiql1ok1xPcKl3GlpdSLJNHsy24Y+6c8A7RVm9sp3uxe2NzHDceX5b+Ym5XXORkZ B4JNMLU9B0upTW8dmZrbZJczCJk352Eg8579P1pja3DFrjaZMhT5FZJT90k5+X2PH406awmu YrPzrlGltphKzhMBsAjAHbr+lNm0iG6u7uS4ZZIrmNEKdCNuec/j+lIlKn1EXWk/s6W7eI/L M0KRqcl2DbQB9TUtld30sxivbFYPl3K6Sb1+h4GDVWDQvK0gWRu3aRJzNHO3LBt24E+ppbHS JY9TOo3lxHJOVKjyVKKQe5BJyeKCmqdnY2RS03cPUfnRuHrTOcyfFF9NZaM4tji4uHWCI+hb jP4DNW9K02HStNhsoRhY1wxH8Tdyay/FTbP7JnY/uotQjMnsOef8+tb+73H50ALQRmmSM+xv L278Hbk8Z7ZrE87xb/z76R/39k/woA1bbTrSzknkt4Vja4ffJt/iPrRe6ha6dB515OkMecZc 4z9PWsmx1bV/7fXS9Sgsl3QGbdbuzYwcc5rPs7/SL7WrvUdVvbVWglMFrDNIBsVerYPcnvQB rQeLNGnmEQujGzHapmjZAx9iRir4BuyWb/Ug8AH7/v8ASs3UdW8P3llJbzX9hMjDbtaVT+Xp Wdo2tR2Gj6nD9qS6TTCfIkDZ3oRlRnv6Uikmbl/rGm6UFS6uEjZh8sajcx+ijmq2keINKvVj tY7kLNtwI5VKFvoD1qHw5YRw2Y1K9eOXUbtfMllYglQeij0AFWbjTbHV9JSC52btoKSAjdG3 Yg0DtozS2eXuKjAxyB0rF8E/8i4v/XxN/wChmpfDV/NeaS8d22bm1kaCVv7xXv8AliovBH/I uL/18Tf+hmmSHjf/AJFS7/4D/wChCtlLu22D/SIun98Vj+N/+RUu/wDgP/oQqVfCPh4qD/ZF ryP7lAjVS4hkbbHLG59FYE1hawM+LtBz6zf+gGtGy0DSdNuPPstPhglxt3ouDis/WP8AkbtB +s3/AKBQBBd283ha8fUbGNpNMlbN1bKP9Uf76j+Yrore5iu7eO4t3WSKRQyuOhFSFVIIIyD1 BrmJY5PCN41zCrSaPO+ZYxz9lYn7wH931oA6S4/49pf9w/yrH8F/8ijp/wD1z/qa1XlSayeS N1dHjJVl5BGOtZPgz/kULD/rmf5mgCe88T6TY3JtprrMq/fEaM4T/eIHH41pW88V1Cs0EiyR OMq6HIIrl/Dl9Z6THLpOplbW9MzF2mGBcZJwwboeO1dLZWltZW4itI1jiJLBV6ZPNAFiiiig AooooASmPDHIQXQEipKKAIPskH/PMUfZYP8AnmKmooHzPuQ/ZIP+eQo+yQdox+dTUUBzPuQ/ ZIMf6sUfZIP+eYqaigOZ9yH7JB/zzFH2WD/nmKmooC7IfskH/PMUfZYP+eYqaigOZ9yH7Lb/ APPIUfZIP+eYqaloDml3IPskH/PJaPskH/PIVNRQHNLuZ+p6Pbajp01oy7PMXAYdVPY/nWdo d7HJ/wASvU41i1K3G1gTgTAdHX1zXQ1S1PSLHVY1W8hDFOUdTh0PqCORQHM+5OLWDH+rFV72 Sw063e5u2SKJRyWPX6etZ40DUovkt/Ed5HH6PGkh/M0+38L2a3Aur6afUZ1+61y2VX6L0oHz PuVvD9ob+7utcuYDElyBHbRN1WMdz7moNB07T477UdMvLOCS4iuGlQyRglo3OQRnqB0rqwAB Wbqei22pvHKzSQXMX+ruIW2uvtn09qBXG3Oi6WsDkadaqVGc+Uvas5rLSde0K+XTLWOPcHiW RYgu5h0I9Rmpm8OXVyvl6hrt5dQd4lVY9w9CRya07eGPToUt4kEdsgwgUcIPT/69IabMzw+L DUtGhc20QniTypoyvKOvBBq4n2Gx0lbidIo4o49zMVHAqC/8PwXdyb60uZrK6YfNLbtw49x0 NVbLwwlwkM2p6hcagqYZIpMLGD7qOtHUrmbjuS+FLdv7Nub6WLy2vrh51UjBCnp/j+NHgn/k XF/6+Jv/AEM1thgw2p93pkdKw4/CFpApWDUtUhQsW2R3RVQScngCmQO8b/8AIqXf1T/0IVup 9xfpWXJoFvPo0ml3FxdzQyNuLyy7pOufvH6VXHhSLH/IY1j/AMDD/hQI3q57WP8Akb9B+s3/ AKBVyx0JNPuhcLqOozkAjZPcl1/KrFxpsFzqFrfSF/NtC3l4PB3DBzQBdprxpIjI6hlYYIPQ ilHSloA5KZZfCLyIN0miz5weptWPb/dNWvC1zFY+CLS5nYrHFEWcgZwMmt+aGKeB4ZY1eN1w ysMgiq1jptvp+nLYRLugUFQr8/Ke1ABJBYaxYo00MVzBKoZd654Pp6Vh6JdDSP7YtgZp7Owm URAfMygjlRk9jVlfDU1sDFp2s3VnbMSTCqqwXP8AdJ5Wr1potnZ6a9hEH8uQku7NlnY9ST60 AOOsWqh95dGR0RlYchmxgfrz9DV8VnSaNaSly4fL78nd/e6/lzj0ya0FoAdRRRQAUlVb29i0 +3a4nEpjXljHGz7R6kAdKhtNXt7y5jhjSYGWJpVMkRTKggdDg/xCnZicknY0aKSo/Oj87yd4 8zbu255x0zSGS0lIc1BZ3kd5HI8YYCOV4juHdTg/yoFcs0VG88URQSSKpkbamT944JwPwB/K n0DCioYriKeSZY23GF9j8dGwDj8iKgutRhs7mGGXcPMR3L8bUVcZJJ92A49aLCuty9RTQeKa k0cpcRurGNtrgH7pwDg/gR+dAXJKKbURu7cTeT56CTds2553Y3Y+uATQMnopDSHlcUALS1nQ 6tbyaUdTcSQ24BILjnbnGcDPWr4o2EncWiimSyxwhTJIqBmCjccZJ4AoAfRUcM0c8YlicOjd GU5Bp/vQMWg4Iqjd6rbWVylvIs7yyIXCwwtIdoIGTtBxyRVtTuAYDAPrRYV0RvbR4JUFPXaS KisoI/skRO4/KOCxIqS9u47K382VWKl0T5RzlmCj9TTJ7iKwW3jdWxLKIUx2JBPPtxRZlc+j Vy0AAMDgUtNFQQXkc91c26Bg9syq5I4OVDDH4GjUlss0VWtbu3vLcz28qyRgspI7EHBH6U+1 uI7q1juIW3RSqGRsYyDQFyaimRSxzKWjdXUMVJBzgg4I/A06gYtLVW+u47G0a4lDFFZVIUc8 sAP1NWGZUUsxAAGST2FArjqSqVlqdtfsywGTIG4b42UMPVSRyPcVJcXcdtNbxyBs3EvlpgdD tJ5/I0WdwurFmlqGa6gtyBNKke4MRuOMgDJ/IU9XV0DqQVIyCO4oHcfRTciloAWiiigCnqyP Jo17Gilna3kCqoySdp4FYd9pz3MlqzQzEw6Y+0oWXbJ8mBx346e1dPikwaqMrGcoKRx1rHqs mpwyXDOlwZUbPlSk+VgZGc7AOuc8irniK3vJ7uVYBcBHtY13Q5GD5y5wR325/CulwaMU+fW4 vZq1rnKNbNb3csF1Fd/2THMwRY/MY52IQePmK53dO9ULCO8t9PvreOG+jN3lbVXVyc+a5JY/ w8FTk44rusGjb60/aaCdLW9zjfs00+oxqLe6lRLwSmWRXVlO2Tg84IHy4I4wQKdDa3djY2Fv AZhJqkKxTiR2LRvjLPycjjI46HFdhg1E9rFJcpcMgMsYKo3oD1xRzj9nbUxLqE2+vWZt4Z3A 2rs2tswSdz7hxuHfd14xUXiaxlmuxcQQyvIljOqum7hiUwOO/J/yK6XBowfWlz2dx8iascfe W88ZuLgx3bzfbZDGgEhSQADap2n5RnOD0z1rW061a2j1iTypo2luWcbclm/dryue+c4962cH NKBQ53BU7HHWr3Nqm4xXf2cQzQo4jl3SOwQqxU5IOQwz0z04qG40/VHVSkUxuonjMTMThW+z EE5/3sD6125B7UYNNVNbkuldWuc94aiuEuZiXYQGMAoYpV+fPJzIc5x6cVXeKZp5FKXZ1Q3L bX+fyvK3cc/d27PxzXU4NG2lzalcmljl0sXt/h89tHbyiTyGJjwS2c+nX8KbdO1093NsvTdu c6eyJIqgY4yMADnOd1dVg0Yo5w9na1jlWjn8u5/d3h1gs+HXfsKZOMH7n3cY75qjcWUVzq9s tla6gbZTEZfNEoXeJVOfm7gZyRxXcYNBGaaqWJdK6tc462hkFoo1SK9JEf8AooiEnDZbOdvQ 5x97jGKksLLUY7iK8uBcG7a/WOU7mK+X5Y3cdNu7v611oGKMGk5jVJdzndYRV8QW0s0t7DEL Vl8y1Rmy29Tg7VNVry21D+0Lm4shcec9xsjZi20x/Z89DwPnHX1rq8UmD6ChTsDp3OC1W3SU omn2uqtF5ObgESZLeZGeN3V8A8jirl1b3Dsv9jQ3It1lUoJlfiXa/I3845GT0ziuywaCKftO gvZHFW8OoLC5BnMGE+1pHHMGYbhvILnJOM/d/wAK2PDsMaXWpNbwzx27zIYvOVgWGwAkbucZ rd20YNJzuUoWZzmmafdWulR3VrGVuP3gmgYbRMN7Y+jY6H86xorbVY4baNw8MqQRC1HlSsU+ UZ+6QoOc53V3mDQR701UaE6SZxdvpeqos1lbedDFdTyyvKGI8pkckYz2f5fwBq2Eupo4LzVY rlYLku9xBFvJiYABBheccN07kV1OKMUOo30BUkupw1/p+pXUM3lx3PyQg2fmbjs/fLt3DuQB nntium07cNKeOW3laaMMsschyZG6nBPBBzx257Vp4PrRg0nO6sEafK7nJ7roxGDTvtxsQFM0 csbK8Q3DKISAT8u7pnGBg81W1K1uZotukxXQtQ2Yg4cMJPLkBK7vmA5A5712uDRimp2E6V1a 5xeoQXGo6k15DBdPEIZBCWR1IcQsOFOCMkgdOTVmaOXEv2mO8N5sT7CYg+F+QdccA7s53dq6 vFGMUc/kP2fmceltfRtPJKLtWnF0s7xBmxym0qCf94jHvW/oDSHSkEkRj2sVXO4b1zw2G+YZ 9DWgFpwFS5XHGHKxaKKKk0CiiikAlFFFMTCloooASiiigBaKKKACiiigBKKKKYBRRRSBBRRR TAKWiigAooopAJRRRTEFHeiikMWiiigApKKKBhRRRTEFLRRSAKKKKAEooooAKWiigYUUUUAf /9k= --B_3352117614_1209465-- From James.Winterbottom@andrew.com Mon Mar 22 15:50:38 2010 Return-Path: <James.Winterbottom@andrew.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32AA028C178 for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 15:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.121 X-Spam-Level: X-Spam-Status: No, score=0.121 tagged_above=-999 required=5 tests=[AWL=-1.825, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, EXTRA_MPART_TYPE=1, 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 ZgRdhWaN6d2h for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 15:50:33 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 1F5AF3A6B9C for <ecrit@ietf.org>; Mon, 22 Mar 2010 15:50:30 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:26308 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S15247817Ab0CVWur (ORCPT <rfc822;ecrit@ietf.org>); Mon, 22 Mar 2010 17:50:47 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 22 Mar 2010 17:50:46 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 23 Mar 2010 06:50:43 +0800 From: "Winterbottom, James" <James.Winterbottom@andrew.com> To: Marc Linsner <mlinsner@cisco.com>, ecrit <ecrit@ietf.org> Date: Tue, 23 Mar 2010 06:50:40 +0800 Thread-Topic: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) Thread-Index: AcrKA1Q1g8OpYGRevUanw+3rrw4wnwAAjCqgAAMDCrAAAAfLMA== Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120DFB1302E@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880120DFB12FFC@SISPE7MB1.commscope.com> <C7CD416D.21810%mlinsner@cisco.com> In-Reply-To: <C7CD416D.21810%mlinsner@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_005_5A55A45AE77F5941B18E5457ECAC81880120DFB1302ESISPE7MB1co_"; type="multipart/alternative" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Mar 2010 22:50:38 -0000 --_005_5A55A45AE77F5941B18E5457ECAC81880120DFB1302ESISPE7MB1co_ Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC81880120DFB1302ESISPE7MB1co_" --_000_5A55A45AE77F5941B18E5457ECAC81880120DFB1302ESISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Marc, I understand that you are against this, however, the ECRIT charter already = requires this relationship to some degree by providing mechanisms to suppor= t location hiding. Geopriv supports third-party requests through the HELD i= dentity extensions mechanism, and all of these point to the PSAP or emergen= cy authority being permitted to query a LIS for location. Cheers James [cid:image001.jpg@01CACA6E.4BBBE9A0] James Winterbottom Global Product Manager Andrew GeoLENs IP Location Product Portfolio Email: james.winterbottom@andrew.com<mailto:james.winterbottom@andrew.com> Phone: +61-2-42-212938 Mobile: +61-448-266004 ________________________________ From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Tuesday, 23 March 2010 9:47 AM To: Winterbottom, James; ecrit Subject: Re: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) James, >From Ray's message: "and that LIS permitting queries from the PSAP. " I am obviously against forcing the access provider to establish a business/= technical relationship with the PSAP. This goes well beyond requiring the = access provider to supply location to it's customer. -Marc- On 3/22/10 2:29 PM, "Winterbottom, James" <James.Winterbottom@andrew.com> w= rote: Hi Marc, Requiring the access network to have a location service suitable for provid= ing routing and dispatch information for emergency services is a fundamenta= l aspect of i2, i3 and ECRIT. Furthermore, the LIS needs to provide locatio= n information that will result in a valid route to the PSAP. If civic locat= ion information is used then this must line-up with the profiles for civic = fields used in the local LoST server, so much of the relationships and requ= irements are you concerned about below are already pivotal to deployment of= the basic ECRIT solution as defined in phone BCP. What Ray is talking about from this point is that there is likely to regula= tion in the UK requiring ISPs and access providers to have a LIS, largely b= ecause this is seemed to be the best way to enable progression towards a NG= emergency solution. Experience in the cellular world, clearly show that wi= thout regulation access providers will not put this equipment in place so t= hat the services can progress. Discussions I have had with carriers has res= ulted in the same answer, without regulation they are not going to spend th= e money required to make it happen. This impacts all the solutions not just= ECRIT Direct. Cheers James [cid:image002.jpg@01CACA6E.4BBBE9A0] James Winterbottom Global Product= Manager Andrew GeoLENs IP Location Product Portfolio Email: james.winterbo= ttom@andrew.com Phone: +61-2-42-212938 Mobile: +61-448-266004 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of M= arc Linsner Sent: Tuesday, 23 March 2010 8:05 AM To: Ray.Bellis@nominet.org.uk; ecrit Subject: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) Ray, Assuming this pertains to the conversation around ECRIT Direct. IMO, it's unfortunate that regulators are led to the conclusion that you ou= tline. Forcing a business/technical relationship between an access provide= r and public safety is only going to stifle those offering or wanting to of= fer access services, in the end harming the consumer of Internet services. = But I suppose that's the intention of those proposing such to the regulato= rs. Regardless, the IETF should not put forth any architecture that forces= those relationships. I believe that using UK regulation as justification for the ECRIT Direct wo= rk will actually be detrimental to it's progress within the IETF. -Marc- On 3/22/10 10:20 AM, "Ray.Bellis@nominet.org.uk" <Ray.Bellis@nominet.org.uk= > wrote: To back up what James W just said at the mic: The proposed UK model for emergency service access over VoIP depends on eac= h ISP running a LIS and that LIS permitting queries from the PSAP. It's my belief that this will be enshrined in UK law via the introduction b= y OFCOM of a new "General Condition of Service" which will apply to any pub= lic telecommunications provider, including pure IP access providers. Ray --_000_5A55A45AE77F5941B18E5457ECAC81880120DFB1302ESISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" xmlns=3D"http://ww= w.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"= > <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <title>Re: [Ecrit] ECRIT Direct (was: Re:  ISPs and LIS requirements)<= /title> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"country-region"/> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"place"/> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"City"/> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"PersonName"/> <!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!-- /* Font Definitions */ @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:blue; text-decoration:underline;} p {mso-margin-top-alt:auto; margin-right:0cm; mso-margin-bottom-alt:auto; margin-left:0cm; font-size:12.0pt; font-family:"Times New Roman";} span.EmailStyle18 {mso-style-type:personal-reply; font-family:Arial; color:navy;} @page Section1 {size:595.3pt 841.9pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-AU link=3Dblue vlink=3Dblue> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>Hi Marc,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>I understand that you are against this= , however, the ECRIT charter already requires this relationship to some degre= e by providing mechanisms to support location hiding. Geopriv supports third-par= ty requests through the HELD identity extensions mechanism, and all of these p= oint to the PSAP or emergency authority being permitted to query a LIS for locat= ion.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>Cheers<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>James<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <div> <table class=3DMsoTableGrid border=3D0 cellspacing=3D0 cellpadding=3D0 style=3D'border-collapse:collapse'> <tr> <td width=3D284 valign=3Dtop style=3D'width:213.05pt;padding:0cm 5.4pt 0c= m 5.4pt'> <p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New Roman"= ><span style=3D'font-size:12.0pt;color:navy'><img width=3D321 height=3D114 id=3D"_x0000_i1028" src=3D"cid:image001.jpg@01CACA6E.4BBBE9A0"><o:p></o:p= ></span></font></p> </td> <td width=3D284 valign=3Dtop style=3D'width:213.05pt;padding:0cm 5.4pt 0c= m 5.4pt'> <p class=3DMsoNormal><b><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-family:Calibri;color:navy;font-weight:bold= '>James Winterbottom<o:p></o:p></span></font></b></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-family:Calibri;color:navy'>Global Product Manager<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-family:Calibri;color:navy'>Andrew GeoLENs<= o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-family:Calibri;color:navy'>IP Location Pro= duct Portfolio<o:p></o:p></span></font></p> <p class=3DMsoNormal><b><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-family:Calibri;color:navy;font-weight:bold= '>Email:</span></font></b><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font= -family: Calibri;color:navy'> <a href=3D"mailto:james.winterbottom@andrew.com">jam= es.winterbottom@andrew.com</a><o:p></o:p></span></font></p> <p class=3DMsoNormal><b><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-family:Calibri;color:navy;font-weight:bold= '>Phone:</span></font></b><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font= -family: Calibri;color:navy'> +61-2-42-212938<o:p></o:p></span></font></p> <p class=3DMsoNormal><st1:City w:st=3D"on"><st1:place w:st=3D"on"><b><fon= t size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-family= :Calibri; color:navy;font-weight:bold'>Mobile</span></font></b></st1:place></st1:= City><b><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font= -family: Calibri;color:navy;font-weight:bold'>:</span></font></b><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-family:C= alibri; color:navy'> +61-448-266004</span></font><font color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p> </td> </tr> </table> <p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New Roman"><= span style=3D'font-size:12.0pt;color:navy'> </span></font><o:p></o:p></p> </div> <div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm = 4.0pt'> <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz= e=3D3 face=3D"Times New Roman"><span lang=3DEN-US style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span lang=3DEN-US style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span>= </font></b><font size=3D2 face=3DTahoma><span lang=3DEN-US style=3D'font-size:10.0pt;font-fa= mily:Tahoma'> Marc Linsner [mailto:mlinsner@cisco.com] <br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, 23 March 2010= 9:47 AM<br> <b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName w:st=3D"= on">Winterbottom, James</st1:PersonName>; ecrit<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [Ecrit] ECRIT D= irect (was: Re: ISPs and LIS requirements)</span></font><span lang=3DEN-US><o:p><= /o:p></span></p> </div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 face=3DC= alibri><span style=3D'font-size:11.0pt;font-family:Calibri'>James,<br> <br> >From Ray’s message:<br> <br> “and that LIS permitting queries from the PSAP. “<br> <br> I am obviously against forcing the access provider to establish a business/technical relationship with the PSAP.  This goes well beyond requiring the access provider to supply location to it’s customer.<br= > <br> -Marc-<br> <br> On 3/22/10 2:29 PM, "<st1:PersonName w:st=3D"on">Winterbottom, James</= st1:PersonName>" <<a href=3D"James.Winterbottom@andrew.com">James.Winterbottom@andrew.com= </a>> wrote:</span></font><o:p></o:p></p> <p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 color=3D= navy face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'>= Hi Marc,<br>  <br> Requiring the access network to have a location service suitable for provid= ing routing and dispatch information for emergency services is a fundamental as= pect of i2, i3 and ECRIT. Furthermore, the LIS needs to provide location informa= tion that will result in a valid route to the PSAP. If civic location informatio= n is used then this must line-up with the profiles for civic fields used in the local LoST server, so much of the relationships and requirements are you concerned about below are already pivotal to deployment of the basic ECRIT solution as defined in phone BCP.<br>  <br> What Ray is talking about from this point is that there is likely to regula= tion in the <st1:country-region w:st=3D"on"><st1:place w:st=3D"on">UK</st1:place= ></st1:country-region> requiring ISPs and access providers to have a LIS, largely because this is seemed to be the best way to enable progression towards a NG emergency solution. Experience in the cellular world, clearly show that without regulation access providers will not put this equipment in place so that th= e services can progress. Discussions I have had with carriers has resulted in= the same answer, without regulation they are not going to spend the money requi= red to make it happen. This impacts all the solutions not just ECRIT Direct.<br= >  <br> Cheers<br> James<br>  <br>  <br> </span></font><font size=3D2 face=3DCalibri><span style=3D'font-size:11.0pt= ; font-family:Calibri'><br>   </span></font><font color=3Dnavy><span style=3D'color:navy'><im= g border=3D0 width=3D321 height=3D114 id=3D"_x0000_i1025" src=3D"cid:image002.jpg@01CACA6E.4BBBE9A0"></span></font><font size=3D2 face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri'>  =  </span></font><b><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-f= amily:Calibri; color:navy;font-weight:bold'>James Winterbottom</span></font></b><font size= =3D2 face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri'> </span= ></font><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-f= amily:Calibri; color:navy'>Global Product Manager</span></font><font size=3D2 face=3DCalib= ri><span style=3D'font-size:11.0pt;font-family:Calibri'> </span></font><font size=3D= 2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-family:Cal= ibri; color:navy'>Andrew GeoLENs</span></font><font size=3D2 face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri'> </span></font><font size=3D= 2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-family:Cal= ibri; color:navy'>IP Location Product Portfolio</span></font><font size=3D2 face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri'> </span= ></font><b><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-f= amily:Calibri; color:navy;font-weight:bold'>Email:</span></font></b><font size=3D2 color= =3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-family:Calibri;color:na= vy'> <a href=3D"james.winterbottom@andrew.com">james.winterbottom@andrew.com</a></s= pan></font><font size=3D2 face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri= '> </span></font><b><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-f= amily:Calibri; color:navy;font-weight:bold'>Phone:</span></font></b><font size=3D2 color= =3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-family:Calibri;color:na= vy'> +61-2-42-212938</span></font><font size=3D2 face=3DCalibri><span style=3D'f= ont-size: 11.0pt;font-family:Calibri'> </span></font><st1:City w:st=3D"on"><st1:place w:st=3D"on"><b><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'f= ont-size:10.0pt; font-family:Calibri;color:navy;font-weight:bold'>Mobile</span></font></b>= </st1:place></st1:City><b><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-f= amily:Calibri; color:navy;font-weight:bold'>:</span></font></b><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-family:Calibri;color:na= vy'> +61-448-266004</span></font><font size=3D2 face=3DCalibri><span style=3D'fo= nt-size: 11.0pt;font-family:Calibri'>  </span></font><o:p></o:p></p> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz= e=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter> </span></font></div> <p style=3D'margin-bottom:12.0pt'><b><font size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span>= </font></b><font size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>= <a href=3D"ecrit-bounces@ietf.org">ecrit-bounces@ietf.org</a> [<a href=3D"mailto:ecrit-bounces@ietf.org">mailto:ecrit-bounces@ietf.org</a>] <= b><span style=3D'font-weight:bold'>On Behalf Of </span></b>Marc Linsner<br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, 23 March 2010= 8:05 AM<br> <b><span style=3D'font-weight:bold'>To:</span></b> <a href=3D"Ray.Bellis@nominet.org.uk">Ray.Bellis@nominet.org.uk</a>; ecrit<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> [Ecrit] ECRIT Direc= t (was: Re: ISPs and LIS requirements)<br> </span></font><br> <font size=3D2 face=3DCalibri><span style=3D'font-size:11.0pt;font-family:C= alibri'>Ray,<br> <br> Assuming this pertains to the conversation around ECRIT Direct.<br> <br> IMO, it’s unfortunate that regulators are led to the conclusion that = you outline.  Forcing a business/technical relationship between an access provider and public safety is only going to stifle those offering or wantin= g to offer access services, in the end harming the consumer of Internet services= .  But I suppose that’s the intention of those proposing such to t= he regulators.  Regardless, the IETF should not put forth any architectur= e that forces those relationships.<br> <br> I believe that using <st1:country-region w:st=3D"on"><st1:place w:st=3D"on"= >UK</st1:place></st1:country-region> regulation as justification for the ECRIT Direct work will actually be detrimental to it’s progress within the IETF.<br> <br> -Marc-<br> <br> <br> <br> <br> On 3/22/10 10:20 AM, "<a href=3D"Ray.Bellis@nominet.org.uk">Ray.Bellis= @nominet.org.uk</a>" <<a href=3D"Ray.Bellis@nominet.org.uk">Ray.Bellis@nominet.org.uk</a>> wrote:<br> To back up what James W just said at the mic: <br> <br> The proposed <st1:country-region w:st=3D"on"><st1:place w:st=3D"on">UK</st1= :place></st1:country-region> model for emergency service access over VoIP depends on each ISP running a = LIS and that LIS permitting queries from the PSAP. <br> <br> It's my belief that this will be enshrined in <st1:country-region w:st=3D"o= n"><st1:place w:st=3D"on">UK</st1:place></st1:country-region> law via the introduction b= y OFCOM of a new "General Condition of Service" which will apply to= any public telecommunications provider, including pure IP access providers. <br= > <br> Ray </span></font><o:p></o:p></p> </div> </div> </body> </html> --_000_5A55A45AE77F5941B18E5457ECAC81880120DFB1302ESISPE7MB1co_-- --_005_5A55A45AE77F5941B18E5457ECAC81880120DFB1302ESISPE7MB1co_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6590; creation-date="Tue, 23 Mar 2010 06:50:41 GMT"; modification-date="Tue, 23 Mar 2010 06:50:41 GMT" Content-ID: <image001.jpg@01CACA6E.4BBBE9A0> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAByAUEDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2U9KT Pao57iG2haWeVI0UZLMcAVx+rfEayt2MOlxG7l6BzkJn+Z/Ck2lub0MNVru1ON/yOzdljUs7BVAy STgCmNcQpD5zTRiPGd5YAY+teL6x4g1fVpGW+uHVc/6gfKo/D/Gqjz3+oukBknuGA2xxgk4HTAFZ e1WyPchkM+VSnNI9T1Hx3odhuVbhrmQfwwjI/PpVKw+IunzRTy3qG2CsBFGuWd/XiuJ/4RHXPPhg Fi3mSruC54Rf9o9q6/RPhxa2+JtWcXMnXyU4QH39aFKo3sFbC5ZQpazcn5Mkg8Zarrd2sOiaSxi3 Yaeboo/lXaJnbzUdvBDbRCKCJIo14CoMAVLWqT6nh1qlOb/dxsvxFopMijNMwFopMj1oyPWgBaKT IpaACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAx9b8PW2vpBHeSSCKFt2xDjccY5qTT/D2k6WALSxiQ93K5b8zWnikxxSsnqae2qKHJzadjzyPw Hd6vq11falN9mglmZgi8uwzx7CsfxV41tvh9qy6R4d02zmlSMNcyT7mYMegyCO39K9Tvppraxnng t2uJY4yyRL1dscD8a8Hm+H3jjVE1PVrqxC3M75eGRlMku45O3sAPr2pxhFO5tiMdXrJRk9Oy2O/8 R/ES70bwNo+uW1tbSXOo7d0b7tinblsYOeo9a5+6+NF+NE06ezsrJ9QnkkjuYn37Y8EbSvOeQf0r P1vwl4t1Hwl4b0lNInL2SyifLL8hL/KevZTUJ+FesWfje2hhsZZdJW4jY3G5cBOCc854q0lY4byO j8SfE7xDpXiYaJpmlWl3MIYyybHZzIV3MAAegp2nfF+a+8K6teyafDDqWnIjKhLGKTc236jvxmuf 1Tw744i+IF94h0vRZDIZ3MDuUIAI2g4J9KbN8NPEmn+D5kWzN1qWo3CGWKJwfKjTLDJzgkse1GgX ZaT41+IIfs1xeaPYG1mJ5iLhmAOGx8xwfqK0/EXxX1ix8Uy6TpVlYSRKE2tcsynJUE5O4Ada53QP hzrel+KtLn1DQmvLAlHnBZcRkjnIzyVP8qg1XwZ4tu/E2oanJ4Za7SeeRwkjqFIJ4PDelOyFdnXa t8SvEOjLoRurDTd2pIXmKlmVBvx8pDY6c96qJ8ap2v8AVFNna/ZYI3ayPzbpWBwu7nv14FHxB8G6 7q2i+HV0/SvMmtrby5oYiAIuAccn8K5jU/hT4igmsIbLT5JhJbRtcS7l2xysTuB57DHT0pLlG+Y9 Z+HniTV/FeiPqmp2ttbI0pSAQBhvA6k5J78fga62uW8P2WraNd22jpAg0m2g2BwB1AHOeuSf5mup qGWtgooooGFFFFABRRRQAUUUUAFFFFABRSUUALRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFJRQBDdz/Z7WSbaWKLkKo5J7AVkw3l//ZRW63x3EcgWZ1TJCn+IAfl+tbZ5FJgZpp2Ja1MU 6q1sfLt2e8VRndIfmfPZcAA4xz9aautagx2fY4t/JzubHBx6etbm0DHTj2o2j0FO67E8r7nPJrE6 XLMxZ/NOArZEcGOu4Yzj0Oec09vEMysF8iIFgSGYthcdjx1OMit7aCOn6U0wozq7KCy5wSKd12Dl l3MiDWLq9t7torRo3jXKBgc59CPXjNMOqCzH+j3El7uG4+bngj+EYX7xz0PpW7t9KTYPQetK6Hyv uYb65dRSBZLeJFd9iuWbC8E5PFNHiG6fbss1y+MIxbcn+9x37VutEj43KDtORkdDShBkn1p3j2Fy y7lLTr9r15FaBojEQr5P8fUge2MHPvWhUccax52ADJJPuTT81LLV+otFJmlpDCkoJxXP3Os3upX0 lhoSx/uTtnvJBlIz6KP4jQB0FGawh4bnlG6517Unk9YpRGv5AVFPDr+iqZ7a6Oq26cvBMoEuP9lh 1/GgDo6KpaZqlrq1kt1avuQ8EHqh7gjsau0AFFJSE4FACk4BNIjq6hlOQeQage7hwVUlzj+Bc1FZ XUQtYg25PlA+ZcUXK5Ha9i6TijOaaWDKSORjrWT4VvrnUNFFxdy+ZKZpF3YA4DkDp7Cgk2KKyPFV 7c6d4euLq0l8qZNu1sA4ywHeoRo+ulQf+Enl5H/PpHQBu5pCwzisyw03VLa6El3rj3cQBzEbdEyf XIqh4k1u70bU9PMERnikD+dEByVAByPccmgDpKKr2d7b39rHdWsiyxSDKsKsUAJRmmTsVgkYHBCk j8qzPC95cah4ds7u6k8yaVMu2AM8n0oA16KKKACiiigAooooAaTiqr32zVYLLZnzYnk3Z6bSBjH4 /pVvGapSWe/VYb0yACKJ49uOu4qc/pQVG19SgPE0LW2oP5JEtkX/AHbHHmBe4P6e1Tarqd5Z/ZGt 7WKZbhxH88pUhiCR2PHFV7nw3Fc6bcWz3G2SSaSWOVRgpuPK+47Gr15YG7S1USqn2eZZen3sAjHt 1pG79kpJoq6xrsmlzRR/Z4nzC00haXbgAgELxyeas3epvELeK1t/OublSyRs20BRjJY9hyB+NVdY 0FNWuobkzKklvGREdudr5BDfpjFWLuxmna3uIbhIryBSocrlWB6gj0yAaBfurR763/QdaalLK89v cwCC5hXeyK24Mp6EH8MVW0vXJ7xrZbqzFv8Aa4vNgZZN4YdSDwMHHNWLSwkjkmubq4Wa5mQIWVdq qo6AD8aq6Xos9o1sby8jn+xxmOBY02gZ4JOScnHFAWp2f9fcTT635Ftfy+SD9jmEWN/3shTn2+9+ lS3uozxXa2dnbLPOV8xgz7FRc4BJwepzjiql1ok1xPcKl3GlpdSLJNHsy24Y+6c8A7RVm9sp3uxe 2NzHDceX5b+Ym5XXORkZB4JNMLU9B0upTW8dmZrbZJczCJk352Eg8579P1pja3DFrjaZMhT5FZJT 90k5+X2PH406awmuYrPzrlGltphKzhMBsAjAHbr+lNm0iG6u7uS4ZZIrmNEKdCNuec/j+lIlKn1E XWk/s6W7eI/LM0KRqcl2DbQB9TUtld30sxivbFYPl3K6Sb1+h4GDVWDQvK0gWRu3aRJzNHO3LBt2 4E+ppbHSJY9TOo3lxHJOVKjyVKKQe5BJyeKCmqdnY2RS03cPUfnRuHrTOcyfFF9NZaM4tji4uHWC I+hbjP4DNW9K02HStNhsoRhY1wxH8Tdyay/FTbP7JnY/uotQjMnsOef8+tb+73H50ALQRmmSM+xv L278Hbk8Z7ZrE87xb/z76R/39k/woA1bbTrSzknkt4Vja4ffJt/iPrRe6ha6dB515OkMecZc4z9P Wsmx1bV/7fXS9Sgsl3QGbdbuzYwcc5rPs7/SL7WrvUdVvbVWglMFrDNIBsVerYPcnvQBrQeLNGnm EQujGzHapmjZAx9iRir4BuyWb/Ug8AH7/v8ASs3UdW8P3llJbzX9hMjDbtaVT+XpWdo2tR2Gj6nD 9qS6TTCfIkDZ3oRlRnv6Uikmbl/rGm6UFS6uEjZh8sajcx+ijmq2keINKvVjtY7kLNtwI5VKFvoD 1qHw5YRw2Y1K9eOXUbtfMllYglQeij0AFWbjTbHV9JSC52btoKSAjdG3Yg0DtozS2eXuKjAxyB0r F8E/8i4v/XxN/wChmpfDV/NeaS8d22bm1kaCVv7xXv8AliovBH/IuL/18Tf+hmmSHjf/AJFS7/4D /wChCtlLu22D/SIun98Vj+N/+RUu/wDgP/oQqVfCPh4qD/ZFryP7lAjVS4hkbbHLG59FYE1hawM+ LtBz6zf+gGtGy0DSdNuPPstPhglxt3ouDis/WP8AkbtB+s3/AKBQBBd283ha8fUbGNpNMlbN1bKP 9Uf76j+Yrore5iu7eO4t3WSKRQyuOhFSFVIIIyD1BrmJY5PCN41zCrSaPO+ZYxz9lYn7wH931oA6 S4/49pf9w/yrH8F/8ijp/wD1z/qa1XlSayeSN1dHjJVl5BGOtZPgz/kULD/rmf5mgCe88T6TY3Jt prrMq/fEaM4T/eIHH41pW88V1Cs0EiyROMq6HIIrl/Dl9Z6THLpOplbW9MzF2mGBcZJwwboeO1dL ZWltZW4itI1jiJLBV6ZPNAFiiiigAooooASmPDHIQXQEipKKAIPskH/PMUfZYP8AnmKmooHzPuQ/ ZIP+eQo+yQdox+dTUUBzPuQ/ZIMf6sUfZIP+eYqaigOZ9yH7JB/zzFH2WD/nmKmooC7IfskH/PMU fZYP+eYqaigOZ9yH7Lb/APPIUfZIP+eYqaloDml3IPskH/PJaPskH/PIVNRQHNLuZ+p6Pbajp01o y7PMXAYdVPY/nWdod7HJ/wASvU41i1K3G1gTgTAdHX1zXQ1S1PSLHVY1W8hDFOUdTh0PqCORQHM+ 5OLWDH+rFV72Sw063e5u2SKJRyWPX6etZ40DUovkt/Ed5HH6PGkh/M0+38L2a3Aur6afUZ1+61y2 VX6L0oHzPuVvD9ob+7utcuYDElyBHbRN1WMdz7moNB07T477UdMvLOCS4iuGlQyRglo3OQRnqB0r qwABWbqei22pvHKzSQXMX+ruIW2uvtn09qBXG3Oi6WsDkadaqVGc+Uvas5rLSde0K+XTLWOPcHiW RYgu5h0I9Rmpm8OXVyvl6hrt5dQd4lVY9w9CRya07eGPToUt4kEdsgwgUcIPT/69IabMzw+LDUtG hc20QniTypoyvKOvBBq4n2Gx0lbidIo4o49zMVHAqC/8PwXdyb60uZrK6YfNLbtw49x0NVbLwwlw kM2p6hcagqYZIpMLGD7qOtHUrmbjuS+FLdv7Nub6WLy2vrh51UjBCnp/j+NHgn/kXF/6+Jv/AEM1 thgw2p93pkdKw4/CFpApWDUtUhQsW2R3RVQScngCmQO8b/8AIqXf1T/0IVup9xfpWXJoFvPo0ml3 FxdzQyNuLyy7pOufvH6VXHhSLH/IY1j/AMDD/hQI3q57WP8Akb9B+s3/AKBVyx0JNPuhcLqOozkA jZPcl1/KrFxpsFzqFrfSF/NtC3l4PB3DBzQBdprxpIjI6hlYYIPQilHSloA5KZZfCLyIN0miz5we ptWPb/dNWvC1zFY+CLS5nYrHFEWcgZwMmt+aGKeB4ZY1eN1wysMgiq1jptvp+nLYRLugUFQr8/Ke 1ABJBYaxYo00MVzBKoZd654Pp6Vh6JdDSP7YtgZp7OwmURAfMygjlRk9jVlfDU1sDFp2s3VnbMST CqqwXP8AdJ5Wr1potnZ6a9hEH8uQku7NlnY9ST60AOOsWqh95dGR0RlYchmxgfrz9DV8VnSaNaSl y4fL78nd/e6/lzj0ya0FoAdRRRQAUlVb29i0+3a4nEpjXljHGz7R6kAdKhtNXt7y5jhjSYGWJpVM kRTKggdDg/xCnZicknY0aKSo/Oj87yd48zbu255x0zSGS0lIc1BZ3kd5HI8YYCOV4juHdTg/yoFc s0VG88URQSSKpkbamT944JwPwB/Kn0DCioYriKeSZY23GF9j8dGwDj8iKgutRhs7mGGXcPMR3L8b UVcZJJ92A49aLCuty9RTQeKak0cpcRurGNtrgH7pwDg/gR+dAXJKKbURu7cTeT56CTds2553Y3Y+ uATQMnopDSHlcUALS1nQ6tbyaUdTcSQ24BILjnbnGcDPWr4o2EncWiimSyxwhTJIqBmCjccZJ4Ao AfRUcM0c8YlicOjdGU5Bp/vQMWg4Iqjd6rbWVylvIs7yyIXCwwtIdoIGTtBxyRVtTuAYDAPrRYV0 RvbR4JUFPXaSKisoI/skRO4/KOCxIqS9u47K382VWKl0T5RzlmCj9TTJ7iKwW3jdWxLKIUx2JBPP txRZlc+jVy0AAMDgUtNFQQXkc91c26Bg9syq5I4OVDDH4GjUlss0VWtbu3vLcz28qyRgspI7EHBH 6U+1uI7q1juIW3RSqGRsYyDQFyaimRSxzKWjdXUMVJBzgg4I/A06gYtLVW+u47G0a4lDFFZVIUc8 sAP1NWGZUUsxAAGST2FArjqSqVlqdtfsywGTIG4b42UMPVSRyPcVJcXcdtNbxyBs3EvlpgdDtJ5/ I0WdwurFmlqGa6gtyBNKke4MRuOMgDJ/IU9XV0DqQVIyCO4oHcfRTciloAWiiigCnqyPJo17Giln a3kCqoySdp4FYd9pz3MlqzQzEw6Y+0oWXbJ8mBx346e1dPikwaqMrGcoKRx1rHqsmpwyXDOlwZUb PlSk+VgZGc7AOuc8irniK3vJ7uVYBcBHtY13Q5GD5y5wR325/CulwaMU+fW4vZq1rnKNbNb3csF1 Fd/2THMwRY/MY52IQePmK53dO9ULCO8t9PvreOG+jN3lbVXVyc+a5JY/w8FTk44rusGjb60/aaCd LW9zjfs00+oxqLe6lRLwSmWRXVlO2Tg84IHy4I4wQKdDa3djY2FvAZhJqkKxTiR2LRvjLPycjjI4 6HFdhg1E9rFJcpcMgMsYKo3oD1xRzj9nbUxLqE2+vWZt4Z3A2rs2tswSdz7hxuHfd14xUXiaxlmu xcQQyvIljOqum7hiUwOO/J/yK6XBowfWlz2dx8iascfeW88ZuLgx3bzfbZDGgEhSQADap2n5RnOD 0z1rW061a2j1iTypo2luWcbclm/dryue+c4962cHNKBQ53BU7HHWr3Nqm4xXf2cQzQo4jl3SOwQq xU5IOQwz0z04qG40/VHVSkUxuonjMTMThW+zEE5/3sD6125B7UYNNVNbkuldWuc94aiuEuZiXYQG MAoYpV+fPJzIc5x6cVXeKZp5FKXZ1Q3LbX+fyvK3cc/d27PxzXU4NG2lzalcmljl0sXt/h89tHby iTyGJjwS2c+nX8KbdO1093NsvTduc6eyJIqgY4yMADnOd1dVg0Yo5w9na1jlWjn8u5/d3h1gs+HX fsKZOMH7n3cY75qjcWUVzq9stla6gbZTEZfNEoXeJVOfm7gZyRxXcYNBGaaqWJdK6tc462hkFoo1 SK9JEf8AooiEnDZbOdvQ5x97jGKksLLUY7iK8uBcG7a/WOU7mK+X5Y3cdNu7v611oGKMGk5jVJdz ndYRV8QW0s0t7DELVl8y1Rmy29Tg7VNVry21D+0Lm4shcec9xsjZi20x/Z89DwPnHX1rq8UmD6Ch TsDp3OC1W3SUomn2uqtF5ObgESZLeZGeN3V8A8jirl1b3Dsv9jQ3It1lUoJlfiXa/I3845GT0ziu ywaCKftOgvZHFW8OoLC5BnMGE+1pHHMGYbhvILnJOM/d/wAK2PDsMaXWpNbwzx27zIYvOVgWGwAk bucZrd20YNJzuUoWZzmmafdWulR3VrGVuP3gmgYbRMN7Y+jY6H86xorbVY4baNw8MqQRC1HlSsU+ UZ+6QoOc53V3mDQR701UaE6SZxdvpeqos1lbedDFdTyyvKGI8pkckYz2f5fwBq2Eupo4LzVYrlYL ku9xBFvJiYABBheccN07kV1OKMUOo30BUkupw1/p+pXUM3lx3PyQg2fmbjs/fLt3DuQBnntium07 cNKeOW3laaMMsschyZG6nBPBBzx257Vp4PrRg0nO6sEafK7nJ7roxGDTvtxsQFM0csbK8Q3DKISA T8u7pnGBg81W1K1uZotukxXQtQ2Yg4cMJPLkBK7vmA5A5712uDRimp2E6V1a5xeoQXGo6k15DBdP EIZBCWR1IcQsOFOCMkgdOTVmaOXEv2mO8N5sT7CYg+F+QdccA7s53dq6vFGMUc/kP2fmceltfRtP JKLtWnF0s7xBmxym0qCf94jHvW/oDSHSkEkRj2sVXO4b1zw2G+YZ9DWgFpwFS5XHGHKxaKKKk0Ci iikAlFFFMTCloooASiiigBaKKKACiiigBKKKKYBRRRSBBRRRTAKWiigAooopAJRRRTEFHeiikMWi iigApKKKBhRRRTEFLRRSAKKKKAEooooAKWiigYUUUUAf/9k= --_005_5A55A45AE77F5941B18E5457ECAC81880120DFB1302ESISPE7MB1co_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=6590; creation-date="Tue, 23 Mar 2010 06:50:41 GMT"; modification-date="Tue, 23 Mar 2010 06:50:41 GMT" Content-ID: <image002.jpg@01CACA6E.4BBBE9A0> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAByAUEDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2U9KT Pao57iG2haWeVI0UZLMcAVx+rfEayt2MOlxG7l6BzkJn+Z/Ck2lub0MNVru1ON/yOzdljUs7BVAy STgCmNcQpD5zTRiPGd5YAY+teL6x4g1fVpGW+uHVc/6gfKo/D/Gqjz3+oukBknuGA2xxgk4HTAFZ e1WyPchkM+VSnNI9T1Hx3odhuVbhrmQfwwjI/PpVKw+IunzRTy3qG2CsBFGuWd/XiuJ/4RHXPPhg Fi3mSruC54Rf9o9q6/RPhxa2+JtWcXMnXyU4QH39aFKo3sFbC5ZQpazcn5Mkg8Zarrd2sOiaSxi3 Yaeboo/lXaJnbzUdvBDbRCKCJIo14CoMAVLWqT6nh1qlOb/dxsvxFopMijNMwFopMj1oyPWgBaKT IpaACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAx9b8PW2vpBHeSSCKFt2xDjccY5qTT/D2k6WALSxiQ93K5b8zWnikxxSsnqae2qKHJzadjzyPw Hd6vq11falN9mglmZgi8uwzx7CsfxV41tvh9qy6R4d02zmlSMNcyT7mYMegyCO39K9Tvppraxnng t2uJY4yyRL1dscD8a8Hm+H3jjVE1PVrqxC3M75eGRlMku45O3sAPr2pxhFO5tiMdXrJRk9Oy2O/8 R/ES70bwNo+uW1tbSXOo7d0b7tinblsYOeo9a5+6+NF+NE06ezsrJ9QnkkjuYn37Y8EbSvOeQf0r P1vwl4t1Hwl4b0lNInL2SyifLL8hL/KevZTUJ+FesWfje2hhsZZdJW4jY3G5cBOCc854q0lY4byO j8SfE7xDpXiYaJpmlWl3MIYyybHZzIV3MAAegp2nfF+a+8K6teyafDDqWnIjKhLGKTc236jvxmuf 1Tw744i+IF94h0vRZDIZ3MDuUIAI2g4J9KbN8NPEmn+D5kWzN1qWo3CGWKJwfKjTLDJzgkse1GgX ZaT41+IIfs1xeaPYG1mJ5iLhmAOGx8xwfqK0/EXxX1ix8Uy6TpVlYSRKE2tcsynJUE5O4Ada53QP hzrel+KtLn1DQmvLAlHnBZcRkjnIzyVP8qg1XwZ4tu/E2oanJ4Za7SeeRwkjqFIJ4PDelOyFdnXa t8SvEOjLoRurDTd2pIXmKlmVBvx8pDY6c96qJ8ap2v8AVFNna/ZYI3ayPzbpWBwu7nv14FHxB8G6 7q2i+HV0/SvMmtrby5oYiAIuAccn8K5jU/hT4igmsIbLT5JhJbRtcS7l2xysTuB57DHT0pLlG+Y9 Z+HniTV/FeiPqmp2ttbI0pSAQBhvA6k5J78fga62uW8P2WraNd22jpAg0m2g2BwB1AHOeuSf5mup qGWtgooooGFFFFABRRRQAUUUUAFFFFABRSUUALRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFJRQBDdz/Z7WSbaWKLkKo5J7AVkw3l//ZRW63x3EcgWZ1TJCn+IAfl+tbZ5FJgZpp2Ja1MU 6q1sfLt2e8VRndIfmfPZcAA4xz9aautagx2fY4t/JzubHBx6etbm0DHTj2o2j0FO67E8r7nPJrE6 XLMxZ/NOArZEcGOu4Yzj0Oec09vEMysF8iIFgSGYthcdjx1OMit7aCOn6U0wozq7KCy5wSKd12Dl l3MiDWLq9t7torRo3jXKBgc59CPXjNMOqCzH+j3El7uG4+bngj+EYX7xz0PpW7t9KTYPQetK6Hyv uYb65dRSBZLeJFd9iuWbC8E5PFNHiG6fbss1y+MIxbcn+9x37VutEj43KDtORkdDShBkn1p3j2Fy y7lLTr9r15FaBojEQr5P8fUge2MHPvWhUccax52ADJJPuTT81LLV+otFJmlpDCkoJxXP3Os3upX0 lhoSx/uTtnvJBlIz6KP4jQB0FGawh4bnlG6517Unk9YpRGv5AVFPDr+iqZ7a6Oq26cvBMoEuP9lh 1/GgDo6KpaZqlrq1kt1avuQ8EHqh7gjsau0AFFJSE4FACk4BNIjq6hlOQeQage7hwVUlzj+Bc1FZ XUQtYg25PlA+ZcUXK5Ha9i6TijOaaWDKSORjrWT4VvrnUNFFxdy+ZKZpF3YA4DkDp7Cgk2KKyPFV 7c6d4euLq0l8qZNu1sA4ywHeoRo+ulQf+Enl5H/PpHQBu5pCwzisyw03VLa6El3rj3cQBzEbdEyf XIqh4k1u70bU9PMERnikD+dEByVAByPccmgDpKKr2d7b39rHdWsiyxSDKsKsUAJRmmTsVgkYHBCk j8qzPC95cah4ds7u6k8yaVMu2AM8n0oA16KKKACiiigAooooAaTiqr32zVYLLZnzYnk3Z6bSBjH4 /pVvGapSWe/VYb0yACKJ49uOu4qc/pQVG19SgPE0LW2oP5JEtkX/AHbHHmBe4P6e1Tarqd5Z/ZGt 7WKZbhxH88pUhiCR2PHFV7nw3Fc6bcWz3G2SSaSWOVRgpuPK+47Gr15YG7S1USqn2eZZen3sAjHt 1pG79kpJoq6xrsmlzRR/Z4nzC00haXbgAgELxyeas3epvELeK1t/OublSyRs20BRjJY9hyB+NVdY 0FNWuobkzKklvGREdudr5BDfpjFWLuxmna3uIbhIryBSocrlWB6gj0yAaBfurR763/QdaalLK89v cwCC5hXeyK24Mp6EH8MVW0vXJ7xrZbqzFv8Aa4vNgZZN4YdSDwMHHNWLSwkjkmubq4Wa5mQIWVdq qo6AD8aq6Xos9o1sby8jn+xxmOBY02gZ4JOScnHFAWp2f9fcTT635Ftfy+SD9jmEWN/3shTn2+9+ lS3uozxXa2dnbLPOV8xgz7FRc4BJwepzjiql1ok1xPcKl3GlpdSLJNHsy24Y+6c8A7RVm9sp3uxe 2NzHDceX5b+Ym5XXORkZB4JNMLU9B0upTW8dmZrbZJczCJk352Eg8579P1pja3DFrjaZMhT5FZJT 90k5+X2PH406awmuYrPzrlGltphKzhMBsAjAHbr+lNm0iG6u7uS4ZZIrmNEKdCNuec/j+lIlKn1E XWk/s6W7eI/LM0KRqcl2DbQB9TUtld30sxivbFYPl3K6Sb1+h4GDVWDQvK0gWRu3aRJzNHO3LBt2 4E+ppbHSJY9TOo3lxHJOVKjyVKKQe5BJyeKCmqdnY2RS03cPUfnRuHrTOcyfFF9NZaM4tji4uHWC I+hbjP4DNW9K02HStNhsoRhY1wxH8Tdyay/FTbP7JnY/uotQjMnsOef8+tb+73H50ALQRmmSM+xv L278Hbk8Z7ZrE87xb/z76R/39k/woA1bbTrSzknkt4Vja4ffJt/iPrRe6ha6dB515OkMecZc4z9P Wsmx1bV/7fXS9Sgsl3QGbdbuzYwcc5rPs7/SL7WrvUdVvbVWglMFrDNIBsVerYPcnvQBrQeLNGnm EQujGzHapmjZAx9iRir4BuyWb/Ug8AH7/v8ASs3UdW8P3llJbzX9hMjDbtaVT+XpWdo2tR2Gj6nD 9qS6TTCfIkDZ3oRlRnv6Uikmbl/rGm6UFS6uEjZh8sajcx+ijmq2keINKvVjtY7kLNtwI5VKFvoD 1qHw5YRw2Y1K9eOXUbtfMllYglQeij0AFWbjTbHV9JSC52btoKSAjdG3Yg0DtozS2eXuKjAxyB0r F8E/8i4v/XxN/wChmpfDV/NeaS8d22bm1kaCVv7xXv8AliovBH/IuL/18Tf+hmmSHjf/AJFS7/4D /wChCtlLu22D/SIun98Vj+N/+RUu/wDgP/oQqVfCPh4qD/ZFryP7lAjVS4hkbbHLG59FYE1hawM+ LtBz6zf+gGtGy0DSdNuPPstPhglxt3ouDis/WP8AkbtB+s3/AKBQBBd283ha8fUbGNpNMlbN1bKP 9Uf76j+Yrore5iu7eO4t3WSKRQyuOhFSFVIIIyD1BrmJY5PCN41zCrSaPO+ZYxz9lYn7wH931oA6 S4/49pf9w/yrH8F/8ijp/wD1z/qa1XlSayeSN1dHjJVl5BGOtZPgz/kULD/rmf5mgCe88T6TY3Jt prrMq/fEaM4T/eIHH41pW88V1Cs0EiyROMq6HIIrl/Dl9Z6THLpOplbW9MzF2mGBcZJwwboeO1dL ZWltZW4itI1jiJLBV6ZPNAFiiiigAooooASmPDHIQXQEipKKAIPskH/PMUfZYP8AnmKmooHzPuQ/ ZIP+eQo+yQdox+dTUUBzPuQ/ZIMf6sUfZIP+eYqaigOZ9yH7JB/zzFH2WD/nmKmooC7IfskH/PMU fZYP+eYqaigOZ9yH7Lb/APPIUfZIP+eYqaloDml3IPskH/PJaPskH/PIVNRQHNLuZ+p6Pbajp01o y7PMXAYdVPY/nWdod7HJ/wASvU41i1K3G1gTgTAdHX1zXQ1S1PSLHVY1W8hDFOUdTh0PqCORQHM+ 5OLWDH+rFV72Sw063e5u2SKJRyWPX6etZ40DUovkt/Ed5HH6PGkh/M0+38L2a3Aur6afUZ1+61y2 VX6L0oHzPuVvD9ob+7utcuYDElyBHbRN1WMdz7moNB07T477UdMvLOCS4iuGlQyRglo3OQRnqB0r qwABWbqei22pvHKzSQXMX+ruIW2uvtn09qBXG3Oi6WsDkadaqVGc+Uvas5rLSde0K+XTLWOPcHiW RYgu5h0I9Rmpm8OXVyvl6hrt5dQd4lVY9w9CRya07eGPToUt4kEdsgwgUcIPT/69IabMzw+LDUtG hc20QniTypoyvKOvBBq4n2Gx0lbidIo4o49zMVHAqC/8PwXdyb60uZrK6YfNLbtw49x0NVbLwwlw kM2p6hcagqYZIpMLGD7qOtHUrmbjuS+FLdv7Nub6WLy2vrh51UjBCnp/j+NHgn/kXF/6+Jv/AEM1 thgw2p93pkdKw4/CFpApWDUtUhQsW2R3RVQScngCmQO8b/8AIqXf1T/0IVup9xfpWXJoFvPo0ml3 FxdzQyNuLyy7pOufvH6VXHhSLH/IY1j/AMDD/hQI3q57WP8Akb9B+s3/AKBVyx0JNPuhcLqOozkA jZPcl1/KrFxpsFzqFrfSF/NtC3l4PB3DBzQBdprxpIjI6hlYYIPQilHSloA5KZZfCLyIN0miz5we ptWPb/dNWvC1zFY+CLS5nYrHFEWcgZwMmt+aGKeB4ZY1eN1wysMgiq1jptvp+nLYRLugUFQr8/Ke 1ABJBYaxYo00MVzBKoZd654Pp6Vh6JdDSP7YtgZp7OwmURAfMygjlRk9jVlfDU1sDFp2s3VnbMST CqqwXP8AdJ5Wr1potnZ6a9hEH8uQku7NlnY9ST60AOOsWqh95dGR0RlYchmxgfrz9DV8VnSaNaSl y4fL78nd/e6/lzj0ya0FoAdRRRQAUlVb29i0+3a4nEpjXljHGz7R6kAdKhtNXt7y5jhjSYGWJpVM kRTKggdDg/xCnZicknY0aKSo/Oj87yd48zbu255x0zSGS0lIc1BZ3kd5HI8YYCOV4juHdTg/yoFc s0VG88URQSSKpkbamT944JwPwB/Kn0DCioYriKeSZY23GF9j8dGwDj8iKgutRhs7mGGXcPMR3L8b UVcZJJ92A49aLCuty9RTQeKak0cpcRurGNtrgH7pwDg/gR+dAXJKKbURu7cTeT56CTds2553Y3Y+ uATQMnopDSHlcUALS1nQ6tbyaUdTcSQ24BILjnbnGcDPWr4o2EncWiimSyxwhTJIqBmCjccZJ4Ao AfRUcM0c8YlicOjdGU5Bp/vQMWg4Iqjd6rbWVylvIs7yyIXCwwtIdoIGTtBxyRVtTuAYDAPrRYV0 RvbR4JUFPXaSKisoI/skRO4/KOCxIqS9u47K382VWKl0T5RzlmCj9TTJ7iKwW3jdWxLKIUx2JBPP txRZlc+jVy0AAMDgUtNFQQXkc91c26Bg9syq5I4OVDDH4GjUlss0VWtbu3vLcz28qyRgspI7EHBH 6U+1uI7q1juIW3RSqGRsYyDQFyaimRSxzKWjdXUMVJBzgg4I/A06gYtLVW+u47G0a4lDFFZVIUc8 sAP1NWGZUUsxAAGST2FArjqSqVlqdtfsywGTIG4b42UMPVSRyPcVJcXcdtNbxyBs3EvlpgdDtJ5/ I0WdwurFmlqGa6gtyBNKke4MRuOMgDJ/IU9XV0DqQVIyCO4oHcfRTciloAWiiigCnqyPJo17Giln a3kCqoySdp4FYd9pz3MlqzQzEw6Y+0oWXbJ8mBx346e1dPikwaqMrGcoKRx1rHqsmpwyXDOlwZUb PlSk+VgZGc7AOuc8irniK3vJ7uVYBcBHtY13Q5GD5y5wR325/CulwaMU+fW4vZq1rnKNbNb3csF1 Fd/2THMwRY/MY52IQePmK53dO9ULCO8t9PvreOG+jN3lbVXVyc+a5JY/w8FTk44rusGjb60/aaCd LW9zjfs00+oxqLe6lRLwSmWRXVlO2Tg84IHy4I4wQKdDa3djY2FvAZhJqkKxTiR2LRvjLPycjjI4 6HFdhg1E9rFJcpcMgMsYKo3oD1xRzj9nbUxLqE2+vWZt4Z3A2rs2tswSdz7hxuHfd14xUXiaxlmu xcQQyvIljOqum7hiUwOO/J/yK6XBowfWlz2dx8iascfeW88ZuLgx3bzfbZDGgEhSQADap2n5RnOD 0z1rW061a2j1iTypo2luWcbclm/dryue+c4962cHNKBQ53BU7HHWr3Nqm4xXf2cQzQo4jl3SOwQq xU5IOQwz0z04qG40/VHVSkUxuonjMTMThW+zEE5/3sD6125B7UYNNVNbkuldWuc94aiuEuZiXYQG MAoYpV+fPJzIc5x6cVXeKZp5FKXZ1Q3LbX+fyvK3cc/d27PxzXU4NG2lzalcmljl0sXt/h89tHby iTyGJjwS2c+nX8KbdO1093NsvTduc6eyJIqgY4yMADnOd1dVg0Yo5w9na1jlWjn8u5/d3h1gs+HX fsKZOMH7n3cY75qjcWUVzq9stla6gbZTEZfNEoXeJVOfm7gZyRxXcYNBGaaqWJdK6tc462hkFoo1 SK9JEf8AooiEnDZbOdvQ5x97jGKksLLUY7iK8uBcG7a/WOU7mK+X5Y3cdNu7v611oGKMGk5jVJdz ndYRV8QW0s0t7DELVl8y1Rmy29Tg7VNVry21D+0Lm4shcec9xsjZi20x/Z89DwPnHX1rq8UmD6Ch TsDp3OC1W3SUomn2uqtF5ObgESZLeZGeN3V8A8jirl1b3Dsv9jQ3It1lUoJlfiXa/I3845GT0ziu ywaCKftOgvZHFW8OoLC5BnMGE+1pHHMGYbhvILnJOM/d/wAK2PDsMaXWpNbwzx27zIYvOVgWGwAk bucZrd20YNJzuUoWZzmmafdWulR3VrGVuP3gmgYbRMN7Y+jY6H86xorbVY4baNw8MqQRC1HlSsU+ UZ+6QoOc53V3mDQR701UaE6SZxdvpeqos1lbedDFdTyyvKGI8pkckYz2f5fwBq2Eupo4LzVYrlYL ku9xBFvJiYABBheccN07kV1OKMUOo30BUkupw1/p+pXUM3lx3PyQg2fmbjs/fLt3DuQBnntium07 cNKeOW3laaMMsschyZG6nBPBBzx257Vp4PrRg0nO6sEafK7nJ7roxGDTvtxsQFM0csbK8Q3DKISA T8u7pnGBg81W1K1uZotukxXQtQ2Yg4cMJPLkBK7vmA5A5712uDRimp2E6V1a5xeoQXGo6k15DBdP EIZBCWR1IcQsOFOCMkgdOTVmaOXEv2mO8N5sT7CYg+F+QdccA7s53dq6vFGMUc/kP2fmceltfRtP JKLtWnF0s7xBmxym0qCf94jHvW/oDSHSkEkRj2sVXO4b1zw2G+YZ9DWgFpwFS5XHGHKxaKKKk0Ci iikAlFFFMTCloooASiiigBaKKKACiiigBKKKKYBRRRSBBRRRTAKWiigAooopAJRRRTEFHeiikMWi iigApKKKBhRRRTEFLRRSAKKKKAEooooAKWiigYUUUUAf/9k= --_005_5A55A45AE77F5941B18E5457ECAC81880120DFB1302ESISPE7MB1co_-- From Ray.Bellis@nominet.org.uk Mon Mar 22 15:58:00 2010 Return-Path: <Ray.Bellis@nominet.org.uk> 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 D221128C1E4 for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 15:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.831 X-Spam-Level: X-Spam-Status: No, score=-4.831 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_21=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 WZxVjBXzcbAl for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 15:57:58 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 9175528C1E7 for <ecrit@ietf.org>; Mon, 22 Mar 2010 15:57:58 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=FTuUMfyuuacrYuByeaYjPOkjAogEgZXyPNpZS7wm7s1bS+ATH7c6V3U1 neiigu1CHR2Asq9vu4UisspS/8kd0D8fNkZew35uJY+KoLzsU7Jm29TN7 lR7t1LV0f3CQ7zV; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269298697; x=1300834697; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Ecri t]=20ECRIT=20Direct=20(was:=20Re:=20=20ISPs=20and=20LIS =20requirements)|Date:=20Mon,=2022=20Mar=202010=2014:58:1 4=20-0800|Message-ID:=20<OF8BDB5746.55A3CA4A-ON802576EE.0 07DE9A0-882576EE.007E2E64@nominet.org.uk>|To:=20Marc=20Li nsner=20<mlinsner@cisco.com>|Cc:=20ecrit=20<ecrit@ietf.or g>|MIME-Version:=201.0|In-Reply-To:=20<C7CD416D.21810%mli nsner@cisco.com>|References:=20<5A55A45AE77F5941B18E5457E CAC81880120DFB12FFC@SISPE7MB1.commscope.com>=20<C7CD416D. 21810%mlinsner@cisco.com>; bh=T5O2dxxN4jxAG0G6AZzwajQZlL9bJarLbvV8P0rPo+w=; b=Yf+W3Kdu0XG62dxtt6VgLM0Xv/frIXD+0MCTJxVMedRJT9IF945oVZPl dI70ux6w5ghdkU+YbRfMTyRPSutZYSOVuwZEmr0leTZI6+SATWKhTiggy oF1MKn8CVSozdAH; X-IronPort-AV: E=Sophos;i="4.51,290,1267401600"; d="scan'208";a="17259255" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 22 Mar 2010 22:58:15 +0000 In-Reply-To: <C7CD416D.21810%mlinsner@cisco.com> References: <5A55A45AE77F5941B18E5457ECAC81880120DFB12FFC@SISPE7MB1.commscope.com> <C7CD416D.21810%mlinsner@cisco.com> To: Marc Linsner <mlinsner@cisco.com> MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: <OF8BDB5746.55A3CA4A-ON802576EE.007DE9A0-882576EE.007E2E64@nominet.org.uk> From: Ray.Bellis@nominet.org.uk Date: Mon, 22 Mar 2010 14:58:14 -0800 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 22/03/2010 10:58:15 PM, Serialize complete at 22/03/2010 10:58:15 PM Content-Type: multipart/alternative; boundary="=_alternative 007E2E63882576EE_=" Cc: ecrit <ecrit@ietf.org> Subject: Re: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Mar 2010 22:58:00 -0000 This is a multipart message in MIME format. --=_alternative 007E2E63882576EE_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable > ?and that LIS permitting queries from the PSAP. ? >=20 > I am obviously against forcing the access provider to establish a=20 > business/technical relationship with the PSAP. This goes well=20 > beyond requiring the access provider to supply location to it?s=20 customer. The UK design team's view was that if you assume that the client device is = either: 1. unable to provide its location, or 2. untrusted to provide its location then the =5Fonly=5F other place you can get the location from is the access= =20 provider. And, as James has pointed out, much of this is very similar to the NENA i2 = specification. Ray --=_alternative 007E2E63882576EE_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable <tt><font size=3D2><br> > “and that LIS permitting queries from the PSAP. “<br> > <br> > I am obviously against forcing the access provider to establish a <br> > business/technical relationship with the PSAP.  This goes well <br> > beyond requiring the access provider to supply location to it’s = customer.<br> </font></tt> <br><tt><font size=3D2>The UK design team's view was that if you assume that the client device is either:</font></tt> <br> <br><tt><font size=3D2>1.  unable to provide its location, or</font></= tt> <br><tt><font size=3D2>2.  untrusted to provide its location</font></t= t> <br> <br><tt><font size=3D2>then the =5Fonly=5F other place you can get the loca= tion from is the access provider.</font></tt> <br> <br><tt><font size=3D2>And, as James has pointed out, much of this is very similar to the NENA i2 specification.</font></tt> <br> <br><tt><font size=3D2>Ray</font></tt> <br> --=_alternative 007E2E63882576EE_=-- From hgs@cs.columbia.edu Mon Mar 22 16:26:06 2010 Return-Path: <hgs@cs.columbia.edu> 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 483DD3A6912 for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 16:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.481 X-Spam-Level: X-Spam-Status: No, score=0.481 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 WVFehE6pb21X for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 16:26:05 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id B37CD3A6407 for <ecrit@ietf.org>; Mon, 22 Mar 2010 16:26:04 -0700 (PDT) Received: from dhcp-wireless-open-abg-26-78.meeting.ietf.org (dhcp-wireless-open-abg-26-78.meeting.ietf.org [130.129.26.78]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o2MNQIoY027747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 22 Mar 2010 19:26:19 -0400 (EDT) References: <4BA7800A.4040406@gmx.net> <201003221619.o2MGJc2G006891@sj-core-2.cisco.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net> <BLU137-DS1318F3081E30928873CA2D93270@phx.gbl> In-Reply-To: <BLU137-DS1318F3081E30928873CA2D93270@phx.gbl> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: <62D89A2E-1066-4932-91CE-59A7798655E3@cs.columbia.edu> Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne <hgs@cs.columbia.edu> Date: Mon, 22 Mar 2010 19:26:18 -0400 To: Bernard Aboba <bernard_aboba@hotmail.com> X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: 'ECRIT' <ecrit@ietf.org> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of service attacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Mar 2010 23:26:06 -0000 One model is that a visiting user discovers the local domain (via DHCP, = say) and then uses a well-known NAI user name. For example, if a user = visits a Hilton Hotel in Anaheim, he'd use sos@anaheim.hilton.com Is that what you have in mind? Henning On Mar 22, 2010, at 2:02 PM, Bernard Aboba wrote: > Dirk said: >=20 > "So what else is in existing RFCs that could be used (instead of the = NAI > options presented in the unauthenticated draft)?" >=20 > RFC 5113 Section 2.3 describes how domain-based routing typically = functions > in AAA networks, as well as the long-term problems with use of = decorated > NAIs. As noted there, NAI-routing depends on routing table entries > maintained on proxy servers. =20 >=20 > While an NAI like "emergency" will be routed to the local AAA server, = and > "emergency@example.com" will be routed to the AAA server at = example.com > (assuming that this domain is reachable from the local network), the = NAI > "emergency@emergency.com" will result in routing to the AAA server > maintained within the emergency.com domain (assuming that this domain = was > reachable from the local network). As noted below, emergency.com is a = real > domain, so this could result in a Denial of Service attack on the = legitimate > owner of that domain.=20 >=20 > Diverting unauthenticated emergency services calls to an existing = domain > that has not authorized use of its resources for that purpose is = problematic > to say the least. =20 >=20 >=20 > ; <<>> DiG 9.6.1-P3 <<>> @192.168.1.1 emergency.com > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8716 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 >=20 > ;; QUESTION SECTION: > ;emergency.com. IN A >=20 > ;; ANSWER SECTION: > emergency.com. 3600 IN A 205.243.133.2 >=20 > ;; Query time: 118 msec > ;; SERVER: 192.168.1.1#53(192.168.1.1) > ;; WHEN: Mon Mar 22 10:56:32 2010 > ;; MSG SIZE rcvd: 47 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From bernard_aboba@hotmail.com Mon Mar 22 16:49:53 2010 Return-Path: <bernard_aboba@hotmail.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4212528C1B7 for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 16:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.302 X-Spam-Level: X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[AWL=-0.830, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 VDWMPUiRGjfe for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 16:49:52 -0700 (PDT) Received: from blu0-omc2-s36.blu0.hotmail.com (blu0-omc2-s36.blu0.hotmail.com [65.55.111.111]) by core3.amsl.com (Postfix) with ESMTP id BFC8628C1A9 for <ecrit@ietf.org>; Mon, 22 Mar 2010 16:49:51 -0700 (PDT) Received: from BLU137-W26 ([65.55.111.71]) by blu0-omc2-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 16:50:09 -0700 Message-ID: <BLU137-W26F0443F14828D573CC84493270@phx.gbl> Content-Type: multipart/alternative; boundary="_db69130c-27a8-42a6-80d8-92d3b38beb76_" X-Originating-IP: [130.129.26.108] From: Bernard Aboba <bernard_aboba@hotmail.com> To: <hgs@cs.columbia.edu> Date: Mon, 22 Mar 2010 16:50:09 -0700 Importance: Normal In-Reply-To: <62D89A2E-1066-4932-91CE-59A7798655E3@cs.columbia.edu> References: <4BA7800A.4040406@gmx.net> <201003221619.o2MGJc2G006891@sj-core-2.cisco.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net> <BLU137-DS1318F3081E30928873CA2D93270@phx.gbl>, <62D89A2E-1066-4932-91CE-59A7798655E3@cs.columbia.edu> MIME-Version: 1.0 X-OriginalArrivalTime: 22 Mar 2010 23:50:09.0742 (UTC) FILETIME=[681186E0:01CACA1A] Cc: ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of service attacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Mar 2010 23:49:53 -0000 --_db69130c-27a8-42a6-80d8-92d3b38beb76_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If all you want to do is to gain emergency access to the local network=2C y= ou don't need to discover the domain. You can just use an NAI of "sos". = That will be more convenient in situations where the local access mechanism= (e.g. 802.1X) doesn't permit IP packets (including DHCP) to pass prior to = completing authentication=2C so that "domain discovery" couldn't occur unti= l afterwards.=20 > CC: dirk.kroeselberg@nsn.com=3B ecrit@ietf.org > From: hgs@cs.columbia.edu > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of service = attacks on the emergency.com domain) > Date: Mon=2C 22 Mar 2010 19:26:18 -0400 > To: bernard_aboba@hotmail.com >=20 > One model is that a visiting user discovers the local domain (via DHCP=2C= say) and then uses a well-known NAI user name. For example=2C if a user vi= sits a Hilton Hotel in Anaheim=2C he'd use >=20 > sos@anaheim.hilton.com >=20 > Is that what you have in mind? >=20 > Henning >=20 > On Mar 22=2C 2010=2C at 2:02 PM=2C Bernard Aboba wrote: >=20 > > Dirk said: > >=20 > > "So what else is in existing RFCs that could be used (instead of the NA= I > > options presented in the unauthenticated draft)?" > >=20 > > RFC 5113 Section 2.3 describes how domain-based routing typically funct= ions > > in AAA networks=2C as well as the long-term problems with use of decora= ted > > NAIs. As noted there=2C NAI-routing depends on routing table entries > > maintained on proxy servers. =20 > >=20 > > While an NAI like "emergency" will be routed to the local AAA server=2C= and > > "emergency@example.com" will be routed to the AAA server at example.com > > (assuming that this domain is reachable from the local network)=2C the = NAI > > "emergency@emergency.com" will result in routing to the AAA server > > maintained within the emergency.com domain (assuming that this domain w= as > > reachable from the local network). As noted below=2C emergency.com is = a real > > domain=2C so this could result in a Denial of Service attack on the leg= itimate > > owner of that domain.=20 > >=20 > > Diverting unauthenticated emergency services calls to an existing domai= n > > that has not authorized use of its resources for that purpose is proble= matic > > to say the least. =20 > >=20 > >=20 > > =3B <<>> DiG 9.6.1-P3 <<>> @192.168.1.1 emergency.com > > =3B (1 server found) > > =3B=3B global options: +cmd > > =3B=3B Got answer: > > =3B=3B ->>HEADER<<- opcode: QUERY=2C status: NOERROR=2C id: 8716 > > =3B=3B flags: qr rd ra=3B QUERY: 1=2C ANSWER: 1=2C AUTHORITY: 0=2C ADDI= TIONAL: 0 > >=20 > > =3B=3B QUESTION SECTION: > > =3Bemergency.com. IN A > >=20 > > =3B=3B ANSWER SECTION: > > emergency.com. 3600 IN A 205.243.133.2 > >=20 > > =3B=3B Query time: 118 msec > > =3B=3B SERVER: 192.168.1.1#53(192.168.1.1) > > =3B=3B WHEN: Mon Mar 22 10:56:32 2010 > > =3B=3B MSG SIZE rcvd: 47 > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > >=20 >=20 = --_db69130c-27a8-42a6-80d8-92d3b38beb76_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style><!-- .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } --></style> </head> <body class=3D'hmmessage'> If all you want to do is to gain emergency access to the local network=2C y= ou don't need to discover the domain. =3B You can just use an NAI of "s= os". =3B =3B That will be more convenient in situations where the l= ocal access mechanism (e.g. 802.1X) doesn't permit IP packets (including DH= CP) to pass prior to completing authentication=2C so that "domain discovery= " couldn't occur until afterwards. <br><br><br>>=3B CC: dirk.kroeselberg@= nsn.com=3B ecrit@ietf.org<br>>=3B From: hgs@cs.columbia.edu<br>>=3B Sub= ject: Re: [Ecrit] emergency access and EAP-TLS (and denial of service attac= ks on the emergency.com domain)<br>>=3B Date: Mon=2C 22 Mar 2010 19:26:18= -0400<br>>=3B To: bernard_aboba@hotmail.com<br>>=3B <br>>=3B One mod= el is that a visiting user discovers the local domain (via DHCP=2C say) and= then uses a well-known NAI user name. For example=2C if a user visits a Hi= lton Hotel in Anaheim=2C he'd use<br>>=3B <br>>=3B sos@anaheim.hilton.c= om<br>>=3B <br>>=3B Is that what you have in mind?<br>>=3B <br>>=3B= Henning<br>>=3B <br>>=3B On Mar 22=2C 2010=2C at 2:02 PM=2C Bernard Ab= oba wrote:<br>>=3B <br>>=3B >=3B Dirk said:<br>>=3B >=3B <br>>= =3B >=3B "So what else is in existing RFCs that could be used (instead of= the NAI<br>>=3B >=3B options presented in the unauthenticated draft)?"= <br>>=3B >=3B <br>>=3B >=3B RFC 5113 Section 2.3 describes how doma= in-based routing typically functions<br>>=3B >=3B in AAA networks=2C as= well as the long-term problems with use of decorated<br>>=3B >=3B NAIs= . As noted there=2C NAI-routing depends on routing table entries<br>>=3B= >=3B maintained on proxy servers. <br>>=3B >=3B <br>>=3B >=3B W= hile an NAI like "emergency" will be routed to the local AAA server=2C and<= br>>=3B >=3B "emergency@example.com" will be routed to the AAA server a= t example.com<br>>=3B >=3B (assuming that this domain is reachable from= the local network)=2C the NAI<br>>=3B >=3B "emergency@emergency.com" w= ill result in routing to the AAA server<br>>=3B >=3B maintained within = the emergency.com domain (assuming that this domain was<br>>=3B >=3B re= achable from the local network). As noted below=2C emergency.com is a real= <br>>=3B >=3B domain=2C so this could result in a Denial of Service att= ack on the legitimate<br>>=3B >=3B owner of that domain. <br>>=3B >= =3B <br>>=3B >=3B Diverting unauthenticated emergency services calls to= an existing domain<br>>=3B >=3B that has not authorized use of its res= ources for that purpose is problematic<br>>=3B >=3B to say the least. = <br>>=3B >=3B <br>>=3B >=3B <br>>=3B >=3B =3B <=3B<=3B>= =3B>=3B DiG 9.6.1-P3 <=3B<=3B>=3B>=3B @192.168.1.1 emergency.com<= br>>=3B >=3B =3B (1 server found)<br>>=3B >=3B =3B=3B global option= s: +cmd<br>>=3B >=3B =3B=3B Got answer:<br>>=3B >=3B =3B=3B ->=3B= >=3BHEADER<=3B<=3B- opcode: QUERY=2C status: NOERROR=2C id: 8716<br>&= gt=3B >=3B =3B=3B flags: qr rd ra=3B QUERY: 1=2C ANSWER: 1=2C AUTHORITY: = 0=2C ADDITIONAL: 0<br>>=3B >=3B <br>>=3B >=3B =3B=3B QUESTION SECTI= ON:<br>>=3B >=3B =3Bemergency.com. IN A<br>>=3B = >=3B <br>>=3B >=3B =3B=3B ANSWER SECTION:<br>>=3B >=3B emergency.= com. 3600 IN A 205.243.133.2<br>>=3B >=3B <br>&g= t=3B >=3B =3B=3B Query time: 118 msec<br>>=3B >=3B =3B=3B SERVER: 192= .168.1.1#53(192.168.1.1)<br>>=3B >=3B =3B=3B WHEN: Mon Mar 22 10:56:32 = 2010<br>>=3B >=3B =3B=3B MSG SIZE rcvd: 47<br>>=3B >=3B <br>>=3B= >=3B <br>>=3B >=3B _______________________________________________<b= r>>=3B >=3B Ecrit mailing list<br>>=3B >=3B Ecrit@ietf.org<br>>= =3B >=3B https://www.ietf.org/mailman/listinfo/ecrit<br>>=3B >=3B <br= >>=3B <br> </body> </html>= --_db69130c-27a8-42a6-80d8-92d3b38beb76_-- From hgs@cs.columbia.edu Mon Mar 22 17:02:11 2010 Return-Path: <hgs@cs.columbia.edu> 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 D2DEA3A68AB for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 17:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[AWL=1.937, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, 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 OsMQ79TkQTKj for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 17:02:10 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 851C93A67CC for <ecrit@ietf.org>; Mon, 22 Mar 2010 17:02:10 -0700 (PDT) Received: from dhcp-wireless-open-abg-26-78.meeting.ietf.org (dhcp-wireless-open-abg-26-78.meeting.ietf.org [130.129.26.78]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o2N02Ous022557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 22 Mar 2010 20:02:25 -0400 (EDT) References: <4BA7800A.4040406@gmx.net> <201003221619.o2MGJc2G006891@sj-core-2.cisco.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net> <BLU137-DS1318F3081E30928873CA2D93270@phx.gbl>, <62D89A2E-1066-4932-91CE-59A7798655E3@cs.columbia.edu> <BLU137-W26F0443F14828D573CC84493270@phx.gbl> In-Reply-To: <BLU137-W26F0443F14828D573CC84493270@phx.gbl> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-15--1062431852 Message-Id: <A8BCA059-789B-4A66-B2AE-69F72C816248@cs.columbia.edu> From: Henning Schulzrinne <hgs@cs.columbia.edu> Date: Mon, 22 Mar 2010 20:02:24 -0400 To: Bernard Aboba <bernard_aboba@hotmail.com> X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of service attacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 00:02:11 -0000 --Apple-Mail-15--1062431852 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The "sos" name seems to be a reasonable approach that's simple and easy.=20= Longer term, I think a better option is to have a semi-authenticated = mode: Imagine a setup where VSPs or other trustable bodies hand out = tokens (e.g., using the OAuth-WARP work) that the ISP recognizes. The = ISP is given the right to monitor the usage of 'sos' sessions and can = hand the token to the appropriate authorities for prosecution in case of = abuse. That way, you get emergency access, but make it unlikely that the = system will be abused on a large scale. In some countries, you might get = such a token from your local public authority when you're registering = your residence. Henning On Mar 22, 2010, at 7:50 PM, Bernard Aboba wrote: > If all you want to do is to gain emergency access to the local = network, you don't need to discover the domain. You can just use an NAI = of "sos". That will be more convenient in situations where the local = access mechanism (e.g. 802.1X) doesn't permit IP packets (including = DHCP) to pass prior to completing authentication, so that "domain = discovery" couldn't occur until afterwards.=20 >=20 --Apple-Mail-15--1062431852 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><base href=3D"x-msg://681/"></head><body style=3D"word-wrap: = break-word; -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space; "><div>The "sos" name seems to be a reasonable = approach that's simple and easy. </div><div><br></div><div>Longer = term, I think a better option is to have a semi-authenticated mode: = Imagine a setup where VSPs or other trustable bodies hand out tokens = (e.g., using the OAuth-WARP work) that the ISP recognizes. The ISP is = given the right to monitor the usage of 'sos' sessions and can hand the = token to the appropriate authorities for prosecution in case of abuse. = That way, you get emergency access, but make it unlikely that the system = will be abused on a large scale. In some countries, you might get such a = token from your local public authority when you're registering your = residence.</div><div><br></div><div>Henning</div><br><div><div>On Mar = 22, 2010, at 7:50 PM, Bernard Aboba wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span = class=3D"Apple-style-span" style=3D"border-collapse: separate; = font-family: 'Lucida Grande'; font-size: medium; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; = white-space: normal; widows: 2; word-spacing: 0px; = -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; "><div class=3D"hmmessage" = style=3D"font-size: 10pt; font-family: Verdana; ">If all you want to do = is to gain emergency access to the local network, you don't need to = discover the domain.  You can just use an NAI of "sos".   = That will be more convenient in situations where the local access = mechanism (e.g. 802.1X) doesn't permit IP packets (including DHCP) to = pass prior to completing authentication, so that "domain discovery" = couldn't occur until afterwards.<span = class=3D"Apple-converted-space"> </span><br><br></div></span></blockq= uote></div><br></body></html>= --Apple-Mail-15--1062431852-- From dirk.kroeselberg@nsn.com Mon Mar 22 17:25:52 2010 Return-Path: <dirk.kroeselberg@nsn.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A76E828C28C for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 17:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.111 X-Spam-Level: X-Spam-Status: No, score=0.111 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, 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 pcfwSaqwj0m7 for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 17:25:51 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 904F228C289 for <ecrit@ietf.org>; Mon, 22 Mar 2010 17:25:50 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2N0PuwU019414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Mar 2010 01:25:56 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2N0Ptto014370; Tue, 23 Mar 2010 01:25:55 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 01:25:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CACA1F.6690EAA7" Date: Tue, 23 Mar 2010 01:25:56 +0100 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF67025DB1AB@DEMUEXC030.nsn-intra.net> In-Reply-To: <A8BCA059-789B-4A66-B2AE-69F72C816248@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of service attacks on the emergency.com domain) Thread-Index: AcrKHCJKQqodSPMDR0+Np+7IzFyjhAAAlXlg References: <4BA7800A.4040406@gmx.net> <201003221619.o2MGJc2G006891@sj-core-2.cisco.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net> <BLU137-DS1318F3081E30928873CA2D93270@phx.gbl>, <62D89A2E-1066-4932-91CE-59A7798655E3@cs.columbia.edu> <BLU137-W26F0443F14828D573CC84493270@phx.gbl> <A8BCA059-789B-4A66-B2AE-69F72C816248@cs.columbia.edu> From: "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com> To: "ext Henning Schulzrinne" <hgs@cs.columbia.edu>, "Bernard Aboba" <bernard_aboba@hotmail.com> X-OriginalArrivalTime: 23 Mar 2010 00:25:55.0483 (UTC) FILETIME=[67079EB0:01CACA1F] Cc: ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of service attacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 00:25:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CACA1F.6690EAA7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable yes, fixing the NAI to a simple string is simple (this would basically be a NAI that is username only, correct?). =20 However, let me repeat my question from the other thread: How to handle the 'authenticated' emergency case where the NAI carries the regular username? The draft may be about unauthenticated, but just covering unauthenticated and leaving the authenticated case open seems less useful to me. =20 Dirk ________________________________ From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Tuesday, March 23, 2010 1:02 AM To: Bernard Aboba Cc: Kroeselberg, Dirk (NSN - DE/Munich); ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of service attacks on the emergency.com domain) =09 =09 The "sos" name seems to be a reasonable approach that's simple and easy.=20 Longer term, I think a better option is to have a semi-authenticated mode: Imagine a setup where VSPs or other trustable bodies hand out tokens (e.g., using the OAuth-WARP work) that the ISP recognizes. The ISP is given the right to monitor the usage of 'sos' sessions and can hand the token to the appropriate authorities for prosecution in case of abuse. That way, you get emergency access, but make it unlikely that the system will be abused on a large scale. In some countries, you might get such a token from your local public authority when you're registering your residence. Henning On Mar 22, 2010, at 7:50 PM, Bernard Aboba wrote: =09 If all you want to do is to gain emergency access to the local network, you don't need to discover the domain. You can just use an NAI of "sos". That will be more convenient in situations where the local access mechanism (e.g. 802.1X) doesn't permit IP packets (including DHCP) to pass prior to completing authentication, so that "domain discovery" couldn't occur until afterwards.=20 =09 =09 ------_=_NextPart_001_01CACA1F.6690EAA7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"><BASE=20 href=3Dx-msg://681/> <META content=3D"MSHTML 6.00.2900.3660" name=3DGENERATOR></HEAD> <BODY=20 style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; = webkit-line-break: after-white-space"> <DIV><SPAN class=3D875141900-23032010><FONT face=3DArial color=3D#0000ff = size=3D2>yes,=20 fixing the NAI to a simple string is simple (this would basically be a = NAI that=20 is username only, correct?).</FONT></SPAN></DIV> <DIV><SPAN class=3D875141900-23032010><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D875141900-23032010><FONT face=3DArial color=3D#0000ff = size=3D2>However, let me repeat my question from the other thread: How = to handle=20 the 'authenticated' emergency case where the NAI carries the regular = username?=20 The draft may be about unauthenticated, but just covering=20 unauthenticated and leaving the authenticated case open=20 seems less useful to me.</FONT></SPAN></DIV> <DIV><SPAN class=3D875141900-23032010><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D875141900-23032010><FONT face=3DArial color=3D#0000ff = size=3D2>Dirk</FONT></SPAN></DIV><BR> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ext Henning Schulzrinne=20 [mailto:hgs@cs.columbia.edu] <BR><B>Sent:</B> Tuesday, March 23, 2010 = 1:02=20 AM<BR><B>To:</B> Bernard Aboba<BR><B>Cc:</B> Kroeselberg, Dirk (NSN -=20 DE/Munich); ecrit@ietf.org<BR><B>Subject:</B> Re: [Ecrit] emergency = access and=20 EAP-TLS (and denial of service attacks on the emergency.com=20 domain)<BR></FONT><BR></DIV> <DIV></DIV> <DIV>The "sos" name seems to be a reasonable approach that's simple = and=20 easy. </DIV> <DIV><BR></DIV> <DIV>Longer term, I think a better option is to have a = semi-authenticated=20 mode: Imagine a setup where VSPs or other trustable bodies hand out = tokens=20 (e.g., using the OAuth-WARP work) that the ISP recognizes. The ISP is = given=20 the right to monitor the usage of 'sos' sessions and can hand the = token to the=20 appropriate authorities for prosecution in case of abuse. That way, = you get=20 emergency access, but make it unlikely that the system will be abused = on a=20 large scale. In some countries, you might get such a token from your = local=20 public authority when you're registering your residence.</DIV> <DIV><BR></DIV> <DIV>Henning</DIV><BR> <DIV> <DIV>On Mar 22, 2010, at 7:50 PM, Bernard Aboba wrote:</DIV><BR=20 class=3DApple-interchange-newline> <BLOCKQUOTE type=3D"cite"><SPAN class=3DApple-style-span=20 style=3D"WORD-SPACING: 0px; FONT: medium 'Lucida Grande'; = TEXT-TRANSFORM: none; TEXT-INDENT: 0px; WHITE-SPACE: normal; = LETTER-SPACING: normal; BORDER-COLLAPSE: separate; orphans: 2; widows: = 2; webkit-border-horizontal-spacing: 0px; = webkit-border-vertical-spacing: 0px; webkit-text-decorations-in-effect: = none; webkit-text-size-adjust: auto; webkit-text-stroke-width: 0px"> <DIV class=3Dhmmessage style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Verdana">If all=20 you want to do is to gain emergency access to the local network, you = don't=20 need to discover the domain.  You can just use an NAI of=20 "sos".   That will be more convenient in situations where = the=20 local access mechanism (e.g. 802.1X) doesn't permit IP packets = (including=20 DHCP) to pass prior to completing authentication, so that "domain = discovery"=20 couldn't occur until afterwards.<SPAN=20 = class=3DApple-converted-space> </SPAN><BR><BR></DIV></SPAN></BLOCKQU= OTE></DIV><BR></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01CACA1F.6690EAA7-- From Martin.Dawson@andrew.com Mon Mar 22 17:52:06 2010 Return-Path: <Martin.Dawson@andrew.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 916DA3A6880 for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 17:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.132 X-Spam-Level: ** X-Spam-Status: No, score=2.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, EXTRA_MPART_TYPE=1, 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 T0kJV6zKo8yG for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 17:51:57 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id C70E83A680D for <ecrit@ietf.org>; Mon, 22 Mar 2010 17:51:56 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:33075 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S196563Ab0CWAwO (ORCPT <rfc822;ecrit@ietf.org>); Mon, 22 Mar 2010 19:52:14 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 22 Mar 2010 19:52:14 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 23 Mar 2010 08:52:13 +0800 From: "Dawson, Martin" <Martin.Dawson@andrew.com> To: ecrit <ecrit@ietf.org> Date: Tue, 23 Mar 2010 08:52:11 +0800 Thread-Topic: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) Thread-Index: AcrKA1Q1g8OpYGRevUanw+3rrw4wnwAAjCqgAAMDCrAAA9B+MA== Message-ID: <8B0A9FCBB9832F43971E38010638454F03E24ECE70@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880120DFB12FFC@SISPE7MB1.commscope.com> <C7CD416D.21810%mlinsner@cisco.com> In-Reply-To: <C7CD416D.21810%mlinsner@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_8B0A9FCBB9832F43971E38010638454F03E24ECE70SISPE7MB1comm_"; type="multipart/alternative" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Subject: Re: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 00:52:06 -0000 --_004_8B0A9FCBB9832F43971E38010638454F03E24ECE70SISPE7MB1comm_ Content-Type: multipart/alternative; boundary="_000_8B0A9FCBB9832F43971E38010638454F03E24ECE70SISPE7MB1comm_" --_000_8B0A9FCBB9832F43971E38010638454F03E24ECE70SISPE7MB1comm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Marc, Though this already happens. The reason we have POTS and cellular E9-1-1 is= that operators are required to give PSAPs access to their network location= service. You don't want that requirement to continue for the IP service in= addition to the circuit service. You are entitled to your opinion on this. Nevertheless, it's the only thing= that will allow an enhanced emergency calling service to be supported in t= he future. Given Internet based emergency calling will eventually replace (= fixed and mobile) circuit based emergency calling, a failure to introduce t= his regulation would result in a real effective deterioration in the qualit= y of emergency services. I'm not sure if that's your goal. Cheers, Martin ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of M= arc Linsner Sent: Tuesday, 23 March 2010 9:47 AM To: Winterbottom, James; ecrit Subject: Re: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) James, >From Ray's message: "and that LIS permitting queries from the PSAP. " I am obviously against forcing the access provider to establish a business/= technical relationship with the PSAP. This goes well beyond requiring the = access provider to supply location to it's customer. -Marc- On 3/22/10 2:29 PM, "Winterbottom, James" <James.Winterbottom@andrew.com> w= rote: Hi Marc, Requiring the access network to have a location service suitable for provid= ing routing and dispatch information for emergency services is a fundamenta= l aspect of i2, i3 and ECRIT. Furthermore, the LIS needs to provide locatio= n information that will result in a valid route to the PSAP. If civic locat= ion information is used then this must line-up with the profiles for civic = fields used in the local LoST server, so much of the relationships and requ= irements are you concerned about below are already pivotal to deployment of= the basic ECRIT solution as defined in phone BCP. What Ray is talking about from this point is that there is likely to regula= tion in the UK requiring ISPs and access providers to have a LIS, largely b= ecause this is seemed to be the best way to enable progression towards a NG= emergency solution. Experience in the cellular world, clearly show that wi= thout regulation access providers will not put this equipment in place so t= hat the services can progress. Discussions I have had with carriers has res= ulted in the same answer, without regulation they are not going to spend th= e money required to make it happen. This impacts all the solutions not just= ECRIT Direct. Cheers James [cid:image001.jpg@01CACA7E.0B17A730] James Winterbottom Global Product= Manager Andrew GeoLENs IP Location Product Portfolio Email: james.winterbo= ttom@andrew.com Phone: +61-2-42-212938 Mobile: +61-448-266004 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of M= arc Linsner Sent: Tuesday, 23 March 2010 8:05 AM To: Ray.Bellis@nominet.org.uk; ecrit Subject: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) Ray, Assuming this pertains to the conversation around ECRIT Direct. IMO, it's unfortunate that regulators are led to the conclusion that you ou= tline. Forcing a business/technical relationship between an access provide= r and public safety is only going to stifle those offering or wanting to of= fer access services, in the end harming the consumer of Internet services. = But I suppose that's the intention of those proposing such to the regulato= rs. Regardless, the IETF should not put forth any architecture that forces= those relationships. I believe that using UK regulation as justification for the ECRIT Direct wo= rk will actually be detrimental to it's progress within the IETF. -Marc- On 3/22/10 10:20 AM, "Ray.Bellis@nominet.org.uk" <Ray.Bellis@nominet.org.uk= > wrote: To back up what James W just said at the mic: The proposed UK model for emergency service access over VoIP depends on eac= h ISP running a LIS and that LIS permitting queries from the PSAP. It's my belief that this will be enshrined in UK law via the introduction b= y OFCOM of a new "General Condition of Service" which will apply to any pub= lic telecommunications provider, including pure IP access providers. Ray --_000_8B0A9FCBB9832F43971E38010638454F03E24ECE70SISPE7MB1comm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" xmlns=3D"http://ww= w.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <title>Re: [Ecrit] ECRIT Direct (was: Re:  ISPs and LIS requirements)<= /title> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"country-region"/> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"City"/> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"place"/> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"PersonName"/> <!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!-- /* Font Definitions */ @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:blue; text-decoration:underline;} p {mso-margin-top-alt:auto; margin-right:0cm; mso-margin-bottom-alt:auto; margin-left:0cm; font-size:12.0pt; font-family:"Times New Roman";} span.EmailStyle18 {mso-style-type:personal-reply; font-family:Arial; color:navy;} @page Section1 {size:595.3pt 841.9pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-AU link=3Dblue vlink=3Dblue> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>Hi Marc,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>Though this already happens. The reaso= n we have POTS and cellular E9-1-1 is that operators are required to give PSAPs access to their network location service. You don’t want that require= ment to continue for the IP service in addition to the circuit service.<o:p></o:= p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>You are entitled to your opinion on th= is. Nevertheless, it’s the only thing that will allow an enhanced emergency calling ser= vice to be supported in the future. Given Internet based emergency calling will eventually replace (fixed and mobile) circuit based emergency calling, a failure to introduce this regulation would result in a real effective deterioration in the quality of emergency services.<o:p></o:p></span></font= ></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>I’m not sure if that’s you= r goal.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>Cheers,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>Martin<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz= e=3D3 face=3D"Times New Roman"><span lang=3DEN-US style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span lang=3DEN-US style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span>= </font></b><font size=3D2 face=3DTahoma><span lang=3DEN-US style=3D'font-size:10.0pt;font-fa= mily:Tahoma'> ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] <b><span style=3D'font-weight:bold'>On Behalf Of </span></b>Marc Linsner<br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, 23 March 2010= 9:47 AM<br> <b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName w:st=3D"= on">Winterbottom, James</st1:PersonName>; ecrit<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [Ecrit] ECRIT D= irect (was: Re: ISPs and LIS requirements)</span></font><span lang=3DEN-US><o:p><= /o:p></span></p> </div> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D= 'font-size: 12.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 face=3DC= alibri><span style=3D'font-size:11.0pt;font-family:Calibri'>James,<br> <br> >From Ray’s message:<br> <br> “and that LIS permitting queries from the PSAP. “<br> <br> I am obviously against forcing the access provider to establish a business/technical relationship with the PSAP.  This goes well beyond requiring the access provider to supply location to it’s customer.<br= > <br> -Marc-<br> <br> On 3/22/10 2:29 PM, "<st1:PersonName w:st=3D"on">Winterbottom, James</= st1:PersonName>" <<a href=3D"James.Winterbottom@andrew.com">James.Winterbottom@andrew.com= </a>> wrote:</span></font><o:p></o:p></p> <p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 color=3D= navy face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'>= Hi Marc,<br>  <br> Requiring the access network to have a location service suitable for provid= ing routing and dispatch information for emergency services is a fundamental as= pect of i2, i3 and ECRIT. Furthermore, the LIS needs to provide location informa= tion that will result in a valid route to the PSAP. If civic location informatio= n is used then this must line-up with the profiles for civic fields used in the local LoST server, so much of the relationships and requirements are you concerned about below are already pivotal to deployment of the basic ECRIT solution as defined in phone BCP.<br>  <br> What Ray is talking about from this point is that there is likely to regula= tion in the <st1:country-region w:st=3D"on"><st1:place w:st=3D"on">UK</st1:place= ></st1:country-region> requiring ISPs and access providers to have a LIS, largely because this is seemed to be the best way to enable progression towards a NG emergency solution. Experience in the cellular world, clearly show that without regulation access providers will not put this equipment in place so that th= e services can progress. Discussions I have had with carriers has resulted in= the same answer, without regulation they are not going to spend the money requi= red to make it happen. This impacts all the solutions not just ECRIT Direct.<br= >  <br> Cheers<br> James<br>  <br>  <br> </span></font><font size=3D2 face=3DCalibri><span style=3D'font-size:11.0pt= ; font-family:Calibri'><br>   </span></font><font color=3Dnavy><span style=3D'color:navy'><im= g border=3D0 width=3D321 height=3D114 id=3D"_x0000_i1025" src=3D"cid:image001.jpg@01CACA7E.0B17A730"></span></font><font size=3D2 face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri'>  =  </span></font><b><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-f= amily:Calibri; color:navy;font-weight:bold'>James Winterbottom</span></font></b><font size= =3D2 face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri'> </span= ></font><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-f= amily:Calibri; color:navy'>Global Product Manager</span></font><font size=3D2 face=3DCalib= ri><span style=3D'font-size:11.0pt;font-family:Calibri'> </span></font><font size=3D= 2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-family:Cal= ibri; color:navy'>Andrew GeoLENs</span></font><font size=3D2 face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri'> </span></font><font size=3D= 2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-family:Cal= ibri; color:navy'>IP Location Product Portfolio</span></font><font size=3D2 face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri'> </span= ></font><b><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-f= amily:Calibri; color:navy;font-weight:bold'>Email:</span></font></b><font size=3D2 color= =3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-family:Calibri;color:na= vy'> <a href=3D"james.winterbottom@andrew.com">james.winterbottom@andrew.com</a></s= pan></font><font size=3D2 face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri= '> </span></font><b><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-f= amily:Calibri; color:navy;font-weight:bold'>Phone:</span></font></b><font size=3D2 color= =3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-family:Calibri;color:na= vy'> +61-2-42-212938</span></font><font size=3D2 face=3DCalibri><span style=3D'f= ont-size: 11.0pt;font-family:Calibri'> </span></font><st1:City w:st=3D"on"><st1:place w:st=3D"on"><b><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'f= ont-size:10.0pt; font-family:Calibri;color:navy;font-weight:bold'>Mobile</span></font></b>= </st1:place></st1:City><b><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-f= amily:Calibri; color:navy;font-weight:bold'>:</span></font></b><font size=3D2 color=3Dnavy face=3DCalibri><span style=3D'font-size:10.0pt;font-family:Calibri;color:na= vy'> +61-448-266004</span></font><font size=3D2 face=3DCalibri><span style=3D'fo= nt-size: 11.0pt;font-family:Calibri'>  </span></font><o:p></o:p></p> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz= e=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter> </span></font></div> <p style=3D'margin-bottom:12.0pt'><b><font size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span>= </font></b><font size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>= <a href=3D"ecrit-bounces@ietf.org">ecrit-bounces@ietf.org</a> [<a href=3D"mailto:ecrit-bounces@ietf.org">mailto:ecrit-bounces@ietf.org</a>] <= b><span style=3D'font-weight:bold'>On Behalf Of </span></b>Marc Linsner<br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, 23 March 2010= 8:05 AM<br> <b><span style=3D'font-weight:bold'>To:</span></b> <a href=3D"Ray.Bellis@nominet.org.uk">Ray.Bellis@nominet.org.uk</a>; ecrit<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> [Ecrit] ECRIT Direc= t (was: Re: ISPs and LIS requirements)<br> </span></font><br> <font size=3D2 face=3DCalibri><span style=3D'font-size:11.0pt;font-family:C= alibri'>Ray,<br> <br> Assuming this pertains to the conversation around ECRIT Direct.<br> <br> IMO, it’s unfortunate that regulators are led to the conclusion that = you outline.  Forcing a business/technical relationship between an access provider and public safety is only going to stifle those offering or wantin= g to offer access services, in the end harming the consumer of Internet services= .  But I suppose that’s the intention of those proposing such to t= he regulators.  Regardless, the IETF should not put forth any architectur= e that forces those relationships.<br> <br> I believe that using <st1:country-region w:st=3D"on"><st1:place w:st=3D"on"= >UK</st1:place></st1:country-region> regulation as justification for the ECRIT Direct work will actually be detrimental to it’s progress within the IETF.<br> <br> -Marc-<br> <br> <br> <br> <br> On 3/22/10 10:20 AM, "<a href=3D"Ray.Bellis@nominet.org.uk">Ray.Bellis= @nominet.org.uk</a>" <<a href=3D"Ray.Bellis@nominet.org.uk">Ray.Bellis@nominet.org.uk</a>> wrote:<br> To back up what James W just said at the mic: <br> <br> The proposed <st1:country-region w:st=3D"on"><st1:place w:st=3D"on">UK</st1= :place></st1:country-region> model for emergency service access over VoIP depends on each ISP running a = LIS and that LIS permitting queries from the PSAP. <br> <br> It's my belief that this will be enshrined in <st1:country-region w:st=3D"o= n"><st1:place w:st=3D"on">UK</st1:place></st1:country-region> law via the introduction b= y OFCOM of a new "General Condition of Service" which will apply to= any public telecommunications provider, including pure IP access providers. <br= > <br> Ray </span></font><o:p></o:p></p> </div> </body> </html> --_000_8B0A9FCBB9832F43971E38010638454F03E24ECE70SISPE7MB1comm_-- --_004_8B0A9FCBB9832F43971E38010638454F03E24ECE70SISPE7MB1comm_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6590; creation-date="Tue, 23 Mar 2010 08:52:11 GMT"; modification-date="Tue, 23 Mar 2010 08:52:11 GMT" Content-ID: <image001.jpg@01CACA7E.0B17A730> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAByAUEDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2U9KT Pao57iG2haWeVI0UZLMcAVx+rfEayt2MOlxG7l6BzkJn+Z/Ck2lub0MNVru1ON/yOzdljUs7BVAy STgCmNcQpD5zTRiPGd5YAY+teL6x4g1fVpGW+uHVc/6gfKo/D/Gqjz3+oukBknuGA2xxgk4HTAFZ e1WyPchkM+VSnNI9T1Hx3odhuVbhrmQfwwjI/PpVKw+IunzRTy3qG2CsBFGuWd/XiuJ/4RHXPPhg Fi3mSruC54Rf9o9q6/RPhxa2+JtWcXMnXyU4QH39aFKo3sFbC5ZQpazcn5Mkg8Zarrd2sOiaSxi3 Yaeboo/lXaJnbzUdvBDbRCKCJIo14CoMAVLWqT6nh1qlOb/dxsvxFopMijNMwFopMj1oyPWgBaKT IpaACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAx9b8PW2vpBHeSSCKFt2xDjccY5qTT/D2k6WALSxiQ93K5b8zWnikxxSsnqae2qKHJzadjzyPw Hd6vq11falN9mglmZgi8uwzx7CsfxV41tvh9qy6R4d02zmlSMNcyT7mYMegyCO39K9Tvppraxnng t2uJY4yyRL1dscD8a8Hm+H3jjVE1PVrqxC3M75eGRlMku45O3sAPr2pxhFO5tiMdXrJRk9Oy2O/8 R/ES70bwNo+uW1tbSXOo7d0b7tinblsYOeo9a5+6+NF+NE06ezsrJ9QnkkjuYn37Y8EbSvOeQf0r P1vwl4t1Hwl4b0lNInL2SyifLL8hL/KevZTUJ+FesWfje2hhsZZdJW4jY3G5cBOCc854q0lY4byO j8SfE7xDpXiYaJpmlWl3MIYyybHZzIV3MAAegp2nfF+a+8K6teyafDDqWnIjKhLGKTc236jvxmuf 1Tw744i+IF94h0vRZDIZ3MDuUIAI2g4J9KbN8NPEmn+D5kWzN1qWo3CGWKJwfKjTLDJzgkse1GgX ZaT41+IIfs1xeaPYG1mJ5iLhmAOGx8xwfqK0/EXxX1ix8Uy6TpVlYSRKE2tcsynJUE5O4Ada53QP hzrel+KtLn1DQmvLAlHnBZcRkjnIzyVP8qg1XwZ4tu/E2oanJ4Za7SeeRwkjqFIJ4PDelOyFdnXa t8SvEOjLoRurDTd2pIXmKlmVBvx8pDY6c96qJ8ap2v8AVFNna/ZYI3ayPzbpWBwu7nv14FHxB8G6 7q2i+HV0/SvMmtrby5oYiAIuAccn8K5jU/hT4igmsIbLT5JhJbRtcS7l2xysTuB57DHT0pLlG+Y9 Z+HniTV/FeiPqmp2ttbI0pSAQBhvA6k5J78fga62uW8P2WraNd22jpAg0m2g2BwB1AHOeuSf5mup qGWtgooooGFFFFABRRRQAUUUUAFFFFABRSUUALRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFJRQBDdz/Z7WSbaWKLkKo5J7AVkw3l//ZRW63x3EcgWZ1TJCn+IAfl+tbZ5FJgZpp2Ja1MU 6q1sfLt2e8VRndIfmfPZcAA4xz9aautagx2fY4t/JzubHBx6etbm0DHTj2o2j0FO67E8r7nPJrE6 XLMxZ/NOArZEcGOu4Yzj0Oec09vEMysF8iIFgSGYthcdjx1OMit7aCOn6U0wozq7KCy5wSKd12Dl l3MiDWLq9t7torRo3jXKBgc59CPXjNMOqCzH+j3El7uG4+bngj+EYX7xz0PpW7t9KTYPQetK6Hyv uYb65dRSBZLeJFd9iuWbC8E5PFNHiG6fbss1y+MIxbcn+9x37VutEj43KDtORkdDShBkn1p3j2Fy y7lLTr9r15FaBojEQr5P8fUge2MHPvWhUccax52ADJJPuTT81LLV+otFJmlpDCkoJxXP3Os3upX0 lhoSx/uTtnvJBlIz6KP4jQB0FGawh4bnlG6517Unk9YpRGv5AVFPDr+iqZ7a6Oq26cvBMoEuP9lh 1/GgDo6KpaZqlrq1kt1avuQ8EHqh7gjsau0AFFJSE4FACk4BNIjq6hlOQeQage7hwVUlzj+Bc1FZ XUQtYg25PlA+ZcUXK5Ha9i6TijOaaWDKSORjrWT4VvrnUNFFxdy+ZKZpF3YA4DkDp7Cgk2KKyPFV 7c6d4euLq0l8qZNu1sA4ywHeoRo+ulQf+Enl5H/PpHQBu5pCwzisyw03VLa6El3rj3cQBzEbdEyf XIqh4k1u70bU9PMERnikD+dEByVAByPccmgDpKKr2d7b39rHdWsiyxSDKsKsUAJRmmTsVgkYHBCk j8qzPC95cah4ds7u6k8yaVMu2AM8n0oA16KKKACiiigAooooAaTiqr32zVYLLZnzYnk3Z6bSBjH4 /pVvGapSWe/VYb0yACKJ49uOu4qc/pQVG19SgPE0LW2oP5JEtkX/AHbHHmBe4P6e1Tarqd5Z/ZGt 7WKZbhxH88pUhiCR2PHFV7nw3Fc6bcWz3G2SSaSWOVRgpuPK+47Gr15YG7S1USqn2eZZen3sAjHt 1pG79kpJoq6xrsmlzRR/Z4nzC00haXbgAgELxyeas3epvELeK1t/OublSyRs20BRjJY9hyB+NVdY 0FNWuobkzKklvGREdudr5BDfpjFWLuxmna3uIbhIryBSocrlWB6gj0yAaBfurR763/QdaalLK89v cwCC5hXeyK24Mp6EH8MVW0vXJ7xrZbqzFv8Aa4vNgZZN4YdSDwMHHNWLSwkjkmubq4Wa5mQIWVdq qo6AD8aq6Xos9o1sby8jn+xxmOBY02gZ4JOScnHFAWp2f9fcTT635Ftfy+SD9jmEWN/3shTn2+9+ lS3uozxXa2dnbLPOV8xgz7FRc4BJwepzjiql1ok1xPcKl3GlpdSLJNHsy24Y+6c8A7RVm9sp3uxe 2NzHDceX5b+Ym5XXORkZB4JNMLU9B0upTW8dmZrbZJczCJk352Eg8579P1pja3DFrjaZMhT5FZJT 90k5+X2PH406awmuYrPzrlGltphKzhMBsAjAHbr+lNm0iG6u7uS4ZZIrmNEKdCNuec/j+lIlKn1E XWk/s6W7eI/LM0KRqcl2DbQB9TUtld30sxivbFYPl3K6Sb1+h4GDVWDQvK0gWRu3aRJzNHO3LBt2 4E+ppbHSJY9TOo3lxHJOVKjyVKKQe5BJyeKCmqdnY2RS03cPUfnRuHrTOcyfFF9NZaM4tji4uHWC I+hbjP4DNW9K02HStNhsoRhY1wxH8Tdyay/FTbP7JnY/uotQjMnsOef8+tb+73H50ALQRmmSM+xv L278Hbk8Z7ZrE87xb/z76R/39k/woA1bbTrSzknkt4Vja4ffJt/iPrRe6ha6dB515OkMecZc4z9P Wsmx1bV/7fXS9Sgsl3QGbdbuzYwcc5rPs7/SL7WrvUdVvbVWglMFrDNIBsVerYPcnvQBrQeLNGnm EQujGzHapmjZAx9iRir4BuyWb/Ug8AH7/v8ASs3UdW8P3llJbzX9hMjDbtaVT+XpWdo2tR2Gj6nD 9qS6TTCfIkDZ3oRlRnv6Uikmbl/rGm6UFS6uEjZh8sajcx+ijmq2keINKvVjtY7kLNtwI5VKFvoD 1qHw5YRw2Y1K9eOXUbtfMllYglQeij0AFWbjTbHV9JSC52btoKSAjdG3Yg0DtozS2eXuKjAxyB0r F8E/8i4v/XxN/wChmpfDV/NeaS8d22bm1kaCVv7xXv8AliovBH/IuL/18Tf+hmmSHjf/AJFS7/4D /wChCtlLu22D/SIun98Vj+N/+RUu/wDgP/oQqVfCPh4qD/ZFryP7lAjVS4hkbbHLG59FYE1hawM+ LtBz6zf+gGtGy0DSdNuPPstPhglxt3ouDis/WP8AkbtB+s3/AKBQBBd283ha8fUbGNpNMlbN1bKP 9Uf76j+Yrore5iu7eO4t3WSKRQyuOhFSFVIIIyD1BrmJY5PCN41zCrSaPO+ZYxz9lYn7wH931oA6 S4/49pf9w/yrH8F/8ijp/wD1z/qa1XlSayeSN1dHjJVl5BGOtZPgz/kULD/rmf5mgCe88T6TY3Jt prrMq/fEaM4T/eIHH41pW88V1Cs0EiyROMq6HIIrl/Dl9Z6THLpOplbW9MzF2mGBcZJwwboeO1dL ZWltZW4itI1jiJLBV6ZPNAFiiiigAooooASmPDHIQXQEipKKAIPskH/PMUfZYP8AnmKmooHzPuQ/ ZIP+eQo+yQdox+dTUUBzPuQ/ZIMf6sUfZIP+eYqaigOZ9yH7JB/zzFH2WD/nmKmooC7IfskH/PMU fZYP+eYqaigOZ9yH7Lb/APPIUfZIP+eYqaloDml3IPskH/PJaPskH/PIVNRQHNLuZ+p6Pbajp01o y7PMXAYdVPY/nWdod7HJ/wASvU41i1K3G1gTgTAdHX1zXQ1S1PSLHVY1W8hDFOUdTh0PqCORQHM+ 5OLWDH+rFV72Sw063e5u2SKJRyWPX6etZ40DUovkt/Ed5HH6PGkh/M0+38L2a3Aur6afUZ1+61y2 VX6L0oHzPuVvD9ob+7utcuYDElyBHbRN1WMdz7moNB07T477UdMvLOCS4iuGlQyRglo3OQRnqB0r qwABWbqei22pvHKzSQXMX+ruIW2uvtn09qBXG3Oi6WsDkadaqVGc+Uvas5rLSde0K+XTLWOPcHiW RYgu5h0I9Rmpm8OXVyvl6hrt5dQd4lVY9w9CRya07eGPToUt4kEdsgwgUcIPT/69IabMzw+LDUtG hc20QniTypoyvKOvBBq4n2Gx0lbidIo4o49zMVHAqC/8PwXdyb60uZrK6YfNLbtw49x0NVbLwwlw kM2p6hcagqYZIpMLGD7qOtHUrmbjuS+FLdv7Nub6WLy2vrh51UjBCnp/j+NHgn/kXF/6+Jv/AEM1 thgw2p93pkdKw4/CFpApWDUtUhQsW2R3RVQScngCmQO8b/8AIqXf1T/0IVup9xfpWXJoFvPo0ml3 FxdzQyNuLyy7pOufvH6VXHhSLH/IY1j/AMDD/hQI3q57WP8Akb9B+s3/AKBVyx0JNPuhcLqOozkA jZPcl1/KrFxpsFzqFrfSF/NtC3l4PB3DBzQBdprxpIjI6hlYYIPQilHSloA5KZZfCLyIN0miz5we ptWPb/dNWvC1zFY+CLS5nYrHFEWcgZwMmt+aGKeB4ZY1eN1wysMgiq1jptvp+nLYRLugUFQr8/Ke 1ABJBYaxYo00MVzBKoZd654Pp6Vh6JdDSP7YtgZp7OwmURAfMygjlRk9jVlfDU1sDFp2s3VnbMST CqqwXP8AdJ5Wr1potnZ6a9hEH8uQku7NlnY9ST60AOOsWqh95dGR0RlYchmxgfrz9DV8VnSaNaSl y4fL78nd/e6/lzj0ya0FoAdRRRQAUlVb29i0+3a4nEpjXljHGz7R6kAdKhtNXt7y5jhjSYGWJpVM kRTKggdDg/xCnZicknY0aKSo/Oj87yd48zbu255x0zSGS0lIc1BZ3kd5HI8YYCOV4juHdTg/yoFc s0VG88URQSSKpkbamT944JwPwB/Kn0DCioYriKeSZY23GF9j8dGwDj8iKgutRhs7mGGXcPMR3L8b UVcZJJ92A49aLCuty9RTQeKak0cpcRurGNtrgH7pwDg/gR+dAXJKKbURu7cTeT56CTds2553Y3Y+ uATQMnopDSHlcUALS1nQ6tbyaUdTcSQ24BILjnbnGcDPWr4o2EncWiimSyxwhTJIqBmCjccZJ4Ao AfRUcM0c8YlicOjdGU5Bp/vQMWg4Iqjd6rbWVylvIs7yyIXCwwtIdoIGTtBxyRVtTuAYDAPrRYV0 RvbR4JUFPXaSKisoI/skRO4/KOCxIqS9u47K382VWKl0T5RzlmCj9TTJ7iKwW3jdWxLKIUx2JBPP txRZlc+jVy0AAMDgUtNFQQXkc91c26Bg9syq5I4OVDDH4GjUlss0VWtbu3vLcz28qyRgspI7EHBH 6U+1uI7q1juIW3RSqGRsYyDQFyaimRSxzKWjdXUMVJBzgg4I/A06gYtLVW+u47G0a4lDFFZVIUc8 sAP1NWGZUUsxAAGST2FArjqSqVlqdtfsywGTIG4b42UMPVSRyPcVJcXcdtNbxyBs3EvlpgdDtJ5/ I0WdwurFmlqGa6gtyBNKke4MRuOMgDJ/IU9XV0DqQVIyCO4oHcfRTciloAWiiigCnqyPJo17Giln a3kCqoySdp4FYd9pz3MlqzQzEw6Y+0oWXbJ8mBx346e1dPikwaqMrGcoKRx1rHqsmpwyXDOlwZUb PlSk+VgZGc7AOuc8irniK3vJ7uVYBcBHtY13Q5GD5y5wR325/CulwaMU+fW4vZq1rnKNbNb3csF1 Fd/2THMwRY/MY52IQePmK53dO9ULCO8t9PvreOG+jN3lbVXVyc+a5JY/w8FTk44rusGjb60/aaCd LW9zjfs00+oxqLe6lRLwSmWRXVlO2Tg84IHy4I4wQKdDa3djY2FvAZhJqkKxTiR2LRvjLPycjjI4 6HFdhg1E9rFJcpcMgMsYKo3oD1xRzj9nbUxLqE2+vWZt4Z3A2rs2tswSdz7hxuHfd14xUXiaxlmu xcQQyvIljOqum7hiUwOO/J/yK6XBowfWlz2dx8iascfeW88ZuLgx3bzfbZDGgEhSQADap2n5RnOD 0z1rW061a2j1iTypo2luWcbclm/dryue+c4962cHNKBQ53BU7HHWr3Nqm4xXf2cQzQo4jl3SOwQq xU5IOQwz0z04qG40/VHVSkUxuonjMTMThW+zEE5/3sD6125B7UYNNVNbkuldWuc94aiuEuZiXYQG MAoYpV+fPJzIc5x6cVXeKZp5FKXZ1Q3LbX+fyvK3cc/d27PxzXU4NG2lzalcmljl0sXt/h89tHby iTyGJjwS2c+nX8KbdO1093NsvTduc6eyJIqgY4yMADnOd1dVg0Yo5w9na1jlWjn8u5/d3h1gs+HX fsKZOMH7n3cY75qjcWUVzq9stla6gbZTEZfNEoXeJVOfm7gZyRxXcYNBGaaqWJdK6tc462hkFoo1 SK9JEf8AooiEnDZbOdvQ5x97jGKksLLUY7iK8uBcG7a/WOU7mK+X5Y3cdNu7v611oGKMGk5jVJdz ndYRV8QW0s0t7DELVl8y1Rmy29Tg7VNVry21D+0Lm4shcec9xsjZi20x/Z89DwPnHX1rq8UmD6Ch TsDp3OC1W3SUomn2uqtF5ObgESZLeZGeN3V8A8jirl1b3Dsv9jQ3It1lUoJlfiXa/I3845GT0ziu ywaCKftOgvZHFW8OoLC5BnMGE+1pHHMGYbhvILnJOM/d/wAK2PDsMaXWpNbwzx27zIYvOVgWGwAk bucZrd20YNJzuUoWZzmmafdWulR3VrGVuP3gmgYbRMN7Y+jY6H86xorbVY4baNw8MqQRC1HlSsU+ UZ+6QoOc53V3mDQR701UaE6SZxdvpeqos1lbedDFdTyyvKGI8pkckYz2f5fwBq2Eupo4LzVYrlYL ku9xBFvJiYABBheccN07kV1OKMUOo30BUkupw1/p+pXUM3lx3PyQg2fmbjs/fLt3DuQBnntium07 cNKeOW3laaMMsschyZG6nBPBBzx257Vp4PrRg0nO6sEafK7nJ7roxGDTvtxsQFM0csbK8Q3DKISA T8u7pnGBg81W1K1uZotukxXQtQ2Yg4cMJPLkBK7vmA5A5712uDRimp2E6V1a5xeoQXGo6k15DBdP EIZBCWR1IcQsOFOCMkgdOTVmaOXEv2mO8N5sT7CYg+F+QdccA7s53dq6vFGMUc/kP2fmceltfRtP JKLtWnF0s7xBmxym0qCf94jHvW/oDSHSkEkRj2sVXO4b1zw2G+YZ9DWgFpwFS5XHGHKxaKKKk0Ci iikAlFFFMTCloooASiiigBaKKKACiiigBKKKKYBRRRSBBRRRTAKWiigAooopAJRRRTEFHeiikMWi iigApKKKBhRRRTEFLRRSAKKKKAEooooAKWiigYUUUUAf/9k= --_004_8B0A9FCBB9832F43971E38010638454F03E24ECE70SISPE7MB1comm_-- From jsalowey@cisco.com Mon Mar 22 18:14:43 2010 Return-Path: <jsalowey@cisco.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33CF13A689F for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 18:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.034 X-Spam-Level: X-Spam-Status: No, score=-10.034 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAy2iODik6r2 for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 18:14:41 -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 603C33A67CC for <ecrit@ietf.org>; Mon, 22 Mar 2010 18:14:41 -0700 (PDT) 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: AhQFALeyp0urRN+J/2dsb2JhbACBQ5lnc6UIixUHjVGEfQSDHosw X-IronPort-AV: E=Sophos;i="4.51,291,1267401600"; d="scan'208,217";a="501054235" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 23 Mar 2010 01:14:59 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o2N1ExVD004743; Tue, 23 Mar 2010 01:14:59 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 18:14:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CACA26.41C39617" Date: Mon, 22 Mar 2010 18:14:59 -0700 Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE509E6BFCB@xmb-sjc-225.amer.cisco.com> In-Reply-To: <8C51C7A529FC9D49843ACF5AE2FFBF67025DB1AB@DEMUEXC030.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrKHCJKQqodSPMDR0+Np+7IzFyjhAAAlXlgAAFV0VA= References: <4BA7800A.4040406@gmx.net><201003221619.o2MGJc2G006891@sj-core-2.cisco.com><8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net><BLU137-DS1318F3081E30928873CA2D93270@phx.gbl>, <62D89A2E-1066-4932-91CE-59A7798655E3@cs.columbia.edu><BLU137-W26F0443F14828D573CC84493270@phx.gbl><A8BCA059-789B-4A66-B2AE-69F72C816248@cs.columbia.edu> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB1AB@DEMUEXC030.nsn-intra.net> From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com> To: "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com>, "ext Henning Schulzrinne" <hgs@cs.columbia.edu>, "Bernard Aboba" <bernard_aboba@hotmail.com> X-OriginalArrivalTime: 23 Mar 2010 01:14:59.0748 (UTC) FILETIME=[41F2CE40:01CACA26] Cc: ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 01:14:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CACA26.41C39617 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do not think EAP or NAI should be used as a signaling mechanism for emergency. These mechanisms are ways to obtain network access when you cannot in some other way. Once you have network access it seems that the emergency procedures should be the same whether you authenticated to get network access or you gained access though another mechanism.=20 =20 I am probably missing some ECRIT specific nuances here, but I feel that tying emergency procedures at higher layers to EAP usage will be fraught with problems.=20 =20 Joe =20 =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Kroeselberg, Dirk (NSN - DE/Munich) Sent: Monday, March 22, 2010 5:26 PM To: ext Henning Schulzrinne; Bernard Aboba Cc: ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) =20 yes, fixing the NAI to a simple string is simple (this would basically be a NAI that is username only, correct?). =20 However, let me repeat my question from the other thread: How to handle the 'authenticated' emergency case where the NAI carries the regular username? The draft may be about unauthenticated, but just covering unauthenticated and leaving the authenticated case open seems less useful to me. =20 Dirk =20 =09 ________________________________ From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Tuesday, March 23, 2010 1:02 AM To: Bernard Aboba Cc: Kroeselberg, Dirk (NSN - DE/Munich); ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of service attacks on the emergency.com domain) The "sos" name seems to be a reasonable approach that's simple and easy.=20 =20 Longer term, I think a better option is to have a semi-authenticated mode: Imagine a setup where VSPs or other trustable bodies hand out tokens (e.g., using the OAuth-WARP work) that the ISP recognizes. The ISP is given the right to monitor the usage of 'sos' sessions and can hand the token to the appropriate authorities for prosecution in case of abuse. That way, you get emergency access, but make it unlikely that the system will be abused on a large scale. In some countries, you might get such a token from your local public authority when you're registering your residence. =20 Henning =20 On Mar 22, 2010, at 7:50 PM, Bernard Aboba wrote: =09 =09 =09 If all you want to do is to gain emergency access to the local network, you don't need to discover the domain. You can just use an NAI of "sos". That will be more convenient in situations where the local access mechanism (e.g. 802.1X) doesn't permit IP packets (including DHCP) to pass prior to completing authentication, so that "domain discovery" couldn't occur until afterwards.=20 =20 ------_=_NextPart_001_01CACA26.41C39617 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <base href=3D"x-msg://681/"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <style> <!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Verdana; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.apple-style-span {mso-style-name:apple-style-span;} span.apple-converted-space {mso-style-name:apple-converted-space;} span.EmailStyle19 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple style=3D'WORD-WRAP: = break-word; webkit-nbsp-mode: space;webkit-line-break: after-white-space'> <div class=3DSection1> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'>I do not think EAP or NAI should be used as a signaling = mechanism for emergency.    These mechanisms are ways to obtain = network access when you cannot in some other way.  Once you have network access it = seems that the emergency procedures should be the same whether you = authenticated to get network access or you gained access though another mechanism. = <o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'>I am probably missing some ECRIT specific nuances here, = but I feel that tying emergency procedures at higher layers to EAP usage will be = fraught with problems. <o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'>Joe<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <div> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt = 0in 0in 0in'> <p class=3DMsoNormal><b><span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>= </b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] <b>On Behalf Of = </b>Kroeselberg, Dirk (NSN - DE/Munich)<br> <b>Sent:</b> Monday, March 22, 2010 5:26 PM<br> <b>To:</b> ext Henning Schulzrinne; Bernard Aboba<br> <b>Cc:</b> ecrit@ietf.org<br> <b>Subject:</b> Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)<o:p></o:p></span></p> </div> </div> <p class=3DMsoNormal><o:p> </o:p></p> <div> <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:blue'>yes, fixing the NAI to a simple string is simple (this would basically be a NAI that is username only, = correct?).</span><o:p></o:p></p> </div> <div> <p class=3DMsoNormal> <o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:blue'>However, let me repeat my question from the other thread: = How to handle the 'authenticated' emergency case where the NAI carries the = regular username? The draft may be about unauthenticated, but just covering unauthenticated and leaving the authenticated case open seems less useful to me.</span><o:p></o:p></p> </div> <div> <p class=3DMsoNormal> <o:p></o:p></p> </div> <div> <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:blue'>Dirk</span><o:p></o:p></p> </div> <blockquote style=3D'border:none;border-left:solid blue = 1.5pt;padding:0in 0in 0in 4.0pt; margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'= > <p class=3DMsoNormal><o:p> </o:p></p> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span = lang=3DDE> <hr size=3D2 width=3D"100%" align=3Dcenter> </span></div> <p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><span lang=3DDE style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>= </b><span lang=3DDE style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> = ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] <br> <b>Sent:</b> Tuesday, March 23, 2010 1:02 AM<br> <b>To:</b> Bernard Aboba<br> <b>Cc:</b> Kroeselberg, Dirk (NSN - DE/Munich); ecrit@ietf.org<br> <b>Subject:</b> Re: [Ecrit] emergency access and EAP-TLS (and denial of = service attacks on the emergency.com domain)</span><span = lang=3DDE><o:p></o:p></span></p> <div> <p class=3DMsoNormal>The "sos" name seems to be a reasonable = approach that's simple and easy. <o:p></o:p></p> </div> <div> <p class=3DMsoNormal><o:p> </o:p></p> </div> <div> <p class=3DMsoNormal>Longer term, I think a better option is to have a semi-authenticated mode: Imagine a setup where VSPs or other trustable = bodies hand out tokens (e.g., using the OAuth-WARP work) that the ISP = recognizes. The ISP is given the right to monitor the usage of 'sos' sessions and can = hand the token to the appropriate authorities for prosecution in case of abuse. = That way, you get emergency access, but make it unlikely that the system will = be abused on a large scale. In some countries, you might get such a token = from your local public authority when you're registering your = residence.<o:p></o:p></p> </div> <div> <p class=3DMsoNormal><o:p> </o:p></p> </div> <div> <p class=3DMsoNormal>Henning<o:p></o:p></p> </div> <p class=3DMsoNormal><o:p> </o:p></p> <div> <div> <p class=3DMsoNormal>On Mar 22, 2010, at 7:50 PM, Bernard Aboba = wrote:<o:p></o:p></p> </div> <p class=3DMsoNormal><br> <br> <o:p></o:p></p> <div> <p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span = style=3D'font-size:10.0pt; font-family:"Verdana","sans-serif"'>If all you want to do is to gain = emergency access to the local network, you don't need to discover the = domain.  You can just use an NAI of "sos".   That will be more convenient in situations where the local access mechanism (e.g. 802.1X) = doesn't permit IP packets (including DHCP) to pass prior to completing = authentication, so that "domain discovery" couldn't occur until = afterwards.<span class=3Dapple-converted-space> </span><o:p></o:p></span></p> </div> </div> <p class=3DMsoNormal><o:p> </o:p></p> </blockquote> </div> </body> </html> ------_=_NextPart_001_01CACA26.41C39617-- From dirk.kroeselberg@nsn.com Mon Mar 22 18:24:17 2010 Return-Path: <dirk.kroeselberg@nsn.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A0823A67FA for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 18:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.019 X-Spam-Level: X-Spam-Status: No, score=0.019 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, 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 cn6bBYgoDYB1 for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 18:24:15 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 5B7323A691A for <ecrit@ietf.org>; Mon, 22 Mar 2010 18:24:11 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2N1OAZj020636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Mar 2010 02:24:10 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2N1OANK023821; Tue, 23 Mar 2010 02:24:10 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 02:24:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CACA27.89323A36" Date: Tue, 23 Mar 2010 02:24:11 +0100 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF67025DB1AD@DEMUEXC030.nsn-intra.net> In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE509E6BFCB@xmb-sjc-225.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrKHCJKQqodSPMDR0+Np+7IzFyjhAAAlXlgAAFV0VAAAMzAMA== References: <4BA7800A.4040406@gmx.net><201003221619.o2MGJc2G006891@sj-core-2.cisco.com><8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net><BLU137-DS1318F3081E30928873CA2D93270@phx.gbl>, <62D89A2E-1066-4932-91CE-59A7798655E3@cs.columbia.edu><BLU137-W26F0443F14828D573CC84493270@phx.gbl><A8BCA059-789B-4A66-B2AE-69F72C816248@cs.columbia.edu> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB1AB@DEMUEXC030.nsn-intra.net> <AC1CFD94F59A264488DC2BEC3E890DE509E6BFCB@xmb-sjc-225.amer.cisco.com> From: "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com> To: "ext Joseph Salowey (jsalowey)" <jsalowey@cisco.com>, "ext Henning Schulzrinne" <hgs@cs.columbia.edu>, "Bernard Aboba" <bernard_aboba@hotmail.com> X-OriginalArrivalTime: 23 Mar 2010 01:24:10.0271 (UTC) FILETIME=[8A15F2F0:01CACA27] Cc: ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 01:24:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CACA27.89323A36 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable not sure I understand correctly, but this is not about tying emergency procedures at higher layers to EAP usage. At least what I thought of is that for 'unauthorized' cases (say an existing prepaid account with insufficient credits for regular calls) the AAA would need to know this is for emergency to take the right authorization decision. =20 Dirk=20 ________________________________ From: ext Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 Sent: Tuesday, March 23, 2010 2:15 AM To: Kroeselberg, Dirk (NSN - DE/Munich); ext Henning Schulzrinne; Bernard Aboba Cc: ecrit@ietf.org Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) =09 =09 I do not think EAP or NAI should be used as a signaling mechanism for emergency. These mechanisms are ways to obtain network access when you cannot in some other way. Once you have network access it seems that the emergency procedures should be the same whether you authenticated to get network access or you gained access though another mechanism.=20 =20 I am probably missing some ECRIT specific nuances here, but I feel that tying emergency procedures at higher layers to EAP usage will be fraught with problems.=20 =20 Joe =20 =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Kroeselberg, Dirk (NSN - DE/Munich) Sent: Monday, March 22, 2010 5:26 PM To: ext Henning Schulzrinne; Bernard Aboba Cc: ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) =20 yes, fixing the NAI to a simple string is simple (this would basically be a NAI that is username only, correct?). =20 However, let me repeat my question from the other thread: How to handle the 'authenticated' emergency case where the NAI carries the regular username? The draft may be about unauthenticated, but just covering unauthenticated and leaving the authenticated case open seems less useful to me. =20 Dirk =20 =09 ________________________________ From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Tuesday, March 23, 2010 1:02 AM To: Bernard Aboba Cc: Kroeselberg, Dirk (NSN - DE/Munich); ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of service attacks on the emergency.com domain) The "sos" name seems to be a reasonable approach that's simple and easy.=20 =20 Longer term, I think a better option is to have a semi-authenticated mode: Imagine a setup where VSPs or other trustable bodies hand out tokens (e.g., using the OAuth-WARP work) that the ISP recognizes. The ISP is given the right to monitor the usage of 'sos' sessions and can hand the token to the appropriate authorities for prosecution in case of abuse. That way, you get emergency access, but make it unlikely that the system will be abused on a large scale. In some countries, you might get such a token from your local public authority when you're registering your residence. =20 Henning =20 On Mar 22, 2010, at 7:50 PM, Bernard Aboba wrote: =09 =09 =09 If all you want to do is to gain emergency access to the local network, you don't need to discover the domain. You can just use an NAI of "sos". That will be more convenient in situations where the local access mechanism (e.g. 802.1X) doesn't permit IP packets (including DHCP) to pass prior to completing authentication, so that "domain discovery" couldn't occur until afterwards.=20 =20 ------_=_NextPart_001_01CACA27.89323A36 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20 "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:m =3D=20 "http://schemas.microsoft.com/office/2004/12/omml"><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2900.3660" name=3DGENERATOR><BASE = href=3Dx-msg://681/><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: Calibri; } @font-face { font-family: Tahoma; } @font-face { font-family: Verdana; } @page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.0in 1.0in 1.0in; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New = Roman","serif" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New = Roman","serif" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New = Roman","serif" } A:link { COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99 } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99 } A:visited { COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99 } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99 } SPAN.apple-style-span { mso-style-name: apple-style-span } SPAN.apple-converted-space { mso-style-name: apple-converted-space } SPAN.EmailStyle19 { COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: = personal-reply } .MsoChpDefault { FONT-SIZE: 10pt; mso-style-type: export-only } DIV.Section1 { page: Section1 } </STYLE> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></HEAD> <BODY lang=3DEN-US=20 style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; = webkit-line-break: after-white-space"=20 vLink=3Dpurple link=3Dblue> <DIV><SPAN class=3D770222001-23032010><FONT face=3DArial color=3D#0000ff = size=3D2>not=20 sure I understand correctly, but this is not about tying emergency = procedures at=20 higher layers to EAP usage. At least what I thought of is that for=20 'unauthorized' cases (say an existing prepaid account with insufficient = credits=20 for regular calls) the AAA would need to know this is for emergency = to take=20 the right authorization decision.</FONT></SPAN></DIV> <DIV><SPAN class=3D770222001-23032010><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D770222001-23032010><FONT face=3DArial color=3D#0000ff = size=3D2>Dirk</FONT> </SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> ext Joseph Salowey = (jsalowey)=20 [mailto:jsalowey@cisco.com] <BR><B>Sent:</B> Tuesday, March 23, 2010 = 2:15=20 AM<BR><B>To:</B> Kroeselberg, Dirk (NSN - DE/Munich); ext Henning = Schulzrinne;=20 Bernard Aboba<BR><B>Cc:</B> ecrit@ietf.org<BR><B>Subject:</B> RE: = [Ecrit]=20 emergency access and EAP-TLS (and denial of serviceattacks on the=20 emergency.com domain)<BR></FONT><BR></DIV> <DIV></DIV> <DIV class=3DSection1> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">I=20 do not think EAP or NAI should be used as a signaling mechanism for=20 emergency.    These mechanisms are ways to obtain = network=20 access when you cannot in some other way.  Once you have network = access=20 it seems that the emergency procedures should be the same whether you=20 authenticated to get network access or you gained access though = another=20 mechanism. <o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">I=20 am probably missing some ECRIT specific nuances here, but I feel that = tying=20 emergency procedures at higher layers to EAP usage will be fraught = with=20 problems. <o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">Joe<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <DIV> <DIV=20 style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: = #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: = medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none"> <P class=3DMsoNormal><B><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = 'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] <B>On Behalf Of = </B>Kroeselberg, Dirk (NSN - DE/Munich)<BR><B>Sent:</B> Monday, March = 22, 2010=20 5:26 PM<BR><B>To:</B> ext Henning Schulzrinne; Bernard = Aboba<BR><B>Cc:</B>=20 ecrit@ietf.org<BR><B>Subject:</B> Re: [Ecrit] emergency access and = EAP-TLS=20 (and denial of serviceattacks on the emergency.com=20 domain)<o:p></o:p></SPAN></P></DIV></DIV> <P class=3DMsoNormal><o:p> </o:p></P> <DIV> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">yes,=20 fixing the NAI to a simple string is simple (this would basically be a = NAI=20 that is username only, correct?).</SPAN><o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal> <o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">However,=20 let me repeat my question from the other thread: How to handle the=20 'authenticated' emergency case where the NAI carries the regular = username? The=20 draft may be about unauthenticated, but just covering = unauthenticated and=20 leaving the authenticated case open seems less useful to=20 me.</SPAN><o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal> <o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">Dirk</SPAN><o:p></o:p></P></DIV> <BLOCKQUOTE=20 style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: = medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt = 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: = medium none"> <P class=3DMsoNormal><o:p> </o:p></P> <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" = align=3Dcenter><SPAN lang=3DDE> <HR align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></DIV> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><SPAN = lang=3DDE=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = 'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20 lang=3DDE style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = 'Tahoma','sans-serif'"> ext=20 Henning Schulzrinne [mailto:hgs@cs.columbia.edu] <BR><B>Sent:</B> = Tuesday,=20 March 23, 2010 1:02 AM<BR><B>To:</B> Bernard Aboba<BR><B>Cc:</B>=20 Kroeselberg, Dirk (NSN - DE/Munich); = ecrit@ietf.org<BR><B>Subject:</B> Re:=20 [Ecrit] emergency access and EAP-TLS (and denial of service attacks = on the=20 emergency.com domain)</SPAN><SPAN lang=3DDE><o:p></o:p></SPAN></P> <DIV> <P class=3DMsoNormal>The "sos" name seems to be a reasonable = approach that's=20 simple and easy. <o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><o:p> </o:p></P></DIV> <DIV> <P class=3DMsoNormal>Longer term, I think a better option is to have = a=20 semi-authenticated mode: Imagine a setup where VSPs or other = trustable=20 bodies hand out tokens (e.g., using the OAuth-WARP work) that the = ISP=20 recognizes. The ISP is given the right to monitor the usage of 'sos' = sessions and can hand the token to the appropriate authorities for=20 prosecution in case of abuse. That way, you get emergency access, = but make=20 it unlikely that the system will be abused on a large scale. In some = countries, you might get such a token from your local public = authority when=20 you're registering your residence.<o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><o:p> </o:p></P></DIV> <DIV> <P class=3DMsoNormal>Henning<o:p></o:p></P></DIV> <P class=3DMsoNormal><o:p> </o:p></P> <DIV> <DIV> <P class=3DMsoNormal>On Mar 22, 2010, at 7:50 PM, Bernard Aboba=20 wrote:<o:p></o:p></P></DIV> <P class=3DMsoNormal><BR><BR><o:p></o:p></P> <DIV> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Verdana','sans-serif'">If = all you want=20 to do is to gain emergency access to the local network, you don't = need to=20 discover the domain.  You can just use an NAI of = "sos".  =20 That will be more convenient in situations where the local access = mechanism=20 (e.g. 802.1X) doesn't permit IP packets (including DHCP) to pass = prior to=20 completing authentication, so that "domain discovery" couldn't occur = until=20 afterwards.<SPAN=20 = class=3Dapple-converted-space> </SPAN><o:p></o:p></SPAN></P></DIV></= DIV> <P=20 class=3DMsoNormal><o:p> </o:p></P></BLOCKQUOTE></DIV></BLOCKQUOTE></= BODY></HTML> ------_=_NextPart_001_01CACA27.89323A36-- From bernard_aboba@hotmail.com Mon Mar 22 18:28:05 2010 Return-Path: <bernard_aboba@hotmail.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86B713A68D8; Mon, 22 Mar 2010 18:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.055 X-Spam-Level: X-Spam-Status: No, score=-0.055 tagged_above=-999 required=5 tests=[AWL=-0.446, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, 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 lxiDZlJIiFk5; Mon, 22 Mar 2010 18:28:03 -0700 (PDT) Received: from blu0-omc4-s25.blu0.hotmail.com (blu0-omc4-s25.blu0.hotmail.com [65.55.111.164]) by core3.amsl.com (Postfix) with ESMTP id E04653A68CE; Mon, 22 Mar 2010 18:28:02 -0700 (PDT) Received: from BLU137-W37 ([65.55.111.136]) by blu0-omc4-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 18:28:20 -0700 Message-ID: <BLU137-W370951B6C399E53F93420993260@phx.gbl> Content-Type: multipart/alternative; boundary="_0dd1094f-8cce-46a1-83e9-a75d0ccc8219_" X-Originating-IP: [130.129.27.170] From: Bernard Aboba <bernard_aboba@hotmail.com> To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>, <dirk.kroeselberg@nsn.com>, <hgs@cs.columbia.edu> Date: Mon, 22 Mar 2010 18:28:20 -0700 Importance: Normal In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE509E6BFCB@xmb-sjc-225.amer.cisco.com> References: <4BA7800A.4040406@gmx.net><201003221619.o2MGJc2G006891@sj-core-2.cisco.com><8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net><BLU137-DS1318F3081E30928873CA2D93270@phx.gbl>, <62D89A2E-1066-4932-91CE-59A7798655E3@cs.columbia.edu><BLU137-W26F0443F14828D573CC84493270@phx.gbl><A8BCA059-789B-4A66-B2AE-69F72C816248@cs.columbia.edu> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB1AB@DEMUEXC030.nsn-intra.net>, <AC1CFD94F59A264488DC2BEC3E890DE509E6BFCB@xmb-sjc-225.amer.cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Mar 2010 01:28:20.0633 (UTC) FILETIME=[1F502890:01CACA28] Cc: ecrit@ietf.org, emu@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 01:28:05 -0000 --_0dd1094f-8cce-46a1-83e9-a75d0ccc8219_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Part of the confusion here may be that we're talking about "unauthenticated= " at multiple layers. There is unauthenticated network access=2C and then = there is unauthenticated VOIP signaling. =20 These are two orthogonal things. The VOIP signaling should not change rega= rdless of whether the network access is authenticated or unauthenticated.=20 Similarly=2C it's possible to use authenticated or unauthenticated VOIP sig= naling over authenticated or unauthenticated access. =20 Focusing solely on how to obtain "unauthenticated" access=2C the question i= s how the client signals that it is interested in "unauthenticated" access.= This is important=2C because otherwise the server might request client au= thentication (e.g. a client certificate request). Essentially the "sos" NA= I is functioning similar to the "anonymous" NAI in that this results in spe= cial processing on the AAA server side. Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of serviceatt= acks on the emergency.com domain) Date: Mon=2C 22 Mar 2010 18:14:59 -0700 From: jsalowey@cisco.com To: dirk.kroeselberg@nsn.com=3B hgs@cs.columbia.edu=3B bernard_aboba@hotmai= l.com CC: ecrit@ietf.org I do not think EAP or NAI should be used as a signaling mechanism for emergency. These mechanisms are ways to obtain network access when you cannot in some other way. Once you have network access it seems that the emergency procedures should be the same whether you authenticated = to get network access or you gained access though another mechanism.=20 =20 I am probably missing some ECRIT specific nuances here=2C but I feel that tying emergency procedures at higher layers to EAP usage will be fraug= ht with problems.=20 =20 Joe =20 =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Kroesel= berg=2C Dirk (NSN - DE/Munich) Sent: Monday=2C March 22=2C 2010 5:26 PM To: ext Henning Schulzrinne=3B Bernard Aboba Cc: ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) =20 yes=2C fixing the NAI to a simple string is simple (this would basically be a NAI that is username only=2C correct?). =20 However=2C let me repeat my question from the other thread: How to handle the 'authenticated' emergency case where the NAI carries the regular username? The draft may be about unauthenticated=2C but just covering unauthenticated and leaving the authenticated case open seems less useful to me. =20 Dirk =20 From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Tuesday=2C March 23=2C 2010 1:02 AM To: Bernard Aboba Cc: Kroeselberg=2C Dirk (NSN - DE/Munich)=3B ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of service attacks on the emergency.com domain) The "sos" name seems to be a reasonable approach that's simple and easy.=20 =20 Longer term=2C I think a better option is to have a semi-authenticated mode: Imagine a setup where VSPs or other trustable bodi= es hand out tokens (e.g.=2C using the OAuth-WARP work) that the ISP recognizes= . The ISP is given the right to monitor the usage of 'sos' sessions and can hand = the token to the appropriate authorities for prosecution in case of abuse. That way=2C you get emergency access=2C but make it unlikely that the system wil= l be abused on a large scale. In some countries=2C you might get such a token fr= om your local public authority when you're registering your residence. =20 Henning =20 On Mar 22=2C 2010=2C at 7:50 PM=2C Bernard Aboba wrote: If all you want to do is to gain emergency access to the local network=2C you don't need to discover the domain. You can just use an NAI of "sos". That will be more convenient in situations where the local access mechanism (e.g. 802.1X) doe= sn't permit IP packets (including DHCP) to pass prior to completing authenticati= on=2C so that "domain discovery" couldn't occur until afterwards.=20 =20 = --_0dd1094f-8cce-46a1-83e9-a75d0ccc8219_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style><!-- .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } --></style> </head> <body class=3D'hmmessage'> Part of the confusion here may be that we're talking about "unauthenticated= " at multiple layers. =3B There is unauthenticated network access=2C an= d then there is unauthenticated VOIP signaling. =3B <br><br>These are t= wo orthogonal things. =3B The VOIP signaling should not change regardle= ss of whether the network access is authenticated or unauthenticated. <br><= br>Similarly=2C it's possible to use authenticated or unauthenticated VOIP = signaling over authenticated or unauthenticated access. =3B <br><br>Foc= using solely on how to obtain "unauthenticated" access=2C the question is h= ow the client signals that it is interested in "unauthenticated" access.&nb= sp=3B This is important=2C because otherwise the server might request clien= t authentication (e.g. a client certificate request). =3B Essentially t= he "sos" NAI is functioning similar to the "anonymous" NAI in that this res= ults in special processing on the AAA server side.<br><table style=3D"borde= r-top: 1px solid black=3B font-weight: bold=3B font-family: 'Segoe UI'=2CTa= homa=2Csan-serif=3B"><tbody><tr><td><br></td></tr></tbody></table><br><br><= hr id=3D"stopSpelling">Subject: RE: [Ecrit] emergency access and EAP-TLS (a= nd denial of serviceattacks on the emergency.com domain)<br>Date: Mon=2C 22= Mar 2010 18:14:59 -0700<br>From: jsalowey@cisco.com<br>To: dirk.kroeselber= g@nsn.com=3B hgs@cs.columbia.edu=3B bernard_aboba@hotmail.com<br>CC: ecrit@= ietf.org<br><br> <style> .ExternalClass .ecxshape {=3B} </style> <style> .ExternalClass p.ecxMsoNormal=2C .ExternalClass li.ecxMsoNormal=2C .Externa= lClass div.ecxMsoNormal {margin-bottom:.0001pt=3Bfont-size:12.0pt=3Bfont-family:'Times New Roman'= =2C'serif'=3B} .ExternalClass a:link=2C .ExternalClass span.ecxMsoHyperlink {color:blue=3Btext-decoration:underline=3B} .ExternalClass a:visited=2C .ExternalClass span.ecxMsoHyperlinkFollowed {color:purple=3Btext-decoration:underline=3B} .ExternalClass span.ecxapple-style-span {=3B} .ExternalClass span.ecxapple-converted-space {=3B} .ExternalClass span.ecxEmailStyle19 {font-family:'Calibri'=2C'sans-serif'=3Bcolor:#1F497D=3B} .ExternalClass .ecxMsoChpDefault {font-size:10.0pt=3B} @page Section1 {size:8.5in 11.0in=3B} .ExternalClass div.ecxSection1 {page:Section1=3B} </style> <div class=3D"ecxSection1"> <p class=3D"ecxMsoNormal"><span style=3D"font-size: 11pt=3B font-family: 'C= alibri'=2C'sans-serif'=3B color: rgb(31=2C 73=2C 125)=3B">I do not think EA= P or NAI should be used as a signaling mechanism for emergency. =3B =3B =3B These mechanisms are ways to obtain = network access when you cannot in some other way. =3B Once you have network access it = seems that the emergency procedures should be the same whether you authenticated = to get network access or you gained access though another mechanism. </span></= p> <p class=3D"ecxMsoNormal"><span style=3D"font-size: 11pt=3B font-family: 'C= alibri'=2C'sans-serif'=3B color: rgb(31=2C 73=2C 125)=3B"> =3B</span></= p> <p class=3D"ecxMsoNormal"><span style=3D"font-size: 11pt=3B font-family: 'C= alibri'=2C'sans-serif'=3B color: rgb(31=2C 73=2C 125)=3B">I am probably mis= sing some ECRIT specific nuances here=2C but I feel that tying emergency procedures at higher layers to EAP usage will be fraug= ht with problems. </span></p> <p class=3D"ecxMsoNormal"><span style=3D"font-size: 11pt=3B font-family: 'C= alibri'=2C'sans-serif'=3B color: rgb(31=2C 73=2C 125)=3B"> =3B</span></= p> <p class=3D"ecxMsoNormal"><span style=3D"font-size: 11pt=3B font-family: 'C= alibri'=2C'sans-serif'=3B color: rgb(31=2C 73=2C 125)=3B">Joe</span></p> <p class=3D"ecxMsoNormal"><span style=3D"font-size: 11pt=3B font-family: 'C= alibri'=2C'sans-serif'=3B color: rgb(31=2C 73=2C 125)=3B"> =3B</span></= p> <p class=3D"ecxMsoNormal"><span style=3D"font-size: 11pt=3B font-family: 'C= alibri'=2C'sans-serif'=3B color: rgb(31=2C 73=2C 125)=3B"> =3B</span></= p> <div> <div style=3D"border-right: medium none=3B border-width: 1pt medium medium= =3B border-style: solid none none=3B border-color: rgb(181=2C 196=2C 223) -= moz-use-text-color -moz-use-text-color=3B padding: 3pt 0in 0in=3B"> <p class=3D"ecxMsoNormal"><b><span style=3D"font-size: 10pt=3B font-family:= 'Tahoma'=2C'sans-serif'=3B">From:</span></b><span style=3D"font-size: 10pt= =3B font-family: 'Tahoma'=2C'sans-serif'=3B"> ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] <b>On Behalf Of </b>= Kroeselberg=2C Dirk (NSN - DE/Munich)<br> <b>Sent:</b> Monday=2C March 22=2C 2010 5:26 PM<br> <b>To:</b> ext Henning Schulzrinne=3B Bernard Aboba<br> <b>Cc:</b> ecrit@ietf.org<br> <b>Subject:</b> Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)</span></p> </div> </div> <p class=3D"ecxMsoNormal"> =3B</p> <div> <p class=3D"ecxMsoNormal"><span style=3D"font-size: 10pt=3B font-family: 'A= rial'=2C'sans-serif'=3B color: blue=3B">yes=2C fixing the NAI to a simple s= tring is simple (this would basically be a NAI that is username only=2C correct?).</span></p> </div> <div> <p class=3D"ecxMsoNormal"> =3B</p> </div> <div> <p class=3D"ecxMsoNormal"><span style=3D"font-size: 10pt=3B font-family: 'A= rial'=2C'sans-serif'=3B color: blue=3B">However=2C let me repeat my questio= n from the other thread: How to handle the 'authenticated' emergency case where the NAI carries the regular username? The draft may be about unauthenticated=2C but just covering unauthenticated =3Band leaving the authenticated case open seems =3Bless =3Buseful to me.</span></p> </div> <div> <p class=3D"ecxMsoNormal"> =3B</p> </div> <div> <p class=3D"ecxMsoNormal"><span style=3D"font-size: 10pt=3B font-family: 'A= rial'=2C'sans-serif'=3B color: blue=3B">Dirk</span></p> </div> <blockquote style=3D"border-width: medium medium medium 1.5pt=3B border-sty= le: none none none solid=3B border-color: -moz-use-text-color -moz-use-text= -color -moz-use-text-color blue=3B padding: 0in 0in 0in 4pt=3B margin-left:= 3.75pt=3B margin-right: 0in=3B margin-bottom: 5pt=3B"> <p class=3D"ecxMsoNormal"> =3B</p> <div class=3D"ecxMsoNormal" style=3D"text-align: center=3B" align=3D"center= "><span lang=3D"DE"> <hr align=3D"center" width=3D"100%" size=3D"2"> </span></div> <p class=3D"ecxMsoNormal" style=3D"margin-bottom: 12pt=3B"><b><span style= =3D"font-size: 10pt=3B font-family: 'Tahoma'=2C'sans-serif'=3B" lang=3D"DE"= >From:</span></b><span style=3D"font-size: 10pt=3B font-family: 'Tahoma'=2C= 'sans-serif'=3B" lang=3D"DE"> ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] <br> <b>Sent:</b> Tuesday=2C March 23=2C 2010 1:02 AM<br> <b>To:</b> Bernard Aboba<br> <b>Cc:</b> Kroeselberg=2C Dirk (NSN - DE/Munich)=3B ecrit@ietf.org<br> <b>Subject:</b> Re: [Ecrit] emergency access and EAP-TLS (and denial of ser= vice attacks on the emergency.com domain)</span><span lang=3D"DE"></span></p> <div> <p class=3D"ecxMsoNormal">The "sos" name seems to be a reasonable approach that's simple and easy. =3B</p> </div> <div> <p class=3D"ecxMsoNormal"> =3B</p> </div> <div> <p class=3D"ecxMsoNormal">Longer term=2C I think a better option is to have= a semi-authenticated mode: Imagine a setup where VSPs or other trustable bodi= es hand out tokens (e.g.=2C using the OAuth-WARP work) that the ISP recognizes= . The ISP is given the right to monitor the usage of 'sos' sessions and can hand = the token to the appropriate authorities for prosecution in case of abuse. That way=2C you get emergency access=2C but make it unlikely that the system wil= l be abused on a large scale. In some countries=2C you might get such a token fr= om your local public authority when you're registering your residence.</p> </div> <div> <p class=3D"ecxMsoNormal"> =3B</p> </div> <div> <p class=3D"ecxMsoNormal">Henning</p> </div> <p class=3D"ecxMsoNormal"> =3B</p> <div> <div> <p class=3D"ecxMsoNormal">On Mar 22=2C 2010=2C at 7:50 PM=2C Bernard Aboba = wrote:</p> </div> <p class=3D"ecxMsoNormal"><br> <br> </p> <div> <p class=3D"ecxMsoNormal" style=3D"margin-bottom: 12pt=3B"><span style=3D"f= ont-size: 10pt=3B font-family: 'Verdana'=2C'sans-serif'=3B">If all you want= to do is to gain emergency access to the local network=2C you don't need to discover the domain. = =3B You can just use an NAI of "sos". =3B =3B That will be more convenient in situations where the local access mechanism (e.g. 802.1X) doe= sn't permit IP packets (including DHCP) to pass prior to completing authenticati= on=2C so that "domain discovery" couldn't occur until afterwards.<span class=3D"e= cxapple-converted-space"> =3B</span></span></p> </div> </div> <p class=3D"ecxMsoNormal"> =3B</p> </blockquote> </div> </body> </html>= --_0dd1094f-8cce-46a1-83e9-a75d0ccc8219_-- From rbarnes@bbn.com Mon Mar 22 22:07:07 2010 Return-Path: <rbarnes@bbn.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6B33A6845 for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 22:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.431 X-Spam-Level: ** X-Spam-Status: No, score=2.431 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=2.431] 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 vD7b5j0ECu4q for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 22:07:06 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 25BB53A67F4 for <ecrit@ietf.org>; Mon, 22 Mar 2010 22:07:06 -0700 (PDT) Received: from [128.89.254.32] (helo=dhcp184-48-62-120.ach.lax.wayport.net) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1NtwKp-0001Md-QE; Tue, 23 Mar 2010 01:07:24 -0400 Message-Id: <AFDFB414-A963-467C-A387-74B9FB98D918@bbn.com> From: Richard Barnes <rbarnes@bbn.com> To: Marc Linsner <mlinsner@cisco.com> In-Reply-To: <C7CD416D.21810%mlinsner@cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 22 Mar 2010 22:07:21 -0700 References: <C7CD416D.21810%mlinsner@cisco.com> X-Mailer: Apple Mail (2.936) Cc: ecrit <ecrit@ietf.org> Subject: Re: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 05:07:07 -0000 How onerous is this, really? In order to supply location to =20 endpoints, ISPs are already required to operate a location server of =20 some sort, DHCP or HELD. Allowing PSAP access just means that they =20 have to add an account and maybe a firewall rule. --Richard On Mar 22, 2010, at 3:46 PM, Marc Linsner wrote: > James, > > =46rom Ray=92s message: > > =93and that LIS permitting queries from the PSAP. =93 > > I am obviously against forcing the access provider to establish a =20 > business/technical relationship with the PSAP. This goes well =20 > beyond requiring the access provider to supply location to it=92s =20 > customer. > > -Marc- > > On 3/22/10 2:29 PM, "Winterbottom, James" = <James.Winterbottom@andrew.com=20 > > wrote: > >> Hi Marc, >> >> Requiring the access network to have a location service suitable =20 >> for providing routing and dispatch information for emergency =20 >> services is a fundamental aspect of i2, i3 and ECRIT. Furthermore, =20= >> the LIS needs to provide location information that will result in a =20= >> valid route to the PSAP. If civic location information is used then =20= >> this must line-up with the profiles for civic fields used in the =20 >> local LoST server, so much of the relationships and requirements =20 >> are you concerned about below are already pivotal to deployment of =20= >> the basic ECRIT solution as defined in phone BCP. >> >> What Ray is talking about from this point is that there is likely =20 >> to regulation in the UK requiring ISPs and access providers to have =20= >> a LIS, largely because this is seemed to be the best way to enable =20= >> progression towards a NG emergency solution. Experience in the =20 >> cellular world, clearly show that without regulation access =20 >> providers will not put this equipment in place so that the services =20= >> can progress. Discussions I have had with carriers has resulted in =20= >> the same answer, without regulation they are not going to spend the =20= >> money required to make it happen. This impacts all the solutions =20 >> not just ECRIT Direct. >> >> Cheers >> James >> >> >> >> <image.jpg> James Winterbottom Global Product Manager Andrew =20 >> GeoLENs IP Location Product Portfolio Email: = james.winterbottom@andrew.com=20 >> Phone: +61-2-42-212938 Mobile: +61-448-266004 >> >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On =20 >> Behalf Of Marc Linsner >> Sent: Tuesday, 23 March 2010 8:05 AM >> To: Ray.Bellis@nominet.org.uk; ecrit >> Subject: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) >> >> Ray, >> >> Assuming this pertains to the conversation around ECRIT Direct. >> >> IMO, it=92s unfortunate that regulators are led to the conclusion =20 >> that you outline. Forcing a business/technical relationship =20 >> between an access provider and public safety is only going to =20 >> stifle those offering or wanting to offer access services, in the =20 >> end harming the consumer of Internet services. But I suppose =20 >> that=92s the intention of those proposing such to the regulators. =20= >> Regardless, the IETF should not put forth any architecture that =20 >> forces those relationships. >> >> I believe that using UK regulation as justification for the ECRIT =20 >> Direct work will actually be detrimental to it=92s progress within =20= >> the IETF. >> >> -Marc- >> >> >> >> >> On 3/22/10 10:20 AM, "Ray.Bellis@nominet.org.uk" = <Ray.Bellis@nominet.org.uk=20 >> > wrote: >> To back up what James W just said at the mic: >> >> The proposed UK model for emergency service access over VoIP =20 >> depends on each ISP running a LIS and that LIS permitting queries =20 >> from the PSAP. >> >> It's my belief that this will be enshrined in UK law via the =20 >> introduction by OFCOM of a new "General Condition of Service" which =20= >> will apply to any public telecommunications provider, including =20 >> pure IP access providers. >> >> Ray >> > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Mon Mar 22 22:26:36 2010 Return-Path: <rbarnes@bbn.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6296A3A67F4 for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 22:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.431 X-Spam-Level: ** X-Spam-Status: No, score=2.431 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=2.431] 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 KwAXcCNx7V69 for <ecrit@core3.amsl.com>; Mon, 22 Mar 2010 22:26:35 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 3E7DC3A67DF for <ecrit@ietf.org>; Mon, 22 Mar 2010 22:24:14 -0700 (PDT) Received: from [128.89.254.32] (helo=dhcp184-48-62-120.ach.lax.wayport.net) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1Ntwaq-0001QJ-20; Tue, 23 Mar 2010 01:23:56 -0400 Message-Id: <93B8DBC9-FE13-4617-9ED2-5901E5BAF939@bbn.com> From: Richard Barnes <rbarnes@bbn.com> To: Bernard Aboba <bernard_aboba@hotmail.com> In-Reply-To: <BLU137-W370951B6C399E53F93420993260@phx.gbl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 22 Mar 2010 22:23:53 -0700 References: <4BA7800A.4040406@gmx.net><201003221619.o2MGJc2G006891@sj-core-2.cisco.com><8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net><BLU137-DS1318F3081E30928873CA2D93270@phx.gbl>, <62D89A2E-1066-4932-91CE-59A7798655E3@cs.columbia.edu><BLU137-W26F0443F14828D573CC84493270@phx.gbl><A8BCA059-789B-4A66-B2AE-69F72C816248@cs.columbia.edu> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB1AB@DEMUEXC030.nsn-intra.net>, <AC1CFD94F59A264488DC2BEC3E890DE509E6BFCB@xmb-sjc-225.amer.cisco.com> <BLU137-W370951B6C399E53F93420993260@phx.gbl> X-Mailer: Apple Mail (2.936) Cc: emu@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 05:26:36 -0000 In particular, providing unauthenticated *network* access is a prerequisite for providing unauthenticated *VoIP* access. Also, Bernard: Does your below mention of "anonymous" NAI indicate that there is actually a reserved NAI "anonymous"? If so, then I don't really see the use for a separate "sos" NAI -- you can just provide ECRIT access to "anonymous". --Richard On Mar 22, 2010, at 6:28 PM, Bernard Aboba wrote: > Part of the confusion here may be that we're talking about > "unauthenticated" at multiple layers. There is unauthenticated > network access, and then there is unauthenticated VOIP signaling. > > These are two orthogonal things. The VOIP signaling should not > change regardless of whether the network access is authenticated or > unauthenticated. > > Similarly, it's possible to use authenticated or unauthenticated > VOIP signaling over authenticated or unauthenticated access. > > Focusing solely on how to obtain "unauthenticated" access, the > question is how the client signals that it is interested in > "unauthenticated" access. This is important, because otherwise the > server might request client authentication (e.g. a client > certificate request). Essentially the "sos" NAI is functioning > similar to the "anonymous" NAI in that this results in special > processing on the AAA server side. > > > > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of > serviceattacks on the emergency.com domain) > Date: Mon, 22 Mar 2010 18:14:59 -0700 > From: jsalowey@cisco.com > To: dirk.kroeselberg@nsn.com; hgs@cs.columbia.edu; bernard_aboba@hotmail.com > CC: ecrit@ietf.org > > I do not think EAP or NAI should be used as a signaling mechanism > for emergency. These mechanisms are ways to obtain network access > when you cannot in some other way. Once you have network access it > seems that the emergency procedures should be the same whether you > authenticated to get network access or you gained access though > another mechanism. > > I am probably missing some ECRIT specific nuances here, but I feel > that tying emergency procedures at higher layers to EAP usage will > be fraught with problems. > > Joe > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of Kroeselberg, Dirk (NSN - DE/Munich) > Sent: Monday, March 22, 2010 5:26 PM > To: ext Henning Schulzrinne; Bernard Aboba > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of > serviceattacks on the emergency.com domain) > > yes, fixing the NAI to a simple string is simple (this would > basically be a NAI that is username only, correct?). > > However, let me repeat my question from the other thread: How to > handle the 'authenticated' emergency case where the NAI carries the > regular username? The draft may be about unauthenticated, but just > covering unauthenticated and leaving the authenticated case open > seems less useful to me. > > Dirk > > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, March 23, 2010 1:02 AM > To: Bernard Aboba > Cc: Kroeselberg, Dirk (NSN - DE/Munich); ecrit@ietf.org > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of > service attacks on the emergency.com domain) > > The "sos" name seems to be a reasonable approach that's simple and > easy. > > Longer term, I think a better option is to have a semi-authenticated > mode: Imagine a setup where VSPs or other trustable bodies hand out > tokens (e.g., using the OAuth-WARP work) that the ISP recognizes. > The ISP is given the right to monitor the usage of 'sos' sessions > and can hand the token to the appropriate authorities for > prosecution in case of abuse. That way, you get emergency access, > but make it unlikely that the system will be abused on a large > scale. In some countries, you might get such a token from your local > public authority when you're registering your residence. > > Henning > > On Mar 22, 2010, at 7:50 PM, Bernard Aboba wrote: > > > If all you want to do is to gain emergency access to the local > network, you don't need to discover the domain. You can just use an > NAI of "sos". That will be more convenient in situations where the > local access mechanism (e.g. 802.1X) doesn't permit IP packets > (including DHCP) to pass prior to completing authentication, so that > "domain discovery" couldn't occur until afterwards. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hgs@cs.columbia.edu Mon Mar 22 22:28:54 2010 Return-Path: <hgs@cs.columbia.edu> 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 594B23A6888; Mon, 22 Mar 2010 22:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.671 X-Spam-Level: *** X-Spam-Status: No, score=3.671 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=2.431, SARE_LWSHORTT=1.24] 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 XbFddRgtKVr9; Mon, 22 Mar 2010 22:28:53 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id 80F813A67DF; Mon, 22 Mar 2010 22:28:53 -0700 (PDT) Received: from dhcp-wireless-open-abg-26-78.meeting.ietf.org (dhcp-wireless-open-abg-26-78.meeting.ietf.org [130.129.26.78]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o2N5T7vI018808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 23 Mar 2010 01:29:07 -0400 (EDT) References: <4BA7800A.4040406@gmx.net><201003221619.o2MGJc2G006891@sj-core-2.cisco.com><8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net><BLU137-DS1318F3081E30928873CA2D93270@phx.gbl>, <62D89A2E-1066-4932-91CE-59A7798655E3@cs.columbia.edu><BLU137-W26F0443F14828D573CC84493270@phx.gbl><A8BCA059-789B-4A66-B2AE-69F72C816248@cs.columbia.edu> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB1AB@DEMUEXC030.nsn-intra.net>, <AC1CFD94F59A264488DC2BEC3E890DE509E6BFCB@xmb-sjc-225.amer.cisco.com> <BLU137-W370951B6C399E53F93420993260@phx.gbl> <93B8DBC9-FE13-4617-9ED2-5901E5BAF939@bbn.com> In-Reply-To: <93B8DBC9-FE13-4617-9ED2-5901E5BAF939@bbn.com> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: <7D215F09-A6BD-4199-BC71-CB134FEAFD1A@cs.columbia.edu> Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne <hgs@cs.columbia.edu> Date: Tue, 23 Mar 2010 01:29:04 -0400 To: Richard Barnes <rbarnes@bbn.com> X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: emu@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 05:28:54 -0000 The goal is to provide a specific "emergency only" network access, = rather than anonymous access. Indeed, anonymity is typically not the = goal. As a hotel operator, I might be happy to provide emergency call = access even to non-guests, but clearly don't want to free Internet = access to the neighborhood. Thus, I think that the "sos" NAI in the = short term, along with non-subscription-based access right token for = emergency calling longer term, is a reasonable direction. Henning On Mar 23, 2010, at 1:23 AM, Richard Barnes wrote: > In particular, providing unauthenticated *network* access is a = prerequisite for providing unauthenticated *VoIP* access. >=20 > Also, Bernard: Does your below mention of "anonymous" NAI indicate = that there is actually a reserved NAI "anonymous"? If so, then I don't = really see the use for a separate "sos" NAI -- you can just provide = ECRIT access to "anonymous". >=20 > --Richard From bernard_aboba@hotmail.com Mon Mar 22 22:29:37 2010 Return-Path: <bernard_aboba@hotmail.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246383A67DF; Mon, 22 Mar 2010 22:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.431 X-Spam-Level: ** X-Spam-Status: No, score=2.431 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=2.431] 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 c+1p+6yEcMeT; Mon, 22 Mar 2010 22:29:35 -0700 (PDT) Received: from blu0-omc3-s5.blu0.hotmail.com (blu0-omc3-s5.blu0.hotmail.com [65.55.116.80]) by core3.amsl.com (Postfix) with ESMTP id CD3F53A6888; Mon, 22 Mar 2010 22:29:33 -0700 (PDT) Received: from BLU0-SMTP13 ([65.55.116.72]) by blu0-omc3-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 22:29:51 -0700 X-Originating-IP: [166.205.11.253] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: <BLU0-SMTP1377A7E38D5F6553186CC793260@phx.gbl> Received: from [10.131.119.2] ([166.205.11.253]) by BLU0-SMTP13.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 22:29:48 -0700 References: <4BA7800A.4040406@gmx.net><201003221619.o2MGJc2G006891@sj-core-2.cisco.com><8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net><BLU137-DS1318F3081E30928873CA2D93270@phx.gbl>, <62D89A2E-1066-4932-91CE-59A7798655E3@cs.columbia.edu><BLU137-W26F0443F14828D573CC84493270@phx.gbl><A8BCA059-789B-4A66-B2AE-69F72C816248@cs.columbia.edu> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB1AB@DEMUEXC030.nsn-intra.net>, <AC1CFD94F59A264488DC2BEC3E890DE509E6BFCB@xmb-sjc-225.amer.cisco.com> <BLU137-W370951B6C399E53F93420993260@phx.gbl> <93B8DBC9-FE13-4617-9ED2-5901E5BAF939@bbn.com> From: Bernard Aboba <bernard_aboba@hotmail.com> To: Richard Barnes <rbarnes@bbn.com> In-Reply-To: <93B8DBC9-FE13-4617-9ED2-5901E5BAF939@bbn.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Mon, 22 Mar 2010 22:29:37 -0700 X-OriginalArrivalTime: 23 Mar 2010 05:29:51.0956 (UTC) FILETIME=[DCD09140:01CACA49] Cc: "emu@ietf.org" <emu@ietf.org>, "ecrit@ietf.org" <ecrit@ietf.org> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 05:29:37 -0000 Yes, there is an "anonymous" NAI, but the goal of that is to hide the identity from the NAS and eavesdroppers, not to enable client unauthenticated access. On Mar 22, 2010, at 10:23 PM, Richard Barnes <rbarnes@bbn.com> wrote: > In particular, providing unauthenticated *network* access is a > prerequisite for providing unauthenticated *VoIP* access. > > Also, Bernard: Does your below mention of "anonymous" NAI indicate > that there is actually a reserved NAI "anonymous"? If so, then I > don't really see the use for a separate "sos" NAI -- you can just > provide ECRIT access to "anonymous". > > --Richard > > > > On Mar 22, 2010, at 6:28 PM, Bernard Aboba wrote: > >> Part of the confusion here may be that we're talking about >> "unauthenticated" at multiple layers. There is unauthenticated >> network access, and then there is unauthenticated VOIP signaling. >> >> These are two orthogonal things. The VOIP signaling should not >> change regardless of whether the network access is authenticated or >> unauthenticated. >> >> Similarly, it's possible to use authenticated or unauthenticated >> VOIP signaling over authenticated or unauthenticated access. >> >> Focusing solely on how to obtain "unauthenticated" access, the >> question is how the client signals that it is interested in >> "unauthenticated" access. This is important, because otherwise the >> server might request client authentication (e.g. a client >> certificate request). Essentially the "sos" NAI is functioning >> similar to the "anonymous" NAI in that this results in special >> processing on the AAA server side. >> >> >> >> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of >> serviceattacks on the emergency.com domain) >> Date: Mon, 22 Mar 2010 18:14:59 -0700 >> From: jsalowey@cisco.com >> To: dirk.kroeselberg@nsn.com; hgs@cs.columbia.edu; bernard_aboba@hotmail.com >> CC: ecrit@ietf.org >> >> I do not think EAP or NAI should be used as a signaling mechanism >> for emergency. These mechanisms are ways to obtain network >> access when you cannot in some other way. Once you have network >> access it seems that the emergency procedures should be the same >> whether you authenticated to get network access or you gained >> access though another mechanism. >> >> I am probably missing some ECRIT specific nuances here, but I feel >> that tying emergency procedures at higher layers to EAP usage will >> be fraught with problems. >> >> Joe >> >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf Of Kroeselberg, Dirk (NSN - DE/Munich) >> Sent: Monday, March 22, 2010 5:26 PM >> To: ext Henning Schulzrinne; Bernard Aboba >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of >> serviceattacks on the emergency.com domain) >> >> yes, fixing the NAI to a simple string is simple (this would >> basically be a NAI that is username only, correct?). >> >> However, let me repeat my question from the other thread: How to >> handle the 'authenticated' emergency case where the NAI carries the >> regular username? The draft may be about unauthenticated, but just >> covering unauthenticated and leaving the authenticated case open >> seems less useful to me. >> >> Dirk >> >> From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Tuesday, March 23, 2010 1:02 AM >> To: Bernard Aboba >> Cc: Kroeselberg, Dirk (NSN - DE/Munich); ecrit@ietf.org >> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of >> service attacks on the emergency.com domain) >> >> The "sos" name seems to be a reasonable approach that's simple and >> easy. >> >> Longer term, I think a better option is to have a semi- >> authenticated mode: Imagine a setup where VSPs or other trustable >> bodies hand out tokens (e.g., using the OAuth-WARP work) that the >> ISP recognizes. The ISP is given the right to monitor the usage of >> 'sos' sessions and can hand the token to the appropriate >> authorities for prosecution in case of abuse. That way, you get >> emergency access, but make it unlikely that the system will be >> abused on a large scale. In some countries, you might get such a >> token from your local public authority when you're registering your >> residence. >> >> Henning >> >> On Mar 22, 2010, at 7:50 PM, Bernard Aboba wrote: >> >> >> If all you want to do is to gain emergency access to the local >> network, you don't need to discover the domain. You can just use >> an NAI of "sos". That will be more convenient in situations where >> the local access mechanism (e.g. 802.1X) doesn't permit IP packets >> (including DHCP) to pass prior to completing authentication, so >> that "domain discovery" couldn't occur until afterwards. >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > From rbarnes@bbn.com Mon Mar 22 22:43:37 2010 Return-Path: <rbarnes@bbn.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BCB03A6806; Mon, 22 Mar 2010 22:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.431 X-Spam-Level: ** X-Spam-Status: No, score=2.431 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=2.431] 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 I42vk0hYFqHv; Mon, 22 Mar 2010 22:43:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id CE9A53A6452; Mon, 22 Mar 2010 22:43:28 -0700 (PDT) Received: from [128.89.254.32] (helo=dhcp184-48-62-120.ach.lax.wayport.net) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1Ntwtn-0001Xe-2S; Tue, 23 Mar 2010 01:43:32 -0400 Message-Id: <B9E6D716-3CC7-44FE-8A1D-08F366A42D20@bbn.com> From: Richard Barnes <rbarnes@bbn.com> To: Bernard Aboba <bernard_aboba@hotmail.com> In-Reply-To: <BLU0-SMTP1377A7E38D5F6553186CC793260@phx.gbl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 22 Mar 2010 22:43:28 -0700 References: <4BA7800A.4040406@gmx.net><201003221619.o2MGJc2G006891@sj-core-2.cisco.com><8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net><BLU137-DS1318F3081E30928873CA2D93270@phx.gbl>, <62D89A2E-1066-4932-91CE-59A7798655E3@cs.columbia.edu><BLU137-W26F0443F14828D573CC84493270@phx.gbl><A8BCA059-789B-4A66-B2AE-69F72C816248@cs.columbia.edu> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB1AB@DEMUEXC030.nsn-intra.net>, <AC1CFD94F59A264488DC2BEC3E890DE509E6BFCB@xmb-sjc-225.amer.cisco.com> <BLU137-W370951B6C399E53F93420993260@phx.gbl> <93B8DBC9-FE13-4617-9ED2-5901E5BAF939@bbn.com> <BLU0-SMTP1377A7E38D5F6553186CC793260@phx.gbl> X-Mailer: Apple Mail (2.936) Cc: "emu@ietf.org" <emu@ietf.org>, "ecrit@ietf.org" <ecrit@ietf.org> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 05:43:37 -0000 Doesn't it functionally amount to the same thing, though? Just the client choosing not to authenticate vs not being able to authenticate? --Richard On Mar 22, 2010, at 10:29 PM, Bernard Aboba wrote: > Yes, there is an "anonymous" NAI, but the goal of that is to hide > the identity from the NAS and eavesdroppers, not to enable client > unauthenticated access. > > On Mar 22, 2010, at 10:23 PM, Richard Barnes <rbarnes@bbn.com> wrote: > >> In particular, providing unauthenticated *network* access is a >> prerequisite for providing unauthenticated *VoIP* access. >> >> Also, Bernard: Does your below mention of "anonymous" NAI indicate >> that there is actually a reserved NAI "anonymous"? If so, then I >> don't really see the use for a separate "sos" NAI -- you can just >> provide ECRIT access to "anonymous". >> >> --Richard >> >> >> >> On Mar 22, 2010, at 6:28 PM, Bernard Aboba wrote: >> >>> Part of the confusion here may be that we're talking about >>> "unauthenticated" at multiple layers. There is unauthenticated >>> network access, and then there is unauthenticated VOIP signaling. >>> >>> These are two orthogonal things. The VOIP signaling should not >>> change regardless of whether the network access is authenticated >>> or unauthenticated. >>> >>> Similarly, it's possible to use authenticated or unauthenticated >>> VOIP signaling over authenticated or unauthenticated access. >>> >>> Focusing solely on how to obtain "unauthenticated" access, the >>> question is how the client signals that it is interested in >>> "unauthenticated" access. This is important, because otherwise >>> the server might request client authentication (e.g. a client >>> certificate request). Essentially the "sos" NAI is functioning >>> similar to the "anonymous" NAI in that this results in special >>> processing on the AAA server side. >>> >>> >>> >>> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of >>> serviceattacks on the emergency.com domain) >>> Date: Mon, 22 Mar 2010 18:14:59 -0700 >>> From: jsalowey@cisco.com >>> To: dirk.kroeselberg@nsn.com; hgs@cs.columbia.edu; bernard_aboba@hotmail.com >>> CC: ecrit@ietf.org >>> >>> I do not think EAP or NAI should be used as a signaling mechanism >>> for emergency. These mechanisms are ways to obtain network >>> access when you cannot in some other way. Once you have network >>> access it seems that the emergency procedures should be the same >>> whether you authenticated to get network access or you gained >>> access though another mechanism. >>> >>> I am probably missing some ECRIT specific nuances here, but I feel >>> that tying emergency procedures at higher layers to EAP usage will >>> be fraught with problems. >>> >>> Joe >>> >>> >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> Behalf Of Kroeselberg, Dirk (NSN - DE/Munich) >>> Sent: Monday, March 22, 2010 5:26 PM >>> To: ext Henning Schulzrinne; Bernard Aboba >>> Cc: ecrit@ietf.org >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of >>> serviceattacks on the emergency.com domain) >>> >>> yes, fixing the NAI to a simple string is simple (this would >>> basically be a NAI that is username only, correct?). >>> >>> However, let me repeat my question from the other thread: How to >>> handle the 'authenticated' emergency case where the NAI carries >>> the regular username? The draft may be about unauthenticated, but >>> just covering unauthenticated and leaving the authenticated case >>> open seems less useful to me. >>> >>> Dirk >>> >>> From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>> Sent: Tuesday, March 23, 2010 1:02 AM >>> To: Bernard Aboba >>> Cc: Kroeselberg, Dirk (NSN - DE/Munich); ecrit@ietf.org >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of >>> service attacks on the emergency.com domain) >>> >>> The "sos" name seems to be a reasonable approach that's simple and >>> easy. >>> >>> Longer term, I think a better option is to have a semi- >>> authenticated mode: Imagine a setup where VSPs or other trustable >>> bodies hand out tokens (e.g., using the OAuth-WARP work) that the >>> ISP recognizes. The ISP is given the right to monitor the usage of >>> 'sos' sessions and can hand the token to the appropriate >>> authorities for prosecution in case of abuse. That way, you get >>> emergency access, but make it unlikely that the system will be >>> abused on a large scale. In some countries, you might get such a >>> token from your local public authority when you're registering >>> your residence. >>> >>> Henning >>> >>> On Mar 22, 2010, at 7:50 PM, Bernard Aboba wrote: >>> >>> >>> If all you want to do is to gain emergency access to the local >>> network, you don't need to discover the domain. You can just use >>> an NAI of "sos". That will be more convenient in situations >>> where the local access mechanism (e.g. 802.1X) doesn't permit IP >>> packets (including DHCP) to pass prior to completing >>> authentication, so that "domain discovery" couldn't occur until >>> afterwards. >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> From Martin.Dawson@andrew.com Mon Mar 22 22:44:28 2010 Return-Path: <Martin.Dawson@andrew.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0850E3A67A1; Mon, 22 Mar 2010 22:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.431 X-Spam-Level: ** X-Spam-Status: No, score=2.431 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=2.431] 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 yQT0caK5df14; Mon, 22 Mar 2010 22:44:27 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id AC0843A6452; Mon, 22 Mar 2010 22:44:26 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:34185 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S15211715Ab0CWFop convert rfc822-to-8bit (ORCPT <rfc822;ecrit@ietf.org> + 1 other); Tue, 23 Mar 2010 00:44:45 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 23 Mar 2010 00:44:45 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 23 Mar 2010 13:44:40 +0800 From: "Dawson, Martin" <Martin.Dawson@andrew.com> To: Richard Barnes <rbarnes@bbn.com>, Bernard Aboba <bernard_aboba@hotmail.com> Date: Tue, 23 Mar 2010 13:44:38 +0800 Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrKSXaOaa9IhmslQziPq/Sf2RCytAAAWrKw Message-ID: <8B0A9FCBB9832F43971E38010638454F03E24ECF25@SISPE7MB1.commscope.com> References: <4BA7800A.4040406@gmx.net><201003221619.o2MGJc2G006891@sj-core-2.cisco.com><8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net><BLU137-DS1318F3081E30928873CA2D93270@phx.gbl>, <62D89A2E-1066-4932-91CE-59A7798655E3@cs.columbia.edu><BLU137-W26F0443F14828D573CC84493270@phx.gbl><A8BCA059-789B-4A66-B2AE-69F72C816248@cs.columbia.edu> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB1AB@DEMUEXC030.nsn-intra.net>, <AC1CFD94F59A264488DC2BEC3E890DE509E6BFCB@xmb-sjc-225.amer.cisco.com> <BLU137-W370951B6C399E53F93420993260@phx.gbl> <93B8DBC9-FE13-4617-9ED2-5901E5BAF939@bbn.com> In-Reply-To: <93B8DBC9-FE13-4617-9ED2-5901E5BAF939@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="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Cc: "emu@ietf.org" <emu@ietf.org>, "ecrit@ietf.org" <ecrit@ietf.org> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 05:44:28 -0000 And it *could* be rephrased as follows. An obligation to support unauthenticated emergency calling means: 1) Provide the option of establishing an unauthenticated IP context 2) It's sufficient if only emergency calling procedures are supported on that IP context This is quite straightforward under an ECRIT-direct model - 2) is satisfied as long as HELD, LoST, and a SIP route to the relevant PSAP URI is available. It's more difficult if you have to allow people to also proxy emergency calls via arbitrary VoIP providers... using arbitrary VoIP protocols. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Tuesday, 23 March 2010 4:24 PM To: Bernard Aboba Cc: emu@ietf.org; ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) In particular, providing unauthenticated *network* access is a prerequisite for providing unauthenticated *VoIP* access. Also, Bernard: Does your below mention of "anonymous" NAI indicate that there is actually a reserved NAI "anonymous"? If so, then I don't really see the use for a separate "sos" NAI -- you can just provide ECRIT access to "anonymous". --Richard On Mar 22, 2010, at 6:28 PM, Bernard Aboba wrote: > Part of the confusion here may be that we're talking about > "unauthenticated" at multiple layers. There is unauthenticated > network access, and then there is unauthenticated VOIP signaling. > > These are two orthogonal things. The VOIP signaling should not > change regardless of whether the network access is authenticated or > unauthenticated. > > Similarly, it's possible to use authenticated or unauthenticated > VOIP signaling over authenticated or unauthenticated access. > > Focusing solely on how to obtain "unauthenticated" access, the > question is how the client signals that it is interested in > "unauthenticated" access. This is important, because otherwise the > server might request client authentication (e.g. a client > certificate request). Essentially the "sos" NAI is functioning > similar to the "anonymous" NAI in that this results in special > processing on the AAA server side. > > > > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of > serviceattacks on the emergency.com domain) > Date: Mon, 22 Mar 2010 18:14:59 -0700 > From: jsalowey@cisco.com > To: dirk.kroeselberg@nsn.com; hgs@cs.columbia.edu; bernard_aboba@hotmail.com > CC: ecrit@ietf.org > > I do not think EAP or NAI should be used as a signaling mechanism > for emergency. These mechanisms are ways to obtain network access > when you cannot in some other way. Once you have network access it > seems that the emergency procedures should be the same whether you > authenticated to get network access or you gained access though > another mechanism. > > I am probably missing some ECRIT specific nuances here, but I feel > that tying emergency procedures at higher layers to EAP usage will > be fraught with problems. > > Joe > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of Kroeselberg, Dirk (NSN - DE/Munich) > Sent: Monday, March 22, 2010 5:26 PM > To: ext Henning Schulzrinne; Bernard Aboba > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of > serviceattacks on the emergency.com domain) > > yes, fixing the NAI to a simple string is simple (this would > basically be a NAI that is username only, correct?). > > However, let me repeat my question from the other thread: How to > handle the 'authenticated' emergency case where the NAI carries the > regular username? The draft may be about unauthenticated, but just > covering unauthenticated and leaving the authenticated case open > seems less useful to me. > > Dirk > > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, March 23, 2010 1:02 AM > To: Bernard Aboba > Cc: Kroeselberg, Dirk (NSN - DE/Munich); ecrit@ietf.org > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of > service attacks on the emergency.com domain) > > The "sos" name seems to be a reasonable approach that's simple and > easy. > > Longer term, I think a better option is to have a semi-authenticated > mode: Imagine a setup where VSPs or other trustable bodies hand out > tokens (e.g., using the OAuth-WARP work) that the ISP recognizes. > The ISP is given the right to monitor the usage of 'sos' sessions > and can hand the token to the appropriate authorities for > prosecution in case of abuse. That way, you get emergency access, > but make it unlikely that the system will be abused on a large > scale. In some countries, you might get such a token from your local > public authority when you're registering your residence. > > Henning > > On Mar 22, 2010, at 7:50 PM, Bernard Aboba wrote: > > > If all you want to do is to gain emergency access to the local > network, you don't need to discover the domain. You can just use an > NAI of "sos". That will be more convenient in situations where the > local access mechanism (e.g. 802.1X) doesn't permit IP packets > (including DHCP) to pass prior to completing authentication, so that > "domain discovery" couldn't occur until afterwards. > > > _______________________________________________ > 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 hgs@cs.columbia.edu Mon Mar 22 22:59:09 2010 Return-Path: <hgs@cs.columbia.edu> 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 5D8AC3A67D7; Mon, 22 Mar 2010 22:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.051 X-Spam-Level: * X-Spam-Status: No, score=1.051 tagged_above=-999 required=5 tests=[AWL=2.620, DNS_FROM_OPENWHOIS=2.431, 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 KkR0+Tkhre0c; Mon, 22 Mar 2010 22:59:08 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 2A8E63A676A; Mon, 22 Mar 2010 22:59:08 -0700 (PDT) Received: from dhcp-wireless-open-abg-26-78.meeting.ietf.org (dhcp-wireless-open-abg-26-78.meeting.ietf.org [130.129.26.78]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o2N5xL3u012360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 23 Mar 2010 01:59:22 -0400 (EDT) References: <4BA7800A.4040406@gmx.net><201003221619.o2MGJc2G006891@sj-core-2.cisco.com><8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net><BLU137-DS1318F3081E30928873CA2D93270@phx.gbl>, <62D89A2E-1066-4932-91CE-59A7798655E3@cs.columbia.edu><BLU137-W26F0443F14828D573CC84493270@phx.gbl><A8BCA059-789B-4A66-B2AE-69F72C816248@cs.columbia.edu> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB1AB@DEMUEXC030.nsn-intra.net>, <AC1CFD94F59A264488DC2BEC3E890DE509E6BFCB@xmb-sjc-225.amer.cisco.com> <BLU137-W370951B6C399E53F93420993260@phx.gbl> <93B8DBC9-FE13-4617-9ED2-5901E5BAF939@bbn.com> <BLU0-SMTP1377A7E38D5F6553186CC793260@phx.gbl> <B9E6D716-3CC7-44FE-8A1D-08F366A42D20@bbn.com> In-Reply-To: <B9E6D716-3CC7-44FE-8A1D-08F366A42D20@bbn.com> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: <5303859C-0B99-45AC-B288-694EB5AB4929@cs.columbia.edu> Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne <hgs@cs.columbia.edu> Date: Tue, 23 Mar 2010 01:59:21 -0400 To: Richard Barnes <rbarnes@bbn.com> X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: "emu@ietf.org" <emu@ietf.org>, "ecrit@ietf.org" <ecrit@ietf.org> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 05:59:09 -0000 No, it indicates the desire to place an emergency call. Thus, if I use = this access to visit Facebook, I'm doing the equivalent of parking in a = handicapped parking spot. The "anonymous" notion would not. Henning On Mar 23, 2010, at 1:43 AM, Richard Barnes wrote: > Doesn't it functionally amount to the same thing, though? Just the = client choosing not to authenticate vs not being able to authenticate? > --Richard >=20 From rbarnes@bbn.com Mon Mar 22 23:01:18 2010 Return-Path: <rbarnes@bbn.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 837453A67D7; Mon, 22 Mar 2010 23:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.051 X-Spam-Level: *** X-Spam-Status: No, score=3.051 tagged_above=-999 required=5 tests=[AWL=-0.620, DNS_FROM_OPENWHOIS=2.431, SARE_LWSHORTT=1.24] 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 LKW6s9mmvgMK; Mon, 22 Mar 2010 23:01:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id DB8193A6807; Mon, 22 Mar 2010 23:01:09 -0700 (PDT) Received: from [128.89.254.32] (helo=dhcp184-48-62-120.ach.lax.wayport.net) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1NtxB5-0001wV-RO; Tue, 23 Mar 2010 02:01:24 -0400 Message-Id: <747F7DA9-CC46-4185-AB7F-04306B5B6D58@bbn.com> From: Richard Barnes <rbarnes@bbn.com> To: Henning Schulzrinne <hgs@cs.columbia.edu> In-Reply-To: <7D215F09-A6BD-4199-BC71-CB134FEAFD1A@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 22 Mar 2010 23:00:40 -0700 References: <4BA7800A.4040406@gmx.net><201003221619.o2MGJc2G006891@sj-core-2.cisco.com><8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net><BLU137-DS1318F3081E30928873CA2D93270@phx.gbl>, <62D89A2E-1066-4932-91CE-59A7798655E3@cs.columbia.edu><BLU137-W26F0443F14828D573CC84493270@phx.gbl><A8BCA059-789B-4A66-B2AE-69F72C816248@cs.columbia.edu> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB1AB@DEMUEXC030.nsn-intra.net>, <AC1CFD94F59A264488DC2BEC3E890DE509E6BFCB@xmb-sjc-225.amer.cisco.com> <BLU137-W370951B6C399E53F93420993260@phx.gbl> <93B8DBC9-FE13-4617-9ED2-5901E5BAF939@bbn.com> <7D215F09-A6BD-4199-BC71-CB134FEAFD1A@cs.columbia.edu> X-Mailer: Apple Mail (2.936) Cc: emu@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 06:01:18 -0000 Seems like kind of a false distinction -- if the network doesn't know you, it doesn't know you. Are you envisioning anonymous users that *won't* be allowed emergency call access? --Richard On Mar 22, 2010, at 10:29 PM, Henning Schulzrinne wrote: > The goal is to provide a specific "emergency only" network access, > rather than anonymous access. Indeed, anonymity is typically not the > goal. As a hotel operator, I might be happy to provide emergency > call access even to non-guests, but clearly don't want to free > Internet access to the neighborhood. Thus, I think that the "sos" > NAI in the short term, along with non-subscription-based access > right token for emergency calling longer term, is a reasonable > direction. > > Henning > > On Mar 23, 2010, at 1:23 AM, Richard Barnes wrote: > >> In particular, providing unauthenticated *network* access is a >> prerequisite for providing unauthenticated *VoIP* access. >> >> Also, Bernard: Does your below mention of "anonymous" NAI indicate >> that there is actually a reserved NAI "anonymous"? If so, then I >> don't really see the use for a separate "sos" NAI -- you can just >> provide ECRIT access to "anonymous". >> >> --Richard > From rbarnes@bbn.com Mon Mar 22 23:26:37 2010 Return-Path: <rbarnes@bbn.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7C93A69A2; Mon, 22 Mar 2010 23:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.52 X-Spam-Level: ** X-Spam-Status: No, score=2.52 tagged_above=-999 required=5 tests=[AWL=0.089, DNS_FROM_OPENWHOIS=2.431] 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 9g5XDBxjFj-B; Mon, 22 Mar 2010 23:26:36 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 51C843A6997; Mon, 22 Mar 2010 23:26:36 -0700 (PDT) Received: from [128.89.254.32] (helo=dhcp184-48-62-120.ach.lax.wayport.net) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1NtxZk-0001l6-Sn; Tue, 23 Mar 2010 02:26:53 -0400 Message-Id: <76853329-E44C-4456-AB99-19A704C52EF1@bbn.com> From: Richard Barnes <rbarnes@bbn.com> To: Henning Schulzrinne <hgs@cs.columbia.edu> In-Reply-To: <5303859C-0B99-45AC-B288-694EB5AB4929@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 22 Mar 2010 23:26:50 -0700 References: <4BA7800A.4040406@gmx.net><201003221619.o2MGJc2G006891@sj-core-2.cisco.com><8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net><BLU137-DS1318F3081E30928873CA2D93270@phx.gbl>, <62D89A2E-1066-4932-91CE-59A7798655E3@cs.columbia.edu><BLU137-W26F0443F14828D573CC84493270@phx.gbl><A8BCA059-789B-4A66-B2AE-69F72C816248@cs.columbia.edu> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB1AB@DEMUEXC030.nsn-intra.net>, <AC1CFD94F59A264488DC2BEC3E890DE509E6BFCB@xmb-sjc-225.amer.cisco.com> <BLU137-W370951B6C399E53F93420993260@phx.gbl> <93B8DBC9-FE13-4617-9ED2-5901E5BAF939@bbn.com> <BLU0-SMTP1377A7E38D5F6553186CC793260@phx.gbl> <B9E6D716-3CC7-44FE-8A1D-08F366A42D20@bbn.com> <5303859C-0B99-45AC-B288-694EB5AB4929@cs.columbia.edu> X-Mailer: Apple Mail (2.936) Cc: "emu@ietf.org" <emu@ietf.org>, "ecrit@ietf.org" <ecrit@ietf.org> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 06:26:37 -0000 I still don't follow. The intent of the user is irrelevant here -- either an unauthenticated user is allowed to make an emergency call or he isn't. Again, are you supposing that a network would provide to classes of unauthenticated service, one that allows only emergency calling and one that allows me to use Facebook? Why wouldn't I just always use the latter? On Mar 22, 2010, at 10:59 PM, Henning Schulzrinne wrote: > No, it indicates the desire to place an emergency call. Thus, if I > use this access to visit Facebook, I'm doing the equivalent of > parking in a handicapped parking spot. The "anonymous" notion would > not. > > Henning > > On Mar 23, 2010, at 1:43 AM, Richard Barnes wrote: > >> Doesn't it functionally amount to the same thing, though? Just >> the client choosing not to authenticate vs not being able to >> authenticate? >> --Richard >> > From bernard_aboba@hotmail.com Tue Mar 23 00:32:17 2010 Return-Path: <bernard_aboba@hotmail.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E6CB3A6812; Tue, 23 Mar 2010 00:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 4YEEkMxPYkUE; Tue, 23 Mar 2010 00:32:15 -0700 (PDT) Received: from blu0-omc4-s18.blu0.hotmail.com (blu0-omc4-s18.blu0.hotmail.com [65.55.111.157]) by core3.amsl.com (Postfix) with ESMTP id 2A9DC3A67FB; Tue, 23 Mar 2010 00:32:15 -0700 (PDT) Received: from BLU137-W16 ([65.55.111.137]) by blu0-omc4-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 00:32:33 -0700 Message-ID: <BLU137-W16A7478A99589D829B03D793260@phx.gbl> Content-Type: multipart/alternative; boundary="_3d5e9545-600e-49d0-948f-ca54964f8426_" X-Originating-IP: [130.129.26.108] From: Bernard Aboba <bernard_aboba@hotmail.com> To: <rbarnes@bbn.com> Date: Tue, 23 Mar 2010 00:32:33 -0700 Importance: Normal In-Reply-To: <B9E6D716-3CC7-44FE-8A1D-08F366A42D20@bbn.com> References: <4BA7800A.4040406@gmx.net><201003221619.o2MGJc2G006891@sj-core-2.cisco.com><8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net><BLU137-DS1318F3081E30928873CA2D93270@phx.gbl>, <62D89A2E-1066-4932-91CE-59A7798655E3@cs.columbia.edu><BLU137-W26F0443F14828D573CC84493270@phx.gbl><A8BCA059-789B-4A66-B2AE-69F72C816248@cs.columbia.edu> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB1AB@DEMUEXC030.nsn-intra.net>, <AC1CFD94F59A264488DC2BEC3E890DE509E6BFCB@xmb-sjc-225.amer.cisco.com> <BLU137-W370951B6C399E53F93420993260@phx.gbl> <93B8DBC9-FE13-4617-9ED2-5901E5BAF939@bbn.com> <BLU0-SMTP1377A7E38D5F6553186CC793260@phx.gbl>, <B9E6D716-3CC7-44FE-8A1D-08F366A42D20@bbn.com> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Mar 2010 07:32:33.0114 (UTC) FILETIME=[006823A0:01CACA5B] Cc: emu@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 07:32:17 -0000 --_3d5e9545-600e-49d0-948f-ca54964f8426_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No=2C because the "anonymous" NAI is typically used in protocols (like EAP-= TTLSv0=2C EAP-FAST or PEAP) where mutual authentication is required. So wh= ile the NAS or an eavesdropper can't determine the client identity=2C the A= AA server can and does determine it (and in turn=2C proves its identity to = the client).=20 So at least in EAP=2C "anonymous" !=3D "unauthenticated" > CC: jsalowey@cisco.com=3B dirk.kroeselberg@nsn.com=3B hgs@cs.columbia.edu= =3B ecrit@ietf.org=3B emu@ietf.org > From: rbarnes@bbn.com > To: bernard_aboba@hotmail.com > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of servicea= ttacks on the emergency.com domain) > Date: Mon=2C 22 Mar 2010 22:43:28 -0700 >=20 > Doesn't it functionally amount to the same thing=2C though? Just the =20 > client choosing not to authenticate vs not being able to authenticate? > --Richard >=20 >=20 > On Mar 22=2C 2010=2C at 10:29 PM=2C Bernard Aboba wrote: >=20 > > Yes=2C there is an "anonymous" NAI=2C but the goal of that is to hide = =20 > > the identity from the NAS and eavesdroppers=2C not to enable client =20 > > unauthenticated access. > > > > On Mar 22=2C 2010=2C at 10:23 PM=2C Richard Barnes <rbarnes@bbn.com> wr= ote: > > > >> In particular=2C providing unauthenticated *network* access is a =20 > >> prerequisite for providing unauthenticated *VoIP* access. > >> > >> Also=2C Bernard: Does your below mention of "anonymous" NAI indicate = =20 > >> that there is actually a reserved NAI "anonymous"? If so=2C then I =20 > >> don't really see the use for a separate "sos" NAI -- you can just =20 > >> provide ECRIT access to "anonymous". > >> > >> --Richard > >> > >> > >> > >> On Mar 22=2C 2010=2C at 6:28 PM=2C Bernard Aboba wrote: > >> > >>> Part of the confusion here may be that we're talking about =20 > >>> "unauthenticated" at multiple layers. There is unauthenticated =20 > >>> network access=2C and then there is unauthenticated VOIP signaling. > >>> > >>> These are two orthogonal things. The VOIP signaling should not =20 > >>> change regardless of whether the network access is authenticated =20 > >>> or unauthenticated. > >>> > >>> Similarly=2C it's possible to use authenticated or unauthenticated =20 > >>> VOIP signaling over authenticated or unauthenticated access. > >>> > >>> Focusing solely on how to obtain "unauthenticated" access=2C the =20 > >>> question is how the client signals that it is interested in =20 > >>> "unauthenticated" access. This is important=2C because otherwise =20 > >>> the server might request client authentication (e.g. a client =20 > >>> certificate request). Essentially the "sos" NAI is functioning =20 > >>> similar to the "anonymous" NAI in that this results in special =20 > >>> processing on the AAA server side. > >>> > >>> > >>> > >>> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of =20 > >>> serviceattacks on the emergency.com domain) > >>> Date: Mon=2C 22 Mar 2010 18:14:59 -0700 > >>> From: jsalowey@cisco.com > >>> To: dirk.kroeselberg@nsn.com=3B hgs@cs.columbia.edu=3B bernard_aboba@= hotmail.com > >>> CC: ecrit@ietf.org > >>> > >>> I do not think EAP or NAI should be used as a signaling mechanism =20 > >>> for emergency. These mechanisms are ways to obtain network =20 > >>> access when you cannot in some other way. Once you have network =20 > >>> access it seems that the emergency procedures should be the same =20 > >>> whether you authenticated to get network access or you gained =20 > >>> access though another mechanism. > >>> > >>> I am probably missing some ECRIT specific nuances here=2C but I feel = =20 > >>> that tying emergency procedures at higher layers to EAP usage will =20 > >>> be fraught with problems. > >>> > >>> Joe > >>> > >>> > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On =20 > >>> Behalf Of Kroeselberg=2C Dirk (NSN - DE/Munich) > >>> Sent: Monday=2C March 22=2C 2010 5:26 PM > >>> To: ext Henning Schulzrinne=3B Bernard Aboba > >>> Cc: ecrit@ietf.org > >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of =20 > >>> serviceattacks on the emergency.com domain) > >>> > >>> yes=2C fixing the NAI to a simple string is simple (this would =20 > >>> basically be a NAI that is username only=2C correct?). > >>> > >>> However=2C let me repeat my question from the other thread: How to =20 > >>> handle the 'authenticated' emergency case where the NAI carries =20 > >>> the regular username? The draft may be about unauthenticated=2C but = =20 > >>> just covering unauthenticated and leaving the authenticated case =20 > >>> open seems less useful to me. > >>> > >>> Dirk > >>> > >>> From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>> Sent: Tuesday=2C March 23=2C 2010 1:02 AM > >>> To: Bernard Aboba > >>> Cc: Kroeselberg=2C Dirk (NSN - DE/Munich)=3B ecrit@ietf.org > >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of =20 > >>> service attacks on the emergency.com domain) > >>> > >>> The "sos" name seems to be a reasonable approach that's simple and =20 > >>> easy. > >>> > >>> Longer term=2C I think a better option is to have a semi-=20 > >>> authenticated mode: Imagine a setup where VSPs or other trustable =20 > >>> bodies hand out tokens (e.g.=2C using the OAuth-WARP work) that the = =20 > >>> ISP recognizes. The ISP is given the right to monitor the usage of =20 > >>> 'sos' sessions and can hand the token to the appropriate =20 > >>> authorities for prosecution in case of abuse. That way=2C you get =20 > >>> emergency access=2C but make it unlikely that the system will be =20 > >>> abused on a large scale. In some countries=2C you might get such a =20 > >>> token from your local public authority when you're registering =20 > >>> your residence. > >>> > >>> Henning > >>> > >>> On Mar 22=2C 2010=2C at 7:50 PM=2C Bernard Aboba wrote: > >>> > >>> > >>> If all you want to do is to gain emergency access to the local =20 > >>> network=2C you don't need to discover the domain. You can just use = =20 > >>> an NAI of "sos". That will be more convenient in situations =20 > >>> where the local access mechanism (e.g. 802.1X) doesn't permit IP =20 > >>> packets (including DHCP) to pass prior to completing =20 > >>> authentication=2C so that "domain discovery" couldn't occur until =20 > >>> afterwards. > >>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >> > >> >=20 = --_3d5e9545-600e-49d0-948f-ca54964f8426_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style><!-- .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } --></style> </head> <body class=3D'hmmessage'> No=2C because the "anonymous" NAI is typically used in protocols (like EAP-= TTLSv0=2C EAP-FAST or PEAP) where mutual authentication is required. = =3B So while the NAS or an eavesdropper can't determine the client identity= =2C the AAA server can and does determine it (and in turn=2C proves its ide= ntity to the client). <br><br>So at least in EAP=2C "anonymous" !=3D "unaut= henticated"<br><br><table style=3D"border-top: 1px solid black=3B font-weig= ht: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td= ><a href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_Greater= Good" style=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decora= tion: none=3B"><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B color:= rgb(63=2C 181=2C 85)=3B text-decoration: underline=3B"></span></a><br></td= ></tr></tbody></table><br><br>>=3B CC: jsalowey@cisco.com=3B dirk.kroesel= berg@nsn.com=3B hgs@cs.columbia.edu=3B ecrit@ietf.org=3B emu@ietf.org<br>&g= t=3B From: rbarnes@bbn.com<br>>=3B To: bernard_aboba@hotmail.com<br>>= =3B Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of servic= eattacks on the emergency.com domain)<br>>=3B Date: Mon=2C 22 Mar 2010 22= :43:28 -0700<br>>=3B <br>>=3B Doesn't it functionally amount to the sam= e thing=2C though? Just the <br>>=3B client choosing not to authentica= te vs not being able to authenticate?<br>>=3B --Richard<br>>=3B <br>>= =3B <br>>=3B On Mar 22=2C 2010=2C at 10:29 PM=2C Bernard Aboba wrote:<br>= >=3B <br>>=3B >=3B Yes=2C there is an "anonymous" NAI=2C but the goal= of that is to hide <br>>=3B >=3B the identity from the NAS and eavesd= roppers=2C not to enable client <br>>=3B >=3B unauthenticated access.<= br>>=3B >=3B<br>>=3B >=3B On Mar 22=2C 2010=2C at 10:23 PM=2C Richa= rd Barnes <=3Brbarnes@bbn.com>=3B wrote:<br>>=3B >=3B<br>>=3B >= =3B>=3B In particular=2C providing unauthenticated *network* access is a = <br>>=3B >=3B>=3B prerequisite for providing unauthenticated *VoIP* = access.<br>>=3B >=3B>=3B<br>>=3B >=3B>=3B Also=2C Bernard: Does= your below mention of "anonymous" NAI indicate <br>>=3B >=3B>=3B th= at there is actually a reserved NAI "anonymous"? If so=2C then I <br>>= =3B >=3B>=3B don't really see the use for a separate "sos" NAI -- you c= an just <br>>=3B >=3B>=3B provide ECRIT access to "anonymous".<br>&g= t=3B >=3B>=3B<br>>=3B >=3B>=3B --Richard<br>>=3B >=3B>=3B<b= r>>=3B >=3B>=3B<br>>=3B >=3B>=3B<br>>=3B >=3B>=3B On Mar = 22=2C 2010=2C at 6:28 PM=2C Bernard Aboba wrote:<br>>=3B >=3B>=3B<br>= >=3B >=3B>=3B>=3B Part of the confusion here may be that we're talk= ing about <br>>=3B >=3B>=3B>=3B "unauthenticated" at multiple laye= rs. There is unauthenticated <br>>=3B >=3B>=3B>=3B network access= =2C and then there is unauthenticated VOIP signaling.<br>>=3B >=3B>= =3B>=3B<br>>=3B >=3B>=3B>=3B These are two orthogonal things. Th= e VOIP signaling should not <br>>=3B >=3B>=3B>=3B change regardles= s of whether the network access is authenticated <br>>=3B >=3B>=3B&g= t=3B or unauthenticated.<br>>=3B >=3B>=3B>=3B<br>>=3B >=3B>= =3B>=3B Similarly=2C it's possible to use authenticated or unauthenticate= d <br>>=3B >=3B>=3B>=3B VOIP signaling over authenticated or unaut= henticated access.<br>>=3B >=3B>=3B>=3B<br>>=3B >=3B>=3B>= =3B Focusing solely on how to obtain "unauthenticated" access=2C the <br>&= gt=3B >=3B>=3B>=3B question is how the client signals that it is inte= rested in <br>>=3B >=3B>=3B>=3B "unauthenticated" access. This is= important=2C because otherwise <br>>=3B >=3B>=3B>=3B the server m= ight request client authentication (e.g. a client <br>>=3B >=3B>=3B&= gt=3B certificate request). Essentially the "sos" NAI is functioning <br>= >=3B >=3B>=3B>=3B similar to the "anonymous" NAI in that this resul= ts in special <br>>=3B >=3B>=3B>=3B processing on the AAA server s= ide.<br>>=3B >=3B>=3B>=3B<br>>=3B >=3B>=3B>=3B<br>>=3B &g= t=3B>=3B>=3B<br>>=3B >=3B>=3B>=3B Subject: RE: [Ecrit] emergenc= y access and EAP-TLS (and denial of <br>>=3B >=3B>=3B>=3B servicea= ttacks on the emergency.com domain)<br>>=3B >=3B>=3B>=3B Date: Mon= =2C 22 Mar 2010 18:14:59 -0700<br>>=3B >=3B>=3B>=3B From: jsalowey@= cisco.com<br>>=3B >=3B>=3B>=3B To: dirk.kroeselberg@nsn.com=3B hgs@= cs.columbia.edu=3B bernard_aboba@hotmail.com<br>>=3B >=3B>=3B>=3B C= C: ecrit@ietf.org<br>>=3B >=3B>=3B>=3B<br>>=3B >=3B>=3B>=3B= I do not think EAP or NAI should be used as a signaling mechanism <br>>= =3B >=3B>=3B>=3B for emergency. These mechanisms are ways to obtai= n network <br>>=3B >=3B>=3B>=3B access when you cannot in some oth= er way. Once you have network <br>>=3B >=3B>=3B>=3B access it see= ms that the emergency procedures should be the same <br>>=3B >=3B>= =3B>=3B whether you authenticated to get network access or you gained <b= r>>=3B >=3B>=3B>=3B access though another mechanism.<br>>=3B >= =3B>=3B>=3B<br>>=3B >=3B>=3B>=3B I am probably missing some ECR= IT specific nuances here=2C but I feel <br>>=3B >=3B>=3B>=3B that = tying emergency procedures at higher layers to EAP usage will <br>>=3B &= gt=3B>=3B>=3B be fraught with problems.<br>>=3B >=3B>=3B>=3B<br= >>=3B >=3B>=3B>=3B Joe<br>>=3B >=3B>=3B>=3B<br>>=3B >= =3B>=3B>=3B<br>>=3B >=3B>=3B>=3B From: ecrit-bounces@ietf.org [= mailto:ecrit-bounces@ietf.org] On <br>>=3B >=3B>=3B>=3B Behalf Of = Kroeselberg=2C Dirk (NSN - DE/Munich)<br>>=3B >=3B>=3B>=3B Sent: Mo= nday=2C March 22=2C 2010 5:26 PM<br>>=3B >=3B>=3B>=3B To: ext Henni= ng Schulzrinne=3B Bernard Aboba<br>>=3B >=3B>=3B>=3B Cc: ecrit@ietf= .org<br>>=3B >=3B>=3B>=3B Subject: Re: [Ecrit] emergency access and= EAP-TLS (and denial of <br>>=3B >=3B>=3B>=3B serviceattacks on th= e emergency.com domain)<br>>=3B >=3B>=3B>=3B<br>>=3B >=3B>=3B= >=3B yes=2C fixing the NAI to a simple string is simple (this would <br>= >=3B >=3B>=3B>=3B basically be a NAI that is username only=2C corre= ct?).<br>>=3B >=3B>=3B>=3B<br>>=3B >=3B>=3B>=3B However=2C = let me repeat my question from the other thread: How to <br>>=3B >=3B&= gt=3B>=3B handle the 'authenticated' emergency case where the NAI carries= <br>>=3B >=3B>=3B>=3B the regular username? The draft may be abou= t unauthenticated=2C but <br>>=3B >=3B>=3B>=3B just covering unaut= henticated and leaving the authenticated case <br>>=3B >=3B>=3B>= =3B open seems less useful to me.<br>>=3B >=3B>=3B>=3B<br>>=3B &g= t=3B>=3B>=3B Dirk<br>>=3B >=3B>=3B>=3B<br>>=3B >=3B>=3B&g= t=3B From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu]<br>>=3B &= gt=3B>=3B>=3B Sent: Tuesday=2C March 23=2C 2010 1:02 AM<br>>=3B >= =3B>=3B>=3B To: Bernard Aboba<br>>=3B >=3B>=3B>=3B Cc: Kroeselb= erg=2C Dirk (NSN - DE/Munich)=3B ecrit@ietf.org<br>>=3B >=3B>=3B>= =3B Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of <br>&= gt=3B >=3B>=3B>=3B service attacks on the emergency.com domain)<br>&g= t=3B >=3B>=3B>=3B<br>>=3B >=3B>=3B>=3B The "sos" name seems t= o be a reasonable approach that's simple and <br>>=3B >=3B>=3B>=3B= easy.<br>>=3B >=3B>=3B>=3B<br>>=3B >=3B>=3B>=3B Longer ter= m=2C I think a better option is to have a semi- <br>>=3B >=3B>=3B>= =3B authenticated mode: Imagine a setup where VSPs or other trustable <br>= >=3B >=3B>=3B>=3B bodies hand out tokens (e.g.=2C using the OAuth-W= ARP work) that the <br>>=3B >=3B>=3B>=3B ISP recognizes. The ISP i= s given the right to monitor the usage of <br>>=3B >=3B>=3B>=3B 's= os' sessions and can hand the token to the appropriate <br>>=3B >=3B&g= t=3B>=3B authorities for prosecution in case of abuse. That way=2C you ge= t <br>>=3B >=3B>=3B>=3B emergency access=2C but make it unlikely t= hat the system will be <br>>=3B >=3B>=3B>=3B abused on a large sca= le. In some countries=2C you might get such a <br>>=3B >=3B>=3B>= =3B token from your local public authority when you're registering <br>>= =3B >=3B>=3B>=3B your residence.<br>>=3B >=3B>=3B>=3B<br>>= =3B >=3B>=3B>=3B Henning<br>>=3B >=3B>=3B>=3B<br>>=3B >= =3B>=3B>=3B On Mar 22=2C 2010=2C at 7:50 PM=2C Bernard Aboba wrote:<br>= >=3B >=3B>=3B>=3B<br>>=3B >=3B>=3B>=3B<br>>=3B >=3B>= =3B>=3B If all you want to do is to gain emergency access to the local <= br>>=3B >=3B>=3B>=3B network=2C you don't need to discover the doma= in. You can just use <br>>=3B >=3B>=3B>=3B an NAI of "sos". Tha= t will be more convenient in situations <br>>=3B >=3B>=3B>=3B wher= e the local access mechanism (e.g. 802.1X) doesn't permit IP <br>>=3B &g= t=3B>=3B>=3B packets (including DHCP) to pass prior to completing <br>= >=3B >=3B>=3B>=3B authentication=2C so that "domain discovery" coul= dn't occur until <br>>=3B >=3B>=3B>=3B afterwards.<br>>=3B >= =3B>=3B>=3B<br>>=3B >=3B>=3B>=3B<br>>=3B >=3B>=3B>=3B _= ______________________________________________<br>>=3B >=3B>=3B>=3B= Ecrit mailing list<br>>=3B >=3B>=3B>=3B Ecrit@ietf.org<br>>=3B &= gt=3B>=3B>=3B https://www.ietf.org/mailman/listinfo/ecrit<br>>=3B >= =3B>=3B<br>>=3B >=3B>=3B<br>>=3B <br> </body> </html>= --_3d5e9545-600e-49d0-948f-ca54964f8426_-- From mlinsner@cisco.com Tue Mar 23 05:48:45 2010 Return-Path: <mlinsner@cisco.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C5A83A6A29 for <ecrit@core3.amsl.com>; Tue, 23 Mar 2010 05:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.472 X-Spam-Level: X-Spam-Status: No, score=-5.472 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh3xY+Ksw99a for <ecrit@core3.amsl.com>; Tue, 23 Mar 2010 05:48:39 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 6DD573A6BFD for <ecrit@ietf.org>; Tue, 23 Mar 2010 05:45:55 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image.jpg : 6590 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooFAK9UqEurR7Hu/2dsb2JhbACBQ416iUWBTF5zohGKYY5GAoJTgigEgx4 X-IronPort-AV: E=Sophos;i="4.51,294,1267401600"; d="jpg'145?scan'145,208,217,145";a="104379018" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 23 Mar 2010 12:46:14 +0000 Received: from [172.27.172.5] ([10.21.75.99]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2NCkCkX000433; Tue, 23 Mar 2010 12:46:13 GMT User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 23 Mar 2010 05:46:12 -0700 From: Marc Linsner <mlinsner@cisco.com> To: "Dawson, Martin" <Martin.Dawson@andrew.com>, ecrit <ecrit@ietf.org> Message-ID: <C7CE0624.21863%mlinsner@cisco.com> Thread-Topic: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) Thread-Index: AcrKA1Q1g8OpYGRevUanw+3rrw4wnwAAjCqgAAMDCrAAA9B+MAAZf5aI In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E24ECE70@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: multipart/related; boundary="B_3352167973_51452" Subject: Re: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 12:48:45 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3352167973_51452 Content-type: multipart/alternative; boundary="B_3352167973_12001" --B_3352167973_12001 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Martin, I understand your position, I have vast experience in business plans underpinned by regulation. -Marc- On 3/22/10 5:52 PM, "Dawson, Martin" <Martin.Dawson@andrew.com> wrote: > Hi Marc, > =20 > Though this already happens. The reason we have POTS and cellular E9-1-1 = is > that operators are required to give PSAPs access to their network locatio= n > service. You don=B9t want that requirement to continue for the IP service i= n > addition to the circuit service. > =20 > You are entitled to your opinion on this. Nevertheless, it=B9s the only thi= ng > that will allow an enhanced emergency calling service to be supported in = the > future. Given Internet based emergency calling will eventually replace (f= ixed > and mobile) circuit based emergency calling, a failure to introduce this > regulation would result in a real effective deterioration in the quality = of > emergency services. > =20 > I=B9m not sure if that=B9s your goal. > =20 > Cheers, > Martin > =20 >=20 >=20 > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of= Marc > Linsner > Sent: Tuesday, 23 March 2010 9:47 AM > To: Winterbottom, James; ecrit > Subject: Re: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) > =20 > James, >=20 > From Ray=B9s message: >=20 > =B3and that LIS permitting queries from the PSAP. =B3 >=20 > I am obviously against forcing the access provider to establish a > business/technical relationship with the PSAP. This goes well beyond > requiring the access provider to supply location to it=B9s customer. >=20 > -Marc- >=20 > On 3/22/10 2:29 PM, "Winterbottom, James" <James.Winterbottom@andrew.com> > wrote: > Hi Marc, > =20 > Requiring the access network to have a location service suitable for prov= iding > routing and dispatch information for emergency services is a fundamental > aspect of i2, i3 and ECRIT. Furthermore, the LIS needs to provide locatio= n > information that will result in a valid route to the PSAP. If civic locat= ion > information is used then this must line-up with the profiles for civic fi= elds > used in the local LoST server, so much of the relationships and requireme= nts > are you concerned about below are already pivotal to deployment of the ba= sic > ECRIT solution as defined in phone BCP. > =20 > What Ray is talking about from this point is that there is likely to > regulation in the UK requiring ISPs and access providers to have a LIS, > largely because this is seemed to be the best way to enable progression > towards a NG emergency solution. Experience in the cellular world, clearl= y > show that without regulation access providers will not put this equipment= in > place so that the services can progress. Discussions I have had with carr= iers > has resulted in the same answer, without regulation they are not going to > spend the money required to make it happen. This impacts all the solution= s not > just ECRIT Direct. > =20 > Cheers > James > =20 > =20 >=20 > James Winterbottom Global Product Manager Andrew GeoLENs IP Location > Product Portfolio Email: james.winterbottom@andrew.com Phone: +61-2-42-21= 2938 > Mobile: +61-448-266004 >=20 >=20 > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of= Marc > Linsner > Sent: Tuesday, 23 March 2010 8:05 AM > To: Ray.Bellis@nominet.org.uk; ecrit > Subject: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) >=20 > Ray, >=20 > Assuming this pertains to the conversation around ECRIT Direct. >=20 > IMO, it=B9s unfortunate that regulators are led to the conclusion that you > outline. Forcing a business/technical relationship between an access pro= vider > and public safety is only going to stifle those offering or wanting to of= fer > access services, in the end harming the consumer of Internet services. B= ut I > suppose that=B9s the intention of those proposing such to the regulators. > Regardless, the IETF should not put forth any architecture that forces th= ose > relationships. >=20 > I believe that using UK regulation as justification for the ECRIT Direct = work > will actually be detrimental to it=B9s progress within the IETF. >=20 > -Marc- >=20 >=20 >=20 >=20 > On 3/22/10 10:20 AM, "Ray.Bellis@nominet.org.uk" <Ray.Bellis@nominet.org.= uk> > wrote: > To back up what James W just said at the mic: >=20 > The proposed UK model for emergency service access over VoIP depends on e= ach > ISP running a LIS and that LIS permitting queries from the PSAP. >=20 > It's my belief that this will be enshrined in UK law via the introduction= by > OFCOM of a new "General Condition of Service" which will apply to any pub= lic > telecommunications provider, including pure IP access providers. >=20 > Ray=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --B_3352167973_12001 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [Ecrit] ECRIT Direct (was: Re:  ISPs and LIS requirements)<= /TITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '>Martin,<BR> <BR> I understand your position, I have vast experience in business plans underp= inned by regulation.<BR> <BR> -Marc-<BR> <BR> <BR> On 3/22/10 5:52 PM, "Dawson, Martin" <<a href=3D"Martin.Dawson@a= ndrew.com">Martin.Dawson@andrew.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><FONT FACE=3D"= Arial"><SPAN STYLE=3D'font-size:10pt'>Hi Marc,<BR>  <BR> Though this already happens. The reason we have POTS and cellular E9-1-1 is= that operators are required to give PSAPs access to their network location = service. You don’t want that requirement to continue for the IP servic= e in addition to the circuit service.<BR>  <BR> You are entitled to your opinion on this. Nevertheless, it’s the only= thing that will allow an enhanced emergency calling service to be supported= in the future. Given Internet based emergency calling will eventually repla= ce (fixed and mobile) circuit based emergency calling, a failure to introduc= e this regulation would result in a real effective deterioration in the qual= ity of emergency services.<BR>  <BR> I’m not sure if that’s your goal.<BR>  <BR> Cheers,<BR> Martin<BR>  <BR> </SPAN></FONT></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:11pt'> </SPAN></FONT> <P ALIGN=3DCENTER> <FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12pt'><HR ALIGN=3DCENTER = SIZE=3D"2" WIDTH=3D"100%"></SPAN></FONT> <P> <FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE=3D'= font-size:10pt'><B>From:</B> <a href=3D"ecrit-bounces@ietf.org">ecrit-bounces@= ietf.org</a> [<a href=3D"mailto:ecrit-bounces@ietf.org">mailto:ecrit-bounces@i= etf.org</a>] <B>On Behalf Of </B>Marc Linsner<BR> <B>Sent:</B> Tuesday, 23 March 2010 9:47 AM<BR> <B>To:</B> Winterbottom, James; ecrit<BR> <B>Subject:</B> Re: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirement= s)<BR> </SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12= pt'> <BR> </SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'= font-size:11pt'>James,<BR> <BR> >From Ray’s message:<BR> <BR> “and that LIS permitting queries from the PSAP. “<BR> <BR> I am obviously against forcing the access provider to establish a business/= technical relationship with the PSAP.  This goes well beyond requiring = the access provider to supply location to it’s customer.<BR> <BR> -Marc-<BR> <BR> On 3/22/10 2:29 PM, "Winterbottom, James" <<a href=3D"James.Wint= erbottom@andrew.com">James.Winterbottom@andrew.com</a>> wrote:<BR> </SPAN></FONT><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><FONT FACE=3D"Arial"><SPAN= STYLE=3D'font-size:10pt'>Hi Marc,<BR>  <BR> Requiring the access network to have a location service suitable for provid= ing routing and dispatch information for emergency services is a fundamental= aspect of i2, i3 and ECRIT. Furthermore, the LIS needs to provide location = information that will result in a valid route to the PSAP. If civic location= information is used then this must line-up with the profiles for civic fiel= ds used in the local LoST server, so much of the relationships and requireme= nts are you concerned about below are already pivotal to deployment of the b= asic ECRIT solution as defined in phone BCP.<BR>  <BR> What Ray is talking about from this point is that there is likely to regula= tion in the UK requiring ISPs and access providers to have a LIS, largely be= cause this is seemed to be the best way to enable progression towards a NG e= mergency solution. Experience in the cellular world, clearly show that witho= ut regulation access providers will not put this equipment in place so that = the services can progress. Discussions I have had with carriers has resulted= in the same answer, without regulation they are not going to spend the mone= y required to make it happen. This impacts all the solutions not just ECRIT = Direct.<BR>  <BR> Cheers<BR> James<BR>  <BR>  <BR> </SPAN></FONT></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:11pt'><BR>   </SPAN></FONT><FONT COLOR=3D"#000080"><FONT FACE=3D"Times New Roman= "><SPAN STYLE=3D'font-size:12pt'><IMG src=3D"cid:3352167972_48216" ></SPAN></FON= T></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-s= ize:11pt'>   </SPAN><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><SPAN STY= LE=3D'font-size:10pt'><B>James Winterbottom</B></SPAN></FONT></FONT><SPAN STYL= E=3D'font-size:11pt'> </SPAN><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><SPAN STYLE=3D= 'font-size:10pt'>Global Product Manager</SPAN></FONT></FONT><SPAN STYLE=3D'fon= t-size:11pt'> </SPAN><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><SPAN STYLE=3D'font-= size:10pt'>Andrew GeoLENs</SPAN></FONT></FONT><SPAN STYLE=3D'font-size:11pt'> = </SPAN><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>IP = Location Product Portfolio</SPAN></FONT></FONT><SPAN STYLE=3D'font-size:11pt'>= </SPAN><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><B= >Email:</B> <a href=3D"james.winterbottom@andrew.com">james.winterbottom@andre= w.com</a></SPAN></FONT></FONT><SPAN STYLE=3D'font-size:11pt'> </SPAN><FONT COL= OR=3D"#000080"><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><B>Phone:</B> +61-2= -42-212938</SPAN></FONT></FONT><SPAN STYLE=3D'font-size:11pt'> </SPAN><FONT CO= LOR=3D"#000080"><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><B>Mobile:</B> +61= -448-266004</SPAN></FONT></FONT><SPAN STYLE=3D'font-size:11pt'>   </SPAN></FONT> <P ALIGN=3DCENTER> <FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12pt'><HR ALIGN=3DCENTER = SIZE=3D"2" WIDTH=3D"100%"></SPAN></FONT> <P> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '><BR> </SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"ecrit-bounces@ietf.org">= ecrit-bounces@ietf.org</a> [<a href=3D"mailto:ecrit-bounces@ietf.org">mailto:e= crit-bounces@ietf.org</a>] <B>On Behalf Of </B>Marc Linsner<BR> <B>Sent:</B> Tuesday, 23 March 2010 8:05 AM<BR> <B>To:</B> <a href=3D"Ray.Bellis@nominet.org.uk">Ray.Bellis@nominet.org.uk</a= >; ecrit<BR> <B>Subject:</B> [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements)<B= R> </SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12= pt'><BR> </SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'= font-size:11pt'>Ray,<BR> <BR> Assuming this pertains to the conversation around ECRIT Direct.<BR> <BR> IMO, it’s unfortunate that regulators are led to the conclusion that = you outline.  Forcing a business/technical relationship between an acce= ss provider and public safety is only going to stifle those offering or want= ing to offer access services, in the end harming the consumer of Internet se= rvices.  But I suppose that’s the intention of those proposing su= ch to the regulators.  Regardless, the IETF should not put forth any ar= chitecture that forces those relationships.<BR> <BR> I believe that using UK regulation as justification for the ECRIT Direct wo= rk will actually be detrimental to it’s progress within the IETF.<BR> <BR> -Marc-<BR> <BR> <BR> <BR> <BR> On 3/22/10 10:20 AM, "<a href=3D"Ray.Bellis@nominet.org.uk">Ray.Bellis@n= ominet.org.uk</a>" <<a href=3D"Ray.Bellis@nominet.org.uk">Ray.Bellis@n= ominet.org.uk</a>> wrote:<BR> To back up what James W just said at the mic: <BR> <BR> The proposed UK model for emergency service access over VoIP depends on eac= h ISP running a LIS and that LIS permitting queries from the PSAP. <BR> <BR> It's my belief that this will be enshrined in UK law via the introduction b= y OFCOM of a new "General Condition of Service" which will apply t= o any public telecommunications provider, including pure IP access providers= . <BR> <BR> Ray <BR> <BR> <HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT><FONT SIZE=3D"2"><FONT FA= CE=3D"Consolas, Courier New, Courier"><SPAN STYLE=3D'font-size:10pt'>___________= ____________________________________<BR> Ecrit mailing list<BR> <a href=3D"Ecrit@ietf.org">Ecrit@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/ecrit">https://www.ietf.org/= mailman/listinfo/ecrit</a><BR> </SPAN></FONT></FONT></BLOCKQUOTE> </BODY> </HTML> --B_3352167973_12001-- --B_3352167973_51452 Content-Type: image/jpeg; name="image.jpg" Content-ID: <3352167972_48216> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8l JCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIo Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAAR CAByAUEDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2U9KTPao57iG2haWeVI0UZLMcAVx+rfEa yt2MOlxG7l6BzkJn+Z/Ck2lub0MNVru1ON/yOzdljUs7BVAySTgCmNcQpD5zTRiPGd5YAY+t eL6x4g1fVpGW+uHVc/6gfKo/D/Gqjz3+oukBknuGA2xxgk4HTAFZe1WyPchkM+VSnNI9T1Hx 3odhuVbhrmQfwwjI/PpVKw+IunzRTy3qG2CsBFGuWd/XiuJ/4RHXPPhgFi3mSruC54Rf9o9q 6/RPhxa2+JtWcXMnXyU4QH39aFKo3sFbC5ZQpazcn5Mkg8Zarrd2sOiaSxi3Yaeboo/lXaJn bzUdvBDbRCKCJIo14CoMAVLWqT6nh1qlOb/dxsvxFopMijNMwFopMj1oyPWgBaKTIpaACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAx 9b8PW2vpBHeSSCKFt2xDjccY5qTT/D2k6WALSxiQ93K5b8zWnikxxSsnqae2qKHJzadjzyPw Hd6vq11falN9mglmZgi8uwzx7CsfxV41tvh9qy6R4d02zmlSMNcyT7mYMegyCO39K9Tvppra xnngt2uJY4yyRL1dscD8a8Hm+H3jjVE1PVrqxC3M75eGRlMku45O3sAPr2pxhFO5tiMdXrJR k9Oy2O/8R/ES70bwNo+uW1tbSXOo7d0b7tinblsYOeo9a5+6+NF+NE06ezsrJ9QnkkjuYn37 Y8EbSvOeQf0rP1vwl4t1Hwl4b0lNInL2SyifLL8hL/KevZTUJ+FesWfje2hhsZZdJW4jY3G5 cBOCc854q0lY4byOj8SfE7xDpXiYaJpmlWl3MIYyybHZzIV3MAAegp2nfF+a+8K6teyafDDq WnIjKhLGKTc236jvxmuf1Tw744i+IF94h0vRZDIZ3MDuUIAI2g4J9KbN8NPEmn+D5kWzN1qW o3CGWKJwfKjTLDJzgkse1GgXZaT41+IIfs1xeaPYG1mJ5iLhmAOGx8xwfqK0/EXxX1ix8Uy6 TpVlYSRKE2tcsynJUE5O4Ada53QPhzrel+KtLn1DQmvLAlHnBZcRkjnIzyVP8qg1XwZ4tu/E 2oanJ4Za7SeeRwkjqFIJ4PDelOyFdnXat8SvEOjLoRurDTd2pIXmKlmVBvx8pDY6c96qJ8ap 2v8AVFNna/ZYI3ayPzbpWBwu7nv14FHxB8G67q2i+HV0/SvMmtrby5oYiAIuAccn8K5jU/hT 4igmsIbLT5JhJbRtcS7l2xysTuB57DHT0pLlG+Y9Z+HniTV/FeiPqmp2ttbI0pSAQBhvA6k5 J78fga62uW8P2WraNd22jpAg0m2g2BwB1AHOeuSf5mupqGWtgooooGFFFFABRRRQAUUUUAFF FFABRSUUALRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFJRQBDdz/Z7WSbaWKLk Ko5J7AVkw3l//ZRW63x3EcgWZ1TJCn+IAfl+tbZ5FJgZpp2Ja1MU6q1sfLt2e8VRndIfmfPZ cAA4xz9aautagx2fY4t/JzubHBx6etbm0DHTj2o2j0FO67E8r7nPJrE6XLMxZ/NOArZEcGOu 4Yzj0Oec09vEMysF8iIFgSGYthcdjx1OMit7aCOn6U0wozq7KCy5wSKd12Dll3MiDWLq9t7t orRo3jXKBgc59CPXjNMOqCzH+j3El7uG4+bngj+EYX7xz0PpW7t9KTYPQetK6HyvuYb65dRS BZLeJFd9iuWbC8E5PFNHiG6fbss1y+MIxbcn+9x37VutEj43KDtORkdDShBkn1p3j2Fyy7lL Tr9r15FaBojEQr5P8fUge2MHPvWhUccax52ADJJPuTT81LLV+otFJmlpDCkoJxXP3Os3upX0 lhoSx/uTtnvJBlIz6KP4jQB0FGawh4bnlG6517Unk9YpRGv5AVFPDr+iqZ7a6Oq26cvBMoEu P9lh1/GgDo6KpaZqlrq1kt1avuQ8EHqh7gjsau0AFFJSE4FACk4BNIjq6hlOQeQage7hwVUl zj+Bc1FZXUQtYg25PlA+ZcUXK5Ha9i6TijOaaWDKSORjrWT4VvrnUNFFxdy+ZKZpF3YA4DkD p7Cgk2KKyPFV7c6d4euLq0l8qZNu1sA4ywHeoRo+ulQf+Enl5H/PpHQBu5pCwzisyw03VLa6 El3rj3cQBzEbdEyfXIqh4k1u70bU9PMERnikD+dEByVAByPccmgDpKKr2d7b39rHdWsiyxSD KsKsUAJRmmTsVgkYHBCkj8qzPC95cah4ds7u6k8yaVMu2AM8n0oA16KKKACiiigAooooAaTi qr32zVYLLZnzYnk3Z6bSBjH4/pVvGapSWe/VYb0yACKJ49uOu4qc/pQVG19SgPE0LW2oP5JE tkX/AHbHHmBe4P6e1Tarqd5Z/ZGt7WKZbhxH88pUhiCR2PHFV7nw3Fc6bcWz3G2SSaSWOVRg puPK+47Gr15YG7S1USqn2eZZen3sAjHt1pG79kpJoq6xrsmlzRR/Z4nzC00haXbgAgELxyea s3epvELeK1t/OublSyRs20BRjJY9hyB+NVdY0FNWuobkzKklvGREdudr5BDfpjFWLuxmna3u IbhIryBSocrlWB6gj0yAaBfurR763/QdaalLK89vcwCC5hXeyK24Mp6EH8MVW0vXJ7xrZbqz Fv8Aa4vNgZZN4YdSDwMHHNWLSwkjkmubq4Wa5mQIWVdqqo6AD8aq6Xos9o1sby8jn+xxmOBY 02gZ4JOScnHFAWp2f9fcTT635Ftfy+SD9jmEWN/3shTn2+9+lS3uozxXa2dnbLPOV8xgz7FR c4BJwepzjiql1ok1xPcKl3GlpdSLJNHsy24Y+6c8A7RVm9sp3uxe2NzHDceX5b+Ym5XXORkZ B4JNMLU9B0upTW8dmZrbZJczCJk352Eg8579P1pja3DFrjaZMhT5FZJT90k5+X2PH406awmu YrPzrlGltphKzhMBsAjAHbr+lNm0iG6u7uS4ZZIrmNEKdCNuec/j+lIlKn1EXWk/s6W7eI/L M0KRqcl2DbQB9TUtld30sxivbFYPl3K6Sb1+h4GDVWDQvK0gWRu3aRJzNHO3LBt24E+ppbHS JY9TOo3lxHJOVKjyVKKQe5BJyeKCmqdnY2RS03cPUfnRuHrTOcyfFF9NZaM4tji4uHWCI+hb jP4DNW9K02HStNhsoRhY1wxH8Tdyay/FTbP7JnY/uotQjMnsOef8+tb+73H50ALQRmmSM+xv L278Hbk8Z7ZrE87xb/z76R/39k/woA1bbTrSzknkt4Vja4ffJt/iPrRe6ha6dB515OkMecZc 4z9PWsmx1bV/7fXS9Sgsl3QGbdbuzYwcc5rPs7/SL7WrvUdVvbVWglMFrDNIBsVerYPcnvQB rQeLNGnmEQujGzHapmjZAx9iRir4BuyWb/Ug8AH7/v8ASs3UdW8P3llJbzX9hMjDbtaVT+Xp Wdo2tR2Gj6nD9qS6TTCfIkDZ3oRlRnv6Uikmbl/rGm6UFS6uEjZh8sajcx+ijmq2keINKvVj tY7kLNtwI5VKFvoD1qHw5YRw2Y1K9eOXUbtfMllYglQeij0AFWbjTbHV9JSC52btoKSAjdG3 Yg0DtozS2eXuKjAxyB0rF8E/8i4v/XxN/wChmpfDV/NeaS8d22bm1kaCVv7xXv8AliovBH/I uL/18Tf+hmmSHjf/AJFS7/4D/wChCtlLu22D/SIun98Vj+N/+RUu/wDgP/oQqVfCPh4qD/ZF ryP7lAjVS4hkbbHLG59FYE1hawM+LtBz6zf+gGtGy0DSdNuPPstPhglxt3ouDis/WP8AkbtB +s3/AKBQBBd283ha8fUbGNpNMlbN1bKP9Uf76j+Yrore5iu7eO4t3WSKRQyuOhFSFVIIIyD1 BrmJY5PCN41zCrSaPO+ZYxz9lYn7wH931oA6S4/49pf9w/yrH8F/8ijp/wD1z/qa1XlSayeS N1dHjJVl5BGOtZPgz/kULD/rmf5mgCe88T6TY3JtprrMq/fEaM4T/eIHH41pW88V1Cs0EiyR OMq6HIIrl/Dl9Z6THLpOplbW9MzF2mGBcZJwwboeO1dLZWltZW4itI1jiJLBV6ZPNAFiiiig AooooASmPDHIQXQEipKKAIPskH/PMUfZYP8AnmKmooHzPuQ/ZIP+eQo+yQdox+dTUUBzPuQ/ ZIMf6sUfZIP+eYqaigOZ9yH7JB/zzFH2WD/nmKmooC7IfskH/PMUfZYP+eYqaigOZ9yH7Lb/ APPIUfZIP+eYqaloDml3IPskH/PJaPskH/PIVNRQHNLuZ+p6Pbajp01oy7PMXAYdVPY/nWdo d7HJ/wASvU41i1K3G1gTgTAdHX1zXQ1S1PSLHVY1W8hDFOUdTh0PqCORQHM+5OLWDH+rFV72 Sw063e5u2SKJRyWPX6etZ40DUovkt/Ed5HH6PGkh/M0+38L2a3Aur6afUZ1+61y2VX6L0oHz PuVvD9ob+7utcuYDElyBHbRN1WMdz7moNB07T477UdMvLOCS4iuGlQyRglo3OQRnqB0rqwAB Wbqei22pvHKzSQXMX+ruIW2uvtn09qBXG3Oi6WsDkadaqVGc+Uvas5rLSde0K+XTLWOPcHiW RYgu5h0I9Rmpm8OXVyvl6hrt5dQd4lVY9w9CRya07eGPToUt4kEdsgwgUcIPT/69IabMzw+L DUtGhc20QniTypoyvKOvBBq4n2Gx0lbidIo4o49zMVHAqC/8PwXdyb60uZrK6YfNLbtw49x0 NVbLwwlwkM2p6hcagqYZIpMLGD7qOtHUrmbjuS+FLdv7Nub6WLy2vrh51UjBCnp/j+NHgn/k XF/6+Jv/AEM1thgw2p93pkdKw4/CFpApWDUtUhQsW2R3RVQScngCmQO8b/8AIqXf1T/0IVup 9xfpWXJoFvPo0ml3FxdzQyNuLyy7pOufvH6VXHhSLH/IY1j/AMDD/hQI3q57WP8Akb9B+s3/ AKBVyx0JNPuhcLqOozkAjZPcl1/KrFxpsFzqFrfSF/NtC3l4PB3DBzQBdprxpIjI6hlYYIPQ ilHSloA5KZZfCLyIN0miz5weptWPb/dNWvC1zFY+CLS5nYrHFEWcgZwMmt+aGKeB4ZY1eN1w ysMgiq1jptvp+nLYRLugUFQr8/Ke1ABJBYaxYo00MVzBKoZd654Pp6Vh6JdDSP7YtgZp7Owm URAfMygjlRk9jVlfDU1sDFp2s3VnbMSTCqqwXP8AdJ5Wr1potnZ6a9hEH8uQku7NlnY9ST60 AOOsWqh95dGR0RlYchmxgfrz9DV8VnSaNaSly4fL78nd/e6/lzj0ya0FoAdRRRQAUlVb29i0 +3a4nEpjXljHGz7R6kAdKhtNXt7y5jhjSYGWJpVMkRTKggdDg/xCnZicknY0aKSo/Oj87yd4 8zbu255x0zSGS0lIc1BZ3kd5HI8YYCOV4juHdTg/yoFcs0VG88URQSSKpkbamT944JwPwB/K n0DCioYriKeSZY23GF9j8dGwDj8iKgutRhs7mGGXcPMR3L8bUVcZJJ92A49aLCuty9RTQeKa k0cpcRurGNtrgH7pwDg/gR+dAXJKKbURu7cTeT56CTds2553Y3Y+uATQMnopDSHlcUALS1nQ 6tbyaUdTcSQ24BILjnbnGcDPWr4o2EncWiimSyxwhTJIqBmCjccZJ4AoAfRUcM0c8YlicOjd GU5Bp/vQMWg4Iqjd6rbWVylvIs7yyIXCwwtIdoIGTtBxyRVtTuAYDAPrRYV0RvbR4JUFPXaS KisoI/skRO4/KOCxIqS9u47K382VWKl0T5RzlmCj9TTJ7iKwW3jdWxLKIUx2JBPPtxRZlc+j Vy0AAMDgUtNFQQXkc91c26Bg9syq5I4OVDDH4GjUlss0VWtbu3vLcz28qyRgspI7EHBH6U+1 uI7q1juIW3RSqGRsYyDQFyaimRSxzKWjdXUMVJBzgg4I/A06gYtLVW+u47G0a4lDFFZVIUc8 sAP1NWGZUUsxAAGST2FArjqSqVlqdtfsywGTIG4b42UMPVSRyPcVJcXcdtNbxyBs3EvlpgdD tJ5/I0WdwurFmlqGa6gtyBNKke4MRuOMgDJ/IU9XV0DqQVIyCO4oHcfRTciloAWiiigCnqyP Jo17Gilna3kCqoySdp4FYd9pz3MlqzQzEw6Y+0oWXbJ8mBx346e1dPikwaqMrGcoKRx1rHqs mpwyXDOlwZUbPlSk+VgZGc7AOuc8irniK3vJ7uVYBcBHtY13Q5GD5y5wR325/CulwaMU+fW4 vZq1rnKNbNb3csF1Fd/2THMwRY/MY52IQePmK53dO9ULCO8t9PvreOG+jN3lbVXVyc+a5JY/ w8FTk44rusGjb60/aaCdLW9zjfs00+oxqLe6lRLwSmWRXVlO2Tg84IHy4I4wQKdDa3djY2Fv AZhJqkKxTiR2LRvjLPycjjI46HFdhg1E9rFJcpcMgMsYKo3oD1xRzj9nbUxLqE2+vWZt4Z3A 2rs2tswSdz7hxuHfd14xUXiaxlmuxcQQyvIljOqum7hiUwOO/J/yK6XBowfWlz2dx8iascfe W88ZuLgx3bzfbZDGgEhSQADap2n5RnOD0z1rW061a2j1iTypo2luWcbclm/dryue+c4962cH NKBQ53BU7HHWr3Nqm4xXf2cQzQo4jl3SOwQqxU5IOQwz0z04qG40/VHVSkUxuonjMTMThW+z EE5/3sD6125B7UYNNVNbkuldWuc94aiuEuZiXYQGMAoYpV+fPJzIc5x6cVXeKZp5FKXZ1Q3L bX+fyvK3cc/d27PxzXU4NG2lzalcmljl0sXt/h89tHbyiTyGJjwS2c+nX8KbdO1093NsvTdu c6eyJIqgY4yMADnOd1dVg0Yo5w9na1jlWjn8u5/d3h1gs+HXfsKZOMH7n3cY75qjcWUVzq9s tla6gbZTEZfNEoXeJVOfm7gZyRxXcYNBGaaqWJdK6tc462hkFoo1SK9JEf8AooiEnDZbOdvQ 5x97jGKksLLUY7iK8uBcG7a/WOU7mK+X5Y3cdNu7v611oGKMGk5jVJdzndYRV8QW0s0t7DEL Vl8y1Rmy29Tg7VNVry21D+0Lm4shcec9xsjZi20x/Z89DwPnHX1rq8UmD6ChTsDp3OC1W3SU omn2uqtF5ObgESZLeZGeN3V8A8jirl1b3Dsv9jQ3It1lUoJlfiXa/I3845GT0ziuywaCKftO gvZHFW8OoLC5BnMGE+1pHHMGYbhvILnJOM/d/wAK2PDsMaXWpNbwzx27zIYvOVgWGwAkbucZ rd20YNJzuUoWZzmmafdWulR3VrGVuP3gmgYbRMN7Y+jY6H86xorbVY4baNw8MqQRC1HlSsU+ UZ+6QoOc53V3mDQR701UaE6SZxdvpeqos1lbedDFdTyyvKGI8pkckYz2f5fwBq2Eupo4LzVY rlYLku9xBFvJiYABBheccN07kV1OKMUOo30BUkupw1/p+pXUM3lx3PyQg2fmbjs/fLt3DuQB nntium07cNKeOW3laaMMsschyZG6nBPBBzx257Vp4PrRg0nO6sEafK7nJ7roxGDTvtxsQFM0 csbK8Q3DKISAT8u7pnGBg81W1K1uZotukxXQtQ2Yg4cMJPLkBK7vmA5A5712uDRimp2E6V1a 5xeoQXGo6k15DBdPEIZBCWR1IcQsOFOCMkgdOTVmaOXEv2mO8N5sT7CYg+F+QdccA7s53dq6 vFGMUc/kP2fmceltfRtPJKLtWnF0s7xBmxym0qCf94jHvW/oDSHSkEkRj2sVXO4b1zw2G+YZ 9DWgFpwFS5XHGHKxaKKKk0CiiikAlFFFMTCloooASiiigBaKKKACiiigBKKKKYBRRRSBBRRR TAKWiigAooopAJRRRTEFHeiikMWiiigApKKKBhRRRTEFLRRSAKKKKAEooooAKWiigYUUUUAf /9k= --B_3352167973_51452-- From mlinsner@cisco.com Tue Mar 23 06:27:28 2010 Return-Path: <mlinsner@cisco.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 483233A6B22 for <ecrit@core3.amsl.com>; Tue, 23 Mar 2010 06:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.471 X-Spam-Level: X-Spam-Status: No, score=-7.471 tagged_above=-999 required=5 tests=[AWL=1.998, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 562Btvq2BtHP for <ecrit@core3.amsl.com>; Tue, 23 Mar 2010 06:27: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 3E1953A6BF1 for <ecrit@ietf.org>; Tue, 23 Mar 2010 06:26:14 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM5dqEurR7Ht/2dsb2JhbACbLHOiJIsNCI4QAoJTDgiCEgSDHg X-IronPort-AV: E=Sophos;i="4.51,295,1267401600"; d="scan'208";a="310915058" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 23 Mar 2010 13:26:33 +0000 Received: from [172.27.172.5] ([10.21.75.99]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2NDQVvG028709; Tue, 23 Mar 2010 13:26:32 GMT User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 23 Mar 2010 06:26:30 -0700 From: Marc Linsner <mlinsner@cisco.com> To: Richard Barnes <rbarnes@bbn.com> Message-ID: <C7CE0F96.2186F%mlinsner@cisco.com> Thread-Topic: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) Thread-Index: AcrKjHKTAYLizkriy0i4ANJkS6yIAg== In-Reply-To: <AFDFB414-A963-467C-A387-74B9FB98D918@bbn.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: ecrit <ecrit@ietf.org> Subject: Re: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 13:27:28 -0000 Richard, The technical aspects are always the least onerous part of regulation. -Marc- On 3/22/10 10:07 PM, "Richard Barnes" <rbarnes@bbn.com> wrote: > How onerous is this, really? In order to supply location to > endpoints, ISPs are already required to operate a location server of > some sort, DHCP or HELD. Allowing PSAP access just means that they > have to add an account and maybe a firewall rule. >=20 > --Richard >=20 >=20 >=20 > On Mar 22, 2010, at 3:46 PM, Marc Linsner wrote: >=20 >> James, >>=20 >> From Ray=B9s message: >>=20 >> =B3and that LIS permitting queries from the PSAP. =B3 >>=20 >> I am obviously against forcing the access provider to establish a >> business/technical relationship with the PSAP. This goes well >> beyond requiring the access provider to supply location to it=B9s >> customer. >>=20 >> -Marc- >>=20 >> On 3/22/10 2:29 PM, "Winterbottom, James" <James.Winterbottom@andrew.com >>> wrote: >>=20 >>> Hi Marc, >>>=20 >>> Requiring the access network to have a location service suitable >>> for providing routing and dispatch information for emergency >>> services is a fundamental aspect of i2, i3 and ECRIT. Furthermore, >>> the LIS needs to provide location information that will result in a >>> valid route to the PSAP. If civic location information is used then >>> this must line-up with the profiles for civic fields used in the >>> local LoST server, so much of the relationships and requirements >>> are you concerned about below are already pivotal to deployment of >>> the basic ECRIT solution as defined in phone BCP. >>>=20 >>> What Ray is talking about from this point is that there is likely >>> to regulation in the UK requiring ISPs and access providers to have >>> a LIS, largely because this is seemed to be the best way to enable >>> progression towards a NG emergency solution. Experience in the >>> cellular world, clearly show that without regulation access >>> providers will not put this equipment in place so that the services >>> can progress. Discussions I have had with carriers has resulted in >>> the same answer, without regulation they are not going to spend the >>> money required to make it happen. This impacts all the solutions >>> not just ECRIT Direct. >>>=20 >>> Cheers >>> James >>>=20 >>>=20 >>>=20 >>> <image.jpg> James Winterbottom Global Product Manager Andrew >>> GeoLENs IP Location Product Portfolio Email: james.winterbottom@andrew.= com >>> Phone: +61-2-42-212938 Mobile: +61-448-266004 >>>=20 >>>=20 >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> Behalf Of Marc Linsner >>> Sent: Tuesday, 23 March 2010 8:05 AM >>> To: Ray.Bellis@nominet.org.uk; ecrit >>> Subject: [Ecrit] ECRIT Direct (was: Re: ISPs and LIS requirements) >>>=20 >>> Ray, >>>=20 >>> Assuming this pertains to the conversation around ECRIT Direct. >>>=20 >>> IMO, it=B9s unfortunate that regulators are led to the conclusion >>> that you outline. Forcing a business/technical relationship >>> between an access provider and public safety is only going to >>> stifle those offering or wanting to offer access services, in the >>> end harming the consumer of Internet services. But I suppose >>> that=B9s the intention of those proposing such to the regulators. >>> Regardless, the IETF should not put forth any architecture that >>> forces those relationships. >>>=20 >>> I believe that using UK regulation as justification for the ECRIT >>> Direct work will actually be detrimental to it=B9s progress within >>> the IETF. >>>=20 >>> -Marc- >>>=20 >>>=20 >>>=20 >>>=20 >>> On 3/22/10 10:20 AM, "Ray.Bellis@nominet.org.uk" <Ray.Bellis@nominet.or= g.uk >>>> wrote: >>> To back up what James W just said at the mic: >>>=20 >>> The proposed UK model for emergency service access over VoIP >>> depends on each ISP running a LIS and that LIS permitting queries >>> from the PSAP. >>>=20 >>> It's my belief that this will be enshrined in UK law via the >>> introduction by OFCOM of a new "General Condition of Service" which >>> will apply to any public telecommunications provider, including >>> pure IP access providers. >>>=20 >>> Ray >>>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From dirk.kroeselberg@nsn.com Tue Mar 23 06:58:04 2010 Return-Path: <dirk.kroeselberg@nsn.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B11243A6C0D; Tue, 23 Mar 2010 06:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 ocCztef2bue4; Tue, 23 Mar 2010 06:58:02 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 47A803A6BB4; Tue, 23 Mar 2010 06:57:58 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2NDvt1I028954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Mar 2010 14:57:56 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2NDvn76001926; Tue, 23 Mar 2010 14:57:55 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 14:57:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CACA90.D2A1EED3" Date: Tue, 23 Mar 2010 14:56:36 +0100 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF67025DB6B2@DEMUEXC030.nsn-intra.net> In-Reply-To: <BLU137-W16A7478A99589D829B03D793260@phx.gbl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrKWwTX2TPkssDKTfm6ildu39l7JgAMywGA References: <4BA7800A.4040406@gmx.net><201003221619.o2MGJc2G006891@sj-core-2.cisco.com><8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net><BLU137-DS1318F3081E30928873CA2D93270@phx.gbl>, <62D89A2E-1066-4932-91CE-59A7798655E3@cs.columbia.edu><BLU137-W26F0443F14828D573CC84493270@phx.gbl><A8BCA059-789B-4A66-B2AE-69F72C816248@cs.columbia.edu> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB1AB@DEMUEXC030.nsn-intra.net>, <AC1CFD94F59A264488DC2BEC3E890DE509E6BFCB@xmb-sjc-225.amer.cisco.com> <BLU137-W370951B6C399E53F93420993260@phx.gbl> <93B8DBC9-FE13-4617-9ED2-5901E5BAF939@bbn.com> <BLU0-SMTP1377A7E38D5F6553186CC793260@phx.gbl>, <B9E6D716-3CC7-44FE-8A1D-08F366A42D20@bbn.com> <BLU137-W16A7478A99589D829B03D793260@phx.gbl> From: "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com> To: "ext Bernard Aboba" <bernard_aboba@hotmail.com>, <rbarnes@bbn.com> X-OriginalArrivalTime: 23 Mar 2010 13:57:49.0711 (UTC) FILETIME=[D2F8E9F0:01CACA90] Cc: emu@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 13:58:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CACA90.D2A1EED3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable in addition to what Bernard said, the functionality does not amount to the same thing because an access network may well allow emergency but not anonymous entry, may not want to put all anonymous users under emergency treatment, etc. It is simple: the peer needs to spell out explicitly that the access request is for emergency.=20 The network needs to know this to apply proper treatment (whatever this will be is up to the network, but it may include authorization decisions in the AAA, priority for some messages, filtering, applying special QoS, etc.). We don't care about this here, but an emergency indication via the NAI has impact outside EAP and the EAP method in the access. =20 Dirk ________________________________ From: ext Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Tuesday, March 23, 2010 8:33 AM To: rbarnes@bbn.com Cc: Joseph Salowey (jsalowey); Kroeselberg, Dirk (NSN - DE/Munich); hgs@cs.columbia.edu; ecrit@ietf.org; emu@ietf.org Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) =09 =09 No, because the "anonymous" NAI is typically used in protocols (like EAP-TTLSv0, EAP-FAST or PEAP) where mutual authentication is required. So while the NAS or an eavesdropper can't determine the client identity, the AAA server can and does determine it (and in turn, proves its identity to the client).=20 =09 So at least in EAP, "anonymous" !=3D "unauthenticated" =09 =09 <http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood>=20 =09 > CC: jsalowey@cisco.com; dirk.kroeselberg@nsn.com; hgs@cs.columbia.edu; ecrit@ietf.org; emu@ietf.org > From: rbarnes@bbn.com > To: bernard_aboba@hotmail.com > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) > Date: Mon, 22 Mar 2010 22:43:28 -0700 >=20 > Doesn't it functionally amount to the same thing, though? Just the=20 > client choosing not to authenticate vs not being able to authenticate? > --Richard >=20 >=20 > On Mar 22, 2010, at 10:29 PM, Bernard Aboba wrote: >=20 > > Yes, there is an "anonymous" NAI, but the goal of that is to hide=20 > > the identity from the NAS and eavesdroppers, not to enable client=20 > > unauthenticated access. > > > > On Mar 22, 2010, at 10:23 PM, Richard Barnes <rbarnes@bbn.com> wrote: > > > >> In particular, providing unauthenticated *network* access is a=20 > >> prerequisite for providing unauthenticated *VoIP* access. > >> > >> Also, Bernard: Does your below mention of "anonymous" NAI indicate=20 > >> that there is actually a reserved NAI "anonymous"? If so, then I=20 > >> don't really see the use for a separate "sos" NAI -- you can just=20 > >> provide ECRIT access to "anonymous". > >> > >> --Richard > >> > >> > >> > >> On Mar 22, 2010, at 6:28 PM, Bernard Aboba wrote: > >> > >>> Part of the confusion here may be that we're talking about > >>> "unauthenticated" at multiple layers. There is unauthenticated=20 > >>> network access, and then there is unauthenticated VOIP signaling. > >>> > >>> These are two orthogonal things. The VOIP signaling should not=20 > >>> change regardless of whether the network access is authenticated=20 > >>> or unauthenticated. > >>> > >>> Similarly, it's possible to use authenticated or unauthenticated=20 > >>> VOIP signaling over authenticated or unauthenticated access. > >>> > >>> Focusing solely on how to obtain "unauthenticated" access, the=20 > >>> question is how the client signals that it is interested in=20 > >>> "unauthenticated" access. This is important, because otherwise=20 > >>> the server might request client authentication (e.g. a client=20 > >>> certificate request). Essentially the "sos" NAI is functioning=20 > >>> similar to the "anonymous" NAI in that this results in special=20 > >>> processing on the AAA server side. > >>> > >>> > >>> > >>> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of=20 > >>> serviceattacks on the emergency.com domain) > >>> Date: Mon, 22 Mar 2010 18:14:59 -0700 > >>> From: jsalowey@cisco.com > >>> To: dirk.kroeselberg@nsn.com; hgs@cs.columbia.edu; bernard_aboba@hotmail.com > >>> CC: ecrit@ietf.org > >>> > >>> I do not think EAP or NAI should be used as a signaling mechanism=20 > >>> for emergency. These mechanisms are ways to obtain network > >>> access when you cannot in some other way. Once you have network=20 > >>> access it seems that the emergency procedures should be the same=20 > >>> whether you authenticated to get network access or you gained=20 > >>> access though another mechanism. > >>> > >>> I am probably missing some ECRIT specific nuances here, but I feel=20 > >>> that tying emergency procedures at higher layers to EAP usage will=20 > >>> be fraught with problems. > >>> > >>> Joe > >>> > >>> > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > >>> Behalf Of Kroeselberg, Dirk (NSN - DE/Munich) > >>> Sent: Monday, March 22, 2010 5:26 PM > >>> To: ext Henning Schulzrinne; Bernard Aboba > >>> Cc: ecrit@ietf.org > >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of=20 > >>> serviceattacks on the emergency.com domain) > >>> > >>> yes, fixing the NAI to a simple string is simple (this would=20 > >>> basically be a NAI that is username only, correct?). > >>> > >>> However, let me repeat my question from the other thread: How to=20 > >>> handle the 'authenticated' emergency case where the NAI carries=20 > >>> the regular username? The draft may be about unauthenticated, but=20 > >>> just covering unauthenticated and leaving the authenticated case=20 > >>> open seems less useful to me. > >>> > >>> Dirk > >>> > >>> From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>> Sent: Tuesday, March 23, 2010 1:02 AM > >>> To: Bernard Aboba > >>> Cc: Kroeselberg, Dirk (NSN - DE/Munich); ecrit@ietf.org > >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of=20 > >>> service attacks on the emergency.com domain) > >>> > >>> The "sos" name seems to be a reasonable approach that's simple and=20 > >>> easy. > >>> > >>> Longer term, I think a better option is to have a semi-=20 > >>> authenticated mode: Imagine a setup where VSPs or other trustable=20 > >>> bodies hand out tokens (e.g., using the OAuth-WARP work) that the=20 > >>> ISP recognizes. The ISP is given the right to monitor the usage of=20 > >>> 'sos' sessions and can hand the token to the appropriate=20 > >>> authorities for prosecution in case of abuse. That way, you get=20 > >>> emergency access, but make it unlikely that the system will be=20 > >>> abused on a large scale. In some countries, you might get such a=20 > >>> token from your local public authority when you're registering=20 > >>> your residence. > >>> > >>> Henning > >>> > >>> On Mar 22, 2010, at 7:50 PM, Bernard Aboba wrote: > >>> > >>> > >>> If all you want to do is to gain emergency access to the local=20 > >>> network, you don't need to discover the domain. You can just use=20 > >>> an NAI of "sos". That will be more convenient in situations=20 > >>> where the local access mechanism (e.g. 802.1X) doesn't permit IP=20 > >>> packets (including DHCP) to pass prior to completing=20 > >>> authentication, so that "domain discovery" couldn't occur until=20 > >>> afterwards. > >>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >> > >> >=20 =09 ------_=_NextPart_001_01CACA90.D2A1EED3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <STYLE>.hmmessage P { PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: = 0px; PADDING-TOP: 0px } BODY.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY: Verdana } </STYLE> <META content=3D"MSHTML 6.00.2900.3660" name=3DGENERATOR></HEAD> <BODY class=3Dhmmessage> <DIV><SPAN class=3D535593813-23032010><FONT face=3DArial = color=3D#0000ff>in addition=20 to what Bernard said, the functionality does not amount to the same = thing=20 because an access network may well allow emergency but = not=20 anonymous entry, may not want to put all anonymous users under emergency = treatment, etc. It is simple: the peer needs to spell out explicitly = that the=20 access request is for emergency. </FONT></SPAN></DIV> <DIV><SPAN class=3D535593813-23032010><FONT face=3DArial = color=3D#0000ff>The network=20 needs to know this to apply proper treatment (whatever this will = be is up=20 to the network, but it may include authorization = decisions in the=20 AAA,  priority for some messages, filtering, applying special = QoS,=20 etc.). We don't care about this here, but an </FONT></SPAN><SPAN=20 class=3D535593813-23032010><FONT face=3DArial color=3D#0000ff>emergency = indication=20 via the NAI has impact outside EAP and the EAP method in = the=20 access.</FONT></SPAN></DIV> <DIV><SPAN class=3D535593813-23032010><FONT face=3DArial=20 color=3D#0000ff></FONT></SPAN> </DIV> <DIV><SPAN class=3D535593813-23032010><FONT face=3DArial=20 color=3D#0000ff>Dirk</FONT></SPAN></DIV><BR> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma><B>From:</B> ext Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com] <BR><B>Sent:</B> Tuesday, March 23, = 2010=20 8:33 AM<BR><B>To:</B> rbarnes@bbn.com<BR><B>Cc:</B> Joseph Salowey = (jsalowey);=20 Kroeselberg, Dirk (NSN - DE/Munich); hgs@cs.columbia.edu; = ecrit@ietf.org;=20 emu@ietf.org<BR><B>Subject:</B> RE: [Ecrit] emergency access and = EAP-TLS (and=20 denial of serviceattacks on the emergency.com = domain)<BR></FONT><BR></DIV> <DIV></DIV>No, because the "anonymous" NAI is typically used in = protocols=20 (like EAP-TTLSv0, EAP-FAST or PEAP) where mutual authentication is=20 required.  So while the NAS or an eavesdropper can't determine = the client=20 identity, the AAA server can and does determine it (and in turn, = proves its=20 identity to the client). <BR><BR>So at least in EAP, "anonymous" !=3D=20 "unauthenticated"<BR><BR> <TABLE=20 style=3D"BORDER-TOP: black 1px solid; FONT-WEIGHT: bold; FONT-FAMILY: = 'Segoe UI',Tahoma,san-serif"> <TBODY> <TR> <TD><A=20 style=3D"FONT-SIZE: 9pt; COLOR: rgb(1,132,203); TEXT-DECORATION: = none"=20 = href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGo= od"><SPAN=20 style=3D"PADDING-RIGHT: 24px; PADDING-LEFT: 24px; FONT-SIZE: = 8pt; PADDING-BOTTOM: 0px; COLOR: rgb(63,181,85); PADDING-TOP: 0px; = TEXT-DECORATION: = underline"></SPAN></A><BR></TD></TR></TBODY></TABLE><BR><BR>>=20 CC: jsalowey@cisco.com; dirk.kroeselberg@nsn.com; hgs@cs.columbia.edu; = ecrit@ietf.org; emu@ietf.org<BR>> From: rbarnes@bbn.com<BR>> To: = bernard_aboba@hotmail.com<BR>> Subject: Re: [Ecrit] emergency = access and=20 EAP-TLS (and denial of serviceattacks on the emergency.com = domain)<BR>>=20 Date: Mon, 22 Mar 2010 22:43:28 -0700<BR>> <BR>> Doesn't it = functionally=20 amount to the same thing, though? Just the <BR>> client choosing = not to=20 authenticate vs not being able to authenticate?<BR>> = --Richard<BR>>=20 <BR>> <BR>> On Mar 22, 2010, at 10:29 PM, Bernard Aboba = wrote:<BR>>=20 <BR>> > Yes, there is an "anonymous" NAI, but the goal of that = is to=20 hide <BR>> > the identity from the NAS and eavesdroppers, not to = enable=20 client <BR>> > unauthenticated access.<BR>> ><BR>> > = On Mar=20 22, 2010, at 10:23 PM, Richard Barnes <rbarnes@bbn.com> = wrote:<BR>>=20 ><BR>> >> In particular, providing unauthenticated = *network*=20 access is a <BR>> >> prerequisite for providing = unauthenticated=20 *VoIP* access.<BR>> >><BR>> >> Also, Bernard: Does = your=20 below mention of "anonymous" NAI indicate <BR>> >> that there = is=20 actually a reserved NAI "anonymous"? If so, then I <BR>> >> = don't=20 really see the use for a separate "sos" NAI -- you can just <BR>> = >>=20 provide ECRIT access to "anonymous".<BR>> >><BR>> >> = --Richard<BR>> >><BR>> >><BR>> >><BR>> = >>=20 On Mar 22, 2010, at 6:28 PM, Bernard Aboba wrote:<BR>> = >><BR>>=20 >>> Part of the confusion here may be that we're talking = about=20 <BR>> >>> "unauthenticated" at multiple layers. There is=20 unauthenticated <BR>> >>> network access, and then there = is=20 unauthenticated VOIP signaling.<BR>> >>><BR>> = >>>=20 These are two orthogonal things. The VOIP signaling should not = <BR>>=20 >>> change regardless of whether the network access is = authenticated=20 <BR>> >>> or unauthenticated.<BR>> >>><BR>> = >>> Similarly, it's possible to use authenticated or = unauthenticated=20 <BR>> >>> VOIP signaling over authenticated or = unauthenticated=20 access.<BR>> >>><BR>> >>> Focusing solely on = how to=20 obtain "unauthenticated" access, the <BR>> >>> question is = how the=20 client signals that it is interested in <BR>> >>>=20 "unauthenticated" access. This is important, because otherwise = <BR>>=20 >>> the server might request client authentication (e.g. a = client=20 <BR>> >>> certificate request). Essentially the "sos" NAI = is=20 functioning <BR>> >>> similar to the "anonymous" NAI in = that this=20 results in special <BR>> >>> processing on the AAA server=20 side.<BR>> >>><BR>> >>><BR>> = >>><BR>>=20 >>> Subject: RE: [Ecrit] emergency access and EAP-TLS (and = denial of=20 <BR>> >>> serviceattacks on the emergency.com = domain)<BR>>=20 >>> Date: Mon, 22 Mar 2010 18:14:59 -0700<BR>> = >>> From:=20 jsalowey@cisco.com<BR>> >>> To: dirk.kroeselberg@nsn.com;=20 hgs@cs.columbia.edu; bernard_aboba@hotmail.com<BR>> >>> = CC:=20 ecrit@ietf.org<BR>> >>><BR>> >>> I do not = think EAP or=20 NAI should be used as a signaling mechanism <BR>> >>> for=20 emergency. These mechanisms are ways to obtain network <BR>> = >>>=20 access when you cannot in some other way. Once you have network = <BR>>=20 >>> access it seems that the emergency procedures should be = the same=20 <BR>> >>> whether you authenticated to get network access = or you=20 gained <BR>> >>> access though another mechanism.<BR>>=20 >>><BR>> >>> I am probably missing some ECRIT = specific=20 nuances here, but I feel <BR>> >>> that tying emergency = procedures=20 at higher layers to EAP usage will <BR>> >>> be fraught = with=20 problems.<BR>> >>><BR>> >>> Joe<BR>>=20 >>><BR>> >>><BR>> >>> From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On <BR>>=20 >>> Behalf Of Kroeselberg, Dirk (NSN - DE/Munich)<BR>>=20 >>> Sent: Monday, March 22, 2010 5:26 PM<BR>> >>> = To: ext=20 Henning Schulzrinne; Bernard Aboba<BR>> >>> Cc:=20 ecrit@ietf.org<BR>> >>> Subject: Re: [Ecrit] emergency = access and=20 EAP-TLS (and denial of <BR>> >>> serviceattacks on the=20 emergency.com domain)<BR>> >>><BR>> >>> yes, = fixing=20 the NAI to a simple string is simple (this would <BR>> >>> = basically be a NAI that is username only, correct?).<BR>>=20 >>><BR>> >>> However, let me repeat my question = from the=20 other thread: How to <BR>> >>> handle the 'authenticated'=20 emergency case where the NAI carries <BR>> >>> the regular = username? The draft may be about unauthenticated, but <BR>> = >>>=20 just covering unauthenticated and leaving the authenticated case = <BR>>=20 >>> open seems less useful to me.<BR>> = >>><BR>>=20 >>> Dirk<BR>> >>><BR>> >>> From: ext = Henning=20 Schulzrinne [mailto:hgs@cs.columbia.edu]<BR>> >>> Sent: = Tuesday,=20 March 23, 2010 1:02 AM<BR>> >>> To: Bernard Aboba<BR>>=20 >>> Cc: Kroeselberg, Dirk (NSN - DE/Munich); = ecrit@ietf.org<BR>>=20 >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and = denial of=20 <BR>> >>> service attacks on the emergency.com = domain)<BR>>=20 >>><BR>> >>> The "sos" name seems to be a = reasonable=20 approach that's simple and <BR>> >>> easy.<BR>>=20 >>><BR>> >>> Longer term, I think a better option = is to=20 have a semi- <BR>> >>> authenticated mode: Imagine a setup = where=20 VSPs or other trustable <BR>> >>> bodies hand out tokens = (e.g.,=20 using the OAuth-WARP work) that the <BR>> >>> ISP = recognizes. The=20 ISP is given the right to monitor the usage of <BR>> >>> = 'sos'=20 sessions and can hand the token to the appropriate <BR>> = >>>=20 authorities for prosecution in case of abuse. That way, you get = <BR>>=20 >>> emergency access, but make it unlikely that the system = will be=20 <BR>> >>> abused on a large scale. In some countries, you = might=20 get such a <BR>> >>> token from your local public = authority when=20 you're registering <BR>> >>> your residence.<BR>>=20 >>><BR>> >>> Henning<BR>> >>><BR>> = >>> On Mar 22, 2010, at 7:50 PM, Bernard Aboba wrote:<BR>> = >>><BR>> >>><BR>> >>> If all you want = to do=20 is to gain emergency access to the local <BR>> >>> = network, you=20 don't need to discover the domain. You can just use <BR>> = >>> an=20 NAI of "sos". That will be more convenient in situations <BR>> = >>>=20 where the local access mechanism (e.g. 802.1X) doesn't permit IP = <BR>>=20 >>> packets (including DHCP) to pass prior to completing = <BR>>=20 >>> authentication, so that "domain discovery" couldn't occur = until=20 <BR>> >>> afterwards.<BR>> >>><BR>>=20 >>><BR>> >>>=20 _______________________________________________<BR>> >>> = Ecrit=20 mailing list<BR>> >>> Ecrit@ietf.org<BR>> >>>=20 https://www.ietf.org/mailman/listinfo/ecrit<BR>> >><BR>>=20 >><BR>> <BR></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01CACA90.D2A1EED3-- From rbarnes@bbn.com Tue Mar 23 08:58:17 2010 Return-Path: <rbarnes@bbn.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5EE3A6830; Tue, 23 Mar 2010 08:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.858 X-Spam-Level: * X-Spam-Status: No, score=1.858 tagged_above=-999 required=5 tests=[AWL=0.727, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 jptkItmCGz1o; Tue, 23 Mar 2010 08:58:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 368E23A6358; Tue, 23 Mar 2010 08:58:15 -0700 (PDT) Received: from [128.89.253.232] (helo=dhcp-wireless-open-abg-24-118.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1Nu6Uq-0008bq-Bj; Tue, 23 Mar 2010 11:58:24 -0400 Message-Id: <969ADDD1-2BAF-42D6-BED9-DF3DB1EDBDAA@bbn.com> From: Richard Barnes <rbarnes@bbn.com> To: Bernard Aboba <bernard_aboba@hotmail.com> In-Reply-To: <BLU137-W16A7478A99589D829B03D793260@phx.gbl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 23 Mar 2010 08:58:17 -0700 References: <4BA7800A.4040406@gmx.net><201003221619.o2MGJc2G006891@sj-core-2.cisco.com><8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net><BLU137-DS1318F3081E30928873CA2D93270@phx.gbl>, <62D89A2E-1066-4932-91CE-59A7798655E3@cs.columbia.edu><BLU137-W26F0443F14828D573CC84493270@phx.gbl><A8BCA059-789B-4A66-B2AE-69F72C816248@cs.columbia.edu> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB1AB@DEMUEXC030.nsn-intra.net>, <AC1CFD94F59A264488DC2BEC3E890DE509E6BFCB@xmb-sjc-225.amer.cisco.com> <BLU137-W370951B6C399E53F93420993260@phx.gbl> <93B8DBC9-FE13-4617-9ED2-5901E5BAF939@bbn.com> <BLU0-SMTP1377A7E38D5F6553186CC793260@phx.gbl>, <B9E6D716-3CC7-44FE-8A1D-08F366A42D20@bbn.com> <BLU137-W16A7478A99589D829B03D793260@phx.gbl> X-Mailer: Apple Mail (2.936) Cc: emu@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 15:58:17 -0000 Ah, ok, that makes sense. So maybe we just need an "unauthenticated" token? Still don't see anything really emergency-specific in this, besides specifying what constraints you might put on unauthenticated users. --Richard On Mar 23, 2010, at 12:32 AM, Bernard Aboba wrote: > No, because the "anonymous" NAI is typically used in protocols (like > EAP-TTLSv0, EAP-FAST or PEAP) where mutual authentication is > required. So while the NAS or an eavesdropper can't determine the > client identity, the AAA server can and does determine it (and in > turn, proves its identity to the client). > > So at least in EAP, "anonymous" != "unauthenticated" > > > > > > CC: jsalowey@cisco.com; dirk.kroeselberg@nsn.com; hgs@cs.columbia.edu > ; ecrit@ietf.org; emu@ietf.org > > From: rbarnes@bbn.com > > To: bernard_aboba@hotmail.com > > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of > serviceattacks on the emergency.com domain) > > Date: Mon, 22 Mar 2010 22:43:28 -0700 > > > > Doesn't it functionally amount to the same thing, though? Just the > > client choosing not to authenticate vs not being able to > authenticate? > > --Richard > > > > > > On Mar 22, 2010, at 10:29 PM, Bernard Aboba wrote: > > > > > Yes, there is an "anonymous" NAI, but the goal of that is to hide > > > the identity from the NAS and eavesdroppers, not to enable client > > > unauthenticated access. > > > > > > On Mar 22, 2010, at 10:23 PM, Richard Barnes <rbarnes@bbn.com> > wrote: > > > > > >> In particular, providing unauthenticated *network* access is a > > >> prerequisite for providing unauthenticated *VoIP* access. > > >> > > >> Also, Bernard: Does your below mention of "anonymous" NAI > indicate > > >> that there is actually a reserved NAI "anonymous"? If so, then I > > >> don't really see the use for a separate "sos" NAI -- you can just > > >> provide ECRIT access to "anonymous". > > >> > > >> --Richard > > >> > > >> > > >> > > >> On Mar 22, 2010, at 6:28 PM, Bernard Aboba wrote: > > >> > > >>> Part of the confusion here may be that we're talking about > > >>> "unauthenticated" at multiple layers. There is unauthenticated > > >>> network access, and then there is unauthenticated VOIP > signaling. > > >>> > > >>> These are two orthogonal things. The VOIP signaling should not > > >>> change regardless of whether the network access is authenticated > > >>> or unauthenticated. > > >>> > > >>> Similarly, it's possible to use authenticated or unauthenticated > > >>> VOIP signaling over authenticated or unauthenticated access. > > >>> > > >>> Focusing solely on how to obtain "unauthenticated" access, the > > >>> question is how the client signals that it is interested in > > >>> "unauthenticated" access. This is important, because otherwise > > >>> the server might request client authentication (e.g. a client > > >>> certificate request). Essentially the "sos" NAI is functioning > > >>> similar to the "anonymous" NAI in that this results in special > > >>> processing on the AAA server side. > > >>> > > >>> > > >>> > > >>> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of > > >>> serviceattacks on the emergency.com domain) > > >>> Date: Mon, 22 Mar 2010 18:14:59 -0700 > > >>> From: jsalowey@cisco.com > > >>> To: dirk.kroeselberg@nsn.com; hgs@cs.columbia.edu; bernard_aboba@hotmail.com > > >>> CC: ecrit@ietf.org > > >>> > > >>> I do not think EAP or NAI should be used as a signaling > mechanism > > >>> for emergency. These mechanisms are ways to obtain network > > >>> access when you cannot in some other way. Once you have network > > >>> access it seems that the emergency procedures should be the same > > >>> whether you authenticated to get network access or you gained > > >>> access though another mechanism. > > >>> > > >>> I am probably missing some ECRIT specific nuances here, but I > feel > > >>> that tying emergency procedures at higher layers to EAP usage > will > > >>> be fraught with problems. > > >>> > > >>> Joe > > >>> > > >>> > > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > >>> Behalf Of Kroeselberg, Dirk (NSN - DE/Munich) > > >>> Sent: Monday, March 22, 2010 5:26 PM > > >>> To: ext Henning Schulzrinne; Bernard Aboba > > >>> Cc: ecrit@ietf.org > > >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of > > >>> serviceattacks on the emergency.com domain) > > >>> > > >>> yes, fixing the NAI to a simple string is simple (this would > > >>> basically be a NAI that is username only, correct?). > > >>> > > >>> However, let me repeat my question from the other thread: How to > > >>> handle the 'authenticated' emergency case where the NAI carries > > >>> the regular username? The draft may be about unauthenticated, > but > > >>> just covering unauthenticated and leaving the authenticated case > > >>> open seems less useful to me. > > >>> > > >>> Dirk > > >>> > > >>> From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > >>> Sent: Tuesday, March 23, 2010 1:02 AM > > >>> To: Bernard Aboba > > >>> Cc: Kroeselberg, Dirk (NSN - DE/Munich); ecrit@ietf.org > > >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of > > >>> service attacks on the emergency.com domain) > > >>> > > >>> The "sos" name seems to be a reasonable approach that's simple > and > > >>> easy. > > >>> > > >>> Longer term, I think a better option is to have a semi- > > >>> authenticated mode: Imagine a setup where VSPs or other > trustable > > >>> bodies hand out tokens (e.g., using the OAuth-WARP work) that > the > > >>> ISP recognizes. The ISP is given the right to monitor the > usage of > > >>> 'sos' sessions and can hand the token to the appropriate > > >>> authorities for prosecution in case of abuse. That way, you get > > >>> emergency access, but make it unlikely that the system will be > > >>> abused on a large scale. In some countries, you might get such a > > >>> token from your local public authority when you're registering > > >>> your residence. > > >>> > > >>> Henning > > >>> > > >>> On Mar 22, 2010, at 7:50 PM, Bernard Aboba wrote: > > >>> > > >>> > > >>> If all you want to do is to gain emergency access to the local > > >>> network, you don't need to discover the domain. You can just use > > >>> an NAI of "sos". That will be more convenient in situations > > >>> where the local access mechanism (e.g. 802.1X) doesn't permit IP > > >>> packets (including DHCP) to pass prior to completing > > >>> authentication, so that "domain discovery" couldn't occur until > > >>> afterwards. > > >>> > > >>> > > >>> _______________________________________________ > > >>> Ecrit mailing list > > >>> Ecrit@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/ecrit > > >> > > >> > > From br@brianrosen.net Tue Mar 23 14:09:15 2010 Return-Path: <br@brianrosen.net> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED1113A684F; Tue, 23 Mar 2010 14:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.932 X-Spam-Level: *** X-Spam-Status: No, score=3.932 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 OKTFsiRrhosS; Tue, 23 Mar 2010 14:09:12 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id 4CF3C3A6946; Tue, 23 Mar 2010 14:09:02 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.129.39]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from <br@brianrosen.net>) id 1NuBLa-0002y1-79; Tue, 23 Mar 2010 16:09:10 -0500 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 23 Mar 2010 17:09:15 -0400 From: Brian Rosen <br@brianrosen.net> To: Richard Barnes <rbarnes@bbn.com>, Bernard Aboba <bernard_aboba@hotmail.com> Message-ID: <C7CEA63B.2AF5A%br@brianrosen.net> Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrKzRfOc6w4ZPWsrkimclW4dAPFuw== In-Reply-To: <969ADDD1-2BAF-42D6-BED9-DF3DB1EDBDAA@bbn.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 Cc: emu@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 21:09:15 -0000 In this discussion, please keep in mind what I've said many times, in other related discussions: A large percentage (in fact an overwhelming percentage) of PSAPs DON'T WANT unauthenticated access. Their position is that they have lots of relevant experience, and its all bad (tens of thousands of calls with no good ones in some cases). However, there are some PSAPs who want it, and there are some regulatory environments where there are some lawyers who think it's required to support it in some environments. So, perhaps we eventually need to do this, however: It should be completely disableable, and will be for a large number of cases It's not a high priority Brian On 3/23/10 11:58 AM, "Richard Barnes" <rbarnes@bbn.com> wrote: > Ah, ok, that makes sense. So maybe we just need an "unauthenticated" > token? Still don't see anything really emergency-specific in this, > besides specifying what constraints you might put on unauthenticated > users. > > --Richard > > > > On Mar 23, 2010, at 12:32 AM, Bernard Aboba wrote: > >> No, because the "anonymous" NAI is typically used in protocols (like >> EAP-TTLSv0, EAP-FAST or PEAP) where mutual authentication is >> required. So while the NAS or an eavesdropper can't determine the >> client identity, the AAA server can and does determine it (and in >> turn, proves its identity to the client). >> >> So at least in EAP, "anonymous" != "unauthenticated" >> >> >> >> >>> CC: jsalowey@cisco.com; dirk.kroeselberg@nsn.com; hgs@cs.columbia.edu >> ; ecrit@ietf.org; emu@ietf.org >>> From: rbarnes@bbn.com >>> To: bernard_aboba@hotmail.com >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of >> serviceattacks on the emergency.com domain) >>> Date: Mon, 22 Mar 2010 22:43:28 -0700 >>> >>> Doesn't it functionally amount to the same thing, though? Just the >>> client choosing not to authenticate vs not being able to >> authenticate? >>> --Richard >>> >>> >>> On Mar 22, 2010, at 10:29 PM, Bernard Aboba wrote: >>> >>>> Yes, there is an "anonymous" NAI, but the goal of that is to hide >>>> the identity from the NAS and eavesdroppers, not to enable client >>>> unauthenticated access. >>>> >>>> On Mar 22, 2010, at 10:23 PM, Richard Barnes <rbarnes@bbn.com> >> wrote: >>>> >>>>> In particular, providing unauthenticated *network* access is a >>>>> prerequisite for providing unauthenticated *VoIP* access. >>>>> >>>>> Also, Bernard: Does your below mention of "anonymous" NAI >> indicate >>>>> that there is actually a reserved NAI "anonymous"? If so, then I >>>>> don't really see the use for a separate "sos" NAI -- you can just >>>>> provide ECRIT access to "anonymous". >>>>> >>>>> --Richard >>>>> >>>>> >>>>> >>>>> On Mar 22, 2010, at 6:28 PM, Bernard Aboba wrote: >>>>> >>>>>> Part of the confusion here may be that we're talking about >>>>>> "unauthenticated" at multiple layers. There is unauthenticated >>>>>> network access, and then there is unauthenticated VOIP >> signaling. >>>>>> >>>>>> These are two orthogonal things. The VOIP signaling should not >>>>>> change regardless of whether the network access is authenticated >>>>>> or unauthenticated. >>>>>> >>>>>> Similarly, it's possible to use authenticated or unauthenticated >>>>>> VOIP signaling over authenticated or unauthenticated access. >>>>>> >>>>>> Focusing solely on how to obtain "unauthenticated" access, the >>>>>> question is how the client signals that it is interested in >>>>>> "unauthenticated" access. This is important, because otherwise >>>>>> the server might request client authentication (e.g. a client >>>>>> certificate request). Essentially the "sos" NAI is functioning >>>>>> similar to the "anonymous" NAI in that this results in special >>>>>> processing on the AAA server side. >>>>>> >>>>>> >>>>>> >>>>>> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of >>>>>> serviceattacks on the emergency.com domain) >>>>>> Date: Mon, 22 Mar 2010 18:14:59 -0700 >>>>>> From: jsalowey@cisco.com >>>>>> To: dirk.kroeselberg@nsn.com; hgs@cs.columbia.edu; >>>>>> bernard_aboba@hotmail.com >>>>>> CC: ecrit@ietf.org >>>>>> >>>>>> I do not think EAP or NAI should be used as a signaling >> mechanism >>>>>> for emergency. These mechanisms are ways to obtain network >>>>>> access when you cannot in some other way. Once you have network >>>>>> access it seems that the emergency procedures should be the same >>>>>> whether you authenticated to get network access or you gained >>>>>> access though another mechanism. >>>>>> >>>>>> I am probably missing some ECRIT specific nuances here, but I >> feel >>>>>> that tying emergency procedures at higher layers to EAP usage >> will >>>>>> be fraught with problems. >>>>>> >>>>>> Joe >>>>>> >>>>>> >>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>>>> Behalf Of Kroeselberg, Dirk (NSN - DE/Munich) >>>>>> Sent: Monday, March 22, 2010 5:26 PM >>>>>> To: ext Henning Schulzrinne; Bernard Aboba >>>>>> Cc: ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of >>>>>> serviceattacks on the emergency.com domain) >>>>>> >>>>>> yes, fixing the NAI to a simple string is simple (this would >>>>>> basically be a NAI that is username only, correct?). >>>>>> >>>>>> However, let me repeat my question from the other thread: How to >>>>>> handle the 'authenticated' emergency case where the NAI carries >>>>>> the regular username? The draft may be about unauthenticated, >> but >>>>>> just covering unauthenticated and leaving the authenticated case >>>>>> open seems less useful to me. >>>>>> >>>>>> Dirk >>>>>> >>>>>> From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>> Sent: Tuesday, March 23, 2010 1:02 AM >>>>>> To: Bernard Aboba >>>>>> Cc: Kroeselberg, Dirk (NSN - DE/Munich); ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of >>>>>> service attacks on the emergency.com domain) >>>>>> >>>>>> The "sos" name seems to be a reasonable approach that's simple >> and >>>>>> easy. >>>>>> >>>>>> Longer term, I think a better option is to have a semi- >>>>>> authenticated mode: Imagine a setup where VSPs or other >> trustable >>>>>> bodies hand out tokens (e.g., using the OAuth-WARP work) that >> the >>>>>> ISP recognizes. The ISP is given the right to monitor the >> usage of >>>>>> 'sos' sessions and can hand the token to the appropriate >>>>>> authorities for prosecution in case of abuse. That way, you get >>>>>> emergency access, but make it unlikely that the system will be >>>>>> abused on a large scale. In some countries, you might get such a >>>>>> token from your local public authority when you're registering >>>>>> your residence. >>>>>> >>>>>> Henning >>>>>> >>>>>> On Mar 22, 2010, at 7:50 PM, Bernard Aboba wrote: >>>>>> >>>>>> >>>>>> If all you want to do is to gain emergency access to the local >>>>>> network, you don't need to discover the domain. You can just use >>>>>> an NAI of "sos". That will be more convenient in situations >>>>>> where the local access mechanism (e.g. 802.1X) doesn't permit IP >>>>>> packets (including DHCP) to pass prior to completing >>>>>> authentication, so that "domain discovery" couldn't occur until >>>>>> afterwards. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> >>> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From Martin.Thomson@andrew.com Tue Mar 23 14:13:57 2010 Return-Path: <Martin.Thomson@andrew.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1246A3A6933; Tue, 23 Mar 2010 14:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 OhDFMu06+w4D; Tue, 23 Mar 2010 14:13:54 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 291893A6A5C; Tue, 23 Mar 2010 14:13:21 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:55920 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S198681Ab0CWVNg (ORCPT <rfc822;ecrit@ietf.org> + 1 other); Tue, 23 Mar 2010 16:13:36 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 23 Mar 2010 16:13:36 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 24 Mar 2010 05:13:33 +0800 From: "Thomson, Martin" <Martin.Thomson@andrew.com> To: Brian Rosen <br@brianrosen.net>, Richard Barnes <rbarnes@bbn.com>, Bernard Aboba <bernard_aboba@hotmail.com> Date: Wed, 24 Mar 2010 05:14:51 +0800 Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrKzRfOc6w4ZPWsrkimclW4dAPFuwAAHhnQ Message-ID: <8B0A9FCBB9832F43971E38010638454F03E24ED000@SISPE7MB1.commscope.com> References: <969ADDD1-2BAF-42D6-BED9-DF3DB1EDBDAA@bbn.com> <C7CEA63B.2AF5A%br@brianrosen.net> In-Reply-To: <C7CEA63B.2AF5A%br@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "emu@ietf.org" <emu@ietf.org>, "ecrit@ietf.org" <ecrit@ietf.org> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 21:13:57 -0000 PiBBIGxhcmdlIHBlcmNlbnRhZ2UgKGluIGZhY3QgYW4gb3ZlcndoZWxtaW5nIHBlcmNlbnRhZ2Up IG9mIFBTQVBzIERPTidUDQo+IFdBTlQNCj4gdW5hdXRoZW50aWNhdGVkIGFjY2Vzcy4gIFRoZWly IHBvc2l0aW9uIGlzIHRoYXQgdGhleSBoYXZlIGxvdHMgb2YNCj4gcmVsZXZhbnQNCj4gZXhwZXJp ZW5jZSwgYW5kIGl0cyBhbGwgYmFkICh0ZW5zIG9mIHRob3VzYW5kcyBvZiBjYWxscyB3aXRoIG5v IGdvb2QNCj4gb25lcyBpbg0KPiBzb21lIGNhc2VzKS4NCj4gDQo+IEhvd2V2ZXIsIHRoZXJlIGFy ZSBzb21lIFBTQVBzIHdobyB3YW50IGl0LCBhbmQgdGhlcmUgYXJlIHNvbWUNCj4gcmVndWxhdG9y eQ0KPiBlbnZpcm9ubWVudHMgd2hlcmUgdGhlcmUgYXJlIHNvbWUgbGF3eWVycyB3aG8gdGhpbmsg aXQncyByZXF1aXJlZCB0bw0KPiBzdXBwb3J0DQo+IGl0IGluIHNvbWUgZW52aXJvbm1lbnRzLg0K DQpUaGUgZ29vZCB0aGluZyBpczogd2UgZG9uJ3Qgc2V0IHBvbGljeSBoZXJlLiAgSSdtIG5vdCBz ZWVpbmcgc3VmZmljaWVudCBldmlkZW5jZSB0aGF0IF9ldmVyeW9uZV8gZG9lc24ndCB3YW50IHRo aXMsIG9ubHkgdGhhdCBzb21lIGRvbid0IHdhbnQgdGhpcy4NCg0KSSBjYW4ndCBjb21tZW50IG9u IHByaW9yaXR5LiAgVGhhdCB3b3VsZCBiZSBwb2xpY3kgdG9vLg0KDQotLU1hcnRpbg0K From br@brianrosen.net Tue Mar 23 14:29:05 2010 Return-Path: <br@brianrosen.net> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377B73A68C0; Tue, 23 Mar 2010 14:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.678 X-Spam-Level: *** X-Spam-Status: No, score=3.678 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 rFelovGNN1xN; Tue, 23 Mar 2010 14:29:03 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id C9E733A67F9; Tue, 23 Mar 2010 14:29:03 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.129.39]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from <br@brianrosen.net>) id 1NuBex-0005AX-Qm; Tue, 23 Mar 2010 16:29:12 -0500 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 23 Mar 2010 17:29:17 -0400 From: Brian Rosen <br@brianrosen.net> To: "Thomson, Martin" <Martin.Thomson@andrew.com>, Richard Barnes <rbarnes@bbn.com>, Bernard Aboba <bernard_aboba@hotmail.com> Message-ID: <C7CEAAED.2AF6F%br@brianrosen.net> Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrKzRfOc6w4ZPWsrkimclW4dAPFuwAAHhnQAACVA9c= In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E24ED000@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 Cc: "emu@ietf.org" <emu@ietf.org>, "ecrit@ietf.org" <ecrit@ietf.org> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 21:29:05 -0000 I think the relevant part of this is 'it's not a high priority'. That is policy of the work group, which we do have control over. If we have nothing else more important to do, then by all means, let's waste a ton of time on unauthenticated access. If we have other work to do, perhaps we could defer this. I am not the chair, but in general, anyone can discuss anything, regardless of "priority" on the list. However, when it comes to adopting work group items, I think this should be way down our list. I might also suggest that unauthenticated access really isn't within the charter of the work group. It may be that the reason unauthenticated access may be needed is for emergency calling, but that means we may (eventually) need to ask some other work group to do work for a requirement we generate. It would seem that dealing with EAP is not within the domain of this work group. Brian On 3/23/10 5:14 PM, "Thomson, Martin" <Martin.Thomson@andrew.com> wrote: >> A large percentage (in fact an overwhelming percentage) of PSAPs DON'T >> WANT >> unauthenticated access. Their position is that they have lots of >> relevant >> experience, and its all bad (tens of thousands of calls with no good >> ones in >> some cases). >> >> However, there are some PSAPs who want it, and there are some >> regulatory >> environments where there are some lawyers who think it's required to >> support >> it in some environments. > > The good thing is: we don't set policy here. I'm not seeing sufficient > evidence that _everyone_ doesn't want this, only that some don't want this. > > I can't comment on priority. That would be policy too. > > --Martin From dirk.kroeselberg@nsn.com Tue Mar 23 14:59:57 2010 Return-Path: <dirk.kroeselberg@nsn.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10C1B3A69BF; Tue, 23 Mar 2010 14:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 oyVVOZ9cdNDs; Tue, 23 Mar 2010 14:59:55 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 28D633A6923; Tue, 23 Mar 2010 14:59:53 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2NLxuZI025902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Mar 2010 22:59:56 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2NLxuqA031380; Tue, 23 Mar 2010 22:59:56 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 22:59:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Mar 2010 22:59:51 +0100 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF67025DB8FF@DEMUEXC030.nsn-intra.net> In-Reply-To: <C7CEAAED.2AF6F%br@brianrosen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrKzRfOc6w4ZPWsrkimclW4dAPFuwAAHhnQAACVA9cAADWmAA== References: <8B0A9FCBB9832F43971E38010638454F03E24ED000@SISPE7MB1.commscope.com> <C7CEAAED.2AF6F%br@brianrosen.net> From: "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com> To: "ext Brian Rosen" <br@brianrosen.net>, "Thomson, Martin" <Martin.Thomson@andrew.com>, "Richard Barnes" <rbarnes@bbn.com>, "Bernard Aboba" <bernard_aboba@hotmail.com> X-OriginalArrivalTime: 23 Mar 2010 21:59:56.0146 (UTC) FILETIME=[2C789D20:01CACAD4] Cc: emu@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 21:59:57 -0000 as spelled out by others already, we need to separate the aspects here. So the 'unauthenticated' draft intends to cover 1) the VSP/ASP related part 2) the access/ISP part.=20 3) unauthenticated access (no credentials) 4) unauthorized cases like empty prepaid account, roaming not allowed etc, where credentials are available but do not allow regular access. Considerations for 3) and 4) are different between the VSP/ASP and access/ISP cases. For the VSP/ASP part, we probably do not need to care a lot about 4), but for access/ISP this is different. And unfortunately regulatory requirements for 4) are pretty different from the unauthenticated case. Now, regarding EAP:=20 Up to now, IETF does not provide any recommendation for 3) and 4). This made different organizations come up with different incompatible ways to solve the problem. The idea behind adding the EAP considerations to our draft was to discuss whether IETF is able to recommend a common way. Any such recommendation needs to cover both 3) and 4) (not just unauthenticated). Dirk > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of ext Brian Rosen > Sent: Tuesday, March 23, 2010 10:29 PM > To: Thomson, Martin; Richard Barnes; Bernard Aboba > Cc: emu@ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial=20 > of serviceattacks on the emergency.com domain) >=20 > I think the relevant part of this is 'it's not a high=20 > priority'. That is > policy of the work group, which we do have control over. >=20 > If we have nothing else more important to do, then by all=20 > means, let's waste > a ton of time on unauthenticated access. If we have other work to do, > perhaps we could defer this. >=20 > I am not the chair, but in general, anyone can discuss=20 > anything, regardless > of "priority" on the list. However, when it comes to=20 > adopting work group > items, I think this should be way down our list. >=20 > I might also suggest that unauthenticated access really isn't=20 > within the > charter of the work group. It may be that the reason=20 > unauthenticated access > may be needed is for emergency calling, but that means we may=20 > (eventually) > need to ask some other work group to do work for a=20 > requirement we generate. > It would seem that dealing with EAP is not within the domain=20 > of this work > group. >=20 > Brian >=20 >=20 > On 3/23/10 5:14 PM, "Thomson, Martin"=20 > <Martin.Thomson@andrew.com> wrote: >=20 > >> A large percentage (in fact an overwhelming percentage) of=20 > PSAPs DON'T > >> WANT > >> unauthenticated access. Their position is that they have lots of > >> relevant > >> experience, and its all bad (tens of thousands of calls=20 > with no good > >> ones in > >> some cases). > >>=20 > >> However, there are some PSAPs who want it, and there are some > >> regulatory > >> environments where there are some lawyers who think it's=20 > required to > >> support > >> it in some environments. > >=20 > > The good thing is: we don't set policy here. I'm not=20 > seeing sufficient > > evidence that _everyone_ doesn't want this, only that some=20 > don't want this. > >=20 > > I can't comment on priority. That would be policy too. > >=20 > > --Martin >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From hgs@cs.columbia.edu Tue Mar 23 15:32:04 2010 Return-Path: <hgs@cs.columbia.edu> 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 239C23A6C5F; Tue, 23 Mar 2010 15:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[AWL=1.960, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 2mrFsm0BttZy; Tue, 23 Mar 2010 15:31:55 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 0C9D03A6BF4; Tue, 23 Mar 2010 15:31:54 -0700 (PDT) Received: from dhcp-wireless-open-abg-26-78.meeting.ietf.org (dhcp-wireless-open-abg-26-78.meeting.ietf.org [130.129.26.78]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o2NMW784013749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 23 Mar 2010 18:32:09 -0400 (EDT) References: <C7CEA63B.2AF5A%br@brianrosen.net> In-Reply-To: <C7CEA63B.2AF5A%br@brianrosen.net> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: <A10F80D2-B8E6-46A6-9C07-97EB6E6A7B68@cs.columbia.edu> Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne <hgs@cs.columbia.edu> Date: Tue, 23 Mar 2010 18:32:06 -0400 To: Brian Rosen <br@brianrosen.net> X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: emu@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 22:32:04 -0000 I think part of the confusion is that unauthenticated network access = does not mean unauthenticated caller. As I've been trying to point out = for a while, with apparently limited success, is that it would be quite = possible to have authenticated callers from unauthenticated network = access, i.e., callers whose (billing) address and other identifying = details would be known to the PSAP, or at least readily obtainable by = normal legal means. It may still be possible to get fake callers, if callers are willing to = use stolen credit cards to establish a relationship to the VSP, or who = use forged credentials with civic authorities, but that problem is = presumably similar for regular cell phones (where the attraction to do = that is larger, given the ability to get more useful services than just = talking to a 911 operator). To repeat myself: In that model, the 'sos' network access or some other = token-based model is used, depending on the risk tolerance of the local = wireless network provider (hotel, airport, Boingo, etc.). PAI or more = sophisticated models are then used to authenticate the caller to the = PSAP. I don't know how PSAPs can object to that, given that this model doesn't = exist today and has nothing to do with SIMless cell phones or whatever = "unauthenticated" calls (pay phones?) they get today. I see such access = as useful during time of cellular network stress (see 9/11, where cell = phone usage in NYC was severely impaired, but the Internet worked just = fine) and indoor usage (see Hilton Anaheim, where my cell phone ceases = to work in the terminal room). Henning On Mar 23, 2010, at 5:09 PM, Brian Rosen wrote: > In this discussion, please keep in mind what I've said many times, in = other > related discussions: >=20 > A large percentage (in fact an overwhelming percentage) of PSAPs DON'T = WANT > unauthenticated access. Their position is that they have lots of = relevant > experience, and its all bad (tens of thousands of calls with no good = ones in > some cases). >=20 > However, there are some PSAPs who want it, and there are some = regulatory > environments where there are some lawyers who think it's required to = support > it in some environments. >=20 > So, perhaps we eventually need to do this, however: >=20 > It should be completely disableable, and will be for a large number of = cases > It's not a high priority >=20 > Brian >=20 >=20 > On 3/23/10 11:58 AM, "Richard Barnes" <rbarnes@bbn.com> wrote: >=20 >> Ah, ok, that makes sense. So maybe we just need an "unauthenticated" >> token? Still don't see anything really emergency-specific in this, >> besides specifying what constraints you might put on unauthenticated >> users. >>=20 >> --Richard >>=20 >>=20 >>=20 >> On Mar 23, 2010, at 12:32 AM, Bernard Aboba wrote: >>=20 >>> No, because the "anonymous" NAI is typically used in protocols (like >>> EAP-TTLSv0, EAP-FAST or PEAP) where mutual authentication is >>> required. So while the NAS or an eavesdropper can't determine the >>> client identity, the AAA server can and does determine it (and in >>> turn, proves its identity to the client). >>>=20 >>> So at least in EAP, "anonymous" !=3D "unauthenticated" >>>=20 >>>=20 >>>=20 >>>=20 >>>> CC: jsalowey@cisco.com; dirk.kroeselberg@nsn.com; = hgs@cs.columbia.edu >>> ; ecrit@ietf.org; emu@ietf.org >>>> From: rbarnes@bbn.com >>>> To: bernard_aboba@hotmail.com >>>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of >>> serviceattacks on the emergency.com domain) >>>> Date: Mon, 22 Mar 2010 22:43:28 -0700 >>>>=20 >>>> Doesn't it functionally amount to the same thing, though? Just the >>>> client choosing not to authenticate vs not being able to >>> authenticate? >>>> --Richard >>>>=20 >>>>=20 >>>> On Mar 22, 2010, at 10:29 PM, Bernard Aboba wrote: >>>>=20 >>>>> Yes, there is an "anonymous" NAI, but the goal of that is to hide >>>>> the identity from the NAS and eavesdroppers, not to enable client >>>>> unauthenticated access. >>>>>=20 >>>>> On Mar 22, 2010, at 10:23 PM, Richard Barnes <rbarnes@bbn.com> >>> wrote: >>>>>=20 >>>>>> In particular, providing unauthenticated *network* access is a >>>>>> prerequisite for providing unauthenticated *VoIP* access. >>>>>>=20 >>>>>> Also, Bernard: Does your below mention of "anonymous" NAI >>> indicate >>>>>> that there is actually a reserved NAI "anonymous"? If so, then I >>>>>> don't really see the use for a separate "sos" NAI -- you can just >>>>>> provide ECRIT access to "anonymous". >>>>>>=20 >>>>>> --Richard >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Mar 22, 2010, at 6:28 PM, Bernard Aboba wrote: >>>>>>=20 >>>>>>> Part of the confusion here may be that we're talking about >>>>>>> "unauthenticated" at multiple layers. There is unauthenticated >>>>>>> network access, and then there is unauthenticated VOIP >>> signaling. >>>>>>>=20 >>>>>>> These are two orthogonal things. The VOIP signaling should not >>>>>>> change regardless of whether the network access is authenticated >>>>>>> or unauthenticated. >>>>>>>=20 >>>>>>> Similarly, it's possible to use authenticated or unauthenticated >>>>>>> VOIP signaling over authenticated or unauthenticated access. >>>>>>>=20 >>>>>>> Focusing solely on how to obtain "unauthenticated" access, the >>>>>>> question is how the client signals that it is interested in >>>>>>> "unauthenticated" access. This is important, because otherwise >>>>>>> the server might request client authentication (e.g. a client >>>>>>> certificate request). Essentially the "sos" NAI is functioning >>>>>>> similar to the "anonymous" NAI in that this results in special >>>>>>> processing on the AAA server side. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of >>>>>>> serviceattacks on the emergency.com domain) >>>>>>> Date: Mon, 22 Mar 2010 18:14:59 -0700 >>>>>>> From: jsalowey@cisco.com >>>>>>> To: dirk.kroeselberg@nsn.com; hgs@cs.columbia.edu; >>>>>>> bernard_aboba@hotmail.com >>>>>>> CC: ecrit@ietf.org >>>>>>>=20 >>>>>>> I do not think EAP or NAI should be used as a signaling >>> mechanism >>>>>>> for emergency. These mechanisms are ways to obtain network >>>>>>> access when you cannot in some other way. Once you have network >>>>>>> access it seems that the emergency procedures should be the same >>>>>>> whether you authenticated to get network access or you gained >>>>>>> access though another mechanism. >>>>>>>=20 >>>>>>> I am probably missing some ECRIT specific nuances here, but I >>> feel >>>>>>> that tying emergency procedures at higher layers to EAP usage >>> will >>>>>>> be fraught with problems. >>>>>>>=20 >>>>>>> Joe >>>>>>>=20 >>>>>>>=20 >>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>>>>> Behalf Of Kroeselberg, Dirk (NSN - DE/Munich) >>>>>>> Sent: Monday, March 22, 2010 5:26 PM >>>>>>> To: ext Henning Schulzrinne; Bernard Aboba >>>>>>> Cc: ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of >>>>>>> serviceattacks on the emergency.com domain) >>>>>>>=20 >>>>>>> yes, fixing the NAI to a simple string is simple (this would >>>>>>> basically be a NAI that is username only, correct?). >>>>>>>=20 >>>>>>> However, let me repeat my question from the other thread: How to >>>>>>> handle the 'authenticated' emergency case where the NAI carries >>>>>>> the regular username? The draft may be about unauthenticated, >>> but >>>>>>> just covering unauthenticated and leaving the authenticated case >>>>>>> open seems less useful to me. >>>>>>>=20 >>>>>>> Dirk >>>>>>>=20 >>>>>>> From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>>> Sent: Tuesday, March 23, 2010 1:02 AM >>>>>>> To: Bernard Aboba >>>>>>> Cc: Kroeselberg, Dirk (NSN - DE/Munich); ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of >>>>>>> service attacks on the emergency.com domain) >>>>>>>=20 >>>>>>> The "sos" name seems to be a reasonable approach that's simple >>> and >>>>>>> easy. >>>>>>>=20 >>>>>>> Longer term, I think a better option is to have a semi- >>>>>>> authenticated mode: Imagine a setup where VSPs or other >>> trustable >>>>>>> bodies hand out tokens (e.g., using the OAuth-WARP work) that >>> the >>>>>>> ISP recognizes. The ISP is given the right to monitor the >>> usage of >>>>>>> 'sos' sessions and can hand the token to the appropriate >>>>>>> authorities for prosecution in case of abuse. That way, you get >>>>>>> emergency access, but make it unlikely that the system will be >>>>>>> abused on a large scale. In some countries, you might get such a >>>>>>> token from your local public authority when you're registering >>>>>>> your residence. >>>>>>>=20 >>>>>>> Henning >>>>>>>=20 >>>>>>> On Mar 22, 2010, at 7:50 PM, Bernard Aboba wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> If all you want to do is to gain emergency access to the local >>>>>>> network, you don't need to discover the domain. You can just use >>>>>>> an NAI of "sos". That will be more convenient in situations >>>>>>> where the local access mechanism (e.g. 802.1X) doesn't permit IP >>>>>>> packets (including DHCP) to pass prior to completing >>>>>>> authentication, so that "domain discovery" couldn't occur until >>>>>>> afterwards. >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>=20 >>>>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From hgs@cs.columbia.edu Tue Mar 23 15:40:30 2010 Return-Path: <hgs@cs.columbia.edu> 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 B175C3A6946; Tue, 23 Mar 2010 15:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=2.307, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_55=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 jJJpZpVCcokL; Tue, 23 Mar 2010 15:40:29 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 249A83A67AE; Tue, 23 Mar 2010 15:40:29 -0700 (PDT) Received: from dhcp-wireless-open-abg-26-78.meeting.ietf.org (dhcp-wireless-open-abg-26-78.meeting.ietf.org [130.129.26.78]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o2NMefNv026445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 23 Mar 2010 18:40:42 -0400 (EDT) References: <4BA7800A.4040406@gmx.net><201003221619.o2MGJc2G006891@sj-core-2.cisco.com><8C51C7A529FC9D49843ACF5AE2FFBF67025DB128@DEMUEXC030.nsn-intra.net><BLU137-DS1318F3081E30928873CA2D93270@phx.gbl>, <62D89A2E-1066-4932-91CE-59A7798655E3@cs.columbia.edu><BLU137-W26F0443F14828D573CC84493270@phx.gbl><A8BCA059-789B-4A66-B2AE-69F72C816248@cs.columbia.edu> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB1AB@DEMUEXC030.nsn-intra.net>, <AC1CFD94F59A264488DC2BEC3E890DE509E6BFCB@xmb-sjc-225.amer.cisco.com> <BLU137-W370951B6C399E53F93420993260@phx.gbl> <93B8DBC9-FE13-4617-9ED2-5901E5BAF939@bbn.com> <BLU0-SMTP1377A7E38D5F6553186CC793260@phx.gbl>, <B9E6D716-3CC7-44FE-8A1D-08F366A42D20@bbn.com> <BLU137-W16A7478A99589D829B03D793260@phx.gbl> <969ADDD1-2BAF-42D6-BED9-DF3DB1EDBDAA@bbn.com> In-Reply-To: <969ADDD1-2BAF-42D6-BED9-DF3DB1EDBDAA@bbn.com> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: <B4244DAA-CB71-419F-9CDD-E3ADE9EC4FEE@cs.columbia.edu> Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne <hgs@cs.columbia.edu> Date: Tue, 23 Mar 2010 18:40:40 -0400 To: Richard Barnes <rbarnes@bbn.com> X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: emu@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 22:40:30 -0000 You may find a recent article in CACM of interest. It argued, if I = recall correctly, that the old role-based model of access control is = actually not all that useful in many scenarios. The authors argued that, = in many cases, a better model is to allow&audit, i.e., let people access = information or resources and then deal with miscreants. This clearly = doesn't work all the time, but in cases where the losses are bounded, = this seems like a much more robust and simple-to-implement model. In = this case, the ISP's potential losses are relatively minor (a bit of = theoretical revenue loss); with the authentication token I mentioned, = they can decide to go after the non-trivial abusers. Henning On Mar 23, 2010, at 11:58 AM, Richard Barnes wrote: > Ah, ok, that makes sense. So maybe we just need an "unauthenticated" = token? Still don't see anything really emergency-specific in this, = besides specifying what constraints you might put on unauthenticated = users. >=20 > --Richard >=20 >=20 >=20 > On Mar 23, 2010, at 12:32 AM, Bernard Aboba wrote: >=20 >> No, because the "anonymous" NAI is typically used in protocols (like = EAP-TTLSv0, EAP-FAST or PEAP) where mutual authentication is required. = So while the NAS or an eavesdropper can't determine the client identity, = the AAA server can and does determine it (and in turn, proves its = identity to the client). >>=20 >> So at least in EAP, "anonymous" !=3D "unauthenticated" >>=20 >>=20 >>=20 >>=20 >> > CC: jsalowey@cisco.com; dirk.kroeselberg@nsn.com; = hgs@cs.columbia.edu; ecrit@ietf.org; emu@ietf.org >> > From: rbarnes@bbn.com >> > To: bernard_aboba@hotmail.com >> > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of = serviceattacks on the emergency.com domain) >> > Date: Mon, 22 Mar 2010 22:43:28 -0700 >> > >> > Doesn't it functionally amount to the same thing, though? Just the >> > client choosing not to authenticate vs not being able to = authenticate? >> > --Richard >> > >> > >> > On Mar 22, 2010, at 10:29 PM, Bernard Aboba wrote: >> > >> > > Yes, there is an "anonymous" NAI, but the goal of that is to hide >> > > the identity from the NAS and eavesdroppers, not to enable client >> > > unauthenticated access. >> > > >> > > On Mar 22, 2010, at 10:23 PM, Richard Barnes <rbarnes@bbn.com> = wrote: >> > > >> > >> In particular, providing unauthenticated *network* access is a >> > >> prerequisite for providing unauthenticated *VoIP* access. >> > >> >> > >> Also, Bernard: Does your below mention of "anonymous" NAI = indicate >> > >> that there is actually a reserved NAI "anonymous"? If so, then I >> > >> don't really see the use for a separate "sos" NAI -- you can = just >> > >> provide ECRIT access to "anonymous". >> > >> >> > >> --Richard >> > >> >> > >> >> > >> >> > >> On Mar 22, 2010, at 6:28 PM, Bernard Aboba wrote: >> > >> >> > >>> Part of the confusion here may be that we're talking about >> > >>> "unauthenticated" at multiple layers. There is unauthenticated >> > >>> network access, and then there is unauthenticated VOIP = signaling. >> > >>> >> > >>> These are two orthogonal things. The VOIP signaling should not >> > >>> change regardless of whether the network access is = authenticated >> > >>> or unauthenticated. >> > >>> >> > >>> Similarly, it's possible to use authenticated or = unauthenticated >> > >>> VOIP signaling over authenticated or unauthenticated access. >> > >>> >> > >>> Focusing solely on how to obtain "unauthenticated" access, the >> > >>> question is how the client signals that it is interested in >> > >>> "unauthenticated" access. This is important, because otherwise >> > >>> the server might request client authentication (e.g. a client >> > >>> certificate request). Essentially the "sos" NAI is functioning >> > >>> similar to the "anonymous" NAI in that this results in special >> > >>> processing on the AAA server side. >> > >>> >> > >>> >> > >>> >> > >>> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial = of >> > >>> serviceattacks on the emergency.com domain) >> > >>> Date: Mon, 22 Mar 2010 18:14:59 -0700 >> > >>> From: jsalowey@cisco.com >> > >>> To: dirk.kroeselberg@nsn.com; hgs@cs.columbia.edu; = bernard_aboba@hotmail.com >> > >>> CC: ecrit@ietf.org >> > >>> >> > >>> I do not think EAP or NAI should be used as a signaling = mechanism >> > >>> for emergency. These mechanisms are ways to obtain network >> > >>> access when you cannot in some other way. Once you have network >> > >>> access it seems that the emergency procedures should be the = same >> > >>> whether you authenticated to get network access or you gained >> > >>> access though another mechanism. >> > >>> >> > >>> I am probably missing some ECRIT specific nuances here, but I = feel >> > >>> that tying emergency procedures at higher layers to EAP usage = will >> > >>> be fraught with problems. >> > >>> >> > >>> Joe >> > >>> >> > >>> >> > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> > >>> Behalf Of Kroeselberg, Dirk (NSN - DE/Munich) >> > >>> Sent: Monday, March 22, 2010 5:26 PM >> > >>> To: ext Henning Schulzrinne; Bernard Aboba >> > >>> Cc: ecrit@ietf.org >> > >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial = of >> > >>> serviceattacks on the emergency.com domain) >> > >>> >> > >>> yes, fixing the NAI to a simple string is simple (this would >> > >>> basically be a NAI that is username only, correct?). >> > >>> >> > >>> However, let me repeat my question from the other thread: How = to >> > >>> handle the 'authenticated' emergency case where the NAI carries >> > >>> the regular username? The draft may be about unauthenticated, = but >> > >>> just covering unauthenticated and leaving the authenticated = case >> > >>> open seems less useful to me. >> > >>> >> > >>> Dirk >> > >>> >> > >>> From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> > >>> Sent: Tuesday, March 23, 2010 1:02 AM >> > >>> To: Bernard Aboba >> > >>> Cc: Kroeselberg, Dirk (NSN - DE/Munich); ecrit@ietf.org >> > >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial = of >> > >>> service attacks on the emergency.com domain) >> > >>> >> > >>> The "sos" name seems to be a reasonable approach that's simple = and >> > >>> easy. >> > >>> >> > >>> Longer term, I think a better option is to have a semi- >> > >>> authenticated mode: Imagine a setup where VSPs or other = trustable >> > >>> bodies hand out tokens (e.g., using the OAuth-WARP work) that = the >> > >>> ISP recognizes. The ISP is given the right to monitor the usage = of >> > >>> 'sos' sessions and can hand the token to the appropriate >> > >>> authorities for prosecution in case of abuse. That way, you get >> > >>> emergency access, but make it unlikely that the system will be >> > >>> abused on a large scale. In some countries, you might get such = a >> > >>> token from your local public authority when you're registering >> > >>> your residence. >> > >>> >> > >>> Henning >> > >>> >> > >>> On Mar 22, 2010, at 7:50 PM, Bernard Aboba wrote: >> > >>> >> > >>> >> > >>> If all you want to do is to gain emergency access to the local >> > >>> network, you don't need to discover the domain. You can just = use >> > >>> an NAI of "sos". That will be more convenient in situations >> > >>> where the local access mechanism (e.g. 802.1X) doesn't permit = IP >> > >>> packets (including DHCP) to pass prior to completing >> > >>> authentication, so that "domain discovery" couldn't occur until >> > >>> afterwards. >> > >>> >> > >>> >> > >>> _______________________________________________ >> > >>> Ecrit mailing list >> > >>> Ecrit@ietf.org >> > >>> https://www.ietf.org/mailman/listinfo/ecrit >> > >> >> > >> >> > >=20 >=20 From Martin.Dawson@andrew.com Tue Mar 23 15:43:42 2010 Return-Path: <Martin.Dawson@andrew.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 852D53A69EF; Tue, 23 Mar 2010 15:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.781 X-Spam-Level: * X-Spam-Status: No, score=1.781 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 RgDOIQEjG-vO; Tue, 23 Mar 2010 15:43:40 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id D12113A68C0; Tue, 23 Mar 2010 15:43:40 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:12436 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S15372600Ab0CWWoA convert rfc822-to-8bit (ORCPT <rfc822;ecrit@ietf.org> + 1 other); Tue, 23 Mar 2010 17:44:00 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 23 Mar 2010 17:44:00 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 24 Mar 2010 06:43:57 +0800 From: "Dawson, Martin" <Martin.Dawson@andrew.com> To: Brian Rosen <br@brianrosen.net>, "Thomson, Martin" <Martin.Thomson@andrew.com>, Richard Barnes <rbarnes@bbn.com>, Bernard Aboba <bernard_aboba@hotmail.com> Date: Wed, 24 Mar 2010 06:43:55 +0800 Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrKzRfOc6w4ZPWsrkimclW4dAPFuwAAHhnQAACVA9cAAQknQA== Message-ID: <8B0A9FCBB9832F43971E38010638454F03E24ED009@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03E24ED000@SISPE7MB1.commscope.com> <C7CEAAED.2AF6F%br@brianrosen.net> In-Reply-To: <C7CEAAED.2AF6F%br@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Cc: "emu@ietf.org" <emu@ietf.org>, "ecrit@ietf.org" <ecrit@ietf.org> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 22:43:42 -0000 To elaborate on Brian's "counter point" - some jurisdictions may prefer to *forbid* access to the emergency service from unauthenticated/anonymous access as opposed to *require* it to be supported. Noting this is the equivalent of saying emergency calls for circuit service cannot be made from public phone booths; this is still a possible policy within a given jurisdiction. I'd also posit that not only is it not a priority for IETF but that the question actually needs to be dealt with in more specific forums first. The ECRIT emergency procedures occur at or above the IP layer. Before anything that ECRIT describes becomes relevant, there needs to be an IP context. So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, the DSL forum, etc. as to how a device is able to get an unauthenticated IP context on their technology, for whatever purpose, before the policies on permitting/prohibiting ECRIT procedures or anything else that can be done on IP can be applied. This is easier on some access technologies than it is on others. I doubt that there's a reasonable assumption that the connecting device can necessarily provide an explicit "emergency intent" flag. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, 24 March 2010 8:29 AM To: Thomson, Martin; Richard Barnes; Bernard Aboba Cc: emu@ietf.org; ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) I think the relevant part of this is 'it's not a high priority'. That is policy of the work group, which we do have control over. If we have nothing else more important to do, then by all means, let's waste a ton of time on unauthenticated access. If we have other work to do, perhaps we could defer this. I am not the chair, but in general, anyone can discuss anything, regardless of "priority" on the list. However, when it comes to adopting work group items, I think this should be way down our list. I might also suggest that unauthenticated access really isn't within the charter of the work group. It may be that the reason unauthenticated access may be needed is for emergency calling, but that means we may (eventually) need to ask some other work group to do work for a requirement we generate. It would seem that dealing with EAP is not within the domain of this work group. Brian On 3/23/10 5:14 PM, "Thomson, Martin" <Martin.Thomson@andrew.com> wrote: >> A large percentage (in fact an overwhelming percentage) of PSAPs DON'T >> WANT >> unauthenticated access. Their position is that they have lots of >> relevant >> experience, and its all bad (tens of thousands of calls with no good >> ones in >> some cases). >> >> However, there are some PSAPs who want it, and there are some >> regulatory >> environments where there are some lawyers who think it's required to >> support >> it in some environments. > > The good thing is: we don't set policy here. I'm not seeing sufficient > evidence that _everyone_ doesn't want this, only that some don't want this. > > I can't comment on priority. That would be policy too. > > --Martin _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From dirk.kroeselberg@nsn.com Tue Mar 23 16:14:11 2010 Return-Path: <dirk.kroeselberg@nsn.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FAAB3A6B99; Tue, 23 Mar 2010 16:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 R-zIv3cmSFpn; Tue, 23 Mar 2010 16:14:10 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id CEF403A6D02; Tue, 23 Mar 2010 16:14:08 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2NNEChr005762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Mar 2010 00:14:13 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2NNEBZS010932; Wed, 24 Mar 2010 00:14:11 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Mar 2010 00:14:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Mar 2010 00:14:08 +0100 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF67025DB904@DEMUEXC030.nsn-intra.net> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E24ED009@SISPE7MB1.commscope.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrKzRfOc6w4ZPWsrkimclW4dAPFuwAAHhnQAACVA9cAAQknQAACQEEA References: <8B0A9FCBB9832F43971E38010638454F03E24ED000@SISPE7MB1.commscope.com><C7CEAAED.2AF6F%br@brianrosen.net> <8B0A9FCBB9832F43971E38010638454F03E24ED009@SISPE7MB1.commscope.com> From: "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com> To: "ext Dawson, Martin" <Martin.Dawson@andrew.com>, "Brian Rosen" <br@brianrosen.net>, "Thomson, Martin" <Martin.Thomson@andrew.com>, "Richard Barnes" <rbarnes@bbn.com>, "Bernard Aboba" <bernard_aboba@hotmail.com> X-OriginalArrivalTime: 23 Mar 2010 23:14:11.0700 (UTC) FILETIME=[8C303340:01CACADE] Cc: emu@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 23:14:11 -0000 > So - it's more the domain of the IEEE, 3GPP, WiFi Alliance,=20 > the DSL forum, etc. as to how a device is able to get an=20 > unauthenticated IP context on their technology, for whatever=20 > purpose, before the policies on permitting/prohibiting ECRIT =20 but what is the concrete recommendation that you want to give here? - Drop the access/ISP part from the draft and say access/ISP is out-of-scope? - move this to EMU? - or deal with the EAP/NAI related aspects outside IETF as you seem to suggest (which is already partially the case today due to lack of guidance)? > is on others. I doubt that there's a reasonable assumption=20 > that the connecting device can necessarily provide an=20 > explicit "emergency intent" flag. maybe this is why some people do this via the NAI ;-) Dirk > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of ext Dawson, Martin > Sent: Tuesday, March 23, 2010 11:44 PM > To: Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba > Cc: emu@ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial=20 > of serviceattacks on the emergency.com domain) >=20 > To elaborate on Brian's "counter point" - some jurisdictions=20 > may prefer to *forbid* access to the emergency service from=20 > unauthenticated/anonymous access as opposed to *require* it=20 > to be supported. Noting this is the equivalent of saying=20 > emergency calls for circuit service cannot be made from=20 > public phone booths; this is still a possible policy within a=20 > given jurisdiction. >=20 > I'd also posit that not only is it not a priority for IETF=20 > but that the question actually needs to be dealt with in more=20 > specific forums first. The ECRIT emergency procedures occur=20 > at or above the IP layer. Before anything that ECRIT=20 > describes becomes relevant, there needs to be an IP context. >=20 > So - it's more the domain of the IEEE, 3GPP, WiFi Alliance,=20 > the DSL forum, etc. as to how a device is able to get an=20 > unauthenticated IP context on their technology, for whatever=20 > purpose, before the policies on permitting/prohibiting ECRIT=20 > procedures or anything else that can be done on IP can be=20 > applied. This is easier on some access technologies than it=20 > is on others. I doubt that there's a reasonable assumption=20 > that the connecting device can necessarily provide an=20 > explicit "emergency intent" flag. >=20 > Cheers, > Martin >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Brian Rosen > Sent: Wednesday, 24 March 2010 8:29 AM > To: Thomson, Martin; Richard Barnes; Bernard Aboba > Cc: emu@ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial=20 > of serviceattacks on the emergency.com domain) >=20 > I think the relevant part of this is 'it's not a high=20 > priority'. That is > policy of the work group, which we do have control over. >=20 > If we have nothing else more important to do, then by all=20 > means, let's waste > a ton of time on unauthenticated access. If we have other work to do, > perhaps we could defer this. >=20 > I am not the chair, but in general, anyone can discuss=20 > anything, regardless > of "priority" on the list. However, when it comes to=20 > adopting work group > items, I think this should be way down our list. >=20 > I might also suggest that unauthenticated access really isn't=20 > within the > charter of the work group. It may be that the reason=20 > unauthenticated access > may be needed is for emergency calling, but that means we may=20 > (eventually) > need to ask some other work group to do work for a=20 > requirement we generate. > It would seem that dealing with EAP is not within the domain=20 > of this work > group. >=20 > Brian >=20 >=20 > On 3/23/10 5:14 PM, "Thomson, Martin"=20 > <Martin.Thomson@andrew.com> wrote: >=20 > >> A large percentage (in fact an overwhelming percentage) of=20 > PSAPs DON'T > >> WANT > >> unauthenticated access. Their position is that they have lots of > >> relevant > >> experience, and its all bad (tens of thousands of calls=20 > with no good > >> ones in > >> some cases). > >>=20 > >> However, there are some PSAPs who want it, and there are some > >> regulatory > >> environments where there are some lawyers who think it's=20 > required to > >> support > >> it in some environments. > >=20 > > The good thing is: we don't set policy here. I'm not=20 > seeing sufficient > > evidence that _everyone_ doesn't want this, only that some=20 > don't want this. > >=20 > > I can't comment on priority. That would be policy too. > >=20 > > --Martin >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From bernard_aboba@hotmail.com Tue Mar 23 16:19:49 2010 Return-Path: <bernard_aboba@hotmail.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B727A3A68E5; Tue, 23 Mar 2010 16:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 wvohW0nPY6DZ; Tue, 23 Mar 2010 16:19:47 -0700 (PDT) Received: from blu0-omc2-s14.blu0.hotmail.com (blu0-omc2-s14.blu0.hotmail.com [65.55.111.89]) by core3.amsl.com (Postfix) with ESMTP id 302683A68AF; Tue, 23 Mar 2010 16:19:41 -0700 (PDT) Received: from BLU137-W10 ([65.55.111.71]) by blu0-omc2-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 16:20:00 -0700 Message-ID: <BLU137-W100D7CA35730693EA66D4C93260@phx.gbl> Content-Type: multipart/alternative; boundary="_dec41396-c5aa-41ed-96c6-47b20c8260f7_" X-Originating-IP: [130.129.27.170] From: Bernard Aboba <bernard_aboba@hotmail.com> To: <br@brianrosen.net>, <rbarnes@bbn.com> Date: Tue, 23 Mar 2010 16:19:59 -0700 Importance: Normal In-Reply-To: <C7CEA63B.2AF5A%br@brianrosen.net> References: <969ADDD1-2BAF-42D6-BED9-DF3DB1EDBDAA@bbn.com>, <C7CEA63B.2AF5A%br@brianrosen.net> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Mar 2010 23:20:00.0259 (UTC) FILETIME=[5BF21530:01CACADF] Cc: emu@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 23:19:49 -0000 --_dec41396-c5aa-41ed-96c6-47b20c8260f7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At least with the approach we've been talking about (e.g. "sos" NAI)=2C exp= licit configuration and server-side work (e.g. server-only auth support) is= going to be required to turn on "unauthenticated access". So I don't thi= nk you have to worry about it being "turned on by default"=2C given that fe= w if any hosts or AAA servers support this today.=20 About priority. Enterprise customers tend to be dragged into E-9-1-1 deplo= yments kicking and screaming to begin with=2C and (at least in the US)=2C t= here is currently no federal requirement for MLTS support for E-9-1-1=2C o= nly state laws. At various points=2C I've heard claims that this might be = a legal requirement somewhere for anonymous access. If that is true or mig= ht be true=2C it would be nice to have a pointer to a regulation or statute= . It's definitely not referenced in any U.S. 9-1-1 legislation or regulato= ry proceeding=2C or even in the recently introduced National Broadband plan= or legislative proposals (HR 4829). =20 > Date: Tue=2C 23 Mar 2010 17:09:15 -0400 > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of servicea= ttacks on the emergency.com domain) > From: br@brianrosen.net > To: rbarnes@bbn.com=3B bernard_aboba@hotmail.com > CC: emu@ietf.org=3B ecrit@ietf.org >=20 > In this discussion=2C please keep in mind what I've said many times=2C in= other > related discussions: >=20 > A large percentage (in fact an overwhelming percentage) of PSAPs DON'T WA= NT > unauthenticated access. Their position is that they have lots of relevan= t > experience=2C and its all bad (tens of thousands of calls with no good on= es in > some cases). >=20 > However=2C there are some PSAPs who want it=2C and there are some regulat= ory > environments where there are some lawyers who think it's required to supp= ort > it in some environments. >=20 > So=2C perhaps we eventually need to do this=2C however: >=20 > It should be completely disablable=2C and will be for a large number of c= ases > It's not a high priority >=20 > Brian >=20 >=20 > On 3/23/10 11:58 AM=2C "Richard Barnes" <rbarnes@bbn.com> wrote: >=20 > > Ah=2C ok=2C that makes sense. So maybe we just need an "unauthenticate= d" > > token? Still don't see anything really emergency-specific in this=2C > > besides specifying what constraints you might put on unauthenticated > > users. > >=20 > > --Richard > >=20 > >=20 > >=20 > > On Mar 23=2C 2010=2C at 12:32 AM=2C Bernard Aboba wrote: > >=20 > >> No=2C because the "anonymous" NAI is typically used in protocols (like > >> EAP-TTLSv0=2C EAP-FAST or PEAP) where mutual authentication is > >> required. So while the NAS or an eavesdropper can't determine the > >> client identity=2C the AAA server can and does determine it (and in > >> turn=2C proves its identity to the client). > >>=20 > >> So at least in EAP=2C "anonymous" !=3D "unauthenticated" > >>=20 > >>=20 > >>=20 > >>=20 > >>> CC: jsalowey@cisco.com=3B dirk.kroeselberg@nsn.com=3B hgs@cs.columbia= .edu > >> =3B ecrit@ietf.org=3B emu@ietf.org > >>> From: rbarnes@bbn.com > >>> To: bernard_aboba@hotmail.com > >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of > >> serviceattacks on the emergency.com domain) > >>> Date: Mon=2C 22 Mar 2010 22:43:28 -0700 > >>>=20 > >>> Doesn't it functionally amount to the same thing=2C though? Just the > >>> client choosing not to authenticate vs not being able to > >> authenticate? > >>> --Richard > >>>=20 > >>>=20 > >>> On Mar 22=2C 2010=2C at 10:29 PM=2C Bernard Aboba wrote: > >>>=20 > >>>> Yes=2C there is an "anonymous" NAI=2C but the goal of that is to hid= e > >>>> the identity from the NAS and eavesdroppers=2C not to enable client > >>>> unauthenticated access. > >>>>=20 > >>>> On Mar 22=2C 2010=2C at 10:23 PM=2C Richard Barnes <rbarnes@bbn.com> > >> wrote: > >>>>=20 > >>>>> In particular=2C providing unauthenticated *network* access is a > >>>>> prerequisite for providing unauthenticated *VoIP* access. > >>>>>=20 > >>>>> Also=2C Bernard: Does your below mention of "anonymous" NAI > >> indicate > >>>>> that there is actually a reserved NAI "anonymous"? If so=2C then I > >>>>> don't really see the use for a separate "sos" NAI -- you can just > >>>>> provide ECRIT access to "anonymous". > >>>>>=20 > >>>>> --Richard > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>> On Mar 22=2C 2010=2C at 6:28 PM=2C Bernard Aboba wrote: > >>>>>=20 > >>>>>> Part of the confusion here may be that we're talking about > >>>>>> "unauthenticated" at multiple layers. There is unauthenticated > >>>>>> network access=2C and then there is unauthenticated VOIP > >> signaling. > >>>>>>=20 > >>>>>> These are two orthogonal things. The VOIP signaling should not > >>>>>> change regardless of whether the network access is authenticated > >>>>>> or unauthenticated. > >>>>>>=20 > >>>>>> Similarly=2C it's possible to use authenticated or unauthenticated > >>>>>> VOIP signaling over authenticated or unauthenticated access. > >>>>>>=20 > >>>>>> Focusing solely on how to obtain "unauthenticated" access=2C the > >>>>>> question is how the client signals that it is interested in > >>>>>> "unauthenticated" access. This is important=2C because otherwise > >>>>>> the server might request client authentication (e.g. a client > >>>>>> certificate request). Essentially the "sos" NAI is functioning > >>>>>> similar to the "anonymous" NAI in that this results in special > >>>>>> processing on the AAA server side. > >>>>>>=20 > >>>>>>=20 > >>>>>>=20 > >>>>>> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of > >>>>>> serviceattacks on the emergency.com domain) > >>>>>> Date: Mon=2C 22 Mar 2010 18:14:59 -0700 > >>>>>> From: jsalowey@cisco.com > >>>>>> To: dirk.kroeselberg@nsn.com=3B hgs@cs.columbia.edu=3B > >>>>>> bernard_aboba@hotmail.com > >>>>>> CC: ecrit@ietf.org > >>>>>>=20 > >>>>>> I do not think EAP or NAI should be used as a signaling > >> mechanism > >>>>>> for emergency. These mechanisms are ways to obtain network > >>>>>> access when you cannot in some other way. Once you have network > >>>>>> access it seems that the emergency procedures should be the same > >>>>>> whether you authenticated to get network access or you gained > >>>>>> access though another mechanism. > >>>>>>=20 > >>>>>> I am probably missing some ECRIT specific nuances here=2C but I > >> feel > >>>>>> that tying emergency procedures at higher layers to EAP usage > >> will > >>>>>> be fraught with problems. > >>>>>>=20 > >>>>>> Joe > >>>>>>=20 > >>>>>>=20 > >>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>>>>> Behalf Of Kroeselberg=2C Dirk (NSN - DE/Munich) > >>>>>> Sent: Monday=2C March 22=2C 2010 5:26 PM > >>>>>> To: ext Henning Schulzrinne=3B Bernard Aboba > >>>>>> Cc: ecrit@ietf.org > >>>>>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of > >>>>>> serviceattacks on the emergency.com domain) > >>>>>>=20 > >>>>>> yes=2C fixing the NAI to a simple string is simple (this would > >>>>>> basically be a NAI that is username only=2C correct?). > >>>>>>=20 > >>>>>> However=2C let me repeat my question from the other thread: How to > >>>>>> handle the 'authenticated' emergency case where the NAI carries > >>>>>> the regular username? The draft may be about unauthenticated=2C > >> but > >>>>>> just covering unauthenticated and leaving the authenticated case > >>>>>> open seems less useful to me. > >>>>>>=20 > >>>>>> Dirk > >>>>>>=20 > >>>>>> From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>>>>> Sent: Tuesday=2C March 23=2C 2010 1:02 AM > >>>>>> To: Bernard Aboba > >>>>>> Cc: Kroeselberg=2C Dirk (NSN - DE/Munich)=3B ecrit@ietf.org > >>>>>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of > >>>>>> service attacks on the emergency.com domain) > >>>>>>=20 > >>>>>> The "sos" name seems to be a reasonable approach that's simple > >> and > >>>>>> easy. > >>>>>>=20 > >>>>>> Longer term=2C I think a better option is to have a semi- > >>>>>> authenticated mode: Imagine a setup where VSPs or other > >> trustable > >>>>>> bodies hand out tokens (e.g.=2C using the OAuth-WARP work) that > >> the > >>>>>> ISP recognizes. The ISP is given the right to monitor the > >> usage of > >>>>>> 'sos' sessions and can hand the token to the appropriate > >>>>>> authorities for prosecution in case of abuse. That way=2C you get > >>>>>> emergency access=2C but make it unlikely that the system will be > >>>>>> abused on a large scale. In some countries=2C you might get such a > >>>>>> token from your local public authority when you're registering > >>>>>> your residence. > >>>>>>=20 > >>>>>> Henning > >>>>>>=20 > >>>>>> On Mar 22=2C 2010=2C at 7:50 PM=2C Bernard Aboba wrote: > >>>>>>=20 > >>>>>>=20 > >>>>>> If all you want to do is to gain emergency access to the local > >>>>>> network=2C you don't need to discover the domain. You can just use > >>>>>> an NAI of "sos". That will be more convenient in situations > >>>>>> where the local access mechanism (e.g. 802.1X) doesn't permit IP > >>>>>> packets (including DHCP) to pass prior to completing > >>>>>> authentication=2C so that "domain discovery" couldn't occur until > >>>>>> afterwards. > >>>>>>=20 > >>>>>>=20 > >>>>>> _______________________________________________ > >>>>>> Ecrit mailing list > >>>>>> Ecrit@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>>>=20 > >>>>>=20 > >>>=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 = --_dec41396-c5aa-41ed-96c6-47b20c8260f7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style><!-- .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } --></style> </head> <body class=3D'hmmessage'> At least with the approach we've been talking about (e.g. "sos" NAI)=2C exp= licit configuration and server-side work (e.g. server-only auth support) is= going to be required to turn on "unauthenticated access". =3B =3B = So I don't think you have to worry about it being "turned on by default"=2C= given that few if any hosts or AAA servers support this today. <br><br>Abo= ut priority. =3B Enterprise customers tend to be dragged into E-9-1-1 d= eployments kicking and screaming to begin with=2C and (at least in the US)= =2C there is =3B currently no federal requirement for MLTS support for = E-9-1-1=2C only state laws. =3B At various points=2C I've heard claims = that this might be a legal requirement somewhere for anonymous access. = =3B If that is true or might be true=2C it would be nice to have a pointer = to a regulation or statute. =3B It's definitely not referenced in any U= .S. 9-1-1 legislation or regulatory proceeding=2C or even in the recently i= ntroduced National Broadband plan or legislative proposals (HR 4829). = =3B <br><br>>=3B Date: Tue=2C 23 Mar 2010 17:09:15 -0400<br>>=3B Subjec= t: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks o= n the emergency.com domain)<br>>=3B From: br@brianrosen.net<br>>=3B To:= rbarnes@bbn.com=3B bernard_aboba@hotmail.com<br>>=3B CC: emu@ietf.org=3B= ecrit@ietf.org<br>>=3B <br>>=3B In this discussion=2C please keep in m= ind what I've said many times=2C in other<br>>=3B related discussions:<br= >>=3B <br>>=3B A large percentage (in fact an overwhelming percentage) = of PSAPs DON'T WANT<br>>=3B unauthenticated access. Their position is th= at they have lots of relevant<br>>=3B experience=2C and its all bad (tens= of thousands of calls with no good ones in<br>>=3B some cases).<br>>= =3B <br>>=3B However=2C there are some PSAPs who want it=2C and there are= some regulatory<br>>=3B environments where there are some lawyers who th= ink it's required to support<br>>=3B it in some environments.<br>>=3B <= br>>=3B So=2C perhaps we eventually need to do this=2C however:<br>>=3B= <br>>=3B It should be completely disablable=2C and will be for a large n= umber of cases<br>>=3B It's not a high priority<br>>=3B <br>>=3B Bria= n<br>>=3B <br>>=3B <br>>=3B On 3/23/10 11:58 AM=2C "Richard Barnes" &= lt=3Brbarnes@bbn.com>=3B wrote:<br>>=3B <br>>=3B >=3B Ah=2C ok=2C t= hat makes sense. So maybe we just need an "unauthenticated"<br>>=3B >= =3B token? Still don't see anything really emergency-specific in this=2C<b= r>>=3B >=3B besides specifying what constraints you might put on unauth= enticated<br>>=3B >=3B users.<br>>=3B >=3B <br>>=3B >=3B --Rich= ard<br>>=3B >=3B <br>>=3B >=3B <br>>=3B >=3B <br>>=3B >=3B = On Mar 23=2C 2010=2C at 12:32 AM=2C Bernard Aboba wrote:<br>>=3B >=3B <= br>>=3B >=3B>=3B No=2C because the "anonymous" NAI is typically used = in protocols (like<br>>=3B >=3B>=3B EAP-TTLSv0=2C EAP-FAST or PEAP) w= here mutual authentication is<br>>=3B >=3B>=3B required. So while th= e NAS or an eavesdropper can't determine the<br>>=3B >=3B>=3B client = identity=2C the AAA server can and does determine it (and in<br>>=3B >= =3B>=3B turn=2C proves its identity to the client).<br>>=3B >=3B>= =3B <br>>=3B >=3B>=3B So at least in EAP=2C "anonymous" !=3D "unauthe= nticated"<br>>=3B >=3B>=3B <br>>=3B >=3B>=3B <br>>=3B >=3B&= gt=3B <br>>=3B >=3B>=3B <br>>=3B >=3B>=3B>=3B CC: jsalowey@ci= sco.com=3B dirk.kroeselberg@nsn.com=3B hgs@cs.columbia.edu<br>>=3B >=3B= >=3B =3B ecrit@ietf.org=3B emu@ietf.org<br>>=3B >=3B>=3B>=3B From= : rbarnes@bbn.com<br>>=3B >=3B>=3B>=3B To: bernard_aboba@hotmail.co= m<br>>=3B >=3B>=3B>=3B Subject: Re: [Ecrit] emergency access and EA= P-TLS (and denial of<br>>=3B >=3B>=3B serviceattacks on the emergency= .com domain)<br>>=3B >=3B>=3B>=3B Date: Mon=2C 22 Mar 2010 22:43:28= -0700<br>>=3B >=3B>=3B>=3B <br>>=3B >=3B>=3B>=3B Doesn't i= t functionally amount to the same thing=2C though? Just the<br>>=3B >= =3B>=3B>=3B client choosing not to authenticate vs not being able to<br= >>=3B >=3B>=3B authenticate?<br>>=3B >=3B>=3B>=3B --Richard<b= r>>=3B >=3B>=3B>=3B <br>>=3B >=3B>=3B>=3B <br>>=3B >=3B= >=3B>=3B On Mar 22=2C 2010=2C at 10:29 PM=2C Bernard Aboba wrote:<br>&g= t=3B >=3B>=3B>=3B <br>>=3B >=3B>=3B>=3B>=3B Yes=2C there is= an "anonymous" NAI=2C but the goal of that is to hide<br>>=3B >=3B>= =3B>=3B>=3B the identity from the NAS and eavesdroppers=2C not to enabl= e client<br>>=3B >=3B>=3B>=3B>=3B unauthenticated access.<br>>= =3B >=3B>=3B>=3B>=3B <br>>=3B >=3B>=3B>=3B>=3B On Mar 22= =2C 2010=2C at 10:23 PM=2C Richard Barnes <=3Brbarnes@bbn.com>=3B<br>&g= t=3B >=3B>=3B wrote:<br>>=3B >=3B>=3B>=3B>=3B <br>>=3B >= =3B>=3B>=3B>=3B>=3B In particular=2C providing unauthenticated *net= work* access is a<br>>=3B >=3B>=3B>=3B>=3B>=3B prerequisite for= providing unauthenticated *VoIP* access.<br>>=3B >=3B>=3B>=3B>= =3B>=3B <br>>=3B >=3B>=3B>=3B>=3B>=3B Also=2C Bernard: Does y= our below mention of "anonymous" NAI<br>>=3B >=3B>=3B indicate<br>>= =3B >=3B>=3B>=3B>=3B>=3B that there is actually a reserved NAI "a= nonymous"? If so=2C then I<br>>=3B >=3B>=3B>=3B>=3B>=3B don't r= eally see the use for a separate "sos" NAI -- you can just<br>>=3B >=3B= >=3B>=3B>=3B>=3B provide ECRIT access to "anonymous".<br>>=3B >= =3B>=3B>=3B>=3B>=3B <br>>=3B >=3B>=3B>=3B>=3B>=3B --Ric= hard<br>>=3B >=3B>=3B>=3B>=3B>=3B <br>>=3B >=3B>=3B>=3B= >=3B>=3B <br>>=3B >=3B>=3B>=3B>=3B>=3B <br>>=3B >=3B>= =3B>=3B>=3B>=3B On Mar 22=2C 2010=2C at 6:28 PM=2C Bernard Aboba wrot= e:<br>>=3B >=3B>=3B>=3B>=3B>=3B <br>>=3B >=3B>=3B>=3B&g= t=3B>=3B>=3B Part of the confusion here may be that we're talking about= <br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B "unauthenticated" at multip= le layers. There is unauthenticated<br>>=3B >=3B>=3B>=3B>=3B>= =3B>=3B network access=2C and then there is unauthenticated VOIP<br>>= =3B >=3B>=3B signaling.<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B = <br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B These are two orthogonal th= ings. The VOIP signaling should not<br>>=3B >=3B>=3B>=3B>=3B>= =3B>=3B change regardless of whether the network access is authenticated<= br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B or unauthenticated.<br>>= =3B >=3B>=3B>=3B>=3B>=3B>=3B <br>>=3B >=3B>=3B>=3B>= =3B>=3B>=3B Similarly=2C it's possible to use authenticated or unauthen= ticated<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B VOIP signaling over = authenticated or unauthenticated access.<br>>=3B >=3B>=3B>=3B>=3B= >=3B>=3B <br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B Focusing solel= y on how to obtain "unauthenticated" access=2C the<br>>=3B >=3B>=3B&g= t=3B>=3B>=3B>=3B question is how the client signals that it is intere= sted in<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B "unauthenticated" ac= cess. This is important=2C because otherwise<br>>=3B >=3B>=3B>=3B&g= t=3B>=3B>=3B the server might request client authentication (e.g. a cli= ent<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B certificate request). Es= sentially the "sos" NAI is functioning<br>>=3B >=3B>=3B>=3B>=3B&g= t=3B>=3B similar to the "anonymous" NAI in that this results in special<b= r>>=3B >=3B>=3B>=3B>=3B>=3B>=3B processing on the AAA server = side.<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B <br>>=3B >=3B>= =3B>=3B>=3B>=3B>=3B <br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B= <br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B Subject: RE: [Ecrit] emerg= ency access and EAP-TLS (and denial of<br>>=3B >=3B>=3B>=3B>=3B&g= t=3B>=3B serviceattacks on the emergency.com domain)<br>>=3B >=3B>= =3B>=3B>=3B>=3B>=3B Date: Mon=2C 22 Mar 2010 18:14:59 -0700<br>>= =3B >=3B>=3B>=3B>=3B>=3B>=3B From: jsalowey@cisco.com<br>>=3B= >=3B>=3B>=3B>=3B>=3B>=3B To: dirk.kroeselberg@nsn.com=3B hgs@c= s.columbia.edu=3B<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B bernard_ab= oba@hotmail.com<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B CC: ecrit@ie= tf.org<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B <br>>=3B >=3B>= =3B>=3B>=3B>=3B>=3B I do not think EAP or NAI should be used as a s= ignaling<br>>=3B >=3B>=3B mechanism<br>>=3B >=3B>=3B>=3B>= =3B>=3B>=3B for emergency. These mechanisms are ways to obtain network<= br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B access when you cannot in so= me other way. Once you have network<br>>=3B >=3B>=3B>=3B>=3B>= =3B>=3B access it seems that the emergency procedures should be the same<= br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B whether you authenticated to= get network access or you gained<br>>=3B >=3B>=3B>=3B>=3B>=3B&= gt=3B access though another mechanism.<br>>=3B >=3B>=3B>=3B>=3B&g= t=3B>=3B <br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B I am probably mi= ssing some ECRIT specific nuances here=2C but I<br>>=3B >=3B>=3B feel= <br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B that tying emergency proced= ures at higher layers to EAP usage<br>>=3B >=3B>=3B will<br>>=3B &g= t=3B>=3B>=3B>=3B>=3B>=3B be fraught with problems.<br>>=3B >= =3B>=3B>=3B>=3B>=3B>=3B <br>>=3B >=3B>=3B>=3B>=3B>=3B= >=3B Joe<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B <br>>=3B >=3B= >=3B>=3B>=3B>=3B>=3B <br>>=3B >=3B>=3B>=3B>=3B>=3B>= =3B From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On<br>>= =3B >=3B>=3B>=3B>=3B>=3B>=3B Behalf Of Kroeselberg=2C Dirk (NSN= - DE/Munich)<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B Sent: Monday= =2C March 22=2C 2010 5:26 PM<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B= To: ext Henning Schulzrinne=3B Bernard Aboba<br>>=3B >=3B>=3B>=3B&= gt=3B>=3B>=3B Cc: ecrit@ietf.org<br>>=3B >=3B>=3B>=3B>=3B>= =3B>=3B Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of<= br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B serviceattacks on the emerge= ncy.com domain)<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B <br>>=3B &= gt=3B>=3B>=3B>=3B>=3B>=3B yes=2C fixing the NAI to a simple strin= g is simple (this would<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B basi= cally be a NAI that is username only=2C correct?).<br>>=3B >=3B>=3B&g= t=3B>=3B>=3B>=3B <br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B Howe= ver=2C let me repeat my question from the other thread: How to<br>>=3B &g= t=3B>=3B>=3B>=3B>=3B>=3B handle the 'authenticated' emergency cas= e where the NAI carries<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B the = regular username? The draft may be about unauthenticated=2C<br>>=3B >= =3B>=3B but<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B just covering = unauthenticated and leaving the authenticated case<br>>=3B >=3B>=3B&g= t=3B>=3B>=3B>=3B open seems less useful to me.<br>>=3B >=3B>=3B= >=3B>=3B>=3B>=3B <br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B Di= rk<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B <br>>=3B >=3B>=3B&g= t=3B>=3B>=3B>=3B From: ext Henning Schulzrinne [mailto:hgs@cs.columbi= a.edu]<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B Sent: Tuesday=2C Marc= h 23=2C 2010 1:02 AM<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B To: Ber= nard Aboba<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B Cc: Kroeselberg= =2C Dirk (NSN - DE/Munich)=3B ecrit@ietf.org<br>>=3B >=3B>=3B>=3B&g= t=3B>=3B>=3B Subject: Re: [Ecrit] emergency access and EAP-TLS (and den= ial of<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B service attacks on th= e emergency.com domain)<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B <br>= >=3B >=3B>=3B>=3B>=3B>=3B>=3B The "sos" name seems to be a re= asonable approach that's simple<br>>=3B >=3B>=3B and<br>>=3B >=3B= >=3B>=3B>=3B>=3B>=3B easy.<br>>=3B >=3B>=3B>=3B>=3B>= =3B>=3B <br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B Longer term=2C I = think a better option is to have a semi-<br>>=3B >=3B>=3B>=3B>=3B= >=3B>=3B authenticated mode: Imagine a setup where VSPs or other<br>>= =3B >=3B>=3B trustable<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B b= odies hand out tokens (e.g.=2C using the OAuth-WARP work) that<br>>=3B &g= t=3B>=3B the<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B ISP recognize= s. The ISP is given the right to monitor the<br>>=3B >=3B>=3B usage o= f<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B 'sos' sessions and can han= d the token to the appropriate<br>>=3B >=3B>=3B>=3B>=3B>=3B>= =3B authorities for prosecution in case of abuse. That way=2C you get<br>&g= t=3B >=3B>=3B>=3B>=3B>=3B>=3B emergency access=2C but make it u= nlikely that the system will be<br>>=3B >=3B>=3B>=3B>=3B>=3B>= =3B abused on a large scale. In some countries=2C you might get such a<br>&= gt=3B >=3B>=3B>=3B>=3B>=3B>=3B token from your local public aut= hority when you're registering<br>>=3B >=3B>=3B>=3B>=3B>=3B>= =3B your residence.<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B <br>>= =3B >=3B>=3B>=3B>=3B>=3B>=3B Henning<br>>=3B >=3B>=3B>= =3B>=3B>=3B>=3B <br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B On Ma= r 22=2C 2010=2C at 7:50 PM=2C Bernard Aboba wrote:<br>>=3B >=3B>=3B&g= t=3B>=3B>=3B>=3B <br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B <br>= >=3B >=3B>=3B>=3B>=3B>=3B>=3B If all you want to do is to gai= n emergency access to the local<br>>=3B >=3B>=3B>=3B>=3B>=3B>= =3B network=2C you don't need to discover the domain. You can just use<br>&= gt=3B >=3B>=3B>=3B>=3B>=3B>=3B an NAI of "sos". That will be mo= re convenient in situations<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B = where the local access mechanism (e.g. 802.1X) doesn't permit IP<br>>=3B = >=3B>=3B>=3B>=3B>=3B>=3B packets (including DHCP) to pass prior= to completing<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B authenticatio= n=2C so that "domain discovery" couldn't occur until<br>>=3B >=3B>=3B= >=3B>=3B>=3B>=3B afterwards.<br>>=3B >=3B>=3B>=3B>=3B>= =3B>=3B <br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B <br>>=3B >=3B= >=3B>=3B>=3B>=3B>=3B ____________________________________________= ___<br>>=3B >=3B>=3B>=3B>=3B>=3B>=3B Ecrit mailing list<br>&g= t=3B >=3B>=3B>=3B>=3B>=3B>=3B Ecrit@ietf.org<br>>=3B >=3B&g= t=3B>=3B>=3B>=3B>=3B https://www.ietf.org/mailman/listinfo/ecrit<br= >>=3B >=3B>=3B>=3B>=3B>=3B <br>>=3B >=3B>=3B>=3B>=3B&= gt=3B <br>>=3B >=3B>=3B>=3B <br>>=3B >=3B <br>>=3B >=3B ___= ____________________________________________<br>>=3B >=3B Ecrit mailing= list<br>>=3B >=3B Ecrit@ietf.org<br>>=3B >=3B https://www.ietf.org= /mailman/listinfo/ecrit<br>>=3B <br>>=3B <br> </body> </html>= --_dec41396-c5aa-41ed-96c6-47b20c8260f7_-- From root@core3.amsl.com Tue Mar 23 16:45:02 2010 Return-Path: <root@core3.amsl.com> X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0C1193A6C4C; Tue, 23 Mar 2010 16:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100323234502.0C1193A6C4C@core3.amsl.com> Date: Tue, 23 Mar 2010 16:45:02 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-specifying-holes-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Mar 2010 23:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Specifying Holes in LoST Service Boundaries Author(s) : J. Winterbottom, M. Thomson Filename : draft-ietf-ecrit-specifying-holes-03.txt Pages : 17 Date : 2010-03-23 This document describes how holes can be specified in geodetic service boundaries. One means of implementing a search solution in a service database, such as one might provide with a LoST server, is described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-specifying-holes-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-specifying-holes-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-23163752.I-D@ietf.org> --NextPart-- From Martin.Dawson@andrew.com Tue Mar 23 18:14:21 2010 Return-Path: <Martin.Dawson@andrew.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A55DE3A684D; Tue, 23 Mar 2010 18:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.456 X-Spam-Level: * X-Spam-Status: No, score=1.456 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 EP7FAQ25FA0f; Tue, 23 Mar 2010 18:14:20 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 7904E3A67AD; Tue, 23 Mar 2010 18:14:20 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:29374 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S15374830Ab0CXBOj convert rfc822-to-8bit (ORCPT <rfc822;ecrit@ietf.org> + 1 other); Tue, 23 Mar 2010 20:14:39 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 23 Mar 2010 20:14:39 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 24 Mar 2010 09:14:36 +0800 From: "Dawson, Martin" <Martin.Dawson@andrew.com> To: "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com>, Brian Rosen <br@brianrosen.net>, "Thomson, Martin" <Martin.Thomson@andrew.com>, Richard Barnes <rbarnes@bbn.com>, Bernard Aboba <bernard_aboba@hotmail.com> Date: Wed, 24 Mar 2010 09:14:35 +0800 Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrKzRfOc6w4ZPWsrkimclW4dAPFuwAAHhnQAACVA9cAAQknQAACQEEAAAQ84AA= Message-ID: <8B0A9FCBB9832F43971E38010638454F03E24ED048@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03E24ED000@SISPE7MB1.commscope.com><C7CEAAED.2AF6F%br@brianrosen.net> <8B0A9FCBB9832F43971E38010638454F03E24ED009@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB904@DEMUEXC030.nsn-intra.net> In-Reply-To: <8C51C7A529FC9D49843ACF5AE2FFBF67025DB904@DEMUEXC030.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Cc: "emu@ietf.org" <emu@ietf.org>, "ecrit@ietf.org" <ecrit@ietf.org> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 24 Mar 2010 01:14:21 -0000 Consider the access out of scope, certainly. Recommend to access-specific forums that they shouldn't *assume* the connecting device is actually the device making the emergency call (e.g. a WiFi device on a portable 3G router) so there's no reliable assumption the connecting device can provide an emergency flag. Then it's whatever ECRIT might recommend as appropriate on top of IP. I think Richard's questions are along the line of what the value of this specific "emergency flag" is at the IP level. It's not like anyone but the device user knows whether the access really is only required for emergency purposes. It's a valid question; access policy may just be to bar or allow (depending on whether it's a prohibitive or a permissive policy) access to emergency specific things - such as routes to PSAPs. A flag is not necessarily required to apply that sort of policy. Cheers, Martin -----Original Message----- From: Kroeselberg, Dirk (NSN - DE/Munich) [mailto:dirk.kroeselberg@nsn.com] Sent: Wednesday, 24 March 2010 10:14 AM To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba Cc: emu@ietf.org; ecrit@ietf.org Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) > So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, > the DSL forum, etc. as to how a device is able to get an > unauthenticated IP context on their technology, for whatever > purpose, before the policies on permitting/prohibiting ECRIT but what is the concrete recommendation that you want to give here? - Drop the access/ISP part from the draft and say access/ISP is out-of-scope? - move this to EMU? - or deal with the EAP/NAI related aspects outside IETF as you seem to suggest (which is already partially the case today due to lack of guidance)? > is on others. I doubt that there's a reasonable assumption > that the connecting device can necessarily provide an > explicit "emergency intent" flag. maybe this is why some people do this via the NAI ;-) Dirk > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of ext Dawson, Martin > Sent: Tuesday, March 23, 2010 11:44 PM > To: Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba > Cc: emu@ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial > of serviceattacks on the emergency.com domain) > > To elaborate on Brian's "counter point" - some jurisdictions > may prefer to *forbid* access to the emergency service from > unauthenticated/anonymous access as opposed to *require* it > to be supported. Noting this is the equivalent of saying > emergency calls for circuit service cannot be made from > public phone booths; this is still a possible policy within a > given jurisdiction. > > I'd also posit that not only is it not a priority for IETF > but that the question actually needs to be dealt with in more > specific forums first. The ECRIT emergency procedures occur > at or above the IP layer. Before anything that ECRIT > describes becomes relevant, there needs to be an IP context. > > So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, > the DSL forum, etc. as to how a device is able to get an > unauthenticated IP context on their technology, for whatever > purpose, before the policies on permitting/prohibiting ECRIT > procedures or anything else that can be done on IP can be > applied. This is easier on some access technologies than it > is on others. I doubt that there's a reasonable assumption > that the connecting device can necessarily provide an > explicit "emergency intent" flag. > > Cheers, > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Wednesday, 24 March 2010 8:29 AM > To: Thomson, Martin; Richard Barnes; Bernard Aboba > Cc: emu@ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial > of serviceattacks on the emergency.com domain) > > I think the relevant part of this is 'it's not a high > priority'. That is > policy of the work group, which we do have control over. > > If we have nothing else more important to do, then by all > means, let's waste > a ton of time on unauthenticated access. If we have other work to do, > perhaps we could defer this. > > I am not the chair, but in general, anyone can discuss > anything, regardless > of "priority" on the list. However, when it comes to > adopting work group > items, I think this should be way down our list. > > I might also suggest that unauthenticated access really isn't > within the > charter of the work group. It may be that the reason > unauthenticated access > may be needed is for emergency calling, but that means we may > (eventually) > need to ask some other work group to do work for a > requirement we generate. > It would seem that dealing with EAP is not within the domain > of this work > group. > > Brian > > > On 3/23/10 5:14 PM, "Thomson, Martin" > <Martin.Thomson@andrew.com> wrote: > > >> A large percentage (in fact an overwhelming percentage) of > PSAPs DON'T > >> WANT > >> unauthenticated access. Their position is that they have lots of > >> relevant > >> experience, and its all bad (tens of thousands of calls > with no good > >> ones in > >> some cases). > >> > >> However, there are some PSAPs who want it, and there are some > >> regulatory > >> environments where there are some lawyers who think it's > required to > >> support > >> it in some environments. > > > > The good thing is: we don't set policy here. I'm not > seeing sufficient > > evidence that _everyone_ doesn't want this, only that some > don't want this. > > > > I can't comment on priority. That would be policy too. > > > > --Martin > > > _______________________________________________ > 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 Tue Mar 23 18:38:40 2010 Return-Path: <Hannes.Tschofenig@gmx.net> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D7C23A6857 for <ecrit@core3.amsl.com>; Tue, 23 Mar 2010 18:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 cTyE53Q1lTbY for <ecrit@core3.amsl.com>; Tue, 23 Mar 2010 18:38:39 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3A5873A681F for <ecrit@ietf.org>; Tue, 23 Mar 2010 18:38:38 -0700 (PDT) Received: (qmail invoked by alias); 24 Mar 2010 01:38:57 -0000 Received: from dhcp-wireless-open-abg-24-115.meeting.ietf.org (EHLO [130.129.24.115]) [130.129.24.115] by mail.gmx.net (mp029) with SMTP; 24 Mar 2010 02:38:57 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/rLuw0hFfrYrFHuvil3vdOPEcERcDoKjfVUvFWZi AIrgwQfbO8c7Re Message-ID: <4BA96D17.3080206@gmx.net> Date: Tue, 23 Mar 2010 21:38:31 -0400 From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net> User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: 'ECRIT' <ecrit@ietf.org>, GEOPRIV <geopriv@ietf.org>, earlywarning@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.68999999999999995 Subject: [Ecrit] ATOCA Informal Gathering at IETF#77 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 24 Mar 2010 01:38:40 -0000 Reminder for the chat about the ATOCA charter text discussion as mentioned in my previous mail. DATE: Wednesday, 24th March TIME: 13:00 to 15:00 ROOM: Carmel (4th floor) Looking forward to see you there. Ciao Hannes From dirk.kroeselberg@nsn.com Tue Mar 23 20:11:57 2010 Return-Path: <dirk.kroeselberg@nsn.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C36A3A694C; Tue, 23 Mar 2010 20:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 kmzFpQxDb4nN; Tue, 23 Mar 2010 20:11:54 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 15B373A686A; Tue, 23 Mar 2010 20:11:53 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2O3BwPR019713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Mar 2010 04:11:58 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2O3Bwql025901; Wed, 24 Mar 2010 04:11:58 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Mar 2010 04:11:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Mar 2010 04:11:55 +0100 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF67025DB920@DEMUEXC030.nsn-intra.net> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E24ED048@SISPE7MB1.commscope.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrKzRfOc6w4ZPWsrkimclW4dAPFuwAAHhnQAACVA9cAAQknQAACQEEAAAQ84AAABDcxsA== References: <8B0A9FCBB9832F43971E38010638454F03E24ED000@SISPE7MB1.commscope.com><C7CEAAED.2AF6F%br@brianrosen.net> <8B0A9FCBB9832F43971E38010638454F03E24ED009@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB904@DEMUEXC030.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03E24ED048@SISPE7MB1.commscope.com> From: "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com> To: "ext Dawson, Martin" <Martin.Dawson@andrew.com>, "Brian Rosen" <br@brianrosen.net>, "Thomson, Martin" <Martin.Thomson@andrew.com>, "Richard Barnes" <rbarnes@bbn.com>, "Bernard Aboba" <bernard_aboba@hotmail.com> X-OriginalArrivalTime: 24 Mar 2010 03:11:57.0973 (UTC) FILETIME=[C38CB450:01CACAFF] Cc: emu@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 24 Mar 2010 03:11:57 -0000 see inline. Dirk=20 > -----Original Message----- > From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 > Sent: Wednesday, March 24, 2010 2:15 AM > To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen;=20 > Thomson, Martin; Richard Barnes; Bernard Aboba > Cc: emu@ietf.org; ecrit@ietf.org > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial=20 > of serviceattacks on the emergency.com domain) >=20 > Consider the access out of scope, certainly. Recommend to=20 > access-specific forums that they shouldn't *assume* the=20 > connecting device is actually the device making the emergency=20 > call (e.g. a WiFi device on a portable 3G router) so there's=20 > no reliable assumption the connecting device can provide an=20 > emergency flag. I do not see a value in such recommendation from IETF would be.=20 For layer-2 flags these organizations define such flags. They know. =20 > Then it's whatever ECRIT might recommend as appropriate on=20 > top of IP. I think Richard's questions are along the line of=20 > what the value of this specific "emergency flag" is at the IP=20 > level.=20 What flag are you refering to? Up to now we were only discussing options to indicate emergency in EAP, which rather on top of layer-2 than IP. It's not like anyone but the device user knows whether=20 > the access really is only required for emergency purposes.=20 > It's a valid question; access policy may just be to bar or=20 > allow (depending on whether it's a prohibitive or a=20 > permissive policy) access to emergency specific things - such=20 > as routes to PSAPs. A flag is not necessarily required to=20 > apply that sort of policy. Without a full subscription (either insufficient authorization or no subscription) you may want to enter the NW for other things than emergency. So would you always hotline these entrants to the PSAP? >=20 > Cheers, > Martin >=20 > -----Original Message----- > From: Kroeselberg, Dirk (NSN - DE/Munich)=20 > [mailto:dirk.kroeselberg@nsn.com]=20 > Sent: Wednesday, 24 March 2010 10:14 AM > To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard=20 > Barnes; Bernard Aboba > Cc: emu@ietf.org; ecrit@ietf.org > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial=20 > of serviceattacks on the emergency.com domain) >=20 > > So - it's more the domain of the IEEE, 3GPP, WiFi Alliance,=20 > > the DSL forum, etc. as to how a device is able to get an=20 > > unauthenticated IP context on their technology, for whatever=20 > > purpose, before the policies on permitting/prohibiting ECRIT =20 >=20 > but what is the concrete recommendation that you want to give here? >=20 > - Drop the access/ISP part from the draft and say access/ISP is > out-of-scope? > - move this to EMU? > - or deal with the EAP/NAI related aspects outside IETF as you seem to > suggest (which is already partially the case today due to lack of > guidance)? >=20 > > is on others. I doubt that there's a reasonable assumption=20 > > that the connecting device can necessarily provide an=20 > > explicit "emergency intent" flag. > maybe this is why some people do this via the NAI ;-) >=20 > Dirk >=20 >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > > On Behalf Of ext Dawson, Martin > > Sent: Tuesday, March 23, 2010 11:44 PM > > To: Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba > > Cc: emu@ietf.org; ecrit@ietf.org > > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial=20 > > of serviceattacks on the emergency.com domain) > >=20 > > To elaborate on Brian's "counter point" - some jurisdictions=20 > > may prefer to *forbid* access to the emergency service from=20 > > unauthenticated/anonymous access as opposed to *require* it=20 > > to be supported. Noting this is the equivalent of saying=20 > > emergency calls for circuit service cannot be made from=20 > > public phone booths; this is still a possible policy within a=20 > > given jurisdiction. > >=20 > > I'd also posit that not only is it not a priority for IETF=20 > > but that the question actually needs to be dealt with in more=20 > > specific forums first. The ECRIT emergency procedures occur=20 > > at or above the IP layer. Before anything that ECRIT=20 > > describes becomes relevant, there needs to be an IP context. > >=20 > > So - it's more the domain of the IEEE, 3GPP, WiFi Alliance,=20 > > the DSL forum, etc. as to how a device is able to get an=20 > > unauthenticated IP context on their technology, for whatever=20 > > purpose, before the policies on permitting/prohibiting ECRIT=20 > > procedures or anything else that can be done on IP can be=20 > > applied. This is easier on some access technologies than it=20 > > is on others. I doubt that there's a reasonable assumption=20 > > that the connecting device can necessarily provide an=20 > > explicit "emergency intent" flag. > >=20 > > Cheers, > > Martin > >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > > On Behalf Of Brian Rosen > > Sent: Wednesday, 24 March 2010 8:29 AM > > To: Thomson, Martin; Richard Barnes; Bernard Aboba > > Cc: emu@ietf.org; ecrit@ietf.org > > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial=20 > > of serviceattacks on the emergency.com domain) > >=20 > > I think the relevant part of this is 'it's not a high=20 > > priority'. That is > > policy of the work group, which we do have control over. > >=20 > > If we have nothing else more important to do, then by all=20 > > means, let's waste > > a ton of time on unauthenticated access. If we have other=20 > work to do, > > perhaps we could defer this. > >=20 > > I am not the chair, but in general, anyone can discuss=20 > > anything, regardless > > of "priority" on the list. However, when it comes to=20 > > adopting work group > > items, I think this should be way down our list. > >=20 > > I might also suggest that unauthenticated access really isn't=20 > > within the > > charter of the work group. It may be that the reason=20 > > unauthenticated access > > may be needed is for emergency calling, but that means we may=20 > > (eventually) > > need to ask some other work group to do work for a=20 > > requirement we generate. > > It would seem that dealing with EAP is not within the domain=20 > > of this work > > group. > >=20 > > Brian > >=20 > >=20 > > On 3/23/10 5:14 PM, "Thomson, Martin"=20 > > <Martin.Thomson@andrew.com> wrote: > >=20 > > >> A large percentage (in fact an overwhelming percentage) of=20 > > PSAPs DON'T > > >> WANT > > >> unauthenticated access. Their position is that they have lots of > > >> relevant > > >> experience, and its all bad (tens of thousands of calls=20 > > with no good > > >> ones in > > >> some cases). > > >>=20 > > >> However, there are some PSAPs who want it, and there are some > > >> regulatory > > >> environments where there are some lawyers who think it's=20 > > required to > > >> support > > >> it in some environments. > > >=20 > > > The good thing is: we don't set policy here. I'm not=20 > > seeing sufficient > > > evidence that _everyone_ doesn't want this, only that some=20 > > don't want this. > > >=20 > > > I can't comment on priority. That would be policy too. > > >=20 > > > --Martin > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > >=20 >=20 From Martin.Dawson@andrew.com Tue Mar 23 21:42:26 2010 Return-Path: <Martin.Dawson@andrew.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B61C3A67A7; Tue, 23 Mar 2010 21:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.348 X-Spam-Level: * X-Spam-Status: No, score=1.348 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 d0l-R+4LNv7E; Tue, 23 Mar 2010 21:42:25 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id BFA553A6783; Tue, 23 Mar 2010 21:42:24 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:34855 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S199085Ab0CXEmo convert rfc822-to-8bit (ORCPT <rfc822;ecrit@ietf.org> + 1 other); Tue, 23 Mar 2010 23:42:44 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 23 Mar 2010 23:42:44 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 24 Mar 2010 12:42:26 +0800 From: "Dawson, Martin" <Martin.Dawson@andrew.com> To: "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com>, Brian Rosen <br@brianrosen.net>, "Thomson, Martin" <Martin.Thomson@andrew.com>, Richard Barnes <rbarnes@bbn.com>, Bernard Aboba <bernard_aboba@hotmail.com> Date: Wed, 24 Mar 2010 12:42:23 +0800 Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrKzRfOc6w4ZPWsrkimclW4dAPFuwAAHhnQAACVA9cAAQknQAACQEEAAAQ84AAABDcxsAACUHmQ Message-ID: <8B0A9FCBB9832F43971E38010638454F03E24ED0A9@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03E24ED000@SISPE7MB1.commscope.com><C7CEAAED.2AF6F%br@brianrosen.net> <8B0A9FCBB9832F43971E38010638454F03E24ED009@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB904@DEMUEXC030.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03E24ED048@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB920@DEMUEXC030.nsn-intra.net> In-Reply-To: <8C51C7A529FC9D49843ACF5AE2FFBF67025DB920@DEMUEXC030.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Cc: "emu@ietf.org" <emu@ietf.org>, "ecrit@ietf.org" <ecrit@ietf.org> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 24 Mar 2010 04:42:26 -0000 Hi Dirk, > I do not see a value in such recommendation from IETF would be. > For layer-2 flags these organizations define such flags. They know. SDOs set their own agendas; that's fair enough. They don't always want to consider how their architectures interwork with specifications defined by, say, the IETF. So perhaps, as you say, it's pointless. While ECRIT procedures are at the IP level and are intended to support clients that are connecting on IP via a routing device at the access, a "link technology SDO" may still persist with the assumption that it's the connecting device that negotiates procedures in an emergency scenario. Alternatively, they may consider the ECRIT model and decide to do something different. It is, as you say, up to them. > What flag are you refering to? Up to now we were only discussing options > to indicate emergency in EAP, which rather on top of layer-2 than IP. Which, if I understand it, is about negotiating an IP context in what is also an "emergency context". Leaving aside my point above as to whether that's a generally effective facility for supporting emergency connectivity, there's also the question (which I may be unfairly be attributing to Richard) as to what value it is to the access to know that this connectivity has been granted in an "emergency context". What's it going to do with this alleged context? > Without a full subscription (either insufficient authorization or no > subscription) you may want to enter the NW for other things than > emergency. So would you always hotline these entrants to the PSAP? No - you wouldn't. But, then, the concept of "hotlining the entrant to a PSAP" refers to a procedure that isn't described by ECRIT. There's no "hotlining". The device knows it wants to initiate an emergency call; it gets location from the LIS, gets the PSAP URI from LoST, and initiates a SIP session to the PSAP. The proposition of "hotlining" based on a layer 2 technology specific procedure is the sort of thing I refer to above. An access technology specific SDO may, for their own reasons, decide to define this sort of thing. I think they're talking about use cases that are orthogonal to what ECRIT is describing. ECRIT describes emergency procedures for the Internet, on IP, and independent of access technology. I guess the extent to which an SDO thinks these things are worth developing depends on the extent to which they think a) ECRIT is not a significant model or to which b) they think there are "emergency" use cases that are outside the Internet domain or to which c) there is some complementary subset of use cases for their link technology (e.g. WiFi phones in an enterprise environment with an "emergency" button that set up an emergency IP context and are hotlined to the enterprise softswitch that then does ECRIT procedures to the outside world). The SDO just needs to decide whether there is a benefit consistent with the effort in defining/implementing such functionality. I think it's good if their delegates are aware of ECRIT in making that decision. Cheers, Martin -----Original Message----- From: Kroeselberg, Dirk (NSN - DE/Munich) [mailto:dirk.kroeselberg@nsn.com] Sent: Wednesday, 24 March 2010 2:12 PM To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba Cc: emu@ietf.org; ecrit@ietf.org Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) see inline. Dirk > -----Original Message----- > From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Wednesday, March 24, 2010 2:15 AM > To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen; > Thomson, Martin; Richard Barnes; Bernard Aboba > Cc: emu@ietf.org; ecrit@ietf.org > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial > of serviceattacks on the emergency.com domain) > > Consider the access out of scope, certainly. Recommend to > access-specific forums that they shouldn't *assume* the > connecting device is actually the device making the emergency > call (e.g. a WiFi device on a portable 3G router) so there's > no reliable assumption the connecting device can provide an > emergency flag. I do not see a value in such recommendation from IETF would be. For layer-2 flags these organizations define such flags. They know. > Then it's whatever ECRIT might recommend as appropriate on > top of IP. I think Richard's questions are along the line of > what the value of this specific "emergency flag" is at the IP > level. What flag are you refering to? Up to now we were only discussing options to indicate emergency in EAP, which rather on top of layer-2 than IP. It's not like anyone but the device user knows whether > the access really is only required for emergency purposes. > It's a valid question; access policy may just be to bar or > allow (depending on whether it's a prohibitive or a > permissive policy) access to emergency specific things - such > as routes to PSAPs. A flag is not necessarily required to > apply that sort of policy. Without a full subscription (either insufficient authorization or no subscription) you may want to enter the NW for other things than emergency. So would you always hotline these entrants to the PSAP? > > Cheers, > Martin > > -----Original Message----- > From: Kroeselberg, Dirk (NSN - DE/Munich) > [mailto:dirk.kroeselberg@nsn.com] > Sent: Wednesday, 24 March 2010 10:14 AM > To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard > Barnes; Bernard Aboba > Cc: emu@ietf.org; ecrit@ietf.org > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial > of serviceattacks on the emergency.com domain) > > > So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, > > the DSL forum, etc. as to how a device is able to get an > > unauthenticated IP context on their technology, for whatever > > purpose, before the policies on permitting/prohibiting ECRIT > > but what is the concrete recommendation that you want to give here? > > - Drop the access/ISP part from the draft and say access/ISP is > out-of-scope? > - move this to EMU? > - or deal with the EAP/NAI related aspects outside IETF as you seem to > suggest (which is already partially the case today due to lack of > guidance)? > > > is on others. I doubt that there's a reasonable assumption > > that the connecting device can necessarily provide an > > explicit "emergency intent" flag. > maybe this is why some people do this via the NAI ;-) > > Dirk > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of ext Dawson, Martin > > Sent: Tuesday, March 23, 2010 11:44 PM > > To: Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba > > Cc: emu@ietf.org; ecrit@ietf.org > > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial > > of serviceattacks on the emergency.com domain) > > > > To elaborate on Brian's "counter point" - some jurisdictions > > may prefer to *forbid* access to the emergency service from > > unauthenticated/anonymous access as opposed to *require* it > > to be supported. Noting this is the equivalent of saying > > emergency calls for circuit service cannot be made from > > public phone booths; this is still a possible policy within a > > given jurisdiction. > > > > I'd also posit that not only is it not a priority for IETF > > but that the question actually needs to be dealt with in more > > specific forums first. The ECRIT emergency procedures occur > > at or above the IP layer. Before anything that ECRIT > > describes becomes relevant, there needs to be an IP context. > > > > So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, > > the DSL forum, etc. as to how a device is able to get an > > unauthenticated IP context on their technology, for whatever > > purpose, before the policies on permitting/prohibiting ECRIT > > procedures or anything else that can be done on IP can be > > applied. This is easier on some access technologies than it > > is on others. I doubt that there's a reasonable assumption > > that the connecting device can necessarily provide an > > explicit "emergency intent" flag. > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of Brian Rosen > > Sent: Wednesday, 24 March 2010 8:29 AM > > To: Thomson, Martin; Richard Barnes; Bernard Aboba > > Cc: emu@ietf.org; ecrit@ietf.org > > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial > > of serviceattacks on the emergency.com domain) > > > > I think the relevant part of this is 'it's not a high > > priority'. That is > > policy of the work group, which we do have control over. > > > > If we have nothing else more important to do, then by all > > means, let's waste > > a ton of time on unauthenticated access. If we have other > work to do, > > perhaps we could defer this. > > > > I am not the chair, but in general, anyone can discuss > > anything, regardless > > of "priority" on the list. However, when it comes to > > adopting work group > > items, I think this should be way down our list. > > > > I might also suggest that unauthenticated access really isn't > > within the > > charter of the work group. It may be that the reason > > unauthenticated access > > may be needed is for emergency calling, but that means we may > > (eventually) > > need to ask some other work group to do work for a > > requirement we generate. > > It would seem that dealing with EAP is not within the domain > > of this work > > group. > > > > Brian > > > > > > On 3/23/10 5:14 PM, "Thomson, Martin" > > <Martin.Thomson@andrew.com> wrote: > > > > >> A large percentage (in fact an overwhelming percentage) of > > PSAPs DON'T > > >> WANT > > >> unauthenticated access. Their position is that they have lots of > > >> relevant > > >> experience, and its all bad (tens of thousands of calls > > with no good > > >> ones in > > >> some cases). > > >> > > >> However, there are some PSAPs who want it, and there are some > > >> regulatory > > >> environments where there are some lawyers who think it's > > required to > > >> support > > >> it in some environments. > > > > > > The good thing is: we don't set policy here. I'm not > > seeing sufficient > > > evidence that _everyone_ doesn't want this, only that some > > don't want this. > > > > > > I can't comment on priority. That would be policy too. > > > > > > --Martin > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > From Martin.Dawson@andrew.com Wed Mar 24 03:55:16 2010 Return-Path: <Martin.Dawson@andrew.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B41813A6A21; Wed, 24 Mar 2010 03:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.293 X-Spam-Level: * X-Spam-Status: No, score=1.293 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 ULZFhLo3dQfX; Wed, 24 Mar 2010 03:55:15 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id AE2603A68EC; Wed, 24 Mar 2010 03:55:11 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:49513 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S15140834Ab0CXKzb convert rfc822-to-8bit (ORCPT <rfc822;emu@ietf.org> + 1 other); Wed, 24 Mar 2010 05:55:31 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 24 Mar 2010 05:55:31 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 24 Mar 2010 18:55:28 +0800 From: "Dawson, Martin" <Martin.Dawson@andrew.com> To: "Kutt, Andres" <akutt@ebay.com> Date: Wed, 24 Mar 2010 18:55:26 +0800 Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrKzRfOc6w4ZPWsrkimclW4dAPFuwAAHhnQAACVA9cAAQknQAACQEEAAAQ84AAAE8l+zAAAihfg Message-ID: <8B0A9FCBB9832F43971E38010638454F03E24ED180@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03E24ED048@SISPE7MB1.commscope.com> <C7CFB696.6B64%akutt@ebay.com> In-Reply-To: <C7CFB696.6B64%akutt@ebay.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="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Cc: "emu@ietf.org" <emu@ietf.org>, "ecrit@ietf.org" <ecrit@ietf.org> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 24 Mar 2010 10:55:16 -0000 Hi Andres, Could you take us step by step through the establishment of the anonymous connection and the initiation of the emergency call and highlight where/how this notification mechanism would be invoked and what it would do? I would find that helpful. I'm interested in how people see the access network being able to limit the use of an arbitrary third party VoIP application to emergency calling, if that's the intent, in the context of unauthenticated/anonymous access. BTW, I haven't said that access is completely out of scope. Actually, it obviously is in scope both in terms of what facilities it provides and what its policies are with respect to emergency calling procedures in the context of unaurthenticated/anonymous connections. It's the concept of gating the establishment of unauthenticated/anonymous connections on some kind of a priori knowledge or indication that its for the purpose of an emergency call that I question. Regards, Martin -----Original Message----- From: Kutt, Andres [mailto:akutt@ebay.com] Sent: Wednesday, 24 March 2010 9:31 PM To: Dawson, Martin Cc: emu@ietf.org; ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Hi, Leaving access completely out of scope is of course the easiest course but some synchronization must remain. In case of Skype, there is no way for the access provider to tell whether the user is placing an emergency call or chatting with their friends as the protocol used is opaque for the outsider. This is true in any case the service provider uses a protocol not known or understood by access provider and we must assume this can legally occur. Thus, should anonymous access be required, a mechanism must exist to notify the access provider about an attempted emergency call. Yours, Andres On 3/24/10 3:14 AM, "Dawson, Martin" <Martin.Dawson@andrew.com> wrote: > Consider the access out of scope, certainly. Recommend to access-specific > forums that they shouldn't *assume* the connecting device is actually the > device making the emergency call (e.g. a WiFi device on a portable 3G router) > so there's no reliable assumption the connecting device can provide an > emergency flag. > > Then it's whatever ECRIT might recommend as appropriate on top of IP. I think > Richard's questions are along the line of what the value of this specific > "emergency flag" is at the IP level. It's not like anyone but the device user > knows whether the access really is only required for emergency purposes. It's > a valid question; access policy may just be to bar or allow (depending on > whether it's a prohibitive or a permissive policy) access to emergency > specific things - such as routes to PSAPs. A flag is not necessarily required > to apply that sort of policy. > > Cheers, > Martin > > -----Original Message----- > From: Kroeselberg, Dirk (NSN - DE/Munich) [mailto:dirk.kroeselberg@nsn.com] > Sent: Wednesday, 24 March 2010 10:14 AM > To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; Bernard > Aboba > Cc: emu@ietf.org; ecrit@ietf.org > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of > serviceattacks on the emergency.com domain) > >> So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, >> the DSL forum, etc. as to how a device is able to get an >> unauthenticated IP context on their technology, for whatever >> purpose, before the policies on permitting/prohibiting ECRIT > > but what is the concrete recommendation that you want to give here? > > - Drop the access/ISP part from the draft and say access/ISP is > out-of-scope? > - move this to EMU? > - or deal with the EAP/NAI related aspects outside IETF as you seem to > suggest (which is already partially the case today due to lack of > guidance)? > >> is on others. I doubt that there's a reasonable assumption >> that the connecting device can necessarily provide an >> explicit "emergency intent" flag. > maybe this is why some people do this via the NAI ;-) > > Dirk > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of ext Dawson, Martin >> Sent: Tuesday, March 23, 2010 11:44 PM >> To: Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba >> Cc: emu@ietf.org; ecrit@ietf.org >> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial >> of serviceattacks on the emergency.com domain) >> >> To elaborate on Brian's "counter point" - some jurisdictions >> may prefer to *forbid* access to the emergency service from >> unauthenticated/anonymous access as opposed to *require* it >> to be supported. Noting this is the equivalent of saying >> emergency calls for circuit service cannot be made from >> public phone booths; this is still a possible policy within a >> given jurisdiction. >> >> I'd also posit that not only is it not a priority for IETF >> but that the question actually needs to be dealt with in more >> specific forums first. The ECRIT emergency procedures occur >> at or above the IP layer. Before anything that ECRIT >> describes becomes relevant, there needs to be an IP context. >> >> So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, >> the DSL forum, etc. as to how a device is able to get an >> unauthenticated IP context on their technology, for whatever >> purpose, before the policies on permitting/prohibiting ECRIT >> procedures or anything else that can be done on IP can be >> applied. This is easier on some access technologies than it >> is on others. I doubt that there's a reasonable assumption >> that the connecting device can necessarily provide an >> explicit "emergency intent" flag. >> >> Cheers, >> Martin >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of Brian Rosen >> Sent: Wednesday, 24 March 2010 8:29 AM >> To: Thomson, Martin; Richard Barnes; Bernard Aboba >> Cc: emu@ietf.org; ecrit@ietf.org >> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial >> of serviceattacks on the emergency.com domain) >> >> I think the relevant part of this is 'it's not a high >> priority'. That is >> policy of the work group, which we do have control over. >> >> If we have nothing else more important to do, then by all >> means, let's waste >> a ton of time on unauthenticated access. If we have other work to do, >> perhaps we could defer this. >> >> I am not the chair, but in general, anyone can discuss >> anything, regardless >> of "priority" on the list. However, when it comes to >> adopting work group >> items, I think this should be way down our list. >> >> I might also suggest that unauthenticated access really isn't >> within the >> charter of the work group. It may be that the reason >> unauthenticated access >> may be needed is for emergency calling, but that means we may >> (eventually) >> need to ask some other work group to do work for a >> requirement we generate. >> It would seem that dealing with EAP is not within the domain >> of this work >> group. >> >> Brian >> >> >> On 3/23/10 5:14 PM, "Thomson, Martin" >> <Martin.Thomson@andrew.com> wrote: >> >>>> A large percentage (in fact an overwhelming percentage) of >> PSAPs DON'T >>>> WANT >>>> unauthenticated access. Their position is that they have lots of >>>> relevant >>>> experience, and its all bad (tens of thousands of calls >> with no good >>>> ones in >>>> some cases). >>>> >>>> However, there are some PSAPs who want it, and there are some >>>> regulatory >>>> environments where there are some lawyers who think it's >> required to >>>> support >>>> it in some environments. >>> >>> The good thing is: we don't set policy here. I'm not >> seeing sufficient >>> evidence that _everyone_ doesn't want this, only that some >> don't want this. >>> >>> I can't comment on priority. That would be policy too. >>> >>> --Martin >> >> >> _______________________________________________ >> 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 dirk.kroeselberg@nsn.com Wed Mar 24 08:53:58 2010 Return-Path: <dirk.kroeselberg@nsn.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0BF23A6999; Wed, 24 Mar 2010 08:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 2cComRIEFixF; Wed, 24 Mar 2010 08:53:56 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id B865D3A6B9D; Wed, 24 Mar 2010 08:46:16 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2OFkGZ8018043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Mar 2010 16:46:16 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2OFkDlt025948; Wed, 24 Mar 2010 16:46:15 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Mar 2010 16:46:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Mar 2010 16:46:10 +0100 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF67025DBEDB@DEMUEXC030.nsn-intra.net> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E24ED0A9@SISPE7MB1.commscope.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrKzRfOc6w4ZPWsrkimclW4dAPFuwAAHhnQAACVA9cAAQknQAACQEEAAAQ84AAABDcxsAACUHmQABfrbWA= References: <8B0A9FCBB9832F43971E38010638454F03E24ED000@SISPE7MB1.commscope.com><C7CEAAED.2AF6F%br@brianrosen.net> <8B0A9FCBB9832F43971E38010638454F03E24ED009@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB904@DEMUEXC030.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03E24ED048@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB920@DEMUEXC030.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03E24ED0A9@SISPE7MB1.commscope.com> From: "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com> To: "ext Dawson, Martin" <Martin.Dawson@andrew.com>, "Brian Rosen" <br@brianrosen.net>, "Thomson, Martin" <Martin.Thomson@andrew.com>, "Richard Barnes" <rbarnes@bbn.com>, "Bernard Aboba" <bernard_aboba@hotmail.com> X-OriginalArrivalTime: 24 Mar 2010 15:46:14.0822 (UTC) FILETIME=[22BBD460:01CACB69] Cc: emu@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 24 Mar 2010 15:53:58 -0000 > facility for supporting emergency connectivity, there's also=20 > the question (which I may be unfairly be attributing to=20 > Richard) as to what value it is to the access to know that=20 > this connectivity has been granted in an "emergency context".=20 > What's it going to do with this alleged context? Considering this in authorization decisions, QoS, setting IP filters (limited access), priority. Just to give a few examples.=20 > No - you wouldn't. But, then, the concept of "hotlining the=20 > entrant to a PSAP" refers to a procedure that isn't described=20 > by ECRIT. There's no "hotlining". The device knows it wants=20 Right, but I was saying it is important for the access network to recognize that the 'special' entry the MS wants to do is for emergency, not let the access network roll dices. Of course hotlining procedures are not in scope of ECRIT, there is nothing emergency-specific besides installing the right filters (which by the way we also discuss in the draft - should we also drop this?). Dirk > -----Original Message----- > From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 > Sent: Wednesday, March 24, 2010 5:42 AM > To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen;=20 > Thomson, Martin; Richard Barnes; Bernard Aboba > Cc: emu@ietf.org; ecrit@ietf.org > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial=20 > of serviceattacks on the emergency.com domain) >=20 >=20 > Hi Dirk, >=20 > > I do not see a value in such recommendation from IETF would be.=20 > > For layer-2 flags these organizations define such flags. They know. >=20 > SDOs set their own agendas; that's fair enough. They don't=20 > always want to consider how their architectures interwork=20 > with specifications defined by, say, the IETF. So perhaps, as=20 > you say, it's pointless. While ECRIT procedures are at the IP=20 > level and are intended to support clients that are connecting=20 > on IP via a routing device at the access, a "link technology=20 > SDO" may still persist with the assumption that it's the=20 > connecting device that negotiates procedures in an emergency=20 > scenario. Alternatively, they may consider the ECRIT model=20 > and decide to do something different. It is, as you say, up to them. >=20 > > What flag are you refering to? Up to now we were only=20 > discussing options > > to indicate emergency in EAP, which rather on top of=20 > layer-2 than IP. >=20 > Which, if I understand it, is about negotiating an IP context=20 > in what is also an "emergency context". Leaving aside my=20 > point above as to whether that's a generally effective=20 > facility for supporting emergency connectivity, there's also=20 > the question (which I may be unfairly be attributing to=20 > Richard) as to what value it is to the access to know that=20 > this connectivity has been granted in an "emergency context".=20 > What's it going to do with this alleged context? >=20 > > Without a full subscription (either insufficient authorization or no > > subscription) you may want to enter the NW for other things than > > emergency. So would you always hotline these entrants to the PSAP? >=20 > No - you wouldn't. But, then, the concept of "hotlining the=20 > entrant to a PSAP" refers to a procedure that isn't described=20 > by ECRIT. There's no "hotlining". The device knows it wants=20 > to initiate an emergency call; it gets location from the LIS,=20 > gets the PSAP URI from LoST, and initiates a SIP session to=20 > the PSAP. The proposition of "hotlining" based on a layer 2=20 > technology specific procedure is the sort of thing I refer to=20 > above. An access technology specific SDO may, for their own=20 > reasons, decide to define this sort of thing. I think they're=20 > talking about use cases that are orthogonal to what ECRIT is=20 > describing. ECRIT describes emergency procedures for the=20 > Internet, on IP, and independent of access technology. >=20 > I guess the extent to which an SDO thinks these things are=20 > worth developing depends on the extent to which they think a)=20 > ECRIT is not a significant model or to which b) they think=20 > there are "emergency" use cases that are outside the Internet=20 > domain or to which c) there is some complementary subset of=20 > use cases for their link technology (e.g. WiFi phones in an=20 > enterprise environment with an "emergency" button that set up=20 > an emergency IP context and are hotlined to the enterprise=20 > softswitch that then does ECRIT procedures to the outside=20 > world). The SDO just needs to decide whether there is a=20 > benefit consistent with the effort in defining/implementing=20 > such functionality. I think it's good if their delegates are=20 > aware of ECRIT in making that decision. >=20 > Cheers, > Martin >=20 > -----Original Message----- > From: Kroeselberg, Dirk (NSN - DE/Munich)=20 > [mailto:dirk.kroeselberg@nsn.com]=20 > Sent: Wednesday, 24 March 2010 2:12 PM > To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard=20 > Barnes; Bernard Aboba > Cc: emu@ietf.org; ecrit@ietf.org > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial=20 > of serviceattacks on the emergency.com domain) >=20 > see inline. >=20 > Dirk=20 >=20 > > -----Original Message----- > > From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 > > Sent: Wednesday, March 24, 2010 2:15 AM > > To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen;=20 > > Thomson, Martin; Richard Barnes; Bernard Aboba > > Cc: emu@ietf.org; ecrit@ietf.org > > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial=20 > > of serviceattacks on the emergency.com domain) > >=20 > > Consider the access out of scope, certainly. Recommend to=20 > > access-specific forums that they shouldn't *assume* the=20 > > connecting device is actually the device making the emergency=20 > > call (e.g. a WiFi device on a portable 3G router) so there's=20 > > no reliable assumption the connecting device can provide an=20 > > emergency flag. >=20 > I do not see a value in such recommendation from IETF would be.=20 > For layer-2 flags these organizations define such flags. They know. > =20 > > Then it's whatever ECRIT might recommend as appropriate on=20 > > top of IP. I think Richard's questions are along the line of=20 > > what the value of this specific "emergency flag" is at the IP=20 > > level.=20 > What flag are you refering to? Up to now we were only=20 > discussing options > to indicate emergency in EAP, which rather on top of layer-2 than IP. >=20 > It's not like anyone but the device user knows whether=20 > > the access really is only required for emergency purposes.=20 > > It's a valid question; access policy may just be to bar or=20 > > allow (depending on whether it's a prohibitive or a=20 > > permissive policy) access to emergency specific things - such=20 > > as routes to PSAPs. A flag is not necessarily required to=20 > > apply that sort of policy. > Without a full subscription (either insufficient authorization or no > subscription) you may want to enter the NW for other things than > emergency. So would you always hotline these entrants to the PSAP? >=20 > >=20 > > Cheers, > > Martin > >=20 > > -----Original Message----- > > From: Kroeselberg, Dirk (NSN - DE/Munich)=20 > > [mailto:dirk.kroeselberg@nsn.com]=20 > > Sent: Wednesday, 24 March 2010 10:14 AM > > To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard=20 > > Barnes; Bernard Aboba > > Cc: emu@ietf.org; ecrit@ietf.org > > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial=20 > > of serviceattacks on the emergency.com domain) > >=20 > > > So - it's more the domain of the IEEE, 3GPP, WiFi Alliance,=20 > > > the DSL forum, etc. as to how a device is able to get an=20 > > > unauthenticated IP context on their technology, for whatever=20 > > > purpose, before the policies on permitting/prohibiting ECRIT =20 > >=20 > > but what is the concrete recommendation that you want to give here? > >=20 > > - Drop the access/ISP part from the draft and say access/ISP is > > out-of-scope? > > - move this to EMU? > > - or deal with the EAP/NAI related aspects outside IETF as=20 > you seem to > > suggest (which is already partially the case today due to lack of > > guidance)? > >=20 > > > is on others. I doubt that there's a reasonable assumption=20 > > > that the connecting device can necessarily provide an=20 > > > explicit "emergency intent" flag. > > maybe this is why some people do this via the NAI ;-) > >=20 > > Dirk > >=20 > >=20 > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > > > On Behalf Of ext Dawson, Martin > > > Sent: Tuesday, March 23, 2010 11:44 PM > > > To: Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba > > > Cc: emu@ietf.org; ecrit@ietf.org > > > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial=20 > > > of serviceattacks on the emergency.com domain) > > >=20 > > > To elaborate on Brian's "counter point" - some jurisdictions=20 > > > may prefer to *forbid* access to the emergency service from=20 > > > unauthenticated/anonymous access as opposed to *require* it=20 > > > to be supported. Noting this is the equivalent of saying=20 > > > emergency calls for circuit service cannot be made from=20 > > > public phone booths; this is still a possible policy within a=20 > > > given jurisdiction. > > >=20 > > > I'd also posit that not only is it not a priority for IETF=20 > > > but that the question actually needs to be dealt with in more=20 > > > specific forums first. The ECRIT emergency procedures occur=20 > > > at or above the IP layer. Before anything that ECRIT=20 > > > describes becomes relevant, there needs to be an IP context. > > >=20 > > > So - it's more the domain of the IEEE, 3GPP, WiFi Alliance,=20 > > > the DSL forum, etc. as to how a device is able to get an=20 > > > unauthenticated IP context on their technology, for whatever=20 > > > purpose, before the policies on permitting/prohibiting ECRIT=20 > > > procedures or anything else that can be done on IP can be=20 > > > applied. This is easier on some access technologies than it=20 > > > is on others. I doubt that there's a reasonable assumption=20 > > > that the connecting device can necessarily provide an=20 > > > explicit "emergency intent" flag. > > >=20 > > > Cheers, > > > Martin > > >=20 > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > > > On Behalf Of Brian Rosen > > > Sent: Wednesday, 24 March 2010 8:29 AM > > > To: Thomson, Martin; Richard Barnes; Bernard Aboba > > > Cc: emu@ietf.org; ecrit@ietf.org > > > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial=20 > > > of serviceattacks on the emergency.com domain) > > >=20 > > > I think the relevant part of this is 'it's not a high=20 > > > priority'. That is > > > policy of the work group, which we do have control over. > > >=20 > > > If we have nothing else more important to do, then by all=20 > > > means, let's waste > > > a ton of time on unauthenticated access. If we have other=20 > > work to do, > > > perhaps we could defer this. > > >=20 > > > I am not the chair, but in general, anyone can discuss=20 > > > anything, regardless > > > of "priority" on the list. However, when it comes to=20 > > > adopting work group > > > items, I think this should be way down our list. > > >=20 > > > I might also suggest that unauthenticated access really isn't=20 > > > within the > > > charter of the work group. It may be that the reason=20 > > > unauthenticated access > > > may be needed is for emergency calling, but that means we may=20 > > > (eventually) > > > need to ask some other work group to do work for a=20 > > > requirement we generate. > > > It would seem that dealing with EAP is not within the domain=20 > > > of this work > > > group. > > >=20 > > > Brian > > >=20 > > >=20 > > > On 3/23/10 5:14 PM, "Thomson, Martin"=20 > > > <Martin.Thomson@andrew.com> wrote: > > >=20 > > > >> A large percentage (in fact an overwhelming percentage) of=20 > > > PSAPs DON'T > > > >> WANT > > > >> unauthenticated access. Their position is that they=20 > have lots of > > > >> relevant > > > >> experience, and its all bad (tens of thousands of calls=20 > > > with no good > > > >> ones in > > > >> some cases). > > > >>=20 > > > >> However, there are some PSAPs who want it, and there are some > > > >> regulatory > > > >> environments where there are some lawyers who think it's=20 > > > required to > > > >> support > > > >> it in some environments. > > > >=20 > > > > The good thing is: we don't set policy here. I'm not=20 > > > seeing sufficient > > > > evidence that _everyone_ doesn't want this, only that some=20 > > > don't want this. > > > >=20 > > > > I can't comment on priority. That would be policy too. > > > >=20 > > > > --Martin > > >=20 > > >=20 > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > >=20 > >=20 >=20 From Martin.Dawson@andrew.com Wed Mar 24 19:16:03 2010 Return-Path: <Martin.Dawson@andrew.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63B2C3A6A81; Wed, 24 Mar 2010 19:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.261 X-Spam-Level: * X-Spam-Status: No, score=1.261 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 TTY9AuqXOt-1; Wed, 24 Mar 2010 19:15:50 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 6B9073A6BF8; Wed, 24 Mar 2010 19:15:43 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:23693 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S15494191Ab0CYCQE convert rfc822-to-8bit (ORCPT <rfc822;emu@ietf.org> + 1 other); Wed, 24 Mar 2010 21:16:04 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 24 Mar 2010 21:16:04 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Thu, 25 Mar 2010 10:16:01 +0800 From: "Dawson, Martin" <Martin.Dawson@andrew.com> To: "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com> Date: Thu, 25 Mar 2010 10:15:59 +0800 Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrKzRfOc6w4ZPWsrkimclW4dAPFuwAAHhnQAACVA9cAAQknQAACQEEAAAQ84AAABDcxsAACUHmQABfrbWAAFZ7x4A== Message-ID: <8B0A9FCBB9832F43971E38010638454F03E24ED22E@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03E24ED000@SISPE7MB1.commscope.com><C7CEAAED.2AF6F%br@brianrosen.net> <8B0A9FCBB9832F43971E38010638454F03E24ED009@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB904@DEMUEXC030.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03E24ED048@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB920@DEMUEXC030.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03E24ED0A9@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DBEDB@DEMUEXC030.nsn-intra.net> In-Reply-To: <8C51C7A529FC9D49843ACF5AE2FFBF67025DBEDB@DEMUEXC030.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Cc: "emu@ietf.org" <emu@ietf.org>, "ecrit@ietf.org" <ecrit@ietf.org> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 25 Mar 2010 02:16:03 -0000 I'll describe a potential real world scenario before I try to answer your question. * Public WiFi hotspots generally provide a "free unauthenticated and anonymous" IP context. * Once connected to the access, users are generally "portal locked" to a single web page that requires further authentication/payment to proceed. The access may provide some additional "filters" that allow routes to some subset of news/commercial websites as a "bonus". * In order to support unauthenticated/anonymous emergency calling at this point, the hotspot would need to add the location service, access to LoST, and a route to the relevant PSAP URI(s) to the filter list. The question I raise is what would be done differently if the connecting device *could* have provided an indication that it wanted the connection for the purpose an emergency call? I don't think anything needs to be done differently. I don't, for example, think there's any prioritization benefit. An "emergency" type query to the LCP (HELD option), an emergency service lookup to LoST, and a SIP session directed toward a PSAP URI are all things that could be explicitly detected and given priority. Priority isn't an end-goal in itself in any case. The end goal is reliability and response time for these emergency related services. The access provider may need to ensure some service level there. They can do that without needing to roll dice. And, given they can neither rely on devices to provide an emergency indication nor trust that indication if they do, they are likely better off providing the necessary service level for emergency procedures independently of the device's broadc asted intentions. Let me say that I think the draft is great; it crystallizes a lot of issues. I just think the section on EAP isn't necessary; it doesn't describe a generally applicable solution and its presence is likely to cause confusion as to its significance. In answer to your question; no, I don't suggest dropping the discussion on filters. I think that's a fundamental aspect; I think it's orthogonal to the concept of an "emergency intent indicator". Cheers, Martin -----Original Message----- From: Kroeselberg, Dirk (NSN - DE/Munich) [mailto:dirk.kroeselberg@nsn.com] Sent: Thursday, 25 March 2010 2:46 AM To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba Cc: emu@ietf.org; ecrit@ietf.org Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) > facility for supporting emergency connectivity, there's also > the question (which I may be unfairly be attributing to > Richard) as to what value it is to the access to know that > this connectivity has been granted in an "emergency context". > What's it going to do with this alleged context? Considering this in authorization decisions, QoS, setting IP filters (limited access), priority. Just to give a few examples. > No - you wouldn't. But, then, the concept of "hotlining the > entrant to a PSAP" refers to a procedure that isn't described > by ECRIT. There's no "hotlining". The device knows it wants Right, but I was saying it is important for the access network to recognize that the 'special' entry the MS wants to do is for emergency, not let the access network roll dices. Of course hotlining procedures are not in scope of ECRIT, there is nothing emergency-specific besides installing the right filters (which by the way we also discuss in the draft - should we also drop this?). Dirk > -----Original Message----- > From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Wednesday, March 24, 2010 5:42 AM > To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen; > Thomson, Martin; Richard Barnes; Bernard Aboba > Cc: emu@ietf.org; ecrit@ietf.org > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial > of serviceattacks on the emergency.com domain) > > > Hi Dirk, > > > I do not see a value in such recommendation from IETF would be. > > For layer-2 flags these organizations define such flags. They know. > > SDOs set their own agendas; that's fair enough. They don't > always want to consider how their architectures interwork > with specifications defined by, say, the IETF. So perhaps, as > you say, it's pointless. While ECRIT procedures are at the IP > level and are intended to support clients that are connecting > on IP via a routing device at the access, a "link technology > SDO" may still persist with the assumption that it's the > connecting device that negotiates procedures in an emergency > scenario. Alternatively, they may consider the ECRIT model > and decide to do something different. It is, as you say, up to them. > > > What flag are you refering to? Up to now we were only > discussing options > > to indicate emergency in EAP, which rather on top of > layer-2 than IP. > > Which, if I understand it, is about negotiating an IP context > in what is also an "emergency context". Leaving aside my > point above as to whether that's a generally effective > facility for supporting emergency connectivity, there's also > the question (which I may be unfairly be attributing to > Richard) as to what value it is to the access to know that > this connectivity has been granted in an "emergency context". > What's it going to do with this alleged context? > > > Without a full subscription (either insufficient authorization or no > > subscription) you may want to enter the NW for other things than > > emergency. So would you always hotline these entrants to the PSAP? > > No - you wouldn't. But, then, the concept of "hotlining the > entrant to a PSAP" refers to a procedure that isn't described > by ECRIT. There's no "hotlining". The device knows it wants > to initiate an emergency call; it gets location from the LIS, > gets the PSAP URI from LoST, and initiates a SIP session to > the PSAP. The proposition of "hotlining" based on a layer 2 > technology specific procedure is the sort of thing I refer to > above. An access technology specific SDO may, for their own > reasons, decide to define this sort of thing. I think they're > talking about use cases that are orthogonal to what ECRIT is > describing. ECRIT describes emergency procedures for the > Internet, on IP, and independent of access technology. > > I guess the extent to which an SDO thinks these things are > worth developing depends on the extent to which they think a) > ECRIT is not a significant model or to which b) they think > there are "emergency" use cases that are outside the Internet > domain or to which c) there is some complementary subset of > use cases for their link technology (e.g. WiFi phones in an > enterprise environment with an "emergency" button that set up > an emergency IP context and are hotlined to the enterprise > softswitch that then does ECRIT procedures to the outside > world). The SDO just needs to decide whether there is a > benefit consistent with the effort in defining/implementing > such functionality. I think it's good if their delegates are > aware of ECRIT in making that decision. > > Cheers, > Martin > > -----Original Message----- > From: Kroeselberg, Dirk (NSN - DE/Munich) > [mailto:dirk.kroeselberg@nsn.com] > Sent: Wednesday, 24 March 2010 2:12 PM > To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard > Barnes; Bernard Aboba > Cc: emu@ietf.org; ecrit@ietf.org > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial > of serviceattacks on the emergency.com domain) > > see inline. > > Dirk > > > -----Original Message----- > > From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Wednesday, March 24, 2010 2:15 AM > > To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen; > > Thomson, Martin; Richard Barnes; Bernard Aboba > > Cc: emu@ietf.org; ecrit@ietf.org > > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial > > of serviceattacks on the emergency.com domain) > > > > Consider the access out of scope, certainly. Recommend to > > access-specific forums that they shouldn't *assume* the > > connecting device is actually the device making the emergency > > call (e.g. a WiFi device on a portable 3G router) so there's > > no reliable assumption the connecting device can provide an > > emergency flag. > > I do not see a value in such recommendation from IETF would be. > For layer-2 flags these organizations define such flags. They know. > > > Then it's whatever ECRIT might recommend as appropriate on > > top of IP. I think Richard's questions are along the line of > > what the value of this specific "emergency flag" is at the IP > > level. > What flag are you refering to? Up to now we were only > discussing options > to indicate emergency in EAP, which rather on top of layer-2 than IP. > > It's not like anyone but the device user knows whether > > the access really is only required for emergency purposes. > > It's a valid question; access policy may just be to bar or > > allow (depending on whether it's a prohibitive or a > > permissive policy) access to emergency specific things - such > > as routes to PSAPs. A flag is not necessarily required to > > apply that sort of policy. > Without a full subscription (either insufficient authorization or no > subscription) you may want to enter the NW for other things than > emergency. So would you always hotline these entrants to the PSAP? > > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Kroeselberg, Dirk (NSN - DE/Munich) > > [mailto:dirk.kroeselberg@nsn.com] > > Sent: Wednesday, 24 March 2010 10:14 AM > > To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard > > Barnes; Bernard Aboba > > Cc: emu@ietf.org; ecrit@ietf.org > > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial > > of serviceattacks on the emergency.com domain) > > > > > So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, > > > the DSL forum, etc. as to how a device is able to get an > > > unauthenticated IP context on their technology, for whatever > > > purpose, before the policies on permitting/prohibiting ECRIT > > > > but what is the concrete recommendation that you want to give here? > > > > - Drop the access/ISP part from the draft and say access/ISP is > > out-of-scope? > > - move this to EMU? > > - or deal with the EAP/NAI related aspects outside IETF as > you seem to > > suggest (which is already partially the case today due to lack of > > guidance)? > > > > > is on others. I doubt that there's a reasonable assumption > > > that the connecting device can necessarily provide an > > > explicit "emergency intent" flag. > > maybe this is why some people do this via the NAI ;-) > > > > Dirk > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > > On Behalf Of ext Dawson, Martin > > > Sent: Tuesday, March 23, 2010 11:44 PM > > > To: Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba > > > Cc: emu@ietf.org; ecrit@ietf.org > > > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial > > > of serviceattacks on the emergency.com domain) > > > > > > To elaborate on Brian's "counter point" - some jurisdictions > > > may prefer to *forbid* access to the emergency service from > > > unauthenticated/anonymous access as opposed to *require* it > > > to be supported. Noting this is the equivalent of saying > > > emergency calls for circuit service cannot be made from > > > public phone booths; this is still a possible policy within a > > > given jurisdiction. > > > > > > I'd also posit that not only is it not a priority for IETF > > > but that the question actually needs to be dealt with in more > > > specific forums first. The ECRIT emergency procedures occur > > > at or above the IP layer. Before anything that ECRIT > > > describes becomes relevant, there needs to be an IP context. > > > > > > So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, > > > the DSL forum, etc. as to how a device is able to get an > > > unauthenticated IP context on their technology, for whatever > > > purpose, before the policies on permitting/prohibiting ECRIT > > > procedures or anything else that can be done on IP can be > > > applied. This is easier on some access technologies than it > > > is on others. I doubt that there's a reasonable assumption > > > that the connecting device can necessarily provide an > > > explicit "emergency intent" flag. > > > > > > Cheers, > > > Martin > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > > On Behalf Of Brian Rosen > > > Sent: Wednesday, 24 March 2010 8:29 AM > > > To: Thomson, Martin; Richard Barnes; Bernard Aboba > > > Cc: emu@ietf.org; ecrit@ietf.org > > > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial > > > of serviceattacks on the emergency.com domain) > > > > > > I think the relevant part of this is 'it's not a high > > > priority'. That is > > > policy of the work group, which we do have control over. > > > > > > If we have nothing else more important to do, then by all > > > means, let's waste > > > a ton of time on unauthenticated access. If we have other > > work to do, > > > perhaps we could defer this. > > > > > > I am not the chair, but in general, anyone can discuss > > > anything, regardless > > > of "priority" on the list. However, when it comes to > > > adopting work group > > > items, I think this should be way down our list. > > > > > > I might also suggest that unauthenticated access really isn't > > > within the > > > charter of the work group. It may be that the reason > > > unauthenticated access > > > may be needed is for emergency calling, but that means we may > > > (eventually) > > > need to ask some other work group to do work for a > > > requirement we generate. > > > It would seem that dealing with EAP is not within the domain > > > of this work > > > group. > > > > > > Brian > > > > > > > > > On 3/23/10 5:14 PM, "Thomson, Martin" > > > <Martin.Thomson@andrew.com> wrote: > > > > > > >> A large percentage (in fact an overwhelming percentage) of > > > PSAPs DON'T > > > >> WANT > > > >> unauthenticated access. Their position is that they > have lots of > > > >> relevant > > > >> experience, and its all bad (tens of thousands of calls > > > with no good > > > >> ones in > > > >> some cases). > > > >> > > > >> However, there are some PSAPs who want it, and there are some > > > >> regulatory > > > >> environments where there are some lawyers who think it's > > > required to > > > >> support > > > >> it in some environments. > > > > > > > > The good thing is: we don't set policy here. I'm not > > > seeing sufficient > > > > evidence that _everyone_ doesn't want this, only that some > > > don't want this. > > > > > > > > I can't comment on priority. That would be policy too. > > > > > > > > --Martin > > > > > > > > > _______________________________________________ > > > 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 dirk.kroeselberg@nsn.com Wed Mar 24 21:02:03 2010 Return-Path: <dirk.kroeselberg@nsn.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39AF43A69A8; Wed, 24 Mar 2010 21:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 4pzbu09aPUVR; Wed, 24 Mar 2010 21:02:01 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 553643A6903; Wed, 24 Mar 2010 21:02:00 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2P42G6P010918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 Mar 2010 05:02:16 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2P42GVK016355; Thu, 25 Mar 2010 05:02:16 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Mar 2010 05:02:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Mar 2010 05:01:37 +0100 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF67025DBFDE@DEMUEXC030.nsn-intra.net> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E24ED22E@SISPE7MB1.commscope.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrKzRfOc6w4ZPWsrkimclW4dAPFuwAAHhnQAACVA9cAAQknQAACQEEAAAQ84AAABDcxsAACUHmQABfrbWAAFZ7x4AADZ0uw References: <8B0A9FCBB9832F43971E38010638454F03E24ED000@SISPE7MB1.commscope.com><C7CEAAED.2AF6F%br@brianrosen.net> <8B0A9FCBB9832F43971E38010638454F03E24ED009@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB904@DEMUEXC030.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03E24ED048@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB920@DEMUEXC030.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03E24ED0A9@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DBEDB@DEMUEXC030.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03E24ED22E@SISPE7MB1.commscope.com> From: "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com> To: "ext Dawson, Martin" <Martin.Dawson@andrew.com> X-OriginalArrivalTime: 25 Mar 2010 04:02:16.0316 (UTC) FILETIME=[F5090BC0:01CACBCF] Cc: emu@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 25 Mar 2010 04:02:03 -0000 there is no EAP in your scenario as this is open WiFi, so of course any EAP-based emergency indicator would not apply to it. However, there are other scenarios. So what you are basically saying with your example is that network access authentication is only based on EAP for certain scenarios. Sure, this is correct (not sure whether this is clear in the draft, I will check). For open WiFi access we can only provide high-level guidance like the one you describe below.=20 For EAP this can be more specific, if something is agreeable. If not, fine. However, looking at this whole thread, it makes much sense to me to adjust and keep the section instead of not capturing the whole discussion.=20 What is probably missing at the moment are figures that clarify the relation between access/ISP and VSP/ASP for unauthenticated and unauthorized cases. We are planning to add such figures. Dirk=20 > -----Original Message----- > From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 > Sent: Thursday, March 25, 2010 3:16 AM > To: Kroeselberg, Dirk (NSN - DE/Munich) > Cc: emu@ietf.org; ecrit@ietf.org > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial=20 > of serviceattacks on the emergency.com domain) >=20 > I'll describe a potential real world scenario before I try to=20 > answer your question. >=20 > * Public WiFi hotspots generally provide a "free=20 > unauthenticated and anonymous" IP context. >=20 > * Once connected to the access, users are generally "portal=20 > locked" to a single web page that requires further=20 > authentication/payment to proceed. The access may provide=20 > some additional "filters" that allow routes to some subset of=20 > news/commercial websites as a "bonus". >=20 > * In order to support unauthenticated/anonymous emergency=20 > calling at this point, the hotspot would need to add the=20 > location service, access to LoST, and a route to the relevant=20 > PSAP URI(s) to the filter list. >=20 > The question I raise is what would be done differently if the=20 > connecting device *could* have provided an indication that it=20 > wanted the connection for the purpose an emergency call? I=20 > don't think anything needs to be done differently. I don't,=20 > for example, think there's any prioritization benefit. An=20 > "emergency" type query to the LCP (HELD option), an emergency=20 > service lookup to LoST, and a SIP session directed toward a=20 > PSAP URI are all things that could be explicitly detected and=20 > given priority. Priority isn't an end-goal in itself in any=20 > case. The end goal is reliability and response time for these=20 > emergency related services. The access provider may need to=20 > ensure some service level there. They can do that without=20 > needing to roll dice. And, given they can neither rely on=20 > devices to provide an emergency indication nor trust that=20 > indication if they do, they are likely better off providing=20 > the necessary service level for emergency procedures=20 > independently of the device's broadcasted intentions. >=20 > Let me say that I think the draft is great; it crystallizes a=20 > lot of issues. I just think the section on EAP isn't=20 > necessary; it doesn't describe a generally applicable=20 > solution and its presence is likely to cause confusion as to=20 > its significance. In answer to your question; no, I don't=20 > suggest dropping the discussion on filters. I think that's a=20 > fundamental aspect; I think it's orthogonal to the concept of=20 > an "emergency intent indicator". >=20 > Cheers, > Martin >=20 >=20 >=20 > -----Original Message----- > From: Kroeselberg, Dirk (NSN - DE/Munich)=20 > [mailto:dirk.kroeselberg@nsn.com] > Sent: Thursday, 25 March 2010 2:46 AM > To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard=20 > Barnes; Bernard Aboba > Cc: emu@ietf.org; ecrit@ietf.org > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial=20 > of serviceattacks on the emergency.com domain) >=20 > > facility for supporting emergency connectivity, there's also > > the question (which I may be unfairly be attributing to > > Richard) as to what value it is to the access to know that > > this connectivity has been granted in an "emergency context". > > What's it going to do with this alleged context? >=20 > Considering this in authorization decisions, QoS, setting IP filters > (limited access), priority. Just to give a few examples. >=20 > > No - you wouldn't. But, then, the concept of "hotlining the > > entrant to a PSAP" refers to a procedure that isn't described > > by ECRIT. There's no "hotlining". The device knows it wants >=20 > Right, but I was saying it is important for the access network to > recognize that the 'special' entry the MS wants to do is for=20 > emergency, > not let the access network roll dices. > Of course hotlining procedures are not in scope of ECRIT, there is > nothing emergency-specific besides installing the right filters (which > by the way we also discuss in the draft - should we also drop this?). >=20 > Dirk >=20 > > -----Original Message----- > > From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Wednesday, March 24, 2010 5:42 AM > > To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen; > > Thomson, Martin; Richard Barnes; Bernard Aboba > > Cc: emu@ietf.org; ecrit@ietf.org > > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial > > of serviceattacks on the emergency.com domain) > > > > > > Hi Dirk, > > > > > I do not see a value in such recommendation from IETF would be. > > > For layer-2 flags these organizations define such flags.=20 > They know. > > > > SDOs set their own agendas; that's fair enough. They don't > > always want to consider how their architectures interwork > > with specifications defined by, say, the IETF. So perhaps, as > > you say, it's pointless. While ECRIT procedures are at the IP > > level and are intended to support clients that are connecting > > on IP via a routing device at the access, a "link technology > > SDO" may still persist with the assumption that it's the > > connecting device that negotiates procedures in an emergency > > scenario. Alternatively, they may consider the ECRIT model > > and decide to do something different. It is, as you say, up to them. > > > > > What flag are you refering to? Up to now we were only > > discussing options > > > to indicate emergency in EAP, which rather on top of > > layer-2 than IP. > > > > Which, if I understand it, is about negotiating an IP context > > in what is also an "emergency context". Leaving aside my > > point above as to whether that's a generally effective > > facility for supporting emergency connectivity, there's also > > the question (which I may be unfairly be attributing to > > Richard) as to what value it is to the access to know that > > this connectivity has been granted in an "emergency context". > > What's it going to do with this alleged context? > > > > > Without a full subscription (either insufficient=20 > authorization or no > > > subscription) you may want to enter the NW for other things than > > > emergency. So would you always hotline these entrants to the PSAP? > > > > No - you wouldn't. But, then, the concept of "hotlining the > > entrant to a PSAP" refers to a procedure that isn't described > > by ECRIT. There's no "hotlining". The device knows it wants > > to initiate an emergency call; it gets location from the LIS, > > gets the PSAP URI from LoST, and initiates a SIP session to > > the PSAP. The proposition of "hotlining" based on a layer 2 > > technology specific procedure is the sort of thing I refer to > > above. An access technology specific SDO may, for their own > > reasons, decide to define this sort of thing. I think they're > > talking about use cases that are orthogonal to what ECRIT is > > describing. ECRIT describes emergency procedures for the > > Internet, on IP, and independent of access technology. > > > > I guess the extent to which an SDO thinks these things are > > worth developing depends on the extent to which they think a) > > ECRIT is not a significant model or to which b) they think > > there are "emergency" use cases that are outside the Internet > > domain or to which c) there is some complementary subset of > > use cases for their link technology (e.g. WiFi phones in an > > enterprise environment with an "emergency" button that set up > > an emergency IP context and are hotlined to the enterprise > > softswitch that then does ECRIT procedures to the outside > > world). The SDO just needs to decide whether there is a > > benefit consistent with the effort in defining/implementing > > such functionality. I think it's good if their delegates are > > aware of ECRIT in making that decision. > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Kroeselberg, Dirk (NSN - DE/Munich) > > [mailto:dirk.kroeselberg@nsn.com] > > Sent: Wednesday, 24 March 2010 2:12 PM > > To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard > > Barnes; Bernard Aboba > > Cc: emu@ietf.org; ecrit@ietf.org > > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial > > of serviceattacks on the emergency.com domain) > > > > see inline. > > > > Dirk > > > > > -----Original Message----- > > > From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > Sent: Wednesday, March 24, 2010 2:15 AM > > > To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen; > > > Thomson, Martin; Richard Barnes; Bernard Aboba > > > Cc: emu@ietf.org; ecrit@ietf.org > > > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial > > > of serviceattacks on the emergency.com domain) > > > > > > Consider the access out of scope, certainly. Recommend to > > > access-specific forums that they shouldn't *assume* the > > > connecting device is actually the device making the emergency > > > call (e.g. a WiFi device on a portable 3G router) so there's > > > no reliable assumption the connecting device can provide an > > > emergency flag. > > > > I do not see a value in such recommendation from IETF would be. > > For layer-2 flags these organizations define such flags. They know. > > > > > Then it's whatever ECRIT might recommend as appropriate on > > > top of IP. I think Richard's questions are along the line of > > > what the value of this specific "emergency flag" is at the IP > > > level. > > What flag are you refering to? Up to now we were only > > discussing options > > to indicate emergency in EAP, which rather on top of=20 > layer-2 than IP. > > > > It's not like anyone but the device user knows whether > > > the access really is only required for emergency purposes. > > > It's a valid question; access policy may just be to bar or > > > allow (depending on whether it's a prohibitive or a > > > permissive policy) access to emergency specific things - such > > > as routes to PSAPs. A flag is not necessarily required to > > > apply that sort of policy. > > Without a full subscription (either insufficient authorization or no > > subscription) you may want to enter the NW for other things than > > emergency. So would you always hotline these entrants to the PSAP? > > > > > > > > Cheers, > > > Martin > > > > > > -----Original Message----- > > > From: Kroeselberg, Dirk (NSN - DE/Munich) > > > [mailto:dirk.kroeselberg@nsn.com] > > > Sent: Wednesday, 24 March 2010 10:14 AM > > > To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard > > > Barnes; Bernard Aboba > > > Cc: emu@ietf.org; ecrit@ietf.org > > > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial > > > of serviceattacks on the emergency.com domain) > > > > > > > So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, > > > > the DSL forum, etc. as to how a device is able to get an > > > > unauthenticated IP context on their technology, for whatever > > > > purpose, before the policies on permitting/prohibiting ECRIT > > > > > > but what is the concrete recommendation that you want to=20 > give here? > > > > > > - Drop the access/ISP part from the draft and say access/ISP is > > > out-of-scope? > > > - move this to EMU? > > > - or deal with the EAP/NAI related aspects outside IETF as > > you seem to > > > suggest (which is already partially the case today due to lack of > > > guidance)? > > > > > > > is on others. I doubt that there's a reasonable assumption > > > > that the connecting device can necessarily provide an > > > > explicit "emergency intent" flag. > > > maybe this is why some people do this via the NAI ;-) > > > > > > Dirk > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > > > On Behalf Of ext Dawson, Martin > > > > Sent: Tuesday, March 23, 2010 11:44 PM > > > > To: Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba > > > > Cc: emu@ietf.org; ecrit@ietf.org > > > > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial > > > > of serviceattacks on the emergency.com domain) > > > > > > > > To elaborate on Brian's "counter point" - some jurisdictions > > > > may prefer to *forbid* access to the emergency service from > > > > unauthenticated/anonymous access as opposed to *require* it > > > > to be supported. Noting this is the equivalent of saying > > > > emergency calls for circuit service cannot be made from > > > > public phone booths; this is still a possible policy within a > > > > given jurisdiction. > > > > > > > > I'd also posit that not only is it not a priority for IETF > > > > but that the question actually needs to be dealt with in more > > > > specific forums first. The ECRIT emergency procedures occur > > > > at or above the IP layer. Before anything that ECRIT > > > > describes becomes relevant, there needs to be an IP context. > > > > > > > > So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, > > > > the DSL forum, etc. as to how a device is able to get an > > > > unauthenticated IP context on their technology, for whatever > > > > purpose, before the policies on permitting/prohibiting ECRIT > > > > procedures or anything else that can be done on IP can be > > > > applied. This is easier on some access technologies than it > > > > is on others. I doubt that there's a reasonable assumption > > > > that the connecting device can necessarily provide an > > > > explicit "emergency intent" flag. > > > > > > > > Cheers, > > > > Martin > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > > > On Behalf Of Brian Rosen > > > > Sent: Wednesday, 24 March 2010 8:29 AM > > > > To: Thomson, Martin; Richard Barnes; Bernard Aboba > > > > Cc: emu@ietf.org; ecrit@ietf.org > > > > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial > > > > of serviceattacks on the emergency.com domain) > > > > > > > > I think the relevant part of this is 'it's not a high > > > > priority'. That is > > > > policy of the work group, which we do have control over. > > > > > > > > If we have nothing else more important to do, then by all > > > > means, let's waste > > > > a ton of time on unauthenticated access. If we have other > > > work to do, > > > > perhaps we could defer this. > > > > > > > > I am not the chair, but in general, anyone can discuss > > > > anything, regardless > > > > of "priority" on the list. However, when it comes to > > > > adopting work group > > > > items, I think this should be way down our list. > > > > > > > > I might also suggest that unauthenticated access really isn't > > > > within the > > > > charter of the work group. It may be that the reason > > > > unauthenticated access > > > > may be needed is for emergency calling, but that means we may > > > > (eventually) > > > > need to ask some other work group to do work for a > > > > requirement we generate. > > > > It would seem that dealing with EAP is not within the domain > > > > of this work > > > > group. > > > > > > > > Brian > > > > > > > > > > > > On 3/23/10 5:14 PM, "Thomson, Martin" > > > > <Martin.Thomson@andrew.com> wrote: > > > > > > > > >> A large percentage (in fact an overwhelming percentage) of > > > > PSAPs DON'T > > > > >> WANT > > > > >> unauthenticated access. Their position is that they > > have lots of > > > > >> relevant > > > > >> experience, and its all bad (tens of thousands of calls > > > > with no good > > > > >> ones in > > > > >> some cases). > > > > >> > > > > >> However, there are some PSAPs who want it, and there are some > > > > >> regulatory > > > > >> environments where there are some lawyers who think it's > > > > required to > > > > >> support > > > > >> it in some environments. > > > > > > > > > > The good thing is: we don't set policy here. I'm not > > > > seeing sufficient > > > > > evidence that _everyone_ doesn't want this, only that some > > > > don't want this. > > > > > > > > > > I can't comment on priority. That would be policy too. > > > > > > > > > > --Martin > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > >=20 From hgs@cs.columbia.edu Thu Mar 25 08:47:46 2010 Return-Path: <hgs@cs.columbia.edu> 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 64D703A679C; Thu, 25 Mar 2010 08:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_50=0.001, DATE_IN_PAST_12_24=0.992, DNS_FROM_OPENWHOIS=1.13, 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 j2uXFpahGMBW; Thu, 25 Mar 2010 08:47:44 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id EBAAF3A63C9; Thu, 25 Mar 2010 08:47:43 -0700 (PDT) Received: from dhcp-wireless-open-abg-26-78.meeting.ietf.org (dhcp-wireless-open-abg-26-78.meeting.ietf.org [130.129.26.78]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o2PFm05A015895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 25 Mar 2010 11:48:03 -0400 (EDT) References: <8B0A9FCBB9832F43971E38010638454F03E24ED000@SISPE7MB1.commscope.com><C7CEAAED.2AF6F%br@brianrosen.net> <8B0A9FCBB9832F43971E38010638454F03E24ED009@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB904@DEMUEXC030.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03E24ED048@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB920@DEMUEXC030.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03E24ED0A9@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DBEDB@DEMUEXC030.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03E24ED22E@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E24ED22E@SISPE7MB1.commscope.com> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: <4F292458-5122-4B4A-A572-995559D4D65C@cs.columbia.edu> Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne <hgs@cs.columbia.edu> Date: Wed, 24 Mar 2010 22:40:34 -0400 To: "Dawson, Martin" <Martin.Dawson@andrew.com> X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: "ecrit@ietf.org" <ecrit@ietf.org>, "emu@ietf.org" <emu@ietf.org> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 25 Mar 2010 15:47:47 -0000 With non-web devices, it's becoming more common to have 802.1x as a = second authentication option, beyond the splash page. (indeed, just = yesterday I got word that my employer is transitioning to this, and this = is how many, if not most, European universities work). The motivation is = that entering authentication data on some WiFi devices, such as digital = cameras or even smart phones, is painful. Thus, having a mode to bypass = normal 802.1x processes for emergency purposes can be quite useful. I don't think that this will be all that common immediately or even in = the next year or two, but there's no reason not to encourage such new = architectures if we believe they are useful for public safety. After = all, I thought our goal is to enable (legitimate) emergency calls, not = to prevent them. As proposed, the system would allow unrestricted access for emergency = purposes. I realize some have some difficulty fathoming why a provider = would do this, but the cost to the ISP (or campus, or hotel) is minimal, = so consider it the equivalent of providing pull boxes for fire alarms. I = consider it the equivalent of a "emergency exit only" sign - they are = abused rarely and there are processes in place to deal with abusers. You = don't fix the problem by putting a stronger lock in front of the = emergency exit. I guess you can consider it the "picket fence" theory of = security. The "sos" user ID is essentially a picket fence that will = allow socially useful behavior.=20 Henning On Mar 24, 2010, at 10:15 PM, Dawson, Martin wrote: > I'll describe a potential real world scenario before I try to answer = your question. >=20 > * Public WiFi hotspots generally provide a "free unauthenticated and = anonymous" IP context. >=20 > * Once connected to the access, users are generally "portal locked" to = a single web page that requires further authentication/payment to = proceed. The access may provide some additional "filters" that allow = routes to some subset of news/commercial websites as a "bonus". >=20 > * In order to support unauthenticated/anonymous emergency calling at = this point, the hotspot would need to add the location service, access = to LoST, and a route to the relevant PSAP URI(s) to the filter list. >=20 > The question I raise is what would be done differently if the = connecting device *could* have provided an indication that it wanted the = connection for the purpose an emergency call? I don't think anything = needs to be done differently. I don't, for example, think there's any = prioritization benefit. An "emergency" type query to the LCP (HELD = option), an emergency service lookup to LoST, and a SIP session directed = toward a PSAP URI are all things that could be explicitly detected and = given priority. Priority isn't an end-goal in itself in any case. The = end goal is reliability and response time for these emergency related = services. The access provider may need to ensure some service level = there. They can do that without needing to roll dice. And, given they = can neither rely on devices to provide an emergency indication nor trust = that indication if they do, they are likely better off providing the = necessary service level for emergency procedures independently of the = device's broadc > asted intentions. >=20 > Let me say that I think the draft is great; it crystallizes a lot of = issues. I just think the section on EAP isn't necessary; it doesn't = describe a generally applicable solution and its presence is likely to = cause confusion as to its significance. In answer to your question; no, = I don't suggest dropping the discussion on filters. I think that's a = fundamental aspect; I think it's orthogonal to the concept of an = "emergency intent indicator". >=20 > Cheers, > Martin >=20 >=20 >=20 > -----Original Message----- > From: Kroeselberg, Dirk (NSN - DE/Munich) = [mailto:dirk.kroeselberg@nsn.com] > Sent: Thursday, 25 March 2010 2:46 AM > To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; = Bernard Aboba > Cc: emu@ietf.org; ecrit@ietf.org > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of = serviceattacks on the emergency.com domain) >=20 >> facility for supporting emergency connectivity, there's also >> the question (which I may be unfairly be attributing to >> Richard) as to what value it is to the access to know that >> this connectivity has been granted in an "emergency context". >> What's it going to do with this alleged context? >=20 > Considering this in authorization decisions, QoS, setting IP filters > (limited access), priority. Just to give a few examples. >=20 >> No - you wouldn't. But, then, the concept of "hotlining the >> entrant to a PSAP" refers to a procedure that isn't described >> by ECRIT. There's no "hotlining". The device knows it wants >=20 > Right, but I was saying it is important for the access network to > recognize that the 'special' entry the MS wants to do is for = emergency, > not let the access network roll dices. > Of course hotlining procedures are not in scope of ECRIT, there is > nothing emergency-specific besides installing the right filters (which > by the way we also discuss in the draft - should we also drop this?). >=20 > Dirk >=20 >> -----Original Message----- >> From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com] >> Sent: Wednesday, March 24, 2010 5:42 AM >> To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen; >> Thomson, Martin; Richard Barnes; Bernard Aboba >> Cc: emu@ietf.org; ecrit@ietf.org >> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial >> of serviceattacks on the emergency.com domain) >>=20 >>=20 >> Hi Dirk, >>=20 >>> I do not see a value in such recommendation from IETF would be. >>> For layer-2 flags these organizations define such flags. They know. >>=20 >> SDOs set their own agendas; that's fair enough. They don't >> always want to consider how their architectures interwork >> with specifications defined by, say, the IETF. So perhaps, as >> you say, it's pointless. While ECRIT procedures are at the IP >> level and are intended to support clients that are connecting >> on IP via a routing device at the access, a "link technology >> SDO" may still persist with the assumption that it's the >> connecting device that negotiates procedures in an emergency >> scenario. Alternatively, they may consider the ECRIT model >> and decide to do something different. It is, as you say, up to them. >>=20 >>> What flag are you refering to? Up to now we were only >> discussing options >>> to indicate emergency in EAP, which rather on top of >> layer-2 than IP. >>=20 >> Which, if I understand it, is about negotiating an IP context >> in what is also an "emergency context". Leaving aside my >> point above as to whether that's a generally effective >> facility for supporting emergency connectivity, there's also >> the question (which I may be unfairly be attributing to >> Richard) as to what value it is to the access to know that >> this connectivity has been granted in an "emergency context". >> What's it going to do with this alleged context? >>=20 >>> Without a full subscription (either insufficient authorization or no >>> subscription) you may want to enter the NW for other things than >>> emergency. So would you always hotline these entrants to the PSAP? >>=20 >> No - you wouldn't. But, then, the concept of "hotlining the >> entrant to a PSAP" refers to a procedure that isn't described >> by ECRIT. There's no "hotlining". The device knows it wants >> to initiate an emergency call; it gets location from the LIS, >> gets the PSAP URI from LoST, and initiates a SIP session to >> the PSAP. The proposition of "hotlining" based on a layer 2 >> technology specific procedure is the sort of thing I refer to >> above. An access technology specific SDO may, for their own >> reasons, decide to define this sort of thing. I think they're >> talking about use cases that are orthogonal to what ECRIT is >> describing. ECRIT describes emergency procedures for the >> Internet, on IP, and independent of access technology. >>=20 >> I guess the extent to which an SDO thinks these things are >> worth developing depends on the extent to which they think a) >> ECRIT is not a significant model or to which b) they think >> there are "emergency" use cases that are outside the Internet >> domain or to which c) there is some complementary subset of >> use cases for their link technology (e.g. WiFi phones in an >> enterprise environment with an "emergency" button that set up >> an emergency IP context and are hotlined to the enterprise >> softswitch that then does ECRIT procedures to the outside >> world). The SDO just needs to decide whether there is a >> benefit consistent with the effort in defining/implementing >> such functionality. I think it's good if their delegates are >> aware of ECRIT in making that decision. >>=20 >> Cheers, >> Martin >>=20 >> -----Original Message----- >> From: Kroeselberg, Dirk (NSN - DE/Munich) >> [mailto:dirk.kroeselberg@nsn.com] >> Sent: Wednesday, 24 March 2010 2:12 PM >> To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard >> Barnes; Bernard Aboba >> Cc: emu@ietf.org; ecrit@ietf.org >> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial >> of serviceattacks on the emergency.com domain) >>=20 >> see inline. >>=20 >> Dirk >>=20 >>> -----Original Message----- >>> From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com] >>> Sent: Wednesday, March 24, 2010 2:15 AM >>> To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen; >>> Thomson, Martin; Richard Barnes; Bernard Aboba >>> Cc: emu@ietf.org; ecrit@ietf.org >>> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial >>> of serviceattacks on the emergency.com domain) >>>=20 >>> Consider the access out of scope, certainly. Recommend to >>> access-specific forums that they shouldn't *assume* the >>> connecting device is actually the device making the emergency >>> call (e.g. a WiFi device on a portable 3G router) so there's >>> no reliable assumption the connecting device can provide an >>> emergency flag. >>=20 >> I do not see a value in such recommendation from IETF would be. >> For layer-2 flags these organizations define such flags. They know. >>=20 >>> Then it's whatever ECRIT might recommend as appropriate on >>> top of IP. I think Richard's questions are along the line of >>> what the value of this specific "emergency flag" is at the IP >>> level. >> What flag are you refering to? Up to now we were only >> discussing options >> to indicate emergency in EAP, which rather on top of layer-2 than IP. >>=20 >> It's not like anyone but the device user knows whether >>> the access really is only required for emergency purposes. >>> It's a valid question; access policy may just be to bar or >>> allow (depending on whether it's a prohibitive or a >>> permissive policy) access to emergency specific things - such >>> as routes to PSAPs. A flag is not necessarily required to >>> apply that sort of policy. >> Without a full subscription (either insufficient authorization or no >> subscription) you may want to enter the NW for other things than >> emergency. So would you always hotline these entrants to the PSAP? >>=20 >>>=20 >>> Cheers, >>> Martin >>>=20 >>> -----Original Message----- >>> From: Kroeselberg, Dirk (NSN - DE/Munich) >>> [mailto:dirk.kroeselberg@nsn.com] >>> Sent: Wednesday, 24 March 2010 10:14 AM >>> To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard >>> Barnes; Bernard Aboba >>> Cc: emu@ietf.org; ecrit@ietf.org >>> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial >>> of serviceattacks on the emergency.com domain) >>>=20 >>>> So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, >>>> the DSL forum, etc. as to how a device is able to get an >>>> unauthenticated IP context on their technology, for whatever >>>> purpose, before the policies on permitting/prohibiting ECRIT >>>=20 >>> but what is the concrete recommendation that you want to give here? >>>=20 >>> - Drop the access/ISP part from the draft and say access/ISP is >>> out-of-scope? >>> - move this to EMU? >>> - or deal with the EAP/NAI related aspects outside IETF as >> you seem to >>> suggest (which is already partially the case today due to lack of >>> guidance)? >>>=20 >>>> is on others. I doubt that there's a reasonable assumption >>>> that the connecting device can necessarily provide an >>>> explicit "emergency intent" flag. >>> maybe this is why some people do this via the NAI ;-) >>>=20 >>> Dirk >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>> On Behalf Of ext Dawson, Martin >>>> Sent: Tuesday, March 23, 2010 11:44 PM >>>> To: Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba >>>> Cc: emu@ietf.org; ecrit@ietf.org >>>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial >>>> of serviceattacks on the emergency.com domain) >>>>=20 >>>> To elaborate on Brian's "counter point" - some jurisdictions >>>> may prefer to *forbid* access to the emergency service from >>>> unauthenticated/anonymous access as opposed to *require* it >>>> to be supported. Noting this is the equivalent of saying >>>> emergency calls for circuit service cannot be made from >>>> public phone booths; this is still a possible policy within a >>>> given jurisdiction. >>>>=20 >>>> I'd also posit that not only is it not a priority for IETF >>>> but that the question actually needs to be dealt with in more >>>> specific forums first. The ECRIT emergency procedures occur >>>> at or above the IP layer. Before anything that ECRIT >>>> describes becomes relevant, there needs to be an IP context. >>>>=20 >>>> So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, >>>> the DSL forum, etc. as to how a device is able to get an >>>> unauthenticated IP context on their technology, for whatever >>>> purpose, before the policies on permitting/prohibiting ECRIT >>>> procedures or anything else that can be done on IP can be >>>> applied. This is easier on some access technologies than it >>>> is on others. I doubt that there's a reasonable assumption >>>> that the connecting device can necessarily provide an >>>> explicit "emergency intent" flag. >>>>=20 >>>> Cheers, >>>> Martin >>>>=20 >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>> On Behalf Of Brian Rosen >>>> Sent: Wednesday, 24 March 2010 8:29 AM >>>> To: Thomson, Martin; Richard Barnes; Bernard Aboba >>>> Cc: emu@ietf.org; ecrit@ietf.org >>>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial >>>> of serviceattacks on the emergency.com domain) >>>>=20 >>>> I think the relevant part of this is 'it's not a high >>>> priority'. That is >>>> policy of the work group, which we do have control over. >>>>=20 >>>> If we have nothing else more important to do, then by all >>>> means, let's waste >>>> a ton of time on unauthenticated access. If we have other >>> work to do, >>>> perhaps we could defer this. >>>>=20 >>>> I am not the chair, but in general, anyone can discuss >>>> anything, regardless >>>> of "priority" on the list. However, when it comes to >>>> adopting work group >>>> items, I think this should be way down our list. >>>>=20 >>>> I might also suggest that unauthenticated access really isn't >>>> within the >>>> charter of the work group. It may be that the reason >>>> unauthenticated access >>>> may be needed is for emergency calling, but that means we may >>>> (eventually) >>>> need to ask some other work group to do work for a >>>> requirement we generate. >>>> It would seem that dealing with EAP is not within the domain >>>> of this work >>>> group. >>>>=20 >>>> Brian >>>>=20 >>>>=20 >>>> On 3/23/10 5:14 PM, "Thomson, Martin" >>>> <Martin.Thomson@andrew.com> wrote: >>>>=20 >>>>>> A large percentage (in fact an overwhelming percentage) of >>>> PSAPs DON'T >>>>>> WANT >>>>>> unauthenticated access. Their position is that they >> have lots of >>>>>> relevant >>>>>> experience, and its all bad (tens of thousands of calls >>>> with no good >>>>>> ones in >>>>>> some cases). >>>>>>=20 >>>>>> However, there are some PSAPs who want it, and there are some >>>>>> regulatory >>>>>> environments where there are some lawyers who think it's >>>> required to >>>>>> support >>>>>> it in some environments. >>>>>=20 >>>>> The good thing is: we don't set policy here. I'm not >>>> seeing sufficient >>>>> evidence that _everyone_ doesn't want this, only that some >>>> don't want this. >>>>>=20 >>>>> I can't comment on priority. That would be policy too. >>>>>=20 >>>>> --Martin >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>>=20 >>=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From hgs@cs.columbia.edu Thu Mar 25 17:00:33 2010 Return-Path: <hgs@cs.columbia.edu> 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 0CE663A6939 for <ecrit@core3.amsl.com>; Thu, 25 Mar 2010 17:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.722 X-Spam-Level: X-Spam-Status: No, score=-0.722 tagged_above=-999 required=5 tests=[AWL=-1.667, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] 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 jwt4RePBmNsB for <ecrit@core3.amsl.com>; Thu, 25 Mar 2010 17:00:32 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id 0577B3A6830 for <ecrit@ietf.org>; Thu, 25 Mar 2010 17:00:31 -0700 (PDT) Received: from dhcp-wireless-open-abg-26-78.meeting.ietf.org (dhcp-wireless-open-abg-26-78.meeting.ietf.org [130.129.26.78]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o2Q00nqh012432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 25 Mar 2010 20:00:50 -0400 (EDT) References: <8BC845943058D844ABFC73D2220D466508F4EE40@nics-mail.sbg.nic.at> <8BC845943058D844ABFC73D2220D466508F4EE41@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D466508F4EE41@nics-mail.sbg.nic.at> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: <A589845B-16B7-492D-8038-B55735B732C2@cs.columbia.edu> Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne <hgs@cs.columbia.edu> Date: Thu, 25 Mar 2010 20:00:48 -0400 To: Alexander Mayrhofer <alexander.mayrhofer@nic.at> X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: "Ecrit@Ietf. Org" <ecrit@ietf.org> Subject: Re: [Ecrit] "service URN classification" pointer. X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 26 Mar 2010 00:00:33 -0000 I looked at this effort, and I admit that I'm not all that impressed. = The collection seems rather haphazard and the "voting" process seems to = require ten random people to vote yes, with no clear indication that = they have a qualification beyond being able to post to a Wiki. Also, = many of the items are geographic features, such as rivers, rather than = services. I don't see how this is better than, say, the GEOPRIV WG or = any other random collection of IETF members. I have no objection to = incorporating the relevant service-oriented labels, but wholesale = adoption seems problematic. Henning On Mar 22, 2010, at 2:19 PM, Alexander Mayrhofer wrote: > [hate to reply to myself, but..] >=20 >> There are "well know" tags that are long established, and there is >> typically heated discussion once someone proposes something new. >>=20 >> http://wiki.openstreetmap.org/wiki/Tag >=20 > All about the development of the Tag spaces can be found here: >=20 > http://wiki.openstreetmap.org/wiki/Category:Proposals_admin >=20 > Alex > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From alexander.mayrhofer@nic.at Thu Mar 25 17:11:23 2010 Return-Path: <alexander.mayrhofer@nic.at> 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 7E6E23A68AD for <ecrit@core3.amsl.com>; Thu, 25 Mar 2010 17:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ISoRh-OTE8a for <ecrit@core3.amsl.com>; Thu, 25 Mar 2010 17:11:22 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id 1E3AC3A6933 for <ecrit@ietf.org>; Thu, 25 Mar 2010 17:11:20 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.sbg.nic.at with XWall v3.45 ; Fri, 26 Mar 2010 01:11:41 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 26 Mar 2010 01:11:26 +0100 Message-ID: <8BC845943058D844ABFC73D2220D466508FC882A@nics-mail.sbg.nic.at> In-Reply-To: <A589845B-16B7-492D-8038-B55735B732C2@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] "service URN classification" pointer. Thread-Index: AcrMd24NWQrTiWTbQwu+WXLMrRq/PAAANUsg References: <8BC845943058D844ABFC73D2220D466508F4EE40@nics-mail.sbg.nic.at> <8BC845943058D844ABFC73D2220D466508F4EE41@nics-mail.sbg.nic.at> <A589845B-16B7-492D-8038-B55735B732C2@cs.columbia.edu> From: "Alexander Mayrhofer" <alexander.mayrhofer@nic.at> To: "Henning Schulzrinne" <hgs@cs.columbia.edu> X-XWALL-BCKS: auto Cc: "Ecrit@Ietf. Org" <ecrit@ietf.org> Subject: Re: [Ecrit] "service URN classification" pointer. X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 26 Mar 2010 00:11:23 -0000 > I looked at this effort, and I admit that I'm not all that=20 > impressed. The collection seems rather haphazard and the=20 > "voting" process seems to require ten random people to vote=20 > yes, with no clear indication that they have a qualification=20 > beyond being able to post to a Wiki. Also, many of the items=20 > are geographic features, such as rivers, rather than=20 > services. I don't see how this is better than, say, the=20 > GEOPRIV WG or any other random collection of IETF members. I=20 > have no objection to incorporating the relevant=20 > service-oriented labels, but wholesale adoption seems problematic. I didn't say it was better or worse than work in other groups or by other means of organizations. It's definitely more "casual" than most other classification processes, and hence might have much more entropy than others. It has, however, a massive community using that classification. (And yes, there *are* edit wars on Openstreetmap). I think that the general problem of classification is multi-dimensional - i have thought about it for a bit long time ago, and didn't even come up with a conclusion whether a hierarchical or tag-based (flat) model was better.. Alex From andres.kytt@skype.net Fri Mar 26 04:11:40 2010 Return-Path: <andres.kytt@skype.net> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C251F3A6966; Fri, 26 Mar 2010 04:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3, 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 ek5oxU0893dv; Fri, 26 Mar 2010 04:11:38 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 4D5433A6864; Fri, 26 Mar 2010 04:11:38 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 3615360132D98; Fri, 26 Mar 2010 11:12:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=date:subject :from:to:cc:message-id:in-reply-to:mime-version:content-type: content-transfer-encoding; s=mail; bh=cAzjMDDvrzdlpGnJ239sHizIH1 w=; b=GpTuIg0WRRljLj9TIjzOHvP5nYA26A3hvon6ApjJWsw9mrNTVfyUqr+csZ Gc0JZfXtprQxtet4oae/XvqxwWzOIvaB6AhqdOHM5wo5hqX1qpWASZUZkiSl0aVi dP89W9MJwPThKblx17S6fKPh8Ry3JBSB7wSnlodPpdy+urVPU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=date:subject:from:to :cc:message-id:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=Q638/ZvX/uZdYTuQFgVu dfWL//r6HTq1LikqUPUB3mEBe1tO+uY2UtDDYPS2xRGnB81LyIrlJtKEkb2DPTth j0erPkXwuk61m32qFxylhXG570VzcLGDTEIChN0Xa6fZYyvY8mRy3pr8+B6HiBSt 8H9/3crW2fDMOHOcVdB02HE= Received: from [172.16.42.71] (unknown [195.46.244.194]) by mail.skype.net (Postfix) with ESMTPS id C202460132D96; Fri, 26 Mar 2010 11:11:59 +0000 (GMT) User-Agent: Microsoft-Entourage/13.3.0.091002 Date: Fri, 26 Mar 2010 13:11:57 +0200 From: Andres =?ISO-8859-1?B?S/x0dA==?= <andres.kytt@skype.net> To: "Dawson, Martin" <Martin.Dawson@andrew.com> Message-ID: <C7D2631D.6BEB%andres.kytt@skype.net> Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrKzRfOc6w4ZPWsrkimclW4dAPFuwAAHhnQAACVA9cAAQknQAACQEEAAAQ84AAAE8l+zAAAihfgAGV2j3o= In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E24ED180@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "emu@ietf.org" <emu@ietf.org>, "ecrit@ietf.org" <ecrit@ietf.org> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 26 Mar 2010 11:11:41 -0000 Hi, Certainly. Let's assume the following: - existing UI implementation is used (i.e. the software provider will not build a separate SIP client with distinct UI just for emergency calling) - the client is multifunctional i.e. it is used for more things than calling - the client has been authenticated already, this kind of software tends to run in the background continuously - there is no network connection Given these assumptions EC would work like this: - user attempts to place an EC - the client, being offline, attempts to re-establish it's session with the network/server (i.e. get online) - at this point, the access provider needs to know that the session being established is for the purposes of an EC and needs to allow the connection - session gets established with the server/network - user attempts an emergency call - the call reaches servers/network and is connected - the call ends - at this point there needs to be a way to drop the connection as the access provider has no way of knowing whether the call has ended or not. Please note that - session establishment happens before the call and access provider has no idea whether this is because of ordinary client use or EC. Remember, the protocol used is opaque - it is impossible for the client to know whether EC is even allowed/implemented for a particular location before the session is established - because the protocol used is opaque, the access provider has no way to distinguish between session establishment, an actual EC, ordinary IM traffic or common web browsing (one could envision a VoIP application that uses HTTP bindings for signaling purposes) Thus, regardless of the methods used, the access provider needs to trust the service provider to only use the connection for emergency calling and nothing else. As for the session establishment, one way to do this is the way Skype Access (you buy WIFI time using your Skype credit) works: - the client wraps a session request in a DNS query against skype.com name server. DNS is usually quite unrestricted but there are, of course, exceptions - single-use credentials are issued - WISPr authentication is attempted using the credentials acquired - the access provider attempts authentication against Skype - session is established - when the authentication session ends, the access provider attempts a re-authenticate and terminates the connection should it fail Yours, Andres On 3/24/10 12:55 PM, "Dawson, Martin" <Martin.Dawson@andrew.com> wrote: > Hi Andres, > > Could you take us step by step through the establishment of the anonymous > connection and the initiation of the emergency call and highlight where/how > this notification mechanism would be invoked and what it would do? > > I would find that helpful. I'm interested in how people see the access network > being able to limit the use of an arbitrary third party VoIP application to > emergency calling, if that's the intent, in the context of > unauthenticated/anonymous access. > > BTW, I haven't said that access is completely out of scope. Actually, it > obviously is in scope both in terms of what facilities it provides and what > its policies are with respect to emergency calling procedures in the context > of unaurthenticated/anonymous connections. It's the concept of gating the > establishment of unauthenticated/anonymous connections on some kind of a > priori knowledge or indication that its for the purpose of an emergency call > that I question. > > Regards, > Martin > > -----Original Message----- > From: Kutt, Andres [mailto:akutt@ebay.com] > Sent: Wednesday, 24 March 2010 9:31 PM > To: Dawson, Martin > Cc: emu@ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of > serviceattacks on the emergency.com domain) > > Hi, > > Leaving access completely out of scope is of course the easiest course > but some synchronization must remain. In case of Skype, there is no way for > the access provider to tell whether the user is placing an emergency call or > chatting with their friends as the protocol used is opaque for the outsider. > This is true in any case the service provider uses a protocol not known or > understood by access provider and we must assume this can legally occur. > Thus, should anonymous access be required, a mechanism must exist to notify > the access provider about an attempted emergency call. > > Yours, > Andres > > > On 3/24/10 3:14 AM, "Dawson, Martin" <Martin.Dawson@andrew.com> wrote: > >> Consider the access out of scope, certainly. Recommend to access-specific >> forums that they shouldn't *assume* the connecting device is actually the >> device making the emergency call (e.g. a WiFi device on a portable 3G router) >> so there's no reliable assumption the connecting device can provide an >> emergency flag. >> >> Then it's whatever ECRIT might recommend as appropriate on top of IP. I think >> Richard's questions are along the line of what the value of this specific >> "emergency flag" is at the IP level. It's not like anyone but the device user >> knows whether the access really is only required for emergency purposes. It's >> a valid question; access policy may just be to bar or allow (depending on >> whether it's a prohibitive or a permissive policy) access to emergency >> specific things - such as routes to PSAPs. A flag is not necessarily required >> to apply that sort of policy. >> >> Cheers, >> Martin >> >> -----Original Message----- >> From: Kroeselberg, Dirk (NSN - DE/Munich) [mailto:dirk.kroeselberg@nsn.com] >> Sent: Wednesday, 24 March 2010 10:14 AM >> To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; Bernard >> Aboba >> Cc: emu@ietf.org; ecrit@ietf.org >> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of >> serviceattacks on the emergency.com domain) >> >>> So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, >>> the DSL forum, etc. as to how a device is able to get an >>> unauthenticated IP context on their technology, for whatever >>> purpose, before the policies on permitting/prohibiting ECRIT >> >> but what is the concrete recommendation that you want to give here? >> >> - Drop the access/ISP part from the draft and say access/ISP is >> out-of-scope? >> - move this to EMU? >> - or deal with the EAP/NAI related aspects outside IETF as you seem to >> suggest (which is already partially the case today due to lack of >> guidance)? >> >>> is on others. I doubt that there's a reasonable assumption >>> that the connecting device can necessarily provide an >>> explicit "emergency intent" flag. >> maybe this is why some people do this via the NAI ;-) >> >> Dirk >> >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>> On Behalf Of ext Dawson, Martin >>> Sent: Tuesday, March 23, 2010 11:44 PM >>> To: Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba >>> Cc: emu@ietf.org; ecrit@ietf.org >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial >>> of serviceattacks on the emergency.com domain) >>> >>> To elaborate on Brian's "counter point" - some jurisdictions >>> may prefer to *forbid* access to the emergency service from >>> unauthenticated/anonymous access as opposed to *require* it >>> to be supported. Noting this is the equivalent of saying >>> emergency calls for circuit service cannot be made from >>> public phone booths; this is still a possible policy within a >>> given jurisdiction. >>> >>> I'd also posit that not only is it not a priority for IETF >>> but that the question actually needs to be dealt with in more >>> specific forums first. The ECRIT emergency procedures occur >>> at or above the IP layer. Before anything that ECRIT >>> describes becomes relevant, there needs to be an IP context. >>> >>> So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, >>> the DSL forum, etc. as to how a device is able to get an >>> unauthenticated IP context on their technology, for whatever >>> purpose, before the policies on permitting/prohibiting ECRIT >>> procedures or anything else that can be done on IP can be >>> applied. This is easier on some access technologies than it >>> is on others. I doubt that there's a reasonable assumption >>> that the connecting device can necessarily provide an >>> explicit "emergency intent" flag. >>> >>> Cheers, >>> Martin >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>> On Behalf Of Brian Rosen >>> Sent: Wednesday, 24 March 2010 8:29 AM >>> To: Thomson, Martin; Richard Barnes; Bernard Aboba >>> Cc: emu@ietf.org; ecrit@ietf.org >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial >>> of serviceattacks on the emergency.com domain) >>> >>> I think the relevant part of this is 'it's not a high >>> priority'. That is >>> policy of the work group, which we do have control over. >>> >>> If we have nothing else more important to do, then by all >>> means, let's waste >>> a ton of time on unauthenticated access. If we have other work to do, >>> perhaps we could defer this. >>> >>> I am not the chair, but in general, anyone can discuss >>> anything, regardless >>> of "priority" on the list. However, when it comes to >>> adopting work group >>> items, I think this should be way down our list. >>> >>> I might also suggest that unauthenticated access really isn't >>> within the >>> charter of the work group. It may be that the reason >>> unauthenticated access >>> may be needed is for emergency calling, but that means we may >>> (eventually) >>> need to ask some other work group to do work for a >>> requirement we generate. >>> It would seem that dealing with EAP is not within the domain >>> of this work >>> group. >>> >>> Brian >>> >>> >>> On 3/23/10 5:14 PM, "Thomson, Martin" >>> <Martin.Thomson@andrew.com> wrote: >>> >>>>> A large percentage (in fact an overwhelming percentage) of >>> PSAPs DON'T >>>>> WANT >>>>> unauthenticated access. Their position is that they have lots of >>>>> relevant >>>>> experience, and its all bad (tens of thousands of calls >>> with no good >>>>> ones in >>>>> some cases). >>>>> >>>>> However, there are some PSAPs who want it, and there are some >>>>> regulatory >>>>> environments where there are some lawyers who think it's >>> required to >>>>> support >>>>> it in some environments. >>>> >>>> The good thing is: we don't set policy here. I'm not >>> seeing sufficient >>>> evidence that _everyone_ doesn't want this, only that some >>> don't want this. >>>> >>>> I can't comment on priority. That would be policy too. >>>> >>>> --Martin >>> >>> >>> _______________________________________________ >>> 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 Martin.Dawson@andrew.com Fri Mar 26 17:50:51 2010 Return-Path: <Martin.Dawson@andrew.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC0A3A6810; Fri, 26 Mar 2010 17:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[AWL=1.258, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yocVpKT503gD; Fri, 26 Mar 2010 17:50:49 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 389793A683B; Fri, 26 Mar 2010 17:50:49 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:9147 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S210423Ab0C0AvL convert rfc822-to-8bit (ORCPT <rfc822;emu@ietf.org> + 1 other); Fri, 26 Mar 2010 19:51:11 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 26 Mar 2010 19:51:10 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Sat, 27 Mar 2010 08:51:08 +0800 From: "Dawson, Martin" <Martin.Dawson@andrew.com> To: =?iso-8859-1?Q?Andres_K=FCtt?= <andres.kytt@skype.net> Date: Sat, 27 Mar 2010 08:51:05 +0800 Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrKzRfOc6w4ZPWsrkimclW4dAPFuwAAHhnQAACVA9cAAQknQAACQEEAAAQ84AAAE8l+zAAAihfgAGV2j3oAHFLc8A== Message-ID: <8B0A9FCBB9832F43971E38010638454F03E24ED460@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03E24ED180@SISPE7MB1.commscope.com> <C7D2631D.6BEB%andres.kytt@skype.net> In-Reply-To: <C7D2631D.6BEB%andres.kytt@skype.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Cc: "emu@ietf.org" <emu@ietf.org>, "ecrit@ietf.org" <ecrit@ietf.org> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 27 Mar 2010 00:50:51 -0000 It seems to me that fly in the ointment is this point: > - because the protocol used is opaque, the access provider has no way to > distinguish between session establishment, an actual EC, ordinary IM traffic > or common web browsing (one could envision a VoIP application that uses HTTP > bindings for signaling purposes) I agree with this point. Effectively it says that the access has no way of knowing whether the third party application actually is just supporting an emergency call. Not only is it opaque but it has no control signalling relationship with the access either - so the access has no independent way to inform the application that the client is only supposed to be doing an emergency call. I do not see how the "it's understood to be an emergency IP context" knowledge facilitates any of this policy control. Out of control is out of control. On you first point about the UI implementation. I have... hang on... five applications on my Android device menu that do voice in one form or another. Frankly, it would be most convenient to have one there that just said "Emergency" and whose sole purpose was to do the ECRIT procedures (as described in this draft). That would be an ECRIT direct calling client. Access networks can most readily support policies that allow for this mode of use - without the third party trust issues that you raise. Cheers, Martin -----Original Message----- From: Andres Kütt [mailto:andres.kytt@skype.net] Sent: Friday, 26 March 2010 10:12 PM To: Dawson, Martin Cc: emu@ietf.org; ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Hi, Certainly. Let's assume the following: - existing UI implementation is used (i.e. the software provider will not build a separate SIP client with distinct UI just for emergency calling) - the client is multifunctional i.e. it is used for more things than calling - the client has been authenticated already, this kind of software tends to run in the background continuously - there is no network connection Given these assumptions EC would work like this: - user attempts to place an EC - the client, being offline, attempts to re-establish it's session with the network/server (i.e. get online) - at this point, the access provider needs to know that the session being established is for the purposes of an EC and needs to allow the connection - session gets established with the server/network - user attempts an emergency call - the call reaches servers/network and is connected - the call ends - at this point there needs to be a way to drop the connection as the access provider has no way of knowing whether the call has ended or not. Please note that - session establishment happens before the call and access provider has no idea whether this is because of ordinary client use or EC. Remember, the protocol used is opaque - it is impossible for the client to know whether EC is even allowed/implemented for a particular location before the session is established - because the protocol used is opaque, the access provider has no way to distinguish between session establishment, an actual EC, ordinary IM traffic or common web browsing (one could envision a VoIP application that uses HTTP bindings for signaling purposes) Thus, regardless of the methods used, the access provider needs to trust the service provider to only use the connection for emergency calling and nothing else. As for the session establishment, one way to do this is the way Skype Access (you buy WIFI time using your Skype credit) works: - the client wraps a session request in a DNS query against skype.com name server. DNS is usually quite unrestricted but there are, of course, exceptions - single-use credentials are issued - WISPr authentication is attempted using the credentials acquired - the access provider attempts authentication against Skype - session is established - when the authentication session ends, the access provider attempts a re-authenticate and terminates the connection should it fail Yours, Andres On 3/24/10 12:55 PM, "Dawson, Martin" <Martin.Dawson@andrew.com> wrote: > Hi Andres, > > Could you take us step by step through the establishment of the anonymous > connection and the initiation of the emergency call and highlight where/how > this notification mechanism would be invoked and what it would do? > > I would find that helpful. I'm interested in how people see the access network > being able to limit the use of an arbitrary third party VoIP application to > emergency calling, if that's the intent, in the context of > unauthenticated/anonymous access. > > BTW, I haven't said that access is completely out of scope. Actually, it > obviously is in scope both in terms of what facilities it provides and what > its policies are with respect to emergency calling procedures in the context > of unaurthenticated/anonymous connections. It's the concept of gating the > establishment of unauthenticated/anonymous connections on some kind of a > priori knowledge or indication that its for the purpose of an emergency call > that I question. > > Regards, > Martin > > -----Original Message----- > From: Kutt, Andres [mailto:akutt@ebay.com] > Sent: Wednesday, 24 March 2010 9:31 PM > To: Dawson, Martin > Cc: emu@ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of > serviceattacks on the emergency.com domain) > > Hi, > > Leaving access completely out of scope is of course the easiest course > but some synchronization must remain. In case of Skype, there is no way for > the access provider to tell whether the user is placing an emergency call or > chatting with their friends as the protocol used is opaque for the outsider. > This is true in any case the service provider uses a protocol not known or > understood by access provider and we must assume this can legally occur. > Thus, should anonymous access be required, a mechanism must exist to notify > the access provider about an attempted emergency call. > > Yours, > Andres > > > On 3/24/10 3:14 AM, "Dawson, Martin" <Martin.Dawson@andrew.com> wrote: > >> Consider the access out of scope, certainly. Recommend to access-specific >> forums that they shouldn't *assume* the connecting device is actually the >> device making the emergency call (e.g. a WiFi device on a portable 3G router) >> so there's no reliable assumption the connecting device can provide an >> emergency flag. >> >> Then it's whatever ECRIT might recommend as appropriate on top of IP. I think >> Richard's questions are along the line of what the value of this specific >> "emergency flag" is at the IP level. It's not like anyone but the device user >> knows whether the access really is only required for emergency purposes. It's >> a valid question; access policy may just be to bar or allow (depending on >> whether it's a prohibitive or a permissive policy) access to emergency >> specific things - such as routes to PSAPs. A flag is not necessarily required >> to apply that sort of policy. >> >> Cheers, >> Martin >> >> -----Original Message----- >> From: Kroeselberg, Dirk (NSN - DE/Munich) [mailto:dirk.kroeselberg@nsn.com] >> Sent: Wednesday, 24 March 2010 10:14 AM >> To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; Bernard >> Aboba >> Cc: emu@ietf.org; ecrit@ietf.org >> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of >> serviceattacks on the emergency.com domain) >> >>> So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, >>> the DSL forum, etc. as to how a device is able to get an >>> unauthenticated IP context on their technology, for whatever >>> purpose, before the policies on permitting/prohibiting ECRIT >> >> but what is the concrete recommendation that you want to give here? >> >> - Drop the access/ISP part from the draft and say access/ISP is >> out-of-scope? >> - move this to EMU? >> - or deal with the EAP/NAI related aspects outside IETF as you seem to >> suggest (which is already partially the case today due to lack of >> guidance)? >> >>> is on others. I doubt that there's a reasonable assumption >>> that the connecting device can necessarily provide an >>> explicit "emergency intent" flag. >> maybe this is why some people do this via the NAI ;-) >> >> Dirk >> >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>> On Behalf Of ext Dawson, Martin >>> Sent: Tuesday, March 23, 2010 11:44 PM >>> To: Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba >>> Cc: emu@ietf.org; ecrit@ietf.org >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial >>> of serviceattacks on the emergency.com domain) >>> >>> To elaborate on Brian's "counter point" - some jurisdictions >>> may prefer to *forbid* access to the emergency service from >>> unauthenticated/anonymous access as opposed to *require* it >>> to be supported. Noting this is the equivalent of saying >>> emergency calls for circuit service cannot be made from >>> public phone booths; this is still a possible policy within a >>> given jurisdiction. >>> >>> I'd also posit that not only is it not a priority for IETF >>> but that the question actually needs to be dealt with in more >>> specific forums first. The ECRIT emergency procedures occur >>> at or above the IP layer. Before anything that ECRIT >>> describes becomes relevant, there needs to be an IP context. >>> >>> So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, >>> the DSL forum, etc. as to how a device is able to get an >>> unauthenticated IP context on their technology, for whatever >>> purpose, before the policies on permitting/prohibiting ECRIT >>> procedures or anything else that can be done on IP can be >>> applied. This is easier on some access technologies than it >>> is on others. I doubt that there's a reasonable assumption >>> that the connecting device can necessarily provide an >>> explicit "emergency intent" flag. >>> >>> Cheers, >>> Martin >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>> On Behalf Of Brian Rosen >>> Sent: Wednesday, 24 March 2010 8:29 AM >>> To: Thomson, Martin; Richard Barnes; Bernard Aboba >>> Cc: emu@ietf.org; ecrit@ietf.org >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial >>> of serviceattacks on the emergency.com domain) >>> >>> I think the relevant part of this is 'it's not a high >>> priority'. That is >>> policy of the work group, which we do have control over. >>> >>> If we have nothing else more important to do, then by all >>> means, let's waste >>> a ton of time on unauthenticated access. If we have other work to do, >>> perhaps we could defer this. >>> >>> I am not the chair, but in general, anyone can discuss >>> anything, regardless >>> of "priority" on the list. However, when it comes to >>> adopting work group >>> items, I think this should be way down our list. >>> >>> I might also suggest that unauthenticated access really isn't >>> within the >>> charter of the work group. It may be that the reason >>> unauthenticated access >>> may be needed is for emergency calling, but that means we may >>> (eventually) >>> need to ask some other work group to do work for a >>> requirement we generate. >>> It would seem that dealing with EAP is not within the domain >>> of this work >>> group. >>> >>> Brian >>> >>> >>> On 3/23/10 5:14 PM, "Thomson, Martin" >>> <Martin.Thomson@andrew.com> wrote: >>> >>>>> A large percentage (in fact an overwhelming percentage) of >>> PSAPs DON'T >>>>> WANT >>>>> unauthenticated access. Their position is that they have lots of >>>>> relevant >>>>> experience, and its all bad (tens of thousands of calls >>> with no good >>>>> ones in >>>>> some cases). >>>>> >>>>> However, there are some PSAPs who want it, and there are some >>>>> regulatory >>>>> environments where there are some lawyers who think it's >>> required to >>>>> support >>>>> it in some environments. >>>> >>>> The good thing is: we don't set policy here. I'm not >>> seeing sufficient >>>> evidence that _everyone_ doesn't want this, only that some >>> don't want this. >>>> >>>> I can't comment on priority. That would be policy too. >>>> >>>> --Martin >>> >>> >>> _______________________________________________ >>> 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 Gabor.Bajko@nokia.com Mon Mar 29 17:17:21 2010 Return-Path: <Gabor.Bajko@nokia.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC9D23A6801; Mon, 29 Mar 2010 17:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 R--n7CvKOXQW; Mon, 29 Mar 2010 17:17:17 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 1150E3A63EC; Mon, 29 Mar 2010 17:17:15 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o2U0HawR020716; Tue, 30 Mar 2010 03:17:38 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Mar 2010 03:17:37 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Mar 2010 03:17:32 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 30 Mar 2010 02:17:19 +0200 From: <Gabor.Bajko@nokia.com> To: <Martin.Dawson@andrew.com>, <dirk.kroeselberg@nsn.com> Date: Tue, 30 Mar 2010 02:17:16 +0200 Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrKzRfOc6w4ZPWsrkimclW4dAPFuwAAHhnQAACVA9cAAQknQAACQEEAAAQ84AAABDcxsAACUHmQABfrbWAAFZ7x4AD3fYrQ Message-ID: <A99B171D26E1564B92D36826128CD66159C060DB70@NOK-EUMSG-01.mgdnok.nokia.com> References: <8B0A9FCBB9832F43971E38010638454F03E24ED000@SISPE7MB1.commscope.com><C7CEAAED.2AF6F%br@brianrosen.net> <8B0A9FCBB9832F43971E38010638454F03E24ED009@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB904@DEMUEXC030.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03E24ED048@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB920@DEMUEXC030.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03E24ED0A9@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DBEDB@DEMUEXC030.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03E24ED22E@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E24ED22E@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Mar 2010 00:17:32.0656 (UTC) FILETIME=[64368F00:01CACF9E] X-Nokia-AV: Clean Cc: emu@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 30 Mar 2010 00:17:21 -0000 In an RSNA enabled wifi network you are not redirected to a portal page, bu= t rather authenticated (if you have the key) before getting associated. If = you do not know the key, you can't associate, and can't send any 802.11 dat= a packets to the AP. If there was an indication included in the EAP Request= , then the AP would know that this STA is requesting association for emerge= ncy call purposes, and may be able to give access to it even if the STA is = not in posession of the proper credentials (installing filters would still = be necessary). For open access wifi networks, the 802.11 specification has a slightly diff= erent solution than the one suggested below: the AP may be configured with = multiple SSIDs, with one of them being dedicated for emergency call purpose= s. This is then signalled in the beacon frame. STAs willing to place an eme= rgency call would first perform an active scan, identify the proper SSID an= d associate (RSNA is not supposed to be enabled). -- Gabor -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of e= xt Dawson, Martin Sent: Wednesday, March 24, 2010 7:16 PM To: Kroeselberg, Dirk (NSN - DE/Munich) Cc: emu@ietf.org; ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceatt= acks on the emergency.com domain) I'll describe a potential real world scenario before I try to answer your q= uestion. * Public WiFi hotspots generally provide a "free unauthenticated and anonym= ous" IP context. * Once connected to the access, users are generally "portal locked" to a si= ngle web page that requires further authentication/payment to proceed. The = access may provide some additional "filters" that allow routes to some subs= et of news/commercial websites as a "bonus". * In order to support unauthenticated/anonymous emergency calling at this p= oint, the hotspot would need to add the location service, access to LoST, a= nd a route to the relevant PSAP URI(s) to the filter list. The question I raise is what would be done differently if the connecting de= vice *could* have provided an indication that it wanted the connection for = the purpose an emergency call? I don't think anything needs to be done diff= erently. I don't, for example, think there's any prioritization benefit. An= "emergency" type query to the LCP (HELD option), an emergency service look= up to LoST, and a SIP session directed toward a PSAP URI are all things tha= t could be explicitly detected and given priority. Priority isn't an end-go= al in itself in any case. The end goal is reliability and response time for= these emergency related services. The access provider may need to ensure s= ome service level there. They can do that without needing to roll dice. And= , given they can neither rely on devices to provide an emergency indication= nor trust that indication if they do, they are likely better off providing= the necessary service level for emergency procedures independently of the = device's broadc asted intentions. Let me say that I think the draft is great; it crystallizes a lot of issues= . I just think the section on EAP isn't necessary; it doesn't describe a ge= nerally applicable solution and its presence is likely to cause confusion a= s to its significance. In answer to your question; no, I don't suggest drop= ping the discussion on filters. I think that's a fundamental aspect; I thin= k it's orthogonal to the concept of an "emergency intent indicator". Cheers, Martin -----Original Message----- From: Kroeselberg, Dirk (NSN - DE/Munich) [mailto:dirk.kroeselberg@nsn.com] Sent: Thursday, 25 March 2010 2:46 AM To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; Bernard A= boba Cc: emu@ietf.org; ecrit@ietf.org Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of serviceatt= acks on the emergency.com domain) > facility for supporting emergency connectivity, there's also the > question (which I may be unfairly be attributing to > Richard) as to what value it is to the access to know that this > connectivity has been granted in an "emergency context". > What's it going to do with this alleged context? Considering this in authorization decisions, QoS, setting IP filters (limit= ed access), priority. Just to give a few examples. > No - you wouldn't. But, then, the concept of "hotlining the entrant to > a PSAP" refers to a procedure that isn't described by ECRIT. There's > no "hotlining". The device knows it wants Right, but I was saying it is important for the access network to recognize= that the 'special' entry the MS wants to do is for emergency, not let the = access network roll dices. Of course hotlining procedures are not in scope of ECRIT, there is nothing = emergency-specific besides installing the right filters (which by the way w= e also discuss in the draft - should we also drop this?). Dirk > -----Original Message----- > From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Wednesday, March 24, 2010 5:42 AM > To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen; Thomson, Martin; > Richard Barnes; Bernard Aboba > Cc: emu@ietf.org; ecrit@ietf.org > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of > serviceattacks on the emergency.com domain) > > > Hi Dirk, > > > I do not see a value in such recommendation from IETF would be. > > For layer-2 flags these organizations define such flags. They know. > > SDOs set their own agendas; that's fair enough. They don't always want > to consider how their architectures interwork with specifications > defined by, say, the IETF. So perhaps, as you say, it's pointless. > While ECRIT procedures are at the IP level and are intended to support > clients that are connecting on IP via a routing device at the access, > a "link technology SDO" may still persist with the assumption that > it's the connecting device that negotiates procedures in an emergency > scenario. Alternatively, they may consider the ECRIT model and decide > to do something different. It is, as you say, up to them. > > > What flag are you refering to? Up to now we were only > discussing options > > to indicate emergency in EAP, which rather on top of > layer-2 than IP. > > Which, if I understand it, is about negotiating an IP context in what > is also an "emergency context". Leaving aside my point above as to > whether that's a generally effective facility for supporting emergency > connectivity, there's also the question (which I may be unfairly be > attributing to > Richard) as to what value it is to the access to know that this > connectivity has been granted in an "emergency context". > What's it going to do with this alleged context? > > > Without a full subscription (either insufficient authorization or no > > subscription) you may want to enter the NW for other things than > > emergency. So would you always hotline these entrants to the PSAP? > > No - you wouldn't. But, then, the concept of "hotlining the entrant to > a PSAP" refers to a procedure that isn't described by ECRIT. There's > no "hotlining". The device knows it wants to initiate an emergency > call; it gets location from the LIS, gets the PSAP URI from LoST, and > initiates a SIP session to the PSAP. The proposition of "hotlining" > based on a layer 2 technology specific procedure is the sort of thing > I refer to above. An access technology specific SDO may, for their own > reasons, decide to define this sort of thing. I think they're talking > about use cases that are orthogonal to what ECRIT is describing. ECRIT > describes emergency procedures for the Internet, on IP, and > independent of access technology. > > I guess the extent to which an SDO thinks these things are worth > developing depends on the extent to which they think a) ECRIT is not a > significant model or to which b) they think there are "emergency" use > cases that are outside the Internet domain or to which c) there is > some complementary subset of use cases for their link technology (e.g. > WiFi phones in an enterprise environment with an "emergency" button > that set up an emergency IP context and are hotlined to the enterprise > softswitch that then does ECRIT procedures to the outside world). The > SDO just needs to decide whether there is a benefit consistent with > the effort in defining/implementing such functionality. I think it's > good if their delegates are aware of ECRIT in making that decision. > > Cheers, > Martin > > -----Original Message----- > From: Kroeselberg, Dirk (NSN - DE/Munich) > [mailto:dirk.kroeselberg@nsn.com] > Sent: Wednesday, 24 March 2010 2:12 PM > To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; > Bernard Aboba > Cc: emu@ietf.org; ecrit@ietf.org > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of > serviceattacks on the emergency.com domain) > > see inline. > > Dirk > > > -----Original Message----- > > From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Wednesday, March 24, 2010 2:15 AM > > To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen; Thomson, > > Martin; Richard Barnes; Bernard Aboba > > Cc: emu@ietf.org; ecrit@ietf.org > > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of > > serviceattacks on the emergency.com domain) > > > > Consider the access out of scope, certainly. Recommend to > > access-specific forums that they shouldn't *assume* the connecting > > device is actually the device making the emergency call (e.g. a WiFi > > device on a portable 3G router) so there's no reliable assumption > > the connecting device can provide an emergency flag. > > I do not see a value in such recommendation from IETF would be. > For layer-2 flags these organizations define such flags. They know. > > > Then it's whatever ECRIT might recommend as appropriate on top of > > IP. I think Richard's questions are along the line of what the value > > of this specific "emergency flag" is at the IP level. > What flag are you refering to? Up to now we were only discussing > options to indicate emergency in EAP, which rather on top of layer-2 > than IP. > > It's not like anyone but the device user knows whether > > the access really is only required for emergency purposes. > > It's a valid question; access policy may just be to bar or allow > > (depending on whether it's a prohibitive or a permissive policy) > > access to emergency specific things - such as routes to PSAPs. A > > flag is not necessarily required to apply that sort of policy. > Without a full subscription (either insufficient authorization or no > subscription) you may want to enter the NW for other things than > emergency. So would you always hotline these entrants to the PSAP? > > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Kroeselberg, Dirk (NSN - DE/Munich) > > [mailto:dirk.kroeselberg@nsn.com] > > Sent: Wednesday, 24 March 2010 10:14 AM > > To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; > > Bernard Aboba > > Cc: emu@ietf.org; ecrit@ietf.org > > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of > > serviceattacks on the emergency.com domain) > > > > > So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, the > > > DSL forum, etc. as to how a device is able to get an > > > unauthenticated IP context on their technology, for whatever > > > purpose, before the policies on permitting/prohibiting ECRIT > > > > but what is the concrete recommendation that you want to give here? > > > > - Drop the access/ISP part from the draft and say access/ISP is > > out-of-scope? > > - move this to EMU? > > - or deal with the EAP/NAI related aspects outside IETF as > you seem to > > suggest (which is already partially the case today due to lack of > > guidance)? > > > > > is on others. I doubt that there's a reasonable assumption that > > > the connecting device can necessarily provide an explicit > > > "emergency intent" flag. > > maybe this is why some people do this via the NAI ;-) > > > > Dirk > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > > Behalf Of ext Dawson, Martin > > > Sent: Tuesday, March 23, 2010 11:44 PM > > > To: Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba > > > Cc: emu@ietf.org; ecrit@ietf.org > > > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of > > > serviceattacks on the emergency.com domain) > > > > > > To elaborate on Brian's "counter point" - some jurisdictions may > > > prefer to *forbid* access to the emergency service from > > > unauthenticated/anonymous access as opposed to *require* it to be > > > supported. Noting this is the equivalent of saying emergency calls > > > for circuit service cannot be made from public phone booths; this > > > is still a possible policy within a given jurisdiction. > > > > > > I'd also posit that not only is it not a priority for IETF but > > > that the question actually needs to be dealt with in more specific > > > forums first. The ECRIT emergency procedures occur at or above the > > > IP layer. Before anything that ECRIT describes becomes relevant, > > > there needs to be an IP context. > > > > > > So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, the > > > DSL forum, etc. as to how a device is able to get an > > > unauthenticated IP context on their technology, for whatever > > > purpose, before the policies on permitting/prohibiting ECRIT > > > procedures or anything else that can be done on IP can be applied. > > > This is easier on some access technologies than it is on others. I > > > doubt that there's a reasonable assumption that the connecting > > > device can necessarily provide an explicit "emergency intent" > > > flag. > > > > > > Cheers, > > > Martin > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > > Behalf Of Brian Rosen > > > Sent: Wednesday, 24 March 2010 8:29 AM > > > To: Thomson, Martin; Richard Barnes; Bernard Aboba > > > Cc: emu@ietf.org; ecrit@ietf.org > > > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of > > > serviceattacks on the emergency.com domain) > > > > > > I think the relevant part of this is 'it's not a high priority'. > > > That is policy of the work group, which we do have control over. > > > > > > If we have nothing else more important to do, then by all means, > > > let's waste a ton of time on unauthenticated access. If we have > > > other > > work to do, > > > perhaps we could defer this. > > > > > > I am not the chair, but in general, anyone can discuss anything, > > > regardless of "priority" on the list. However, when it comes to > > > adopting work group items, I think this should be way down our > > > list. > > > > > > I might also suggest that unauthenticated access really isn't > > > within the charter of the work group. It may be that the reason > > > unauthenticated access may be needed is for emergency calling, but > > > that means we may > > > (eventually) > > > need to ask some other work group to do work for a requirement we > > > generate. > > > It would seem that dealing with EAP is not within the domain of > > > this work group. > > > > > > Brian > > > > > > > > > On 3/23/10 5:14 PM, "Thomson, Martin" > > > <Martin.Thomson@andrew.com> wrote: > > > > > > >> A large percentage (in fact an overwhelming percentage) of > > > PSAPs DON'T > > > >> WANT > > > >> unauthenticated access. Their position is that they > have lots of > > > >> relevant > > > >> experience, and its all bad (tens of thousands of calls > > > with no good > > > >> ones in > > > >> some cases). > > > >> > > > >> However, there are some PSAPs who want it, and there are some > > > >> regulatory environments where there are some lawyers who think > > > >> it's > > > required to > > > >> support > > > >> it in some environments. > > > > > > > > The good thing is: we don't set policy here. I'm not > > > seeing sufficient > > > > evidence that _everyone_ doesn't want this, only that some > > > don't want this. > > > > > > > > I can't comment on priority. That would be policy too. > > > > > > > > --Martin > > > > > > > > > _______________________________________________ > > > 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 rbarnes@bbn.com Mon Mar 29 17:22:46 2010 Return-Path: <rbarnes@bbn.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F7D3A6B0E; Mon, 29 Mar 2010 17:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.142 X-Spam-Level: X-Spam-Status: No, score=-0.142 tagged_above=-999 required=5 tests=[AWL=1.327, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 ZQoICf22z0VB; Mon, 29 Mar 2010 17:22:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 9D2FA3A6B52; Mon, 29 Mar 2010 17:22:38 -0700 (PDT) Received: from [128.89.254.172] (port=53496 helo=[192.168.1.46]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1NwPEW-000Hov-Lj; Mon, 29 Mar 2010 20:23:06 -0400 Message-Id: <2B2C1EAC-FC6A-43DC-8C95-AAD7D7781B91@bbn.com> From: Richard Barnes <rbarnes@bbn.com> To: <Gabor.Bajko@nokia.com> In-Reply-To: <A99B171D26E1564B92D36826128CD66159C060DB70@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 29 Mar 2010 20:23:01 -0400 References: <8B0A9FCBB9832F43971E38010638454F03E24ED000@SISPE7MB1.commscope.com><C7CEAAED.2AF6F%br@brianrosen.net> <8B0A9FCBB9832F43971E38010638454F03E24ED009@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB904@DEMUEXC030.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03E24ED048@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB920@DEMUEXC030.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03E24ED0A9@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DBEDB@DEMUEXC030.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03E24ED22E@SISPE7MB1.commscope.com> <A99B171D26E1564B92D36826128CD66159C060DB70@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: Apple Mail (2.936) Cc: Martin.Dawson@andrew.com, ecrit@ietf.org, emu@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 30 Mar 2010 00:22:46 -0000 Why is this an issue for open APs? Priority? --Richard On Mar 29, 2010, at 8:17 PM, <Gabor.Bajko@nokia.com> wrote: > In an RSNA enabled wifi network you are not redirected to a portal > page, but rather authenticated (if you have the key) before getting > associated. If you do not know the key, you can't associate, and > can't send any 802.11 data packets to the AP. If there was an > indication included in the EAP Request, then the AP would know that > this STA is requesting association for emergency call purposes, and > may be able to give access to it even if the STA is not in posession > of the proper credentials (installing filters would still be > necessary). > > For open access wifi networks, the 802.11 specification has a > slightly different solution than the one suggested below: the AP may > be configured with multiple SSIDs, with one of them being dedicated > for emergency call purposes. This is then signalled in the beacon > frame. STAs willing to place an emergency call would first perform > an active scan, identify the proper SSID and associate (RSNA is not > supposed to be enabled). > > -- Gabor > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of ext Dawson, Martin > Sent: Wednesday, March 24, 2010 7:16 PM > To: Kroeselberg, Dirk (NSN - DE/Munich) > Cc: emu@ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of > serviceattacks on the emergency.com domain) > > I'll describe a potential real world scenario before I try to answer > your question. > > * Public WiFi hotspots generally provide a "free unauthenticated and > anonymous" IP context. > > * Once connected to the access, users are generally "portal locked" > to a single web page that requires further authentication/payment to > proceed. The access may provide some additional "filters" that allow > routes to some subset of news/commercial websites as a "bonus". > > * In order to support unauthenticated/anonymous emergency calling at > this point, the hotspot would need to add the location service, > access to LoST, and a route to the relevant PSAP URI(s) to the > filter list. > > The question I raise is what would be done differently if the > connecting device *could* have provided an indication that it wanted > the connection for the purpose an emergency call? I don't think > anything needs to be done differently. I don't, for example, think > there's any prioritization benefit. An "emergency" type query to the > LCP (HELD option), an emergency service lookup to LoST, and a SIP > session directed toward a PSAP URI are all things that could be > explicitly detected and given priority. Priority isn't an end-goal > in itself in any case. The end goal is reliability and response time > for these emergency related services. The access provider may need > to ensure some service level there. They can do that without needing > to roll dice. And, given they can neither rely on devices to provide > an emergency indication nor trust that indication if they do, they > are likely better off providing the necessary service level for > emergency procedures independently of the device's broadc > asted intentions. > > Let me say that I think the draft is great; it crystallizes a lot of > issues. I just think the section on EAP isn't necessary; it doesn't > describe a generally applicable solution and its presence is likely > to cause confusion as to its significance. In answer to your > question; no, I don't suggest dropping the discussion on filters. I > think that's a fundamental aspect; I think it's orthogonal to the > concept of an "emergency intent indicator". > > Cheers, > Martin > > > > -----Original Message----- > From: Kroeselberg, Dirk (NSN - DE/Munich) [mailto:dirk.kroeselberg@nsn.com > ] > Sent: Thursday, 25 March 2010 2:46 AM > To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; > Bernard Aboba > Cc: emu@ietf.org; ecrit@ietf.org > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of > serviceattacks on the emergency.com domain) > >> facility for supporting emergency connectivity, there's also the >> question (which I may be unfairly be attributing to >> Richard) as to what value it is to the access to know that this >> connectivity has been granted in an "emergency context". >> What's it going to do with this alleged context? > > Considering this in authorization decisions, QoS, setting IP filters > (limited access), priority. Just to give a few examples. > >> No - you wouldn't. But, then, the concept of "hotlining the entrant >> to >> a PSAP" refers to a procedure that isn't described by ECRIT. There's >> no "hotlining". The device knows it wants > > Right, but I was saying it is important for the access network to > recognize that the 'special' entry the MS wants to do is for > emergency, not let the access network roll dices. > Of course hotlining procedures are not in scope of ECRIT, there is > nothing emergency-specific besides installing the right filters > (which by the way we also discuss in the draft - should we also drop > this?). > > Dirk > >> -----Original Message----- >> From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com] >> Sent: Wednesday, March 24, 2010 5:42 AM >> To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen; Thomson, >> Martin; >> Richard Barnes; Bernard Aboba >> Cc: emu@ietf.org; ecrit@ietf.org >> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of >> serviceattacks on the emergency.com domain) >> >> >> Hi Dirk, >> >>> I do not see a value in such recommendation from IETF would be. >>> For layer-2 flags these organizations define such flags. They know. >> >> SDOs set their own agendas; that's fair enough. They don't always >> want >> to consider how their architectures interwork with specifications >> defined by, say, the IETF. So perhaps, as you say, it's pointless. >> While ECRIT procedures are at the IP level and are intended to >> support >> clients that are connecting on IP via a routing device at the access, >> a "link technology SDO" may still persist with the assumption that >> it's the connecting device that negotiates procedures in an emergency >> scenario. Alternatively, they may consider the ECRIT model and decide >> to do something different. It is, as you say, up to them. >> >>> What flag are you refering to? Up to now we were only >> discussing options >>> to indicate emergency in EAP, which rather on top of >> layer-2 than IP. >> >> Which, if I understand it, is about negotiating an IP context in what >> is also an "emergency context". Leaving aside my point above as to >> whether that's a generally effective facility for supporting >> emergency >> connectivity, there's also the question (which I may be unfairly be >> attributing to >> Richard) as to what value it is to the access to know that this >> connectivity has been granted in an "emergency context". >> What's it going to do with this alleged context? >> >>> Without a full subscription (either insufficient authorization or no >>> subscription) you may want to enter the NW for other things than >>> emergency. So would you always hotline these entrants to the PSAP? >> >> No - you wouldn't. But, then, the concept of "hotlining the entrant >> to >> a PSAP" refers to a procedure that isn't described by ECRIT. There's >> no "hotlining". The device knows it wants to initiate an emergency >> call; it gets location from the LIS, gets the PSAP URI from LoST, and >> initiates a SIP session to the PSAP. The proposition of "hotlining" >> based on a layer 2 technology specific procedure is the sort of thing >> I refer to above. An access technology specific SDO may, for their >> own >> reasons, decide to define this sort of thing. I think they're talking >> about use cases that are orthogonal to what ECRIT is describing. >> ECRIT >> describes emergency procedures for the Internet, on IP, and >> independent of access technology. >> >> I guess the extent to which an SDO thinks these things are worth >> developing depends on the extent to which they think a) ECRIT is >> not a >> significant model or to which b) they think there are "emergency" use >> cases that are outside the Internet domain or to which c) there is >> some complementary subset of use cases for their link technology >> (e.g. >> WiFi phones in an enterprise environment with an "emergency" button >> that set up an emergency IP context and are hotlined to the >> enterprise >> softswitch that then does ECRIT procedures to the outside world). The >> SDO just needs to decide whether there is a benefit consistent with >> the effort in defining/implementing such functionality. I think it's >> good if their delegates are aware of ECRIT in making that decision. >> >> Cheers, >> Martin >> >> -----Original Message----- >> From: Kroeselberg, Dirk (NSN - DE/Munich) >> [mailto:dirk.kroeselberg@nsn.com] >> Sent: Wednesday, 24 March 2010 2:12 PM >> To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; >> Bernard Aboba >> Cc: emu@ietf.org; ecrit@ietf.org >> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of >> serviceattacks on the emergency.com domain) >> >> see inline. >> >> Dirk >> >>> -----Original Message----- >>> From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com] >>> Sent: Wednesday, March 24, 2010 2:15 AM >>> To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen; Thomson, >>> Martin; Richard Barnes; Bernard Aboba >>> Cc: emu@ietf.org; ecrit@ietf.org >>> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of >>> serviceattacks on the emergency.com domain) >>> >>> Consider the access out of scope, certainly. Recommend to >>> access-specific forums that they shouldn't *assume* the connecting >>> device is actually the device making the emergency call (e.g. a WiFi >>> device on a portable 3G router) so there's no reliable assumption >>> the connecting device can provide an emergency flag. >> >> I do not see a value in such recommendation from IETF would be. >> For layer-2 flags these organizations define such flags. They know. >> >>> Then it's whatever ECRIT might recommend as appropriate on top of >>> IP. I think Richard's questions are along the line of what the value >>> of this specific "emergency flag" is at the IP level. >> What flag are you refering to? Up to now we were only discussing >> options to indicate emergency in EAP, which rather on top of layer-2 >> than IP. >> >> It's not like anyone but the device user knows whether >>> the access really is only required for emergency purposes. >>> It's a valid question; access policy may just be to bar or allow >>> (depending on whether it's a prohibitive or a permissive policy) >>> access to emergency specific things - such as routes to PSAPs. A >>> flag is not necessarily required to apply that sort of policy. >> Without a full subscription (either insufficient authorization or no >> subscription) you may want to enter the NW for other things than >> emergency. So would you always hotline these entrants to the PSAP? >> >>> >>> Cheers, >>> Martin >>> >>> -----Original Message----- >>> From: Kroeselberg, Dirk (NSN - DE/Munich) >>> [mailto:dirk.kroeselberg@nsn.com] >>> Sent: Wednesday, 24 March 2010 10:14 AM >>> To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; >>> Bernard Aboba >>> Cc: emu@ietf.org; ecrit@ietf.org >>> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of >>> serviceattacks on the emergency.com domain) >>> >>>> So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, the >>>> DSL forum, etc. as to how a device is able to get an >>>> unauthenticated IP context on their technology, for whatever >>>> purpose, before the policies on permitting/prohibiting ECRIT >>> >>> but what is the concrete recommendation that you want to give here? >>> >>> - Drop the access/ISP part from the draft and say access/ISP is >>> out-of-scope? >>> - move this to EMU? >>> - or deal with the EAP/NAI related aspects outside IETF as >> you seem to >>> suggest (which is already partially the case today due to lack of >>> guidance)? >>> >>>> is on others. I doubt that there's a reasonable assumption that >>>> the connecting device can necessarily provide an explicit >>>> "emergency intent" flag. >>> maybe this is why some people do this via the NAI ;-) >>> >>> Dirk >>> >>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>> Behalf Of ext Dawson, Martin >>>> Sent: Tuesday, March 23, 2010 11:44 PM >>>> To: Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba >>>> Cc: emu@ietf.org; ecrit@ietf.org >>>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of >>>> serviceattacks on the emergency.com domain) >>>> >>>> To elaborate on Brian's "counter point" - some jurisdictions may >>>> prefer to *forbid* access to the emergency service from >>>> unauthenticated/anonymous access as opposed to *require* it to be >>>> supported. Noting this is the equivalent of saying emergency calls >>>> for circuit service cannot be made from public phone booths; this >>>> is still a possible policy within a given jurisdiction. >>>> >>>> I'd also posit that not only is it not a priority for IETF but >>>> that the question actually needs to be dealt with in more specific >>>> forums first. The ECRIT emergency procedures occur at or above the >>>> IP layer. Before anything that ECRIT describes becomes relevant, >>>> there needs to be an IP context. >>>> >>>> So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, the >>>> DSL forum, etc. as to how a device is able to get an >>>> unauthenticated IP context on their technology, for whatever >>>> purpose, before the policies on permitting/prohibiting ECRIT >>>> procedures or anything else that can be done on IP can be applied. >>>> This is easier on some access technologies than it is on others. I >>>> doubt that there's a reasonable assumption that the connecting >>>> device can necessarily provide an explicit "emergency intent" >>>> flag. >>>> >>>> Cheers, >>>> Martin >>>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>> Behalf Of Brian Rosen >>>> Sent: Wednesday, 24 March 2010 8:29 AM >>>> To: Thomson, Martin; Richard Barnes; Bernard Aboba >>>> Cc: emu@ietf.org; ecrit@ietf.org >>>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of >>>> serviceattacks on the emergency.com domain) >>>> >>>> I think the relevant part of this is 'it's not a high priority'. >>>> That is policy of the work group, which we do have control over. >>>> >>>> If we have nothing else more important to do, then by all means, >>>> let's waste a ton of time on unauthenticated access. If we have >>>> other >>> work to do, >>>> perhaps we could defer this. >>>> >>>> I am not the chair, but in general, anyone can discuss anything, >>>> regardless of "priority" on the list. However, when it comes to >>>> adopting work group items, I think this should be way down our >>>> list. >>>> >>>> I might also suggest that unauthenticated access really isn't >>>> within the charter of the work group. It may be that the reason >>>> unauthenticated access may be needed is for emergency calling, but >>>> that means we may >>>> (eventually) >>>> need to ask some other work group to do work for a requirement we >>>> generate. >>>> It would seem that dealing with EAP is not within the domain of >>>> this work group. >>>> >>>> Brian >>>> >>>> >>>> On 3/23/10 5:14 PM, "Thomson, Martin" >>>> <Martin.Thomson@andrew.com> wrote: >>>> >>>>>> A large percentage (in fact an overwhelming percentage) of >>>> PSAPs DON'T >>>>>> WANT >>>>>> unauthenticated access. Their position is that they >> have lots of >>>>>> relevant >>>>>> experience, and its all bad (tens of thousands of calls >>>> with no good >>>>>> ones in >>>>>> some cases). >>>>>> >>>>>> However, there are some PSAPs who want it, and there are some >>>>>> regulatory environments where there are some lawyers who think >>>>>> it's >>>> required to >>>>>> support >>>>>> it in some environments. >>>>> >>>>> The good thing is: we don't set policy here. I'm not >>>> seeing sufficient >>>>> evidence that _everyone_ doesn't want this, only that some >>>> don't want this. >>>>> >>>>> I can't comment on priority. That would be policy too. >>>>> >>>>> --Martin >>>> >>>> >>>> _______________________________________________ >>>> 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 Gabor.Bajko@nokia.com Mon Mar 29 17:32:41 2010 Return-Path: <Gabor.Bajko@nokia.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318B73A63EC for <ecrit@core3.amsl.com>; Mon, 29 Mar 2010 17:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.169 X-Spam-Level: X-Spam-Status: No, score=-4.169 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 zCo8bMCnU8Eu for <ecrit@core3.amsl.com>; Mon, 29 Mar 2010 17:32:38 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D933C3A6B11 for <ecrit@ietf.org>; Mon, 29 Mar 2010 17:32:37 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o2U0WsY6025033; Tue, 30 Mar 2010 03:32:54 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Mar 2010 03:32:54 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Mar 2010 03:32:49 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 30 Mar 2010 02:32:48 +0200 From: <Gabor.Bajko@nokia.com> To: <rbarnes@bbn.com> Date: Tue, 30 Mar 2010 02:32:46 +0200 Thread-Topic: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrPnzorzHpjrDHSRGmpmzm5lRpFjwAAIzTw Message-ID: <A99B171D26E1564B92D36826128CD66159C060DB78@NOK-EUMSG-01.mgdnok.nokia.com> References: <8B0A9FCBB9832F43971E38010638454F03E24ED000@SISPE7MB1.commscope.com><C7CEAAED.2AF6F%br@brianrosen.net> <8B0A9FCBB9832F43971E38010638454F03E24ED009@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB904@DEMUEXC030.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03E24ED048@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DB920@DEMUEXC030.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03E24ED0A9@SISPE7MB1.commscope.com> <8C51C7A529FC9D49843ACF5AE2FFBF67025DBEDB@DEMUEXC030.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03E24ED22E@SISPE7MB1.commscope.com> <A99B171D26E1564B92D36826128CD66159C060DB70@NOK-EUMSG-01.mgdnok.nokia.com> <2B2C1EAC-FC6A-43DC-8C95-AAD7D7781B91@bbn.com> In-Reply-To: <2B2C1EAC-FC6A-43DC-8C95-AAD7D7781B91@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Mar 2010 00:32:49.0306 (UTC) FILETIME=[86943FA0:01CACFA0] X-Nokia-AV: Clean Cc: Martin.Dawson@andrew.com, ecrit@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 30 Mar 2010 00:32:41 -0000 "open AP" does not always mean access to Internet. It may, but in many case= s you end up being redirected to a portal page and required to pay. With th= e dedicated SSID, you know in advance that you'll get access to ES and not = redirected to a portal page. -- gabor -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of e= xt Richard Barnes Sent: Monday, March 29, 2010 5:23 PM To: Bajko Gabor (Nokia-CIC/MtView) Cc: Martin.Dawson@andrew.com; ecrit@ietf.org; emu@ietf.org Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceatt= acks on the emergency.com domain) Why is this an issue for open APs? Priority? --Richard On Mar 29, 2010, at 8:17 PM, <Gabor.Bajko@nokia.com> wrote: > In an RSNA enabled wifi network you are not redirected to a portal > page, but rather authenticated (if you have the key) before getting > associated. If you do not know the key, you can't associate, and can't > send any 802.11 data packets to the AP. If there was an indication > included in the EAP Request, then the AP would know that this STA is > requesting association for emergency call purposes, and may be able to > give access to it even if the STA is not in posession of the proper > credentials (installing filters would still be necessary). > > For open access wifi networks, the 802.11 specification has a slightly > different solution than the one suggested below: the AP may be > configured with multiple SSIDs, with one of them being dedicated for > emergency call purposes. This is then signalled in the beacon frame. > STAs willing to place an emergency call would first perform an active > scan, identify the proper SSID and associate (RSNA is not supposed to > be enabled). > > -- Gabor > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of ext Dawson, Martin > Sent: Wednesday, March 24, 2010 7:16 PM > To: Kroeselberg, Dirk (NSN - DE/Munich) > Cc: emu@ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of > serviceattacks on the emergency.com domain) > > I'll describe a potential real world scenario before I try to answer > your question. > > * Public WiFi hotspots generally provide a "free unauthenticated and > anonymous" IP context. > > * Once connected to the access, users are generally "portal locked" > to a single web page that requires further authentication/payment to > proceed. The access may provide some additional "filters" that allow > routes to some subset of news/commercial websites as a "bonus". > > * In order to support unauthenticated/anonymous emergency calling at > this point, the hotspot would need to add the location service, access > to LoST, and a route to the relevant PSAP URI(s) to the filter list. > > The question I raise is what would be done differently if the > connecting device *could* have provided an indication that it wanted > the connection for the purpose an emergency call? I don't think > anything needs to be done differently. I don't, for example, think > there's any prioritization benefit. An "emergency" type query to the > LCP (HELD option), an emergency service lookup to LoST, and a SIP > session directed toward a PSAP URI are all things that could be > explicitly detected and given priority. Priority isn't an end-goal in > itself in any case. The end goal is reliability and response time for > these emergency related services. The access provider may need to > ensure some service level there. They can do that without needing to > roll dice. And, given they can neither rely on devices to provide an > emergency indication nor trust that indication if they do, they are > likely better off providing the necessary service level for emergency > procedures independently of the device's broadc > asted intentions. > > Let me say that I think the draft is great; it crystallizes a lot of > issues. I just think the section on EAP isn't necessary; it doesn't > describe a generally applicable solution and its presence is likely to > cause confusion as to its significance. In answer to your question; > no, I don't suggest dropping the discussion on filters. I think that's > a fundamental aspect; I think it's orthogonal to the concept of an > "emergency intent indicator". > > Cheers, > Martin > > > > -----Original Message----- > From: Kroeselberg, Dirk (NSN - DE/Munich) > [mailto:dirk.kroeselberg@nsn.com ] > Sent: Thursday, 25 March 2010 2:46 AM > To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; > Bernard Aboba > Cc: emu@ietf.org; ecrit@ietf.org > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of > serviceattacks on the emergency.com domain) > >> facility for supporting emergency connectivity, there's also the >> question (which I may be unfairly be attributing to >> Richard) as to what value it is to the access to know that this >> connectivity has been granted in an "emergency context". >> What's it going to do with this alleged context? > > Considering this in authorization decisions, QoS, setting IP filters > (limited access), priority. Just to give a few examples. > >> No - you wouldn't. But, then, the concept of "hotlining the entrant >> to a PSAP" refers to a procedure that isn't described by ECRIT. >> There's no "hotlining". The device knows it wants > > Right, but I was saying it is important for the access network to > recognize that the 'special' entry the MS wants to do is for > emergency, not let the access network roll dices. > Of course hotlining procedures are not in scope of ECRIT, there is > nothing emergency-specific besides installing the right filters (which > by the way we also discuss in the draft - should we also drop this?). > > Dirk > >> -----Original Message----- >> From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com] >> Sent: Wednesday, March 24, 2010 5:42 AM >> To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen; Thomson, >> Martin; Richard Barnes; Bernard Aboba >> Cc: emu@ietf.org; ecrit@ietf.org >> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of >> serviceattacks on the emergency.com domain) >> >> >> Hi Dirk, >> >>> I do not see a value in such recommendation from IETF would be. >>> For layer-2 flags these organizations define such flags. They know. >> >> SDOs set their own agendas; that's fair enough. They don't always >> want >> to consider how their architectures interwork with specifications >> defined by, say, the IETF. So perhaps, as you say, it's pointless. >> While ECRIT procedures are at the IP level and are intended to >> support >> clients that are connecting on IP via a routing device at the access, >> a "link technology SDO" may still persist with the assumption that >> it's the connecting device that negotiates procedures in an emergency >> scenario. Alternatively, they may consider the ECRIT model and decide >> to do something different. It is, as you say, up to them. >> >>> What flag are you refering to? Up to now we were only >> discussing options >>> to indicate emergency in EAP, which rather on top of >> layer-2 than IP. >> >> Which, if I understand it, is about negotiating an IP context in what >> is also an "emergency context". Leaving aside my point above as to >> whether that's a generally effective facility for supporting >> emergency >> connectivity, there's also the question (which I may be unfairly be >> attributing to >> Richard) as to what value it is to the access to know that this >> connectivity has been granted in an "emergency context". >> What's it going to do with this alleged context? >> >>> Without a full subscription (either insufficient authorization or no >>> subscription) you may want to enter the NW for other things than >>> emergency. So would you always hotline these entrants to the PSAP? >> >> No - you wouldn't. But, then, the concept of "hotlining the entrant >> to >> a PSAP" refers to a procedure that isn't described by ECRIT. There's >> no "hotlining". The device knows it wants to initiate an emergency >> call; it gets location from the LIS, gets the PSAP URI from LoST, and >> initiates a SIP session to the PSAP. The proposition of "hotlining" >> based on a layer 2 technology specific procedure is the sort of thing >> I refer to above. An access technology specific SDO may, for their >> own >> reasons, decide to define this sort of thing. I think they're talking >> about use cases that are orthogonal to what ECRIT is describing. >> ECRIT >> describes emergency procedures for the Internet, on IP, and >> independent of access technology. >> >> I guess the extent to which an SDO thinks these things are worth >> developing depends on the extent to which they think a) ECRIT is >> not a >> significant model or to which b) they think there are "emergency" use >> cases that are outside the Internet domain or to which c) there is >> some complementary subset of use cases for their link technology >> (e.g. >> WiFi phones in an enterprise environment with an "emergency" button >> that set up an emergency IP context and are hotlined to the >> enterprise >> softswitch that then does ECRIT procedures to the outside world). The >> SDO just needs to decide whether there is a benefit consistent with >> the effort in defining/implementing such functionality. I think it's >> good if their delegates are aware of ECRIT in making that decision. >> >> Cheers, >> Martin >> >> -----Original Message----- >> From: Kroeselberg, Dirk (NSN - DE/Munich) >> [mailto:dirk.kroeselberg@nsn.com] >> Sent: Wednesday, 24 March 2010 2:12 PM >> To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; >> Bernard Aboba >> Cc: emu@ietf.org; ecrit@ietf.org >> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of >> serviceattacks on the emergency.com domain) >> >> see inline. >> >> Dirk >> >>> -----Original Message----- >>> From: ext Dawson, Martin [mailto:Martin.Dawson@andrew.com] >>> Sent: Wednesday, March 24, 2010 2:15 AM >>> To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen; Thomson, >>> Martin; Richard Barnes; Bernard Aboba >>> Cc: emu@ietf.org; ecrit@ietf.org >>> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of >>> serviceattacks on the emergency.com domain) >>> >>> Consider the access out of scope, certainly. Recommend to >>> access-specific forums that they shouldn't *assume* the connecting >>> device is actually the device making the emergency call (e.g. a WiFi >>> device on a portable 3G router) so there's no reliable assumption >>> the connecting device can provide an emergency flag. >> >> I do not see a value in such recommendation from IETF would be. >> For layer-2 flags these organizations define such flags. They know. >> >>> Then it's whatever ECRIT might recommend as appropriate on top of >>> IP. I think Richard's questions are along the line of what the value >>> of this specific "emergency flag" is at the IP level. >> What flag are you refering to? Up to now we were only discussing >> options to indicate emergency in EAP, which rather on top of layer-2 >> than IP. >> >> It's not like anyone but the device user knows whether >>> the access really is only required for emergency purposes. >>> It's a valid question; access policy may just be to bar or allow >>> (depending on whether it's a prohibitive or a permissive policy) >>> access to emergency specific things - such as routes to PSAPs. A >>> flag is not necessarily required to apply that sort of policy. >> Without a full subscription (either insufficient authorization or no >> subscription) you may want to enter the NW for other things than >> emergency. So would you always hotline these entrants to the PSAP? >> >>> >>> Cheers, >>> Martin >>> >>> -----Original Message----- >>> From: Kroeselberg, Dirk (NSN - DE/Munich) >>> [mailto:dirk.kroeselberg@nsn.com] >>> Sent: Wednesday, 24 March 2010 10:14 AM >>> To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; >>> Bernard Aboba >>> Cc: emu@ietf.org; ecrit@ietf.org >>> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of >>> serviceattacks on the emergency.com domain) >>> >>>> So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, the >>>> DSL forum, etc. as to how a device is able to get an >>>> unauthenticated IP context on their technology, for whatever >>>> purpose, before the policies on permitting/prohibiting ECRIT >>> >>> but what is the concrete recommendation that you want to give here? >>> >>> - Drop the access/ISP part from the draft and say access/ISP is >>> out-of-scope? >>> - move this to EMU? >>> - or deal with the EAP/NAI related aspects outside IETF as >> you seem to >>> suggest (which is already partially the case today due to lack of >>> guidance)? >>> >>>> is on others. I doubt that there's a reasonable assumption that >>>> the connecting device can necessarily provide an explicit >>>> "emergency intent" flag. >>> maybe this is why some people do this via the NAI ;-) >>> >>> Dirk >>> >>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>> Behalf Of ext Dawson, Martin >>>> Sent: Tuesday, March 23, 2010 11:44 PM >>>> To: Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba >>>> Cc: emu@ietf.org; ecrit@ietf.org >>>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of >>>> serviceattacks on the emergency.com domain) >>>> >>>> To elaborate on Brian's "counter point" - some jurisdictions may >>>> prefer to *forbid* access to the emergency service from >>>> unauthenticated/anonymous access as opposed to *require* it to be >>>> supported. Noting this is the equivalent of saying emergency calls >>>> for circuit service cannot be made from public phone booths; this >>>> is still a possible policy within a given jurisdiction. >>>> >>>> I'd also posit that not only is it not a priority for IETF but >>>> that the question actually needs to be dealt with in more specific >>>> forums first. The ECRIT emergency procedures occur at or above the >>>> IP layer. Before anything that ECRIT describes becomes relevant, >>>> there needs to be an IP context. >>>> >>>> So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, the >>>> DSL forum, etc. as to how a device is able to get an >>>> unauthenticated IP context on their technology, for whatever >>>> purpose, before the policies on permitting/prohibiting ECRIT >>>> procedures or anything else that can be done on IP can be applied. >>>> This is easier on some access technologies than it is on others. I >>>> doubt that there's a reasonable assumption that the connecting >>>> device can necessarily provide an explicit "emergency intent" >>>> flag. >>>> >>>> Cheers, >>>> Martin >>>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>> Behalf Of Brian Rosen >>>> Sent: Wednesday, 24 March 2010 8:29 AM >>>> To: Thomson, Martin; Richard Barnes; Bernard Aboba >>>> Cc: emu@ietf.org; ecrit@ietf.org >>>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of >>>> serviceattacks on the emergency.com domain) >>>> >>>> I think the relevant part of this is 'it's not a high priority'. >>>> That is policy of the work group, which we do have control over. >>>> >>>> If we have nothing else more important to do, then by all means, >>>> let's waste a ton of time on unauthenticated access. If we have >>>> other >>> work to do, >>>> perhaps we could defer this. >>>> >>>> I am not the chair, but in general, anyone can discuss anything, >>>> regardless of "priority" on the list. However, when it comes to >>>> adopting work group items, I think this should be way down our >>>> list. >>>> >>>> I might also suggest that unauthenticated access really isn't >>>> within the charter of the work group. It may be that the reason >>>> unauthenticated access may be needed is for emergency calling, but >>>> that means we may >>>> (eventually) >>>> need to ask some other work group to do work for a requirement we >>>> generate. >>>> It would seem that dealing with EAP is not within the domain of >>>> this work group. >>>> >>>> Brian >>>> >>>> >>>> On 3/23/10 5:14 PM, "Thomson, Martin" >>>> <Martin.Thomson@andrew.com> wrote: >>>> >>>>>> A large percentage (in fact an overwhelming percentage) of >>>> PSAPs DON'T >>>>>> WANT >>>>>> unauthenticated access. Their position is that they >> have lots of >>>>>> relevant >>>>>> experience, and its all bad (tens of thousands of calls >>>> with no good >>>>>> ones in >>>>>> some cases). >>>>>> >>>>>> However, there are some PSAPs who want it, and there are some >>>>>> regulatory environments where there are some lawyers who think >>>>>> it's >>>> required to >>>>>> support >>>>>> it in some environments. >>>>> >>>>> The good thing is: we don't set policy here. I'm not >>>> seeing sufficient >>>>> evidence that _everyone_ doesn't want this, only that some >>>> don't want this. >>>>> >>>>> I can't comment on priority. That would be policy too. >>>>> >>>>> --Martin >>>> >>>> >>>> _______________________________________________ >>>> 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From RMarshall@telecomsys.com Tue Mar 30 14:25:34 2010 Return-Path: <RMarshall@telecomsys.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD9DB3A684A for <ecrit@core3.amsl.com>; Tue, 30 Mar 2010 14:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 YPjfILwo926p for <ecrit@core3.amsl.com>; Tue, 30 Mar 2010 14:25:33 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [199.165.246.12]) by core3.amsl.com (Postfix) with ESMTP id A1D363A6B31 for <ecrit@ietf.org>; Tue, 30 Mar 2010 14:25:32 -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 <T94bbdfbe000a200c491224@sea-mimesweep-1.telecomsys.com>; Tue, 30 Mar 2010 14:26:02 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Mar 2010 14:25:25 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657511BC0C8F@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <A5AE1957-2DAC-4018-9E9A-9CAC501C8BEE@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF77 ECRIT Meeting Minutes Now Posted Thread-Index: AcrQRh1SIPfoJXWBSqOC6HelKm7sMAAB4B6Q References: <C7D7D30B.22DEB%mlinsner@cisco.com> <A5AE1957-2DAC-4018-9E9A-9CAC501C8BEE@bbn.com> From: "Roger Marshall" <RMarshall@telecomsys.com> To: "ecrit" <ecrit@ietf.org> Subject: [Ecrit] IETF77 ECRIT Meeting Minutes Now Posted X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 30 Mar 2010 21:25:34 -0000 All: The consolidated meeting minutes for the IETF77 ECRIT meeting held Monday, 3/22/2010, have now been uploaded to the Meeting Materials page. These are a compilation of written notes by Paul Kyzivat and Byron Smith. Many thanks to both! See the following link: http://www.ietf.org/proceedings/10mar/minutes/ecrit.txt Please let me know if there are any errors/omissions that need fixing. Regards, Roger Marshall. ECRIT Secretary CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. From mlinsner@cisco.com Wed Mar 31 13:17:09 2010 Return-Path: <mlinsner@cisco.com> X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043CB3A692A for <ecrit@core3.amsl.com>; Wed, 31 Mar 2010 13:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.969 X-Spam-Level: X-Spam-Status: No, score=-8.969 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HpiqV7G3+97 for <ecrit@core3.amsl.com>; Wed, 31 Mar 2010 13:17:08 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 37D883A6A73 for <ecrit@ietf.org>; Wed, 31 Mar 2010 13:17:01 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJtKs0urR7H+/2dsb2JhbACbOXGoFJkkhQAE X-IronPort-AV: E=Sophos;i="4.51,343,1267401600"; d="scan'208";a="108417617" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 31 Mar 2010 20:17:32 +0000 Received: from [10.116.195.124] (rtp-mlinsner-87111.cisco.com [10.116.195.124]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2VKHVwV017776 for <ecrit@ietf.org>; Wed, 31 Mar 2010 20:17:31 GMT User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 31 Mar 2010 16:17:28 -0400 From: Marc Linsner <mlinsner@cisco.com> To: ecrit <ecrit@ietf.org> Message-ID: <C7D92618.22ECC%mlinsner@cisco.com> Thread-Topic: SIP Location Conveyance Thread-Index: AcrRDy8x5IbsuMvK3EewPd5/R4hHLQ== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [Ecrit] SIP Location Conveyance X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 31 Mar 2010 20:17:09 -0000 All, There are some proposed changes to SIP Location Conveyance that were discussed in the SIPCore meeting last week that *could* affect both PhoneBCP and Framework. See: http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#Draft-sipcore-loc ation-conveyance Both Brian Rosen and James Polk (current authors of loc-conveyance) are aware of the proposed changes, and Brian stated he would keep ecrit aware of anything pertinent to our drafts. Feel free to join/participate in the sipcore mail list (https://www.ietf.org/mailman/listinfo/sipcore) if you have interest in these proposals. Thanks, -Marc & Richard-