From dirk.kroeselberg@nsn.com Thu Apr 1 02:15: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 672593A694C; Thu, 1 Apr 2010 02:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.281 X-Spam-Level: * X-Spam-Status: No, score=1.281 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001, 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 YWMjz9THxBqT; Thu, 1 Apr 2010 02:15:12 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id AF2D43A68E1; Thu, 1 Apr 2010 02:15:10 -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 o319Fbsg005834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 Apr 2010 11:15:37 +0200 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 o319FWCD031255; Thu, 1 Apr 2010 11:15:37 +0200 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 11:15:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Apr 2010 11:15:32 +0200 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF67026458C2@DEMUEXC030.nsn-intra.net> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E24ED460@SISPE7MB1.commscope.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) Thread-Index: AcrKzRfOc6w4ZPWsrkimclW4dAPFuwAAHhnQAACVA9cAAQknQAACQEEAAAQ84AAAE8l+zAAAihfgAGV2j3oAHFLc8AENAMkg References: <8B0A9FCBB9832F43971E38010638454F03E24ED180@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03E24ED460@SISPE7MB1.commscope.com> From: "Kroeselberg, Dirk (NSN - DE/Munich)" To: "ext Dawson, Martin" , =?iso-8859-1?Q?Andres_K=FCtt?= X-OriginalArrivalTime: 01 Apr 2010 09:15:34.0161 (UTC) FILETIME=[E250D010:01CAD17B] Cc: emu@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] [Emu] 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 09:15:14 -0000 Martin, see inline. Thanks, Dirk=20 > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > Behalf Of ext Dawson, Martin > Sent: Saturday, March 27, 2010 1:51 AM > To: Andres K=FCtt > Cc: emu@ietf.org; ecrit@ietf.org > Subject: Re: [Emu] [Ecrit] emergency access and EAP-TLS (and=20 > denial of serviceattacks on the emergency.com domain) >=20 > It seems to me that fly in the ointment is this point: >=20 > > - because the protocol used is opaque, the access provider=20 > has no way to > > distinguish between session establishment, an actual EC,=20 > ordinary IM traffic > > or common web browsing (one could envision a VoIP=20 > application that uses HTTP > > bindings for signaling purposes) >=20 > I agree with this point. Effectively it says that the access=20 > has no way of knowing whether the third party application=20 > actually is just supporting an emergency call. Not only is it=20 > opaque but it has no control signalling relationship with the=20 > access either - so the access has no independent way to=20 > inform the application that the client is only supposed to be=20 > doing an emergency call. I am not sure whether there is any need for the 'access' informing the = application, but of course there are examples where a signaling = relationship between the access/ISP part and the application exists. So = here you seem to be talking about a specific subset of access only. Or do we want to limit ourselves to such subset? >=20 > I do not see how the "it's understood to be an emergency IP=20 > context" knowledge facilitates any of this policy control.=20 > Out of control is out of control. >=20 >=20 > On you first point about the UI implementation. I have...=20 > hang on... five applications on my Android device menu that=20 > do voice in one form or another. Frankly, it would be most=20 > convenient to have one there that just said "Emergency" and=20 > whose sole purpose was to do the ECRIT procedures (as=20 > described in this draft). That would be an ECRIT direct=20 > calling client. Access networks can most readily support=20 > policies that allow for this mode of use - without the third=20 > party trust issues that you raise. Could you please detail what would be required to make 'Access networks = can most readily support...' work, i.e., allow the client access when = not yet connected (Andres' scenario)? Especially for access networks = other than WLAN. >=20 > Cheers, > Martin >=20 > -----Original Message----- > From: Andres K=FCtt [mailto:andres.kytt@skype.net]=20 > 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=20 > of serviceattacks on the emergency.com domain) >=20 > Hi, >=20 > Certainly. Let's assume the following: > - existing UI implementation is used (i.e. the software=20 > provider will not > build a separate SIP client with distinct UI just for=20 > emergency calling) > - the client is multifunctional i.e. it is used for more=20 > things than calling > - the client has been authenticated already, this kind of=20 > software tends to > run in the background continuously > - there is no network connection >=20 > Given these assumptions EC would work like this: > - user attempts to place an EC > - the client, being offline, attempts to re-establish it's=20 > session with the > network/server (i.e. get online) > - at this point, the access provider needs to know that the=20 > session being > established is for the purposes of an EC and needs to allow=20 > 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=20 > connection as the access > provider has no way of knowing whether the call has ended or not. >=20 > Please note that > - session establishment happens before the call and access=20 > provider has no > idea whether this is because of ordinary client use or EC.=20 > 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=20 > has no way to > distinguish between session establishment, an actual EC,=20 > ordinary IM traffic > or common web browsing (one could envision a VoIP application=20 > that uses HTTP > bindings for signaling purposes) >=20 > Thus, regardless of the methods used, the access provider=20 > needs to trust the > service provider to only use the connection for emergency calling and > nothing else. =20 >=20 > As for the session establishment, one way to do this is the=20 > way Skype Access > (you buy WIFI time using your Skype credit) works: > - the client wraps a session request in a DNS query against=20 > 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 >=20 > Yours, > Andres >=20 > On 3/24/10 12:55 PM, "Dawson, Martin"=20 > wrote: >=20 > > Hi Andres, > >=20 > > Could you take us step by step through the establishment of=20 > the anonymous > > connection and the initiation of the emergency call and=20 > highlight where/how > > this notification mechanism would be invoked and what it would do? > >=20 > > I would find that helpful. I'm interested in how people see=20 > the access network > > being able to limit the use of an arbitrary third party=20 > VoIP application to > > emergency calling, if that's the intent, in the context of > > unauthenticated/anonymous access. > >=20 > > BTW, I haven't said that access is completely out of scope.=20 > Actually, it > > obviously is in scope both in terms of what facilities it=20 > provides and what > > its policies are with respect to emergency calling=20 > procedures in the context > > of unaurthenticated/anonymous connections. It's the concept=20 > of gating the > > establishment of unauthenticated/anonymous connections on=20 > some kind of a > > priori knowledge or indication that its for the purpose of=20 > an emergency call > > that I question. > >=20 > > Regards, > > Martin > >=20 > > -----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) > >=20 > > Hi, > > =20 > > Leaving access completely out of scope is of course the=20 > easiest course > > but some synchronization must remain. In case of Skype,=20 > there is no way for > > the access provider to tell whether the user is placing an=20 > emergency call or > > chatting with their friends as the protocol used is opaque=20 > for the outsider. > > This is true in any case the service provider uses a=20 > protocol not known or > > understood by access provider and we must assume this can=20 > legally occur. > > Thus, should anonymous access be required, a mechanism must=20 > exist to notify > > the access provider about an attempted emergency call. > >=20 > > Yours, > > Andres=20 > >=20 > >=20 > > On 3/24/10 3:14 AM, "Dawson, Martin"=20 > wrote: > >=20 > >> Consider the access out of scope, certainly. Recommend to=20 > access-specific > >> forums that they shouldn't *assume* the connecting device=20 > is actually the > >> device making the emergency call (e.g. a WiFi device on a=20 > portable 3G router) > >> so there's no reliable assumption the connecting device=20 > can provide an > >> emergency flag. > >>=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 what the value=20 > of this specific > >> "emergency flag" is at the IP level. It's not like anyone=20 > but the device user > >> knows whether the access really is only required for=20 > emergency purposes. It's > >> a valid question; access policy may just be to bar or=20 > allow (depending on > >> whether it's a prohibitive or a permissive policy) access=20 > to emergency > >> specific things - such as routes to PSAPs. A flag is not=20 > necessarily required > >> to apply that sort of policy. > >>=20 > >> Cheers, > >> Martin > >>=20 > >> -----Original Message----- > >> From: Kroeselberg, Dirk (NSN - DE/Munich)=20 > [mailto:dirk.kroeselberg@nsn.com] > >> 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 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=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 > >>> 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=20 > 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" > >>> wrote: > >>>=20 > >>>>> A large percentage (in fact an overwhelming percentage) of > >>> 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 > >>> 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 > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >=20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu >=20 From andreaf@cs.columbia.edu Fri Apr 2 12:29: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 C04373A6B81 for ; Fri, 2 Apr 2010 12:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.468 X-Spam-Level: X-Spam-Status: No, score=-5.468 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 4s7DNJRvI8zt for ; Fri, 2 Apr 2010 12:29:19 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 976633A6B64 for ; Fri, 2 Apr 2010 11:56:59 -0700 (PDT) Received: from irtdesk1.cs.columbia.edu (irtdesk1.cs.columbia.edu [128.59.22.127]) (user=agf2104 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o32IvWwj007275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Apr 2010 14:57:32 -0400 (EDT) Message-ID: <4BB63E1C.4040802@cs.columbia.edu> Date: Fri, 02 Apr 2010 14:57:32 -0400 From: Andrea G Forte User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: multipart/alternative; boundary="------------000702000407070709050409" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Subject: [Ecrit] Fwd: New Version Notification for draft-forte-lost-extensions-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: Fri, 02 Apr 2010 19:29:20 -0000 This is a multi-part message in MIME format. --------------000702000407070709050409 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, we have submitted a new draft on LoST extensions. As per previous discussion in the working group this draft has been submitted as an individual submission. You can find the abstract below. The following changes have been made: - A "served by" query has been added for all those services with a service region (e.g., pizza delivery). - We make use of other shapes such as the elliptic shape for finding services in the direction of movement that is, neither at the user's current location nor at his final destination. - We define new elements in a new name-space for the new types of queries. - Various clarifications and improvements. Any comment on this draft would be much appreciated. URL: http://ietfreport.isoc.org/idref/draft-forte-lost-extensions/ Regards, -Andrea -------- Original Message -------- Subject: New Version Notification for draft-forte-lost-extensions-00 Date: Wed, 31 Mar 2010 13:02:15 -0700 (PDT) From: IETF I-D Submission Tool To: andreaf@cs.columbia.edu CC: hgs@cs.columbia.edu A new version of I-D, draft-forte-lost-extensions-00.txt has been successfully submitted by Andrea Forte and posted to the IETF repository. Filename: draft-forte-lost-extensions Revision: 00 Title: Location-to-Service Translation Protocol (LoST) Extensions Creation_date: 2010-03-31 WG ID: Independent Submission Number_of_pages: 18 Abstract: An important class of location-based services answer the question "What instances of this service are closest to me?" Examples include finding restaurants, gas stations, stores, automated teller machines, wireless access points (hot spots) or parking spaces. Currently, the Location-to-Service Translation (LoST) protocol only supports mapping locations to a single service based on service regions. This document describes an extension that allows queries of the type "N nearest", "within distance X" and "served by". The IETF Secretariat. --------------000702000407070709050409 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear all,

we have submitted a new draft on LoST extensions. As per previous discussion in the working group this draft has been submitted as an individual submission. You can find the abstract below.

The following changes have been made:
- A "served by" query has been added for all those services with a service region (e.g., pizza delivery).
- We make use of other shapes such as the elliptic shape for finding services in the direction of movement that is, neither at the user's current location nor at his final destination.
- We define new elements in a new name-space for the new types of queries.
- Various clarifications and improvements.

Any comment on this draft would be much appreciated.

URL: http://ietfreport.isoc.org/idref/draft-forte-lost-extensions/

Regards,
-Andrea


-------- Original Message --------
Subject: New Version Notification for draft-forte-lost-extensions-00
Date: Wed, 31 Mar 2010 13:02:15 -0700 (PDT)
From: IETF I-D Submission Tool <idsubmission@ietf.org>
To: andreaf@cs.columbia.edu
CC: hgs@cs.columbia.edu 


A new version of I-D, draft-forte-lost-extensions-00.txt has been successfully submitted by Andrea Forte and posted to the IETF repository.

Filename:	 draft-forte-lost-extensions
Revision:	 00
Title:		 Location-to-Service Translation Protocol (LoST) Extensions
Creation_date:	 2010-03-31
WG ID:		 Independent Submission
Number_of_pages: 18

Abstract:
An important class of location-based services answer the question
"What instances of this service are closest to me?"  Examples include
finding restaurants, gas stations, stores, automated teller machines,
wireless access points (hot spots) or parking spaces.  Currently, the
Location-to-Service Translation (LoST) protocol only supports mapping
locations to a single service based on service regions.  This
document describes an extension that allows queries of the type "N
nearest", "within distance X" and "served by".
                                                                                  


The IETF Secretariat.
--------------000702000407070709050409-- From hannes.tschofenig@nsn.com Mon Apr 5 01:34: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 BDA353A6825 for ; Mon, 5 Apr 2010 01:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.9 X-Spam-Level: * X-Spam-Status: No, score=1.9 tagged_above=-999 required=5 tests=[AWL=1.599, BAYES_50=0.001, 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 zSAj78aNesJa for ; Mon, 5 Apr 2010 01:34:09 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 99FC33A6817 for ; Mon, 5 Apr 2010 01:34:08 -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 o358Y3pT032024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Apr 2010 10:34:03 +0200 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 o358Y2XE021553; Mon, 5 Apr 2010 10:34:02 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Apr 2010 10:34:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Apr 2010 11:33:38 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45026A06FF@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-phonebcp requirements on IM protocolsin endpoints Thread-Index: AcqqrO3QMhTsTpslQ4W1aJrQ/1UvtgAIDZpACnNdEQA= References: <00c401caaaac$ef3efd60$cdbcf820$@hellstrom@omnitor.se> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Bernard Aboba" , =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= , "Ecrit@Ietf. Org" X-OriginalArrivalTime: 05 Apr 2010 08:34:02.0151 (UTC) FILETIME=[BE9D4370:01CAD49A] Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp requirements on IM protocolsin endpoints 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, 05 Apr 2010 08:34:09 -0000 Gunnar is correct with his comment.=20 =20 Ciao Hannes ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of ext Bernard Aboba Sent: 11 February, 2010 05:49 To: 'Gunnar Hellstr=F6m'; 'Ecrit@Ietf. Org' Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp requirements on IM = protocolsin endpoints =09 =09 +1 =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Gunnar Hellstr=F6m Sent: Wednesday, February 10, 2010 3:58 PM To: Ecrit@Ietf. Org Subject: [Ecrit] draft-ietf-ecrit-phonebcp requirements on IM protocols = in endpoints =20 I found a potential small inconsistency in draft-ietf-ecrit-phonebcp =20 draft-ietf-ecrit-phonebcp-14 has a requirement in the media section = 14, saying: =20 " ED-78 Endpoints supporting Instant Messaging (IM) MUST support both [RFC3428] and [RFC4975]." =20 Is this to require too much from the endpoints? Currently the users' = endpoints seldom implement both IM protocols. Would an endpoint only = supporting SIP Message be forbidden to use it in an emergency situation = because it does not have MSRP support? =20 =20 I would expect this double requirement on the PSAPs, so that they can = handle IM of both kinds. =20 This is an endpoint requirement, so I would expect the "both" replaced = by "either"/"or". =20 Proposal: "ED-78 Endpoints supporting Instant Messaging (IM) MUST support either [RFC3428] or [RFC4975]." =20 I suggest to make that change in phonebcp unless there is a good = explanation why both IM protocols shall be required in the end-user = devices. =20 Or is there a use case thought behind it: Alice sends a SIP Message to = the PSAP saying "Help!". The PSAP want to establish an IM session to = find out all details and therefore tries to connect for an MSRP IM = session. If they responded by SIP Message outside a dialogue, their = messages would appear on all terminals logged in on the same SIP address = as the one that Alice uses causing an integrity risk. Was that the thought behind this double protocol requirement? =20 /Gunnar From Martin.Thomson@andrew.com Mon Apr 5 23:11: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 068C53A6822 for ; Mon, 5 Apr 2010 23:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.446, 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 1e8HLfpZ5vf6 for ; Mon, 5 Apr 2010 23:11:18 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 52A623A67D2 for ; Mon, 5 Apr 2010 23:11:18 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:63780 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S214209Ab0DFGLP (ORCPT ); Tue, 6 Apr 2010 01:11:15 -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, 6 Apr 2010 01:11:15 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 6 Apr 2010 14:11:07 +0800 From: "Thomson, Martin" To: "ecrit@ietf.org" Date: Tue, 6 Apr 2010 14:12:30 +0800 Thread-Topic: Comments on draft-forte-lost-extensions-00 Thread-Index: AcrVUCOxdRar5dasSoCJBrSLj41upQ== Message-ID: <8B0A9FCBB9832F43971E38010638454F03E3F30627@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 Subject: [Ecrit] Comments on draft-forte-lost-extensions-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, 06 Apr 2010 06:11:20 -0000 UmVhZGluZyB0aGlzIGRyYWZ0LCBJJ20gbm90IGNvbnZpbmNlZCBvZiB3aGF0IHRoaXMgcHJvdmlk ZXMgLSBhc2lkZSBmcm9tIG1vcmUgc3ludGF4LiAgTG9TVCBhbHJlYWR5IHByb3ZpZGVzIGZvciBt b3N0IG9mIHRoaXMgZnVuY3Rpb25hbGl0eS4NCg0KV2hlcmUgdGhlcmUgaXMgYW1iaWd1aXR5IGFy aXNpbmcgZnJvbSB1bmNlcnRhaW50eSwgTG9TVCBhbGxvd3MgYSBzZXJ2ZXIgdG8gcHJvdmlkZSBt dWx0aXBsZSBjaG9pY2VzOg0KDQogICBBIHNlcnZlciBNQVkgcmV0dXJuIG11bHRpcGxlIDxtYXBw aW5nPiBlbGVtZW50cyBpZiB0aGUNCiAgIHNoYXBlIGV4dGVuZHMgYWNyb3NzIG11bHRpcGxlIHNl cnZpY2UgYXJlYXMuICANCg0KVGhpcyBjb3ZlcnMgIndpdGhpbiBkaXN0YW5jZSBYIiBpZiB5b3Ug dXNlIHVuY2VydGFpbnR5IChhcyBzdGF0ZWQsIHVzZSBhIGNpcmNsZSBhbmQgeW91IG5lZWQgbm8g ZXh0ZW5zaW9uKS4NCg0KInNlcnZlZCBieSIgaXMgdGhlIG1vc3QgY29uZnVzaW5nLiAgSXNuJ3Qg dGhlIHB1cnBvc2Ugb2YgTG9TVCB0byBwcm92aWRlIGEgbGlzdCBvZiB0aGUgZW50aXRpZXMgdGhh dCBzZXJ2aWNlIHRoZSBzZWxlY3RlZCBsb2NhdGlvbj8NCg0KU2VydmljZSBsb2NhdGlvbiBzZWVt cyBhIHJlYXNvbmFibGUgYWRkaXRpb24gdG8gc2VydmljZSBtZXRhZGF0YS4gIEhvd2V2ZXIsIHRo aXMgY2FuIGFscmVhZHkgYmUgcHJvdmlkZWQgYnkgcmVmZXJlbmNlLiAgQSBwcmVzOiBVUkkgd291 bGQgYmUgYWRlcXVhdGUuDQoNCkxpbWl0aW5nIHRoZSBudW1iZXIgb2Ygc2VydmljZXMgaXMgb2Yg bWFyZ2luYWwgYmVuZWZpdCBhdCBiZXN0LCBhbmQgaXMgYXJndWFibHkgYmV0dGVyIGxlZnQgdG8g c2VydmVyIHBvbGljeSB0byBjb250cm9sLg0KDQotLU1hcnRpbg0K From andreaf@cs.columbia.edu Tue Apr 6 13:28: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 5336028C0EF for ; Tue, 6 Apr 2010 13:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=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 TdqvS9xrFZhb for ; Tue, 6 Apr 2010 13:28:01 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 4D0773A6AFD for ; Tue, 6 Apr 2010 13:25:19 -0700 (PDT) Received: from irtdesk1.cs.columbia.edu (irtdesk1.cs.columbia.edu [128.59.22.127]) (user=agf2104 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o36KP9Zt007569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Apr 2010 16:25:13 -0400 (EDT) Message-ID: <4BBB98A5.3030902@cs.columbia.edu> Date: Tue, 06 Apr 2010 16:25:09 -0400 From: Andrea G Forte User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Thomson, Martin" References: <8B0A9FCBB9832F43971E38010638454F03E3F30627@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E3F30627@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments on draft-forte-lost-extensions-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, 06 Apr 2010 20:28:02 -0000 In RFC5222, Section 1 a service region is defined as follows. "To minimize round trips and to provide robustness against network failures, LoST supports caching of individual mappings and indicates the region for which the same answer would be returned ("service region")." and in Section 5.5: "A response MAY indicate the region for which the service URL returned would be the same as in the actual query, the so-called service region." Given that for non-emergency services for each query we could get a large number of service URLs, a service region as per definition above would be the region within which a user would get the same set of service URLs. If even only one of the URLs changes, the set of URLs changes that is, the service region changes. Therefore, for non-emergency services we can distinguish two types of service regions. One is the region served by the single POI (e.g., pizza delivery), the other one is according to the definition in RFC 5222 the region within which the client would always get the same set of service URLs. The second type of service region would include multiple service regions of the first type. Because of this, the service region as defined in RFC 5222 would change very frequently, making the use of service regions as described in RFC 5222 not that useful. This difference between emergency and non-emergency services is due to the fact that PSAPs have service regions that do not overlap significantly with one another and one service region is served by a single PSAP. As explained above, this is not the case for non-emergency services. Please read other answers inline. -Andrea On 4/6/10 2:12 AM, Thomson, Martin wrote: > Reading this draft, I'm not convinced of what this provides - aside from more syntax. LoST already provides for most of this functionality. > > Where there is ambiguity arising from uncertainty, LoST allows a server to provide multiple choices: > > A server MAY return multiple elements if the > shape extends across multiple service areas. > > This covers "within distance X" if you use uncertainty (as stated, use a circle and you need no extension). > It does not. For example, how would LoST handle today a request for all available ATM machines within 300m from my current location? ATM machines do not have a service region. Similarly, if I want to search for a French restaurant to go and have dinner to within 200m from my current location, I do not care about its service region (assuming it has one). I am not interested in the restaurant delivering food to me, I am interested in going to that restaurant. This means that I could be out of its service region and still be willing to go and eat there. Again, service regions have different meanings for non-emergency services. > "served by" is the most confusing. Isn't the purpose of LoST to provide a list of the entities that service the selected location? > The "served by" query is a "normal" LoST query but somehow we have to distinguish it from the other types of queries described in the draft and that is why we define a new boolean element. In other words, "served by" queries are the queries LoST handles today. > Service location seems a reasonable addition to service metadata. However, this can already be provided by reference. A pres: URI would be adequate. > We are doing it by value, yes you can do it also by reference, but as in all the LoST documents we still would like to have a choice. > Limiting the number of services is of marginal benefit at best, and is arguably better left to server policy to control. > What server? Provided and managed by whom? How would a server know about the capabilities/performance of your devices (e.g., available bandwidth), and the intentions of the user? It would be better to leave this choice to the user rather than forcing it on the user. I do not consider this issue marginal. In places like New York City where the number of results can be quite large, a way for the user to limit the number of results to a custom value can be very useful. This is true from a device (and its capabilities) perspective as well as from a user perspective. Also, similarly to large SIP messages in the IMS (SigComp - RFC 3320 anyone?), receiving large LoST messages on low bit-rate links is not good. > --Martin > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > From rbarnes@bbn.com Mon Apr 12 00:00: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 D7F403A69F2 for ; Mon, 12 Apr 2010 00:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=-0.926, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKCvNFmCwT2r for ; Mon, 12 Apr 2010 00:00:32 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 954AF3A69F1 for ; Mon, 12 Apr 2010 00:00:29 -0700 (PDT) Received: from [128.89.255.180] (port=49864 helo=[192.168.1.162]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Dd9-000On4-4m for ecrit@ietf.org; Mon, 12 Apr 2010 03:00:23 -0400 Message-Id: <5275A299-54CF-46EE-AE33-5E9FD054AF2E@bbn.com> From: Richard Barnes To: ecrit@ietf.org 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, 12 Apr 2010 10:00:21 +0300 X-Mailer: Apple Mail (2.936) Subject: [Ecrit] ECRIT client implementation report 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, 12 Apr 2010 07:00:33 -0000 Executive summary: We built a bare-bones ECRIT client in around a week's worth of labor. Full report: Just a quick note to relate some recent experience implementing ECRIT: A colleague and I just spent some time extending the SIP Communicator multi-protocol client [1] so that it can place calls to service URNs using the ECRIT system. It's not phonebcp compliant (e.g., since we probably don't do anything that's in ED-65), but at least you can talk to a PSAP: It turns a service URN into a SIP URI and places a call to it. Our starting point was the "Internet Geolocation Toolkit" (igtk [2]), the HELD/DHCP location client we've been working on. The client itself is written in C++, but we've got a Java version via SWIG. Starting from there, here's the time it took, in man-hours: 16 hr Figuring out SIP Communicator's architecture 4 hr Adding a location plug-in to expose igtk to SIP Communicator 8 hr Adding an "ECRIT resolver" to do LoST mapping 8 hr Integrating the ECRIT resolver into the call path ===== 36 hr TOTAL What it doesn't do: -- LoST discovery -- LoST number recognition -- LoST -- Any ECRIT-specific SIP things (e.g., including service URN or Geolocation) What it does do: -- LIS discovery and HELD -- DHCP geolocation options -- LoST query -- Place SIP call to PSAP URI from LoST You can even add urn:service:sos.police as a "buddy" :) I hope to have the source code posted in the next update to igtk, which should be in a few weeks. Cheers, --Richard [1] [2] From wwwrun@core3.amsl.com Fri Apr 16 08:09:26 2010 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id CB0623A6B53; Fri, 16 Apr 2010 08:09:26 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100416150926.CB0623A6B53@core3.amsl.com> Date: Fri, 16 Apr 2010 08:09:26 -0700 (PDT) Cc: ecrit chair , Internet Architecture Board , ecrit mailing list , RFC Editor Subject: [Ecrit] Document Action: 'Location Hiding: Problem Statement and Requirements' to Informational RFC 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, 16 Apr 2010 15:09:26 -0000 The IESG has approved the following document: - 'Location Hiding: Problem Statement and Requirements ' as an Informational RFC This document is the product of the Emergency Context Resolution with Internet Technologies Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-location-hiding-req-04.txt Technical Summary The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to end points or VoIP service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). For determining the PSAP Uniform Resource Identifier (URI) the usage of the Location-to- Service Translation (LoST) Protocol is envisioned. This document provides a problem statement and lists requirements for situations where the Internet Access Provider (IAP) and/or the Internet Service Provider (ISP) are only willing to disclose limited or no location information. Working Group Summary There is consensus in the WG to publish this document. Document Quality The document has been reviewed by ECRIT working group members and feedback was provided by participants from various emergency services workshops. Personnel Marc Linsner is the document shepherd for this document. From rbarnes@bbn.com Mon Apr 19 14:07: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 EC9673A68D4 for ; Mon, 19 Apr 2010 14:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.179 X-Spam-Level: X-Spam-Status: No, score=-1.179 tagged_above=-999 required=5 tests=[AWL=-1.180, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXNkIydC2xoL for ; Mon, 19 Apr 2010 14:07:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id DBB0F3A67BD for ; Mon, 19 Apr 2010 14:07:39 -0700 (PDT) Received: from [192.1.255.202] (port=62399 helo=col-dhcp-192-1-255-202.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O3yBm-0001Jp-It; Mon, 19 Apr 2010 17:07:30 -0400 Message-Id: <94C75AEE-279A-4E1E-AB21-91FEEAE4EC7E@bbn.com> From: Richard Barnes To: draft-george-ecrit-lamp-post@tools.ietf.org 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, 19 Apr 2010 17:07:29 -0400 X-Mailer: Apple Mail (2.936) Cc: ecrit@ietf.org Subject: [Ecrit] Generalizing draft-george-ecrit-lamp-post 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, 19 Apr 2010 21:07:41 -0000 It seems like this draft is a little specific to a particular use- case. As several people mentioned in Anaheim, there are lots of things around that have numbers on them -- from lamp-posts, mile- posts, utility poles, bridges, etc. If you were going to be inclusive, you might include all the QR codes that Google has been putting up as well. So to avoid having to define new CAtypes for every "numbered thing that can be a location indicator", could I suggest that we make the following generalization? 1. Add a single "place number" ("PLN"?) CAtype with two child nodes: 1.1. A "type" to indicate what type of numbered object is being referred to 1.2. The number of the referenced object 2. Add a first-come-first-served registry of type values From br@brianrosen.net Mon Apr 19 14:12: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 94B903A695B for ; Mon, 19 Apr 2010 14:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_50=0.001, 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 6tQx2HZpoINC for ; Mon, 19 Apr 2010 14:12:21 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id B24153A67FA for ; Mon, 19 Apr 2010 14:12:20 -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 ) id 1O3yG6-0002Mc-OH; Mon, 19 Apr 2010 16:11:58 -0500 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 19 Apr 2010 17:12:04 -0400 From: Brian Rosen To: Richard Barnes , Message-ID: Thread-Topic: Generalizing draft-george-ecrit-lamp-post Thread-Index: AcrgBPWx1c6rHHuwSkC7UNNn/bBjCA== In-Reply-To: <94C75AEE-279A-4E1E-AB21-91FEEAE4EC7E@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: ecrit@ietf.org Subject: Re: [Ecrit] Generalizing draft-george-ecrit-lamp-post 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, 19 Apr 2010 21:12:23 -0000 We thought of that, although what we considered was a simple attribute for type and then just leave value as a normal CAtype is defined. I even said that in the intro to this version. The annoyance is that, once again, to do that, you have to create a new namespace, although I'm getting used to that now (thanks, Martin), especially when adding a Catype that has subelements or attributes. Brian On 4/19/10 5:07 PM, "Richard Barnes" wrote: > It seems like this draft is a little specific to a particular use- > case. As several people mentioned in Anaheim, there are lots of > things around that have numbers on them -- from lamp-posts, mile- > posts, utility poles, bridges, etc. If you were going to be > inclusive, you might include all the QR codes that Google has been > putting up as well. > > So to avoid having to define new CAtypes for every "numbered thing > that can be a location indicator", could I suggest that we make the > following generalization? > > 1. Add a single "place number" ("PLN"?) CAtype with two child nodes: > 1.1. A "type" to indicate what type of numbered object is being > referred to > 1.2. The number of the referenced object > > 2. Add a first-come-first-served registry of type values > > From rbarnes@bbn.com Mon Apr 19 14:18: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 3B12F3A69A0 for ; Mon, 19 Apr 2010 14:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=-0.568, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lD5F+af7vLG4 for ; Mon, 19 Apr 2010 14:18:05 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 417D53A6A61 for ; Mon, 19 Apr 2010 14:18:02 -0700 (PDT) Received: from [192.1.255.202] (port=62450 helo=col-dhcp-192-1-255-202.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O3yLh-0001Rr-EI; Mon, 19 Apr 2010 17:17:45 -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: Mon, 19 Apr 2010 17:17:44 -0400 References: X-Mailer: Apple Mail (2.936) Cc: draft-george-ecrit-lamp-post@tools.ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] Generalizing draft-george-ecrit-lamp-post 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, 19 Apr 2010 21:18:06 -0000 True. The other annoyance is that you add attributes, sub-elements, etc., you have to come up with a binary encoding in order to maintain compatibility with DHCP. Still, it seems wasteful of CAtype space to keep defining new CAtypes for every little thing we notice. Wasn't that kind of the idea with INT? --Richard On Apr 19, 2010, at 5:12 PM, Brian Rosen wrote: > We thought of that, although what we considered was a simple > attribute for > type and then just leave value as a normal CAtype is defined. I > even said > that in the intro to this version. > > The annoyance is that, once again, to do that, you have to create a > new > namespace, although I'm getting used to that now (thanks, Martin), > especially when adding a Catype that has subelements or attributes. > > Brian > > > On 4/19/10 5:07 PM, "Richard Barnes" wrote: > >> It seems like this draft is a little specific to a particular use- >> case. As several people mentioned in Anaheim, there are lots of >> things around that have numbers on them -- from lamp-posts, mile- >> posts, utility poles, bridges, etc. If you were going to be >> inclusive, you might include all the QR codes that Google has been >> putting up as well. >> >> So to avoid having to define new CAtypes for every "numbered thing >> that can be a location indicator", could I suggest that we make the >> following generalization? >> >> 1. Add a single "place number" ("PLN"?) CAtype with two child nodes: >> 1.1. A "type" to indicate what type of numbered object is being >> referred to >> 1.2. The number of the referenced object >> >> 2. Add a first-come-first-served registry of type values >> >> > > From hgs@cs.columbia.edu Mon Apr 19 14:28: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 38C4D3A68BA for ; Mon, 19 Apr 2010 14:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, 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 nzjBRLjf-G7q for ; Mon, 19 Apr 2010 14:28:11 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 583763A67BD for ; Mon, 19 Apr 2010 14:28:11 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o3JLRxR2000996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Apr 2010 17:27:59 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <94C75AEE-279A-4E1E-AB21-91FEEAE4EC7E@bbn.com> Date: Mon, 19 Apr 2010 17:27:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94C75AEE-279A-4E1E-AB21-91FEEAE4EC7E@bbn.com> To: Richard Barnes X-Mailer: Apple Mail (2.1078) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: draft-george-ecrit-lamp-post@tools.ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] Generalizing draft-george-ecrit-lamp-post 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, 19 Apr 2010 21:28:12 -0000 I think there's little advantage of sub-spacing; we have no shortage of = CA numbers and each time you do that, you then have to face the issue of = whether a new element belongs in one bin or the other. Henning On Apr 19, 2010, at 5:07 PM, Richard Barnes wrote: > It seems like this draft is a little specific to a particular = use-case. As several people mentioned in Anaheim, there are lots of = things around that have numbers on them -- from lamp-posts, mile-posts, = utility poles, bridges, etc. If you were going to be inclusive, you = might include all the QR codes that Google has been putting up as well. >=20 > So to avoid having to define new CAtypes for every "numbered thing = that can be a location indicator", could I suggest that we make the = following generalization? >=20 > 1. Add a single "place number" ("PLN"?) CAtype with two child nodes: > 1.1. A "type" to indicate what type of numbered object is being = referred to > 1.2. The number of the referenced object >=20 > 2. Add a first-come-first-served registry of type values >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From rbarnes@bbn.com Thu Apr 22 08:57: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 86A443A6B9B for ; Thu, 22 Apr 2010 08:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[AWL=-1.105, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjW6o8ity8o7 for ; Thu, 22 Apr 2010 08:57:20 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 89B963A67D3 for ; Thu, 22 Apr 2010 08:57:20 -0700 (PDT) Received: from [192.1.255.202] (port=53105 helo=col-dhcp-192-1-255-202.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4ym5-000LnM-Vh for ecrit@ietf.org; Thu, 22 Apr 2010 11:57:10 -0400 Message-Id: <1A8DFA1A-1562-45D4-B674-111897A99A9F@bbn.com> From: Richard Barnes To: ecrit@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 22 Apr 2010 11:57:07 -0400 X-Mailer: Apple Mail (2.936) Subject: [Ecrit] Announcement: Emergency Services Workshop 7 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, 22 Apr 2010 15:57:21 -0000 Dear colleagues, We're pleased to announce that registration is open for the seventh Emergency Services Workshop, to be held 11-13 May 2010, at the University of Maryland, in College Park, MD, USA. A registration link, as well as agenda and travel information, can be found on the ESW website: We invite talks of 30-60 minutes on topics related to IP emergency services, especially around the following topics: -- Standards development activities related to emergency communications -- Prototypes of standards-based IP emergency services -- Internet-based authority-to-citizen alerts and early warning -- Automatic IP geolocation technologies and deployment considerations -- Implementation and deployment of IP-based emergency calling systems Please send proposals for presentations to . Background: The Emergency Services Workshop series is an ongoing effort in the emergency services community to coordinate global standards and technologies for emergency calling and emergency notification. The primary focus of the workshop series is foster coordination among the many standards development organizations (SDOs) involved in emergency services as they all work toward a global solution for emergency communications using Internet technologies. In addition, the workshops try to bring in operational and regulatory perspectives on emergency services, so that these experiences and requirements can be incorporated into ongoing technical development processes. Participation is open all stakeholders in the emergency communications system, including industry (e.g., equipment vendors or telecommunications companies) as well as government (e.g., regulatory bodies or emergency response organizations). Thanks for your interest, The ESW Coordination Team From rbarnes@bbn.com Fri Apr 30 09:01:28 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 5BD4B3A6B02 for ; Fri, 30 Apr 2010 09:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.785 X-Spam-Level: X-Spam-Status: No, score=-0.785 tagged_above=-999 required=5 tests=[AWL=-0.786, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqK3HTk-b+IM for ; Fri, 30 Apr 2010 09:01:27 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 19F043A6405 for ; Fri, 30 Apr 2010 09:01:27 -0700 (PDT) Received: from [128.89.253.165] (port=56300 helo=[192.168.1.46]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O7seO-000EgN-OD for ecrit@ietf.org; Fri, 30 Apr 2010 12:01:12 -0400 Message-Id: From: Richard Barnes To: ecrit@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 30 Apr 2010 12:01:12 -0400 X-Mailer: Apple Mail (2.936) Subject: [Ecrit] ESW7: Detailed agenda and reminder to register 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, 30 Apr 2010 16:01:28 -0000 Dear colleagues, This is an update to let you know that the detailed agenda has been posted for the upcoming Emergency Services Workshop: Also, just a reminder that if you are planning to attend, please fill out the registration form on the website: Thanks for your interest, The ESW Coordination Team